Признаки и причины неуспешных внедрений 1С: ERP

Суть в том, что 1С ERP работает как «полуавтомат». А должна работать как «полный автомат». Здесь понятие «автомат» имеет не тот контекст, что в классической кибернетической теории автоматов.

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

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

Все документы (операции) формируют последовательные записи в регистры (иерархия на оси времени). Регистры обеспечивают взаимодействие функциональных блоков и документов (операций) из экономически отдельных цепочек блоков (документов, операций). Например: цепочка «ТОиР» и цепочка «Производство» экономически отдельны, могут исполняться параллельно, независимо. Но, через регистры они связаны. Например: на расчет программы производства влияет состояние ремонта/обслуживания основных средств. Аналогично на производство влияет цепочка «ЗУП», которая многим кажется вовсе независимой настолько, что ЗУП (зарплата и управление персоналом) ведут в отдельной базе.

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

Модель же 1С ERP работает в режиме «полуавтомата», в одном направлении («прямой» ход), а вот автокорректировки, т.е. «обратного» хода в ней нет. Отсюда и гигантские проблемы с «перепроведением» и проблемы с пересчётом регистров, если изменились настройки системы или код алгоритма отдельного объекта (документа). В общем, пользователям ERP есть чем заниматься – постоянно раскапывать почему и что не так считается.

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

Диспетчирование в 1С ERP выражается в том, что подача заданий на производство может быть задана вручную человеком - диспетчером. Получив отчёт-срез состояний загрузки оборудования, наличия материалов и т.п., проще говоря, получив срез ресурсов и имея список задач, человек может принять решение и перетасовать очередь работы оборудования (берите выше - всей компании) или вмешаться в результаты автоматического расчёта.

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

- срез свободных мощностей на момент принятия решения и на период исполнения задания (список оборудования/персонала и их свободные слоты рабочего времени);

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

- сроки исполнения каждого задания из очереди всех заказов клиента (сроки поставки клиенту по заказу, сформировавшему задание);

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

Всё?

Для простого случая всё.

Но простым случаем будет всего три варианта:

1) Заказов (заданий) меньше, чем производственных мощностей (ресурсов) на их реализацию. Это случай, когда либо бизнес не выбирает все возможные сделки/заказы с рынка, либо бизнес имеет избыточные активы в данной сфере экономики;

2) В ходе задания на производство (этапа) выполняется одна простая операция;

3) Заказы (из которых формируются задания на производство) составляют стабильный неизменяемый список, объёмы, параметры изделия и сроки, однажды определенные, не изменяются.

Здесь 1С ERP и диспетчер с ручной подачей заданий справятся. Но, это при условии одновременного исполнения трёх вариантов, позволяющим считать случай «простым».

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

Ниже на ментальной карте выведены верхнеуровневые параметры, которые должен держать в голове диспетчер (плановик, руководитель), пытающийся управлять заданиями на производство (этапами, выпуском, а руководитель ещё и всей экономикой от заказа клиента до логистики закупок).

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

Теперь смотрим внимательнее на схему и замечаем, что большинство параметров относятся не сколь к текущему моменту (слоту) времени, в котором «диспетчер» принимает решение, а описывают ситуацию с ещё не состоявшимися событиями, например:

- очередь заказов от клиентов;

- очередь заданий на производство по другим заказам;

- загрузка оборудования от сегодня и далее;

- загрузка и наличие персонала от сегодня и далее;

- остатки сырья сейчас и в каждый последующий слот времени = логистика;

- и т.д.

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

Отсюда следствие: ERP-система должна использовать блок планирования и с возможностью автоматической корректировки.

Теперь построим возражение на этот аргумент: «В 1С ERP есть функционал расчёта производственной программы (т.е. производственного планирования), поэтому можно обойтись без планирования на верхнем уровне (на уровне сделок)».

Обратимся снова к ментальной карте выше. Функционал 1С ERP по расчёту производственной программы не учитывает в этих блоках следующее:

1) В блоке «Финансы»

             Факт неоплаты в срок (недостатка средств) – кассового разрыва.

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

Следствие: Расчёт производственной программы должен делаться не только с учётом наличия сырья в заданные моменты времени в будущем, но и от наличия необходимого остатка в заданные моменты времени в будущем. Причем не только остатков сырья, но и денежных средств. (Это, кстати говоря, можно сделать через «План остатков» системы планирования 1С ERP).

2) В блоке «События»

   Ряд событий (сбой, брак, запреты и др.) создают «петли» движения ТМЦ. Например: необходимость дополнительных операций по дозакупке/переработке/переделке/переводу_в_сырьё брака. При этом переработка брака занимает ресурсы оборудования и конкурирует с вариантом закупки сырья вновь, но зато с более длительной логистикой доставки на склад.

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

