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

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

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

Вы в курсе, что SAP, MS Axapta/Dynamics AX и большинство других ERP, которые “на слуху”, являются “модульными” системами?

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

Тогда вы вряд ли знаете, что различия между ними имеют критически важное значение. И что неверный выбор на 98% гарантирует провал проекта внедрения.

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

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

Вначале немного истории.

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

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

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

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

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

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

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

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

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

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

 

Собственно, по такому же простому алгоритму Мэри Шелли скреативила известного литературно-кинематографического героя.

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

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

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

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

     
  • и продавать.
    Мол, купите сначала складской модуль, а потом когда деньги будут купите «HR-модуль», а еще есть мегасупер «МСФО-модуль» — пригодится когда на IPO пойдете и так далее. Во какая гибкость!

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

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



 

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

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

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

Представляете, как все это будет работать в реальности?
А если рыночные условия заставляют постоянно корректировать бизнес-процессы?
Во-во.
Именно так на практике и “работают” "модульные" системы.

Франкенштейн мог быть могучим чудовищем исключительно в фантазии автора и на экране.

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

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


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

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

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

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

Можете ли вы, положа руку на сердце, представить ситуацию, действительно обусловленную требованиями бизнеса и интересами акционеров, при которой подобная “гибкость” может быть оправдана? Если, опять же, не понимать понятие «бизнес» в том смысле, в каком его трактует гоп-компания небезызвестного Михал Иваныча.

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

Представим себе сотрудника финансового отдела, который нашел, например, ошибку в проводках, источником которой является товарный "модуль" системы. Он пытается связаться с кем-то из логистики, логистам в этом копаться неинтересно (да и не их это проблемы), или нужный человек ушел в отпуск или еще что-то.
Каковы дальнейшие действия сотрудника-финика? Он ответственно напишет письмо с описанием проблемы и сделает корректировку ошибки в “своем” финансовом "модуле" (со счета такого-то на счет такой-то такая-то сумма).
Это первые несколько раз.
Затем, если проблема устранена не будет, сотрудник даже не будет письмо писать — сразу сделает корректировку — нужно срочно предоставлять отчетность, ждать некогда. Потом ИТ-отдел по требованию финансового отдела напишет алгоритм, делающий эти корректировки автоматически, тем самым сэкономив кучу времени финансистам.
Обратите внимание — корректировки проводятся только в финансовом "модуле" и отражаются только на его итогах, косяки в товарном "модуле" правятся/создаются логистами/кладовщиками совершенно независимо.
Представьте степень (не) соответствия данных в обоих "модулях" другу (а сколько их еще в "модульной" системе!) и реальности на перспективе нескольких лет — с учетом того, что сотрудники всегда идут по пути наименьшего сопротивления.

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



 

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

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

Модульная система же, с точки зрения эксплуатанта, является совокупностью АРМов (порядком устаревших еще при Советском Союзе), функционал которых реализуется, в сущности, отдельными приложениями, зачастую разработанных разными компаниями в разные десятилетия. 
Представьте, колл-центр у вас работает в отдельном "модуле" колл-центра, склад в своей WMS-софтине, взаиморасчеты с клиентами находятся в модуле "Продажи". 
Все эти модули "интегрированы" между собою, в основном, пиарной лапшой продавцов суперсистемы под раскрученным зонтичным брендом. 
Чтобы передать данные из "колл-центра" на "склад", нужно провести цепочку "синхронизаций" между прокладочными "модулями". 
Конечно, на практике, это никто и не делает, поскольку тогда не то, что "процессный подход", а просто работа компании наглухо встанет.

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

 

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

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

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

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

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

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

Что получается в случае построения социализма в отдельно взятой стране “модульной” автоматизации отдельно взятого финансового блока?
Все данные нужно вносить минимум дважды: сначала продавец выписывает накладную в своей старой системе (1С, например или вообще вручную) — по этим документам идут реальные сделки.
Потом, все эти документы надо переносить (вторично наколачивать) в тот самый “финансовый модуль”.
И кто это будет делать?

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

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

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

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

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

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

 

V. Монолитные системы: сложнее для понимания,
архитектурно куда совершеннее.
Но — верное решение

Что же предлагаем мы — взамен “модульному” УГ?

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

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

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

Поясним последний тезис простыми словами.
В IEM-решениях на платформе Ultimate Solid основой учета являются регистры (во внутренней терминологии системы — «итоги»).

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

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

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

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

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

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

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

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

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

VI. Заместительная терапия
в IEM-системах Ultimate

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

Сии причины банальны.

Подобно тому, как приятель Швейка Благник уводил собак сосисками, а педофилы берут детей на шоколадки, “модульные” системы подкупают фиников/бухгалтеров циничной эксплуатацией профессиональных деформаций мышления. Ну как же, вот «главная книга»! Милая сердцу бухгалтера, начало начал бухгалтерии на протяжении вот уже более чем полутысячи лет. Все через нее, «Главная книга» всему голова. И тает, тает сердце финансового работника!

А у нас тем временем отсутствует финансовый “модуль” (равно как и любой “модуль” вообще, но остальные “модули” находятся вне интереса бухгалтеров)!
А… Mamma mia! У ВАС НЕТ ПЛАНА СЧЕТОВ!!!

А ведь и вправду — нет.
Вместо «плана счетов», свежайшего продукта всего-то 500–800 летней давности (смотря откуда считать) в виде нескольких столбцов цифр, мы предоставляем эксплуатантам систему «итогов», отражающей в себе предприятие клиента во всей его полноте.
«Итоги» системы имеют понятные всем сотрудникам названия (в противовес таинственным номерным шифрам бухгалтерского братства РСБУ), такие как «Остатки на складах», «Остатки по расчетным счетам», «Товарные долги водителей» etc.

Дорогим же соработникам бухгалтерско-финансовых сибирских руд, кои, подобно эксцентричному британскому лорду, каждый день требовавшему к завтраку Times столетней давности, не желают оскорблять свой взор паскудным опрощением великого искусства бухучета, обещаем (при их согласии, конечно!) в специальной бухгалтерской настройке интерфейса приводить названия, картинки и термины к теплому клетчатому пледу веками привычным стандартам.
Будет вам и 41, и 50, и 62 счет (и протчая елико угодно), и «план счетов».

Радуйте глаз на здоровье, дорогие товарищи!

Другие материалы из Библиотеки атеиста


Powered by Сон разума