Очередной проект показал, что мыслями на эту тему стоит поделиться. Давайте рассмотрим две наиболее распространенные ситуации, при которых обычно заказывается обследование:
- Есть проблемные области в управлении ИТ, ситуацию в которых хотелось бы улучшить.
- Есть непреодолимое желание проверить, что "все сделано правильно".
Одним из ключевых факторов успеха является постановка задачи.Без этого никак: необходимо определиться, зачем делается обследование и что должно быть на выходе.
Итак, начнем с проверки на "правильность". Понятие "правильно" у каждой компании свое, поэтому проверка на соответствие стандартам не всегда дает возможность правильно выбрать направление для совершенствования. В некоторых случаях разумное отступление от положений стандарта позволяет получить лучший результат. Несомненно, на выбор направления совершенствования оказывают влияние и ресурсные ограничения, и культура внутри компании, и специфика ее бизнеса, а все эти детали никак не учитываются в стандартах. И уж тем более не стоит проверять собственные процессы на "соответствие ITIL", об этом мы уже не раз писали. В идеале проверка на правильность должна начинаться с определения задач, которые должны решаться, оценки текущих возможностей и ограничений компании. Направлений проверки два: проверить, что задачи решаются, и проверить, что задачи решаются рационально. Затем на основании этой информации может быть определено целевое состояние процессов: состав, цели, задачи, специфика и т.д., то есть определены инструменты, с помощью которых будут решаться поставленные задачи. Последующее сравнение целевого состояния с текущим позволит получить перечень областей для совершенствования, а из них – перечень мероприятий.
Теперь о том, что должно быть на выходе.Обычно заказчика интересует перечень мероприятий для совершенствования. Здесь можно рекомендовать только проверку наличия обоснования для каждого из мероприятий и достаточного уровня детализации. Обоснование для реализации мероприятий должно содержать объяснение, основывающееся на фактах, а не фразы "так в ITIL, поэтому и вам необходимо", "так делают все, а вы – нет". Желательно, чтобы был проведен анализ рисков, описано чем грозит отказ от реализации данных мероприятий.
Важно, чтобы рекомендации не сводились к банальному "необходимо внедрить процесс …". Для этого в ходе обследования должны быть выявлены причины возникновения проблем, возможности и ограничения организации по их устранению. В некоторых ситуациях можно обойтись и без внедрения процессов или сильно упростить процесс. Детализация мероприятий также важна, т.е., например, предложение по внедрению процесса должно содержать перечень задач, которые будет решать процесс, и его ключевые особенности, которые необходимо учесть при проектировании и внедрении.
К сожалению, на практике не всегда эти простые идеи используются, поэтому периодически приходится сталкиваться с отчетами об обследовании, подготовленными различными компаниями, которые вызывают ощущение "развода" Заказчика на выполнение дополнительных работ, которые не всегда нужны, ну или не нужны в предлагаемом объеме.
Возможно кому-то изложенные мной мысли помогут правильнее поставить задачу консультантам или оценить результат.Если у вас тоже есть, чем поделиться по этой теме – ждем ваши комментарии.
Обоснование для реализации мероприятий должно содержать объяснение, основывающееся на фактах, а не фразы “так в ITIL, поэтому и вам необходимо”, “так делают все, а вы — нет”.
Что вы имеете в виду под фактами? Можете пример привести?
“так делают все, а вы — нет” это вполне себе факты достаточные для принятия решения. Что вы можете им противопоставить? Противопоставить им можно либо ваше личное мнение “я думаю, что вам это поможет”, либо эксперимент “давайте попробуем сделать так в филиале Х и посмотрим как получится”. Я других фактов не вижу.