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-консультантам буває складно розібратися в чужій діаграмі, а питання дуже часто потрібно вирішити якомога оперативніше, щоб не призвести до зупинки заводу. Для вирішення цієї проблеми ми працюємо над типізацією основних сценаріїв та діаграм під них.
Найголовніша перевага цього підходу — візулізованість. В першу чергу, людина за своєю природою набагато простіше сприймає візуальні схеми, особливо якщо вони компактно і правильно відображені.

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

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

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

👍ПодобаєтьсяСподобалось2
До обраногоВ обраному1
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Что это вы тут забираете хлеб у GPT-3

Сегодня попалось похожее:

Консалтерское: change management
Приходишь, бывалоча, к клиенту и слышишь от людей разные уровни дистанцирования себя от дела:

1. Хочу, чтобы все считали меня скульптором.

2. Хочу быть скульптором и ваять, ваять, ваять чего-нибудь.

3. Хочу сваять статуй Аполлона, давно уже хочу.

4. Я тут ваяю статуй Аполлона, и для этого мне нужно до темноты сегодня доколотить его левую пятку...

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

В цитате про «дистанцирование от дела» , а в треде про «дистанцирование от кода», остальное один в один )))

Просто напомню что SQL вообще тоже создавался как язык обработки данных для неспециалистов — такой себе no-code 70-x. В принципе он даже очень хорошо с этой ролью справляется уже 40 лет. Но DBA все еще есть и новые базы данных все еще появляются.

SQL вообще тоже создавался как язык обработки данных для неспециалистов

Только «неспециалист» тут означает «без PhD in Relational algebra».

такой себе no-code 70-x.

low-code :)

но не суть

А проблема в том что, по мотивам Пуанкаре: «В математике нет символов для неясных мыслей»

Компьютеры не понимают неясных мыслей — нужны люди которые могут ясно мыслить, и пояснять компьютеру, что ему делать. как в слогане IBM — Компьютер должен работать, человек — думать.

И пока компьютер не научится понимать «неясные мысли» — любые ура технологии хорошо если упрощают пояснение ему

Например развесистая IDE — упрощает кодирование, в сравнении с написанием кода в vi
GitHub Copilot, говорят, тоже

Но где технология которая избавит человека от — думать?
а именно с этим — проблема. думать надо. выходит долго. с ошибками, переделками, что опять долго.
код или блок-схемы/UML диаграмы/"no code"- нужно думать или не нужно, вот в чем Вопрос :)

И пока компьютер не научится понимать «неясные мысли» — любые ура технологии хорошо если упрощают пояснение ему

И где ты видел неясные мысли ? Как раз все наоборот. Вот например ясная мысль. Хочу чтобы комментарии в теме обновлялись асинхронно, без перегрузки страницы. ТЗ ясно сформулировано в одном предложении. А головняка разработчикам доу на месяц работы.

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

Скільки платиш?

235 грамм сыра

вот видишь #никогданебылоивотопять

Вот например ясная мысль.

а стоп а какого именно сыра? может это какой-то «сырный эквивалент»? сыркоин? и казалось бы б «ясная мысль» но вот в реализации... ))

Молодец. Подловил. Сыр Чердер, срок годности истекает на след. неделе. Условия оплаты, самовывоз из моего холодильника )

Так и написано Cherder ? O_o по ходу тебе продали сырный продукт со вкусом сыра :)

Как раз все наоборот. Вот например ясная мысль.

С черными как ночь трюфелями?

С черными как ночь трюфелями?

Скорее с молодыми опарышами

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

зацени красивое это действительно 1 (одно) предложение осталось его разобрать )) и тут внезапно...

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

лёгким движением руки и уже 8 (восемь) артефактов самого высокого уровня считая отдельно артефактами их взаимодействие что правильно и вот ты даже утверждаешь (здесь в качестве рассматриваемой гипотезы это не спор «ты утверждаешь как аргумент»)

Вот например ясная мысль.

но смотри есть «тема» и есть «страница» ага хорошо всё ясно и вот в контексте это одно и то же ж или это разное и если это разное то как оно ещё и между собой взаимодействует?

... а потом оно ещё и взаимодействует с «комментарии в теме» ))

и это крайне занимательная фишка которую видимо упускают из виду все... а вот кто эти «все» я пока не решил окончательно надо ещё разбираться ))

