Автоматизация ≠ установка программы: почему проекты 1С проваливаются еще до старта

За 20 лет работы с автоматизацией я видел разные проекты: успешные, тяжёлые, спасённые в последний момент и провалившиеся. И вот что интересно: почти ни один провал не был связан с тем, что программа «плохая» или программисты «не справились». Судьба большинства неудачных проектов была решена ещё до того, как кто-то открыл конфигуратор.

Типичная картина. Компания выросла. Продажи в одной базе, склад в другой, производство в Excel, финансы «у Марины в файлике». Руководитель смотрит на этот зоопарк и принимает решение: внедряем единую систему, наводим порядок.

Логика понятная. Но в ней спрятана подмена: порядок ожидается от программы, а не от компании.

Программа — это контролер правил. Очень быстрый, очень дисциплинированный, но контролер. Если правил нет — то контролировать нечего. Если правила есть, но всем плевать на их соблюдение, то толку тоже не будет. Вместо старого бардака будет новый хаос: с электронным документооборотом и красивыми отчётами, которым нельзя верить.

Система не создаёт сама:

• правильные данные — если справочник номенклатуры ведут пять человек по своим понятиям, в новой системе будет пять «Канцелярий» и три «Канцтовара»;

• роли и ответственность — если сегодня непонятно, кто отвечает за резерв товара под заказ, то после внедрения это будет непонятно уже в двух системах;

• дисциплину — если кладовщик оформляет перемещения «потом, в конце недели», остатки в системе будут врать ровно так же, как врали в Excel.

Автоматизация — это изменение того, как компания работает. Установка программы — только часть этого изменения, и не самая сложная.

Спросите у трёх руководителей одной компании, зачем они внедряют ERP, — часто получите три разных ответа. Директор хочет видеть прибыль по направлениям, коммерческий — чтобы отгрузки не тормозили, главбух — чтобы «не переносить всё руками».

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

Ну и конечно, цель “Надо внедрять ERP, потому что поддержка УПП скоро закончится” - плохая цель.

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

• половина заказов оформляется задним числом;

• резервы «по договорённости» снимаются звонком на склад;

• у двух менеджеров свои правила скидок, о которых не знает руководитель отдела;

• а самый ходовой товар вообще отгружается до оформления документов, «потому что клиент   ждать не будет».

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

Правильный ответ: до автоматизации нужно честно зафиксировать, как процесс идёт на самом деле (AS IS), решить, как он должен идти (TO BE), и — важно — провести организационные изменения. Не «система заставит работать по-новому», а компания решает работать по-новому, и система это поддерживает.

При это крайне важно оценить возможности компании по проведению изменений. Обычно хотят “все и сразу”, максимально детально и т.п. У меня есть любимый пример из практики: на этапе подготовке к внедрению ERP мы написали кучу требований, пожеланий заказчика по изменению работы. А когда это все свели в один документ и начали финальное обсуждение, генеральный директор понял, что они не осилят такой объем организационных изменений. В итоге, от требований осталась примерно треть, практически укладывающаяся в типовой функционал. В итоге, проект стал значительно дешевле и быстрее, заказчик получил самый необходимый функционал быстро. А остальные задачи реализовались уже постепенно в рамках поддержки.

Справедливости ради: сейчас почти все интеграторы предлагают описание процессов «как есть» и «как будет». Это стало стандартным пунктом КП, красивым слайдом в презентации. Проблема в другом — в том, что скрывается за словами «как будет».

Откройте типичную схему TO BE и сравните с AS IS. Очень часто разница сводится к одному: везде, где было написано «УПП», теперь написано «ERP». Тот же процесс, те же роли, те же костыли и обходы — просто в новой программе. Это не проектирование целевого процесса. Это замена вывески.

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

Интегратору проще этого не касаться: нарисовать TO BE = AS IS + новая система, подписать у заказчика и идти настраивать. Заказчику тоже проще — не надо ссориться с коммерческим директором из-за регламента скидок. Все довольны, этап «моделирование» закрыт. А потом выясняется, что компания за большие деньги получила свои старые проблемы в новом интерфейсе.

Поэтому мой совет: когда вам показывают схемы TO BE, задайте один вопрос — «что именно в работе компании изменится, кроме программы?» Если внятного ответа нет, этап моделирования вы, скорее всего, оплатили зря.

НСИ — самая скучная тема в любом проекте и самая частая причина, по которой красивая система выдаёт мусор. Дубли контрагентов, номенклатура без характеристик, спецификации «примерно», остатки, которые «мы потом сверим».

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

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

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

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

Работающий склад через три месяца ценнее, чем «всё сразу» через два года. Об этом я подробно писал в статье про плавный переход с УПП на ERP — тот же принцип работает для любого внедрения.

Короткий чек-лист. Отвечайте честно:

1.     Могут ли три ключевых руководителя одинаково сформулировать цель проекта и критерий успеха?

2.     Описан ли реальный процесс (с исключениями и обходами), а не регламент из папки?

3.     Отличается ли ваша схема TO BE от AS IS чем-то, кроме названия системы?

4.     Кто персонально отвечает за качество НСИ?

5.     Есть ли со стороны бизнеса человек с полномочиями принимать решения по спорным вопросам — и, что крайне важно, временем на проект?

6.     Определён ли первый этап, который даст работающий результат за обозримый срок?

7.     Готова ли компания менять свои процессы, а не только «настроить программу под нас»?

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

Хороший подрядчик иногда должен сказать клиенту: «Пока автоматизировать не надо. Сначала разберитесь вот с этим». Я понимаю, что от интегратора странно такое слышать — мы же вроде должны продавать внедрения. Но проект, который стартует на неготовой почве, не нужен никому: клиент теряет деньги и веру в автоматизацию, подрядчик — репутацию.

Программа — это усилитель. Она усиливает то, что есть: порядок — в порядок, хаос — в хаос. Поэтому прежде чем спрашивать «какую систему выбрать», стоит спросить «что именно мы хотим усилить».

А вы сталкивались с проектами, которые провалились ещё до старта? По каким признакам вы поняли бы это заранее?

Реклама: ИП Шарипов Руслан Рафикович, ИНН 780226784621, erid: 2W5zFJVhSJ5