Представляем продолжение стенограммы записи интервью и докладов экспертов ИТРП на презентации в формате “Круглый стол по 1C:ERP”, проведенной в Санкт-Петербурге в июне 2019г (первая часть была опубликована на сайте ИТРП в предыдущей публикации).

Ранее в своем выступлении коллеги ответили на вопросы о влиянии 1C:ERP на бизнес-процессы управления организацией.  Продолжим и дополним затронутую тему: в этой части доклада вспомним, каковы основные особенности 1C:ERP по сравнению с учетными программами 1С. Из этих особенностей будем исходить в подходах к внедрению системы.

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

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

На основании планов производства мы строим планы снабжения, закупок и, наконец, бюджеты – в т. ч. план движения денежных средств (ДДС) до казначейства. Так выстраивается вся цепочка функций в общем случае, но на практике не обязательно на каждом предприятии задействуются все виды планов. В отдельных случаях вообще объемное планирование может не применяться, а используется оперативный расчет потребностей по статистике, на других предприятиях производство планируют «заказ-под-заказ», всё это индивидуально…

Однако пройдем по цепочке, рассмотрим некоторые специфичные вопросы, возникающие при внедрении планирования.

Продажи: аспекты внедрения

Начинаем с плана продаж. И вот здесь важнейший момент, когда нужно руководителю и всем службам «договориться на берегу» и выйти на компромиссный вариант при определении временной зоны, в рамках которой исключается вставка новых заказов на выпуск готовой продукции. Часто такую зону называют «Замороженной зоной». Дело в том, что объемно-календарное планирование представляет собой последовательность взаимозависимых планов и в результате взаимных пересчетов планов могут вноситься изменения в производственные планы. Изменение производственных планов в ближайшем горизонте вызывает т. н. «нервозность» производства. От того, насколько гибкой является реакция производственной системы на изменение планов (заказов), зависит отзывчивость компании к изменениям спроса на рынке. Добиться событийной системы планирования в реальном времени – когда мы пытаемся ловить каждый срочный заказ, и под него ломаем все планы и тут же  пересчитываем задания по цехам/участкам – часто бывает крайне затруднительно в связи с инерционностью производственной системы. Как минимум, неоправданно дорого.

Если этой договоренности о «замороженной зоне» нет, то клиентская служба будет время от времени прибегать с требованием: «Аааа!! У нас новый важный заказчик, нужно срочно вот такую-то продукцию!». Иногда такую, что требуется серьезная работа по подготовке производства.  Это ломает производству и логистике все планы. Один из наших заказчиков выразился так: «Наша служба продаж – это обезьяна с гранатой в производстве» 😊. Постоянное неупорядоченное перепланирование может оборачиваться особенно большими неприятностями и потерями, если переналадка оборудования на другую продукцию занимает значительное время. Обязательно нужно договориться о фиксированной «замороженной» зоне и соблюдать ее. Вставка новых заказов в «замороженную» зону разрешается только по согласованию с руководством предприятия. То есть до определенной точки на временной шкале, в течение декларированного горизонта – с новыми заказами продажникам влезать нельзя, новый заказ следует ставить после этого горизонта. И с выбором методологии формирования плана продаж, и с выбором «замороженной зоны» лучше определяться еще до того, как будут потрачены деньги и время на настройку системы планирования.

Планирование производства

