Ф’южн-фабрика, або Як бізнес-розробники можуть розвантажити ІТ-відділ

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

Постійне збільшення команди не завжди є можливим чи виправданим. Що ж робити, коли бізнес наполягає, а людей і ресурсів на виконання всіх вимог обмаль? Сісти й плакати, постійно відмовляти чи погіршувати якість — не варіант. А чи не пробували ви навчити бізнес-користувачів розробляти застосунки та автоматизувати бізнес-процеси?

Так-так — «сам-собі-девелопер». Якщо ви одразу вважаєте цю ідею жахливою, розгляньмо її детальніше. Мене звати Даніїл Безлюднов, я менеджер розробки програмного забезпечення в EPAM Україна і маю понад 10 років досвіду у роботі з технологіями Microsoft, Power Platform, Dynamics 365 CRM, Azure та .NET. В цьому матеріалі поділюся новими трендами у світі автоматизації та розробки корпоративних застосунків.

Що таке ф’южн-фабрика і хто такі бізнес-розробники

Далі я буду оперувати певними термінами, тому надамо їм визначення на початку.

Ф’южн-фабрика (англ. fusion factory) — концепт, який пропонує поєднання роботи професійних розробників і тренованих бізнес-розробників задля підвищення продуктивності розробки корпоративних застосунків та автоматизації за допомогою засобів, які не потребують знання мов програмування. Саме про цей концепт і піде мова далі.

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

Некодові інструменти (англ. no code) — набір застосунків, нотацій, формул і підходів до розробки, які дають змогу створювати рішення без знання професійних мов програмування, як-от Java, C#, Python, Javascript чи інших. Основні взаємодії компонентів будуються за допомогою Excel-подібних формул та перетягування й поєднання елементів на графічному інтерфейсі. Найпопулярніші технології в цьому сегменті — Microsoft Power Platform, Appian, Pega, OutSystems, AppSheet та інші.

Як це працює

Ф’южн-фабрика (малюнок 1) — це новий підхід, який повністю змінює формат взаємодії бізнесу та ІТ-департаменту всередині компанії. Він виводить нового гравця на поле розробки. Гравця, який дуже сильно відрізняється за рівнем знань, потребами та специфікою роботи від професійних інженерів.

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

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

Малюнок 1. Модель ф’южн-фабрики

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

Малюнок 2. Модель робочого процесу з допомогою ф’южн-фабрики

  1. Процес починається з ідеї (тут все як завжди), яку вносять бізнес-користувачі.
  2. Після цього бізнес-розробники за допомогою ІТ-коуча проводять всебічну оцінку (assessment) запиту. Вони обмірковують, чи варто його розробляти, чи можна щось перевикористати та, чи можна його виконати самостійно або ж знадобиться допомога ІТ-департаменту.
  3. Наступна стадія — дизайн, під час якого розробляються концепт бізнес-процесу та скетчі графічного інтерфейсу.
  4. На етапі розробки за допомогою некодових інструментів бізнес-розробники покривають 90% роботи й просять допомоги у професійних інженерів з 10% за складними, нетривіальними та комплексними компонентами.
  5. На етапі розгортання проводиться постачання рішення до кінцевих користувачів за допомогою підготовленої автоматизованої лінії постачання. Процес в найкращому випадку має робитися лише в декілька кліків.
  6. Після постачання готового рішення дуже важливо розповсюдити знання про розроблені застосунки, автоматизовані процеси, компоненти, які можна перевикористати. А також про те, де знайти пов’язану документацію тощо.
  7. Закінчується все передачею застосунку чи процесу в ІТ-відділ до стадії контролю (monitoring) з погляду технічних вимог та до бізнес-розробників на перевірку на потенційні майбутні покращення.

Які є ризики підходу

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

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

