"Щоб все працювало і юзери не скаржилися …"

"Персоналу шість душ, локалці на дві сотні робочих місць плюс серверів з десяток, телефонія, Інтернет-канал …"

Напевно, таке розуміння сфери своєї діяльності та об'єктів управління притаманне більшості ІТ-менеджерів, що мають у підпорядкуванні від двох до десятка працівників і відповідальних "за все, що з проводами, крім кавоварки ". Зазвичай такий опис сфери відповідальності влаштовує і їх керівництво – коротко і ясно. Набагато важче отримати відповідь на просте запитання -" навіщо? ". Формулювання відділу ІТ зазвичай настільки ж проста як і беззмістовна: "Щоб все працювало і юзери не скаржилися." Керівництво зі свого боку далеко не завжди розуміє не тільки чим зайняті всі ці "комп'ютерщики", але і що компанії дають сервера, Інтернет – взагалі все це комп'ютерне господарство крім хіба що ноутбука самого директора. Через це не тільки утруднено нормальне взаєморозуміння між ІТ та керівництвом компанії (наприклад, обговорення витрат на ІТ впирається в те ж питання – "навіщо?" – А пояснювати директору переваги клієнт-серверної моделі заняття часто невдячна), а й фактична користь для бізнесу від витрат і зусиль ІТ-підрозділу неізмеряема, некерована і, як наслідок, низька.

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

Отримавши завдяки такому списку відповідь на питання "навіщо?", Ми можемо по-іншому поглянути на те, чим же все-таки треба управляти. Люди, проводи, "залізо" – це необхідні інструменти ІТ-менеджера для надання бізнесу послуг. Звичайно ці інструменти вимагають керівництва, обслуговування, замін. Але організовувати треба не роботу кожної з цих складових окремо, а використання їх як єдиного цілого. Іншими словами, управляти наданням послуг.

Чи потрібна теорія?

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

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

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

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

Які цілі і як вимірювати результат?

"Схоже, нічого оригінального в цьому підході немає. Судячи з того, що ми наданням послуг управляти повинні, цілями в нас вони і будуть – нормально надані послуги (без перебоїв і з хорошими технічними характеристиками). А вже для оцінки результатів параметри відомі – швидкість обробки SQL-запиту, об'єм Інтернет-трафіку, час відгуку Веб-сервера міряти вміємо. Тільки для кожної послуги процес будувати – Чи не занадто непоказно? "

Звичайно, непоказно, а головне – не треба. Нормально надавані послуги – це наша глобальне завдання. Для її вирішення як мінімум треба: лагодити те що зламалося як можна швидше, вирішувати виникаючі проблеми, точно знати, яке ПЗ і "залізо" у нас є, мати правила впровадження нового і замін наявного. Заради цих цілей – загальних для всіх послуг – і треба вибудовувати процеси. Так що керуємо ми не самими послугами (кожній окремо), а різними аспектами їх надання: ліквідацією поломок, вирішенням проблем, змінами в інфраструктурі, її складом і конфігурацією. Звичайно, це далеко не повний список. Треба узгоджувати з керівництвом склад і опис послуг, своєчасно готувати плани модернізацій, "рахувати гроші" і своєчасно виявляти "вузькі місця", не забувати про безпеку і бути готовим до аварій. Крім того, як уже говорилося, залишаються і операційні процеси (наприклад, управління ЛВС або адміністрування СУБД).

Цілі в кожного процесу свої – або безпосередньо забезпечують належний рівень послуг (наприклад, максимально допустимий час простою може бути безпосередньо обумовлено в описі послуги) або "допомагають" іншим процесам – точна інформація про склад і конфігурації інфраструктури потрібна і при ліквідації поломок і для планування модернізацій. Але, як вже було сказано, поставити завдання мало – обов'язково треба ввести чіткі критерії оцінки досягнення цілей.

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

У цьому підході дійсно немає нічого оригінального – орієнтація на послуги, процесне управління та націленість на якість за останні десятиліття стали "загальним місцем" в менеджменті. Зручність його використання в тому, що він містить готовий набір "підказок", заснований на досвіді управління ІТ в реальних організаціях.

