Привет, Хабр!
Мы в 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 и ряд локальных систем. Они охватывают и производственные процессы, и финансовые, и контроль, и управление складом. Всего восемь областей, которые полностью закрывают производственный цикл.
Проект был рассчитан на год, но из-за пандемии старт пришлось сдвинуть — мы подготовились и запустили его на удалёнке. На то, чтобы заточить проект под дистанционную работу, ушло 1,5 дополнительных месяца, но мы справились. Это довольно-таки недолгий срок для такой масштабной истории, как переход целой фабрики на новую ERP-систему. Ведь у нас копится опыт, который мы собираем, записываем и превращаем в руководства.
Все шаги записаны: как в 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. Таким образом получили список задач по изменению систем и процессов, над которыми надо работать.
Основные гэпы при внедрении 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? Иногда. Но и интересно тоже.