Представьте, что Вы сдаёте экзамен ITIL v3 Foundation. Самый первый, простой и базовый экзамен из всей замечательной схемы сертификации имени APMG. Вам попался следующий вопрос:
Сколько процессов описано в ITIL v3?
A. 24
B. 26
C. 26 или 27
Ваш ответ?
На самом деле правильный ответ в природе не существует, ибо не определён. Такова уж сущность ITIL вообще и ITIL v3 в частности – как можно меньше определённости, даже в базовых понятиях. Зато каждый из приведённых вариантов можно так или иначе обосновать. Смотрите.
Вариант В (26 процессов) – это точка зрения Шерон Тэйлор, главного архитектора ITIL v3. Наверное, главному архитектору всея ITIL верить можно.
Вариант А (24 процесса) – это та же точка зрения, но с учётом мнения авторов книги CSI, по заявлениям которых они никогда не считали процессами такие штуки как "Service Measurement" и "Service Reporting". То есть – на два процесса меньше.
Вариант С (самый забавный) есть не что иное, как пункт из официального FAQ по ITIL v3, который находился в этом FAQ достаточно продолжительное время. Там было сформулировано примерно так: "На часто задаваемый вопрос о количестве процессов в ITIL v3 отвечаем: 26 или 27, смотря как считать".
Ещё можно вспомнить цитату из книги Service Strategy о том, что является большим заблуждением точка зрения, что Capacity Management – это процесс. Это функция, и всё тут. Жаль, что авторы раздела про управление мощностями не читали стратегию, вот бы они удивились.
Некоторые знатоки способны насчитать в ITIL v3 ни много, ни мало – 34 процесса. Для этого нужно строго следовать всем упоминаниям и структуре книг, тогда, например, ROI – тоже отдельный процесс. Почему бы и нет. И TCO пусть тоже будет. И IRR. И ещё два десятка аналогичных показателей, чего уж там.
Короче, бардак.
Где же бардак? В том, что невозможно посчитать количество процессов? В том что слово процесс используется в широком смысле (фактически, любой вид деятельности, не зависимо от наличия “разумного” workflow)? Давайте оглянемся вокруг.
Есть CobiT. Все четко – 34 процесса, споры не уместны. Четкая и ясная классификация, увязка целей и задач процессов с целями и задачами организации, рисками, метриками. Прекрасный инструмент для проверки, потому что претензии на полноту и системность. Но попробуйте организовать деятельность в виде набора взаимосвязанных процессов, сильно ли Вам поможет CobiT? Кто про себя может сказать “у нас процессы построены по CobiT?”
Есть eTOM. Все четко – ясная классификация видов деятельности телеком-операторов. Количество процессов считать бесмыссленно – зависит от того, до какого уровня декомпозиции считать (а стандарт определяет от трёх до четырёх уровней). Да и по тексту термины “процесс” и “процессный элемент” регулярно меняются местами. В частности, уже “процессы” второго уровня во многом процессами в wokrlfow-смысле не являются. Готовых workflow (в eTOM они называются “end-to-end”) процессов нет (есть несколько примеров в GB921F). Прекрасный инструмент для анализа деятельности телеком-оператора, потому что универсально, системно, полно. Но опять же, не смотря на регулярные утверждения “у нас всё по eTOM” по моему глубокому убеждению _построить_ процессы по eTOM невозможно.
ITIL. А ITIL, если оставить в стороне претензии на системность и целостность (или попытки такого восприятия) предлгает вполне рабочие рекомендации “как строить процессы”. Неизвестно сколько их – конечно, везде по-разному. Путаются процессы и функции – конечно, практика показывает, что эти инструменты управления в разных организациях работают по-разному. Вот и в ITIL говорится об organization capabilities, которые могут быть и в виде функций, и в виде процессов, и в виде навыков и управленческой компетенции сотрудников. ITIL настолько же запутанный, противоречивый и по-разному толкуемый, как и управление в реальных организациях, которые нас окружают.
Смущает главный вопрос – зачем так разрабатывать вопросы экзамена, будто на них существует единственно верный ответ? И ладно бы только ITFO, но ведь и на менеджерском экзамене такая же петрушка. А я бы осторожно относился к менеджеру, который точно знает ответ на вопрос об “организации процесса управления мощностями”, он же и заказчику это приподнесет словами: “у нас есть типовой процесс, это best-practice”. Жуть.
Правду говорят: “Мудрый ищет истину, дурак уже нашел”.