Завод глазами молодого разработчика ERP. Часть 1

Меня зовут Николай, мне 21 год. Около двух месяцев назад мне впервые предложили принять участие в создании масштабного цифрового продукта - ERP-системы для завода моторных масел. Почти как очень большая практическая работа в университете, только вместо зачёта – реальный бизнес, деньги и несколько сотен видов продукции. Большой проект и классные перспективы проявить себя. Настоящий завод с множеством данных, сложной архитектурой и интеграцией с 1С. Звучало как работа, после которой я с полной уверенностью мог рассказывать, что смог обуздать и структурировать сложные процессы в кротчайшие сроки.

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

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

Проект, который начинался с дашборда

В конце июня наша команда получила исходную задачу: создать для производителя моторных масел систему BI-аналитики с элементами AI. От нас хотели получить управленческие дашборды, возможность работы с продажами и запасами, кабинеты для разных ролей и цифрового помощника, способного обращать внимание руководителя на важные отклонения. ТЗ получено, можно открывать редактор и работать. В начале июля стороны подписали договор, после чего команда начала готовить интервью с сотрудниками завода. Мы под микроскопом начали изучать продажи, клиентский сервис, планирование производства, снабжение, бухгалтерия, финансы и логистика. И вот тут слово «дашборд» постепенно начало уступать место слову «система». Показать цифру довольно легко, но гораздо сложнее понять, откуда она появилась, кому принадлежит и какое решение должно последовать после её изменения. Если руководитель видит рост запасов, то ему нужна связь с продажами и производственным планом. Если менеджер замечает просроченную задолженность, ему требуется список клиентов и следующее действие. Если заказ обеспечен частично, то система должна показать, какая позиция есть на складе, какая ждёт выпуска и кто отвечает за срок. Каждый новый вопрос добавлял к будущему продукту ещё один процесс. Каждый новый ответ на наши вопросы в ходе созвона добавлял к нашему продукту ещё один процесс. В какой-то момент, окинув глазами список необходимых внедрений, я понял, что одними дашбордами делу не поможешь. Мы строим полноценную ERP-систему.

Завод, который помещался в нескольких вкладках

На первых созвонах все процессы выглядели компактно. Коммерческий блок продаёт продукцию. Производство её выпускает. Склад хранит. Логистика доставляет. Финансы считают деньги. Между подразделениями работает 1С, рядом живут Excel-таблицы, а руководители хотят видеть общую картину в одном окне. Всё понятно. Можно расходиться. Именно в этот момент к нам подключился руководитель проекта и начал задавать вопросы: «Как заявка клиента попадает на завод? Кто проверяет наличие продукции? В какой момент товар резервируется? Кто обещает дату отгрузки? Что происходит при дефиците? Как заказ попадает в производственный план? Кто меняет приоритеты? Где фиксируется результат лабораторной проверки? Когда выпущенная партия становится доступной для продажи?»

С каждым новым ответом схема разрасталась. Мы, разработчики, поняли, что за короткой фразой «отгрузить заказ» скрывается отдельный сложный производственный цикл с множеством нюансов, о которых я подробно расскажу во второй статье. Внимательно слушая клиента, я представлял себе будущую базу данных. Всю цепочку рассуждений и ответов на вопросы я старательно переносил на бумагу в виде схем, чтобы не оставить ни один процесс в компании без внимания. Вадим, наш технический директор, посмотрев на мои записи, спросил: «А что здесь считается фактом?» Я уже приготовился ответить, но решил ещё немного подумать. Вопрос был прост только на первый взгляд. «Это нам еще предстоит выяснить», – ответил я.

Пять жизней одного остатка

Первым испытанием стало слово «остаток». Казалось бы, всё просто, у него нет «двойного дна». Для человека со стороны это количество товара на складе. Взяли номенклатуру, посмотрели число, вывели на экран, алгоритм простой. Поэтому я уже мысленно закрыл эту задачу для себя. Однако на заводе одно слово, например, «остаток» может иметь целых пять разных смыслов!

Есть физический остаток: продукция действительно находится на территории склада. Есть свободное количество после резервов. Есть партия, которая выпущена, но ещё проходит лабораторный контроль. Есть товар на складе ответственного хранения. Есть запас сырья, который однажды превратится в готовую продукцию. Один показатель превратился в модель принятия решений. Я записал в блокноте: «Остаток — это число плюс контекст». Однако, если учесть, что каждый интересуется остатком по-разному, ведь коммерческий директор спрашивает, сколько продукции можно продать; клиентский сервис хочет подтвердить заказ; планировщик ищет дефицит, который требуется закрыть выпуском; финансовый директор видит деньги, застывшие в запасах; собственник оценивает состояние бизнеса. Соответственно, формулировка должна измениться: «Остаток – это ответ на вопрос конкретного человека». Однажды собственник сформулировал своё ожидание от системы предельно ясно. В одном окне он хочет видеть деньги на счетах, деньги в дебиторской задолженности, деньги в сырье, деньги в готовом товаре, поступления, списания и кредиторскую задолженность. Вот и вся управленческая философия. Где деньги? В каком они состоянии? Куда движутся? Что задерживает их движение? После этой формулировки ERP стала для меня гораздо понятнее. Руководителю нужна карта денег, а система должна связать её с происходящим на предприятии.

Когда вопросы становятся частью разработки

В июле команда провела серию интервью с сотрудниками завода. Люди рассказывали о своём рабочем дне, я ожидал услышать перечень функций будущей системы. Один сотрудник начинал утро с выгрузки из 1С. Другой собирал сведения из нескольких таблиц. Третий уточнял статус заказа по телефону. Кто-то держал важные нормативы в памяти. Кто-то вручную сопоставлял названия одного клиента в разных источниках. Корпоративная архитектура оказалась шире набора программ. В неё входили файлы, переписки, устные договорённости и человеческий опыт, которые вместе создавали хрупкую, но удивительно живучую конструкцию. Руководитель проекта учил нас всегда внимательно относиться к формулировкам. Если человек говорил «обычно делаем так», следовало выяснить судьбу исключений. Если звучало «это есть в 1С», требовалось открыть конкретный отчёт и изучить состав полей. Если два подразделения использовали одинаковое слово, требовалась сверка смысла. В итоге интервью стали больше напоминать расследование. У каждого показателя появлялась биография: кто его создаёт, где он хранится, кто исправляет ошибку, кто доверяет ему и какое действие следует дальше.

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

Мой первый кризис масштаба

Примерно в этот период возникло сомнение: «Хватит ли мне опыта?» - до проекта я писал код, работал с базами данных, собирал интерфейсы. Здесь вокруг каждого технического решения существовал промышленный контекст. Ошибка в учебном проекте максимум грозила мне неудом. Ошибка в производственной системе способна исказить картину запасов, изменить приоритет выпуска или создать ложное ощущение обеспеченности заказа. Поэтому ответственность ощущалась физически. Я смотрел на схему будущей системы, где продажи соединялись со складом, склад – с производством, производство – со снабжением, а всё вместе – с финансами. Она напоминала карту метро города, в котором я оказался впервые. Причём некоторые станции ещё строились, несколько веток существовали в Excel, а расписание поездов хранилось у опытного сотрудника в голове. Хотелось быстро доказать собственную полезность: написать модуль, собрать экран, показать результат. Скорость давала знакомое чувство прогресса. Вадим предложил другой ориентир: «Сначала добейся уверенности в одном показателе, только потом добавляй следующий». Эта фраза стала для меня опорой. Большую и сложную проблему никогда не решить сложным и громоздким решением. Однако её можно решить цепочкой маленьких проверяемых решений. Масштаб остался прежним. Изменился способ смотреть на него.

Прототип как способ задавать вопросы

В начале августа мы показали рабочей группе интерфейс будущей системы. Я воспринимал прототип как раннюю версию продукта. Руководитель проекта называл его инструментом разговора. Разница между этими взглядами обнаружилась на первой же демонстрации. После того, как сотрудник видел знакомый показатель на экране, он сразу задавал точный вопрос: откуда взялась сумма, учтены ли возвраты, какой склад выбран, куда попали продажи конкретного направления, что означает цвет строки. Позднее в систему пришли реальные данные из 1С, и разговор стал ещё предметнее. Пользователи проверяли выручку, объёмы, прибыль, фильтры, менеджеров и планы. Замечания приходили почти ежедневно. Иногда коротко: «Цифры другие». Иногда с приложенным отчётом, скриншотом и пояснением. Мы оперативно находила причину, уточняли методику, пересчитывали показатель и снова показывали результат. Так происходила разработка: показали, получили замечание, нашли правило, исправили, сверили.

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

Две профессиональные оптики

В проекте у меня появились две профессиональные оптики, через которые я мог «калибровать» своё восприятие. Вадим смотрит на систему через архитектуру, качество данных, устойчивость и безопасность. Его интересует источник значения, частота обновления, поведение интеграции при сбое и воспроизводимость расчёта. Руководитель проекта смотрит через людей и управленческие решения. Его интересует, кто откроет экран, какой вопрос приведёт человека в систему, какое действие последует после увиденного, и кто отвечает за результат. Сначала эти взгляды казались разными направлениями работы. Затем они соединились. Надёжная архитектура без понятного пользовательского действия превращается в технический памятник самой себе. Удобный экран без проверяемых данных становится убедительной иллюзией. Промышленный продукт возникает в точке, где сходятся обе дисциплины. Моя роль тоже начала меняться. Я всё чаще спрашивал о происхождении данных и реже спешил предлагать готовый элемент интерфейса. Вместо одного вопроса «Как это реализовать?» появилось несколько новых: «Кто принимает решение? Какая информация ему нужна? Кто владеет этой информацией? Как проверить её достоверность? Что произойдёт после нажатия кнопки»? Похоже, именно так программист начинает становиться разработчиком продукта.

Где мы сейчас

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

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

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

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

Что команда сделала за первые два месяца

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

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

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