No-code. Чому це зручно для оптимізації ПЗ у промисловому IT

Мене звуть Ігор Алексіков, вже майже 5 років я працюю MES-консультантом в OLSOM, компанії-вендорі ПЗ для виробництва та логістики.

У цій статті я трохи розповім про MES і виробничий IT і покажу, яким чином ми використовуємо продукти, розроблені за принципом no-code для адаптації рішень під різні процеси на клієнтських заводах.

Ця стаття буде цікава для IT-інженерів-початківців, тих, хто стикається з промисловістю і хто шукає шляхи в оптимізації своєї роботи.

Основні процеси на виробництві, з якими ми працюємо

Наша MES система може покривати досить широкий спектр процесів на виробництві.

Як я вже сказав, ми працюємо на рівні MES-систем — у прошарку між стратегічним та тактичним плануванням у ERP та безпосередньо робочими станціями. Якщо коротко, то MES дозволяє в реальному часі моніторити роботу будь-яких виробничих ліній та процесів на виробництві, та майже моментально реагувати на будь-які зміни у цих процесах, а також гнучкіше планувати дії всередині заводу.

Якщо, припустимо, на стратегічному рівні (в ERP) заплановано 10К деталей, а насправді було виготовлено 8К, інформація про це та про причини невиконання плану дійде до ERP-системи зі значною затримкою при передачі звітів в електронному, а іноді навіть у паперовому вигляді . Тоді як MES-системи, інтегровані у виробничу лінію, покажуть це в ту ж секунду в режимі реального часу і «сповістять» ERP про можливі невідповідності факту та плану.

Загалом, ми покриваємо повний цикл виробництва від входу сировини на склад до послідовного відвантаження готової продукції замовнику. За допомогою цих систем забезпечується оптимальне планування, контроль виконання замовлення, зняття даних, побудова та візуалізація аналітики за різними виробничими метриками. Також у функціонал систем входить контроль роботи операторів, облік часу роботи, контроль якості, управління ремонтом, техобслуговуванням і т.д. Аж до виконання замовлення та його відвантаження.

Типові workflow на заводі з виготовлення автокомплектуючих

Основні процеси, які користуються популярністю серед наших замовників, це збирання факту про виготовлення продукції з різних виробничих агрегатів, інформації про те, за яких умов була зроблена деталь (температура всередині машини, тиск тощо). Далі — обробка цих даних та надання різних звітностей: інформація на веб-ресурсах, розсилка зацікавленим сторонам поштою, надсилання звітності до ERP-систем. Результати нашого аналізу допомагають виробничим командам правильніше планувати свої ресурси, моніторити стан системи та контролювати KPI своїх операторів.

Також ми підтримуємо складні виробничі сценарії — контроль жорсткої послідовності замовлень, де йде контроль кожної деталі: у випадку, коли на одній лінії збираються машини різних комплектацій, постачання компонентів має чітко відповідати списку, що йде по конвеєру (щоб на ваш червоний BMW зі шкіряним салоном не потрапили сині двері з текстильним).

І ще одна важлива функція: MES-системи збирають та архівують дані про так звані елементи безпеки в машинах згідно з міжнародними стандартами, щоб можна було відстежити, де були вироблені фари, крісла, як вбудовані подушки безпеки тощо.

Контрагенти та зовнішні зв’язки, з якими ми взаємодіємо (ERP, EDI)

MES-системи — проміжний шар між машинами та різним персоналом на заводі та поза ним, тому інтеграції з різними службами та сервісами заводу для нас має дуже високий пріоритет. Ми виробили свої протоколи комунікації та взаємодії з різними машинами за методами PLC, RestAPI та іншими комунікаціями. Після отримання інформації від машин, дані необхідно надсилати в ERP-системи для фінансових звітностей, тому ми підтримуємо інтеграцію в різні системи, основною є SAP.

Для обміну логістичною інформацією наш продукт добре інтегрується з EDI-системами для отримання замовлень та надсилання накладних. Це допомагає максимально уникнути паперового обороту та робить процес обміну даними миттєвим.

Коротко про принцип low code — no code

З одного боку, наша робота ґрунтується на загальних принципах, регламентах та міжнародних стандартах виробництва, з іншого боку — мені ще не доводилося зустрічати два однакових заводи, тому система має бути досить гнучкою; додайте до цього, що, як правило, великі заводи працюють у режимі 24/7, тобто все потрібно робити швидко та бажано відразу на продакшені.

Основні принципи наших рішень — це швидкість постачання. Допомога — наш продукт, який дозволяє обійтися мінімальними вміннями програмування і при цьому зробити складну логіку. Там є набір функціональних блоків, кожен із яких несе певну бізнес-цінність для виробництва. При створенні якогось процесу MES-консультант не виступає «кодером», а виступає як інженер-аналітик, який не будує щоразу новий велосипед, а використовує стандартні підходи, що забезпечують високу безпеку рішень. Це зручно, тому що якщо в якомусь модулі необхідно внести якісь зміни, це можна легко зробити без втручання і переробки побудованої логіки.

Якщо порівняти структуру блоків та код, який йому відповідає, то отримаємо приблизно таку картинку.

~ 400 рядків коду

