Модульные ERP. О чем вы узнаете после провала внедрения

Модульные ERP. О чем вы узнаете после провала внедрения

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

Диапазон перспектив доверчивого заказчика — от просто провального внедрения до многолетних мучений с гирей на ногах.

"Любая сложная задача
имеет простое, легкое для понимания
неверное решение"

Законы Мерфи

I. Немного истории Или откуда есть пошли ERP.

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

Аналогичный подход к проектированию автомобиля использовался на заре его истории:

  • брался конный экипаж;
  • лошадиный движитель заменялся бензиновым (а поначалу еще чаще паровым или электрическим);
  • вуаля, автомобиль готов.

С течением времени подход автомобильных дизайнеров (в буквальном смысле английского design) несколько изменился.

Однако не таковы КИС. Создатели оных, согласно известной поговорке, работа не волк, в лес не убежит от добра не ищут и сермяжно-антикварно продолжают менять лошадь на паровой котел.

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

Полезность итоговой складской программы ограничивалась знанием того, сколько чего лежит на складе (в штуках, граммах, метрах — и прочих естественных для данного товара единицах измерения).

Так и жили по отдельности бухгалтерские и складские программы — и общего между ними было столько же, сколько у огурца с пальцем.

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

Как связать палец с огурцом?

Решение очевидно: взять хорошую (лучшую) бухгалтерскую программу, хорошую (лучшую) складскую и наладить между ними "обмен данными" (она же "синхронизация" — о, как много в этом, как говорится, звуке).

Вспоминаем эпиграф.

Так и появились на свет "модульные" ERP: “модуль” склада (WMS) сопрягается с модулем “финансов” (ERP), sales-модуль “интегрируется” с CRM, и так далее.

Итоговое количество “модулей” ограничено только платежеспособностью компании и доверчивостью СЕО к продавцам чудо-панацей.


II. Кому от “модульных” систем жить хорошо. А кому — слезы горькие

Любая "модульная" система имеет не менее трех важнейших преимуществ:

  • легко “производить” и “расширять функционал”: знай себе прикладывай "модули". Происхождение “модулей” значения не имеет — доминирующие на рынке системы являют собой истинно цыганский базар всепланетного интернационала “модулей” — когда-то написанных, купленных отдельно, доставшихся бесплатно (как же ж не пристроить к делу) вместе с купленными компаниями etc. Единственное, что нужно для наречения произвольного софтверного хлама “модулем” системы — чтобы он хоть как-то “синхронизировался” с остальными. Как — не принципиально, хоть на веб-сервисах, хоть на XML-файлах. Не шутка.
  • удобно рекламировать. В смысле гипнотизировать низкоиммунных слушателей в стиле « — Ох, как у нас много модулей, смотри ж ты! Очень, мол, богатый функционал!”
  • и продавать. Мол, купите сначала WMS, а потом CRM и SCM, а когда совсем разбогатеете - HRM, BPM и PLM. А к тому моменту мракетологи еще чего нибудь трехбуквенное родят.

Однако — нет в мире совершенства.

Есть и у “модульных” систем маленький грешок: они практически неработоспособны.

Понятно, что это с точки зрения продавца этот недостаток мало существенен, но — с точки зрения эксплуатанта?

Посмотрите на свое предприятие со стороны. У вас наверняка в том либо ином виде есть отдел продаж («Sales модуль…), финики/бухгалтерия («Финансовый модуль»), склады («Складской модуль»). И много других "модулей", но для мысленной модели ограничимся перечисленными. А теперь представьте, как ваша компания будет работать, если из ее структуры вычесть (в целях "гибкости" и "управления бюджетом") "складской модуль".

А?

Правильно.

Еще более близкую аналогию с ERP-системой мы получим, если помыслим реорганизацию вашего бизнеса в духе доведения идеи аутсорсинга до идиотизма:

  • единая компания упраздняется;
  • бизнес-процессы каждого функционального подразделения передаются на "аутсорсинг" внешним подрядчикам. Складские услуги вам предоставляет одна фирма, колл-центр аутсорсит другая, продает товары третий внешний подрядчик и так далее;
  • общая “координация” и “синхронизация” ведется штаб-квартирой (“модуль” “главная книга”) путем регулярного сбора отчетов от подрядчиков и проведения регулярных конференций в тематике “работаем плохо, надо работать лучше”.

Представляете, как все это будет работать в реальности?

А если рыночные условия заставляют постоянно корректировать бизнес-процессы?

Во-во.

Именно так на практике и работают модульные ERP.

Подготовленный читатель воскликнет: «— Да что вы несете! А как же тысячи внедрений по всему миру?»

Именно так, дорогие читатели.
 

III. Как они работают на самом деле

“Модульные” системы подарили миру такую… как сказать… возможность что ли? короче — независимое “исполнение” или “проведение” по разным “модулям”.

На пальцах очень условно: есть продажная накладная.

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

Независимое “исполнение” по разным “модулям” (сорри за обилие кавычек) совершенно легально позволяет такие финты, как, к примеру, провести в «складском модуле» и — не провести в «финансовом».

