Управління проєктами автоматизації: ведення проєктів PLC, SCADA та систем керування від URS до введення в експлуатацію

Що таке управління проєктами автоматизації

Управління проєктами автоматизації це дисципліна планування, виконання, координації та постачання проєктів промислової автоматизації, які встановлюють, налаштовують та інтегрують системи керування (PLC, SCADA, DCS, системи безпеки) на виробничому підприємстві або технологічній установці. Вона перебуває на перетині управління інженерними проєктами, управління IT-проєктами та управління операційними проєктами, черпає з усіх трьох, але не зводиться до жодного, адже проєкти автоматизації мають власні риси, які загальні підходи до управління проєктами не покривають повністю.

Визначення та місце проєктів автоматизації

Проєкт автоматизації починається, коли виробнича організація вирішує встановити нову технологію керування або модернізувати наявні системи керування, і завершується, коли встановлена система працює безпечно й надійно у виробництві та задовольняє операційні вимоги, визначені на початку. Обсяг зазвичай охоплює вибір і закупівлю обладнання, налаштування та програмування програмного забезпечення, інтеграцію з наявними системами підприємства, випробування в кілька етапів, валідацію безпеки та кібербезпеки, навчання операторів і формальну передачу в експлуатацію. Поширені типи проєктів це greenfield-встановлення (нове підприємство, без спадщини), brownfield-модернізації (заміна застарілих систем керування на діючому підприємстві), розширення потужностей (нові виробничі лінії в наявній архітектурі автоматизації) та оновлення систем безпеки (приведення наявних встановлень до чинних норм, як-от IEC 61511 Видання 2).

Чим вони відрізняються від звичайних виробничих проєктів

Проєкт автоматизації не є звичайним виробничим проєктом, навіть якщо він відбувається в межах виробничої компанії. Чотири відмінності вирішальні. Перша: результат це система, а не продукт: отримують працездатну архітектуру автоматизації, а не окремий готовий до продажу продукт, тож критерії успіху стосуються експлуатаційних показників, а не характеристик продукту. Друга: робота міждисциплінарна за своєю природою так, як звичайні виробничі проєкти не є: механіка, електрика, програмне забезпечення керування, IT-інфраструктура та інженерія процесу мають зійтися до однієї дати встановлення, часто з різними підрядниками, відповідальними за різні дисципліни. Третя: порядок валідації обов’язковий і незворотний: FAT перед SAT перед введенням в експлуатацію, без можливих скорочень, бо фізичні залежності нав’язують послідовність. Четверта: вимоги безпеки та відповідності часто несуть регуляторну вагу, з якою загальні виробничі проєкти не стикаються з тією самою інтенсивністю, від норм функційної безпеки до вимог кібербезпеки та галузевих регламентів.

Чим вони відрізняються від IT-проєктів

Інколи проєкти автоматизації помилково ведуть як IT-проєкти, бо обидва містять програмне забезпечення. Відмінності значні. IT-проєкти зазвичай дозволяють ітеративне розгортання, поетапний вихід для підмножин користувачів і швидкі виправлення після випуску. Проєкти автоматизації розгортаються на фізичній установці, де програмне забезпечення керує фізичними процесами з реальними наслідками: гаряче виправлення PLC у хімічному реакторі це не той самий тип зміни, що виправлення вебзастосунку. IT-проєкти можна призупинити; діючі установки часто ні. Провал IT-проєкту зазвичай спричиняє втрату даних або незручність для користувача; провал проєкту автоматизації може спричинити інциденти безпеки, викиди в довкілля або порушення регламентів. Саме тому існує дисципліна FAT-SAT-введення в експлуатацію і саме тому її скорочення породжує дорогі наслідки, які менеджери IT-проєктів на початку можуть не розпізнати.

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

Проєкти автоматизації дотримуються усталеної структури із шести фаз, яка стала стандартом у всіх галузях: хімія, фармацевтика, харчова промисловість і напої, енергетика та загальне виробництво. Фази такі: специфікація вимог користувача (URS), специфікація функціонального та детального проєктування (FDS, DDS), інженерія та будівництво, приймальні випробування на заводі (FAT), встановлення та приймальні випробування на об’єкті (SAT), і введення в експлуатацію. Кожна фаза має визначені входи, виходи та критерії гейтів, а дисципліна дотримання критеріїв гейтів між фазами відокремлює проєкти автоматизації, здані вчасно, від тих, що вичерпують бюджет на пізні переробки.

Фаза 1: специфікація вимог користувача (URS)

URS визначає, чого система автоматизації має досягти з операційного погляду: цільова продуктивність виробництва, специфікації продукту, філософія керування, вимоги безпеки, регуляторні обмеження, очікування щодо інтерфейсу оператора та точки інтеграції з наявними системами підприємства й корпоративним IT. Добре написаний URS, подібно до статуту проєкту, функційний, а не технічний: він описує бажаний результат, не приписуючи технічного рішення. Якість URS це найкращий окремий предиктор результатів проєкту автоматизації, бо кожна наступна фаза успадковує неоднозначність або повноту цього документа. Проєкти, які пропускають URS або трактують його як формальність, раз за разом виявляють на SAT або на введенні в експлуатацію, що різні зацікавлені сторони мали різні припущення щодо базових функцій, і на цьому етапі вартість узгодження на порядки вища, ніж була б на фазі URS.

