Давайте разберём уровни зрелости ИТ-процессов на примере управления инцидентами. Это всё то, что сыплется на ИТ-отдел в виде тикетов от пользователей, шефа, текущих задач и всего, что надо сделать. Забегая чуть вперёд, скажу, что в среднем по стране у крупного бизнеса с инцидентами довольно хорошо, в большинстве случаев это 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.
Комментарии (30)
dimaka1256
18.08.2016 11:14+8Где нулевой уровень?
- Эникей (старательно пытающийся вырасти в админа) Вася сам бегает от звонка до звонка и что не забыл, то и сделал?
- Документация на уровне десятка листов А4 почерканных карандашом
- У пользователей нет альтернативы, кроме как учиться самим
- Мелочи Вася покупает на свои и даже частенько получается выбить деньги у бухгалтерии обратно
- Бизнес думает: за что мы этому болвану платим зарплату?
DKorolev
18.08.2016 12:01+1В компании, где есть ИТ (а в этом посте именно такие и рассмотрены), всегда, хотя бы на каком-то уровне зрелости есть процесс управления инцидентами. 0 уровень зрелости – это когда процесса вообще нет, то есть деятельность не осуществляется. А в компании, где есть ИТ, всегда есть процесс управления инцидентами (хотя бы какой-то).
Описание, которое приведено, практически полностью относится к уровню зрелости 1. Единственное — справедливости ради нужно сказать, что вариант «Бизнес думает: за что мы этому болвану платим зарплату» не всегда связан с уровнями зрелости и возможен даже и на третьем. Это, скорее, про наведение прозрачности внутри ИТ.
LoadRunner
18.08.2016 12:07Документация — это уже не нулевой уровень. Ну, если она не в голове, а хотя бы в таком виде, как описано.
Ordinatus
18.08.2016 12:19+6Это уже не нулевой.
Нулевой — это когда нет даже эникея, проблемы решает кто то из более или менее технически грамотных сотрудников или зовут соседа Васю, работающего эникеем.
fireSparrow
18.08.2016 12:19+7Проблема в том, что если первые два уровня (и отчасти — третий) ИТ-подразделение может развиваться само по себе, то начиная с четвёртого необходимы встречные шаги со стороны бизнеса.
А не каждый бизнес к этому готов.
Я вот очень хорошо это вижу на примере нашей компании. У нас был замечательный ИТ-директор (в начале лета, его, к сожалению, переманили в Ростелеком). Но очень многие его благие начинания натыкались на непонимание со стороны бизнеса.
Ничего не получится, если бизнес не понимает, что айтишники — это партнёры с которыми нужно обсуждать совместные проекты, а не обслуживающий персонал. Ничего не получится, если в самом бизнесе процессы не прописаны, а большая часть вопросов решается на личных связях.
Никакой централизации и стандартизации ИТ-инфраструктуры не будет, если у бизнеса большая часть вопросов решается на местах и исходя из сиюминутных задач. Ничего не получится, если пользователи не приучены писать тикеты в существующей системе, а только вопят «Мне нужно просто чтобы всё работало, я не программист, чтобы разбираться как письмо с заявкой отправить», а руководство им потакает, говоря айтишникам: «Ну что вы бюрократию с этими заявками разводите!».
И уж тем более ничего не получится, если айтишникам открытым текстом пеняют: «Вы расходное подразделение, сами ни копейки денег компании не приносите!», а потом режут заранее согласованные бюджеты на оборудование, но не пересматривают проекты, под которые это оборудование планировалось — и крутитесь, как знаете.
«Вы же обслуживающий персонал, вы должны просто решать задачи, которые перед вами ставит бизнес. Что? Согласовывать с вами что-то? Это ещё зачем?»Dobryak88
18.08.2016 14:20+2Чем Вам не нравится термин «обслуживающий персонал»?
Я системный администратор, я обслуживаю компанию, которая занимается химическим производством. Я выполняю функцию по обслуживанию процесса производства, процесса продажи и обслуживанию некоторых других фунцкций. Бухгалтерия — это обслуживающий персонал, они обслуживают основные процессы. Лаборатория — это обслуживающий персонал, да они дорабатывают и разрабатывают рецептуру, но компания получает прибыль не от продаже рецептов, а от продажи продукта по этим рецептам.
По теме: рост даже до второго уровня возможен только при понимании со стороны руководства. Плохой руководитель не поймёт разделение труда и будет требовать всего от каждого, ставь на кон премию этого самого каждого.
Приучить пользователей к тикетам действительно сложно. Мы делаем это постепенно, сокращая круг привилегированных пользователей и задач, которые могут быть обработаны без заявки. Долго, не без скандалов и обвинений в саботаже рабочего процесса, но успех есть.
Вы расходное подразделение, сами ни копейки денег компании не приносите!
Ну так вы и не должны. Единственный способ для отдела информационных технологий принести прибыль (именно прибыль, а не сокращение расходов) — это начать торговать информацией.
а большая часть вопросов решается на личных связях
Так эта компания и не должна претендовать на высокую оценку.
fireSparrow
18.08.2016 14:44+3Чем Вам не нравится термин «обслуживающий персонал»?
К термину у меня никаких претензий нет. Я хорошо понимаю, что есть производственная часть, которая даёт товар, есть коммерческая часть, которая товар превращает в деньги, а есть саппортовые подразделения, которые делают возможным нормальное функционирование производства и коммерсантов.
Но уж если бизнес замахивается на серьёзные проекты, которые требуют серьёзной ИТ-инфраструктуры, то бизнес должен понимать, что выстроить и поддерживать эту инфраструктуру могут только хорошие специалисты, к мнению которых нужно прислушиваться.
И даже если инфраструктура для текущих задач нужна весьма средняя — всё равно, нужно согласовывать планы. Айтишники не магией из воздуха делают инфраструктуру. Под задачу должен быть согласован бюджет, сроки, ответственные, персонал.
А не просто сказать: «Мы всё уже без вас решили, а вы нам просто обеспечьте.»
Ну так вы и не должны. Единственный способ для отдела информационных технологий принести прибыль (именно прибыль, а не сокращение расходов) — это начать торговать информацией.
Вы это понимаете, я это понимаю. А вот со стороны бизнеса мне приходилось на полном серьёзе такое слышать. Конечно, никто не требовал, чтобы мы начали прибыль приносить, это была претензия в духе «Мы вас кормим из милости, вот и не выпендривайтесь тут, а делайте, что вам говорят».
Так эта компания и не должна претендовать на высокую оценку.
К сожалению, далеко не все со стороны бизнеса это понимают. Многие думаю — ну нафига прописывать какие-то бизнес-процессы, разрабатывать инструкции, стандарты? Ведь всегда в случае каких непоняток можно пообщаться и порешать все вопросы.
sbnur
18.08.2016 13:29А где шестой уровень — окукливание структуры, которая становится самодостаточной и работает на самое себя
PS все бюрократические структуры проходят эти стадии
AlexeevEugene
18.08.2016 13:30+1Я невнимательно читал, или правда нет ни слова про мониторинг? Еще заметил корреляцию: чем выше уровень развития ИТ в предлагаемой компании, тем больше и сама компания в целом.
DKorolev
18.08.2016 14:42+4Видимо наоборот, вы читали очень внимательно, раз это заметили)
Начну со второго — действительно, есть определенная корреляция, так как с повышением уровня зрелости увеличивается количество процедур, на которые в небольших компаниях просто нет ресурсов. Да и не нужны они там, так как до определенного количества людей некоторые процедуры просто избыточны и все эффективней держать в поле зрения.
По поводу мониторинга: в самом посте этого нет, но он, конечно же, участвует в уровнях зрелости. Практика показывает такие градации:
Уровни 1-2-3 – мониторинг есть, мониторим zabbix или подобные общие инфраструктурные параметры (CPU, RAM, HDD), можем смотреть каналы, сетевой интерфейс, небольшие скрипты-проверки.
Уровни 3-4 — тут мы уже работаем с ИТ-сервисами и бизнесу (да и ИТ-руководству) уже не столь важно, как работает конкретный сервер, интересно работает у нас почта/CRM/ERM/АБС… или нет. Здесь, в дополнение к инфраструктурному мониторингу, появляются сервисно-ресурсные модели (это какие сервера и ПО входят в сервис «почта», что на чем стоит и как друг на друга влияет). Результат — мониторится уже ИТ-сервис целиком.
Уровни 4-5 – нам ИТ-сервисы зачем нужны? Правильно, чтобы бизнес работал. А бизнес – это бизнес-процессы. Вася должен получить счет по почте (ИТ-сервис почта), внести его в CRM (ИТ-сервис CRM), пометить заказ для отгрузки (ERP), проконтролировать доставку (ну пусть будет какая-то система доставки). Т.е. четыре ИТ-сервиса поддерживают один бизнес-процесс. Если мы мониторим транзакциями бизнес-процесс, то понимаем, есть сейчас возможность выполнять БП или все встало. И где встало.
А вообще, мониторинг — очень большая тема, может, когда-нибудь посвятим ей отдельный пост.sergik718
18.08.2016 19:39+1Очень интересно было бы почитать про мониторинг, может быть какую-то классификацию, когда какой продукт удобней использовать.
las68
22.08.2016 05:24по мониторингу написано много статей, универсального рецепта нет. Есть зависимость от разнородности инфраструктуры, территориальной распределенности, но не такая большая.
las68
22.08.2016 05:22Уровень 3-4 — точно так же покрывается штатной системой мониторинга, только мы при этом даём себе отчет в том, что мы мониторим статус сервиса. Очевидно, что это не отменяет необходимости проверять еще и нижележащую инфраструктуру, а то может так получиться, что сервис работает на последнем резерве.
А вот про транзакционный мониторинг бизнес-процессов — было бы интересно узнать, как вы это делаете, особенно если у нас используются разнородные системы.DKorolev
22.08.2016 19:22+1Про мониторинг бизнес-процессов: есть профильные средства (например, HP Business Process Monitor, BMC TrueSight Operations Management и пр.), которые могут эмулировать действия пользователей для проверки корректности работы системы. Т.е. для каждого приложения, участвующего в бизнес-процессе, создается проверочное действие и виды ответов системы. Простой пример с почтой – а) отправить письмо на определенный адрес, б) проверить ящик получателя, убедиться, что письмо пришло. Ну или если на уровне инфраструктуры – отправить SQL запрос и парсить полученный ответ.
Дальше в подсистеме визуализации это все складывается в бизнес-процесс, для каждого из шагов БП мы мониторим несколько действий (вне зависимости от того, что за системы лежат под этими действиями).
Выглядит это как-то так:
А вообще тема обширная, можно отдельный пост написать об этом.
pan_KOST
23.08.2016 11:47Видя эту схему и описание — для ТАКОГО анализа, на мой взгляд, отлично подойдут практики автоматизированного тестирования ПО, но, как Вы правильно отметили — подсистема визуализации должна быть привязанной к процессам и, в идеале, должен быть соответсвующий дашборд у менеджеров сервисов и соответсвующий дашборд у службы поддержки
heleo
18.08.2016 18:41Сдохли на 3м уровне (( К несчастью для всего этого нужна в первую очередь заинтересованность исполнителей нижнего и среднего звена. Как только контроль ослабевает или становится много работников делающих всё «спустя рукава» всё это превращается в бардак.
darthslider
19.08.2016 09:37Как по мне, нужна наоборот заинтересованность людей среднего и высшего звена (последние зачастую вообще слабо понимаю всё это IT), без поддержки руководства трудно перестать принимать заявки от важных людей, которые поймали тебя в коридоре например или стремиться к стандартизации рабочих мест.
pan_KOST
19.08.2016 12:30Я бы несколько поправил — по факту, заинтересованность необходима ВСЕХ уровней управления и исполнителей, но в обязательном порядке должна быть изначальная и безоговорочная поддержка в высшем звене, которое указывает направление для среднего звена, которое в свою очередь рассказывает всё нижнему звену и исполнителям, но при этом нижнее звено изначально должно хотеть улучшения, а не сопротивляться изменениям
darthslider
19.08.2016 13:19Согласен. Хотя если «низы» не хотят и сопротивляются, то их всё же можно заставить при поддержке «верхов». Потому что есть такая категория пользователей, которые всегда против, и вообще верните Win XP. С такими — только указом руководства можно бороться. И ладно если это люди которые просто «сидят», а бывает что это ценные важные сотрудники (по мнению руководства). Ну и чаще всего это конечно же люди в возрасте.
pan_KOST
19.08.2016 13:29Согласен по поводу низов, но с оговоркой — если низы в большинстве своём дойдут до уровня «саботаж новых процессов/систем», то все усилия менеджеров ни к чему не приведут.
Правда, если такая ситуация складывается, то это уже вопрос в профпригодности менеджеров =)darthslider
19.08.2016 13:31Возможно еще проблема в новых процессах/система таки. Не всё удобное с точки зрения менеджеров и руководства удобно для конечного пользователя. Иногда это вопрос привычки, но иногда действительно есть проблемы.
shtorman
19.08.2016 10:07Спасибо, узнал свой отдел на этапе очень сильного желания закрепиться на третьем уровне… и немного передохнуть.
mtivkov
25.08.2016 11:19А еще бывает такая печаль… когда с 5-го уровня зрелость скатывается на 4-й...
LoadRunner
Оказывается, в нашей компании не совсем всё плохо, как я думал — уровень где-то между вторым и третьим.