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 они сформулированы столь … небрежно. Может быть от того и так долго доходят 🙂

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

ITIL ITIL Practitioner — новый учебный курс 2016

Правильный следующий шаг после ITIL Foundation.
 

Узнайте больше!

Комментарии и мнения

  1. Евгений Фомин

    Очень полезная статья. Большинство людей используют слова «цели» и «задачи» практически как синонимы. Понимание всех трех уровней дает ответ на многие «Почему?» и «Зачем?» мы что-то делаем в Компании.

    В абзаце ошибка:

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

    Уверен, вы имели ввиду слово «задачи».

  2. Роман Журавлёв

    Удивительно, как иногда простые идеи долго доходят до сознания. 

    Всё это время я недоумевал, отчего к этой записи нет ни одного комментария. И вот, через без месяца три года с момента публикации — первый! И дельный к тому же. Евгений, спасибо. 

  3. Руслан Шафеев

    В обсуждении данной темы учавствовал Jan van Bon с "особым" мнением, которое ссылается на статью "Functions and Processes in IT Management", опубликованную ранее в 'ITSM Global Best Practice Vol 1 2008'. Полный текст статьи доступен на сайте inform-it.org по ссылке: http://www.inform-it.org/wp-content/uploads/2015/01/Functions-and-Processes-in-IT-Management-article-ITSM-Global-Best-Practice-Vol-1-2008.pdf

    Интересно узнать мнение экспертов Cleverics о точке зрения Йана и модели "The ISM Method", по мнению авторов, включающей набор из шести "практически реализуемых эффективных и рациональных" процессов с понятным назначением, целями и задачами.

    PS. В 2014 году Олег Скрынник опубликовал статью "The ISM Method: сказка стала былью?" http://www.cleverics.ru/ru/subject-field/articles/592-the-ism-method

    Планирует ли Cleverics дальнейшее изучение этой модели и помощь российским компаниям в её практическом применении в России?

    Спасибо!

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Empty