Практика применения APS решений на проектах с 1С:ERP. Кейс с разработкой контрактов данных для интеграции

Меня зовут Андрей Золотокопов. Я руководитель бизнес-направления производственного планирования в компании «Адептик Плюс».

Хочу рассказать про практику применения APS-решений на проектах 1С:ERP и кейс одного из наших заказчиков.

APS-системы

Почему появилась потребность в APS-системах?

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

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

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

APS-система должна помочь убрать все простои в производстве либо наоборот их показать, чтобы можно было придумать, что с этим можно сделать.

На слайде приведен опыт одного из предприятий.

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

На слайде показаны уровни производственного планирования на предприятиях.

• Первый уровень называется S&OP, Sales and Operation Planning – это бизнес-уровень, который отвечает за все объемно-календарные планы по компании. Владельцем этого уровня является генеральный директор, который собирает за круглым столом директоров по производству, продажников и снабженцев для обсуждения производственных планов на ближайшие полтора года (обычно планирование охватывает 6 кварталов). При составлении планов они опираются на исторические данные, а их вполне может предоставить 1С:ERP – там можно проанализировать, когда и какие товары будут продаваться, где ожидаются пики продаж, и какой объем продаж можно достичь через год или к концу года. Важно, чтобы на этом уровне топ-менеджеры предприятия взяли на себя обязательство стремиться к выполнению намеченных планов.

• Следующий уровень – тактический, MPS (+MRP) . На этом уровне директор по производству берет план, который был согласован у генерального директора, приходит в цеха и пытается понять, как у него будет загружено производство в ближайшие 3-6 месяцев, чтобы составить долгосрочный план производства. Конечно, все зависит от цикла – если цикл производства продукции не умещается в 3 месяца, горизонт планирования лучше расширить до нужного размера. И раскладывая заказы, которые были спущены из отдела продаж, и понимая, что в какой-то период у цехов будет перегрузка, он старается сбалансировать этот план – может быть, где-то откорректировав даты сдачи готовой продукции. Потребителями полученного плана являются снабженцы, которые должны обеспечить производство материалами, но им иногда бывает недостаточно трехмесячного плана, так как плечо поставки, особенно каких-нибудь электронных компонентов, довольно длинное, и им нужен план подлиннее. Считать на такие горизонты точные планы со всеми технологическими ограничениями бессмысленно, потому что они станут неактуальными буквально на следующий день. Но укрупненно можно посчитать.

• Следующий уровень – оперативный. Это то, чего хочет большинство заказчиков. Они всегда приходят с проблемой: «Мы хотим, чтобы все работало как часы, все были чем-то заняты весь день». Но оперативные планы строить бессмысленно, не наведя порядок на предыдущих уровнях. И чтобы объяснить это заказчику, тратится довольно много времени. Для построения оперативного плана берется объем, который был определен на тактическом уровне (MPS) и режется по дням, учитывая переналадки и групповую обработку. Полученный план уже можно будет превратить в сменно-суточное задание для конкретных исполнителей.

Почему планирование – сложная задача?

Мы часто приводим в пример задачу коммивояжера. Там курьер должен посетить 42 города, при этом он может заезжать в каждый город только один раз и должен потратить на это наименьшее количество денег. Количество вариантов решения этой задачи написано на слайде.

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

Как из этого выкрутиться?

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

Или использовать более современные методы – роевой интеллект и мультиагентность.

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

• Кроме того, результаты таких алгоритмов будут значительно быстрее и точнее, хотя объем вычислений все равно остается значительным.

Роли ERP и APS

Для работы системы планирования нужна достоверная информация – такие данные, как:

• заказы;

• рабочие центры;

• технологии;

• запасы/поставки;

• календари работы рабочих центров.

Чтобы качественно посчитать план, все это нужно забрать из учетной системы – в России это, чаще всего, 1С. Главное, чтобы на предприятии эти данные были в нормальном состоянии, потому что часто их тоже приходится дорабатывать.

Система планирования забирает эти данные и сначала строит план производства (MPS-уровень), а потом может превратить его в график производства.

Кроме этого, APS-система может помочь с моделированием и оптимизацией. В ней можно:

• рассчитать варианты для сокращения производственного цикла и минимизации переналадок;

• проводить различные анализы – формировать отчеты для выявления узких мест и понимания, как на них повлиять.

Расскажу, почему производственное планирование реализовать на 1С сложно.

В разработке корпоративных систем есть три активно применяющиеся модели управления данными: OLTP, OLAP и недавно присоединившаяся к ним In-memory.

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

