Підприємницька цінність ІТ для бізнесу, Економіка та Життя
Бізнес вкладає в ІТ-проекти великі кошти, і ці витрати постійно зростають. А яка віддача від таких інвестицій та як її оцінити? Однозначної відповіді наразі немає. Існує поширена точка зору, що цінність ІТ для бізнесу визначається вигодами від ІТ-проекту у вартісному вираженні (збільшення доходу або зниження витрат, або ROI). Але це спрощений підхід. У чому ж підприємницька цінність інформаційних технологій для бізнесу? Чого чекає бізнес від них та як досягти бажаного? Коли ІТ-проект виявляється ефективним? Спробуємо розібратися.
Існують різні підходи щодо визначення цінності ІТ. Вона залежить від тих завдань, які має вирішити ІТ-проект. Наприклад, топ-менеджерам корпоративні ІТ допомагають реалізувати стратегічні цілі та плани бізнесу, зменшити ризики, отримати вигоди. Інвестори розраховують на рентабельність проекту та повернення вкладених коштів. Менеджери середнього рівня сподіваються забезпечити якісну підтримку бізнесу у межах певного бюджету. Для продавців (консультантів) важливими є просування та продаж власних продуктів та послуг.
Для бізнесу ІТ-проекти – інструмент для створення та збільшення вартості. Бізнесу потрібна комерціалізація змін, які роблять ці проекти. І підприємницьку цінність для нього становлять лише зміни, що підтримують наявні конкурентні переваги та розвивають нові. У зв'язку з цим бізнес чекає від шефа ІТ (CIO) плану комерціалізації ІТ-ініціатив. Головним інструментом такої комерціалізації є комерційна бізнес-модель (КБМ). Розглянемо її.
Щоб зрозуміти, як зміни здатні призвести до конкурентних переваг, необхідно мати не менеджерський, а підприємницький погляд назміни. Представимо його у вигляді комерційної бізнес-моделі, що складається з відповідей на шість питань, що характеризують сферу можливих змін.
1. Хто замовник мого продукту?
2. Яку цінність я створюю для нього? Як він збирається використати мій продукт? За що він мені платитиме?
3. Як ця цінність має створюватися?
4. Як я зможу отримати прибуток від цього (п. 1-3)?
5. Як я зможу захистити створену мною цінність і прибуток від конкурентів (у чому мої конкурентні переваги)?
6. Як усе це (п. 1-5) працює на мою стратегію?
Відповіді на перші п'ять питань "великими мазками" визначають, за рахунок чого живе бізнес. На шосте питання бізнес відповідає рідко, оскільки не завжди має виразну стратегію.
Зазначені питання є основними в будь-якому бізнес-плані. Отримавши відповіді, можна зрозуміти, які зміни потрібні компанії. Саме ці питання насамперед цікавлять інвесторів та перетворюють ідеї на інновації. Здійснити зміни можна за допомогою ІТ-проекту. Він допоможе перейти від старої КБМ до нової, яка співвідноситься з ІТ-проектом як очікуваний результат та спосіб його досягнення.
У ІТ-проектах КБМ описує механізм формування та підтримки конкурентних переваг бізнесу. У цей механізм мають бути вбудовані методики оцінки бізнес-ефекту від інвестицій у ІТ. Тільки тоді вони набудуть індивідуальної для кожної компанії конкретики. Підприємцеві, який починає новий проект, важлива не точна оцінка, СКІЛЬКИ він запрацює, а розуміння, ЯК він це зробить. У разі високої невизначеності можливі лише загальні, грубі оцінки, засновані на здоровому глузді, а чи не на витончених методиках. КБМ – не методика оцінки ідей, а правило їх комерціалізації. Детально прописана КБМ (механізмкомерціалізації ініціативи) дозволяє деталізувати цю оцінку, моделювати її і, головне, вести ітераційний контроль, чи ми рухаємося в потрібному напрямку при реалізації такої ініціативи.
Для бізнесу такий підхід — звична практика. Поширення її на ІТ допомагає вибудувати діалог між керівниками ІТ-служб (CIO) та бізнесом звичною для нього мовою. Чим вищий рівень бізнес-керівника, що більше він занурений у підприємництво, то краще він розуміє мову КБМ. Чим нижчий рівень, тим більше значення для нього набуває мова бізнес-процесів, регламентів та показників. І це не просто різні мови, це різні картини світу. Чим потужніші конкурентні переваги бізнес хоче отримати від ІТ, тим більш радикальні та масштабні зміни він має бути налаштований. І вони завжди будуть пов'язані з великими витратами, термінами та ризиками. Бізнес та ІТ-служби мають бути готовими до того, що при реалізації, наприклад, системних змін не вдасться обійтися невеликим набором управлінських практик. Може знадобитися цілий арсенал. Одного класичного управління проектами буде замало. Прийде освоювати програмне або навіть портфельне управління проектами. У процесі реалізації одного ІТ-проекту можуть виникнути інші, здатні дати основний ефект.
Для впровадження змін часто залучають зовнішніх підрядників. Однак у разі системних змін бізнесу та ІТ-службам доведеться брати до рук управління ІТ-проектами, пов'язане з високими ризиками. Чим радикальніше зміни, тим більше ІТ-проекти перетворюються на бізнес-проекти і тим більше значення набуває конструктивний діалог між CIO і топ-менеджментом. І тут важливо знайти компроміс між НАВІЩО та ЯК впроваджувати та використовувати ІТ.
Зміни у бізнесі
Зміни у бізнесі можна класифікувати за рівнем радикальності. Розглянемо три основні види змін.
Поліпшення (раціоналізація) викликають локальні зміни у бізнесі та супроводжуються невеликими локальними ефектами. Ризики таких змін невеликі.
Системні зміни пов'язані з глибоким розбудовою всіх областей бізнесу. Супроводжуються суттєвими ефектами щодо створення сильних конкурентних переваг та значними ризиками.
Радикальні зміни спрямовані створення нового бізнесу чи досягнення галузевого лідерства. Такі зміни є вкрай ризикованими.
Чим вищий ступінь радикальності змін, тим більший масштаб їхнього впливу на компанію та невизначеність умов, у яких вони реалізуються. Для керування такими змінами застосовують різні форми керування проектами. Розглянемо приклади змін, пов'язаних із використанням ІТ. При цьому КБМ розпишемо для замовника та зовнішнього виконавця ІТ-проектів.
Розглянемо проект впровадження окремого модуля "Управління фінансами" ERP-системи у фінансових службах дочірніх підприємств холдингової структури із серійним виробництвом електродвигунів. Проектом впровадження займається зовнішній підрядник – системний інтегратор.
Оскільки в серійному матеріальному виробництві скорочення термінів підготовки фінансової звітності лише опосередковано впливає на загальні показники бізнесу, у замовника відбудуться локальні зміни, вони торкнуться КБМ лише у плані прибутку (п. 4 табл. 1).
Досягнення очікуваних результатів від ІТ-проекту залежить і від підрядника, що залучається, і від замовника. І для ефективної організації управління проектом необхідно скласти КБМ підрядника як конкретного проекту. Даний проект близький до типового, його невизначеність пов'язана із забезпеченням необхіднимиресурсами (п. 4 табл. 2). Коли ситуація на ринках замовника у період реалізації ІТ-проекту стабільна, ризики будуть мінімальними.
Управління таким проектом добре лягає, наприклад, стандарт Project Management Body of Knowledge (PMBoK). Як правило, у разі невеликих локальних раціоналізаторських змін проект не відкривають, керування здійснюється в рамках моделей керування змінами, наприклад, як в управлінні ІТ-сервісами.
Розглянемо складніший проект - комплексне впровадження ERP-системи на тих же підприємствах холдингової структури. Він орієнтований постановку наскрізного планування всього ланцюжка: постачання — запаси — виробництво — збут з урахуванням моделі планування MRP.
У замовника відбудуться системні зміни, вони торкнуться практично всіх аспектів моделі (п. 2-6 табл. 3).
Зміни ризиковані як для замовника, але й підрядчика. В основі таких змін мають бути потужні стимули — боротьба за виживання та лідерство. При реалізації системних змін важливо пам'ятати про дві відправні точки. По-перше, треба розуміти, хто є замовником. По-друге, замовник та виконавець мають стати стратегічними партнерами (п. 1 та 6 табл. 4). Інші пункти КБМ — зони, де виникає невизначеність. Їх потрібно постійно вибудовувати у процесі впровадження проекту.
Системні зміни у бізнесі неможливо здійснити за допомогою одного проекту. У прикладі впровадження ERP-системы лише перший проект комплексної програми розвитку. Вона передбачає реалізацію проектів щодо впорядкування та нормування виробництва, а можливо, і його модернізації, побудови нових партнерських схем роботи з контрагентами, а також щодо розвитку персоналу та організації. Наведені проекти взаємопов'язані, і зупинка одного з них здатнапризвести до зупинки всієї програми. На керування такими формами організації орієнтовані стандарти управління програмами, наприклад, стандарт PMI. Не багато системних інтеграторів вирішуються на проекти, що далеко виходять за межі ІТ-компетенцій.
Радикальні зміни розглянемо на прикладі створення та виведення на ринок нової пошукової системи Google. Період 1998 (стартап) - 2002 (отримання прибутку).
Радикальні зміни є вкрай ризикованими, і всі шість пунктів КБМ вважаються зоною високої невизначеності. Проекти з реалізації подібних змін не укладаються у класичні стандарти управління проектами, наприклад, у стандарт PMBoK. У стандартному управлінні проектами ключові параметри: замовник проекту, цілі та способи їх досягнення чітко визначені і не змінюються. У разі вони визначені нечітко і змінюються. Управління такими проектами реалізується в рамках екстремального управління проектами та є областю венчурного (високовикористаного) бізнесу.
Однак не кожний екстремальний проект призводить до радикальних змін. Навіть типовий проект невмілими діями його учасників можна перетворити на екстремальний. У цьому випадку КБМ не змінюється і типовий проект залишиться, як і був, простим покращенням, але в екстремальному виконанні.
Масштаб змін та форми організації проектів