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

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

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

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

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

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

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