• Концепция OLAP находится в противоречии с OLTP. Вместо нормализации в ней – денормализация, вместо транзакций – пакетная загрузка. В концепции OLAP не нужно быстро и точно писать, важно лишь быстро читать.

• И третий подход – In-memory, его предложил SAP. Этот подход говорит о том, что базы данных может вообще не быть, все рассчитывается в оперативной памяти – она значительно быстрее, с ней работать легче.
  Единственная проблема – когда свет выключится, данные исчезнут. Но это пытались решить аппаратными средствами – записывали то, что находится в оперативной памяти, на жесткие диски, и присоединяли к серверам какие-то батареи, чтобы они не выключались.

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

Интеграция APS-системы с 1С:ERP УХ

Переходим к кейсу. Расскажу, как мы познакомились с заказчиком.

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

• Слева на слайде показано построение плана.

• Справа – печь и те полуфабрикаты, которые в нее загружены.

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

Заказчик – крупное российское производство, 3 производственных площадки, 4 завода. Основные задачи, которые для нас были определены на проект:

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

• Построить детальный график производства на каждом из четырех заводов.

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

• Главное условие – пользователь должен работать только в 1С:ERP УХ. Мы этого немного не ожидали. Мы хотели, чтобы все-таки оставались наши интерфейсы, так как сначала не понимали, как запихать все, что мы разработали, в 1С.

Также у заказчика были следующие проблемы:

• Организационная структура предприятия в этот период трансформировалась – происходило объединение трех заводов в единую производственно-сырьевую систему с общей и согласованной НСИ.

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

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

• Длинный цикл производства готовой продукции – до четырех месяцев.

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

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

Но мы все равно постарались сделать так, чтобы 1С стояла отдельно, а наша система была просто спрятана за ее фасадами.

В основу интеграции положена концепция веб-сервисов – не soap, а новых http-сервисов, с помощью которых мы на стороне 1С вызываем REST API, передавая данные, упакованные в JSON.

Сервер мы написали на Swagger, он же OpenAPI – этот фреймворк позволяет автоматически описывать структуру и формат данных.

На слайде показана работа этого фреймворка:

• С левой стороны на слайде – JSON, которым мы обмениваемся.

• А с правой стороны – Swagger, который удобен и понятен для чтения большинству пользователей и программистов. Здесь мы можем выполнять элементарные запросы – GET, PUT, POST.

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

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

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

Эта информация отправляется к нам. И мы уже, посчитав план, должны вернуть его обратно в 1С.

В этой задаче мы применили брокер сообщений RabbitMQ и написали к нему клиент на технологии внешних компонент Native API, чтобы не реализовывать это все через веб-сервис в 1С, который будет постоянно нас опрашивать.

Следующая задача, которую нужно было решить – это расстановка полуфабрикатов.

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

Для этой задачи мы в браузере 1С создали филиал САПРа через вызов процедур на JavaScript. Наверное, это была одна из самых сложных задач, потому что документацию к браузеру, встроенному в 1С, мы так и не нашли. Если такая документация у кого-то есть, поделитесь с нами, мы будем благодарны.

Проблемы при использовании встроенного браузера были следующие:

• Основное – это несовершенство средств отладки. Мы не понимали, как отладить тот или иной механизм.

• Нет документации по встроенному браузеру.

• Отсутствие некоторых API.

Эти проблемы мы решали упрощением стека инструментов и применением библиотек (полифилов).

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

Вопросы и ответы

На каком языке написана ваша программа?

На C#.

Вы рассказывали про OLAP, про In-memory. Что используете вы?

In-Memory. Мы все считаем в оперативной памяти и не любим заморачиваться с базами данных. Объясню почему.

Я вам показывал, что для работы нашей системы мы забираем данные из 1С. Но если хранить эти данные в базе данных, то когда в 1С изменяется или добавляется новая информация, может возникать рассогласование. Чтобы избежать этой проблемы, мы все считаем в оперативной памяти.

Но теперь если заказчику нужно моделирование с изменением каких-то параметров, и он хочет поэкспериментировать – добавить заказы либо рабочие центры с их графиками работы, эти данные будут только на нашей стороне. В основной базе 1С информация останется прежней. Т.е. в этом случае тоже встает проблема согласования. Мы-то у себя план построим, он будет хороший и красивый, а в 1С это все (рабочие центры, график работы и т.д.) нужно будет изменить отдельно. Там тоже целая работа пройдет.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART Анализ & Управление в ИТ-проектах.