Можно ли самим внедрить ЕРП?

О компании и площадке внедрения

Цель того, о чем я буду рассказывать, – познакомить вас с нашей историей и сформулировать выводы, которые мы сделали для себя, чтобы вы могли поучиться на наших ошибках и не совершать своих.

Я работаю в финансово-промышленной компании «Инвест». Это крупный рязанский холдинг, в который входят несколько групп компаний.

Группа компаний «Русская Кожа» производит кожевенное сырье. У нас находится самый крупный в Европе завод полного цикла, плюс есть еще предприятия по стране.

Группа компаний «Теплоприбор» делает приборы, в основном для атомной промышленности, поэтому подробно на них останавливаться не будем.

Группа компаний «Барс» – это наш B2C-сектор: супермаркеты, продуктовая и книжная розница, сеть ресторанов быстрого питания, рестораны a la carte, аренда и так далее.

И группа компаний «Точинвест» – это, можно сказать, флагман нашего холдинга на текущий момент. Основное направление – металлообработка и цинкование, в частности производство дорожно-мостовых ограждений.

Я поставил ее в конце не случайно, потому что речь сегодня пойдет именно о ней. ERP мы внедряли на предприятии «Точинвест».

Исходная ситуация, цели и стартовые ресурсы

Теперь немного про предприятие. Понятно, что мы внедряли не с нуля – мы не пришли такие: «Вау, ничего нет, пустое поле, сейчас поставим ERP». Конечно, все было не так. На предприятии уже был учет в УПП, причем УПП переписано вдоль и поперек. Думаю, это типовая история: почти у всех УПП доработано, типовых решений уже давно ни у кого нет. По крайней мере, я не видел.

Итак, на предприятии – сильно доработанное УПП, куча своих процессов, наработок и изменений. Руководство ставит задачу: догнать и перегнать, а если формально – перейти на ERP. Цели перехода были такие:

• Снижение зависимости,

• Получение обновляемого решения,

• И, как вишенка на торте, – планирование производства.

Снижение зависимости – это про зависимость от разработчиков. Все доработки кем-то сделаны, при этом почти не документированы, и из-за этого возникает сильная зависимость.

Обновляемое решение – здесь все понятно: регламентированный учет никуда не денется, его нужно вести, систему нужно обновлять. Ну и планирование производства – его просто хотелось получить.

Теперь про старт. Из плюсов – высокая заряженность ИТ-команды. Ребята реально были настроены на результат: «в бой» – и побежали.

Минусов больше:

• Нет опыта именно таких переходов. Не про 1С в целом, а именно про миграции и внедрения такого уровня.

• Нет знания методологии учета в ERP: как в ней правильно работать, почти никто не понимал, только какие-то зачаточные представления.

• И еще один важный момент – нет опыта адекватной оценки трудозатрат. Мы не могли четко сказать, сколько времени займет та или иная задача или этап перехода.

Но на самом деле все эти минусы во многом нивелировались тем самым плюсом – заряженной командой. Если бы этого не было, можно было бы сразу все закрывать и расходиться.

Требования бизнеса и первоначальная методология работы

Как мы начали движение. У бизнеса было два ключевых требования, которые они хотели сохранить:

1. Максимальное использование наработок из УПП. Мы уже многое сделали и не хотели это терять.

2. Максимальная похожесть форм, чтобы при переходе пользователи практически не заметили разницы, и дисбаланс между системами был минимальным.

Мы пошли по классической методологии – Waterfall. Брали процесс, описывали его, рисовали блок-схемы, согласовывали с владельцем процесса, фиксировали и только после этого переходили к доработке. Таким образом мы описали все процессы в альбоме процессов и начали их реализовывать.

Идея реализации была простой. Чтобы обеспечить максимальное сохранение привычного поведения системы, мы сделали так: брали ERP, рисовали в ней формы, но всю «математику» оставляли в УПП. Данные при этом гоняли туда-сюда через обмены – сделали обмен на конвертации данных. Пользователь работает в ERP, видит формы ERP, но расчеты происходят в УПП. И так – до определенного момента.

