Hedges labyrinth

Одно из преимуществ ACM (adaptive case managment), это то, что она позволяет избежать лишней сложности, упростить систему там где это возможно, либо усложнить и расширить там где это оправдано. Причем без лишних временных затрат.

Пример:

Внедряли ITSM в отделе ИТ. Представили деятельность в форме услуг. Процессы и все такое.

Добавили процесс «Техническая поддержка», а туда 3 подпроцесса: Инцидент, Вопрос и Запрос.

Добавили учет характеристики CMDB: с каким объектом связано обращение? Чтобы понимать затраты.

Поработали год. Практика показала:

1. бесмысленность разделения процесса на подпроцессы, т.к. далеко не всегда можно с ходу отличить вопрос от инцидента 🙂 да и при текущих размерах это были бессмысленные потери времени на классификацию

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

Все это в какой то мере оставили в процессе управления изменениями и релизами, т.к. там это действительно нужно и есть смысл.

А вот в тех поддержке решили ограничиться лишь ключевыми измерениями:

1. факт обращения

2. срок

3. ответственный

4. линия решения (1. поддержка, 2. сис. администратор, 3. программист)

5. соблюдение SLA

Все.

Остальное за пару часов удалили.

Это позволило упростить процесс:

1. специалисты поддержки теперь меньше времени тратят на классификацию

2. упростили подсчет затрат по услугам, т.к. их всего 3 и просто сделали 3 отдела

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

4. если обращение происходит через веб форму, то это проще для пользователя — «как отправить письмо по почте», т.к. нет лишних полей для заполнения

Отличия

Структура ИТ-процесса. До

Структура ИТ-процесса. После

Результат

Теперь показатели по ИТ-услугам смотрятся значительно лучше, причем в разрезе по информационным системам, ну или «ИТ-услугам», как велит нам выражаться библиотека ITIL 🙂

Одна информационная система

Вторая информационная система

Итого

Новая структура и KPI могут легко показать результативность и затраты на информационные системы в самых разных разрезах.

Первый же взгляд на чуть более глубокий KPI показал, что одна из систем требует огромных затрат, причем львиная доля — это исправления. Получается что разработчики большую часть времени тратят на исправления того что сделали ранее 🙂

Это позволяет делать выводы и принимать решения.