Купить, доработать или создать свою систему управления производством

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

Четыре пути

Между «купить» и «создать» есть ещё два варианта, и у каждого свои риски.

Главное правило: стандартное покупайте, уникальное стройте

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

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

Урок Lidl: когда доработки съедают проект

Попытка адаптировать типовую систему ко всем существующим процессам может существенно увеличить сложность проекта. Lidl семь лет (2011-2018) пыталась внедрить SAP и потратила около 500 млн евро. Компания вела учёт запасов по закупочным ценам, а стандартная логика системы строилась вокруг розничных. Вместо изменения процесса выбрали масштабные доработки, которые раздули сроки и стоимость. Проект закрыли. Panorama Consulting называет это разрывом требований: несоответствием между тем, как работает компания, и тем, как устроена программа.

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

Как ИИ изменил экономику собственной разработки

Генеративный ИИ в 2024-2026 годах заметно удешевил написание типового кода: экранов, форм, отчётов, интеграций, тестов. Собственные контуры (цеховой учёт, доска мастера, управление буферами, мобильные формы контроля) стали доступнее средним и даже малым предприятиям.

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

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

Именно эти работы составляют большую часть стоимости и риска. Когда код перестаёт быть главным ограничением, главным ограничением становится качество мышления.

Отдельно о разработке «на скорую руку» с помощью ИИ. Система, от которой зависит производство, не должна быть набором случайно сгенерированных экранов. Минимальные правила: сначала модель данных и правила, потом код; задание для ИИ пишется как спецификация с бизнес-правилами, исключениями и критериями приёмки; весь код в системе контроля версий; автоматические тесты на остатки, статусы и права; отдельная тестовая среда.

Когда собственная разработка оправдана

Собственная разработка или разработка на платформе оправдана, если выполнено большинство условий:

1. процесс действительно уникален и даёт конкурентное преимущество;
2. типовые системы покрывают его плохо, и это подтверждено демонстрацией на ваших сценариях, а не впечатлением;
3. контур можно чётко ограничить, например «цеховой учёт и приоритеты», а учёт, финансы и налоги остаются в типовой системе;
4. есть человек, который будет владельцем системы и сможет её развивать: не обязательно программист, но обязательно аналитик;
5. есть бюджет не только на создание, но и на сопровождение, рассчитанный по требованиям к поддержке и развитию;
6. вы готовы соблюдать инженерную дисциплину: версии, тесты, резервные копии, документацию.

Если большинство условий не выполнено, выбирайте типовое решение и подстраивайте процессы.

Собственный контур рядом с 1С

Один из возможных вариантов архитектуры: учёт остаётся в 1С, а производственный контур создаётся отдельно. Чтобы две системы не начали спорить друг с другом, нужны пять правил:

1. Мастер-система для каждого вида данных. Номенклатура, контрагенты, цены, бухгалтерия, зарплата в 1С; маршруты, операции, события цеха, расписание в производственной системе.
2. Обмен в одну сторону для каждого атрибута. Номенклатура приходит из 1С, факт выпуска и расхода материалов уходит в 1С.
3. Внешние идентификаторы объектов учётной системы, а не только наименования.
4. Повторная отправка не создаёт дубль, каждая операция обмена записывается в журнал.
5. Регулярная автоматическая сверка остатков и выпуска между системами.

Так же устроены реальные проекты «Модуля»: у «БРАВО» продажи и договоры остались в 1С, у «МК Подъём» в Bitrix24, а производственный контур спроектирован под способ работы каждой компании.

Сколько это стоит в трудозатратах

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

Статья основана на книге «Управление производством»

В книге главы 13 и 27 разобраны подробнее: с формулами, примерами, шаблонами и полным списком источников.

Читать первые главыО книге