При устранении множественных противоречий важно иметь наработанные практики, модели решения проблем. Делюсь, может быть кому-то пригодится, несмотря на узость специфики.
Пусть у нам в августе нужно внедрить информационную систему(ИС), но поставка виртуальных мощностей запланирована на декабрь. Пусть внедрением системы занимается менеджер проектов, а за эксплуатацию отвечает отдел эксплуатации виртуальной среды. Пусть резервных ресурсов не хватает и система регулярно сбоит. К примеру, копятся очереди SQL-запросов.
Приведённое противоречие обычно и логика его устранения понятна:
Нужно временно развернуть информационную систему на резервных мощностях, предназначенных для других ресурсов.
Нужно разработать обходные решения для устранения инцидентов пока ИС будет глючить на ограниченных ресурсах.
После того, как в декабре поставят недостающие мощности, нужно на них развернуть информационную систему.
Можно решать этот вопрос вручную, а можно организовав процесс, используя Service Desk. Не говорю, что лучше, что хуже, а просто показываю модель решения проблемы из практик.
Контекст: Хорошо классифицировать проблемы следующим образом:
Зона ответственности проблемы
Организационный фактор
Корневая причина
В нашем случае модель решения проблемы может выглядеть следующим образом:
Здесь мы видим, что менеджер проекта заказывает у отдела ЭВС решение нашей проблемы. В отделе ЭВС чётко разделены роли решения проблем. Менеджер проблемы, обычно руководитель, тим-лид и т.п.:
Организует выделение резервных ресурсов и развёртывание на них ИС
Организует установку ИС на недополученных мощностях
Контролирует оперативность и качество реализации обходного решения
Контролирует качество решения проблемы, закрывает проблему.
Ответственный исполнитель проблемы, обычно администратор информационной системы:
Реализует изменение по развёртыванию на резервных мощностях
Разрабатывает обходное решение
Разворачивает ИС, когда поставлены недополученные мощности.
Что даёт данная модель?
Измеримость всей истории (руководители видят цифры про сроки, количество и длительность сбоев по проблеме)
Разграничение ответственности между сотрудниками. К примеру, админ не парится за организационную составляющую, менеджер проектов не парится за организацию реализации обходных решений и развёртывание и т.п.(снижаются затраты на футбол)
Возможность оценки качества закупок мощностей
Данная модель при необходимости декомпозируется на модели реализации изменений и разработки обходных решений.
При правильной организации управления процессами ИТ моделей реализации проблемам и прочих процессов много. Они особенно важны в те моменты, когда некогда думать, сроки горят, и ничего нет.
Такой алгоритм приготовления «каши из топора», пока манки нет.