зацени красивое это действительно 1 (одно) предложение осталось его разобрать )) и тут внезапно...

так и я об том ;)

несколько оффтоп, да и ладно:

дайджест обсуждения в ленте gaperton
Попытки генерировать код автоматически на основе спецификации на самом деле предпринимались довольно давно. Написана спецификация на формальном или неформальном языке — в действительности не так важно.
Исторически, они были не очень успешны. Давайте выделим из них одну попытку. Это автоматическая генерация кода по UML и прочим диаграммам. Типа, ты рисуешь дизайн, а код сам меняется. Красиво и удобно. Было очень горячей темой в 2000+ году. И? Вы помните о ней? Нет?
...
... с генерацией реального кода — проблемка:
хотелка заказчика описывается 1 предложением
которое превращается в 10 предложений бизнес аналитика
которые превращаются в 100 предложений тех задания, спецификации
которые превращаются в 1000 строк программного кода
из чего напрашивается вывод, что на каждом этапе «извне» добавляется информация, отсутствующая, не описанная, и даже не упомянутая на предыдущем этапе.
Как, откуда AphaCode будет иметь на старте — всю информацию?
Как создать для него — критерии для оценки результата?
AphaZero, тот что выиграл в Го имел на старте все:
Правила игры, которые очень простые, и — однозначные критерии оценки победы
А есть так же точно описанные «правила» и «оценки» конечного кода?
Они вообще — хотя бы теоретически — возможны?
...
Генерация кода нейронными сетями — миф. Нс для классификации требуют чтобы область значений была непрерывной и гладкой. Например, в картинке 100 на 100 пикселей можно изменить любые 100 и на ней все равно будет кот.
Для областей знания, где это не так, частный случай — перевод текста, есть проблемы применения НС. Пока лучшие результаты у трансфлрмеров и сетей с вниманием, но качество все ещё низко. А генеративные НС (создающий контент) сделаны на базе классифицирующих и имеют стабильно более низкое качество чем их классифицирующий аналог. Например сеть определяющая что на фотке кот работает так же хорошо как человек на реальных фото, но очень плоха в дифферинциации реальных и нагенерированных фото на основе этой же сети. Так вот общий вывод: код это область которая ещё более требует контекста чем человеческий язык (замените 100 слов в романе Война и Мир и скорее всего суть не изменится, замените 100 операндов в сопоставимой программе и она просто не скомпилируется). И для кода пока нет диферинцируюших сетей, т.е. например НС которая говорила на сколько процентов спектр покрыта кодом. И как следствие ТЕМ более нет генеративных сетей, и пока нет предпосылок что появится.
...
Кстати, можно рассмотреть другой пример. Из микроэлектроники.
Исторически, они проектировали в вентилях, и на вход САПР-у шли диаграммы. Цифровые схемы.
Догадываетесь, что случилось дальше? Инженеры почему-то устали пырится в диаграммы, и изобрели визуально похожий на Паскаль язык описания цифровых схем Verilog. Очень похож — скорее всего, глядя на код вы если не приглядитесь, то перепутаете его с Паскалем. И с тех пор, в «схематике» никто ничего не проектирует.
Штука в том, что с текстом на формальном языке работать гораздо удобнее, чем с картинками, разного рода «псевдокодом», и прочими костылями для тех, кто плохо понимает что делает. Продуктивность выше. Его можно под контроль версий положить, например. Автоматически проверить его корректность. Не будучи долбоебом, вынести повторяющиеся куски в библиотеки, и параметризовать их, чтобы не писать одно и то же каждый раз как мартышка. И все такое прочее.
А искусственный интеллект в данном случае нужен тем, кому не хватает естественного.
...
(конец цитат)

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

P.S.
Rethinking Low-code [rus] / Тимур Шемсединов
youtu.be/vNmO0Y_LTr4

дайджест обсуждения в ленте gaperton

омг сто лет не читал балина даже не сразу вспомнил фамилию что это не гном ))

ЗЫ: ну правда он сто лет и не писал судя по жж ок потом поищу нет ли чего свежего и где

ЗЫ: о нашёл чуть по свежее medium.com/@gaperton

он самый :)

он на ФБ сейчас. да и последние годы — про политику все больше. Ярый республиканец, против всех этих леваков-демократов :)

Но, бывает, пишет иногда «по работе» :)

Ярый республиканец, против всех этих леваков-демократов :)

значит хороший человек надо снова начать читать )) тем более что

Но, бывает, пишет иногда «по работе» :)

Проблема современной разработки, что люди пишут низкоуровневый код с умным лицом. Тоесть занимаются всеми этими мапингами, подключениями. Шлют по сети пакеты сервис бас, вручную сортируют, нарезают, обновляют.
И вместо того, чтобы лить воду на жернова, нужно просто понимать. Что в следующем веке люди к твоей джаве или пхп будут относится как сейчас к ассемблеру.
Нет никакой сакральной необходимости надолбить 100500 строк кода, если задача формулируется в одно предложение. Так же как сейчас никто не долбит на ассемблере три простыни кода, чтобы показать форму с одной кнопкой.
Тебе даже там Тимур в твоем видосике дал подсказку. Что системное программирование имеет шансы выжить, с прикладным уже давно надо закруглятся, оно превратилось в театр абсурда. Слишком много ненужной лапши на типовые задачи.

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

проблема современной разработки что все попытки сделать эту разработку «высокоуровневой» упёрлись исключительно в «шаблонизаторы по готовым шаблонам»

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

Шлют по сети пакеты сервис бас, вручную сортируют, нарезают, обновляют.

в теории существует и LAMP который как раз всё это и делает и чисто технически «ставится с каропки» но другое дело что он в свою очередь предоставляет «очередного низкого уровня блоки» для вот это всё

Шлют по сети пакеты сервис бас, вручную сортируют, нарезают, обновляют.

а «высокоуровневые» снова прямо не решает

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

И вместо того, чтобы лить воду на жернова, нужно просто понимать. Что в следующем веке люди к твоей джаве или пхп будут относится как сейчас к ассемблеру.

ЗЫ: кстати таки на чистом ассемблере пишут только те кто пишет что-то под какие-нибудь сверх уникальные платформы вроде zx spectrum и на которые нет «родного» порта чистого си на котором пишут на пример ардуинки которые в свою очередь уже снова имеют всё то что ты хочешь поддержку низкого уровня

Шлют по сети пакеты сервис бас, вручную сортируют, нарезают, обновляют.

проблема тут как раз в том что придумать что-то существенно лучше чистой сишечки на своём уровне чистой ардуинки которая сишечка бы б и выступала предельно высшим язком описания спецификации «связи блоков в кучу рабочего приложения» и на своём уровне та же ж джава выступает точно таким же ж «связывающим» кроме которого пока не придумали ни чего сильно лучшего

то что и сишечка и джава может ещё и внутренности писать это уже дело десятое

проблема современной разработки что все попытки сделать эту разработку «высокоуровневой» упёрлись исключительно в «шаблонизаторы по готовым шаблонам»

С этим я даже не спорю. Всю малину испортило, что эволюция должна была пойти по стопам АОП, а пошла по стопам ООП.

Спасибо, схоронил, когда-нить посмотрю

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

ваши эти схемки потом выливаются в вот такую дикуху
64.media.tumblr.com/...​xt8KuJe1wp4jg6o1_1280.png

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

Самое сложное в NoCode и LowCode — птичий язык, которым по сути надо писать макрокоманды. Но нет кода — нет и дебага. И в результате нихрена оно не взлетает, пока не появится API чтобы управлять уже честным кодом.

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

Другими словами, это возможно. Но допиливать всё это придётся столь же сложно и долго, как развивать полноценный язык программирования. И даже если это не код, всё равно это какой-то формат документа.

Пример NoCode языка — нами всеми нетрадиционно любимый HTML, с его жирным братиком CSS. Внезапно, эволюцией CSS стал код, а эволюцией HTML — всякие JS движки, заставляющие его пахать, тратя неимоверно больше ресурсов, чем тратила бы полноценная програма. А уж отладка всего этого дерьма... это что-то. А защита от зловредов — адище даже по меркам ада.

Грубо говоря, код был бы красивым и понятным, и было бы 100500 способов его написать, если бы не ЕСЛИ. Каждая третья строчка кода — это какое-нить ЕСЛИ. То есть основная задача кода — не прописать порядок действий, а проверить овердохера всего, прежде чем что-то сдвинуть с места. Коду свойственно вырождаться в бюрократию.

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

