Purpose, goals and objectives

Если жалеть о чем-то, то лишь о том,
Что так тяжело доходишь до вечных истин.
Вера Полозкова.

Удивительно, как иногда простые идеи долго доходят до сознания. Неожиданно осознал идею ITIL разделять purpose, goals и objectives по отношению к процессам. Более того, пришёл к выводу, что мы уже давно используем это в своей проектной практике, просто называем немного другими словами.

И так, purpose. Назначение процесса

Роман Журавлёв как-то опубликовал классную заметку «Some heretical opinions on ITIL service lifecycle» на itsmportal.com, в которой высказал точку зрения, что назначение бывает не у процессов, а у функций. Попробую поспорить (не в целом конечно, а только по этому поводу). Думаю, назначение процесса существует. Это формулировка, которая определяет место процесса в процессной модели, то есть натурально отвечает на вопрос «зачем нужен этот процесс, за что он отвечает». Примеры:

1. Управление инцидентами и запросами пользователей – обеспечение качества ИТ-услуг за счёт скорейшего устранения инцидентов и своевременного выполнения запросов на обслуживание.
2. Управление проблемами – повышение надёжности ИТ-услуг за счёт предотвращения повторов инцидентов посредством определения и устранения корневых причин их возникновения.
3. Управление уровнем услуг – обеспечение качества ИТ-услуг за счёт согласования и контроля соблюдения обязательств поставщика ИТ-услуг, а также организации устранения выявленных несоответствий.

И так далее. Вряд ли эти формулировки будут значительно меняться от внедрения к внедрению, если только не пересматривать процессную модель в целом.

Ответственный за определение назначения процесса – дизайнер (технолог / проектировщик) процессов (то есть специалист по процессам, а не управленец).

Goals. Цели процесса

Цель определяет, что должен обеспечить процесс в некоторый фиксированный отрезок времени (в отличие от назначения, которое определяется без привязки к конкретному периоду планирования). Например, для управления инцидентами это может быть «обеспечить увеличение доли своевременно решённых инцидентов до 95%» или «довести долю обращений, обработанных на первой линии, до 30%» и так далее. Ключевые характеристики целей:

1. формулировка с применением глаголов совершенной формы;
2. измеримость (причём скорее всего метрика будет присутствовать непосредственно в формулировке цели);
3. привязка к отрезку времени (цель ставится на месяц, на квартал, и так далее, а не вообще – навсегда).

Короче, SMART. Все помнят, зачем повторяться.

Ответственный за определение целей процесса – владелец процесса. Цели процессов должны регулярно пересматриваться (уровень зрелости 3+ и выше). Наличие у процесса ясных и актуальных в данный момент времени целей является одним из важнейших индикаторов того, что владелец процесса действительно исполняет свои функции.

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

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

Objectives. Задачи процесса

Задачи процесса определяют, что должен обеспечивать процесс для соответствия назначению и достижения целей. То есть фактически задачи процесса определяют технологию реализации процесса. Например, для управления инцидентами это может быть «Накопление и организация повторного использования знаний по устранению инцидентов и выполнению запросов на обслуживание», для управления проблемами – «Содействие процессу управления инцидентами и запросами пользователей посредством предоставления информации о наиболее эффективных обходных решениях инцидентов» и так далее.

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

Ответственный за определение задач процесса – менеджер процесса. С методической точки зрения ему может / должен помогать дизайнер процесса, но ответственность за то, что задачи процесса соответствуют не только назначению, но и целям лежит именно на менеджере. Причины понятны – менеджеру ставится задача, он обеспечивает её реализацию, включая выбор способа.

Итог

Собственно, вот и вся история. Из песни слова не выкинешь – все три уровня нужны. Немного жаль только, что в книгах ITIL они сформулированы столь … небрежно. Может быть от того и так долго доходят 🙂