Моделі та методи співпраці в проекті aCampus

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

Тому абсолютно, ясно що традиційні методи співпраці «по команді зверху» (властиво для всіх великих компаній), чи по-хуторянському «знаю, але нікому ніколи нізащо…» (властиво малому бізнесу) тощо – є нерелевантними для Індустрії 4.0. Принаймі, якщо ви позиціонуєте себе інноваторами, а не простими споживачами новітніх технологій.

Але що є релевантним? – які методи чи моделі? Можна, звісно, багато говорити про Agile Project Management, але наскільки ця методика охоплює всі аспекти управління та співпраці в розвиткових проектах? Наскільки релевантними є інструменти?

В проекті aCapmpus ми чимало експериментуємо з різними моделями та методиками. Спочатку головною була методика Agile Project Management. Вона була прийнята від початку – в серпні 2019. Детальний план проекту, розміщений в хмарному середовищі Trello щотижня обговорювався з членами команди, відповідно вносились зміни в завдання. Водночас, техніки Agile, які мали б повертати всю команду до вимог споживача (стандартів) й задавати ритм спринтів виглядали дещо абстрактними. Адже у випадку наших 5 стандартів, питання залучення й розуміння контексту споживача і є однією з головних проблем. Тобто, зрозуміти «які ж вимоги» – дуже важко, вони не озвучуються чітко та ясно навіть передовими замовниками чи інтеграторами, оскільки загальний їх рівень розуміння аспектів, пов’язаних зі стандартами, їх витоків є початковим. Більшість замовників вперше взнавали про стандарти, тому питання «які у вас проблеми чи вимоги в сфері застосування стандартів» звучали абстрактно, рис. 1

рис. 1 Екосистема навколо замовника

Вкрай низький рівень відповідей на онлайн опитування в вересні був черговим тому підтвердженням.

Рецепти залучення

Відтак, ми зосередились на кращому залученні окремих, великих замовників. Користуючись авторитетом та зв’язками виконавчої дирекції АППАУ, ми спочатку зосередили ці зусилля на одному стандарті – ISO 22400. До обговорення та вияснення питань навколо цього стандарту виробничих КПЕ були залучені провідні менеджери 9 компаній. Цей процес з методикою розподілу ролей детально описаний за цим посиланням.  Водночас, навіть подібне залучення не гарантує злагодженої, а головне – поступальної роботи експертів. Як зробити так, щоб рух був невпинний й щоб нові завдання мотивували всю експертну команду, а не тільки окремих її учасників?

Процеси та інструменти

Наступна цікава модель, яку ми знайшли в листопаді і над якою зараз чимало рефлексуємо та експериментуємо походить з середовища… самих стандартів. Так, так – несподівано, наш колега запостив в групі ТК 185 гру https://idea-mania.eu/ суть якої полягає в відпрацюванні процесної моделі в проходженні нових стандартів до ринку. В принципі, ці ж процеси та інструменти використовуються і для будь-яких нових практик, рис. 2.

Рис. 2 Загальна карта проходження ідей до ринкового стандарту.

Суть гри полягає в тому, щоб ідеї, які генерує весь час чоловічок зліва внизу мають пройти різні категорії стейкхолдерів. При цьому вони проходять через 5 головних процесів – аналіз ситуації, ініціацію, дискусію, досягнення консенсусу та стандартизацію (зверху на екрані процеси підсвічуються, якщо черговий етап пройдено). В свою чергу, ці етапи неможливо пройти, якщо правильно та своєчасно не використовувати 4 види інструментів. Це – аналіз ситуації (research), розвиток ідей, нетворкинг та промоція. На своєчасності та правильному використанні того чи іншого інструмента в грі зроблено акцент, – тобто, не всі інструменти доступні в певний момент часу. Ця фішки гри нам дуже сподобалась, оскільки це моделювання повністю відповідає складнощам реального управлення складними проектами, де є різні категорії учасників, з різними профілями та досвідом.

Отже, в цю гру дійсно варто зіграти – вона наглядно демонструє, як ідеї перетворюються в кращі практики. І наскільки це непростий процес!