Часовые ставки консалтеров всяких ERP такие и есть — выше в разы чем программистов.
Начинается с — вы сами можете нарисовать себе схемы, визуально.
Ну, после обучения вашего персонала у нас. за Х денех
Ну, такие как у вас процессы немного уникальны, поэтому их сложно нарисовать. Наша линия консультаций поможет. за Y денех
Ну, у вас совсем все как-то уникально. Наши два специалиста на месте у вас, все сделают. За X*Y денех
Наши специалисты не смогли сделать, потому что у вас все бизнес-процессы — нетрадиционные. Разработчики нашей платформы готовят новый релиз...

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

Жаль, что в юридических делах нельзя просто так взять и написать код, правильность которого подтверждалась бы за минуты автотестом, а баги можно было доказать, заскриншотить и воспроизвести. Я б тогда в юристы пошёл, у них ставки покруче. А меняется всё пореже. И уязвимостей 0-дневных нет. Хнык. Хнык.

Вот потому мы и пишем код

при этом, добавлю, как варивишийся в мире ERP и этом всем

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

а "

Разработчики нашей платформы готовят новый релиз...

" — это я скорее пошутил. Часто по другому.
Консалтеры SAP R/3 говорят:
измените ваши бизнес процессы так, чтобы SAP R/3 было удобно.
то есть — убейте вашу уникальность, и тогда SAP R/3 прекрасно автоматизирует ваши процессы.
(банковские программисты знают, сколько приходится поэтому писать обвешивающего ядро SAP кода. Потому что банки — тоже уникальны, несмотря на жесткое регуляторное пространство, в котором они как бизнес живут)

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

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

Но надо с ними держать ухо востро. Уметь напеть — это их просто обязательный скил.

Проблема не в уникальности бизнеса, как раз это больше вредит. Но вот адаптированность бизнеса к рыночной нише уже ВЫНУЖДАЕТ быть в чём-то уникальными. Пусть это даже 1-2% всех процессов. Но именно благодаря адаптированности эти процессы занимают 1-2% времени, там где остальным придётся потратить 100% — это и защищает его нишу.

Полезешь автоматизировать под общую гребёнку — и получишь якобы выравнивание, приведение к стандартам. На деле — вынос с рынка.

По молодости работал админом в пивной компании у дистрибьютора, и застал такое внедрение.
Присказка: Привезли КПКшки HPшные, с полной номенклатурой пива (которого половины уже нет в ассортименте). Смотрите, как называется позиция (и может называться только так, ибо базы с завода): Пиво Рогань Монастирське світле 0.5 л в пет упак.
И вот среди сотен наименований по алфавиту (включающих всё на свете, даже бокалы и рекламные листовки) агент должен найти нужное, сравнить с остатками склада и пробить количество ящиков. После сбора заказа он обязан выйти на связь (которая в те годы то ещё удовольствие) и подтвердить заказ, и если чего-то нет, то обязан согласовать это с клиентом и назвать сумму заказа.
Увертюра: КПКшки маленькие (ну сэкономили ж как могли, фрукт-фрукт, цветок-цветок, КПУ-КПК). И вот эти названия тупо не влезают по ширине экрана. И надо НАЖИМАТЬ каждую строчку, чтобы узнать какое это именно пиво, 1л или 0.5 или 0.5 в пэт или 0.5 в ящ или 2л или 1.75 или 1.5 — и так по КАЖДОЙ позиции. Разрабатывали-то прогу на тестовых данных, там всё влезало.
На сладенькое: То же самое пиво может быть просто пиво, пиво в ящике или пиво в пэт-упаковке — потому что на разных заводах по-разному фасуют и по-разному учитывают. Но с точки зрения склада это одно и то же пиво! Но теперь должно стать разным. Угадайте что будет, если 1 бутылка разбилась? Нет, теперь её нельзя заменить. И нельзя снять этот ящик с остатков даже. И он будет числиться, и его будут продавать, а потом пробивать возвратную накладную.
Вишенка на тортик: КПКшка стоила по тем временам (и по тендерам) как 2 зарплаты агента. Повреждение (поцарапать экран — говно вопрос на пластиковом резистивном сесноре, который шкрябать надо) — снимут полную сумму.

Чего хотел пользователь: Раньше это была просто строчка на бумаге «Мсв 5», и 20-30 таких строчек, часто в 1 строку — это и есть заказ. Всё, 3-5 минут. Пиво по дефолту 0.5, 5 — это ящиков. И девочка за честным компом уже по приезду агента набирала это с той же скоростью и тоже строчкой мсв 5 (каюсь, эту фичу я запрограммил), в том числе могла прямо с телефона никуда не записывая. Связь безлимитной была уже тогда.

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

