Еще несколько слов про CHG

Перечитал своё вчерашнее сообщение. Наверное, не очень понятно, почему я пишу о JIRA в контексте управления изменениями (change management). Всё очень просто: у кого чего болит… У меня сейчас болит это самое управление изменениями.

Дело в том, что CHG – это основной процесс управления ИТ и то насколько он хорошо в организации выстроен в значительной степени и определяет как работает ИТ этой организации. CHG это единственный управляющий процесс в ITIL, т.е. он призван координировать все остальные виды деятельности: планирование, разработку и установку релизов, управление инцидентами и т.д. В нормальной ситуации CHG порождает экземпляры других процессов и контролирует их прохождение. Здесь уместна терминология BPM/SOA, процесс управления изменениями должен реализовывать оркестровку и хореографию других ИТ процессов. А еще CHG тесно связан с процессом управления конфигурациями CFG. В инструментах ИТ управления, например в BMC, приложение управления изменениями Remedy Change and Release management позволяет непосредственно привязывать изменения к конфигурационным единицам из Atrium CMDB (см. рисунок).

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

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

PS: Интеграция JIRA с Confluence оказалась совсем никакой. Ну можно на личную страничку пользователя в Confluence вывести список его задач из JIRA, вот пожалуй и все.