Фаза 2: специфікація функціонального та детального проєктування (FDS, DDS)

FDS перекладає URS у функційне проєктування: який PLC, який SCADA, яка топологія мережі, які контури регулювання, які функції безпеки, які сигналізації і як вони пов’язані між собою та з інфраструктурою підприємства. DDS далі спускається до рівня технічної деталізації, потрібного для інженерії та закупівлі: конкретні моделі обладнання, підрахунки входів/виходів, схеми монтажу, компонування шаф, архітектура програмного забезпечення, макети екранів HMI. Фази FDS і DDS охоплюють огляди проєктування з клієнтом, а затвердження наприкінці DDS це еквівалент заморожування проєктування проєкту автоматизації. Зміни після цієї точки потребують формального управління змінами і зазвичай подовжують графік.

Фаза 3: інженерія та будівництво

Інженерія та будівництво охоплюють закупівлю обладнання, збирання шаф, розробку програмного забезпечення (код PLC, екрани SCADA, логіка безпеки, налаштування historian), встановлення мережевої інфраструктури та механічний і електричний монтаж на об’єкті. Ця фаза відбувається паралельно між кількома дисциплінами та постачальниками, і саме тут міждисциплінарна координація споживає більшу частину уваги менеджера проєкту. Компоненти з тривалим терміном постачання, визначені під час FDS (спеціальні прилади, сертифіковані з безпеки контролери, спеціалізоване мережеве обладнання), мають бути замовлені достатньо рано, щоб інженерія просувалася без очікування обладнання. Розробка програмного забезпечення для PLC і SCADA зазвичай виконується після DDS, паралельно із закупівлею обладнання, щоб обидва були готові разом до FAT.

Фаза 4: приймальні випробування на заводі (FAT)

FAT відбувається на майданчику постачальника або інтегратора, перед відправленням на об’єкт. Повну систему керування (обладнання PLC, програмне забезпечення SCADA, системи безпеки) збирають і випробовують у контрольованому середовищі з імітованими входами й виходами. FAT валідує, що обладнання відповідає DDS, що програмне забезпечення правильно реалізує функційну логіку, що сигналізації та блокування поводяться як спроєктовано, що екрани HMI показують визначену інформацію і що інтеграція між підсистемами працює. FAT це остання економічно вигідна нагода виявити дефекти: виправлення на FAT коштують приблизно вдесятеро менше за ті самі виправлення на SAT і у сто разів менше за дефекти, виявлені на введенні в експлуатацію. Пропуск або скорочення FAT це найпоширеніша окрема причина дорогих перевитрат в автоматизації.

Фаза 5: встановлення та приймальні випробування на об’єкті (SAT)

Після затвердження FAT систему відправляють на об’єкт, встановлюють механічні та електричні підрядники, і вона проходить SAT. SAT перевіряє, що встановлення відповідає кресленням, що фізичні входи/виходи правильно з’єднані з приладами та виконавчими механізмами, що інтеграція з наявними системами підприємства працює як спроєктовано і що наскрізні функційні випробування проходять у реальних умовах встановлення. Для проєктів SCADA та безперервного процесу SAT часто охоплює подовжений прогін від одного до двох тижнів, щоб довести стабільну роботу без значних проблем. Коли кілька підсистем від різних постачальників треба випробувати разом, після окремих SAT проводять інтеграційні випробування на об’єкті (SIT), формально запроваджені в IEC 62381:2024, щоб довести інтегровану роботу.

Фаза 6: введення в експлуатацію

На введенні в експлуатацію валідовану систему переводять у діюче виробництво. Холодне введення в експлуатацію випробовує системи без технологічного матеріалу або з нешкідливими середовищами. Гаряче введення в експлуатацію поступово вводить реальний технологічний матеріал, з налаштуванням контурів регулювання та послідовностей і оптимізацією до цільових показників. Введення в експлуатацію завершується формальною передачею в експлуатацію, яка потребує завершеного навчання операторів, постачання документації (виконавчі креслення, посібники з експлуатації, інструкції з обслуговування), наявності запасних частин і виконання погоджених критеріїв приймання. Періоди підтримки після введення в експлуатацію (зазвичай від 30 до 90 днів) дозволяють інтегратору усунути проблеми, які виникають лише в реальних умовах виробництва.

Хребет валідації: FAT, SAT, SIT і введення в експлуатацію

Етапи валідації між завершенням інженерії та початком стабільного виробництва становлять дисципліну, що визначає управління проєктами автоматизації. Їхній порядок обов’язковий і його не можна скоротити: обладнання та програмне забезпечення спершу мають бути валідовані в контрольованому середовищі (FAT), потім перевірені у встановленому середовищі (SAT), потім інтегровані із сусідніми підсистемами (SIT) і зрештою доведені в реальних умовах процесу (введення в експлуатацію). Кожен етап має відмінні цілі, відмінні критерії приймання та радикально відмінну економіку виявлення й виправлення дефектів.