Хоча в проекті aCampus ми від початку використовували чимало подібних підходів, ця модель – гра своєю структурованістю та фокусом на «правильних» процесах та інструментах нас дійсно зацікавила. Й заставила переглянути деякі практики.  В проекті є 3 різні групи. Чи дійсно вони однаково успішно проходять ці процеси на кожному з головних етапів в проекту? Чи однаково успішно використовують інструменти? Чи добре ними володіють?

Внутрішній аналіз показує, що «ні» – не однаково. Ми виявили кілька вузьких місць

Рис. 3 Прості та складні питання між експертами в досягненні консенсусу.

  1. Найважчим процесом у всіх трьох групах є Build Consensus. На прикладі того ж стандарту ISO 22400 ми вже пояснювали на попередніх семінарах та воркшопах різницю між «простими» та «складними» питаннями, рис. 3

Відповіді на «прості» питання досягаються експертами (включно з зовнішніми, з пром. підприємств) досить швидко, часто – на першому ж зібранні. Натомість, ці ж перші зустрічі генерують «складні» питання, відповідь на які не очевидна. Розгляд подібних питань потребує кількох ітерацій, тобто, кількох зустрічей в яких мають вміло поєднуватись ті самі 3 інструменти

  • Аналіз (знову і краще  – на основі нових фактів)
  • Нетворкинг
  • Розвиток ідей

Подібна ситуація повторилась в групі стандарту МЕК 62264. В певний момент (дискусія 11 листопада) ми майже вперлись в тупикову ситуацію, коли експерти не могли дійти консенсусу щодо cистем автоматизованого обліку, їх ролі – масштабів та цільових застосувань. За кілька ітерацій, й застосовуючи методи сегментації, ми зрештою вийшли з цього становища, що й відображено в останній білій книзі по МЕК 62264 групи НУХТ. Як головний урок для побудови консенсусу,

ітерації (кілька послідовних заходів) – важлива практика до розв’язання складних питань.

  1. Розвиток ідей – як справжнє джерело інсайтів та рух вгору

Але мова не тільки про проблеми недостатнього чи різного володіння групами окремих інструментів, чи про так необхідну ітераційність. Мова також про те, що деякі інструменти досить важко формалізуються, тобто, по ним дуже важко передавати кращий досвід. До таких інструментів відноситься «розвиток ідей» (idea development).

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

Гарним  прикладом подібного розвитку ідей в стандарті ISO 22400 були коментарі Євгена Ковніра (ДТЕК) на семінарі 25 жовтня щодо стандарту ISO 13053  (на який посилається ISO 22400). Натомість, звідси Євген вийшов на методологію DMAIC та методи SixSigma / Lean Manufacturing. Те, як він використовує положення обох стандартів на практиці й вже з використанням методів data science й в конкретних проектах ДТЕК є справді захоплюючим та дуже цікавим. Водночас, погоджуючись з цими прикладами та методами застосуваннями стандартів, інші експерти все-ж  акцентували як на пріоритеті №1 необхідності автоматизованого обліку даних. Таким чином, завдяки обмінам, нетворкингу та дискусіям, ми бачимо досить повну, багату палітру того, як працюють стандарти, як вони живуть реальним життям, і як їх далі розвивати.

Однак, далеко не завжди, – а точніше, в 90% випадків ці ідеї втрачаються. Візьміть для прикладу практику проведення івентів в Україні. По 95% з них ви не знайдете навіть пристойного звіту від організаторів, не кажучи вже про фіксацію тим самих кращих ідей. Все це, «приватна справа» самих учасників івентів. Й по статистиці того, як працює наша пам’ять, шансів згадати щось корисного через тиждень два – мізер.  Саме тому в АППАУ ми робимо звіти після кожного івенту. Навіть після маленького семінару, хоча б в Фейсбук, ми вважаємо важливим та принциповим зафіксувати поточний статус-кво, рівень ідей, головні інсайти тощо.