Угадайте, сколько проработала эта схема в реальности. Нисколько. Чисто для имитации. Старому софту просто пришили API и он имитировал. А цены... сажали в конце месяца 2 девочек и те от балды это набирали и отсылали, потому что иначе дистрибьютора лишат скидки (которая собственно и была его наценкой, и ни копейки выше). Через квартал это отменили — но с тех мелких дистрибьютеров, кто не прислал данные, реально задним числом поснимали скидки.

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

Если бы компания не была монополистом (более 70% рынка) их бы вышвырнули пулей. А так — у них всего лишь отжали солидный кусок доли рынка, притом отжали мало того что более слабые игроки, так ещё и с более паршивым пивом.

На закусь: Позиции стали отпускаться не меньше чем ящиком или упаковкой. А львиная доля самых выгодных продаж тогда шла через ларьки и мелкие магазинчики — ибо супермаркеты сами диктовали цену, ассортимент, не давали конкурировать и имели всю продукцию конкурентов. Так вот, мелкие точки брали новое и пока плохо продающееся пиво по 5-10 бутылок в неделю. На это конечно же приходилось идти, поскольку внедрять новый товар в тесный рынок надо, и если этого не делать — дистрибьютор имел по нему план, и пиво оставалось на складе просрочкой. Лишившись возможности продвигать медленно, пивзаводы лишились возможности продвигать новое вообще. Каждое новое пиво неизменно фейлится — чисто из-за маркетинга, который положили под нож в угоду упрощению IT.

Мораль: На стороне внедрения нужен НЕ человек, хорошо знающий IT и посредственно знающий бизнес; но человек, отлично знающий бизнес, пусть даже средненько знающий IT. Пусть даже в этом случае компьютеры переработают в 3 раза, бедненькие, и не будут на самых новейших (дырявых) технологиях — зато бизнес работает надёжно, как песочные часы.

PS. А кодом там было буквально всё. Будучи формально админом, львиную долю времени я занимался чистейшим программированием. И разумеется, ничего стабильного в бизнесе не было, постоянно, каждую неделю что-то да менялось. Пока я менял вслед за этим код, всё выглядело гладенько.
Собственно, именно в это время я получил реальную экспертизу в понимании бизнес-процессов, сколько что на самом деле стоит и что ценится. И за много лет после нигде уже не было даже шанса увидеть реальные детали самому — только зная априори, что они есть, я общался с заказчиком и выяснял «мелкие» детали, которые окажут существенное влияние. И пусть даже проект разрастался с 1 месяца (предположенного наобум) до 6, с последующей поддержкой — зато он приносил прибыль, а не «неизбежные расходы».

Добро пожаловать в реальный мир! Где алгоритмом является всё, даже действия людей.

По молодости работал админом в пивной компании у дистрибьютора, и застал такое внедрение.

оно всегда такое
лет 10 из кажется 25ти я был в мире 1С. То что вы описали — обыденно, нормально.

и сейчас вот, в заказике — Volvo обновила своего клиента — который имеет средства интеграции с учетной системой диллера — и все пыхтят — прикручивая

А там проблемка — у Volvo свой взгляд на то как надо вести бизнес. А у диллеров в разных странах, и даже городах выработался свой. И их учетные системы так и настроены.
Теперь это все надо втолкнуть в Volvo VIDA

При этом, ощущения у меня от Volvo VIDA что по реализации — куски делали команды которые не общались между собой. Что снаружи — спроектировано сурово правильным энтерпрайзником, под руководствам каких-нить консалтеров с часовым ставками 500+$

Ну и сама организация перехода — прислали WSDL который не соответствует к нему же документации, оба не соответствуют примеру в Soap UI, а по факту оказалось что и Volvo VIDA работает чуть по другому.

Продакт овнера у проекта, на стороне Volvo нет! :)
Шучу, их там думаю пачка. И как получается такой бардак — мне вполне понятно. Это ж — обыденность айти проектов...
по несоответствиям даже понятна — история разработки. в каком порядке что писалось, что забывалось, что ломалось, и почему, что прикручивалось в последний момент, когда жареный петух клюнул и т.п.