Я вже спробував дати відповідь на другу частину питання: "Що за теорія така – ITIL – і навіщо вона потрібна?".
Якщо від багаторазово повторених слів на кшталт "послуга", "процес", "якість" ще не заснули, а інтерес до того, яке ж воно "у справі", поввілся, обговоримо спершу:

Що ж все-таки таке цей Ітіль?

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

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

Офіційний автор – британська урядова організація OGC (Office of Government Commerce), початкової завданням якої було допомогти держ. структурам у формалізації їх відносин з підрядчиками – постачальниками ІТ-послуг. У Великобританії навіть діє офіційний стандарт на Управління Послугами (BS 15000), який базується на ITIL. Хоча формальне авторство належить OGC, в написанні беруть участь представники та організацій-замовників, і постачальників, і консультантів. У книгах описуються групи процесів (наприклад, Підтримка Послуг – Service Support), об'єднані за принципом знаходження на шкалі "Технологія – Послуги ". Ключовими вважаються дві групи – Підтримка та доставка (Delivery) послуг.

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

Як це реалізується на практиці?

"Були б гроші на консультантів – у них і питав би. А ризик невдачі є завжди, так що будемо намагатися своїм розумом доходити. Тільки з чого починати-то? І що робити з поточною роботою?"

Починати (що цілком природно) треба з читання книг Бібліотеки. На жаль, на даний момент перекладів російською немає, а за оригінальні книги доведеться викласти близько 150 доларів за штуку. Альтернативою (У всякому разі, на першому етапі) може бути покупка за 38 доларів "Введення в ITIL" (IT service management – An introduction) видання itSMF (Форуму з Управління Послугами ІТ, що об'єднує теоретиків і практиків ITIL). До речі, вже йдуть роботи з переведення цієї книжки на російську. При наявності хоча б невеликого бюджету також дуже бажано сходити на 2-3дневние курси з основ ITIL – книжки книжками, а спілкування з практиками дорогого коштує. І звичайно дуже багато чого можна почерпнути в чоти – повна картина при тільки її використанні навряд чи складеться, але корисностей можна знайти чимало.

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

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

Якщо про наявність бекапів голова вже не болить, а збій ПК став явищем рідкісним – настала пора ІТ-відділу вибудовувати взаємини з "зовнішнім світом". І в перш за все з тими, без кого його функціонування неможливо – з внутрішніми і сторонніми постачальниками зовнішніх для ІТ послуг. У багатьох реалізаціях ITIL Управління Оточенням (Environmenal Management) вважається фундаментом функціонування всієї інформаційної системи. Дійсно електрика, вентілвція, кондиціювання, зазвичай не входвщіе в сферу відповідальності ІТ-відділу, впливають на його роботу принципово. Тому поки немає спокою і впевненості в цих питаннях – рухатися далі небезпечно.

Коли вирішена і це завдання, можна нарешті переходити до реалізації першої функції з ITIL-івського блоку Підтримки Послуг – створити у відділі Центру Обслуговування. Це ще не реалізація якогось процесу (в Service Support описані п'ять процесів і одна функція – function – Service Desk), але в підтримці послуг – один з ключових елементів. Центр Обслуговування (іноді його називають Help Desk) повинен стати єдиною точкою контакту відділу з "зовнішнім світом". Таким чином вирішуються два завдання. По-перше, це спростить життя користувачам – завжди буде до кого звернутися і людина "на телефоні" не посилатиметься на те, що йому "не до дрібниць ". По-друге, появлвется можливість фіксувати, документувати і вимірювати потік робіт, що виконується відділом ІТ. Цим буде зроблено перший крок у впровадженні блоку процесів Підтримки Послуг.

Що тепер і куди далі?

"Створити єдину точку доступу – гарна думка, але ж людини виділити доведеться. А потім ще під кожен процес – окремого? А де віддача? І як власне процеси впроваджувати?"

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

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

Для того, щоб всі ці управлінські рухи тіла приносили задоволення вам і були оцінені керівництвом, потрібні "швидкі перемоги". На етапі оптимізації операційного рівня це регламентація планових робіт (а відповідно підвищення їх "прозорості" й чітке планування). У результаті ІТ-менеджеру вже не будуть снитися кошмари на тему "А що якщо PDC ляже?!" – Тепер у нього є регламентний бекап, процедура відновлення і відповідальний співробітник. У створенні Центру Обслуговування головна вигода – поява точки збору інформації про всі події, що відбуваються в ІТ. Як результат через два – три місяця ви будете мати статистику за зверненнями користувачів, з якою вже можна йти до керівництва з пропозицією про шляхи зниження їх кількості. Це вже ті самі "цифри та факти", які допомагають ІТ у розмові з Бізнесом. З цього і починається вибудовування відносин "Постачальник – Замовник".

Здається, тепер можна було б і про впровадження процесів поговорити. Але якщо до цих пір розповідати про ITIL можна було на "кухонному" рівні, тут уже потрібне строгість визначень і формулювань, знання термінології і т.д. Тому настав момент погуляти по Мережі, а краще всього відразу замовити книги Бібліотеки. Не забувайте також про цінності вербального спілкування – курси і семінари безцінне джерело знань. Успіхів у ITIL-ізації!

Процеси

Визначення

"Раз Ітіль – процесний підхід, треба напевно чітко описати, а краще визначити – що ж таке процес?"

Можна, звичайно, заглянути в тлумачний словник і прочитати там щось на кшталт:


  1. послідовна зміна станів, будь-л. явищ, хід розвитку чого-л.;
  2. сукупність послідовних дій для досягнення якого-л. результату, напр. виробничий п.

Це загалом то і так "інтуїтивно ясно". Однак з п.2 ми бачимо, що крім "процесів взагалі" є наприклад виробничий процес, так що треба йти глибше, щоб зрозуміти специфіку саме ІТІЛовскіх процесів і отримати "робоче" визначення. У ньому, по-перше, має бути зібрано специфічне для Ітіль зміст (зокрема, націленість на послуги та якість) і по-друге, дано внутрішнє будова і зовнішні зв'язки.

Отже, почнемо вишукування. Найбільш загальне визначення дає нам ДСТУ ISO 9000 – 2001: "Процес – сукупність взаємопов'язаних та взаємодіючих видів діяльності, яка перетворює входи на виходи.

У ITIL – точніше в книзі "Service support" ("Підтримка послуг") наводиться таке визначення: "A connected series of actions, activities, Changes etc. Performed by agents with the intent of satisfying a purpose or achieving a goal. "(" Пов'язаний набір дій, видів діяльності, змін і т.д., що виконується агентами з метою задоволення потреби або досягнення мети. ")

Тут додалася важлива для розуміння процесів складова – агенти. Крім того, замість виходів (про які забувати не треба, оскільки при проектуванні процесу їх доведеться виділяти і специфікувати) згадано, що у процесу є якась мета.

Ось ще одне (CobiT): "Процес – це дія, спрямована на досягнення результату, що може коригуватися при його виконанні і яке зосереджено на досягненні кінцевого результату при оптимальному використанні ресурсів. "

Звідси ми можемо взяти дві речі: процес повинен управлятися (коригуватися) і його треба будувати оптимально.

Можна напевно знайти корисні зерна і в інших джерелах, але більшість так чи інакше повторюють вже сказане. Наприклад в PMBOK 2000 edition читаємо: "series of actions bringing about a result". Так що перейдемо до того, з чого він складається. Пропонується такий розподіл процесу на складові:



Крім того, треба не забути про те, що процеси треба якось описувати. Для цього існує процедура – опис логічно пов'язаних діяльностей та їх виконавців (для більшої деталізації і зручності зазвичай складають набір Робочих інструкцій, які визначають, як слід виконувати види робіт, що входять до складу процедур).

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

Постараємося тепер нічого не втратити але і без зайвого обійтися:

Процес – це циклічний та відтворюваний набір логічно пов'язаних діяльностей, спрямованих на досягнення загальних цілей, описаних процедурами і виконуваних менеджером процесу та іншими ролями (агентами) з використанням виділених ресурсів, керований власником для оптимізації за витратами з використанням вимірюваних характеристик (метрик), який перетворює певні входи в контрольовані за якістю виходи.
(Process – a cyclic and reproduced set of logicaly related activities connected by general targets, described by procedures and performed by process manager and other roles (agents) using allocated resources, controlled by the owner to be optimal in efforts and costs using measured indicators (metrics), which convert specified inputs into the quality controlled outputs.)

Можливо, результат вийшов громіздким, але зате тепер ми знаємо, що таке процес "по-ІТІЛовскі".
Методика впровадження процесів.

"Визначення значне. Тільки з нього все одно не ясно, як ці процеси створювати, в сенсі вибудовувати."

Спробуємо коротко прикинути, в якому порядку і що саме треба робити, щоб "побудувати" ІТІЛовскій процес.

Отже:



Послідовність впровадження ITIL-процесів

"Дуже добре, можна приступати. Починати напевно треба з Процесу Управління Послугами – адже він ключовою."

Дійсно Управління Послугами – у своєму роді "центральну ланку" для всіх ІТІЛовскіх процесів. У створюваній "з нуля" організації або підрозділі починати саме з нього може бути правильно. Але для вже функціонуючої структури це не найкращий шлях. Перед тим, як відповісти собі на питання "за який процес братися в першу чергу", треба зрозуміти "що маємо", тобто оцінити ступінь зрілості як усього ІТ в цілому, так і груп процесів управління ІТ. Звичайно, для оцінки групи процесів доведеться розглядати кожен, але для того, щоб вирішити, з якого процесу починати, потрібна інтегральна оцінка зрілості груп.

Методик оцінки зрілості існує чимало й тут не місце обговорювати їх і порівнювати. Припустимо, що обрана якась методика, проведено оцінку і на виході у нас для кожного процесу – бал від 0 до 5. Тепер треба розглянути оцінки за групами (Operational, Support, Delivery). Якщо в групі Операційних процесів є хоч один з балом нижче трійки – забудьте тимчасово про "відносини Бізнесу та ІТ" та інші високі слова – підготуйте собі тили (у даному контексті під Операційними процесами мається на увазі все те, що називають Technical, Operations, а також Environmenal Management). Однак не треба забувати про наступну мети – рівні Підтримки Послуг. На ньому є безцінна функція – Центр Обслуговування, яка може допомогти і на етапі приведення в порядок операційного рівня. Отже, перший крок при такому розкладі – створення Центру Обслуговування і "" доведення до розуму групи операційних процесів (всередині неї – Technical => Operations => Environmenal, докладніше – залежить від використовуваних технологій).

Говорячи про групу процесів Підтримки Послуг, можна запропонувати такий порядок: спершу Управління інцидентами та Проблемами (разом з "причісуванням" Центру Обслуговування), потім Зміни, потім Конфігурації і Релізи. Знову ж таки треба пам'ятати про наступної мети – Доставці Послуг – і паралельно з процесами рівня Підтримки хоча б контурно окреслити рамки і зміст Процесу Управління Послугами.

Заробивши мінімум по три бали процесам підтримки, можна довести до розуму Управління Послугами і … зробити крок в сторону від доставки послуг, задумавшись над тим звідки вони (послуги) беруться. Звичайно якщо у вашій організації набір сервісів вкрай стабільний і з його зміною цілком справляється операційний рівень – можете не хвилюватися. Якщо ж час від часу присутній якийсь development – саме час зайнятися саме їм. Так що наступний крок – Production Management.

Якщо ви дісталися до цієї стадії – напевно самі розберетеся, в якому порядку впроваджувати Availability, Capacity і Continuity Management. А Управління Фінансами раджу залишити "на солодке" – з нього плавно перейдете на Business – IT alignment, займете місце CIO …

Все вищесказане стосується в першу чергу до тих ІТ-структурам, в яких ідея жити по-ІТІЛовскі йде "зсередини". Якщо ж до вас "зверху" надійшла вказівка "впровадити SLA за три місяці" – подітися нікуди, порядок впровадження буде зовсім іншою. Крім того, це тільки загальні принципи, описувати же порядок для всіх варіантів результату оцінки зрілості – за окремі гроші. А тонкощів може спливти чимало. Наприклад, якщо процес Service Continuity Management отримав нуль балів – киньте все і готуйтеся до пожежі-повені-землетрусу. Так що вивчайте уважно best practice.
І не забувайте – ITIL <=> IMHO).

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*