Генеральный директор ООО «АиБ Цифровизация»
Дмитрий Смирнов
Жесткое требование заключалось в том, что мы должны обеспечить прозрачную систему контроля за ходом проекта. Требование мы удовлетворили. Но история нашего заказчика так показательна, что мы попросили его рассказать, на какие грабли наступило предприятие в своей первой попытке внедрить «1С:ERP». Передаю слово финансовому директору «ЭлекКом Логистик» Алине Николаевой.
Финансовый директор ООО «ЭлекКом Логистик»
Алина Николаева
Cтатистика по внедрениям ERP в России
Согласно исследованию ИНФОСТАРТ, только 10% проектов внедрения ERP-систем в России завершаются в запланированные сроки и бюджет (источник: //infostart.ru/pm/2208051/).
В 65 % процентов случаев запланированные сроки и стоимость проектов были превышены сверх нормы, допустимой с точки зрения менеджмента предприятий: стоимости – не более, чем на 20%, сроков – не более, чем на 50%, но при этом внедрено менее 85 % необходимого функционала.
В 20 % случаев проекты соответствовали критерию внедрения хотя бы 85 % необходимого функционала, но фактические сроки и / или стоимость проекта превысили первоначально допустимый с точки зрения менеджмента предприятий уровень.
В 5 % случаев сроки и стоимость проектов не были превышены сверх допустимого менеджментом предприятий уровня, но необходимый функционал внедрён намного менее, чем на 85 %. Данная ситуация возникла в результате волевого решения руководства предприятий о прекращении проектов во избежание втягивания в бесконечный процесс доработок, устранения недостатков системы и накопления убытков.
Только 10 % предприятий сумели внедрить более 85 % запланированного функционала, не превысив сроки и стоимость проекта сверх допустимого менеджментом предприятий уровня. Результаты этих проектов попали в диапазон успешных проектов. Эти цифры хорошо иллюстрируют, почему наш опыт смены интегратора — не исключение, а часть системной проблемы отрасли.
Кратко о компании
«ЭлекКом» проектирует и производит сложное электротехническое оборудование для объектов энергетики, промышленности и инфраструктуры, включая инженерно-строительное сопровождение на энергообъектах заказчика. У нас три бизнес-направления, несколько производственных площадок, сеть офисов продаж и большой складской распределительный центр.
Для сопровождения деятельности в качестве основной информационной системы мы развивали «1С:УПП». За 15 лет мы обросли замечательными АРМами в части управления продажами, закупками, производственными и складскими процессами и уникальной консолью управления уровнем складского запаса.
Почему решили менять систему и как совершили первую ошибку
Компания бурно развивается: за последние 5 лет мы открыли 2 новые производственные площадки, появились сложные комплексные продукты с новым уровнем сервисного инженерного обслуживания. Процессы перестраиваются и улучшаются буквально на лету. Это серьезно повышает требования к учетной системе: с более чем миллионом активных номенклатур нам критически важно считать ROA (рентабельность активов) и поддерживать эффективное управление будущей прибылью. Мы пришли к решению внедрить более гибкую систему — «1С:ERP».
И сразу же мы совершили первую серьезную ошибку: при выборе интегратора купились на громкое имя, доверились, не проведя необходимой проверки по значимым для нас критериям. Расскажу, на какие грабли мы наступили, и какие требования, получив этот опыт, предъявили к новому интегратору.
Теперь советую всем: проверять, хватает ли у интегратора ресурсов, чтобы реализовать ваш проект, фиксировать все важные условия в договоре.
Грабли № 1: почему я спала по 3 часа в сутки
Внедрение ERP — всегда сложный процесс, особенно когда в проекте задействовано более 500 специалистов, включая 100 предметных экспертов в рабочей группе. Координация такого количества людей — серьезный вызов даже для опытных управленцев.
На старте мы работали с интегратором через электронную почту, и это стало настоящим испытанием. Я оказалась в роли «администратора на пределе»: три часа сна в сутки, постоянный цейтнот. Немудрено, что в такой ситуации управление проектом вышло из-под моего контроля. И первый вывод, который мы для себя сделали – нужна единая платформа для ведения работы по проекту, где:
• все участники видят статусы задач;
• контролируют качество отчётности;
• фиксируют завершение этапов;
• и, главное, — инструмент должен быть доступен команде заказчика.
Это не просто удобство, а необходимость для успешного внедрения.
Грабли № 2: кто должен ставить подпись в отчетных документах
К сожалению, наш интегратор требовал, чтобы у нас были назначены руководители рабочих групп по функциональным блокам. У нас есть функции, к ним смело можно отнести регучет, казначейство, и на этом, пожалуй, все. Вся остальная деятельность компании – это бизнес-процессы. К примеру, у нас три производства в разных городах — Казани, Чебоксарах и Новочебоксарске — и ни один из директоров производства не был готов отвечать за процессы других производственных площадок.
Я как руководитель проекта оказалась в сложной ситуации: интегратор требовал единого ответственного, что было невозможно обеспечить технически. Мне приходилось лично согласовывать решения между тремя производствами и всеми подразделениями, связанными с ними кроссфункционально, перед тем, как выдать их интегратору. Это отнимало значительное время и замедляло проект. Я оказалась заложником условий договора и снова стала «узким местом».
Поэтому, когда мы начали выбирать нового интегратора, второе условие, которое мы включили в конкурс, это то, что лицами, уполномоченными ставить подпись в отчётных документах, которые будут фиксировать «да, это должно быть так» или «нет, так не подходит», — должны быть сами владельцы бизнес-процессов.
Грабли № 3: работа на два фронта
Наша компания использует специализированную консоль управления уровнем складского запаса. У нас огромное количество номенклатур, поэтому нам критически важно управлять закупками и поддерживать оптимальный уровень складских запасов. Такой подход позволяет достичь оптимального ROA, где минимальные запасы обеспечивают максимальную эффективность производства и продаж. То есть мы стараемся не замораживать деньги в складских остатках. Для реализации этой задачи мы расширили функционал «1С:ERP» специальным модулем управления запасами – встроенным решением, максимально приближенным к нашей прежней системе.
В рамках договора интегратор сформировал две проектные команды:
1. по специализированному модулю управления запасами,
2. по основной системе ERP.
Ключевая сложность заключалась в двойном руководстве со стороны интегратора. Как заказчик я столкнулась с серьезными координационными проблемами – создавалось впечатление работы с двумя разными компаниями.
Этот опыт привел нас к важному решению: при новом конкурсе мы жестко зафиксировали требование о едином руководителе проекта от интегратора, отвечающем за координацию обоих направлений.
Грабли № 4: непрозрачность
При анализе отчетных документов от интегратора я столкнулась с критической проблемой: не могла оценить полноту отражения требований. Несмотря на глубокое знание процессов компании (многие из которых создавались при моем участии), в документах было невозможно понять:
• закрыты ли все требования решениями;
• какие функции покрываются типовым решением, а где остаются разрывы;
• какие из выявленных разрывов мы готовы принять, а какие — нет.
Эта неопределенность привела к серьезным последствиям в работе с первым интегратором.
Мы планировали переход с одной системы на другую с 1 января 2025 года. А теперь представьте: весь 1-й квартал 2025 года мы ведем учет по новой функциональной модели, и где-то в середине апреля вдруг понимаем, что модель надо менять. А прошел уже целый квартал.
Я как только представила, на какие суммы мы должны будем согласиться, чтобы выкарабкаться из этой ситуации с учетом объема наших оборотов, чтобы не убить бизнес при том, что значительная часть бюджета проекта и времени уже потрачены.
Осознание масштаба проблемы — необходимости дополнительных инвестиций для спасения проекта без ущерба для операционной деятельности — стало ключевым моментом. Решение было жестким, но необходимым: выход из договора с нашим первым интегратором.
Главный риск, на который я категорически не была согласна, это потеря контроля над содержанием проекта. Для меня как руководителя проекта, ответственного перед собственником, это неприемлемая ситуация.
Этот опыт стал для меня одним из самых сложных в карьере, но и одним из самых полезных — он сформировал новый стандарт управления внедренческими проектами в нашей компании.
Опыт предыдущего проекта позволил сформулировать четкие требования к новому интегратору, чтобы избежать повторения ошибок.
1. Новый интегратор должен изучить бизнес-процессы заказчика до начала работ.
2. В рабочие группы от заказчика должны войти владельцы бизнес-процессов.
3. Команду интегратора представляет один руководитель, отвечающий за работу будущей системы в целом.
4. Важно прособеседовать всех ключевых специалистов команды интегратора, при необходимости произвести осознанные замены до начала работ по проекту.
5. Должен быть инструмент контроля для руководителя проекта со стороны заказчика, в котором я могла бы видеть содержание проекта на кончиках пальцев и чётко видеть отклонения, понимать полноту покрытия требований решениями, чтобы я могла оценивать, зная мнение моей рабочей группы.
На новом конкурсе у нас было несколько компаний, которые подошли по большинству критериев. Но победила именно та, которая смогла предоставить нам удобный инструмент управления проектами.
В целом эта система помогает сохранить всю ценность информации. В итоге мы получаем функциональную модель, которую мы не только активно формируем, но и контролируем ее полноту и внедрение. Решение работает на «1С:Документооборот 3 КОРП».
Мы в нем фиксируем все требования, которые возникают на любой стадии проекта – начальные требования технического задания, уточненные требования по итогам обследования, требования по результатам функционального моделирования, требования по итогам испытаний системы, требования по итогам обучения пользователей, требования, возникающие в процессе ввода в эксплуатацию.
Также для меня важно отслеживать проектные решения.
В системе управления проектом фиксируются все проектные решения – НСИ, настройки системы, фиксируются бизнес-процессы и хозяйственные операции с привязкой к действиям в системе, решения по интеграциям и загрузке исходных данных (справочники и остатки), и по всем решениям регистрируются функциональные разрывы, т.е. требования по доработкам.
Все проектные решения ссылаются на требования, которые они закрывают.
1. Мы видим, какие проектные решения рассматриваются в проекте.
2. Благодаря механизмам 1С:Документооборот решения проходят ознакомления и согласования с отслеживанием исполнительской дисциплины.
3. Мы легко отслеживаем, какие требования покрыты проектными решениями, а какие нет.
Проект еще в работе, мы успешно завершили этап функционального моделирования и уже приступили к разработке, сейчас у нас все идет по плану. Главное — мы вовремя скорректировали управление проектом и теперь надеемся попасть в 10% успешных практик внедрения «1С:ERP».
Мне показалось важным поделиться полученными знаниями и опытом, чтобы вы не наступили на те грабли, на которые наступила я. Совет коллегам: не повторяйте наших ошибок — проверяйте интеграторов тщательнее и настаивайте на прозрачности!
