Типові процеси і типові впровадження (вибачте, наболіло) - real itsm все про itil, cobit, prince2 і

Ось що я думаю про всі ці "типових" принади (запрошую до дискусії). Пояснюю собі це на прикладі компанії N, якій треба організувати у себе процес управління. ну скажімо змінами (тобто треба зробити так, щоб співробітники цієї компанії "з понеділка" почали вносити зміни в ті чи інші системи, послуги, продукти та інше не аби як, а керуючись опредёленнимі правилами). Далі перераховані варіанти вирішення завдання в порядку віддалення від кінцевого результату (тобто фактичної організації роботи).

1. Типове впровадження
Передбачає не тільки типову модель процесу (що це таке дивимося нижче), але і типове рішення задачі суміщення процесу з даної конкретної компанією, тобто з організаційної та географічною структурою, персоналіями і їх рівнем компетенції, системою стимулювання (або як частіше говорять "мотивації" ), корпоративними стандартами (наприклад, в галузі управління якістю або внутрішнього контролю) і так далі. За визначенням типове впровадження можливе тільки в такій компанії, яка всіма своїми перерахованими особливостями схожа на іншу компанію, де такий процес вже впроваджений, тобто виконується тиражування. Як правило, це реалістично тільки при впровадженні в групі компаній, що складаються з набору типових підприємств, що володіють стандартною структурою. Наприклад, група електростанцій в складі ТГК. Стандартний процес управління зміни вже спроектований і затверджений (у вигляді корпоративного стандарту), тепер ми організуємо його виконання на конкретній електростанції. Якщо все піде добре (будемо оптимістами!), То компанія Ni. яка входить до групи компаній N за результатами типового впровадження дійсно має шанс вирішити поставлене завдання - організувати діяльність з управління змінами відповідно до заданих правил.

2. Типовий процес
Правильніше було б сказати "типова модель процесу" (управління змінами), яку ще тільки належить адаптувати до компанії N і запустити в роботу. Що включає в себе модель процесу? Як мінімум:

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

Підкреслю, це мінімум. Саме про типові процеси багато в чому написані книги ITIL (особливо це відноситься до ITIL v2). Тобто наявність типових моделей процесів не гарантує ні унікальною компетенції команди впровадження (неважливо з боку консультантів або замовника), ні тим більше досягнення результату - організації діяльності. Спрощено кажучи, типовий процес це набір документів. Запитайте себе, якщо б у Вашій компанії завтра з'явився набір паперів з управління змінами (не соромтеся в фантазіях - 50 сторінок, 100 сторінок, 200?) Цього було б достатньо для того, щоб зміни виявилися під контролем, а Ви, як керівник, знайшли спокійний сон?

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

Типовий процес далі від консалтингу і ближче до готового продукту. З чого Ви починаєте вибір автомобіля? Правильно, з вивчення і порівняння комплектацій! І не чекайте, що продавець автомобіля заодно навчатиме Вас безпечного водіння. Краще уточнити: "Що я отримаю крім автомобіля (стопки процессной документації)? Які завдання я зможу вирішити?". Відповідь скаже про продавця набагато більше, ніж пропонований цінник.

3. Типова (версія коробочки) система автоматизації
Являє собою конфігурацію системи автоматизації, яка містить готові елементи автоматизації процесів (схему workflow, ролі і їх повноваження, об'єкти з потрібними зв'язками і атрибутами, форми, правила бізнес-логіки та інше). Небезпека полягає в тому, що система сама по собі (навіть дуже потужна, гнучка, безпечна, зручна і масштабована) не «диктує" процес (може бути тільки окремі елементи, наприклад - статуси запиту на зміну, набір пріоритетів, повноваження в залежності від ролі і етапу обробки). І вже тим більше система автоматизації не забезпечує виконання та контроль процесу.

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

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