“Модульные” системы: то, о чем вы узнаете только после провала проекта внедрения

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

Законы Мерфи

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Собственно, именно так и заканчиваются 99% проектов внедрения SAP.

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

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

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

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

Монолитные ERP-решения на платформе Ultimate Solid

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

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

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

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

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

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

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

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

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

« — Эге!», — могут возгласить скептики. «— Значит, получается, вы самые умные. А что ж тогда вы не самые богатые?»
или
«— А что ж тогда получается, во всяких многомиллиардных сапах с аксаптами дураки сидят, что всего этого не понимают? А вы тут одни такие гениальные?»
Нет, товарищи.
Во-первых, в сапах и аксаптах и примкнувший к ним Шепилов прочих зибелях сидят отнюдь не дураки.
И сами тамошние товарищи все вышеизложенное осознают не хуже нас с вами.
Однако самый гениальный строитель при очередной перекладке крыши не сможет поправить принципиальные косяки фундамента, заложенные при строительстве здания еще тридцать лет назад. Снести и заново построить, да только кто ж ему даст.
Во-вторых, мы отнюдь не одни такие умные. И более того: over 95% рынка СНГ систем управления предприятием в численном выражении принадлежит монолитным системам.
Именно так, дорогие товарищи: 1С: Управление предприятием является ярчайшим представителем монолитных систем. И по своей архитектуре, юзабельности и внедрябельности 1С: УПП даст сто тысяч очков вперед любым сапам, аксаптам и прочим надутым пузырям. Единственная беда 1С — принципиальная ограниченность производительности и функционала, следствие изначальной ориентация на малый и сверх-малый бизнес. Впрочем, об этом мы уже писали.

VI. Заместительная терапия
в монолитных решениях Ultima

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

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

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

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

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

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

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