FAT: виявити дефекти в найдешевшій точці

Приймальні випробування на заводі відбуваються на майданчику постачальника, у присутності клієнта або незалежного інспектора. Повну систему керування, або функційно повну підмножину, збирають на випробувальному стенді постачальника й випробовують проти імітованого середовища підприємства із симуляторами входів/виходів, стимуляцією HMI та сценаріями функційних випробувань, похідними від FDS. Типовий обсяг FAT охоплює перевірку входів/виходів і перевірку контурів (кожен канал входу й виходу працює і правильно призначений), випробування логіки керування та функцій (блокування, дозволи, сигналізації, послідовності, валідовані проти P&ID і функційної специфікації), огляд обладнання та монтажу (розміри шаф, маркування провідників, заземлення, монтаж компонентів), перевірки калібрування та приладів і валідацію кібербезпеки для систем, під’єднаних до мережі. Належно проведений FAT зазвичай триває від одного до п’яти днів на майданчику постачальника, залежно від складності системи. Економічна причина ретельного FAT очевидна: виправити дефект на заводі зазвичай коштує на порядки менше, ніж у полі, бо виправлення на заводі не впливає на графік підприємства, не породжує логістичних витрат об’єкта, не перериває експлуатації та не потребує повторної мобілізації бригад.

SAT: перевірити реальне встановлення та інтеграцію

Приймальні випробування на об’єкті відбуваються після встановлення на майданчику клієнта. Вони підтверджують, що встановлення відповідає кресленням, що фізичні входи/виходи правильно з’єднані з приладами та виконавчими механізмами на реальному підприємстві, що інтеграція з наявними системами підприємства (процеси вище й нижче за потоком, інтерфейси MES, ERP) працює як спроєктовано і що наскрізні функційні випробування проходять у реальних умовах встановлення. SAT часто виявляє проблеми, які FAT не міг вловити: неправильно змонтовані прилади, помилкові налаштування польових пристроїв, розбіжності інтеграції зі спадковими системами, електромагнітні завади від сусідніх установок. Для встановлень SCADA та безперервного процесу SAT зазвичай охоплює подовжений прогін стабільності від одного до двох тижнів, щоб довести, що система працює безперервно без значних проблем. Затвердження SAT це гейт до введення в експлуатацію.

SIT: інтегрувати кілька підсистем

Сучасні промислові установки рідко спираються на єдину платформу автоматизації. Типова технологічна установка інтегрує кілька PLC, контролери DCS, системи безпеки, системи виявлення пожежі та газу, пакетні блоки, центри керування двигунами, частотні перетворювачі, аналізатори, системи електричного захисту, historian, системи управління активами та робочі місця операторів, часто від різних постачальників. Кожна підсистема може пройти FAT і SAT окремо, але щойно системи починають обмінюватися реальними технологічними даними, часто виникають проблеми інтеграції. Інтеграційні випробування на об’єкті (SIT), формально запроваджені як стандартний етап в IEC 62381:2024, випробовують усі підсистеми автоматизації, що діють разом як єдине рішення керування процесом. SIT це належна відповідь на складність кількох постачальників, з якою окремі FAT і SAT не можуть упоратися.

Введення в експлуатацію: довести готовність до виробництва

Введення в експлуатацію переводить валідовану систему в діюче виробництво. Холодне введення в експлуатацію перевіряє систему без технологічного матеріалу або з нешкідливими імітантами: насоси працюють, клапани маневрують, послідовності виконуються, сигналізації спрацьовують, але жоден продукт не під загрозою. Гаряче введення в експлуатацію поступово вводить реальний технологічний матеріал, налаштовує контури регулювання (параметри PID, каскадні конфігурації, попереднє керування) і оптимізує послідовності (рецепти партій, процедури пуску та зупину) до цільових показників. Введення в експлуатацію це момент, коли стає видимою накопичена якість URS, FDS, інженерії, FAT і SAT: проєкт, який добре зробив попередні фази, вводять в експлуатацію за дні чи тижні, тоді як проєкт, який пропустив або скоротив попередні фази, може провести місяці на введенні в експлуатацію, розв’язуючи проблеми, які мали б бути виявлені раніше.

Міждисциплінарна координація в проєктах автоматизації

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

Механічна інженерія та будівництво

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

Електрична інженерія та встановлення

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

Інженерія та інтеграція системи керування

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

Інженерія мереж IT та OT

Сучасні системи автоматизації інтегровані в мережу і потребують власної мережевої інфраструктури, відокремленої від корпоративного IT, з визначеними інтерфейсами там, де вони перетинаються. Інженерія мереж IT/OT охоплює архітектуру мережі керування (зазвичай варіанти промислового Ethernet), сегментацію між зоною керування та корпоративною, заходи кібербезпеки згідно з IEC 62443, політики віддаленого доступу та інтеграцію з historian підприємства й системами MES. Інженери IT/OT історично залишалися поза проєктами автоматизації і залучалися пізно, але сучасні проєкти виграють від їхнього долучення із самого URS, бо рішення щодо мережі впливають на фізичне проєктування шаф і прокладання кабелів.