То есть мы переводим, например, один отдел: данные синхронизируются, внешне все выглядит стабильно, расчеты остаются прежними, себестоимость сходится – все работает.

Ход первого этапа внедрения

Что здесь могло пойти не так? На первый взгляд – все хорошо, система работает. Но важно понимать: этот процесс не был быстрым, он сильно растянулся во времени.

За первый год мы запустили НСИ, конструкторский отдел полностью перевели в ERP. ERP стала мастер-системой по всей номенклатуре, маршрутным картам, спецификациям и прочему. Дальше начали постепенно подключать заказы на производство, отражение выпуска. Появилась необходимость в календарном плане, чтобы корректно выверять маршрутные карты.

Также на этом этапе мы сделали контрольный пример – сквозной сценарий между двумя базами, УПП и ERP, чтобы убедиться, что все сходится.

На все это у нас ушло примерно два с лишним года. Это долго, но к этому моменту у нас уже почти все было готово для полноценного перехода.

Накопление проблем: релизы, ветки ERP и рост команды

И вот здесь мы столкнулись с проблемами. Казалось бы, проблема появилась буквально из ниоткуда: вендор выпустил новые релизы. Неожиданно. Но до этого мы долго работали на УПП, и в нашей идеологии было нормально, что внутри системы не происходит резких изменений. Если что-то меняется – то это, как правило, наши собственные доработки.

А здесь ситуация другая: вендор активно развивает продукт, наращивает функционал. И самое интересное оказалось в том, что мы с вендором шли в одном направлении. Мы реализовали у себя какие-то доработки – и вендор сделал примерно то же самое в типовом решении. Встал вопрос: что использовать – свое или типовое? Логично, что типовое, потому что оно будет развиваться и обновляться. Но как быть с уже сделанным – непонятно.

Следующая проблема – это две «ветки» 1С:ERP. Мы начинали доработку на версии 2.4, а к моменту перехода появилась версия 2.5. В ней, насколько помню, переработали производственный модуль. Все наши наработки были сделаны под старую ветку, которая фактически становилась устаревающей. Понятно, что вендор будет развивать новую ветку, а старая отомрет.

И все бы ничего, можно было бы переписать. Но проблема в том, что новая ветка только появилась и не была оттестирована. Мы находили в ней ошибки, и было очевидно, что вендор тоже будет их активно исправлять. В итоге ситуация: переходить нужно, но непонятно, когда именно это делать.

И здесь появляется следующий вопрос: когда переходить на новый релиз? Напомню, до внедрения оставалось примерно полгода. Переходить сейчас или сначала запуститься на старом, а потом перейти? Вопрос «переходить или нет» не стоял – переходить все равно придется. Вопрос был именно во времени.

Если не перейти – есть риск не сдать отчетность. Если перейти – что делать с доработками? Это отдельная большая тема, к которой мы еще вернемся.

На новом релизе у нас перестали работать обмены на конвертации данных. Чуть позже объясню подробнее, но по сути – пришлось переписывать правила. А это трудоемкость, это ресурсы, которых и так не хватало.

Мы попробовали использовать стандартные обмены ERP и УПП. В целом они работают, но за ними нужно постоянно следить. Они часто «встают», их приходится вручную проталкивать. А значит, снова нужны ресурсы.

И еще одна большая проблема: за эти два с половиной года команда выросла. Если на старте был один руководитель проекта и команда исполнителей, то к этому моменту появилось три-четыре полноценных руководителя. У каждого – свое видение, свое понимание, как нужно двигаться, и аргументы, почему именно его подход правильный.

В итоге классическая история про «лебедя, рака и щуку». Принцип единоначалия формально есть, но не все с этим готовы были мириться. Часть команды в итоге ушла.

