Код успіху: як вибрати підхід до цифровізації бізнесу
Яке рішення обрати
Компанії, які здатні швидко змінюватися та запускати нові сервіси, більш конкурентоспроможні в сучасному світі. Тому все більше організацій розуміють важливість цифрової трансформації (Digital Transformation, DX) для досягнення успіху.
У процесі цифровізації IT-системи грають роль транспортних магістралей: вони або підтримують швидкі зміни, або стають пляшковою шийкою. Навіщо розпочинати цей процес і яке технічне рішення обрати, розповіла Mind VP Delivery Management, Innovecs, Наталія Зуб.
Ринок DX у цифрах
Згідно з Gartner, витрати на цифрову трансформацію досягнуть $3,9 трлн до кінця 2021 року, а COVID продовжить бути головним каталізатором змін. Очікується, що середньорічний темп зростання ринку DX становитиме 23% за період з 2019 до 2023 року.
Наочний приклад успішної цифровізації внутрішніх бізнес-процесів демонструє ŠKODA AUTO HR. Компанія заощаджує понад 40% часу на пошук персоналу після впровадження віртуального асистента на основі сервісів IBM Watson.
Але не всі кейси диджиталізації настільки ж ефектні: за даними Everest Group, 73% компаній не побачили будь-якої цінності для бізнесу після завершення цифрової трансформації.
Навіть великі компанії часом зазнають невдач у процесі DX. Так, корпорація General Electric почала створювати свою IoT-платформу ще 2011 року. Попри те що гігант витратив мільярди доларів на масштабні зміни, ціна акцій падала, що позначалося на багатьох операційних сегментах.
Очевидно, не існує єдиного протоколу, за яким би можна було провести Digital Transformation в абстрактній компанії у вакуумі. Світ бізнесу змінюється так швидко, що традиційні підходи починають старіти ще до моменту практичного застосування.
Однак можна виділити найчастіші причини невдач цифровізації компанії, серед яких:
- робота без чіткої мети;
- нерозуміння керівництвом важливості змін;
- відсутність досвіду;
- фокус лише на технологіях.
Кейси можна вивчати, але кожна компанія унікальна, тому потрібно розробляти унікальну стратегію.
Вибір технічного рішення для DX
Зазвичай компанії вибирають один із наведених нижче шляхів.
Коробкове рішення
З плюсів – відносно швидке розгортання. Але варто врахувати, що всі модифікації залежатимуть від провайдера. Не завжди третя сторона зацікавлена в оперативних змінах, які, можливо, будуть важливими для бізнесу.
Самописна система
Шлях розробки з нуля завжди довгий і небезпечний, навіть для компанії, що спеціалізується на створенні автоматизованих софтверних систем. З фіналом розробки є ризик отримати морально застарілий продукт.
Послуги аутсорсера
Варто розглядати такий варіант лише в тому випадку, якщо внутрішня команда планує розвивати компетенції Product Owner. Жодна аутсорс-компанія не може вдаватися абсолютно у всі процеси, не вивчатиме бізнес-домен ідеально.
Максимум, на який варто розраховувати: підрядник надасть команду та налагодить процес розробки. А далі – черга компанії-замовника.
Готові SaaS-рішення
Якщо кожен окремий департамент використовуватиме своє рішення, велика ймовірність отримати розрізнені модулі, а не єдину екосистему. В результаті наскрізна аналітика із залежностями так і залишиться мрією, цифрова трансформація замаскується під автоматизацію та виникне потреба нового інтеграційного проєкту.
Така інтеграція швидше за все обійдеться в кілька разів дорожче порівняно з початковими змінами.
Оптимальний комбінований варіант
Ідеальне рішення компанії слід зібрати індивідуально під свої потреби – як конструктор.
Для зрілих бізнес-процесів варто використовувати коробкове рішення або SaaS, для унікальних чи відсутніх – написати невеликі програми самостійно.
Подумати про єдину централізовану базу даних. Найчастіше підійде Data Warehouse – корпоративне сховище даних, розробку якого цілком безпечно віддати на аутсорс.
Якщо зовнішні та внутрішні умови дозволяють, то інтеграційний проєкт краще запустити до вибору систем. А вибір дозволити зробити інженерам, а не керівникам відділів.
Як показує мій досвід, ці процеси добре «паралеляться», і на реалізацію потрібно не більш як рік. При цьому найцінніше – дані та компетенція – накопичується всередині компанії.
Підхід до встановлення та реалізації завдання
Розглянемо найбільш поширені підходи до процесу розробки, а також їхні переваги та ризики.
Спроба формалізувати 100% вимог
Навіть якщо поставити собі за мету й чітко описати всі вимоги та структури даних, на жаль, передбачити всі нюанси не вдасться. Натомість документація зажене розробників у жорсткі рамки та перекриє дорогу вдалим рішенням.
Гнучка методологія розробки
Метод Agile передбачає наприкінці кожного спринту запуск потенційно готового до постачання інкременту продукту – shippable product increment. У разі цифровізації корпоративних процесів такий підхід складно реалізувати, адже відокремити shippable increment практично неможливо, не порушивши життєво важливих взаємозв’язків.
Гнучка розробка всього продукту
Цього слона треба їсти не частинами, а шарами, тобто працювати необхідно з неподільною системою. Результат такої розробки можна описати термінами PoC (дослівно – proof of concept, перевірка концепції) і MVP (minimum viable product, мінімально життєздатний продукт). Перший шар можна отримати, описавши один життєвий цикл продукту, проєкту чи функціоналу працівника.
Для прояснення детальних вимог майбутніх користувачів оптимально підійде метод Design Driven Development. Підхід передбачає, що спочатку створюється інтерфейс, який тестують у реальних обставинах, і тільки після цього інженери розробляють функціонал. Ця концепція роботи над продуктом заощаджує багато часу, адже зворотний зв’язок буде надано до етапів затвердження функціоналу, розробки, тестування, впровадження та навчання.
Найголовніше пам’ятати: простіше поміняти щось у процесі, ніж добудовувати чергову милицю до складної системи. Тоді не доведеться чекати «повний автомат» за мільйон і через рік, коли «напівавтомат» можна запустити з прийнятним бюджетом уже протягом місяця.
Автори матеріалів OpenMind, як правило, зовнішні експерти та дописувачі, що готують матеріал на замовлення редакції. Але їхня точка зору може не збігатися з точкою зору редакції Mind.
Водночас редакція несе відповідальність за достовірність та відповідність викладеної думки реальності, зокрема, здійснює факт-чекінг наведених тверджень та первинну перевірку автора.
Mind також ретельно вибирає теми та колонки, що можуть бути опубліковані в розділі OpenMind, та опрацьовує їх згідно зі стандартами редакції.