Інженерія процесу та експлуатація

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

Поширені пастки в проєктах автоматизації

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

Недостатньо специфікований URS, переданий в інженерію

Перший шаблон це трактування URS як ранньої формальності замість фундаменту, на якому тримається весь проєкт. URS складають нашвидкуруч, щоб розблокувати інженерію, неоднозначності лишаються в документі з припущенням, що їх з’ясують пізніше, і інженерія просувається проти погано визначеного набору вимог. Наслідки виявляються на SAT і на введенні в експлуатацію: експлуатація виявляє, що система не робить чогось, що вважалося само собою зрозумілим, або робить те, чого ніколи не хотіли, і виправлення потребує перепроєктування, якому надійний URS запобіг би. Контрзахід це вкласти календарний час у ретельний URS з явним затвердженням зацікавлених сторін і визначеними критеріями приймання перед початком інженерії, навіть якщо це наче затримує проєкт.

Скорочений або пропущений FAT

Другий шаблон це трактування FAT як необов’язкового кроку, який можна скоротити, коли графік під тиском. Постачальник завершив програмне забезпечення й обладнання зібрано, але клієнт вирішує, що FAT непотрібний, бо постачальник добре випробовує всередині, або що FAT можна звести до демонстрації замість повного функційного випробування. Наслідки з’являються на SAT і на введенні в експлуатацію, де кожен дефект, який FAT перехопив би, тепер коштує від десяти до ста разів більше на виправлення. Контрзахід це трактувати FAT як такий, що не підлягає обговоренню, незалежно від тиску термінів, і структурувати обсяг FAT настільки конкретно, щоб демонстрація не могла зійти за випробування.

Прогалини в координації кількох постачальників без SIT

Третій шаблон це припущення, що окремих FAT і SAT постачальників достатньо, коли кілька підсистем мають працювати разом. Система кожного постачальника проходить власні випробування, але інтерфейси між системами не були валідовані спільно, і проблеми інтеграції виникають під час введення в експлуатацію, коли їхнє розв’язання найдорожче. Контрзахід це запланувати явні інтеграційні випробування на об’єкті, коли проєкт охоплює кілька підсистем від різних постачальників, і визначити обсяг SIT ще під час URS, щоб постачальники знали, що вони контрактно зобов’язані брати участь в інтегрованих випробуваннях, а не лише валідувати власну підсистему.

Затримки сусідніх дисциплін, що переливаються на автоматизацію

Четвертий шаблон це трактування тривалості проєкту автоматизації так, ніби вона незалежна від інших дисциплін на об’єкті. Механічне будівництво затримується, електричне встановлення затримується, і команда автоматизації прибуває, щоб почати SAT, лише щоб виявити, що підприємство не готове її прийняти. Графіки команди автоматизації зазвичай не можуть зсунутися в тому самому напрямку, бо вікна введення в експлуатацію прив’язані до зупинок підприємства або вікон пуску, зафіксованих задовго наперед. Контрзахід це явно інтегрувати графіки проєкту автоматизації з механічним та електричним графіками, з віхами готовності кожної дисципліни до робіт з автоматизації і з тригерами ескалації, коли дисципліна зсувається за межі запасу.

Відкладена валідація безпеки та кібербезпеки

П’ятий шаблон це трактування випробувань функційної безпеки та валідації кібербезпеки як церемоніальних заходів наприкінці замість безперервних потоків робіт упродовж усього проєкту. Функції безпеки потребують валідації проти специфікації вимог безпеки протягом усього життєвого циклу, від проєктування через FAT і SAT до введення в експлуатацію, а кібербезпека згідно з IEC 62443 так само потребує заходів на етапі проєктування замість аудиту наприкінці проєкту. Контрзахід це визначити потоки робіт безпеки та кібербезпеки з явними результатами на фазу, забезпечити їх ресурсами окремо від функційних випробувань і трактувати приймання безпеки та кібербезпеки як власні гейти замість пунктів загального переліку приймання.

Безпека та відповідність у проєктах автоматизації

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

Функційна безпека згідно з IEC 61511 та IEC 61508

Системи безпеки в процесній промисловості дотримуються IEC 61511 (з IEC 61508 як базовою нормою). Вимоги життєвого циклу охоплюють аналіз небезпек і ризиків, призначення функцій безпеки інструментальним функціям безпеки (SIF) з рівнями повноти безпеки (SIL), специфікацію вимог безпеки, проєктування та інженерію з перевіркою SIL, валідацію під час встановлення та введення в експлуатацію і процедури експлуатації та обслуговування. Безпеку не можна додати на введенні в експлуатацію; вона має бути присутня в кожній фазі. Проєкти автоматизації, які трактують безпеку як власний потік робіт із самого URS, виробляють готові до аудиту докази як природний результат проєкту, тоді як проєкти, які трактують безпеку як завершальний захід приймання, зазвичай пізно виявляють, що прогалини документації або проблеми проєктування потребують переробки.