С этим набором проблем мы подошли к старту внедрения.

Кризис конвертации данных и решение двигаться дальше

Отдельно про конвертацию данных, потому что здесь возможно недопонимание.

Проблема в том, что перестали работать правила, которые мы написали. Они были завязаны на старые метаданные, а в новой версии метаданные сильно изменились – причем изменения были кардинальными. В итоге переписывание правил – это не «чуть-чуть поправить», а фактически написать все заново. Это большая трудоемкость.

А если вспомнить, что вся наша методология была завязана на обменах и конвертации данных – мы постоянно гоняли данные туда-сюда – становится понятно, насколько это критично.

И вот в этот момент впервые встал вопрос: останавливаем внедрение ERP и расходимся или идем дальше? Мы решили идти вперед. Маховик уже раскручен, команда работает.

Мы приняли решение переходить на новый релиз. Все равно рано или поздно это делать, а пока в системе еще никто полноценно не работает, есть шанс за оставшиеся полгода максимально подготовиться.

Начали тестировать, настраивать выгрузку начальных остатков для нового релиза – для старого это уже было настроено, для нового пришлось делать заново. Параллельно проводили обучение сотрудников, которых еще не успели обучить.

Здесь важный момент: тестирование мы продолжали проводить на старом релизе, на тех наработках, которые уже были. Первый и третий процессы шли параллельно – сделать все последовательно мы не успевали.

Ну и по мелочи: где-то менялись печатные формы, их тоже пришлось дорабатывать.

Январский запуск: сбой процессов и вынужденный двойной учет

Настало первое января. Есть старая шутка, что вся самая неприятная история у нас всегда происходит именно первого числа – никогда не семнадцатого и не двадцать восьмого. У нас получилось так же: переход на ERP совпал с началом года.

В этот момент у нас практически перестало работать все. Если представить шкалу, где крайняя точка – это остановка производства, то мы были максимально близко к ней. Для понимания: в день должно отгружаться 30–100 машин, а у нас одна отгрузка занимала три–четыре часа. И это с участием всех доступных ресурсов: айтишников, бухгалтерии, склада, сбыта, ПДО – и чуть ли не уборщица помогала. Это не шутка, так и было.

Если убрать эмоции, то все проблемы сводились к трем основным причинам:

1. Ошибки, возникшие при переносе функционала между релизами. Мы торопились, за полгода много сделали, но что-то не успели нормально протестировать – отсюда ошибки.

2. Плохое тестирование. Не в смысле, что плохо проверили код, а в том, что владельцы процессов не до конца включились. Многие привыкли, что айтишники что-то делают, а если что – потом быстро поправят. Но в этот момент «быстро поправить» уже не получалось: слишком много всего навалилось одновременно.

3. Не учтенный функционал на этапе описания и согласования процессов/измененные процессы с того времени. Три года – это большой срок, за это время многое поменялось, а за изменениями никто системно не следил.

В итоге руководство посмотрело на ситуацию и приняло решение: к полноценной работе в ERP мы пока не готовы. Значит, вводим двойной учет – данные вводим и в ERP, и в УПП.

Почему это произошло? Потому что не весь функционал был перенесен: часть осталась в УПП из-за ошибок и недоработок. Соответственно, какие-то операции можно было выполнять только там. Плюс возникло недоверие к системе: если в ней нельзя полноценно работать, ей нельзя доверять.

Период двойной работы, Agile-подход и финальное преодоление

В таком режиме мы работали примерно до апреля. Постепенно ситуация с отгрузками начала выравниваться: сначала по четыре часа на машину, потом процессы стали более стабильными.

В этот период мы поменяли подход к работе. Ушли от Waterfall и перешли на короткие итерации – по сути, на Agile. У нас появились короткие спринты: мы собирались два–три раза в неделю, обсуждали, что работает, что не работает, что сделано и что нужно сделать в ближайшие два–три дня. Критичные ошибки исправляли сразу, «наживую».

