Давайте разберём уровни зрелости ИТ-процессов на примере управления инцидентами. Это всё то, что сыплется на ИТ-отдел в виде тикетов от пользователей, шефа, текущих задач и всего, что надо сделать. Забегая чуть вперёд, скажу, что в среднем по стране у крупного бизнеса с инцидентами довольно хорошо, в большинстве случаев это 4-й уровень. Ну просто потому, что работа со сбоями — это первое, по чему судят об ИТ-отделе.
Первый уровень — это когда:
- ИТ-отдел работает без распределения обязанностей и специализаций. Все отвечают за всё (точнее, ни за что), принцип выбора исполнителя — «Вася, ты свободен, ну, сделай им там».
- Ответственности нет: если Вася забыл, непонятно, кому писать, непонятно, как и что на что влияет, пользователи вообще не разбираются, кто и что делает. И иногда бьются в истерике.
- Документации нет.
- Автоматизации нет (либо есть на уровне списка задач в блокноте).
- Пользователи почти всё решают по личным знакомствам, обращаясь к тем, кто им уже один раз помог.
На втором уровне появляется базовое распределение обязанностей и вычленение логичных последовательностей действий.
Если точнее, то второй уровень:
- Распределение обязанностей. Внутри ИТ-отдела каждый знает, за какую часть работы отвечает и какие недоработки на чьей совести.
- Появляются последовательности действий. Это пока не процессы и best practice, а как бывает при строительстве нового жилого дома. Сначала (на первом уровне) жильцы ходят к метро кто как, а потом появляется тропинка по диагонали через газон. Она негласная, но работает. Никто не знает, может, её перегородят, но пока работает — не трогай. Так и здесь с процессами. Они обычно не документированы, но алгоритм намётанный уже есть.
- Процесс передаётся договорённостями между людьми, традициями.
- Есть понятийное понимание сроков (чаще всего на уровне того, что главный админ знает, за что его отдел ругают). При ошибках пользователи всё равно жалуются своему начальнику, потому что не понимают, как всё устроено. Тот уже пишет операционному директору, он — ИТ-директору, ИТ-директор спускает до эникея Васи.
- Состав стабильный — «Мы дружелюбным зоопарком помогаем людям».
- Обучение есть, но основано на традициях.
- В роли автоматизации — группа «Вконтакте» для тикетов или внутренний форум компании.
- Если отчёт есть, то он из серии «Хирург читает ЭКГ» — непонятно кому, зачем и что там.
Третий уровень — время собирать камни и писать документацию:
- Договорённости формализуются. Появляются инструкции и регламенты работы, всё чаще начинает всплывать слово «ITIL». Новым людям объясняют уже не на пальцах, а по чек-листу. Всего на бумаге ещё нет, но стандарты уже чёткие. Что такое «подготовить рабочее место», однозначно понятно: уже есть список из 20 пунктов, где пропускать ничего нельзя.
- Есть базовая автоматизация — тикет-система. На этом уровне по типу тикета уже назначает ответственный, система знает, что после выполнения заявки надо оповестить пользователя. Часть документированных действий вроде «закрыл задачу — сообщил пользователю» ложится на систему.
- Бизнес начинает участвовать в жизни ИТ — если раньше сисадминов держали как домашних животных (вроде не гадят и помогают — и то жизнь), то теперь вместе с ними планируют. Правда, пока на уровне «Пацаны, мы открываем 18 новых филиалов и нам срочно нужно в регионы. Хрен с ними, тормозами на все тикеты, кроме бухгалтерских, следующие два месяца открываем точки».
- Появляется отчётность и необходимость рассказывать, что вообще делает отдел. Правда, пока это тупо количество заявок.
- Вероятность действий в обход процессов средняя. Бывает, покупаются нестандартные железки, заявки иногда закрываются без отчёта, есть заявки мимо системы по знакомствам и так далее.
- Появляются формальные требования к кандидатам, понимание того, какое у них должно быть обучение.
- Появляется база знаний на уровень какого-то внутреннего википортала, но нет процесса внесения туда новых данных.
- Нецентрализованные системы — у каждого филиала может стоять своё ПО и быть свой сервисдеск.
Четвёртый уровень — время соединения с бизнесом и рефакторинга всего того, что понакостыляли на третьем:
- Раньше был просто отчёт, а теперь отчёт читают, и он аналитический. На основании его данных меняются процессы, планируется бюджет.
- То, что раньше делалось плохо или медленно (и что можно улучшить), улучшается по процессам.
- Есть регулярно обновляемая база знаний, она же — основной источник данных для молодых стажёров.
- Инструментальные средства централизованные, ПО стремится к гомогенности.
- Банально всё стало структурировано, отрефакторено в сравнении с третьим уровнем (от состояния «эти уроды хотят отчёт» до «а, так они по этому отчёту наш бюджет считают») и работает как часы. Насколько возможно.
- Есть бюджет на экстренные покупки мимо процессов. У нас, например, это ящик водки для промывки кондиционера дата-центра (https://habrahabr.ru/company/croc/blog/268169/).
- Обучение. Оно есть и уже выросло в совсем сознательное. Настолько сознательное, что могут даже целую статью в бюджете выделить и планировать заранее, и в профильных компаниях. А ещё на этом уровне всплывает вопрос сертификации. Вот ещё в моё время у нас на техподдержке за испытательный срок нужно было cдать экзамен на 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.
Автор: КРОК
