Инциденты, проблемы и запросы на обслуживание. Третий шаг ИТ-начальника.

По просьбам коллег продолжу начатую ранее серию заметок о том, с чего начать свеженазначенному начальнику ИТ-службы. В первой части я говорил о внимании к терминам, а во второй - о понимании специфики пользователей. Предположим, что первый стресс от назначения уже прошел, с тем, что означают слова "регламент", "инструкция", "АРМ" и "КИС" более-менее разобрались, и с тем, какие у вас пользователи, тоже есть ясность. Что теперь?

Теперь, мне думается, пришло время начинать целевой аудит своего хозяйства. Причем нужен не формальный, бумажный, а скорее "понятийный" аудит того, что твориться со следующими процессами:

1. Управление инцидентами. Как регистрируются? Как оформляются? Как сохраняются в базе? Как контролируется выполнение метрик времени и качества по обработке инцидентов? Метрики такие существуют? Как взаимодействуют с пользователями и откуда вообще берется информация об инцидентах?
2. Управление проблемами. Если просто "гасить пожар" в виде инцидентов, то реального сдвига к лучшему не будет. Каждый инцидент - это обычно своего рода звоночек о более серьезных вещах. Так что нужно обязательно понять, как регистрируются проблемы? Как отслеживается состояние проблем и процесса их решения? Кто на каком этапе за что отвечает? И так далее.
3. Управление запросами на обслуживание. Кто кому что пишет, когда нужен компьютер для нового сотрудника бухгалтерии? Как отслеживается соблюдение временных метрик таких запросов? Где осуществляется учет запросов? Кто за что отвечает? Кто контролирует? Кто учитывает? Какие порождаются документы на каком этапе, и кто что визирует или одобряет?

Если у ИТ-начальника есть понимание, как осуществляются эти три базовых процесса, можно потихоньку начинать их улучшать и автоматизировать. Программных средств для этого - масса. Можно взять что-то свободно распространяемое, можно купить лицензию на уже известное средство, выбор за вами, нужно лишь чтобы с его помощью можно было бы постепенно улучшать ситуацию в указанных выше базовых процессах. Главное, что нужно помнить: не пользуйтесь слишком дорогими или экзотическими средствами с большим количеством локальных доработок, оставляйте за собой свободу сменить инструмент в случае необходимости.

Кстати, достаточно редко встречается ситуация, что именно вам придется принимать решение о выборе программного средства. Скорее всего, нечто уже куплено и в каком-то виде уже используется на предприятии. Вам нужно лишь оценить, насколько эффективно это делается. И не спешите что-то ломать или менять! Сначала - разберитесь! 

Стремитесь к разумности и к соблюдению принципа Парето: "20% усилий дают 80% результата". Не нужно пытаться сделать все и сразу, действуйте осмысленно и постепенно.

О функциональном и процессном управлении в ИТ

О преимуществах внедрения процессного управления написано в каждом учебнике по управлению. Особенно много и обоснованно - в учебниках по ИТ-управлению. Но в реальной жизни все равно очень много организаций, которые мертвой хваткой держаться за функциональную модель. Почему так? Ведь процессное управление имеет массу преимуществ, оно прекрасно описано, почти 80% основных технологических процессов в ИТ покрываются типовыми процессными сценариями, казалось бы, бери и реализовывай, что останавливает?

Попробуем порассуждать на эту тему. Что такое функциональная модель? Это когда каждый сотрудник выполняет некоторый набор функций, и, собственно, только за них и отвечает. Как в известном диалоге у Райкина, помните: "К пуговицам претензии есть? -Нет, к пуговицам претензий нет, пришиты намертво!". Самый яркий пример построения функционального управления - это конвейер. Каждый уверенно и точно делает свою операцию, на выходе - готовый автомобиль. Причем если конвейер выстроен правильно, то автомобиль, в идеальном случае, создается минимальным количеством работников.

Но это - в идеальном случае. В реальной жизни работники, во-первых, устают от монотонности одинаковой работы, а, во-вторых, стоит событиям хотя бы немного выйти за пределы типового сценария, как возникает необходимость вмешаться вышестоящему начальнику, то есть происходит эскалация, потому что горизонтальные связи минимальны и знаний о смежных областях у таких вот "конвейерных" сотрудников для принятия решений недостаточно.

Поэтому для решения описанных "конвейерных" проблем в той же автомобильной индустрии еще в середине XX века сначала попытались периодически переставлять работников с одной позиции на другую. Это помогало справиться с монотонностью работы, хотя и ценой некоторой потери производительности труда (работники не сразу перестраивались на новую деятельность и сначала ошибались чаще). Но вот проблема с повышенной нагрузкой на управленцев оставалась - в малейшем отклонении от типового сценария работы возникала необходимость в эскалации. Для решения этой проблемы начали расщеплять конвейер на процессные звенья, где в группа работников под управлением соответствующего управленца полностью отвечала за производство практически от начала и до конца, снижая нагрузку на вышестоящих начальников. Это и есть процессное управление.

Собственно, в описанном выше и есть ответ на вопросы, поставленные в начале заметки. Функционально управление позволяет решить задачу за счет минимального количества сотрудников, если обучить их относительно простым операциям и правильно настроить ИТ-"конвейер". Хорошо настроенное функциональное управление - самое дешевое в этом смысле, людей можно запрячь и использовать, как ломовых лошадей.  И, если говорить на чистоту, всем плевать, насколько они недовольны работой - на хорошо описанные функциональные должности всегда можно найти новых людей, а проработанные регламенты позволять быстро подготовить нужных специалистов, хотя если терять людей часто, то "конвейер" ИТ-службы будет давать сбои слишком часто и двигаться недостаточно быстро. Но если избегать совсем уж серьезных ошибок, то все будет нормально. Поэтому за функциональное управление держатся сейчас и будут держаться в будущем - оно самое дешевое в отношении человеческих ресурсов.

Существует и другая причина. Эта причина - незаменимость начальников. Я говорил выше, что функциональная модель управления приводит к эскалации при минимальном выходе за пределы типового сценария. Это повышает нагрузку на руководителей всех звеньев, но зато это же делает их нужными и, при правильном подходе, даже незаменимыми! Так что руководители среднего звена совсем не горят желанием внедрять ресурсное управление, их собственная задроченность дает им психологическую уверенность в своей востребованности и  в собственном завтрашнем дне. А дополнительный бонус к незаменимости - размытая ответственность, неизбежный спутник всех конвейеров, когда, чтобы найти виноватого, приходится выяснять всю цепочку и в конце виноватым окажется дядя Вася с гаечным ключом!

Но эта вот задроченность управленцев рано или поздно приводит их к процессному управлению. Просто устают начальники. И постепенно они потихоньку увеличивают штаты, грамотно или по наитию формируют процессные участки и делегируют полномочия старшим на этим участкам. В противном случае при повышении сложности решаемых задач начальникам придется или ночевать на работе, или снижать показатели работы своей ИТ-службы.

Так что по большому счету альтернативы процессному управлению нет, тем или иным способом внедрять его будут, нахлобучивая сверху на функциональную модель или объединяя их во всевозможные гибриды. Потому что в противном случае незаменимые начальники тихо умрут от переработки или будут уволены за проколы.