Портал №1 по управлению цифровыми
и информационными технологиями

Как построить понятную процессную модель

whats-the-purpose-of-problem-management_2Как построить оптимальную для конкретной организации модель ИТ-процессов? Оптимальную с точки зрения её сложности, управляемости, измеримости, отсутствия "мусора" в виде избыточных и дублирующихся процессов и функций?

Своими рекомендациями делится Robert S. Falkowitz.

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

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

  • "Один выход – один процесс";
  • "Не пытайтесь строить сквозные процессы";
  • "Соотносите выходы процесса с его назначением".

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

  • набор процессов управления инцидентами, различных для разных типов рабочих мест;
  • набор процессов управления изменениями, специфичных для разных сред (тестирования, приёмки, продуктивных).

Очевидными недостатками такого подхода является сложность управления разнородным "зоопарком" процессов. Автор предлагает строить процессную модель, как комплекс взаимосвязанных "небольших" процессов. При этом частично отходя от канонов, описанных в сводах хороших практик. В частности критике подвергнута практика обработки инцидентов в рамках двух процессов – управления инцидентами и управления проблемами. По мнению автора потеря управления над объектом в одном процессе после его передачи во второй процесс делает первый процесс, по сути, неуправляемым. Мы не можем управлять процессом, если не можем контролировать его на каждом этапе. Соответственно, первый процесс должен закончиться после того, как сформирован его выход.

Предлагаемые автором рекомендации основаны на практическом опыте и вызывают несомненных интерес.

Комментариев: 4

  • Ну прям в точку. Я бы еще добавил определение на берегу охвата процессной модели (что внутри, что снаружи) и структуру описания / уровень детализации, чтобы не было соблазна одним документом описать все аспекты управления ИТ.

  • Nargiza Suleymanova

    Статью, безусловно, нужно прочесть полностью в оригинале. Много здравых мыслей + щепотка юмора там, где нужно + моменты, которые хотелось бы обсудить. 🙂

    Из интересного: 1) домены вместо процессов, 2) разделение процессов там, где логика ясна (не нужно мешать все в кучу), 3) выносить за пределы процесса не относящиеся к его результату шаги.

    Из очевидного – иллюстрация как раз об этом: нужно понимать, зачем нужен тот или иной процесс на самом деле 🙂

    • Очень согласен, статья достойна прочтения.

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

  • Сергей Гончаров

    Спасибо, очень интересная статья. А главное как вовремя! Заказчик как раз пытается выстроить процесс (и нас выстроить под этот процесс) развертывания релизов в виде сложного единого процесса: dev, QA, staging, production. И все идет так сложно, и так долго…

    Попробую предложить подход Роберта. Вроде простая идея, но что-то за итилами всякими затерялась.


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM