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

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

Приведённое противоречие обычно и логика его устранения понятна:

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

• Нужно разработать обходные решения для устранения инцидентов пока ИС будет глючить на ограниченных ресурсах.

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

Можно решать этот вопрос вручную, а можно организовав процесс, используя Service Desk. Не говорю, что лучше, что хуже, а просто показываю модель решения проблемы из практик.

Контекст: Хорошо классифицировать проблемы следующим образом:

• Зона ответственности проблемы

• Организационный фактор

• Корневая причина

В нашем случае модель решения проблемы может выглядеть следующим образом:

Здесь мы видим, что менеджер проекта заказывает у отдела ЭВС решение нашей проблемы. В отделе ЭВС чётко разделены роли решения проблем. Менеджер проблемы, обычно руководитель, тим-лид и т.п.:

1. Организует выделение резервных ресурсов и развёртывание на них ИС

2. Организует установку ИС на недополученных мощностях

3. Контролирует оперативность и качество реализации обходного решения

4. Контролирует качество решения проблемы, закрывает проблему.

Ответственный исполнитель проблемы, обычно администратор информационной системы:

1. Реализует изменение по развёртыванию на резервных мощностях

2. Разрабатывает обходное решение

3. Разворачивает ИС, когда поставлены недополученные мощности.

Что даёт данная модель?

• Измеримость всей истории (руководители видят цифры про сроки, количество и длительность сбоев по проблеме)

• Разграничение ответственности между сотрудниками. К примеру, админ не парится за организационную составляющую, менеджер проектов не парится за организацию реализации обходных решений и развёртывание и т.п.(снижаются затраты на футбол)

• Возможность оценки качества закупок мощностей

• Данная модель при необходимости декомпозируется на модели реализации изменений и разработки обходных решений.

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

Такой алгоритм приготовления «каши из топора», пока манки нет.