Например, в химическом производстве (синтетических масел) может быть запрещено в отдельных реакторах варить дешёвое масло, а можно только дорогое. Хотя рядом в точно таком же реакторе дешёвое масло делается без проблем. Причина – необходимость промывки реактора и труб перед варкой дорого масла после дешёвого, а это затратная по ресурсу и времени операция.

Следствие:

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

3) В блоке «Сложно-компонентные параметры на период»

Здесь как раз сокрыта проблема, происходящая из предыдущего пункта. В 1С ERP в настоящее время нет функционала, учитывающего историю предыдущих операций (циклов, партий), который определяет по какому варианту пойдут технологические и организационные процессы дальше.

4) В блоке «Производительность учётного ПО»

Здесь есть неявные параметры, которыми не может управлять производственник - «диспетчер».

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

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

Здесь речь идёт не только о производительности кода ERP (зачастую «допиленного») и серверов, а даже о потенциальной ресурсоёмкости функционала расчёта системы линейных уравнений, необходимого для подобных расчётов в ERP. Не зря для многих производственных, особенно оборонных, машиностроительных компаний, после внедрения УПП/ERP внезапно (удивительно, да?) встаёт проблема ресурсоёмкости пересчёта производственных программ. Для чего начинают смотреть в сторону специальных продуктов типа Siemens Preactor и/или «чистого SQL». А тут ещё санкции и расцвет «дружбы» с Европой и прочими Америками. В самой ERP нужно дорабатывать этот функционал объёмным кодом и не факт что средствами платформы 1С.

  В 1С ERP этот расчёт производится в единственном «текущем сценарии» (в блоке «Производство» 1C ERP вообще нет функционала сценариев расчёта). Но расчёт в «текущем сценарии» может вызвать сдвиг в производственной программе и логистике закупок. И, если расчёт отменяется в силу показанной невыгодности принятия в работу конкретного данного заказа, то необходимо производственную программу вернуть в предрасчетное состояние. Если в период расчета одного заказа поступит второй заказ, то расчёт второго заказа может быть выполнен некорректно, неоптимально, т.к. его возможные слоты времени может в расчете захватить первый заказ, а потом оставить эти слоты пустыми после отмены первого расчета. Чем больше количество заказов, требующих пересекающихся расчетов, тем хуже последствия неоптимальной работы производства и логистики.

Из сказанного ранее возникает необходимость в сценарном расчёте производственной программы. Сценарный расчёт в 1С ERP возможен в блоке «Планирование». Его механизм более примитивен по сравнению с расчетом производственной программы в текущем времени (сценарии), но его условно достаточно для грубой экономической оценки заказа и оценки использования слотов времени и ресурсов на производство. Это означает построение так называемой «системы маржинального управления». Т.е. опять «пилить» код.

Но, к сожалению, и в блоке «Планирование» ERP не реализован полноценный автомат расчёта. Можно автоматически получить из Плана продаж План закупок и План производства с помощью Спецификаций, сформировать Заказы поставщикам/переработчикам, но нет механизма, который, в случае изменения строчки в Плане продаж или Спецификации, аккуратно изымет из связанных планов и заказов «ветки» зависимой номенклатуры и параметров. Да ещё с учётом того, что по общему бизнес-правилу не все заказы поставщику могут быть отозваны автоматически после прохождения точки отзыва.

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

Рассмотрим проблему на примере НСИ номенклатуры. Одна номенклатура представляет в Планировании одну строчку Плана продаж, из которой с помощью спецификации разворачиваются План Закупок и План производства со множеством связанных строк. Если в спецификации выпуска встречаются полуфабрикаты, а к ним ещё полуфабрикаты или выпуск от смежника и так много-много раз (а на практике достаточно и пары уровней), как возникает сложное ветвистое иерархическое дерево связи единицы выпуска с исходным сырьём и оборудованием. На предприятии с большой номенклатурой выпуска, вариативностью аналогов сырья, вариативностью характеристик номенклатуры выпуска, сырья, полуфабрикатов, зависимостью технологических процессов от выбранного изделия или полуфабриката и/или состояния ресурсов возникает сложнейший многомерный объект N-мерного пространства. Который, кстати, в ERP можно увидеть лишь частично с помощью двумерных таблиц типовых отчётов.

Много шансов у человека-диспетчера, технолога, руководителя с помощью таблиц простейшего вида управлять N-мерным пространством? Выше упоминалось, что человек видит и может управлять не более семью уровнями. А, значит, при формировании планового сценария или производственной программы он может выдавать лишь какие-то решения. Может удачные, может - нет. Проверить нечем.  

