Как отраслевой опыт автоматизации помогает снизить стоимость аналогичных проектов и избежать ошибок

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

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

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

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

Но что именно означает это «наличие опыта»? Достаточно, чтобы хотя бы один член команды участвовал в похожем проекте ранее или вся команда должна понимать специфику? Должен ли этот опыт быть описан или можно обойтись знаниями «в головах»? Что вообще входит в опыт – доработки, схемы интеграции, готовые модели процессов?

В статье рассказываем, о том, как сохранять опыт прошлых проектов, в чём он заключается, как с пользой применять его в новых проектах. Материал основан на нашем собственном опыте системного хранения и применения готовых решений и наработок для проектов внедрения 1С.

Что не так с применением типовых решений в сложном отраслевом проекте

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

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

Разрыв между типовым функционалом и реальным бизнесом возникает сразу в нескольких измерениях:

1. Тип отрасли: разные законы – одна система

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

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

2. Длительность производственного цикла

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

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

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

3. Количество и глубина переделов

Еще один критичный фактор – передельность производства.

• Есть малопередельные производства (молочная продукция, напольные покрытия – 1–2–3 передела).
• Есть сложные многопередельные цепочки.

В качестве примера многопередельной цепочки приведём автомобилестроение. Готовое изделие – например, подушка безопасности – может состоять из множества уровней полуфабрикатов. Она включает саму подушку, газовые компоненты, электронику (которая, в свою очередь, состоит из другого ряда полуфабрикатов, а те из других п/ф или материалов). И каждый уровень имеет свою структуру и затраты. В автокомпонентах количество переделов может доходить до 8–9 уровней.

Учетная система в такой ситуации:

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

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

Почему отраслевые проекты становятся дорогими, долгими и непредсказуемыми при отсутствии опыта автоматизации

Если подрядчик делает проект с отраслевой спецификой впервые – он «набивает шишки» за счет заказчика, сталкиваясь со всеми описанными ранее проблемами.

У этого есть несколько причин:

Причина 1. Проверка на готовой системе

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

Причина 2. Больше итераций, тестов и неочевидных ограничений

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

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

• «Этот кейс не описали, потому что он редкий»;
• «Этим функционалом пользовались раз в месяц, но сейчас он критичен»;
• «На тестовых данных все работало, а на реальных – нет или не хватает быстродействия».

Как показывает практика, в результате к изначально запланированному бюджету на кастомизацию часто добавляется еще порядка +30% – просто для того, чтобы довести решение до рабочего состояния.

Причина 3. Неполные и недостоверные бизнес-требования

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

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

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

Причина 4. Сопротивление пользователей из-за нестабильных решений

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

Наш подход: системное хранение и применение наработок из реализованных проектов

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

Опыт как актив

В большинстве проектов опыт существует в виде знаний отдельных членов команды: «Мы такое уже делали – тогда сработало…». Проблема в том, что такой опыт сложно масштабировать, он теряется со сменой команды, плохо воспроизводится в новых проектах.

Мы в assino пошли другим путем – фиксируем опыт и наработки и используем их в будущих проектах. Для этого в компании сформирован банк знаний – репозиторий проверенных решений, который:

• содержит обезличенные наработки по реальным проектам;
• включает архитектурные и методологические решения, прошедшие ОПЭ;
• используется в новых проектах как основа работы, а не только для решения отдельных задач.

Глубина этих наработок составляет до 10 лет. Более старые решения, как правило, теряют актуальность из-за изменений платформы, типового функционала и бизнес-контекста.

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

О каких наработках идёт речь

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

1. Технический и архитектурный уровень

• проверенные архитектурные решения, готовые доработки 1С;
• готовые модули и подсистемы;
• типовые и нетиповые схемы интеграции с внешними системами и оборудованием;
• схемы загрузки данных.

2. Методологический уровень

• модели бизнес-процессов в нотациях BPMN, IDEF0, EPC;
• готовая структура НСИ (нормативно-справочной информации) для различных отраслей;
• методики моделирования и декомпозиции процессов;
• отраслевые сценарии работы в ERP, которые имели успех в продакшене.

3. Понимание ограничений

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

Например, в проектах для автомобильной промышленности мы заранее учитываем ограничения расчета себестоимости при многоуровневых ресурсных спецификациях (BOM с 7–9 уровнями).

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

Командная модель: скорость без потери качества

Системный подход – не только о том «что делать», но и «кто и как это делает». В отраслевые проекты мы заходим командой, в которой:

• задействованы специалисты разных уровней: от junior до архитектора;
• задачи распределяются по сложности, а не по принципу «все делает самый опытный»;
• младшие специалисты работают под контролем старших специалистов и архитекторов.

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

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

Почему даже при наличии готовых решений необходимо обследование

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

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

• по типу производства (добывающее, обрабатывающее, энергетическое);
• по длительности цикла (от ежедневного выпуска до проектов на 1–2 года);
• по количеству переделов и глубине спецификаций;
• по логике расчета себестоимости, учета НЗП, распределения косвенных расходов;
• по интеграциям с оборудованием, MES, WMS, внешними системами.

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

При этом обследование «с нуля» и обследование, которое проводит подрядчик с опытом в сфере, отличается.

У подрядчика без опыта:

• значительная часть времени уходит на изучение предметной области;
• аналитик не всегда может предложить улучшение бизнес-процессов;
• формулировки требований уточняются по нескольку раз;
• ограничения обнаруживаются только на этапе разработки или ОПЭ.

При наличии отраслевых наработок обследование выглядит иначе:

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

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

В чём проявляется экономия бюджета

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

Но основной эффект проявляется на следующих этапах:

1. Моделирование: меньше итераций. Без наработок:

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

С накопленным опытом:

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

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

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

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

3. Запуск и ОПЭ: снижение сопротивления. На этапе запуска и опытно-промышленной эксплуатации экономия становится особенно заметной – хотя ее редко закладывают в расчеты заранее.

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

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

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

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

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

Пример из практики: в автомобилестроении ресурсные спецификации называют BOM (Bill of Materials), говорят о переделах, уровнях полуфабрикатов. Если на встрече подрядчик уверенно оперирует понятиями – это индикатор того, что он уже был в подобных проектах.

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

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

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

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

4. Вопросы, которые подрядчик задает сам. Ещё один надежный критерий – какие вопросы подрядчик задает самостоятельно. Эксперт не ждет, пока заказчик сам все сформулирует. Он задаёт предметные вопросы, знает, где искать ограничения и проблемы, какие неочевидные сценарии использования системы есть у заказчика.

Помощь в автоматизации бизнеса со сложной отраслевой спецификой

Отраслевые проекты автоматизации почти всегда связаны с рисками. Разная логика производства, нестандартные расчеты, длинные циклы, нетиповые интеграции – все это может сделать проект дорогим и непредсказуемым в плане результативности.

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

Мы храним более чем 10 лет опыта автоматизации. Благодаря этому в сложных отраслевых проектах не приходится начинать с нуля и экспериментировать за счет заказчика. Наработки, готовые решения и знания предметной области помогают в работе.

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

Оставьте заявку по форме ниже – эксперт свяжется с вами для консультации.