Кібербезпека згідно з IEC 62443

Промислові системи автоматизації та керування стикаються з загрозами кібербезпеки, які рамки IT-безпеки не покривають повністю. IEC 62443 визначає вимоги кібербезпеки для промислової автоматизації, зокрема сегментацію мережі між зонами IT та OT, безпечний віддалений доступ, управління оновленнями систем керування, журналювання подій безпеки та управління вразливостями. Вимоги кібербезпеки треба визначити під час URS і перенести у FDS, DDS та інженерію. Додавати кібербезпеку на введенні в експлуатацію дорого і рідко дає задовільні результати, бо фундаментальні рішення архітектури вже ухвалені.

Галузеві регламенти

Різні промислові галузі додають проєктам автоматизації специфічні вимоги відповідності. Фармацевтичні проєкти та проєкти наук про життя дотримуються Додатка 15 GMP ЄС, який прямо визнає роль FAT і SAT у кваліфікації та вимагає задокументованих доказів критичної приладовості, калібрування та перевірки процесу. FDA 21 CFR Part 11 застосовується до електронних записів і підписів у науках про життя. Проєкти харчової промисловості та напоїв дотримуються принципів HACCP з галузевими нормами гігієнічного проєктування та простежуваності. Проєкти енергетики та комунальних послуг дотримуються NERC CIP щодо кібербезпеки мережі. Проєкти загальної промисловості потребують доказу маркування CE та відповідних норм ISO щодо безпеки, показників і технічних специфікацій. Вимоги галузі треба визначити під час URS, а графік проєкту має враховувати заходи аудиту та документації, які вони накладають.

Керування кількома проєктами автоматизації на рівні портфеля

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

Інформаційна панель портфеля проєктів автоматизації

Інформаційна панель портфеля проєктів автоматизації показує всі активні проєкти, класифіковані за фазою (URS, FDS, інженерія, FAT, SAT, введення в експлуатацію), з видимістю того, які проєкти наближаються до оглядів гейтів, які заблоковані і скільки їх на кожній фазі. Панель розкриває шаблони, які приховують перспективи окремого проєкту: систематичні вузькі місця в плануванні FAT з тим самим інтегратором, вікна введення в експлуатацію, що скупчуються у вузьких смугах календаря, змагання за ресурси на спеціалізованих компетенціях, як-от програмування систем безпеки. Розпізнавання шаблонів на рівні портфеля живить системне вдосконалення замість реактивного гасіння пожеж від проєкту до проєкту.

Змагання за ресурси на спеціалізованих компетенціях

Проєкти автоматизації залежать від спеціалізованих компетенцій, часто дефіцитних: програмісти систем безпеки, фахівці з кібербезпеки, мережеві архітектори, експерти з певних платформ PLC, інженери введення в експлуатацію з галузевим досвідом. Спільні ресурси стають найбільшим джерелом незапланованих затримок у портфелі з кількох проєктів. Змагання за ресурси, невидиме на рівні проєкту, стає видимим на рівні портфеля, де той самий фахівець, що з’являється водночас у кількох графіках проєктів, викриває подвійне бронювання, яке окремі менеджери проєктів не можуть побачити. Ефективне управління портфелем рано виявляє ці вузькі місця і або додає потужність, або впорядковує проєкти, щоб зменшити змагання, або приймає затримки як видимі рішення портфеля.

Стандартизація між проєктами

Зрілі портфелі проєктів автоматизації стандартизують повторювані елементи: шаблони URS за типом проєкту, структури FDS, формати сценаріїв випробувань FAT, критерії приймання SAT, контрольні переліки введення в експлуатацію, шаблони документації безпеки, процедури оцінки кібербезпеки. Стандартизація уникає повторного винаходу рутинних елементів у кожному проєкті і вивільняє інженерну увагу для частин, які справді різняться. Стандартизація також уможливлює навчання між проєктами: шаблон дефекту, виявлений на FAT одного проєкту, оновлює шаблони, тож наступні проєкти перехоплюють той самий клас дефектів раніше. Інженерні компанії зі зрілою стандартизацією постачають проєкти швидше і з меншою мінливістю, ніж компанії, де кожен проєкт заново винаходить власний підхід.

Планування потужності та рішення щодо тендерів на рівні портфеля

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

Кейс A: Smart Automation, дисципліноване виконання портфеля

Smart Automation це інженерна компанія з Ольштина, Польща, що діє у промисловій автоматизації з 2009 року. Компанія проєктує та постачає повні системи автоматизації, від концепцій машин і аналізів здійсненності до програмування систем керування та систем машинного зору, через роботизовану автоматизацію процесів і будівництво спеціалізованих машин. Досвід команди сумарно перевищує 300 років в автоматизації, робототехніці та мехатроніці. Компанія завершила понад 1000 проєктів для клієнтів, таких як IKEA, Michelin, Siemens Energy, Unilever і Danone, що на практиці означає кілька десятків одночасних проєктів у будь-який момент, різних за обсягом, складністю та розташуванням.