Решает ли задачу здесь автоматический механизм расчета производственной программы в самой ERP? Он решал бы, если бы применялись управляемые человеком критерии оптимальности для решения систем линейных уравнений и если бы выполнялся учёт непроизводственных параметров, влияющих на расчёт (см. выше). А вы видели в ERP функционал управления критериями оптимальности для линейных уравнений? Вот и я нет. Это не значит, что ERP не может рассчитать производственную программу. Она её рассчитывает. Но рассчитывает неоптимально, поскольку получает какое-то решение, но не проверяет его на оптимальность для бизнеса (нет управления критериями оптимальности при расчёте). Оптимально в контексте бизнеса означает нахождение варианта расчёта с минимумом затрат и/или минимумом времени исполнения.

И ладно бы это!

Но, функционал «Планирования» и функционал «Производство» в ERP тесно связаны с функционалом «Управление сделками» (это тот уровень, где формируются заказы покупателя, заказы поставщикам, переработчикам). Ранее упоминалось ветвистое дерево зависимости номенклатур. Так вот, изменение одной строчки номенклатуры в Плане продаж, а это нормальное и частое явление хозяйственной деятельности, т.е. корректировка продаж, при наличии ветвистого дерева связанности номенклатур, спускающегося к сырью и полуфабрикатам заказчиков и смежников, означает корректировку множества Планов закупок, Планов производства, Заданий на производство, Производственной программы и Заказов поставщику/переработчику, и как следствие логистики поставок. А вы видели в ERP инструмент изъятия из заказов поставщику строчек номенклатуры, связанных с корректируемой строчкой в плане продаж и пересчетом производства и логистики?

А с учётом, что не все заказы поставщику можно изменить после определенных событий? Что если сырьё уже поставщиком погружено в вагоны и отправлено? Кроме того, необходимо сценарное проигрывание корректировок перед их внесением. И этого в ERP нет.

Общее между блоком «Планирования» и блоком «Производство» - это Спецификации (ресурсные). Также Спецификации являются инструментом, фиксирующим иерархическое дерево связанности номенклатуры выпуска и номенклатуры сырья. И именно правильно составленные Спецификации позволяют использовать «Планирование» и «Производство» в 1С ERP в согласованном расчёте потенциальной производственной программы на значительный период времени вперёд. Это к тому, что Планирование может сделать предварительную оценку производственно-логистического цикла методом маржинального управления, прежде чем задача пойдёт в производственную программу.

Что значит «правильно» составленные Спецификации?

Как минимум это означает, что

А) Спецификации основаны на «правильной» НСИ, т.е.

- безупречно отлаженной НСИ;

- НСИ, увязывающей внутреннюю номенклатуру  с номенклатурой рынка (поставщиков и покупателей). Это основа маржинального управления;

- НСИ, жестко интегрированной с иными учётными системами (особенно конструкторскими). Это основывается на надлежащей интеграции (на уровне ESB, шины данных)

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

            Особая отдельная проблема модели 1C ERP заключается в беспощадности к попыткам перепроведения объектов уже раз проведённых и размещённых на оси времени. Модель предполагает, что:

- объекты системы (чаще всего «документы») формируют множество записей во множество регистров;

- другие объекты и функции (документы, отчеты, алгоритмы и т.п.) считывают состояние регистров и создают свои записи регистров.

                Любое изменение документа требует, чтобы были перепроведены все объекты, лежащие по оси времени после него и зависимые от него через регистры. Здесь и возникают множественные ошибки:

- неперепроведения всех необходимых объектов;

- ошибок заполнения регистров из-за кода системы или задержек записи в регистры;

- появления новых регистров, ранее не заполнявшихся данным объектом.

                Исправить ошибки проведения – это целая эпопея, которую не все могут довести до конца, а ошибки воспроизводятся ещё и ещё. Отсюда следствие – ERP требует буквально одноразового проведения и запрета перепроведения. Это значит, что бизнес (учёт) должен работать на уровне японской технологии just in time (JIT) или должен быть применён SAPовский принцип – однажды сделанное не изменяется, а только корректируется специальным документом. Реально российскому бизнесу перейти на JIT технологии с постоянной потребностью внести, исправить что-то задним числом? Реально. Но стоить будет дорого. Модель 1C ERP позволяет перепроведение, но не любит его и обязательно наказывает тех, кто перепроводит.

                Резюмируя по разделу «Проблемы модели ERP» можно понять следующее, что текущая модель и функциональность, реализованные в 1С ERP:

                 А) предназначены для относительно несложных бизнес-процессов;

                Б) не имеют возможности полноценного сценарного проигрывания вариантов;

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

Г) работают как «полуавтомат» в связке Планирование-Закупки-Производство-Сделки (Заказы), хотя для решения потребностей современного бизнеса необходим «полный автомат» с обратным ходом. И требуют жесткого соблюдения внутреннего бизнес-процесса ERP, который складывается в определённую пирамиду последовательности внедрения и использования функционала ERP;

Д) Даже имеющийся функционал в модели 1С ERP используется ненадлежащим образом, если не применяется функционал «Планирования» хотя бы в типовом виде.

Е) Требуют работы всего бизнеса на уровне технологий JIT.