Усі ми в одній бурі, але в різних шлюпках. Кожна компанія (шлюпка) знаходиться в своїх умовах. Це означає, що те, що спрацювало в одній, не обов’язково матиме успіх в іншій. Немає єдиного рецепту цифрової трансформації, тому будь-яку інформацію — рефлексуємо та адаптуємо до своєї ситуації. У конспекті лекції саме про це.
Про лекції
4 липня пройшла перша лекція Мері Ротар та Анни Лаврової в рамках інтеграції з Дія.Бізнес. Весь цикл вебінарів містить 5 лекцій:
- Цифрова трансформація для не ІТ-компаній.
- Цифрові трансформації без значних фінансових вкладень.
- Робота та розвиток компанії за ІТ-практиками.
- Продуктовий менеджмент за ІТ-практиками.
- Як ІТ бізнес-аналіз покращить ваш бізнес.
Ми зібрали основні тези з першого вебінару в рамках інтеграції з Дія. Чому ця лекція важлива:
- Спільна ініціатива разом з Дія.
- Можливість розставити всі крапки над цифровою трансформацією та переконатися, що це не страшно.
- Допомога тим, хто опинився у скрутному становищі та чий бізнес потребує розвитку.
Трохи про спікерів:
- Мері Ротар, СЕО, Co-founder IAMPM. 9 років досвіду в маркетингу та Product Management у зарубіжних компаніях. Вивела на ринок більше 50-ти продуктів як консультант, працювала як Product Manager у SaaS (MarkTech), Gaming та EdTech нішах. Запускала проєкти на Kickstarter. Вже 3 роки розвиває власний бізнес у онлайн-освіті. Може розповісти, як запускати успішні проєкти із мінімальним бюджетом.
- Анна Лаврова, Agile Coach у Wemanity Belgium. Сертифікований Scrum Master та SAFe Agilist. Понад 10 років досвіду роботи в управлінні проєктами. За цей час була в ролі PM-а в Outsource, Outstaff, Product, Startup компаніях. Впроваджувала техніки Agile з нуля на багатьох проєктах у 4 країнах. Працювала з державними проєктами США, запустила кілька стартапів, зараз менторит стартап-інкубатор 1991 року. Анна проводить заняття за принципом «learning by doing». Зараз займається цифровою трансформацією найбільшого бельгійського банку.
IT — не таке, яким ви його уявляєте
Щодо сфери ІТ насправді існує безліч невиправданих стереотипів, які в багатьох компаніях гальмують розвиток в напрямку цифровізації. Насправді:
- 30% спеціалістів не пишуть код, не пов’язані з дизайном та не займаються тестуванням.
- Більше 40% ІТ-компаній не заробляють на розробці, а продають інші послуги та товари.
- За успішність технологічних проєктів відповідають зовсім не технічні спеціалісти, а бізнес-люди, менеджери.
Саме таких людей навчають в IAMPM: проєктних та продуктових менеджерів, бізнес-аналітиків, маркетингових спеціалістів, спеціалістів з команди продажів та найму кадрів. 26 освітніх програм розроблено за 5 років та залучено 150+ спікерів з досвідом роботи у відомих ІТ-компаніях.
З нами трансформуються та ростуть відомі українські і міжнародні компанії — ZeBrains, Ciklum, SoftServe, S-PRO, Epam, GlobalLogic, Розетка, Uklon, Нова пошта.
Що таке цифрові трансформації:
- Перехід до віддаленого робочого простору. Ще 2 роки тому з початком пандемії багато компаній були не готові перейти на дистанційний формат, але більшості довелось це зробити, незважаючи на свої бажання чи навіть можливості. Ви одні з них? Вітаємо, тоді ви пройшли один з етапів цифрової трансформації.
- Використання дизайн-мислення для аналізу та оптимізації шляху клієнта. Важливо не просто продати продукт чи послугу, закривши фінансову ціль. Важливо досліджувати, як клієнти про нас дізнаються, чи задоволені вони якістю послуг, щоб розуміти нові перспективи розвитку, аспекти, які потребують додаткової роботи.
- Впровадження автоматизованого обслуговування клієнтів. Все просто: економія свого часу та часу клієнта = кращі результати компанії та рівень задоволеності аудиторії.
- Використання інформації за допомогою штучного інтелекта для підвищення ефективності продажів. Наприклад, запис в блокнот про попередні покупки клієнта задля змоги зробити йому актуальну пропозицію наступного разу.
- Автоматизація управління продуктивністю співробітників або принаймні відслідковування результатів.
Незавжди цифрові трансформації потрібні. Кому вони можуть бути не потрібні, принаймні на даному етапі:
- 1 продукт — 1 клієнт раз на рік (немає змоги новим чином працювати з клієнтом, по-новому продавати продукт);
- 1 персоналізована послуга крізь роки;
- у компанії дуже багато грошей і власники не хочуть збільшувати прибуток.
Трансформація в IAMPM
Шлях IAMPM — від лоукост-навчання офлайн до коротких навчальних ІТ-програм онлайн, де навчаємо всьому, окрім написання кодів. Ми не стали зосереджуватись на дорогих чи дешевих рішеннях, а впровадили різні — для разних типів клієнтів. Відбулися зміни цінності і розширення команди, клієнтів, спікерів.
Раніше ціллю було навчити, сформувати навичку, а не тільки продати курс, а далі ми зрозуміли — нам треба ще й працевлаштувати клієнта, залучили більшу аудиторії з різним фахом і досвідом і тим самим продовжили взаємодію з клієнтом на довгострокову перспективу, а не закрили її з продажем курсу.
При цьому важливо, що основну статтю доходів в офлайн складали публічні офлайн-курси, а в онлайн — корпоративні програми, консалтинг, воркшоп, онлайн-курси, але статті витрат лишились ті самі. Тобто можливості розширюються, але не завжди це призводить до збільшення витрат.
Проблеми, які підштовхнули нас трансформуватися, коли ми перейшли в онлайн — складний та дуже конкурентний ринок, невміння працювати з програмами для ведення задач, потреба в термінових змінах, задачі «на вчора».
Основна ідея полягає в тому, аби не абстрактно змінити життя компанії, коли ми всі з понеділка впроваджуємо нові процеси, а визначити конкретні дії, які ми могли б робити регулярно. Тому в нас все почалося з запровадження принципів:
- Лідер — це не керівник, це модератор та радник.
- Є зрозумілі ітерації, в яких потрібно було досягати певного результату (спринти, відрізки часу, відведені для певних цілей).
- Команда сама обирає цілі.
- Визначені конкретні метрики для розуміння, чи цілі досягнені.
- Регулярні зустрічі згідно правил для обговорення.
Трансформація в IAMPM відбувалася через SCRUM:
- Визначення ролей в команді та передача естафет між членами команди.
- Запровадження спринту — відрізку часу, на котрий планується виконання цілей, в кінці кожного спринту має бути якийсь результат. Визначається одна загальна ціль і адаптовані під кожного спеціаліста.
- Планування — як досягаємо певної мети.
- Дейлі-мітинги — на них можна попросити допомоги, визначити перепони, обговорити проблеми.
- Спринт-ревью — підводимо підсумки, які цілі виконані, як результати відрізняються від цілей, що робити далі ( в ідеалі з участю клієнтів)
- Запровадження ретроспективи — зустріч десь раз на місяць, на якій ми обговорюємо, як ми себе почували, з якими проблемами стикалися. Це допомагає не відчувати вину за недосягнення якихось цілей, виявляти проблеми в продуктивності спеціалістів та ефективно їх вирішувати.
Як бачимо — не ІТ-софтом єдиним це можна зробити. Головна мета всього цього — зростанні від групи працівників до самоорганізованої та здорової команди.
Варто враховувати, що основні зони цифрових трансформацій мають працювати разом, однією системою.
Приклад IAMPM в виборі зон трансформації в форматі “Було-стало”:
Коротко про шлях трансформації
- Починали з настільної гри та офлайн-курсів в Одесі.
- Виросли з хобі в міжнародний проєкт без інвестицій та продовжуємо рости.
- На старті мали нетехнологічну команду початківців, які стали digital-профі завдяки принципам роботи.
Приклади цифрових трансформацій в інших компаніях
В якості прикладів розглянемо трансформації декількох компаній.
Що стосується CapitalOne, то всі зміни були спрямовані на те, аби оптимізувати витрати на виконання певних завдань. Вони торкнулися типів технологій, які використовувалися, віддаленого формату роботи задовго до локдауну, а ІТ-департаменти працювали за конкретним списком принципів, які можна застосувати вже сьогодні, а результати бачити надалі постійно.
В Kroodle всі трансформації стосувалися надання консультацій клієнтам. Це перша компанія в сегменті страхових послуг, яка перевела все обслуговування в соцмережі. Жодних складних продуктів чи застосунків, розуміння, де знаходяться їхні клієнти, та переведення роботи в цей простір.
У 2011 році компанія Domino’s зробила так, щоб через смартфон можна було замовити піццу за 17 секунд. Такий самий час потрібен, аби світлофор став зеленим.
У компанії Sonnen перейшли на Agile. Це сприяло зміні структури компанії, пристосовуючи її до потреб клієнтів, співробітників і ринку, що постійно змінюється. Також зміни включали вдосконалення відділів продажу програми та процесу продажу як такого, а також обслуговування клієнтів і співпраці з партнерами — як на рівні програмного забезпечення, так і на рівні процесу.
«Було-стало» на прикладі виробництва
Розглянемо приклад більш практичного, прикладного бізнесу, якому не було потреби в межах трансформації переходити в онлайн — компанії по виробництву одягу.
На початку маємо наступну картину:
- ціль — вижити;
- є одна людина, яка приймає та контролює всі рішення;
- відділ маркетингу і продажу без налагодженого контакту;
- все виробництво — це не штат, а підрядники, які отримують оплату на карту Приватбанку;
- різні загальні цінності.
Система, яку хотіли б отримати:
- ціль — розвиток;
- лідери команд по кожному напрямку зі своєю зоною відповідальності;
- частково самоорганізовані команди;
- виробництво повинно бути всередині штату;
- оплата нехай навіть на Приват, але через CRM-систему;
- маркетинг, продажі, саппорт працюють синхронізовано.
Помилки, які ви можете допустити при змінах
- незрозумілі цілі;
- нереалістичні дедлайни;
- ігнорування даних;
- недостача ІТ-навичок;
- недостатньо бюджету;
- невідповідна підтримка лідера;
- ігнорування клієнтів;
- внутрішній спротив.
Отже, в першому ефірі ми розглянули інструменти бізнес-моделей, формування моделі цінностей компанії та проведення змін на прикладі IAMPM.