Адаптивные модели изменений

Опубликовано 9 июля 2017

Рубрики: Процессы, Управление изменениями

Комментарии

"Жизнь многообразна, бумага не бесконечна!" ))

"Ну хорошо, а сколько их нужно сделать?" Этот весьма насущный вопрос возникает, когда начинаешь проектировать модели изменений. Мы уже делились на нашем портале разными мыслями по поводу моделей изменений. Например, здесь и здесь. А здесь даже лежит вебинар по данной теме.

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

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

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

Но опять же, сколько их должно быть? Насколько рационально прописывать, извините за каламбур, "каждый чих"? Не будут ли трудозатраты на прописывание желаемого объёма моделей потрачены впустую из-за того, что допущена системная ошибка во всех моделях, или они всё равно не отражают нужной специфики в отдельных случаях и координаторам изменений приходится нарушать правила?

Когда мы говорим про процесс управления инцидентами, мы говорим про чёткие алгоритмы. Потому что нет времени. Потому что надо быстро. Когда мы говорим про управление запросами, мы говорим про заранее понятные работы. А когда мы говорим про изменения, мы говорим "анализируй это!". Мы спрашиваем "на что/кого повлияет? сколько будет стоить?". Потому что уровень неопределённости выше. И у ответственных должен быть более высокий уровень компетенций и полномочий. Полномочий, потому что начать согласовывать "каждый чих" через руководителей вместо того, чтобы прописать их в моделях – тоже не выход. Итого нужно наделить координаторов полномочиями корректировать модели в определённых пределах. Причём, эти пределы могут варьироваться в зависимости от специфики объекта и субъекта изменения.

Ладно, это всё лирика, а что конкретно настраиваем? Речь здесь идёт о нескольких аспектах.

Во-первых, о порядке обработки изменения. То есть через какие этапы проходит, на каких этапах требует согласования, требует ли включения в релиз и так далее. И здесь, как раз, мы можем управлять жёсткостью регламента. Например, для отдельных порядков обработки прописать, что некоторые этапы являются опциональными. Ну а что делать, если некоторые работы по ИТ-инфраструктуре или сетям связи можно выполнять только "на бою"? Да-да, это тоже можно в модели предусмотреть. А для всех информационных систем, например, закрепить общий мастер-порядок, жёстко закрепляющий необходимость приёмочного тестирования в выделенной среде.

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

кто должен координировать изменения данной категории/направления;
кто должен согласовывать в привязке к этапам согласования;
какие конкретно результаты должны быть на выходе определённых этапов (например, документы).

Соответственно, структура классификатора будет матрично-иерархической. Для групп систем или направлений вырисовывается набор типовых порядков обработки и отдельно наборы параметров по ИС или направлениям.

Такой подход позволяет упростить себе задачу и не разрабатывать избыточное количество моделей. Если, конечно, вы доверяете вашим координаторам изменений .