Как построить оптимальную для конкретной организации модель ИТ-процессов? Оптимальную с точки зрения её сложности, управляемости, измеримости, отсутствия "мусора" в виде избыточных и дублирующихся процессов и функций?
Своими рекомендациями делится Robert S. Falkowitz.
В своей статье автор обращает внимание на ряд важных аспектов проектирования архитектуры процессной модели, которые помогают структурировать и оптимизировать деятельность ИТ-организации.
Ключевые принципы, предлагаемые автором, можно с некоторой адаптацией при переводе на русский язык сформулировать следующим образом:
- "Один выход – один процесс";
- "Не пытайтесь строить сквозные процессы";
- "Соотносите выходы процесса с его назначением".
Как указывает автор, многие организации до сих пор тяготеют к построению сложных сквозных процессов, формирующих наборы различных выходов, и "заточенных" под какой-то определённый контекст. В качестве примера приводятся:
- набор процессов управления инцидентами, различных для разных типов рабочих мест;
- набор процессов управления изменениями, специфичных для разных сред (тестирования, приёмки, продуктивных).
Очевидными недостатками такого подхода является сложность управления разнородным "зоопарком" процессов. Автор предлагает строить процессную модель, как комплекс взаимосвязанных "небольших" процессов. При этом частично отходя от канонов, описанных в сводах хороших практик. В частности критике подвергнута практика обработки инцидентов в рамках двух процессов – управления инцидентами и управления проблемами. По мнению автора потеря управления над объектом в одном процессе после его передачи во второй процесс делает первый процесс, по сути, неуправляемым. Мы не можем управлять процессом, если не можем контролировать его на каждом этапе. Соответственно, первый процесс должен закончиться после того, как сформирован его выход.
Предлагаемые автором рекомендации основаны на практическом опыте и вызывают несомненных интерес.
Ну прям в точку. Я бы еще добавил определение на берегу охвата процессной модели (что внутри, что снаружи) и структуру описания / уровень детализации, чтобы не было соблазна одним документом описать все аспекты управления ИТ.