Благо что мое дело — прокси SOAP сервис, а с остальным — менеджеры, механики (как пользователи Volvo VIDA), и 1Сники с бухглатерами мучатся.
Айти директор диллерской сети, который собственно постановщик задачки мне — уже просто матерится.

Мораль: На стороне внедрения нужен НЕ человек, хорошо знающий IT и посредственно знающий бизнес

Это называется
Программист с знанием домена более ценен чем программист без знания домена :)

Прикладной, ессно.
К системному программисту — другие требования

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

И не программст со знанием домена приносит прибыль, а эксперт в домене, знающий программирование. Потому что есть 100500 тыщ мильйонов способов написать код. И работать из них может очень даже любой. Но вот саму корпоративную логику писать — тут уж надо собачатинки откушать.

Проблема в другом — такому программисту сложнее менять работу, а потому он может как и получить доход выше (за счёт экспертизы), так и ниже, и просто лишиться работы — за счёт весьма узкой экспертизы, не являющейся универсальной и не имеющей ценности за пределами бизнеса. То есть это НЕрыночные отношения. Хотя теряя таких людей компания теряет не только денег раз в 50-100 больше, но и пару лет развития в конкретной области — которая может запросто стать узким горлышком и тормозить буквально всё.

Грубо говоря, потеряв продажника, можно просто взять следующего за забором. Потеряв эксперта рынка — теряешь рынок. Потому что отношения рыночные только НА рынке, но за ними стоит 99999+1 адаптация к этому самому рынку. И чем больше оборотов капитала надо для производства и продажи, в такой степени и существуют риски «узкого места». Сэкономив штуку баксов, где-то на другом конце потеряется миллиард.

и сделай им всё как надо

в смысле переписать Volvo VIDA и 1С попутно?

А смысл? Тем более что Volvo VIDA привязывается к железу, и без привязки — не будет иметь доступа к основному вольвоскому дата центру

Если они не общаются меж собой — общайся с ними ты,

А зачем мне это надо? За это ж не платят.
А если заплатят — то смешные деньги. Я этот заказик взял тоже, потому что в «саббатикал», а не ради самих денег. Он прикольный, как раз тем что написал.

Делать карьеру в дилерской сети? То есть метить на место айти директора? На кой, это административная работа

В Вольво? Та кому я там с суконным рылом нужен :) У манагеров там наверняка всяких корочек MBA на всю стену за креслом :)
И по сведениям айти директора — проект пилят «индусы», аутсорсеры. Кому там что втирать рассказывать? Им то нафик во что-то вникать?

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

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

Но — 5 миров Спольски — крутой фронтенд дев тоже не быстро сможет стать эмбедером :)

Если сравнить структуру блоков и код, который ему соответствует, то получим примерно следующую картинку.

Интересно посмотреть на pull request, если вдруг кому стрелочку перекрасить понадобиться.
На лицо того, кто это будет ревьювить, тоже интересно посмотреть.

Дививсь я на таке. Страшне місиво хml, в якому нереально розібратись і глючний редактор на основі Eclipse.

Хорошая рекламная статья. Такие же писались с 90ых всеми предлагающими услуги.
Кто имел дело с производством — знает цену этим победным докладам.

Но с производством на доу мало кто имел дело, так что сойдёт.
(свои главные вехи в этом домене — зам нач АСУ легпромовского предприятия. Рук проекта внедрения на машиностроительном предприятии, дискретно позаказный тип)

Є приклад того, що працює — AADL, Architecture Analysis & Design Language.

Формалізоване графічне представлення, і текстова Ada-подібна мова.

А те, що в статті — це 16 стрічок коду, а не 400.

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

1. Что вы предлагаете? Бизнесу нужно решать задачу а не ждать программистов
2. trends.google.com.ua/...​e?date=today 5-y&q=nocode

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

Сидят и целые отделы девочек циферки в эксельке перебивают вручную.

Новые рабочие места, меньше безработных же.
Профит

Напевно просто позабули всі про ці системи і тепер знову мода повертається

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

А это прямая обязанность разработчика.

Найкращий приклад фіаско no-code — це траєкторія розвитку Jenkins

Всі ці кнопочки і формочки і візуальні красоти розміром з долоню класні коли їх кількість не перевалює за десяток

Як казав класік, якби no-code не було, його треба було б придумати, щоб було зрозуміло чому краще no-no-code

