cutover plan
1 cutover plan
См. также в других словарях:
cutover — cut‧o‧ver [ˈkʌtəʊvə ǁ oʊvər] noun [countable] 1. COMMERCE a very quick change from one stage of a business plan, deal etc to the next stage 2. COMPUTING a time when a company quickly changes from using one particular type of computer equipment,… … Financial and business terms
SAP Implementation — is the whole of processes that defines a complete method to implement SAP software in an organization. The SAP implementation method described in this entry is a generic method and not a specific implementation method as such. It is based on best … Wikipedia
Parallel adoption — is a method for transferring between an old (IT) system to a target (IT) system in an organization. In order to reduce risk, the old and new system run simultaneously for some period of time after which, if the criteria for the new system are met … Wikipedia
Coupon-eligible converter box — TV Converter Box Coupon Program URL https://www.dtv2009.gov/[dead link] … Wikipedia
Ghana — Ghanaian, Ghanian /gah nee euhn, gan ee /, n., adj. /gah neuh, gan euh/, n. 1. a republic in West Africa comprising the former colonies of the Gold Coast and Ashanti, the protectorate of the Northern Territories, and the U.N. trusteeship of… … Universalium
Management information system — A management information system (MIS) provides information needed to manage organizations efficiently and effectively.[1] Management information systems involve three primary resources: people, technology, and information. Management information… … Wikipedia
Monongahela National Forest — Coordinates: 38°55′45″N 79°50′52″W / 38.92917°N 79.84778°W / 38.92917; 79.84778 … Wikipedia
Devon and Somerset Fire and Rescue Service — (DSFRS) Devon and Somerset Fire and Rescue Service (DSFRS) area Coverage Area Devon and Somerset, excluding Bath and North East Somerset and … Wikipedia
Eastern savannas of the United States — The eastern savannas of the United States covered large portions of the east side of the continent until the early 20th century. These were in a fire ecology of open grassland and forests with low ground cover of herbs and grasses.The frequent… … Wikipedia
Virtual Case File — (or VCF) was a software application developed by the United States Federal Bureau of Investigation between 2000 and 2005. The project was not close to completion when it was officially abandoned in January 2005, having turned into a complete… … Wikipedia
Dorset Fire and Rescue Service — area Coverage Area Dorset, South West England. Size 2 … Wikipedia
cutover plan
Смотреть что такое «cutover plan» в других словарях:
cutover — cut‧o‧ver [ˈkʌtəʊvə ǁ oʊvər] noun [countable] 1. COMMERCE a very quick change from one stage of a business plan, deal etc to the next stage 2. COMPUTING a time when a company quickly changes from using one particular type of computer equipment,… … Financial and business terms
SAP Implementation — is the whole of processes that defines a complete method to implement SAP software in an organization. The SAP implementation method described in this entry is a generic method and not a specific implementation method as such. It is based on best … Wikipedia
Parallel adoption — is a method for transferring between an old (IT) system to a target (IT) system in an organization. In order to reduce risk, the old and new system run simultaneously for some period of time after which, if the criteria for the new system are met … Wikipedia
Coupon-eligible converter box — TV Converter Box Coupon Program URL https://www.dtv2009.gov/[dead link] … Wikipedia
Ghana — Ghanaian, Ghanian /gah nee euhn, gan ee /, n., adj. /gah neuh, gan euh/, n. 1. a republic in West Africa comprising the former colonies of the Gold Coast and Ashanti, the protectorate of the Northern Territories, and the U.N. trusteeship of… … Universalium
Management information system — A management information system (MIS) provides information needed to manage organizations efficiently and effectively.[1] Management information systems involve three primary resources: people, technology, and information. Management information… … Wikipedia
Monongahela National Forest — Coordinates: 38°55′45″N 79°50′52″W / 38.92917°N 79.84778°W / 38.92917; 79.84778 … Wikipedia
Devon and Somerset Fire and Rescue Service — (DSFRS) Devon and Somerset Fire and Rescue Service (DSFRS) area Coverage Area Devon and Somerset, excluding Bath and North East Somerset and … Wikipedia
Eastern savannas of the United States — The eastern savannas of the United States covered large portions of the east side of the continent until the early 20th century. These were in a fire ecology of open grassland and forests with low ground cover of herbs and grasses.The frequent… … Wikipedia
Virtual Case File — (or VCF) was a software application developed by the United States Federal Bureau of Investigation between 2000 and 2005. The project was not close to completion when it was officially abandoned in January 2005, having turned into a complete… … Wikipedia
Dorset Fire and Rescue Service — area Coverage Area Dorset, South West England. Size 2 … Wikipedia
Опыт смены SAP-хостинга: как мигрировать системы, чтобы не было мучительно больно
Или можно? Конечно, миграция SAP-систем — это сложный и кропотливый процесс, для успеха которого важна слаженная работа всех участников. А если миграция проводится в сжатые сроки — задача многократно усложняется. Не все решаются на это. Причин может быть несколько. Например, процесс сам по себе длителен и организационно сложен. Плюс есть риск незапланированных простоев систем. Или клиенты не уверены, что, пережив такую операцию, получат бенефиты, соразмерные потраченным усилиям. Однако бывают и исключения.
Под катом расскажем о трудностях, с которыми сталкиваются заказчики в процессе миграции и сопровождения SAP-систем, обсудим, почему стереотипы не всегда соответствуют реальности, и поделимся кейсом, как нам удалось мигрировать системы заказчика в новую инфраструктуру всего за три с небольшим месяца.
Хостинг SAP-систем
Еще каких-то пять лет назад сложно было представить, что клиенты массово начнут использовать хостинговые ресурсы для SAP-приложений. В большинстве случаев их внедряли on-premise. Однако с развитием моделей аутсорсинга и рынка облачных услуг мировоззрение заказчиков начало меняться. Каковы аргументы, влияющие на выбор в пользу облака для SAP?
В чем заключаются сложности смены SAP-хостинга?
Хостинги бывают разные. Несоответствие заявленному уровню сервиса, множество «но» и звездочек с оговорками мелким текстом, ограниченность ресурсов и возможностей хостинг-провайдера, отсутствие гибкости в вопросах коммуникации с клиентом, бюрократия, технические ограничения, низкая компетентность специалистов технической поддержки, а также многие другие нюансы — это лишь малая часть подводных камней, с которыми могут столкнуться клиенты в процессе эксплуатации их бизнес-систем в аутсорсинговых инфраструктурах. Зачастую для клиента все это остается в тени, в дебрях многостраничного контракта, и всплывает уже в процессе пользования услугами.
В какой-то момент для заказчика становится очевидным, что уровень сервиса, который он получает, далек от его ожиданий. Это является неким катализатором к поиску решений по исправлению ситуации и в случае неуспеха, когда проблемы накапливаются до предела и становится совсем больно, переходят к активным действиям по проработке альтернативных вариантов в направлении смены поставщика услуги.
Почему тянут до последнего? Причина проста — процесс переноса систем для клиентов не всегда прозрачен и понятен. Клиенту сложно оценить действительные риски, связанные с процессом миграции. Можно сказать, что миграция для клиентов — это своеобразный черный ящик: непонятно, цена, время простоя систем, риски и как их нивелировать, да и вообще темно и страшно. Тут ведь как, если не получится, то головы полетят и у топов, и у исполнителей.
SAP — это системы корпоративного уровня, сложные и мягко говоря не дешевые. На их внедрение, доработку, сопровождение тратятся приличные бюджеты и от их доступности и корректной работы зависит жизнедеятельность предприятия. А теперь представьте последствия остановки какого-нибудь крупного производства. Это финансовые потери, которые могут исчисляться цифрами с большим количеством нулей, а также репутационные и другие, не менее значимые риски.
Разберем сложности, которые могут возникнуть на каждом из этапов на кейсе миграции SAP-систем одного из наших заказчиков.
Подготовка и проектирование
Миграция — это формула со множеством различных составляющих. И одним из самых важных является этап проектирования и подготовки целевой (новой) инфраструктуры.
Нам необходимо было погрузиться в существующую реализацию систем, их архитектуру. В целевой инфраструктуре мы где-то повторили существующие решения, в каких-то моментах дополнили и улучшили, где-то переделали, продумали и выбрали решения по обеспечению отказоустойчивости и доступности, а также максимально консолидировали все ресурсы.
В процессе проектирования было выполнено много разных упражнений, которые в итоге позволили максимально подготовиться к миграции и учесть всевозможные нюансы и подводные камни (о них позднее).
Что у нас в результате получилось — индивидуально спроектированная инфраструктура частного облака на базе нашего ЦОД:
А вот как реализовали все это с технической точки зрения.
Как устроен проектный менеджмент в Mars
Мы в Mars уже много лет внедряем и развиваем SAP ERP систему, потому что компания постоянно расширяется и важно, чтобы все наши системы были едины. Наш проектный менеджмент ведётся по «золотому стандарту» — набору практик, который работает в любой стране, где присутствует Mars. Недавно мы проапгрейдили Одинцовскую кондитерскую фабрику (выпускает продукцию под такими брендами, как «Коркунов», Dove, а также шоколадные плитки M&M’s) — и готовы поделиться опытом.
О внедрении темплейта SAP ERP на Одинцовской кондитерской фабрике рассказывает Светлана Дешкова, Deployment Project Manager в Mars.
Зачем и как мы внедряем темплейт SAP ERP
Наш шаблон SAP ERP называется Atlas — на него переведены почти все подразделения Mars, но мы расширяемся, и поэтому процесс внедрения шаблона почти бесконечен.
Одинцовская кондитерская фабрика Mars, которая выпускает «Коркунов», работала на локальной SAP, причём на старой версии, которая уже не поддерживается. Плюс, на фабрике существовало множество отдельных систем для управления разными направлениями работы, которые между собой взаимодействовали. IT-подразделение Mars не могло дальше всё это поддерживать — ввиду высокой стоимости и трудоёмкости процесса. Платформу надо было менять.
Кроме того, фабрике надо было встраиваться в глобальные процессы, например по прослеживаемости, качеству готовой продукции. В этом смысле работать в глобальной системе необходимо, чтобы следовать корпоративным стандартам и иметь возможность развиваться с поддержкой IT-систем.
В Одинцово мы внедряли полный набор стандарта для России: SAP ERP, SAP EWM и ряд локальных систем. Они охватывают и производственные процессы, и финансовые, и контроль, и управление складом. Всего восемь областей, которые полностью закрывают производственный цикл.
Процессы на Одинцовской фабрике, которые надо было интегрировать в систему
Все шаги записаны: как в Mars организована документальная база для проектного управления и внедрения изменений
В Mars процессы проектного и программного управления стандартизированы, описаны и задокументированы. Все изменения, которые мы внедряем работу, происходят по гибридной методологии, совмещающей классический и agile-подходы. За основу взяты PRINCE 2 и PMP, но они адаптированы под Mars. У нас есть две системы документации.
1. Библиотека документов, посвящённых проектному управлению
Это ресурс, на котором собрана информация, описывающая все наши внутренние процессы: управление проектами, программами проектов, продуктами, управление изменениями и Agile-подход. С одной стороны, мы базируемся на классических принципах проектного управления, включающем все фазы и формальные подтверждения прохождения каждой фазы. Но в реализации проекта мы опираемся также и на Agile-принципы и применяем Agile-подходы и инструменты.
В компании работает команда методологов, которая отвечает за актуальность и полноту этого сета документации, рассказывает, помогает, устраивает форумы по обмену опытом. В документах чётко расписано, на каком этапе к кому ходить, с кем разговаривать, какие ресурсы привлекать. Всё, начиная с того, как и где найти средства на проект, как проводить feasibility, а как — development.
Библиотека проектных документов включает в себя даже базовые вещи, например такую схему фаз управленческого процесса.
Например, когда мы делаем проекты с поставщиком, у которого есть свой тимлид, мы даём поставщику ссылку на этот портал — и они сами им пользуются. Это снимает массу вопросов о том, какие документы готовить, с кого собирать подтверждения и так далее.
2.Процессная документация
В Mars есть целый институт функциональных экспертов, которые досконально знают процессы в своих областях. Для SAP ERP эти процессы задокументированы. Например, документ описывает, как построено производство: что есть на входе, что делается внутри производственного процесса, что мы получаем на выходе. Такие документы переходят из проекта в проект, они служат вводными, чтобы проектная команда могла разработать to-be-документацию, а IT-подразделение могло перестроить систему под процесс. С этой частью документации могут работать и ключевые пользователи. Для некоторых изменений не надо привлекать функциональных экспертов, достаточно инициативы «на местах». В некоторых проектах мы собираем требования в виде user story.
Но, конечно, никакая документация не заменит практического опыта, и тут на помощь всегда придут коллеги, менеджеры, управляющий комитет проекта. У нас есть внутреннее комьюнити проектных менеджеров. Примерно раз в две недели мы собираемся, чтобы обсудить новости по управлению проектами и изменениями, обменяться опытом ведения проектов. В эту группу входят люди не только из российского или европейского подразделения — это сообщество сотрудников Mars со всего мира, вовлеченных в проектный менеджмент, управление изменениями, а также интересующихся новыми подходами к внедрению изменений. Кроме того, у нас есть Agile-амбассадоры и коучи, которые могут помочь использовать Agile-подход в проектах. Так что, если есть сложности, всегда можно спросить у более опытных коллег, как лучше поступить.
Подходы к проектному управлению работают по всему миру. Есть как глобальные, стандартные для всего Mars процессы, так и локальные — для нужд сегмента или страны.
Проектные менеджеры в Mars разделены по сегментам. Всего их три: это Mars Wrigley (шоколад и жевательные резинки), Petcare (корма для животных) и Mars Food. А все процессы проектного управления стандартизированы, и применять их можно в любой стране. Конечно, есть специфика работы со стейкхолдерами: в разных локациях нужно строить диалог по-своему, но общая методология работает везде.
В случае с фабрикой и внедрением SAP мы организовываем проект по уже отработанной схеме.
Первый этап: как всё учесть и разработать план
На Одинцовской фабрике всё начиналось с классической для ведения проектов стадии feasibility, которая отняла несколько месяцев. Старт работы над проектом — scope and complexity — это воркшоп, занимающий 2–3 дня. В это время собираются все участники будущего проекта, делятся по функциональным областям и составляют общее видение проекта.
Всего над внедрением систем и процессов на фабрике у нас работало около 70 человек. Их условно можно поделить на три функциональные команды.
Функциональные эксперты. Как мы уже говорили, в Mars существует институт сотрудников, которые способны разобраться в любом процессе и создать его лучшую версию. Они лидируют построение и внедрение процесса, вовлекая бизнес-команду (ключевых пользователей, функциональных менеджеров) и IT.
Ключевые пользователи (бизнес-эксперты). Люди, которые работают в определённой области и хорошо знают as-is-процесс, его достоинства и недостатки. Вместе с функциональными экспертами они обсуждают as-is и на основе него строят to-be-процесс, они же отвечают за последующее тестирование и внедрение процесса на местах
IT-команда обычно представлена внешним поставщиком и рядом внутренних сотрудников. Это команда, которая, собственно, и отвечает за изменения в системе. Это аналитики, разработчики, секьюрити и поддержка — множество специалистов. На первом этапе представители этой команды слушают задачи, вникают в процесс и объясняют, что можно сделать в системе быстро, а что нет, занимаются приоритезацией задач, определяют, нужны ли дополнительные расходы и глобальные изменения в шаблоне.
Также в проекте участвует группа менеджеров-заказчиков проекта. Они ставят глобальные цели и помогают определить KPI. У нас есть спонсор проекта, обычно это финансовый менеджер, он выделяет средства на проект. В случае с фабрикой в Одинцово у нас было три бизнес-спонсора: CFO в России, финансовый директор, отвечающий за производство в Европе, и директор самой фабрики. В управляющий комитет проекта входят также руководители функциональных направлений, например логистики, финансов, производства. Они помогают принимать оперативные решения по проекту (изменение скоупа или сроков, уменьшение рисков путём административных мер и изменений в процессах). К бизнес-функции относятся и проектные менеджеры — то есть специалисты, которые ведут проект и отвечают за изменение системное и процессное.
Проект начинается с ревью существующих процессов, в нашем случае — тех, что мы задокументировали как часть as-is-процессов на фабрике. Потом описали то состояние, к которому мы хотим прийти: to be. Таким образом получили список задач по изменению систем и процессов, над которыми надо работать.
Дашборд статуса feasibility: видно, что часть процессов as is мы даже не описывали, потому что после внедрения Atlas они просто-напросто не будут нужны или кардинально поменяются.
Основные гэпы при внедрении ERP всегда связаны с локальными особенностями, из-за которых глобальный шаблон надо изменять или кастомизировать. У фабрики в Одинцово тоже обнаружилась своя специфика:
Нелинейное производство, при котором на выходе мы получаем не готовую коробку конфет, а отдельные конфеты, которые ещё предстоит упаковать.
Линия конфет ручной работы.
Фабрика — отдельное юридическое лицо, но она плотно взаимодействует с другими фабриками и складами Mars по так называемым ICB (intercompany business)-процессам
Изначально шаблон всех этих особенностей не учитывал — пришлось его дорабатывать.
Когда мы определились, кто и над чем будет работать, мы разделили процессы по стримам-функциям. У нас их получилось восемь. По каждой функции проходит серия воркшопов и окончательное формирование to-be-процессов и требований к системе. В это же время работают и кросс-функциональные команды. Задача первого этапа — создать уточнённый проектный план, определиться с бюджетом проекта и ресурсами, которые для него потребуются, составить список to-be-процессов и требований к системам. Когда эта стадия завершилась, у нас было чёткое понимание, что делать и как.
Второй этап: как в одном проекте совместить Agile и Waterfall
Когда мы переводим предприятие на SAP-ERP-шаблон, в этом процессе всегда много от Waterfall-методики. Связано это с тем, что мы не можем внедрять ERP-систему по частям: выводить в продуктив отдельные функциональные блоки очень трудозатратно.
Но внутри фазы реализации мы делаем спринты. На каждый из восьми стримов у нас пришлось 2–3 спринта. Один спринт занимал 1–4 недели. По результатам спринтов мы проводили промежуточное тестирование новых функций с бизнес-заказчиками, чтобы можно было получить раннюю обратную связь и доработать систему под нужды пользователей.
Так выглядел план разработки со всеми спринтами и дедлайнами до того, как в дело вмешалась пандемия.
После того как мы завершили все спринты, у нас прошло интеграционное и end-to-end-тестирование. Мы проверили, как работает система, — от закупки сырья до упаковки для производства продукта до закрытия финансового периода. Тестирование прошло в два этапа, каждый из которых занял месяц. Ещё два месяца было заложено на Cutover — подготовку и миграцию данных, подготовку авторизаций, тренинги. Но Go-Live был, естественно, один.
Ещё один из Agile-принципов, который мы использовали, — возможность вносить изменения (то есть изменять проектный скоуп) даже в последний момент, если мы видим в этом выгоду и возможность. Это очень помогает добиться более точной работы системы, процесса, а также повысить удовлетворённость пользователей.
Так мы совместили две методики, собрав лучшие инструменты и подходы.
По такому дашборду мы отслеживали процесс тестирования — всё прошло штатно.
Из-за локдауна запуск отложили — пришлось срочно переориентировать проект для удалённого старта. На что ушло несколько недель:
На технику. У многих сотрудников на фабрике не было персональных лэптопов, а в переговорках собираться можно было только ограниченному количеству людей. Пришлось их усилить технически, а также закупить наушники-гарнитуры, с помощью которых люди могли бы общаться с проектной командой.
На обучение сотрудников. Мы пользуемся Microsoft Teams и подключили к этому инструменту фабрику. У нас появилась виртуальная комната, в которой круглосуточно дежурил кто-то из проектной команды, и любой человек с фабрики мог позвонить или написать, если возникал вопрос.
На подготовку амбассадоров. Это люди, которым мы провели дополнительное, более углублённое обучение по работе в новых системах. Они на старте поддерживали остальных сотрудников и давали обратную связь.
Третий этап: как внести изменения безболезненно для людей
На протяжении года у нас не было сложностей с вовлечённостью людей, потому что у фабрики было желание стать частью глобального SAP-ERP-шаблона. Руководство фабрики также поддерживало проект, объясняло сотрудникам, что изменения будут, а мы рассказывали, что поможем к ним адаптироваться. После старта мы встроились в оперативные рабочие встречи, то есть мы не собирали людей отдельно, а приходили на стандартные встречи сотрудников, слушали, что происходит у людей, отвечали на вопросы, помогали справиться с адаптацией к новой системе и процессам.
Когда проект стартовал, были свои сложности. Из-за удалёнки мы не могли физически находиться на фабрике, не могли пообщаться со многими людьми здесь и сейчас, хотя поддерживали пользователей дистанционно.
Обратную связь собирали и с помощью ключевых пользователей, которые просто ходили и опрашивали сотрудников, и через форму обратной связи. На основе откликов вносили небольшие изменения в систему — ничего глобального делать не пришлось, только мелкие доработки и дополнительное обучение.
Иногда изменения сталкивались с человеческим фактором: сотрудникам было трудно перестроиться на новую схему работы, кто-то боялся применять новые инструменты. Тут мы снова использовали ключевых пользователей и амбассадоров, которые приходили на места и ещё раз проводили пошаговое обучение работников. Если бы не дистанционка, мы бы могли многое сделать сами — вплоть до того, чтобы подойти и похлопать человека по плечу, похвалить и сказать, что всё получается. Но наши амбассадоры тоже отлично отработали.
Как мы поняли, что проект закончен
У каждого проекта, конечно, есть свои KPI, которые определяются в самом начале, перед запуском. Мы их согласовываем с управляющим комитетом проекта, в который выходят менеджеры и директора. Для каждого случая они индивидуальны. В случае с Одинцовской кондитерской фабрикой было так:
Первый показатель — внедрение всех процессов. Поскольку у нас был список процессов, которые мы должны запустить, нужно было просто отследить, какие из них запущены и в какой день. Мы «поставили галочки».
Второй показатель — для каждого проекта мы создаём issue-трекер, в котором фиксируем все возникающие проблемы. Чтобы проект считался завершённым, в этом трекере не должно остаться критичных проблем — то есть тех, что останавливают работу. Даже если какие-то задачи не решены, они не должны влиять на производственный процесс. Также мы должны были договориться с командой поддержки о том, какие ещё улучшения в рамках continuous improvement мы им передаём для работы, но в целом в issue-трекере должен быть порядок.
У нас также был cutover-план по переходу со старых систем и процессов на новые, в нём было около 1 000 действий. Постепенно мы все их закрыли.
Один из KPI, который основан на операционной деятельности, — закрытие двух финансовых периодов. У нас они занимают 4 недели, мы должны были отследить, что фабрика сделала два закрытия в срок.
Ну и последний признак того, что проект готов, — это подтверждение от команд поддержки, что они получили все тренинги и материалы и готовы взять фабрику на поддержку. Сначала изменения поддерживает проектная команда, а поддержка в это время смотрит и учится. Потом функции переключаются: пользователи идут с проблемами в поддержку, а проектная команда помогает в сложных случаях. И только когда поддержка полностью принимает работу, проект считается законченным.
Вот таким получился наш проект по внедрению SAP ERP на Одинцовской кондитерской фабрике. Сложно ли вести проекты в Mars? Иногда. Но и интересно тоже.