Хтось може сказати: «Так все ІТ — це про складне і не тривіальне». Дозвольте не погодитися. Наведу деякі приклади задач, які бізнес-розробники можуть зробити (і на моєму досвіді дійсно робили) менше ніж за один робочий день:

  1. Розпізнати в листі, який прийшов на загальну електронну пошту, рахунок на оплату в PDF-форматі і записати основні значення у внутрішню систему Х (не плутати з ex-Twitter 🙂).
  2. Зробити форму вводу персональних даних для планшета в реєстратурі.
  3. Зайти на сайт, відфільтрувати дані й звантажити звіт.
  4. Автоматизувати нотифікації при додаванні нових рядків в Excel-файл або нових людей в HR-систему.

Сьогодні вже не обов’язково знати, як працює процесор, як індексується пам’ять, та у чому різниця між чергою і стеком, щоб автоматизувати якийсь бізнес-процес. Так, без цих знань не обійтись на проєктах із запуску супутників на орбіту, автоматизації швидкості руху автомобіля в заторі, чи навіть розробки нової CRM або ERP-системи. Так, будь-які ускладнення потребуватимуть цих знань, але для найпростіших сценаріїв (а у бізнес-користувачів таких зазвичай десятки й сотні, як-от робота з MS Office взаємодія з наявними сайтами, реорганізація файлів і пошти тощо) вистачить базових навичок.

Плюси і мінуси ф’южн-фабрики

Позитивні і негативні сторони цього підходу дуже сильно залежать від погляду, з якої ви дивитеся на нього. Розглянемо декілька.

Професійний розробник

Плюси

Менше монотонної розробки однакових форм, створення того-самого-REST-API в тисячний раз і більше цікавих задач, пов’язаних зі складною бізнес-логікою.

Мінуси

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

Збільшення задач з моніторингу та підтримки через різке зростання кількості застосунків та процесів.

ІТ-менеджмент

Плюси

Розвантаження ІТ-департаменту від безлічі незначних задач.

Збільшення сфокусованості ІТ-команд на стратегічних цілях.

Мінуси

Необхідність зміни підходів та погляду в автоматизації бізнес-процесів.

Потенційне збільшення залежностей через збільшення кількості місць збереження даних.

Потреба в покращенні процесів стандартизації дизайну та постачання.

Збільшення видатків на контроль і підтримку великої кількості застосунків, розроблених не професіоналами.

Необхідність налаштування якісного навчання для бізнес-розробників.

Збільшення ризиків, пов’язаних із безпекою.

Бізнес

Плюси

Можливість отримати автоматизацію процесів, «на яку так давно чекали», за допомогою наявних ресурсів всередині департаменту.

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

Зменшення залежності бізнес-відділів від ІТ-департаменту, що відкриває нові можливості для розвитку.

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

Мінуси

Треба вкластися в навчання співробітників і давати їм час на опанування нових навичок.

Частина роботи перетвориться на підтримку нових застосунків і автоматизованих процесів.

Застосування на практиці

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

Початок роботи був присвячений розробці детального тренінгу на основі технологій Microsoft Power Platform та Microsoft Power Automate з використанням модулів ШІ. Фінальна версія тренінгу містила 10% теорії і 90% практики автоматизації, яку можна було пройти впродовж шести годин за один робочий день (з обідом і трьома перервами). Під час практики група мала автоматизувати деякі нескладні сценарії виростання програм MS Office та роботу з сайтами.

Після розробки тренінгу і першої сесії ми отримали десять нових бізнес-розробників. Після чого почали проводити цей тренінг для груп з 10-20 людей на регулярній основі. Звісно, не всі з новоспечених бізнес-розробників почали щось одразу робити. Розподіл був наступний:

  • Приблизно 40% учасників зайшли «просто повчитися».
  • 30% пішли думати, що саме вони хочуть автоматизувати в їхньому робочому процесі.
  • Ще 20% зробили одну мікроавтоматизацію для своєї рутинної роботи й пішли суперзадоволені.
  • Останні 10% одразу повернулись до ІТ-департаменту і попросили допомоги зі складнішими сценаріями застосування й потребували подальшого менторингу.

Основні виклики з’явились, коли кількість бізнес-розробників перетнула позначку в 50 людей. На цьому етапі різко збільшується потреба в роботі служби контролю та координації бізнес-користувачів. Тільки уявіть: ви збільшили ІТ-департамент на 5-10 постійних і ще 40 потенційних розробників (це приблизно 2-7 команд!). Тепер їх теж треба підтримувати! Для закриття потреби в покращенні контролю, нагляду за застосунками й процесами, та координації бізнес-розробників, ми застосували рішення Microsoft Power Platform Center of Excellence.

Таке рішення допомагає:

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

А також пропонує міріаду застосунків й процесів автоматизації процесу контролю.

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

Насамкінець

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

Більше інформації — за посиланнями:

  1. Fusion development in Power Platform.
  2. Unleashing the citizen developer in all of us with the Microsoft Power Platform.
  3. What is Microsoft Citizen Developers.
  4. Understanding Citizen Developer: Microsoft Power Platform.
👍ПодобаєтьсяСподобалось9
До обраногоВ обраному3
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

З мого досвіду Power Automate, це тільки має сенс для чогось найпростішого. По типу дістати з імейла атачмент і кудись його покласти.

Як тільки починаєш робити щось серйозніше відразу вилазить купа проблем.
Екстремально низький перформанс, ліміти, відсутність нормального дебагеру, відсутність адекватної можливості спільної роботи над флоу, контроль версій...

Я думаю це все актуально для будь-якого якого no code/low code.

Зате менеджмент від нього чомусь тащиться))

Тому що ’ефективні менеджери з дипломом MBA’ люблять погратися в ’реінжинірінг бізнес процесів’

Це дійсно так. Саме тому, що поточні застосунки, low/no-code, АІ та багато чого іншого дає можливіть робити часті експерименти і не втрачати на їх впровадження тисячи чи мільйони долларів. Це дозволяє також закривати дірки в місцях повної відсутності автоматизації простими і ефективними (для своїх задач) інструментами. При цьому ціна експерименту дозволяє доволі легко через рік..два..п’ять цей застосунок чи процес замінити на «професійний» написаний командою розробки ПЗ, який буде коштувати на декілька порядків більше. Це можна зробити коли буде детальніше зрозуміло, що саме треба зробити, чи дійсно впровадження приносить цінність і чи насправді цим користуються. На моємі досвіді саме так і траплялось.

Так і є. Саме такі задачі і автоматизували. Файли, емейли, Sharepoint, Excel, і тд.

Перфоманс для асинхронних процесів не так важливий, особливо при 0% поточного рівня автоматизації і розумного підходу до реінжинірінгу бізнес процесу.
Ліміти. Так. Вони всюди є. Плюс «це ж майкрософт» :). Знову ж таки, ми не говоримо про high-load and big data в даному контексті.
Дебагер — це дійсно болюча тема, і тому, що складніше ніж на 20 блоків дуже важко розробляти, «дебажити» і підтримувати.
Контроль версії можливий, але це заскладна тема для коментарів і бізнес користувачів.

І яка проблема вирішується? Мені здається в ЕРАМ «бізнес-користувачі» писали код до того як це стало мейнстрімом

Вирішувалась задача автоматизації великої кількості тривіальних бізнес процесів (як вказано в статті) при сильно обмежених бюджетах і кількості людей/розробників.
Ця задача вирішувалась для нетехнічних компанії, в яких ІТ відділ був дуже малим і вимірювався одиницями (навіть не десятками) людей, але були доволі «просунуті» люди з бізнесу (продажі, бухгалтерія, маркетінг і тд).

Трохи стикався з лоукодами Power Automate в тому числі , воно так просто на рекламних презентаціях . Від розробника вимагається знати REST API, T-SQL(якщо є база), ,трохи в regexp.- все те саме що мову програмування вчити. Створене Флоу часто зависає ви не керуєте перформансом та маєте ліміти А коли щось потрібно -то не має в базовому функціоналі ,треба платний аддон .короче забавка .наш клієнт відмовився на користь нормальної JS аплікації

Дійсно рекламні акції занадто «гарні». При цьому, ці інструменти можна використовувати, як професійними так і не професійними розробниками. У них як би 2 сценарія використання. Якщо треба автоматизувати обробку емейла чи файла на OneDrive — це можна зробити без будь-яких складнощів і без знань, що таке SOLID, API, T-SQL та інше. При цьому, якщо задача в тому, що б зінтегрувати створення запису у Salesforce та в Azure SQL — цим інструментом можна скористатися, але вже треба знання T-SQL та REST API. Я не кажу, що це буде найкращий вибір, але він точно може бути альтернативою і деяких умовах — гарним вибором.

Performance. Для асинхронних процесів він не є таким критично важливим, якщо ми не кажемо про big data чи high-load, а в контексті автоматизації бізнес процесів в великих enterprise, де поточний рівень автоматизації <5% то і подавно.
Ліміти. Так. Вони всюди є. Плюс «це ж майкрософт» :). Знову ж таки, ми не говоримо про high-load and big data в даному контексті.
Платний. Це Microsoft — у нього все платне :), як і будь що в сучасному клауді (якщо ми не говоримо про тріальні і випробувальні безкоштовні компоненти). Також, враховуючи, що дуже багато кліентів мають Office E3 ліцензію, це дозволяє користуватися цими тулами безкоштовно. Також багато асинхронних процесів можна автоматизувати через service/technical account, що також скорочує ціну.

Ооо, годнота)
Тільки на мою думку таке ще трішки рано імплементувати, почекати поки повипускають всякі ІДЕ які заточені під використання з АІ і спеціальна підготовка не така уже і потрібна, АІ і так буде конвертувати людську мову у мову програмування)

На мою думку, деякі з цих No/Low-code інструментів і є якраз цими IDE з AI. Power Automate Copilot, наприклад, доволі непогано робить тривіальні задачі за 1 промпт в декілька речень. Звичайно у цих інструментів повно обмежень, галюцинацій, але для новачків і бізнес-користувачів вони дуже корисні, і якщо треба працювати із стандартними офісними застосунками, то це саме то, що треба.

Зараз це забавки, а от коли воно справді буде заточено під конкретні інструменти тоді уже думаю можна дивитись на такий тип процесів

Дякую за статтю, не вистачало матеріалів про Power Platform на українському ринку. Цей технічний стек (Power Apps/Power Platform/Dynamics 365/SharePoint) відсутній в опитуваннях DOU тому не зрозуміла загальна статистика таких девелоперів.

Дякую за відгук.
Будемо по трошки просувати Power Platform в маси :). Так, це нішевий стек, але дуже гарний для деяких юз кейсів.

Якщо бізнесу потрібна автоматизація, він вмотивований на автоматизацію то зроблять усе як знають без девелоперів і модних no code систем
Памʼятаю приклади як у невеликих конторах де бізнеса самі собі ваяли на Visual Basic чи Delphi якісь приложухи. Часто доречі при рості коли масштабувалось у велике підприємство ці додатки залишались as is і досі працюють
Є приклад коли у великих ентерпрайзах був наприклад запит до it — створіть систему прогнозування і щоб ще автоматично там розподіляла ордери згідно прогноза продажів. IT такі — не вміємо, знайшли підрядника на овер дофіга мільйонів. Ні дякую, тут у нас дядьки статисти, phd. Якось ваші програмування вивчимо.
Так і зародилась система із acces, python/bash скиптів. І працює круто.
Хотіли замінити, жоден підрядник не узявся бо не зможе зробити систему з такою самою точністю прогнозування

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

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