Рискну предположить, что у любого человека знакомящегося с процессной моделью ITIL в какой-то момент возникает вопрос, обозначенный в заголовке заметки. Казалось бы, технология поиска ответа должна быть простой – берём книги и [c]читаем.
Но на самом деле всё не так просто.
Во-первых, результат зависит от того, как [c]читать. Например, подобную работу при помощи Sharon Taylor (архитектора ITIL v3) проделала Pink Elephant, представив результат в виде удобных таблиц в коротком документе «Definitive ITIL® 2011 & 2007 Edition Process & Function List». Если считать по оглавлению книг, то процессов, которым посвящены отдельные разделы, 26.
Но! В это число не входят так называемые подпроцессы (например, Business capacity management, Service capacity management, Component capacity management лишь коротко описаны в составе процесса Сapacity management [Управление мощностями], не заслужив стандартной для ITIL структуры описания процессов). Кроме того, в ITIL есть виды деятельности, упоминаемые в тексте как процессы, но не имеющие отдельного описания вообще.
Во-вторых, не всегда очевидно, почему те или иные виды деятельности разделены на различные процессы, или, наоборот, не нужно ли разбить процесс на разные процессы. Интересным примером обсуждения темы «Сколько процессов Вы видите на данной картинке?» являются комментарии к статье «Управление инцидентами и запросами пользователей».
Более того, к некоторым процессам ITIL возникают вопрос: «А процесс ли это? Или, скорее, функция?» Интересный разбор тезисов ITIL на тему «процессы и функции» и нестыковок в получающейся общей картине проделан в статье Wim Hoving, Jan van Bon «Functions and processes in IT management» (из книги «IT Service Management Global Best Practices, Volume 1» [поскольку книга вышла в 2008 году, рассматривается ITIL v3 редакции 2007 года]).
Таким образом, даже с формальной точки зрения ответ на простой вопрос из заголовка заметки не получается простым.
Достаточно странный вопрос, поскольку не понятно, как дальше использовать полученное число. ITIL хоть и нельзя рассматривать в качестве полноценной модели процессов, но идея была именно такой. А для любой модели характерен разный уровень детализации. Чем выше уровень детализации (больше количество описанных процессов), тем меньше применимость этой модели. И наоброт. В пределе можно нарисовать один прямоугольничек, обозвать его – "Предоставлять услуги" – и это будет самая универсальная модель процессов. Каждый дополнительный уровень детализации сужает применимость модели. Исходя из этого, количество процессов в модели будет зависеть от вашего конкретного случая, когда из этой модели будет понятно, что речь идет именно про ваше предприятие.
Как в свое время сказал Ю.В. Ипатов -"Уровень детализации модели бизнес процессов должжен быть таким, чтобы можно было отличить металлургический комбинат от птицефабрики".