Відправна точка перед упровадженням FlexiProject була знайомою інженерним компаніям: бюджети вели в рішеннях навколо системи ERP, бо саме там перебувають рахунки, платежі та витрати, але кожен менеджер проєкту виробив особистий підхід до фінансового контролю. Інструментів планування графіка, моніторингу ризиків і планування ресурсів по суті бракувало. Не було повного бачення жодного окремого проєкту, а тим паче всього портфеля. Компанія вирішила шукати виділену систему управління проєктами, яка поєднала б графіки, бюджети, ризики та ресурси в одному місці і стала б єдиним джерелом інформації про проєкти.

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

Дані бюджету мали лишатися узгодженими із системою ERP, тож FlexiProject інтегрували з ERP так, щоб інформація про витрати переходила між системами без подвійного введення. Поза проєктами гнучка структура дозволила відобразити процес тендерів і гарантійний та післягарантійний сервіс. Два чинники рухали прийняття. По-перше, генеральний директор діяв як активний спонсор проєкту, послідовно вимагаючи, щоб уся інформація про проєкт жила в одній системі, і очікуючи регулярних оновлень від кожного менеджера проєкту. По-друге, бар’єр входу був низьким: будувати графіки та бюджети було достатньо інтуїтивно, щоб будь-який менеджер проєкту, незалежно від досвіду, міг почати навчання, вносячи власний реальний проєкт, а не вправляючись на штучних прикладах. Результати видно в рішеннях: відхилення бюджету з прогнозом до завершення, використання ресурсів як вхід для рішень щодо тендерів і планів найму, огляди проєктів кожні два тижні для активних проєктів і щомісяця для проєктів на фазі планування, усе на основі даних у системі, а не презентацій, зроблених вручну.

Кейс B: криза автоматизації Model 3 від Tesla, 2017-2018

Нарощування виробництва Model 3 від Tesla між 2017 і 2018 роками це один з найкраще задокументованих публічно провалів проєкту автоматизації в промисловій історії, незвичний через готовність Ілона Маска визнати його власними словами. Model 3 оголосили у 2016 році як перший масовий автомобіль Tesla, з цільовою ціною 35 000 USD, і за 24 години після запуску 115 000 осіб зробили бронювання. Tesla поставила собі амбітну ціль виробляти 5000 Model 3 на тиждень до кінця 2017 року і дотримувалася підходу, який Маск згодом опише як «автоматизувати все», роблячи ставку на те, що масштабна автоматизація уможливить обсяг, потрібний для опрацювання накопичення передзамовлень.

Результатом стало те, що сам Маск назвав «пеклом виробництва». Tesla зі значним відривом не досягла цілі кінця 2017 року і виробила 2425 Model 3 за весь четвертий квартал 2017 року (проти цілі 5000 на тиждень). Переглянуту ціль на кінець першого кварталу 2018 року, 2500 на тиждень, теж не досягли, і Tesla вийшла на 2020 в останній тиждень першого кварталу. І складання батарейних модулів на Gigafactory, і кінцева складальна лінія у Фрімонті мали проєкти автоматизації, які виявилися ненадійними на виробничому обсязі. Аналітики Bernstein публічно доводили, що переавтоматизація вкарбувала помилки Tesla у виробничу лінію і коштувала більше, ніж принесла. 13 квітня 2018 року Маск публічно визнав у Twitter: «Так, надмірна автоматизація в Tesla була помилкою. Точніше, моєю помилкою. Людей недооцінюють.» В інтерв’ю CBS він описав демонтаж «божевільної складної мережі конвеєрів», яка не працювала, і Tesla зрештою повернула частини складальної лінії до ручної роботи, зокрема відому тимчасову складальну лінію під «наметом» у Фрімонті, яка додала потужність ручною працею замість подальшої автоматизації.

Три уроки прямо переносяться на будь-який проєкт автоматизації. Перший: амбіція автоматизувати без пілотної валідації примножує ризик замість зменшувати його: рішення Tesla розгорнути нову автоматизацію у виробничому масштабі, перш ніж валідувати її на пілотному обсязі, примножило складність кожного наступного циклу розв’язання проблем, тоді як поступове нарощування розкрило б проблеми автоматизації за меншу вартість. Другий: переавтоматизація кроків підскладання, що потребують адаптивності, дає гірші результати, ніж напівавтоматизовані альтернативи, де люди беруть на себе варіацію, а машини повторювану роботу: це відомий принцип японської виробничої практики, який Tesla фактично перевідкрила під тиском виробництва. Третій: зобов’язання щодо графіка проєкту, які припускають, що технологія працюватиме як задумано, без достатнього запасу графіка для розкриття проблем автоматизації, породжують тиск, що робить дисципліноване розв’язання проблем радше складнішим, ніж легшим. Tesla зрештою досягла цілі 5000 на тиждень до кінця червня 2018 року і більш ніж подвоїла загальний випуск 2017 року, але ціна досягнення цього через кризу замість дисциплінованого поступового нарощування була значною.

Як FlexiProject підтримує проєкти автоматизації

