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