ІТ стратегія: розробка або опис?

Хто і коли розробляє стратегію для внутрішніх ІТ-підрозділів?

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

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

Директор з інформаційних технологій і стратегія

Є поширена думка, що бізнес повинен ознайомити ІТ керівника зі своєю стратегією, а той на її підставі напише стратегію ІТ. Таку ситуацію прийнято класифікувати як стратегічне планування. Насправді якщо стратегія бізнесу готова, то там мало вільного місця для розробки ІТ-стратегії. Швидше виявляється, що потрібно шукати конкретні ІТ-рішення для втілення наявною бізнес-стратегії, тобто для стратегічного планування.

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

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

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

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

ІТ-департамент і сили Портера

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

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

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

Ось ще приклад. Наявність вільно розповсюджуваних додатків з підтримкою аудіо- та відеоспілкування, таких як Skype, Live Messenger, ICQ і т.п. ускладнює впровадження корпоративної відеоконференц-зв'язку.

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

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

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

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

Типологія ІТ-стратегій

Які стратегії найбільш часто зустрічаються в ІТ-підрозділах? Проаналізувавши висловлювання ІТ-директорів на конференціях і в ЗМІ, я виділив три найбільш поширених типи стратегій.

Стратегія «акуратних бібліотекарів»

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

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

Стратегія економії на витратах

ІТ-підрозділ є витратним за своєю суттю. Нерідко предметом виправданою гордості ІТ-директора стає прозора структура витрат на ІТ. Це значуще досягнення - справді, не кожне підрозділ в компанії може пишатися прозорістю і прогнозованість своїх витрат. І тоді ІТ-директор проголошує стратегічною метою економію на витратах, пов'язаних з ІТ.

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

Стратегія нарощування капіталізації

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

На жаль, в даному випадку цілі підміняються результатами. Дійсно, результатом впровадження інформаційної системи буде постановка на баланс, але це не мета впровадження. Цілі впровадження інформаційної систем лежать в іншій площині і пов'язані з підвищенням ефективності і т.п.

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

Структура оптимальної стратегії

ІТ-стратегія складається з наступних блоків:

• Місія - коротке визначення сенсу існування ІТ підрозділу;

• Цілі - напрямки діяльності;

• Завдання - дії, спрямовані на досягнення цілей;

• Тактики - особливі дії по виконанню завдань;

• KPI - показники, що дозволяють оцінити досягнення при виконанні завдань.

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

Обрій. небокрай. Йтиметься про короткострокову стратегії з горизонтом один-три роки для середнього ІТ-підрозділу з десятьма-двадцятьма функціями.

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

Аналіз - синтез. Осяяння, бачення, інтуїтивність приймаються як допомогу, але не як метод. Необхідно зібрати дані про поточний стан справ, проаналізувати їх і тільки після цього намагатися синтезувати цілі і можливі тактики їх досягнення. Визначити недосяжні цілі найлегше, але це підходить тільки для героїв і камікадзе. Класичним інструментом аналізу поточного стану справ є SWOT-аналіз - аналіз переваг, недоліків, сприятливих і заважають обставин (strengths, weaknesses, opportunities, threats, SWOT).

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

• впроваджувати готові галузеві інформаційні системи відповідно до практиками TM Forum;

• побудувати процеси компанії відповідно до eTOM;

• реалізувати модель безпеки відповідно до ISO і BS;

• реалізувати сервісну модель роботи ІТ підрозділів.

Можуть бути й інші стратегічні завдання, наприклад, використовувати тільки рішення на основі LAMP (Linux, Apache, MySQL, PHP) і т.п. На мій погляд, три-чотири стратегічні завдання - це максимум того, що потрібно розробити на термін один-два роки. На більш тривалий період робити це немає сенсу - ніхто не запам'ятає 20 завдань, а значить, стратегія вийде формальної і нездійсненною.

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

На наступному кроці потрібно визначити цілі, на досягнення яких можуть бути спрямовані дії. Цілі повинні бути вимірюваними. Загальновідомий зручний критерій коректності мети - SMART (Specific, Measurable, Achievable, Realistic, Timely - точність, вимірність, досяжність, реалістичність, своєчасність).

Наступні цілі, наприклад, відповідають завданням, наведеним вище, і критерієм SMART:

• підвищення частки успішно завершених ІТ-проектів на 30% протягом двох років;

• оптимізація запланованих витрат на ІТ на 50% за рахунок створення трьох центрів компетенцій - центру систем електронного документообігу; фінансового та аналітичного центру; єдиного центру обліку мережевих ресурсів і моніторингу мережі протягом трьох років;

• підвищення якості ІТ-послуг за наступними параметрами: час обробки ІТ-запиту скоротити на 40% протягом року; готовність систем в офісне час не менше 99,9% протягом року.

Сенс визначення цілей в тому, щоб встановити зрозумілий критерій виконання завдань. Завдання можуть залишитися тими ж на наступний період, а цілі - змінитися.

Як визначити, чи завершена завдання, не маючи конкретної мети? На жаль, дуже часто на практиці зустрічаються підрозділи, які виконують свої завдання, але не мають вимірних цілей.

Тонкощі російської мови

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

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

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

Аргументи «проти»

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

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

• все, що я роблю, спрямоване на стратегію;

• у мене мало інструментів для управління стратегією;

• у мене немає часу займатися стратегією щотижня, але щоквартально - а краще щороку - я готовий, починаючи з наступного року;

• діяльність інших підрозділів мене відволікає, я працюю на них, а не на стратегію;

• не розумію, як інші керують стратегією;

• немає зв'язку між операційними пріоритетами, що змінюються щодня, і стратегією;

• ми «маленькі» в рамках групи компаній, і наш внесок у стратегію непомітний;

• чому я повинен реалізовувати стратегію інших бізнесів?

• у мене немає інформації про загальну стратегію, крім того, мені незрозуміло, як її дотримуватися.

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

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

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

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

Федір Краснов - віце-президент по бізнес-процесам та інформаційних технологій компанії «Акадо», [email protected]