FlexiProject підтримує рівень виконання управління проєктами автоматизації з видимістю портфеля, управлінням графіком, відстеженням ризиків, структурованими оглядами та стандартизованими шаблонами. Міждисциплінарна координація проєктів автоматизації, зокрема робота з узгодження функцій механіки, електрики, керування, IT/OT та інженерії процесу, залишається відповідальністю організації. FlexiProject надає операційну інфраструктуру, яка робить керованим дисципліноване виконання проєктів автоматизації у великому масштабі, а не замінник інженерної співпраці, від якої залежить успіх проєкту автоматизації.

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

FlexiProject пропонує інформаційну панель портфеля, яка показує всі активні проєкти автоматизації в одному поданні, класифіковані за фазою (URS, FDS, інженерія, FAT, SAT, введення в експлуатацію) та за клієнтом чи бізнес-підрозділом, з видимістю того, які проєкти наближаються до оглядів гейтів і які заблоковані. Перспектива портфеля виносить на світло шаблони, які приховують подання окремого проєкту, як-от вікна введення в експлуатацію, що скупчуються у вузьких смугах календаря, змагання за ресурси на спеціалізованих компетенціях і систематичні затримки в плануванні FAT з певними інтеграторами. Керівні комітети, які ухвалюють рішення на рівні портфеля, працюють з тієї самої перспективи портфеля, замість узгоджувати окремі звіти проєктів.

Графік з діаграмою Ганта, переліком завдань і канбаном

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

Реєстр ризиків, пов’язаний з фазами проєкту

Реєстр ризиків у FlexiProject відстежує властиві автоматизації ризики з відповідальними, планами пом’якшення та ритмом перегляду. Властиві кожній фазі ризики (доступність компонентів з тривалим терміном постачання під час інженерії, готовність постачальника до FAT, готовність об’єкта до SAT, доступність підприємства для введення в експлуатацію, валідація системи безпеки, оцінка кібербезпеки) пов’язані з відповідними віхами фаз і переглядаються на відповідному гейті. Зв’язок між ризиками, завданнями та графіком означає, що ризик, який матеріалізується, видимо позначається на пов’язаному терміні, замість лишатися в окремому реєстрі, куди ніхто не заглядає під час рішень щодо термінів.

Огляди проєктів як огляди гейтів

Огляди проєктів у FlexiProject можна структурувати як формальні огляди гейтів проєктів автоматизації, з визначеними критеріями, структурованим поданням доказів і формальними рішеннями продовжувати чи не продовжувати, зафіксованими в протоколі проєкту. Ритм перегляду плановий (зазвичай наприкінці кожної фази проєкту і на кожному переході FAT/SAT/введення в експлуатацію), а результати оглядів живлять стандартизовані шаблони наступних проєктів. Критерії гейтів, налаштовані в шаблонах, застосовуються послідовно між проєктами того самого типу, тож гейт затвердження FAT одного проєкту використовує ту саму структуру критеріїв, що й гейт затвердження FAT іншого.

Стандартизовані шаблони для проєктів автоматизації

FlexiProject пропонує стандартизовані шаблони для повторюваної структури проєктів автоматизації, з моделлю шести фаз, хребтом валідації FAT-SAT-введення в експлуатацію, стандартними результатами на фазу і стандартними критеріями гейтів, придатними для автоматизації. Інженерні компанії можуть розширювати шаблони відповідно до особливостей типу проєкту (greenfield, brownfield-модернізація, розширення потужностей, оновлення безпеки), не відмовляючись від базової структури. Управління проєктами автоматизації на основі шаблонів діє як цифровий еквівалент стандартизованої інженерної практики: воно уникає повторного винаходу рутинних елементів проєкту і вивільняє інженерну увагу для частин кожного проєкту, які справді різняться.

Чого FlexiProject не робить

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

Поширені запитання

Чим управління проєктами автоматизації відрізняється від загального управління проєктами?

Загальні принципи управління проєктами застосовні до проєктів автоматизації, але ці проєкти мають власні риси, які загальні підходи не покривають повністю: обов’язковий послідовний хребет валідації (FAT перед SAT перед введенням в експлуатацію), притаманна міждисциплінарна складність, що охоплює механіку, електрику, програмне забезпечення керування, IT/OT та інженерію процесу, вимоги безпеки та відповідності з регуляторною вагою, і залежність від кількох зовнішніх постачальників, чиї затримки поширюються непередбачувано. Менеджери проєктів автоматизації зазвичай мають інженерну освіту та специфічний галузевий досвід, бо технічний зміст рішень впливає на результати проєкту на рівні, який загальне управління проєктами не може замінити.

Скільки триває типовий проєкт автоматизації?

Це залежить від обсягу, складності та галузі. Просте greenfield-встановлення з обмеженою інтеграцією може завершитися за шість-дев’ять місяців. Типова brownfield-модернізація з інтеграцією в наявні системи підприємства зазвичай триває від дванадцяти до вісімнадцяти місяців. Великі інвестиційні проєкти з новою технологією або критичними для безпеки елементами можуть тривати від двох до трьох років. Найбільший окремий чинник графіка часто не інженерна складність, а складність координації: проєкти з багатьма постачальниками та дисциплінами тривають довше, ніж проєкти з меншою кількістю учасників, навіть якщо технічна робота подібна.