Итак, у нас есть график продаж и мы можем на основании графика продаж определить график выпуска готовой продукции (т. н. «Главный календарный план производства» (ГКПП). ГКПП в 1С:ERP реализован в виде множества Заказов на производство готовой продукции, выпуск готовой продукции по которым привязан к временной оси. Как от ГКПП перейти к графику выпуска промежуточных изделий (сборок, ДСЕ, заготовок, полуфабрикатов) отдельными цехами и участками в технологической цепочке?

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

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

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

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

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

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

Теперь об этапах работ при внедрении системы

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

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

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

Анализ производственной системы и при необходимости сквозной пример составляют основу этапа «Концептуальное проектирование». На этом этапе оценивается соответствие возможностей и методологии системы с потребностями бизнеса и потенциальные риски, в т. ч. готовность заказчика организационно и ментально к проекту. Напомним, что проект внедрения ERP-системы – это не только и не столько процесс установки и настройки программ, это прежде всего процесс реорганизации и оптимизации бизнес-процессов, формализации и оцифровки нормативных данных, формирования навыков пользователей, процесс непрерывного управления изменениями проекта. Таким образом, в отличие от внедрения локальных задач (бухгалтерия, складской учет и т. д.), проект внедрения ERP – это на 80% процесс организационных изменений у Заказчика. Помните всегда об этом, особенно при выяснении, почему проект «буксует»!

Итак, в концепте внедрения ERP-системы дается оценка будущего проекта в системе координат «прогнозный бюджет/сроки/бизнес-выгоды/риски». На основании этой оценки Заказчик принимает обоснованное решение о готовности начать проект.

Если решение о внедрении принято, то начинаем Функциональное моделирование. Выполняется оно силами аналитиков от 1 до, в некоторых случаях, 4 месяцев. Здесь важно большую часть времени этого этапа физически присутствовать на предприятии: общаться, работать с ключевыми пользователями, фиксировать информацию, воспроизводить услышанное и получать обратную связь. Модель делаем вместе с функциональными заказчиками, всецело вовлекая их в процесс, двигаемся небольшими итерациями, обсуждая с заказчиком промежуточные результаты.

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

Заказчик должен быть готов к тому, что по своим требованиям он будет отвечать на вопросы консультантов, которые в общем случае звучат как «Зачем?». Например, если заказчик требует вводить в систему те или иные данные, ту или иную аналитику или степень оперативности, получать те или иные отчеты – мы задаем вопросы: «Кто потребитель этих данных, в каких процессах они используются, какие решения могут приниматься на основе этих данных?» Мы должны видеть процесс – тогда сможем предложить наиболее правильное и адекватное решение с минимизацией доработок.  И это решение, возможно, будет непривычно Заказчику. Но оно будет правильным и оптимальным.

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

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

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

Далее, что касается реализации доработок, т. е. программирования…

Для конечного заказчика (не программиста) важно знать несколько принципиальных моментов.

• Особенность платформы 1С в том, что скорость работы функционала, возможность работы параллельно многих пользователей без «зависания» системы всецело зависят от квалификации программиста и знания им специальных приемов, повышающих производительность. Производительный код писать намного сложнее и более трудоемко, чем «тяп-ляп».
• В настоящее время механизм расширений позволяет выполнять доработки в отдельном программном слое, не снимая систему с сопровождения. Квалифицированный архитектор 1С понимает тонкую грань между вмешательством в расчетное ядро системы и «тюнингом-обвесом». Неопытный программист в процессе доработок подобен слону в посудной лавке – он способен обрушить систему, вмешавшись туда куда не следует, причем так, что последствия будут обнаружены тогда, когда поздно будет исправлять из-за накопления большого массива данных.
• Приемка доработок должна выполняться строго по программе испытаний, согласованной с заказчиком. Иначе приемка результатов может превратиться в обсуждение – что в системе должно быть, а что не должно и кто утвердил такое ТЗ…
• Если доработаны связанные процессы, необходимы сквозные испытания, желательно в виде тренинга пользователей – это позволит обнаружить возможные нестыковки. Иногда даже недостатки в эргономике могут стать причиной неработоспособности системы.

И самая главная рекомендация – пожалуйста, не надейтесь на чудо, не ждите, что интегратор за вас предоставит «от и до» всю методологию управления вашим предприятием. Заказчику следует продумать свои потребности, приоритеты, ограничения хотя бы концептуально. А вот детализировать методики управления с учетом поддержки их автоматизированной системой 1C:ERP – мы, конечно, поможем.

Успешных внедрений! :)

На вопросы отвечали: Лисин Николай и другие эксперты ИТРП.