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

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

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

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

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

Законы Мерфи

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

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

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

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

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

Но не ERP-системы.
 


 

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

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

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

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

Но... Как интегрировать палец с огурцом?

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

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

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

 

Итоговое количество «модулей» ограничено только платежеспособностью компании, и склонностью руководства компании к поиску ИТ-эликсира.


II. Кому от модульных ERP-систем жить хорошо. О вершках и корешках.

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

  • легко производить и расширять функционал: знай себе интегрируй дополнительные модули. 
    Происхождение которых значения не имеет. Доминирующие на рынке ERP системы радуют глаз многоцветным разнообразием всепланетного интернационала модулей — когда-то написанных, приобретенных/лицензированных у сторонних разработчиков, доставшихся бесплатно вместе с купленными компаниями, и т.д.
  • удобно рекламировать
    Особенно ИТ-неосведомлённой аудитории в духе: « — Ох, как у нас много модулей, смотри ж ты! Очень, мол, богатый функционал
  • и, самое главное, — продавать
    Мол, купите сначала WMS, а потом CRM, а потом и SCM, а когда совсем разбогатеете — HRM, BPM и PLM. А пока вы все ранее купленное будете «интегрировать», маркетологи новую аббревиатуру придумают.

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

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


Взгляните на свой бизнес со стороны.

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

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

?

Правильно.

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

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

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

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

Во-от.

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

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

Увы и ах. Сказку про голого короля помните?
 

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

Модульные ERP подарили миру такую… как сказать… возможность что ли? короче — независимое «исполнение» («проведение») по разным модулям.

Упрощенно: есть продажная накладная.

Если ее провести в складском WMS-модуле, она спишет содержащийся товар со склада — в штуках. А можно и не проводить. Пусть так и висит в списке документов — распечатать бумажную накладную, и отдать товар со склада это не помешает.

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

Если ее провести в CRM модуле, то на клиента начислятся бонусы, которые можно будет увидеть в карточке клиента. А можно... — «вы уже понимаете».

Независимое проведение по разным модулям легально позволяет провести документ в модуле WMS, и — не сделать это в «финансовом».

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

Вопрос: можно ли себе представить ситуацию, более благоприятную для воровства космических масштабов?

А в интерпретации вендоров ERP это — «гибкость».

Дополнительный вопрос: можете ли вы представить ситуацию, действительно обусловленную требованиями бизнеса и интересами акционеров, при которой подобная «гибкость» может быть оправдана?
 


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

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

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

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

Затем, если проблема устранена не будет, сотрудник финотдела даже не будет письмо писать — сразу сделает корректировку. Потому что нужно делать отчетность, ждать некогда.

С течением времени ИТ-отдел по требованию финансового отдела напишет алгоритм, делающий эти корректировки автоматически, тем самым сэкономив кучу времени финансистам («производительность» труда же!).

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

Данные же в «систему» вбиваются вручную задним числом (чуть позже — вообще не).


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

Вендоры ERP позиционируют модульность как преимущество — возможность «поэтапного внедрения».

Мол, сначала, внедряем в финансах, обкатываем, потом на складе, потом в продажах и так далее. Логично?

На первый взгляд — да.

Но... опять возвращаемся к эпиграфу.

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

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

Рассмотрим на примере «финансов» — именно с них, как правило, начинаются «поэтапные» внедрения модульных систем. 

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

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

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

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

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

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

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

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

Для всех вовлеченных «в процесс» сотрудников это бесконечный, дурной и неоплачиваемый зряшный труд. Качество вытекает.

В итоге два системных следствия:

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

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

Вот видите. Мы же говорили, что ERP-профессионалом для этого быть необязательно.
 


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

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

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

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

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

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

V. Исключительная всеохватность IEM — гарантированная достоверность данных

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

 

Монопольную централизованную всеохватность IEM: нет Модулей кроме инфосферы Дайсона, и IEM System — Воплощение Её.

Управляющая IEM Система предприятия:

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

В архитектуре IEM System одной из основных сущностей являются «регистры».

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

Неограниченная же функциональность IEM System позволяет ей одной заменить все ныне известные ABC-системы.

И даже те, которые ИТ-маркетологи еще не успели изобрести.

January 20, 2015 by John Galt