Расскажу историю проекта внедрения ERP на одном «маленьком» заводе, который мы построили в славном городе Тутаев Ярославской области. Расскажу, как развивалась эта трагикомедия.
Меня зовут Корчемкин Михаил Анатольевич, я – руководитель службы взаимодействия с бизнесом. В IT я уже 15 лет.
Наша группа компаний «Айсберри» занимается производством мороженого и дистрибуцией различных замороженных товаров.
У нас есть три завода по всей России.
-
Самый первый завод компании – это «Вологодское мороженое» в городе Вологда.
-
Завод в Пензе называется «Ледяной дом» – он в составе компании уже пять лет.
-
В 2021 году мы построили самый большой в России завод по производству мороженого в городе Тутаев Ярославской области, в особой экономической зоне.
Мы внедряли ERP…
Какие были предпосылки к внедрению 1С:ERP на данном предприятии?
Организация ведет свою историю с 1937 года. За это время система учета претерпела несколько преобразований.
Более десяти лет назад в организации был внедрен MS Navision 5-й версии, в результате чего существующая система развивалась на принципе монолитности.
Но так как тренды в разработке программного обеспечения ERP-систем (и вообще во всех системах) меняются, нашим ИТ-департаментом была принята позиция развития микросервисной структуры.
Исторически сложилось, что Navision имел очень большую кастомизацию почти по всему, что касалось финучета, производства и очень сложных схем продаж. Это усложнялось тем, что организация имеет 40 филиалов, и зачастую доставка и продажа от имени одного юрлица осуществлялась через длинную логистическую цепочку.
Но так как наш завод находится в особой экономической зоне, основным требованием государства было – использовать отечественную ERP-систему.
-
Для перехода мы составили огромный документ ФТ (функциональные требования).
-
На его основании создали ТЗ (техзадание на доработки)
-
Доработки разделили на четыре очереди
-
И решили, что проект будет вестись по Agile, потому что параллельно тоже по Agile строился завод.
Мы уверенно смотрели в будущее и видели свет в конце тоннеля. Проводили обучение по системе, показывали ее презентации. Но так как самого завода и рабочих мест еще не было, мы демонстрировали, по сути, систему в вакууме. И в ответ на закономерный вопрос: «Всех ли все устраивает?» – все отвечали: «Все супер, все замечательно!»
Наконец, завод был запущен, и мы начали использовать все, что у нас было создано, запрограммировано, сведено. Но вдруг выяснилось, что оно не работает.
Оказалось, что данные в систему вводить некому, потому что было видение, что необходимо экономить на бюджете, на ФОТ, на людях. Завод же передовой! Зачем нам операторы? Соответственно, функция операторов начинает перекладываться на кого? Правильно, на авторов системы.
Плюс ко всему часть функциональности перешла с двух других исторических заводов, а там Navision, царство Excel, и начинаются какие-то манипуляции. Только удалось что-то запустить, а нам заказчики говорят: «Наверное, мы не будем это использовать».
Наш результат был не тем, чего мы бы хотели.
-
Мы получили «вечный Agile» или, как я его люблю называть, колесо Сансары – когда одни доработки порождают вторые доработки, вторые доработки порождают третьи доработки.
-
Чтобы протестировать первые доработки, нужно зафиксировать релиз, но мы не можем это сделать, потому что у нас есть связанные доработки. И получается такой вечный и не останавливаемый Agile.
-
На шестой попытке обновиться от нашего подрядчика мы все-таки решили собрать в костяк все необходимые для функциональности доработки, чтобы получить стабильный релиз.
Ситуация становилась неуправляемой:
-
Мы осознали, что приближаемся к точке невозврата. Во внедрении любой управленческой системы есть точка невозврата – это точка, когда мы понимаем, что мы системой уже не управляем, а система начинает управлять нами.
-
Возникали слишком большие разрывы из разряда «так исторически сложилось», вплоть до того, что планы производства и потребности считаются в Excel.
-
И наблюдалось полнейшее отрицание принципов бережливого производства и партионного учета. При том, что партионный учет для нас принципиально важен, так как мы – пищевое предприятие, и должны отчитываться о каждой партии. Мало того, что мы используем ВетИС (систему «Меркурий»), так как наша продукция из сырья животного происхождения, на нас еще в довесок с 1-го июня обрушился «Честный знак».
Суровый русский FMCG и основные ошибки ИТ при его автоматизации
FMCG (Fast moving consumer goods) – аббревиатура, используемая для описания рынка быстро оборачиваемых товаров или товаров с высокой частотой покупки.
Реалии FMCG-бизнеса в России таковы, что у бизнеса есть три основные цели:
-
Заработать как можно больше.
-
Потратить как можно меньше.
-
Приложить как можно меньше усилий.
Основные же цели ИТ-подразделений – это:
-
Сделать мир лучше.
-
Автоматизировать по максимуму все, что можно. Исключить ручной ввод и дополнительные расчёты, в которых участвуют люди, потому что самое страшное в ИТ-системах – это человеческий фактор. Как только от человека требуется принять какое-то решение, система в опасности. А до этого момента все работает, даже хорошо работает.
-
Царство цифр и аналитики – это отсылка к всяческим BI-вещам, потому что зачастую аналитика, даже по мнению ИТ, помогает принимать решения, как именно бизнес должен существовать дальше.
И на стыке этих трех постулатов с каждой стороны у нас получается, что основные ошибки ИТ в FMCG это:
-
Постановка целей автоматизации выше целей бизнеса. На что зачастую мы получаем: «Ребята, мы здесь собрались не для того, чтобы внедрять систему, а для того, чтобы деньги зарабатывать». Системы не должны отвлекать людей от целей бизнеса. Логистика должна доставлять, продажи должны продавать, бухгалтерия должна вести учет, а не вовлекаться с головой в проекты по внедрению систем.
-
Применение гибких подходов в моментах, требующих более жесткого регулирования. Я считаю, что бизнес должен учитывать методологические ограничения ИТ. Иначе попытка адаптировать систему под бессмысленные требования пользователей может поставить ситуацию в тупик. Административный ресурс нужно побеждать экспертизой, усиленной количеством экспертов.
-
Далекость от «земли». Мы во всех наших планах и системах бываем далеки от земли.
-
Идеализм. Нельзя упускать, что в нашем мире нет ничего идеального. Все мы люди, у всех есть нелюбимый мною «человеческий фактор».
-
Отсутствие принципов 3-х «Зачем?» Об этом расскажу немного дальше.
M.U.D.A.C.
И вот зачастую в ИТ-подразделениях организаций появляется M.U.D.A.C. Хотя это аббревиатура, составленная из пяти английских слов, но это, опять-таки, моя точка зрения.
Давайте разберем по тезисам.
M – methodological.
Человек мастерски подкован во всяческих методологиях, отличает Agile от Waterfall и не только.
Но у него есть темная сторона: он считает, что он лучше знает, что нужно бизнесу. Он не слушает бизнес.
У него огромный опыт с других мест работы, когда принимаемые им решения 100% подходили бизнесу.
Но он никогда не задает себе первый вопрос «зачем»: зачем он находится в данный момент в данной организации?
Это – первое «зачем» из трех, которые нужно себе задать при автоматизации.
U – unstoppable.
Человек дикой энергичности, зачастую подстегивает команду на необдуманные действия.
Думаю, что все сталкивались с нашей любимой российской фразой: «Сначала втянемся, а там уже посмотрим».
Но здесь важно задать себе второй вопрос «зачем»: зачем это все необходимо данной команде в данный момент?
Все действия должны быть обдуманы, чтобы не расходовать впустую человеческий ресурс, результат деятельности живых людей
D – destructive.
Зачастую его решения оказываются разрушительными. Усиленная кастомизация приводит к тому, что разработка оказывается построенной на костылях. И эти костыли впоследствии не систематизируются. А когда система уходит в эксплуатацию, все эти костыли начинают сыпаться уже на поддержку и просто разрушают систему.
A – alone.
Часто у таких людей возникает комплекс «непризнанного гения». А непризнанные гении, как мы знаем из истории, всегда одиноки.
Человек начинает отрываться от команды.
Как следствие, у человека начинает возникать завал с количеством задач, которые он на себя берет. Он же единственный непризнанный гений.
И он не задает себе третий вопрос «зачем?»: зачем все сваливать на себя, когда можно все поделить и делегировать?
Ну и последняя составляющая нашего супергероя: C – critic.
Человек критикует все, что выходит за рамки его понимания, за рамки его установившейся картины мира.
Зачастую человек в данной критике переходит на личности, что начинает разваливать любую команду изнутри. Это очень губительно сказывается как в проектах, так и в любой операционной деятельности.
Но выход есть…
Но выход есть, и мы можем победить в борьбе с такими людьми. Я считаю, что для этого нужно:
-
Отказаться от чистых Agile-проектов. Agile сам по себе подразумевает создание MVP. Но зачастую эту границу MVP очень сложно определить, потому что понимание ИТ о функциональности MVP – это одно, а понимание бизнеса об этом MVP – это другое. Я считаю что нужно «на берегу» договориться об основной функциональности системы с бизнесом и реализовывать договоренности по Waterfall.
-
Ввести службу взаимодействия с бизнесом. В большой организации, в большом ИТ-подразделении необходима служба взаимодействия с бизнесом. Это люди, которые помимо своей ИТ-части еще понимают, как функционирует бизнес изнутри. Я считаю, в среднем и крупном FMCG это должно быть.
-
Ввести институт ИТ-Бизнес партнеров. Этот институт включает в себя службу взаимодействия с бизнесом. Про институт ИТ-Бизнес партнеров в своем докладе рассказывал Сергей Чирухин.
-
И самое главное: общаться с бизнесом по любому поводу и по любым моментам. Если мы с бизнесом не общаемся и не понимаем, чем живет наш бизнес и как он функционирует, мы начинаем быть слишком далеки от «земли».
Эпилог
Ну и небольшой эпилог.
Данные методы не являются универсальным инструментом по решению возникающих проблем. Но в этом и есть смысл нашей жизни – каждая ситуация уникальна.
В жизни всегда есть смысл. Совершенствуйтесь! Просвещайтесь! Общайтесь в профильных сообществах! Нельзя останавливаться в своем развитии.
Вопросы
Какие функции реализует эта служба взаимодействия с бизнесом?
Есть службы, которые являются ресурсным пулом в организации: служба разработки, служба поддержки и так далее.
А служба взаимодействия с бизнесом призвана уменьшать расстояние между айтишниками и бизнесом. Туда должны входить бизнес-аналитики, РП-шники, ИТ-Бизнес партнеры – сотрудники, с которыми взаимодействует бизнес на протяжении жизненного цикла продукта.
Системные аналитики туда входят?
В моем понимании системные аналитики входят в ресурсный пул. А бизнес-аналитики обращены именно к бизнесу.
В чьем подчинении работает ИТ-Бизнес партнер?
Если ИТ-Бизнес партнер по направлению, он должен находиться в ИТ. Если он на стыке общего ИТ и бизнеса, он должен подчиняться ТОП-руководителю компании, генеральному директору либо акционерам.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event.