Уровень детализации на картинках с кодом и с no code разный. Если скрыть лишние детали в коде за абстракциями то код тоже выглядит очень красиво. doZBS();

А если код еще представить как mermaid диаграмму...

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

А эмуляторы кто пишет/поддерживает?

Самое крутое в No code системах — это отладка проблем.
Когда правил больше чем на несколько страниц, это полный п-ц.

Поддерживааю!
Только без иронии.
рекордный проект был реализован (за-конфигурен) во время разговора с директором завода (прибл. 45 минут) — чел. наслушался Lean-овских концепций, и захотел «тут все прооптимизировать». к концу разговора, мы нажали кнопку «build» и запустили завод по новым правилам. директор — в ахуе, (мы в стрёме), но, тестирование показало, что все збс.
до этого я 12 лет был програмистом... могу уверенно сказать, что скорость внердрения no-code и classic-code — раз дофига :-)
ну, да... выучить «С» или Basic — заняло 2-3 недели... выучить no-code — неск. месяцев. Но, и выигриш во времени — окупается.

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

Саме тому така промисловість і випускала 4 десятиліччями вази, а Уази буханки ще й досі випускає

Не только наша промышленность так работает, он тот же Фольксваген обновляет свое производство раз в 15-20 лет, сейчас как раз у них начался переходной период. Порше ещё вообще не обновлялись. Даже на производствах где делают смартфоны, обновление происходит раз в 5-6 лет.

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

А он, скорее всего, и не попросит «с пуговицами». В industrial automation большинство как заказчиков, так и исполнителей давно пожертвовали избыточной кастомизацией и прочим индпошивом ради максимального упрощения и удешевления поддерживаемости, сопровождаемости и прочего maintainability.

Вообще low-code (не совсем уж no-code, да, но low-code) в industrial automation одержал настолько убедительную и безоговорочную победу, что даже странно, почему этот опыт не удалось распространить на другие отрасли. Историю low-code в IA неплохо было бы хотя бы изучить всем тем, кто рассказывает про «красивые сказки» и «это никогда не взлетит».

В автоматизации производства обычно все делают один раз, и так чтобы оно работало как можно дольше, подобная схема не проканает в других отраслях, потому что там всегда нужен свежак. А на производстве, даже в Европке, много где стоят железяки в лучшем случае из середины 00х. Я даже в продаже видел цементный завод, который на Виндоус XP работает, при том что собран был в 2017 году.

В industrial automation большинство как заказчиков, так и исполнителей давно пожертвовали избыточной кастомизацией и прочим индпошивом ради максимального упрощения и удешевления поддерживаемости, сопровождаемости и прочего maintainability.

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

Вообще low-code (не совсем уж no-code, да, но low-code) в industrial automation одержал настолько убедительную и безоговорочную победу

SCADA никуда не уходила и плотно сидит в индустрии, а вот no/low code я не вижу от слова совсем.

SCADA никуда не уходила и плотно сидит в индустрии, а вот no/low code я не вижу от слова совсем.

Так SCADA это и есть натуральный low-code — из всего программирования там обычно только склеивание различных частей системы не самыми большими и сложными скриптами на каком-нибудь VBA. Ну и в остальном по уровням модели CIM — level-0 устройства обычно не программируются вообще (максимум конфигурирование в графических средах); level-1 устройства программируются на 4 языках IEC-61131, из которых 3 графических. В итоге какой-то более-менее сложный текстовый код можно найти только на level-2 в матмоделях процессов и на level-3 в интеграции MES/ERP систем между собой и с level-2.

Так SCADA это и есть натуральный low-code

Ну как тебе сказать, если бы это было истинное low-code на рынке не было бы контор, которые пилять кастомные блоки для SCADA. Я только соглашусь, что убрали GUI от разработчика, а всё остальное ничуть легче не стало. Я помню, когда заказчик захотел MPEG4 IP камеры в крематории/печи по переработке мусора, тогда такого ни у кого ещё не было.

IEC-61131 працює для PLC. Коли логіка для однієї гідравлічної платформи — це ок. А коли їх кілька, скоординованих, залежних від подій, і час треба пришвидшувати чи заповільнювати — все стає не таким простим.

Хоча про що це я? Наш конфігуратор для цирку на QNX — також така собі no-code платформа. Умови і цикли додали років через десять від початку експлуатації, до того було досить послідовностей команд і правил.

Підписатись на коментарі