Представьте, что Вы сдаёте экзамен 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». Жуть.
Правду говорят: «Мудрый ищет истину, дурак уже нашел».