Чий проєкт автоматизації?

Менеджер проєкту автоматизації відповідає за графік, координацію, огляди гейтів і узгодження між дисциплінами, але робота міждисциплінарна за своєю природою і жодна функція не контролює її одноосібно. Механічні підрядники відповідають за фізичну інфраструктуру, електричні за живлення та монтаж, інтегратор системи керування за постачання PLC і SCADA, інженери IT/OT за мережеву інфраструктуру, інженери процесу за філософію керування, а експлуатація за вимоги, які система має задовольнити. Менеджер проєкту автоматизації це координатор та інтегратор між цими функціями. Підтримка вищого керівництва незамінна, бо рішення гейтів мають комерційні наслідки та наслідки для безпеки, які перевищують повноваження менеджера проєкту.

Яка різниця між FAT і SAT?

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

Чи є FAT і SAT обов’язковими за законом?

Це залежить від галузі. Фармацевтичні проєкти та проєкти наук про життя вимагають FAT і SAT фактично згідно з Додатком 15 GMP ЄС, який прямо визнає їхню роль у кваліфікації. Для установок загальної промисловості маркування CE та відповідні норми ISO вимагають доказу, що установка задовольняє специфікації безпеки, показників і технічні, а FAT і SAT це стандартні механізми надання такого доказу. Навіть там, де вони не є суворо обов’язковими за законом, FAT і SAT це поширена практика в більшості промислових галузей, бо економічна причина перехоплювати дефекти в найранішій можливій точці добре задокументована.

Чи можуть проєкти автоматизації дотримуватися гнучких методів?

Проєкти автоматизації мають фізичні залежності, які обмежують застосовність суто гнучких методів: обладнання потребує часу на закупівлю, введення в експлуатацію потребує вікон доступності підприємства, валідація безпеки дотримується регуляторних послідовностей, які не можна ітерувати. Елементи гнучкого мислення добре пасують, зокрема ітеративне уточнення URS із зацікавленими сторонами перед заморожуванням проєктування та ітеративне налагодження під час FAT і введення в експлуатацію. Але фазова структура від URS до введення в експлуатацію це каскадний хребет, бо фізичні та регуляторні обмеження його нав’язують, і спроби застосувати суто гнучкі методи до проєктів автоматизації зазвичай дають гірші результати, ніж дисциплінований підхід фаз і гейтів.

Управління проєктами автоматизації це дисципліна постачання проєктів промислової автоматизації від специфікації вимог користувача, через інженерію, FAT, SAT і введення в експлуатацію, до стабільного виробництва, відмінна від загального управління виробничими проєктами своїм обов’язковим послідовним хребтом валідації, притаманною міждисциплінарною складністю, інтенсивністю безпеки та відповідності і залежністю від координації кількох постачальників. Структура із шести фаз від URS до введення в експлуатацію дає рамку, а хребет валідації FAT-SAT-SIT-введення в експлуатацію дає дисципліну, що його визначає, з дефектами, виявленими на FAT, що коштують на порядок менше, ніж на SAT, і на два порядки менше, ніж під час введення в експлуатацію. Міждисциплінарна координація між функціями механіки, електрики, керування, IT/OT та інженерії процесу поглинає більшу частину уваги менеджера проєкту, а зменшення тертя на передаваннях це найбільший окремий важіль на загальну тривалість проєкту. П’ять шаблонів невдач (недостатньо специфікований URS, скорочений FAT, прогалини в координації кількох постачальників без SIT, затримки сусідніх дисциплін, що переливаються, і відкладені безпека та кібербезпека) можна відвернути названими контрзаходами. Вимоги безпеки та відповідності, зокрема IEC 61511, IEC 62443 і галузеві регламенти, треба вбудувати в потік проєкту із самого URS. Видимість на рівні портфеля щодо одночасних проєктів автоматизації уможливлює рішення щодо ресурсів, стандартизації та потужності, які інженерні компанії ухвалюють постійно. Кейс Smart Automation показує, що інженерна компанія середнього розміру може за місяці побудувати дисциплінований стандарт проєкту навколо спільної системи, тоді як кейс Tesla Model 3 показує, що амбіція автоматизувати без пілотної валідації та дисциплінованого виконання фаз і гейтів породжує «пекло виробництва» в найбільшому можливому масштабі. FlexiProject підтримує рівень виконання управління проєктами автоматизації з видимістю портфеля, управлінням графіком, що поєднує подання діаграми Ганта, переліку завдань і канбану, реєстром ризиків, пов’язаним з фазами, структурованими оглядами як оглядами гейтів і стандартизованими шаблонами проєктів. Міждисциплінарна інженерна координація та дисципліноване дотримання критеріїв гейтів залишаються організаційними відповідальностями. Коли портфель проєктів автоматизації інженерної компанії переріс електронні таблиці і потребує системи, яка підтримує дисципліну між кількома одночасними проєктами та міждисциплінарними командами, тридцять днів повного доступу без кредитної картки це практичний спосіб перевірити придатність.