Раз ИТИЛ - процессный подход, надо наверно четко описать, а лучше определить - что же такое процесс. Можно, конечно, заглянуть в толковый словарь и прочесть там что-то вроде:
последовательная смена состояний, каких-л. явлений, ход развития чего-л.;
совокупность последовательных действий для достижения какого-л. результата, напр. производственный п.;
Это в общем то и так "интуитивно ясно". Однако из п.2 мы видим, что помимо "процессов вообще" есть например производственный процесс, так что надо идти глубже, чтобы понять специфику именно ИТИЛовских процессов и получить "рабочее" определение. В нем, во-первых, должно быть собрано специфичное для ИТИЛ содержание (в частности, нацеленность на услуги и качество) и во-вторых, дано внутренее строение и внешние связи.
Итак, начнем изыскания. Наиболее общее определение дает нам ГОСТ Р ИСО 9000 - 2001: "Процесс - совокупность взаимосвязанных и взаимодействующих видов деятельности, преобразующая входы в выходы.
В ITIL - точнее в книге "Service support" ("Поддержка услуг") приводится следующее определение: "A connected series of actions, activities, Changes etc. performed by agents with the intent of satisfying a purpose or achieving a goal." ("Связанный набор действий, видов деятельности, изменений и т.д., выполняемый агентами с целью удовлетворения потребности или достижения цели.")
Здесь добавилась важная для понимания процессов составляющая - агенты. Кроме того, вместо выходов (про которые забывать не надо, поскольку при проектировании процесса их придется выделять и специфицировать) упомянуто, что у процесса есть некая цель.
Вот еще одно (CobiT): "Процесс - это действие, направленное на достижение результата, которое может корректироваться при его выполнении и которое сосредоточенно на достижении конечного результата при оптимальном использовании ресурсов."
Отсюда мы можем взять две вещи: процесс должен управляться (корректироваться) и его надо строить оптимально.
Можно наверно найте полезные зерна и в других источниках, но большинство так или иначе повторяют уже сказанное. Например в PMBOK 2000 edition читаем: "series of actions bringing about a result". Так что перейдем к тому, из чего он состоит. Предлагается такое деление процесса на составляющие:
подпроцесс (subprocess) - является частью процесса, но не теряет его свойств
деятельность (activity) - набор действий выполняемых одной ролью
действие (action) - атомарная единица процесса
Кроме того, надо не забыть о том, что процессы надо как-то описывать. Для этого существует процедура - описание логически связанных деятельностей и их исполнителей (для большей детализации и удобства обычно составляют набор Рабочих инструкций, которые определяют, как следует выполнять виды работ, входящие в состав процедур).
И, наконец, помимо ролей для каждого процесса важно определить владельца (именно он отвечает за него, имеет право его менять и т.д.) и менеджера (он осуществляет "оперативное управление"). Конечно это тоже роли, но роли специфические и очень важные. Они должны быть четко определены для каждого процесса, даже если выполнять их будет один человек.
Постараемся теперь ничего не потерять но и без лишнего обойтись:
Процесс - это цикличный и воспроизводимый набор логически связанных деятельностей, направленных на достижение общих целей, описанных процедурами и исполняемых менеджером процесса и другими ролями (агентами) с использованием выделенных ресурсов, управляемый владельцем для оптимизации по затратам с использованием измеряемых характеристик (метрик), который преобразует определенные входы в контролируемые по качеству выходы.
(Process - a cyclic and reproduced set of logicaly related activities connected by general targets, described by procedures and performed by process manager and other roles (agents) using allocated resources, controlled by the owner to be optimal in efforts and costs using measured indicators (metrics), which convert specified inputs into the quality controlled outputs.)
Возможно, результат получился громоздким, но зато теперь мы знаем, что такое процесс "по-ИТИЛовски".
Методика внедрения процессов.
"Определение внушительное. Только из него все равно не ясно, как процессы эти создавать, в смысле выстраивать."
Попробуем кратко прикинуть, в каком порядке и что именно надо делать, чтобы "построить" ИТИЛовский процесс.
Итак:
Вначале необходимо для процесса определить цели (с ключевыми факторами успеха для первой стадии), входы-выходы, ресурсы, политики.
Затем составить список процедур (для них - входы-выходы, цель, контроль)
Далее - шаблоны информационных ресурсов (к примеру - что должно быть в любом trouble ticket), первая версия справочников (к примеру - типы service call, статусы инцедентов, etc).
Наконец - подробное (пусть черновое, но чтоб по ним работать можно) описание процедур и базовое описание ролей.
Все, можно "вводить в эксплуатацию" и заниматься:
корректировкой написанного
уточнением процедур и ролей
написанием рабочих инструкций.
Последовательность внедрения ITIL-процессов.
"Отлично, можно приступать. Начинать наверно надо с Процесса Управления Услугами - он ведь ключевой."
Действительно Управление Услугами - в своем роде "центральное звено" для всех ИТИЛовских процессов. В создающейся "с нуля" организации или подразделении начинать именно с него может быть правильно. Но для уже функционирующей структуры это не лучший путь. Перед тем, как ответить себе на вопрос "за какой процесс браться в первую очередь", надо понять "что имеем", то есть оценить степень зрелости как всего ИТ в целом, так и групп процессов управления ИТ. Конечно, для оценки группы процессов придется рассматривать каждый, но для того, чтобы решить, с какого процесса начинать, нужна интегральная оценка зрелости групп.
Методик оценки зрелости существует немало и здесь не место обсуждать их и сравнивать. Предположим, что выбрана некая методика, проведена оценка и на выходе у нас для каждого процесса - балл от 0 до 5. Теперь надо рассмотреть оценки по группам (Operational, Support, Delivery). Если в группе Операционных процессов есть хоть один с баллом ниже тройки - забудьте временно про "отношения Бизнеса и ИТ" и прочие высокие слова - подготовьте себе тылы (в данном контексте под Операционными процессами имеется ввиду все то, что называют Technical, Operations, а также Environmenal Management). Однако не надо забывать о следующей цели - уровне Поддержки Услуг. На нем есть бесценная функция - Центр Обслуживания, которая может помочь и на этапе приведения в порядок операционного уровня. Итак, первый шаг при таком раскладе - создание Центра Обслуживания и ""доведение до ума группы операционных процессов (внутри нее - Technical => Operations => Environmenal, подробнее - зависит от используемых технологий).
Говоря о группе процессов Поддержки Услуг, можно предложить такой порядок: сперва Управление Инцидентами и Проблемами (вместе с "причесыванием" Центра Обслуживания), затем Изменения, потом Конфигурации и Релизы. Опять же надо помнить о следующей цели - Доставке Услуг - и параллельно с процессами уровня Поддержки хотя бы контурно обозначить рамки и содержание Процесса Управления Услугами. Заработав минимум по три балла процессам поддержки, можно довести до ума Управление Услугами и ... сделать шаг в сторону от доставки услуг, задумавшись над тем откуда они (услуги) берутся. Конечно если в вашей организации набор сервисов крайне стабилен и с его изменением вполне справляется операционный уровень - можете не волноваться. Если же время от времени присутствует некий development - самое время заняться именно им. Так что следующий шаг - Production Management.
Если вы добрались до этой стадии - наверно сами разберетесь, в каком порядке внедрять Availability, Capacity и Continuity Management. А Управление Финансами советую оставить "на сладкое" - с него плавно перейдете на Business - IT alignment, займете место CIO...
Все вышесказанное относится в первую очередь к тем ИТ-структурам, в которых идея жить по-ИТИЛовски идет "изнутри". Если же к вам "сверху" пришло указание <<внедрить SLA за три месяца>> - деваться некуда, порядок внедрения будет совсем другой. Кроме того, это только общие принципы, описывать же порядок для всех вариантов результата оценки зрелости - за отдельные деньги. А тонкостей может всплыть немало. Например, если процесс Service Continuity Management получил ноль баллов - бросьте все и готовьтесь к пожару-наводнению-землетрясению. Так что изучайте внимательно best practice.
