Если жалеть о чем-то, то лишь о том,
Что так тяжело доходишь до вечных истин.
Вера Полозкова.
Удивительно, как иногда простые идеи долго доходят до сознания. Неожиданно осознал идею ITIL разделять purpose, goals и objectives по отношению к процессам. Более того, пришёл к выводу, что мы уже давно используем это в своей проектной практике, просто называем немного другими словами.
И так, purpose. Назначение процесса
Роман Журавлёв как-то опубликовал классную заметку «Some heretical opinions on ITIL service lifecycle» на itsmportal.com, в которой высказал точку зрения, что назначение бывает не у процессов, а у функций. Попробую поспорить (не в целом конечно, а только по этому поводу). Думаю, назначение процесса существует. Это формулировка, которая определяет место процесса в процессной модели, то есть натурально отвечает на вопрос «зачем нужен этот процесс, за что он отвечает». Примеры:
- Управление инцидентами и запросами пользователей – обеспечение качества ИТ-услуг за счёт скорейшего устранения инцидентов и своевременного выполнения запросов на обслуживание.
- Управление проблемами – повышение надёжности ИТ-услуг за счёт предотвращения повторов инцидентов посредством определения и устранения корневых причин их возникновения.
- Управление уровнем услуг – обеспечение качества ИТ-услуг за счёт согласования и контроля соблюдения обязательств поставщика ИТ-услуг, а также организации устранения выявленных несоответствий.
И так далее. Вряд ли эти формулировки будут значительно меняться от внедрения к внедрению, если только не пересматривать процессную модель в целом.
Ответственный за определение назначения процесса – дизайнер (технолог / проектировщик) процессов (то есть специалист по процессам, а не управленец).
Goals. Цели процесса
Цель определяет, что должен обеспечить процесс в некоторый фиксированный отрезок времени (в отличие от назначения, которое определяется без привязки к конкретному периоду планирования). Например, для управления инцидентами это может быть «обеспечить увеличение доли своевременно решённых инцидентов до 95%» или «довести долю обращений, обработанных на первой линии, до 30%» и так далее. Ключевые характеристики целей:
- формулировка с применением глаголов совершенной формы;
- измеримость (причём скорее всего метрика будет присутствовать непосредственно в формулировке цели);
- привязка к отрезку времени (цель ставится на месяц, на квартал, и так далее, а не вообще – навсегда).
Короче, SMART. Все помнят, зачем повторяться.
Ответственный за определение целей процесса – владелец процесса. Цели процессов должны регулярно пересматриваться (уровень зрелости 3+ и выше). Наличие у процесса ясных и актуальных в данный момент времени целей является одним из важнейших индикаторов того, что владелец процесса действительно исполняет свои функции.
Интересно, что регулярный пересмотр целей приводит к тому, что цели процесса бессмысленно фиксировать в регламенте процесса (иначе его попросту придётся постоянно пересматривать). Разумно фиксировать цели процесса в текущих планах управления, картах целевых показателей и так далее (кто что использует). Это ещё одно явное отличие целей от назначения процесса.
Очень важна ясная связь между целями процесса, устанавливаемыми при проектировании, целями проекта, в рамках которого это проектирование выполняется, и обоснованием этого проекта перед бизнесом 🙂 Но это отдельная история.
Objectives. Задачи процесса
Задачи процесса определяют, что должен обеспечивать процесс для соответствия назначению и достижения целей. То есть фактически задачи процесса определяют технологию реализации процесса. Например, для управления инцидентами это может быть «Накопление и организация повторного использования знаний по устранению инцидентов и выполнению запросов на обслуживание», для управления проблемами – «Содействие процессу управления инцидентами и запросами пользователей посредством предоставления информации о наиболее эффективных обходных решениях инцидентов» и так далее.
С задачами, также, как и с целями, связываются метрики. Как правило, задачи меняются гораздо реже целей (если только цели не меняются столь кардинально, что требуют постоянного пересмотра процесса). А потому разумно фиксировать задачи процесса непосредственно в регламенте данного процесса.
Ответственный за определение задач процесса – менеджер процесса. С методической точки зрения ему может / должен помогать дизайнер процесса, но ответственность за то, что задачи процесса соответствуют не только назначению, но и целям лежит именно на менеджере. Причины понятны – менеджеру ставится задача, он обеспечивает её реализацию, включая выбор способа.
Итог
Собственно, вот и вся история. Из песни слова не выкинешь – все три уровня нужны. Немного жаль только, что в книгах ITIL они сформулированы столь … небрежно. Может быть от того и так долго доходят 🙂
Очень полезная статья. Большинство людей используют слова “цели” и “задачи” практически как синонимы. Понимание всех трех уровней дает ответ на многие “Почему?” и “Зачем?” мы что-то делаем в Компании.
В абзаце ошибка:
Ответственный за определение задач процесса – менеджер процесса. С методической точки зрения ему может / должен помогать дизайнер процесса, но ответственность за то, что цели процесса соответствуют не только назначению, но и целям лежит именно на менеджере.
Уверен, вы имели ввиду слово “задачи”.