Чи є це практикою розвитку ідей? Тільки частково. Оскільки мова про точку зору одного автора, хай він навіть намагається консолідувати різні експертні думки, що звучать на таких заходах.

Проект aCampus показує, що таких ідей дуже багато, й практики написання звітів після івенту недостатньо. Візьмемо для прикладу останній семінар в Харкові який був дуже багатим на нові ідеї та постановку проблемних запитань. Ось тільки 3 приклади –

  • Костянтин Леонтьєв з «Радій» надав практично готовий кейс застосування МЕК 61508 й того, наскільки ця сертифікація допомогла їм в експортній діяльності, а також в інноваціях та прискоренні в випуску нових продуктів.
  • Олександр Потій з ХАІ, як виявилось, вже закінчує роботи по повній аналітиці стану кібер-безпеки в законодавчій сфері. Цього надзвичайно потребують інші експерти, які задіяні в новоствореній групі 11 листопада в Києві.
  • Цікаву думку висловив в кулуарах Павло Осинський (Софтпром) – стандарти послуговують часто як обмежувальні бар’єри при імпорті. Саме тому, «Радію» було важко ввійти на канадський ринок без МЕК 61508, й ту ж проблему матимуть чи вже мають чимало українських експортерів при вході на ринки ЄС чи інших розвинутих країн.

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

  • Якщо «Радій» має чудовий кейс (стандарт, експорт та конкурентна перевага «в одному флаконі»), чому він до цього часу не оформлений? Адже очевидно, що такий кейс (на кшталт, Інтерпайпу чи ФЕД) міг би стимулювати десятки інших замовників по Україні. Чи можемо ми  це зробити? Яка у всьому цьому роль ХАІ (Центру 4.0), який знає ситуацію там вже багато-багато років? Чому цей замовник ще не залучений до спільноти АППАУ – адже його інтерес до подібних обмінів було видно на цій конференції неозброєним оком? Як нам знайти ще 5-10 подібних кейсів по іншим стандартам?
  • Якщо фірма, де працює О. Потій має повну аналітику по регуляторному середовищі в кібер-безпеці, то де ця інформація в публічному просторі? Хоча б частково? – адже більш, ніж очевидно, що її потребують багато інших експертів ТК 185 та дотичних груп. Як це змінить пріоритети групи, що створена 11 листопада? Які точки дотику ми бачимо?
  • Якщо стандарти вже є обмежувальним, але водночас стимулюючим до впровадження інструментом в чисельних країнах ЄС та світу, чи можемо розвинути ці тези відразу в 2-х напрямах. Перший – краще дослідити в яких країнах і як працюють ці обмеження. Й не забуваючи про положення промислового безвізу АССА, про який стільки розмов зараз. Очевидно, звідси 1 крок до кращого стимулювання у впровадженні стандартів наших експортерів – машино-приладобудівників, системних інтеграторів та інжинірингових компаній. Другий – це чи можна і як використати цей зарубіжний досвід, щоб стимулювати внутрішнього замовника. Адже абсолютно, очевидно, що стейкхолдерів державного рівня, що мали б опікуватись техногенними та кібер-ризиками в Україні чимало.

Отже, ми бачимо як всього 3 ідеї генерують цілий потік питань, відповіді на які дають наступну ітерацію, новий потік ідей, нові рішення і далі – новий етап розвитку.

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

******

Підсумовуючи викладене, скажемо, що єдиного «рецепту успіху» (єдиної методики) в проекті aCampus ми не виявили. Є свої корисні моменти в методах Agile, окремої уваги потребують методи залучення справжніх експертів та правильного розподілу їх ролей в мульти-дисциплінарних командах з різних категорій учасників ринку. Окремо, можемо дискутувати про важливість добре відлагоджених процесних підходах по окремим етапам проектів, та правильному використанні тих чи інших інструментів.

Власне, все це добре вписується в велику тему Agile Project Management. Повна систематизація цих методів та їх оцінка планується по закінченню проекту aCampus.

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

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

Успіхів всім нам в цьому розвитку.

Юрчак Олександр.

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *