Не нашкодити: які п'ять побоювань щодо автоматизації насторожують бізнес

Не нашкодити: які п'ять побоювань щодо автоматизації насторожують бізнес

І що з ними робити

Не нашкодити: які п'ять побоювань щодо автоматизації насторожують бізнес
Фото: depositphotos.com

Автоматизація бізнес-процесів набуває все більшої популярності. Тут велику роль відіграють нові виклики – спочатку пандемія, тепер війна. У нових умовах бізнесу потрібно оптимізувати більше процесів та автоматизувати їх, аби  економити ресурси. Проте бізнес часто не поспішає втілювати нові технології через низку пересторог та побоювань. Які п'ять найпоширеніших страхів бізнесу у цьому питанні та які рішення можуть допомогти з ними впоратись, розповіла Mind Head of Software Development в Integrity Vision Міла Підгорна

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

1. Які організаційні зміни чекають на компанію? 

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

Тож керівництво компанії не одразу наважується змінювати те, що, в принципі, і так працює багато років. 

Яке рішення допоможе?

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

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

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

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

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

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

Ще одним важливим етапом на початку автоматизації є аналіз і підготовка бізнес-кейсу. У замовників є процеси AS IS, які потрібно змоделювати, наприклад, у BPMN 2.0 (Business Process Management Notation – мова моделювання бізнес-процесів, яка є проміжною ланкою між формалізацією/візуалізацією та втіленням бізнес-процесу).

Це необхідно для порівняння наявного процесу з модернізованим після автоматизації і розуміння, якою буде його ефективність. А також треба сформувати “to be” – тобто бачення того, яким буде процес вже після впровадження.

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

2. Як обгрунтувати інвестиції?

Ще одне важливе питання, яке часто турбує замовників, – фінансові вкладення за користування продуктом (якщо це не open source). 

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

Яке рішення допоможе?

Є можливість працювати спочатку за концепцією MVP (minimum viable product) – мінімально життєздатного продукту. Це робота із мінімальним функціоналом, який можна впроваджувати на безоплатних ліцензіях.

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

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

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

3. Як налагодити підтримку продукту вже після автоматизації?

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

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

Саме тому в замовника виникає залежність від внутрішньої команди, яка має експертизу з впровадження такого рішення.. 

Яке рішення допоможе?

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

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

Спочатку процес реалізує надавач послуг своїми силами. Після цього можна створити спільну команду із працівниками компанії-замовника. В неї можуть входити їхні аналітики та розробники. У таких проєктах ми працюємо по Agile. Під час спільної реалізації спеціалісти замовника вчаться: яку документацію вести, як описувати код, як робити code review, вирішувати архітектурні проблеми.

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

4. Як перевірити актуальність продукту? 

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

Яке рішення допоможе?

З власного досвіду можу сказати, що в такій ситуації варто звернути увагу на роботу з Agile, а не Waterfall. З’являється можливість нарощувати функціональність, працювати двотижневими спринтами, і кожні два тижні показувати зацікавленим сторонам новий функціонал.

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

Також у співпраці з ними можна почути цінний фідбек і підкоригувати щось за потреби. Зрештою такий продукт буде живим і відповідатиме реальним вимогам замовника.

5. Як уникнути застарілості продукту?

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

Яке рішення допоможе?

Дуже важливо при виборі будь-якого вендора розуміти, яка в нього концепція розвитку свого продукту. Коли вендор використовує нові технології, наприклад, поєднує моноліт та мікросервісну архітектуру – це дає замовнику можливість вибору.  Окрім розвитку самого рішення, важливо, аби вендор гарантував підтримку попередніх версій.

Стежте за актуальними новинами бізнесу та економіки у нашому Telegram-каналі Mind.ua

Автори матеріалів OpenMind, як правило, зовнішні експерти та дописувачі, що готують матеріал на замовлення редакції. Але їхня точка зору може не збігатися з точкою зору редакції Mind.

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

Mind також ретельно вибирає теми та колонки, що можуть бути опубліковані в розділі OpenMind, та опрацьовує їх згідно зі стандартами редакції.

Проєкт використовує файли cookie сервісів Mind. Це необхідно для його нормальної роботи та аналізу трафіку.ДетальнішеДобре, зрозуміло