По версии креаторов подобных систем это и называется, внимание, — “гибкость”!

Таким образом, товар со склада у вас легко может списываться (и на складе с отчетностью все хорошо, все документы есть), а в финансовом учете ничего не изменилось. Можно ли себе представить ситуацию, более благоприятную для воровства космических масштабов?

Можете ли вы, положа руку на сердце, представить ситуацию, действительно обусловленную требованиями бизнеса и интересами акционеров, при которой подобная “гибкость” может быть оправдана?

Или, вот, «работа над ошибками».

Представим себе сотрудника финансового отдела, который нашел, например, ошибку в проводках, источником которой является товарный "модуль" ERP-системы. Он пытается связаться с кем-то из логистики, логистам в этом копаться неинтересно (да и не их это проблемы), или нужный человек ушел в отпуск или еще что-то.

Каковы дальнейшие действия сотрудника-финика? Он ответственно напишет письмо с описанием проблемы и сделает корректировку ошибки в “своем” финансовом "модуле" (со счета такого-то на счет такой-то такая-то сумма).

Это первые несколько раз.

Затем, если проблема устранена не будет, сотрудник даже не будет письмо писать — сразу сделает корректировку — нужно срочно предоставлять отчетность, ждать некогда. Потом ИТ-отдел по требованию финансового отдела напишет алгоритм, делающий эти корректировки автоматически, тем самым сэкономив кучу времени финансистам.

Обратите внимание — корректировки проводятся только в финансовом "модуле" и отражаются только на его итогах, косяки в товарном "модуле" правятся/создаются логистами/кладовщиками совершенно независимо.

Представьте степень (не) соответствия данных в обоих "модулях" другу (только в двух, а сколько их еще в вашей ERP) и реальности на перспективе нескольких лет — с учетом того, что сотрудники всегда идут по пути наименьшего сопротивления.

Как бы вы охарактеризовали итоговую полезность для бизнеса такой, с позволения сказать, “системы”?

Да, она самая.

Причем — полнейшая.

Посмотрим с точки зрения кибернетики.

Процессный подход, о котором так много (и справедливо) говорится, когда деятельность предприятия рассматривается как совокупность цепочек создания стоимости.

Для IEM Системы процессный подход является естественным просто в силу ее природы.

Простейший пример - движение товаров через ритейлера от производителя до конечного потребителя.

Все пользователи системы работают в едином информационном поле. Закупщик создает прообраз приходной накладной, согласованной с поставщиком, и нажатием кнопки передает ее в область ответственности склада, который будет принимать эту накладную.

Груз приехал. Кладовщик, приняв товар, нажатием кнопки переводит эту накладную на склад хранения, приходуя товар. И так далее - вплоть до отгрузки товара покупателю.

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

ERP-система, с точки зрения эксплуатанта, является совокупностью ископаемых АРМов, функционал которых реализуется, в сущности, отдельными приложениями, зачастую разработанных разными компаниями в разные десятилетия.

Представьте, колл-центр у вас работает в отдельном "модуле" колл-центра, склад в своей WMS-софтине, взаиморасчеты с клиентами находятся в модуле "Продажи".

Все эти модули "интегрированы" между собою, в основном, пиарной лапшой продавцов суперсистемы под раскрученным зонтичным брендом.

Чтобы передать данные из "колл-центра" на "склад", нужно провести цепочку "синхронизаций" между прокладочными "модулями".

Конечно, на практике, это никто и не делает, поскольку тогда не то, что "процессный подход", а просто работа компании наглухо встанет.

Так что заявленный суперфункционал гиперсистемы остается скучать в пресейл-презентациях, а в реальности люди работают в екселе и/или на бумажках.

Данные же в гиперсистему вбиваются ручками задним числом.


IV. Обманчивая легкость внедрения

Частенько продавцы ERP позиционируют “модульность” как преимущество^ в смысле возможности поэтапного внедрения. Типа, сначала, внедряем в финансах, обкатываем, потом на складе, потом в продажах и так далее. Логично?

Вроде бы да. Но...

Опять возвращаемся к эпиграфу. И для того, чтобы это понять, не нужно быть профессионалом в области ERP.

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

Рассмотрим на примере “финансов” — именно с “финансов”, как правило, начинаются “поэтапные” внедрения “модульных” систем. И отнюдь не случайно — именно “финики”, как правило, являются наиболее падкими товарищами на навешивание лапши — по причинам, которые мы осветим ниже.

В любую сколь угодно совершенную систему данные надо вводить.

В случае правильной сквозной автоматизации предприятия данные вводятся конечными пользователями.

При этом ввод данных ограничивается, по сути, вбиванием накладных продавцами-закупщиками, кассовых операций кассирами etc — то есть данные попадают в систему естественным путем в результате фонового выполнения сотрудниками своих прямых обязанностей.

Либо же, в развитой бизнес-логике активно и долго эксплуатирующихся IEM-систем , накладные вбиваются в систему контрагентами предприятия через b2b/b2c площадки — что намного дешевле, а внутренние документы генерируются большей частью автоматом.

Что получается в случае “модульной” автоматизации отдельно взятого финансового блока?

Все данные нужно вносить минимум дважды: сначала продавец выписывает накладную в своей старой системе — по этим документам идут реальные сделки.

Потом, все эти документы надо переносить (вторично наколачивать) в тот самый “финансовый модуль”.

И кто это будет делать?

Всем и каждому, вовлеченному в этот обезьяний процесс безнадежная тупость этой работы будет предельно ясна. Качество вытекает.

В итоге получается два неизбежных следствия:

  • точность информации в “финансовом модуле” будет весьма далека от требуемой. Точнее, просто бессмыслица — осетрина не бывает второй свежести. Это сначала. Потом данные туда перестанут вбивать вообще, потому что и сами “финики” перестанут ими пользоваться — опять же, потому что ерунда. Реально будут использоваться те же старые инструменты, что были до громкого “внедрения”.
  • продолжение работ по внедрению последующих “модулей” системы встретит непреодолимый (и абсолютно оправданный в силу вышеописанных причин) саботаж.

Вы уже готовы спрогнозировать итог такого “поэтапного” внедрения?

Ага.

В зависимости от очковтирательских способностей вовлеченных сотрудников и степени склонности руководства к самообману, проект будет либо

  • официально приостановлен (как вариант — тихонечко забыт);
  • будет доложено об успешном внедрении, которое ограничится установкой на компьютеры сотрудников системы имярек.

Сразу ответим тем товарищам, которые будут возражать в том духе, что вот в описанной ситуации можно будет наладить автоматическую “выгрузку” документов в финансовый блок и никакой обезьянской работы не потребуется.

“Суха теория, мой друг”.

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

Напротив, ситуация еще хуже, поскольку если есть робот, то люди за работу и как бы и не отвечают. Значит и даже пытаться разбираться в получающейся ерунде никто не будет.

V. Монолитные IEM-системы: математическая достоверность данных

Что же предлагаем мы — взамен нерабочей модульной конструкции?

Монолит: нет Модулей кроме Единого Монолита и IEM - Воплощение его.

Монолитные управляющие системы предприятия

Поясним последний тезис простыми словами.

В IEM Системе основой учета являются регистры.

Дать простое, полное и притом понятное определение, что же такое «регистр», не получится, поэтому покажем на примере.

Возьмем склад вашей компании.

В IEM есть регистр «склад». На складе вашего предприятия есть складские остатки — столько-то штук такого-то товара. На регистре «Склад» числится это же количество штук этого же товара — которое видит кладовщик (точнее, любой, у кого есть права).

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

Для того, чтобы изменить состояние реального склада нужно или отгрузить, или получить товар (есть еще варианты как оприходовать/списать по инвентаризации, переоценить бой и так далее, но пренебрежем для простоты изложения) — и никак иначе.

В реальной жизни не может быть, чтобы товар на складе появился из воздуха — чудес не бывает. Стоимость товара на складе может сократиться отгрузкой, или увеличиться через получение товара — но абсолютно невозможно, чтобы себестоимость склада чудотворно изменилась без изменения его количественно-качественного состава. Переоценку для простоты в расчет не берем — хотя, опять же, она берется не из воздуха, а проводится документом, корректирующем сальдо на счете прибылей/убытков путем проведения документа, правящего себестоимость конкретного перечня товаров.

В точности так же, в IEM Системе в принципе невозможно отдельно списать со склада ИЛИ штуки, ИЛИ деньги. Состояние итога «Склад» может измениться исключительно в результате проведения документов, являющихся отражением реальных бизнес-операций (будь то приход, расход, инвентаризация или уценка) — такова архитектура IEM-систем.

Таким образом, IEM-регистр является именно что полным отражением реального бизнес-объекта вашего предприятия — со всеми его значащими свойствами. И «регистр», отражение объекта, изменяется синхронно со своим реальным оригиналом — всеми свойствами одновременно.

С позиции кладовщика регистр «Склад» является автоматизированной приходно-расходной книгой, для финансиста — статьей «ТМЦ на складах» в активе баланса, для разрабочика — многомерным кубом.

Но сущность регистра «Склад» в своей целокупности всегда остается неизменной.

Данные, содержащиеся в регистрах IEM, едины для всех подразделений и сотрудников.

Каждый потребитель управленческой информации работает с теми же регистрами, что и другие потребители, но под своим углом зрения — каждому IEM Система дает именно то, что ему нужно.

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

В результате естественным и автоматическим образом происходит многократная выверка данных, и если в них находится ошибка, корректировку в некоем отдельном “модуле” сделать просто невозможно — за полным отсутствием оного.

Либо ошибка попадет в отчетность к акционерам, либо подразделение, ответственное за появление ошибки, ее исправит (а, возможно, и бизнес-процесс, позволяющий создавать ошибки).

На языке математики это называется гарантированной достоверностью данных монолитного инфоконтейнера IEM: либо достоверны все данные, в нем заключенные, либо они недостоверны все сразу.
 

January 20, 2015 by Al Gal