Як визначити рівень ІТ-зрілості своєї компанії — і які вони бувають



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

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

Якщо точніше, то другий рівень:
  • Розподіл обов'язків. Всередині ІТ-відділу кожен знає, за яку частину роботи відповідає і які недоробки на чиїй совісті.
  • З'являються послідовності дій. Це поки не процеси і best practice, а як буває при будівництві нового житлового будинку. Спочатку (на першому рівні) мешканці ходять до метро хто як, а потім з'являється стежка по діагоналі через газон. Вона негласна, але працює. Ніхто не знає, може, її перегородять, але поки працює — не чіпай. Так і тут з процесами. Вони зазвичай не задокументовані, але алгоритм досвідчене вже є.
  • Процес передається домовленостями між людьми, традиціями.
  • Є понятійне розуміння термінів (найчастіше на рівні того, що головний адмін знає, за що його відділ лають). При помилках користувачі все одно скаржаться своєму начальнику, тому що не розуміють, як все влаштовано. Той вже пише операційного директора, він — ІТ-директор, IT-директор спускає до эникея Васі.
  • Склад стабільний — «Ми доброзичливим зоопарком допомагаємо людям».
  • Навчання є, але засноване на традиціях.
  • В ролі автоматизації — група «Вконтакте» для тікетів або внутрішній форум компанії.
  • Якщо звіт є, то він із серії «Хірург читає ЕКГ» — незрозуміло кому, навіщо і що там.


Третій рівень — час збирати каміння і писати документацію:
  • Домовленості формалізуються. З'являються інструкції і регламенти роботи, все частіше починає спливати слово «ITIL». Новим людям пояснюють вже не на пальцях, а з чек-листом. Всього на папері ще немає, але вже чіткі стандарти. Що таке «підготувати робоче місце», однозначно зрозуміло: вже є список з 20 пунктів, де пропускати нічого не можна.
  • Є базова автоматизація — тікет-система. На цьому рівні за типом тікета вже призначає відповідальний, система знає, що після виконання заявки треба сповістити користувача. Частина документованих дій на зразок «закрив завдання — повідомив користувачеві» лягає на систему.
  • Бізнес починає брати участь в житті ІТ — якщо раніше сисадмінів тримали як домашніх тварин (начебто не гадять і допомагають — і то життя), то тепер разом з ними планують. Щоправда, поки що на рівні «Пацани, ми відкриваємо 18 нових філій і нам терміново потрібно в регіони. Хрін з ними, гальмами на всі тікети, крім бухгалтерських, наступні два місяці відкриваємо точки».
  • З'являється звітність і необхідність розповідати, що взагалі робить відділ. Правда, поки це тупо кількість заявок.
  • Ймовірність дій в обхід процесів середня. Буває, купуються нестандартні залозки, заявки інколи закриваються без звіту, є заявки повз системи по знайомствам і так далі.
  • З'являються формальні вимоги до кандидатів, розуміння того, який у них має бути навчання.
  • З'являється база знань на рівень якогось внутрішнього википортала, але немає процесу внесення туди нових даних.
  • Нецентралізовані системи — у кожної філії може стояти ЗА своє і бути свій сервисдеск.


Четвертий рівень — час з'єднання з бізнесом і рефакторинга всього того, що понакостыляли на третьому:
  • Раніше був просто звіт, а тепер звіт читають, і він аналітичний. На підставі його даних змінюються процеси, планується бюджет.
  • Те, що раніше робилося погано або повільно (і що можна поліпшити), поліпшується за процесами.
  • регулярно оновлювана база знань, вона ж — основне джерело даних для молодих стажерів.
  • Інструментальні засоби централізовані, прагне до гомогенності.
  • Банально все стало структуровано, отрефакторено в порівнянні з третім рівнем (від стану «ці виродки хочуть звіт» до «а, так вони за цим звітом наш бюджет вважають») і працює як годинник. Наскільки можливо.
  • Є бюджет на екстрені покупки повз процесів. У нас, наприклад, це ящик горілки для промивання кондиціонера дата-центру (https://habrahabr.ru/company/croc/blog/268169/).
  • Навчання. Воно є і вже виросло зовсім свідоме. Настільки свідомий, що можуть навіть цілу статтю в бюджеті виділити і планувати заздалегідь, і в профільних компаніях. А ще на цьому рівні спливає питання сертифікації. Ось ще мій час у нас на техпідтримку за випробувальний термін потрібно було здати іспит на MCP (Microsoft Certified Professional).
  • Важливість вирішення тікетів вимірюється в звездюлях від начальства, але вже вимірюються і грамотно ставляться пріоритети.


П'ятий — це коли айтішників сприймають не як загадкових хлопців з підвалу, а як партнерів у бізнесі:
  • CIO і керівники команд знають про плани розвитку бізнесу, коригують плани ІТ відповідно. Та й взагалі, CIO наближається до керівників бізнес-підрозділів, його хоча б кличуть на основні наради і слухають.
  • Постійно покращують процеси в потрібну сторону, часто підказують бізнесу, як можна зробити краще стратегічно.
  • Децентралізація. Завдання вирішуються власниками процесів, тобто тепер відповідальний цілком і повністю вирішує, що і як йому робити (а не запитує керівника кожен раз), але і несе всю відповідальність. Звернення йдуть не через начальника, а безпосередньо відповідальним.
  • Впроваджені кращі світові практики за напрямами. Про ITIL, COBIT і ISO 20 000 не тільки всі чули, але й читали. Деякі — у примусовому порядку.
  • Підсистеми автоматизації проникли один в одного повністю і ставлять пов'язані тікети, вивантажують один одному дані і взагалі правильно працюють. Мінімум ручної рутини.
  • Персонал п'є разом з бухгалтерією (хоча, звичайно, конкретно це — не критерій зрілості), є обмін досвідом (коли читають свої лекції всередині компанії, наприклад), є зовнішнє навчання кшталт «Основи психології», «Самозахист на підприємстві», «Як з гною і палиць зібрати ДГУ». В гості приїжджають лідери галузі та зовнішні експерти для консультацій, коли піднімається складна або нова тема.


Так от, в Росії в середньому — 4 або близько того. Саме з управління інцидентами. З управління конфігураціями (облік інформації про склад інфраструктури, середовищах) та управління змінами (погодження змін та їх реалізація) — приблизно 3 з 5. Це так, в середньому по лікарні, в середніх і enterprise-компаніях.

Посилання:

  • Визначити самостійно можна тут за досить швидкого тесту. Це XLS-файл, ви вибираєте пункти, вам показується результат прямо в таблиці.
  • Методологія ділення на рівні прийшла з ITIL, а звідти вона прийшла з CMMI/CMM. Спочатку в 1991-му з'явилася модель зрілості (CMM), в якій структуровано представлені рівні зрілості процесів для розробки.
  • У 2010-му створена методологія CMMI — більш розширений опис, вже про зрілість процесів в організації взагалі:
  • Моя пошта — dmkorolev@croc.ru.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.