Основні функції, які реалізовані в нашому продукті — це імпорти та експорти різних замовлень та звітностей, елементи комунікацій з різними інтерфейсами виробничих машин та БД, елементи контролю статусу продукції на всіх етапах виробництва, великий спектр перехоплень та обробок помилок під час виконання ПЗ, блоки, що відповідають за виведення інформації оператором станцій.

MES-система зазвичай попередньо збирається у лабораторії. Замість реального обладнання використовують програми-емулятори, які імітують роботу інтерфейсів з обладнанням. У цей момент відбувається складання, налагодження, відкочування, тестування різних виробничих сценаріїв.

Потім йде етап делівері чи постачання, коли система викочується у виробництво. Це може бути робота в полі безпосередньо на виробництві. Система інтегрується, налагоджується та запускається в роботу. Також процес постачання може здійснюватись віддалено.

Система стає Mission-critical Application, без якої завод вже не може повноцінно працювати. Інформаційні потоки діджиталізуються і все замикається на MES: вона стає серцем виробничого процесу.

У чому принцип виграє перед стандартним алгоритмом

Час (підготовка під клієнта, швидкість розгортання, швидкість підтримки). За рахунок стандартизації та невигадування кожного разу нового велосипеда, інженери можуть значно швидше підготувати рішення різної складності для заводу. Воно не вимагає довгих збірок при кожній найменшій зміні, завдяки чому значно зменшується цикл підтримки та виправлення багів.

Середній термін розробки та впровадження рішення — три місяці.

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

Як відбувається заміна — на ілюстрації.

Легко перевизначити логіку реєстрації виробництва, прибираючи непотрібні блоки функціоналу та додаючи нові.

У конкретному випадку для оптимізації зберігання та швидшого доступу змінився інтерфейс взаємодії з базою даних, а саме змінилася модель БД. Це видно з двох блоків, які відповідають за взаємодію із сховищем:

Через зміну параметрів виробництва замовник замовив іншу валідацію у процесі, а саме — чи не перевищило значення кількості вироблених деталей, норми виробництва деталей за один цикл роботи машини.

Навіть після викладання нової конфігурації, ми можемо швидко змінити напрямок стрілки в конфігурації, і стара логіка запрацює, як це було раніше. Часто трапляється, коли замовник вирішує тимчасово відмовитись від оновлення.

Нам дуже важливо мати можливість перемикатися на старий функціонал у разі будь-яких змін на виробництві (нагадаю, що більшість заводів, з якими ми співпрацюємо, працюють у режимі 24/7, їх процеси пов’язані з їхніми контрагентами і швидкість змін стає чи не першим параметром) .

Звичайно, без роботи з кодом компанія обійтися на може. Сценарії, продукти, алгоритми клієнтів постійно розвиваються. Тому, незважаючи на наявність блоків під найрізноманітніші завдання, все одно ми постійно стикаємося з необхідністю дописувати код, створюючи нові блоки під конкретні завдання. Таким чином, у команди RnD завжди є робота, а кожні півроку продукти мають нові релізи з новими можливостями.

Безпека. За рахунок того, що ядро (обробка логіки) та логіка розділені в окремі програмні одиниці, то при оновленні будь-яких параметрів ядра (поліпшення) нам не потрібно змінювати логіку рішення, що дозволяє не робити повного циклу тестування всіх елементів і спрощує бюрократичні процеси.

Профіль спеціаліста. Для роботи MES-консультанта не обов’язково знати якісь мови, але необхідні такі навички: швидке розуміння різних бізнес-процесів, їх аналіз та втілення їх у продукті методами алгоритмічного мислення.

При цьому одна з проблем, з якою нам доводиться боротися, коли проект переходить на етап підтримки, пов’язана саме із простотою використання системи та «людським підходом». Різні люди під те саме завдання створюють діаграми різного виду. Потім іншим MES-консультантам буває складно розібратися в чужій діаграмі, а питання дуже часто потрібно вирішити якомога оперативніше, щоб не призвести до зупинки заводу. Для вирішення цієї проблеми ми працюємо над типізацією основних сценаріїв та діаграм під них.
Найголовніша перевага цього підходу — візулізованість. В першу чергу, людина за своєю природою набагато простіше сприймає візуальні схеми, особливо якщо вони компактно і правильно відображені.

У цьому підході не потрібно тримати в розумі, в якій частині програмного коду зберігатиметься потрібна функція. Така діаграма є самодокументованою, що допомагає знайти потрібний блок та замінити його. За кожним блоком прихована велика функціональна логіка, про яку не потрібно замислюватися фахівцю під час конфігурації проекту, отже, не витрачати багато часу на побудову свого нового «велосипеда», що допомагає дотримуватись стандартності рішень.

Недолік, який важливо усунути у найближчому майбутньому, — відсутність інструменту групування блоків на діаграмі на великих проектах, якого сильно не вистачає. Тому що чим більше підприємство чи чим складніша лінія — тим більшою і складнішою буде діаграма. Крім того, величезні діаграми, які вже не влазять на один екран, виходять у старих проектах, на лініях, де було багато ітерацій, допрацювань та змін.

Безумовно, гнучкість рішення теж має свої значні переваги перед програмуванням будь-якої мови, немає необхідності збирати проекти повністю при зміні якоїсь невеликої баги. І найважливішою перевагою є те, що не потрібно в цьому випадку вивчати якісь нові мови, нові фреймворки, які щодня виходять нові, фахівцеві достатньо мати хороше алгоритмічне мислення.