Так мы жили около четырех месяцев. Четыре месяца постоянных переработок – не только у ИТ, но и у всех сотрудников, потому что двойной ввод никто не отменял. Естественно, накопилась усталость.

И в какой-то момент встал вопрос: а нужна ли нам вообще эта ERP? Зимой еще можно было потерпеть, но приближалось лето, май, дачи, огороды – и мотивация у людей начинала падать.

При этом основная проблема была уже не в отгрузках – они более-менее стабилизировались. Главные проблемы были две:

1. Отсутствие сходимости финансового результата с УПП. Мы видим «финрез» в УПП, а в ERP за тот же период получаем совершенно другой результат – они расходятся принципиально.

2. Несмотря на все усилия и короткие спринты, не весь функционал был перенесен в ERP.

В мае мы собрались всей командой, сели за стол и прямо задали вопрос: «Все? Закрываем проект и расходимся?» Почти все были готовы согласиться. Но потом подумали: если сейчас остановиться, то через год придется проходить через то же самое. Мы все равно не сможем бесконечно сидеть на УПП – меняется законодательство, да и бизнес уже готов к ERP.

В итоге за май, невероятными усилиями, нам удалось добиться сходимости финансового результата за январь. К июню у нас уже было три месяца сходимости – январь, февраль, март. И к июню мы перенесли в ERP практически весь функционал – не на 100%, но примерно на 99,5%.

С 1 июля у нас осталась одна система – ERP. УПП перевели в режим только чтения.

Итого: шесть месяцев люди делали двойную работу. Да, какие-то простые вещи мы автоматизировали – например, документы поступления и реализации. Но производственные документы автоматизированно переносить невозможно, там в любом случае требуется ручной ввод и учет.

Итоги, ошибки проекта и роль команды

Вот такая у нас получилась история. Но история сама по себе не так важна – важны выводы. Давайте разберем наши ошибки.

Ошибка номер один – максимальная заточенность под пользователей. Мы старались максимально перенести весь накопленный функционал из УПП. На самом деле половину этого можно было решить иначе: использовать типовой функционал ERP и немного изменить процессы. Здесь важно уметь отделять действительно уникальные процессы, которые нельзя менять и нужно переносить, от тех, которые просто «так привычно» и «так удобно». Это принципиально важный момент.

Следующая ошибка – изменение процессов за время проекта. С момента их описания и до старта прошло достаточно много времени, и сами процессы внутри компании успели поменяться. В итоге нам приходилось не просто внедрять ERP, а догонять уже изменившуюся реальность.

Следующая ошибка – мы не учли, что вендор может серьезно изменить систему. Я, конечно, утрирую, но изменения оказались существенными, и мы к этому не были готовы.

Самая фатальная ошибка, на мой взгляд, – это шесть месяцев двойного учета. Такой режим – это очень тяжело, и по возможности к нему лучше не приходить.

Еще одна важная проблема – разлаженность действий подразделений до этапа внедрения, точнее отсутствие единой рабочей группы. До перехода каждое подразделение смотрело только на свой участок: «у меня работает – значит все хорошо». Не было общего взгляда на сквозной процесс. И только в январе, когда начались реальные проблемы и появилась угроза остановки производства, люди начали помогать друг другу и смотреть шире. В этот момент границы ответственности расширились, и работа действительно пошла быстрее.

Если говорить о главном выводе – что не нужно делать никогда. Двойной ввод – это зло. К такому сценарию лучше не приходить.

И самый важный вывод: все держится на людях. Айтишники, бухгалтеры, сотрудники склада, менеджеры – все, кто участвует в цепочке, именно благодаря им этот проект удалось довести до результата. Без команды ничего бы не получилось.

Пользуясь случаем, хочу передать привет всем, кто участвовал в этом процессе. Ребята, спасибо вам большое. Всегда приятно рассказывать про то, что получилось, а не про то, что провалилось.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.