Управление в малых ИТ-подразделениях.

"Персоналу шесть душ, локалка на две сотни рабочих мест плюс серверов с десяток, телефония, Интернет-канал...".

Наверное, такое понимание сферы своей деятельности и объектов управления присуще большинству ИТ-менеджеров, имеющих в подчинении от двух до десятка работников и отвечающих "за все, что с проводами, кроме кофеварки". Обычно такое описание сферы ответственности устраивает и их руководство - коротко и ясно. Гораздо труднее получить ответ на простой вопрос - "зачем?". Формулировка отдела ИТ обычно столь же проста сколь и бессодержательна: "Чтоб все работало и юзеры не жаловались." Руководство со своей стороны далеко не всегда понимает не только чем заняты все эти "компьютерщики", но и что компании дают сервера, Интернет - вообще все это компьютерное хозяйство кроме разве что ноутбука самого директора. Из-за этого не только затруднено нормальное взаимопонимание между ИТ и руководством компании (например, обсуждение затрат на ИТ упирается в тот же вопрос - "зачем?" - а объяснять директору преимущества клиент-серверной модели занятие зачастую неблагодарное), но и фактическая польза для бизнеса от затрат и усилий ИТ-подразделения неизмеряема, неуправляема и, как следствие, низка.

Говорить о пользе ИТ, выгоде от вложений в информационную инфраструктуру можно только в том случае, если на выходе есть (точнее, виден) некий продукт, вернее, поскольку речь идет о работе с информацией, услуга. Отдел Информатики как, например, и бухгалтерия предоставляет бизнесу услуги. В случае бухгалтерии это выставление счетов, составление необходимой отчетности, анализ финансовх потоков, а в случае ИТ - использование 1С, возможность сетевой печати или доступ в Интернет. К сожалению, руководству трудно самостоятельно сформулировать, какие конкретно ИТ-услуги нужны бизнесу. В такой ситуации ИТ-менеджер - единственный человек, который может (и заинтересован) "наводить мосты" между работой своего отдела и основной сферой деятельности компании. Построение "списка услуг" поможет в первую очередь ему самому - как для того, чтобы обоснованно "пробивать" финансирование или увеличение штата, так и для более эффективной организации труда в подразделении.

Получив благодаря такому списку ответ на вопрос "зачем?", мы можем по-другому взглянуть на то, чем же все-таки надо управлять. Люди, провода, "железо" - это необходимые инструменты ИТ-менеджера для предоставления бизнесу услуг. Конечно эти инструменты требуют руководства, обслуживания, замен. Но организовывать надо не работу каждой из этих составляющих по отдельности, а использование их как единого целого. Иными словами, управлять предоставлением услуг.

"Управление услугами - звучит заумно и теоретично. Для книжек по менеджменту оно наверно хорошо, только переходить от всем понятого администрирования локальной сети к какой-нибудь 'Услуге сетевого доступа' особого желания нет. В разговорах с руководством можно, конечно, красивыми терминами блеснуть, а вот в реальной работе удобство такого подхода сомнительно."

Во-первых, речь не идет о том, что надо уволить сисадмина или забыть про правила создания резервных копий. Во-вторых, список услуг, о котором шла речь выше, не главное и уж точно не первое, что имеет смысл брать на вооружение из предлагаемого подхода. Помнить, что ИТ-отдел работает для предоставления услуг, надо в первую очередь для того, чтобы в каждый момент времени ясно понимать: "зачем мы делаем именно это а не иное". Понимание того, что целью каждой работы, закупки или изменения штатного расписания является польза для бизнеса поможет делать меньше ненужного а необходимое делать лучше.

Как же собственно предлагается планировать, осуществлять, контролировать и оценивать результаты каждодневной деятельности ИТ? В общем и целом - так же, как это уже делается в подавляющем большинстве отделов информатики: работы надо структурировать, объединяя их в группы. Правда, принцип организации таких групп может отличаться от принятого в отделе на данный момент. Конечно, работы по обслуживанию кабельных трасс, настройке протоколов и служб, управлению доменной структурой и т.д. никуда не денутся - это хорошо структурированная последовательность работ, логично объединенная в упомянутый выше процесс администрирования локальной сети. Но всегда ли ваш сетевик готов ради банальной процедуры (например, замена нерабочего сетевого кабеля) отложить увлекательное и высокоинтеллектуальное занятие вроде тонкой настройки листов доступа на маршрутизаторе? Наверное, нет и скорее всего он прав - отвлекаясь на срочные дела, не требующие особой квалификации, он в итоге принесет компании меньше пользы. Подобные рутинные работы поэтому разумно выделить в отдельную группу и создать "отряд быстрого реагирования" (возможно даже из одного человека), задачей которого будет прием заявок от пользователей, оказание им необходимой помощи и ликвидация различных поломок. В случае серьезных аварий, требующих квалифицированного вмешательства, надо наделить эту "службу скорой помощи" правом срочно привлекать других сотрудников к их ликвидации. Таким образом в процесс устранения поломок могут быть вовлечены различные сотрудники, но при этом есть человек, координирующий работы и отвечающий за результат - стабильную работу пользователей.

Основным принципом объединения работ в логически взаимосвязанные последовательности - процессы - предлагается принять наличие у них единой цели. Важно понимать, что при таком подходе мы не учитываем ни существующее распределение работ, ни деление зон ответственности в отделе по технологическому признаку. К достижению цели "любая поломка должна быть ликвидирована в течение часа" могут привлекаться и сисадмин, и ИТ-менеджер, и сторонняя организация. Если мы сможем сформулировать для себя все (или хотя бы основные) цели, в сумме обеспечивающие качественную работу ИТ как поставщика услуг - пол дела сделано. Останется объединить выполняемые работы в группы, каждая из которых ведет к достижению своей цели, и понять, по каким параметрам мы будем оценивать результат каждого такого процесса.

"Похоже, ничего оригинального в этом подходе нет. Судя по тому, что мы предоставлением услуг управлять должны, целями у нас они и будут - нормально предоставленные услуги (без перебоев и с хорошими техническими характеристиками). А уж для оценки результатов параметры известны - скорость обработки SQL-запроса, объем Интернет-трафика, время отклика Веб-сервера мерить умеем. Только для каждой услуги процесс строить - не слишком ли неказисто?"

Конечно, неказисто, а главное - не нужно. Нормально предоставляемые услуги - это наша глобальная задача. Для ее решения как минимум надо: чинить то что сломалось как можно быстрее, разрешать возникающие проблемы, точно знать, какое ПО и "железо" у нас есть, иметь правила внедрения нового и замен имеющегося. Ради этих целей - общих для всех услуг - и надо выстраивать процессы. Так что управляем мы не самими услугами (каждой по отдельности), а разными аспектами их предоставления: ликвидацией поломок, разрешением проблем, изменениями в инфраструктуре, ее составом и конфигурацией. Конечно, это далеко не полный список. Надо согласовывать с руководством состав и описание услуг, своевременно готовить планы модернизаций, "считать деньги" и своевременно выявлять "узкие места", не забывать о безопасности и быть готовым к авариям. Кроме того, как уже говорилось, остаются и операционные процессы (например, управление ЛВС или администрирование СУБД).

Цели у каждого процесса свои - либо непосредственно обеспечивающие должный уровень услуг (например, максимально допустимое время простоя может быть напрямую оговорено в описании услуги) либо "помогающие" другим процессам - точная информация о составе и конфигурации инфраструктуры нужна и при ликвидации поломок и для планирования модернизаций. Но, как уже было сказано, поставить задачу мало - обязательно надо ввести четкие критерии оценки достижения целей.

Такие индикаторы успешности работы процессов должны быть понятны для всех участников (то есть не быть чересчур технически сложными), точно соответствовать цели процесса и быть измеряемыми, то есть мы должны понимать, как конкретно получить числовое значение индикатора. Термины "хорошее", "быстрый", "точная" для них недопустимы - нам нужна шкала для измерения, чтобы о любом процессе можно было сказать: "он успешен на 85 процентов". В каждом случае мы сможем таким образом зафиксировать, к какому результату мы стремимся - например, для управления ликвидацией поломок успехом может считаться: "количество поломок, не исправленных за час, не более пяти процентов от всех случившихся." Тогда, получив от нашей "службы скорой помощи" статистику по числу поломок и по времени их ликвидации, мы легко оценим успешность по этому параметру. Скорее всего он будет не единственным индикатором для этого процесса - важны также и среднее время исправления и процент поломок, ликвидированных без привлечения дополнительных сотрудников (самим "отрядом быстрого реагирования"). Рассмотренные вместе, значения этих индикаторов говорят нам о качестве выполнения процесса. Поэтому улучшение качества выполнения процесса - это приближение реальных значений индикаторов успешности к целевым. Для того же, чтобы повысить качество всей нашей работы - качество предоставляемых услуг - надо помимо этого "поднять планку" успешности каждого из процессов.

В этом подходе действительно нет ничего оригинального - ориентация на услуги, процессное управление и нацеленность на качество за последние десятилетия стали "общим местом" в менеджменте. Удобство его использования в том, что он содержит готовый набор "подсказок", основаный на опыте управления ИТ в реальных организациях.

Я уже попытался дать ответ на вторую часть вопроса: "Что за теория такая - ITIL - и зачем она нужна?".
Если от многократно повторенных слов вроде "услуга", "процесс", "качество" еще не уснули, а интерес к тому, каково же оно "в деле", поввился, обсудим сперва:

"Набор подсказок - это, конечно, хорошо, но от подхода к управлению желательно системность получить. И что это за организации, которые свой опыт в свободный доступ выложили? И в каком виде это сделано?"

К сожалению или, скорее, к счастью ИТИЛ (или если уж по-русски БИИТ - Библиотека Инфраструктуры ИТ) особой системностью не отличается. Это не методология, не пошаговая инструкция, что и как надо делать. В первой редакции Библиотека состовла из примерно 40 книг, описывающих разные процессы или аспекты применения этого подхода. Во второй редакции, действующей на данный момент, процессы объединены в группы и по каждой из них выпущена (или вот-вот поввится) отдельная книга.

Официальный автор - британская правительственная организация OGC (Office of Government Commerce), изначальной задачей которой было помочь гос. структурам в формализации их отношений с подрядчиками - поставщиками ИТ-услуг. В Великобритании даже действует официальный стандарт на Управление Услугами (BS 15000), который базируется на ITIL. Хотя формальное авторство принадлежит OGC, в написании участвуют представители и организаций-заказчиков, и поставщиков, и консультантов. В книгах описываются группы процессов (например, Поддержка Услуг - Service Support), объединенные по принципу нахождения на шкале "Технология - Услуги". Ключевыми считаются две группы - Поддержка и Доставка (Delivery) Услуг.

Про каждый процесс говорится: какими терминами пользуемся, его цели, входы и выходы, функции и роли, связь с другими процессами, деятельности, индикаторы успешности, методы контроля, затраты и выгоды, возможные сложности и советы по внедрению. Хотя в написании авторы базировались на реальном опыте работы, никакой организационной специфики в этих моделях нет. С одной стороны, в этом огромный плюс - отсутствие привязки к конкретным структурам дает возможность использовать ITIL не только в британских государственных организациях, но и в ИТ-компаниях и подразделениях любой формы собственности по всему миру. С другой стороны, для практического внедренения приходитсв либо использовать какую-либо методологию (то есть платить вендору или консультанту), либо внедрять "по собственному разумению", что требует дополнительных затрат и увеличивает риск неудачи.

"Были бы деньги на консультантов - у них и спрашивал бы. А риск неудачи есть всегда, так что будем пытаться своим умом доходить. Только с чего начинать-то? И что делать с текущей работой?"

Начинать (что вполне естественно) надо с чтения книг Библиотеки. К сожалению, на данный момент переводов на русский нет, а за оригинальные книги придется выложить около 150 долларов за штуку. Альтернативой (во всяком случае, на первом этапе) может быть покупка за 38 долларов "Введения в ITIL" (IT service management - An introduction) издания itSMF (Форума по Управлению Услугами ИТ, объединяющего теоретиков и практиков ITIL). Кстати, уже идут работы по переводу этой книжки на русский. При наличии хотя бы небольшого бюджета также очень желательно сходить на 2-3дневные курсы по основам ITIL - книжки книжками, а общение с практиками дорогого стоит. И конечно очень многое можно почерпнуть в Чети - полная картина при только ее использовании вряд ли сложится, но полезностей можно найти немало.

Когда знания начнут переполнвть - пора начинать ими делиться. Может быть самым важным во внедрении ITIL явлвется изменение психологии сотрудников ИТ, их переориентация с "работы с железками" на "обслуживание Клиента". На это нельзя жалеть ни времени ни усилий. До тех пор, пока слова "услуга", "процесс" и "качество" не станут в ИТ-отделе привычными и незаменимыми, никакав формализация процедур ничего не даст. Важно, чтобы сотрудники воспринимали "предоставление услуг" не как дополнительную работу, а как способ оптимизации (в том числе и в их интересах) всей существующей деятельности. Измениться должна также и оценка качества выполнения задач как отдела в целом, так и каждого отдельного работника. Надо стараться меньше говорить о том что "сеть ни разу за год не легла" (хотя это конечно существенно), и чаще спрашивать себя "довольны ли пользователи"?

Текущая работа действительно никуда не денется. Более того, пока она нормально не налажена переходить скажем к уровню Доставки Услуг бессмысленно - доставлять нечего. Так что начинать (если это еще не сделано) надо с технического (Technical) и операционного (Operations) уровней. Естественно в ITIL по ним тоже есть описания процессов, но на этих уровнях, в отличие от Поддержки и Доставки Услуг, достаточно опытный, технически грамотный и нормально образованный ИТ-менеджер может построить "правильные" процессы сам, руководствуясь профессиональными знаниями и интуицией. Надо только не забывать о "трех китах" - пользоваться процессным подходом, вводить (и применять) критерии оценки качества и в каждый момент оценивать, зачем нужна (и какую пользу приносит бизнесу) конкретная железка, канал данных, программа, резервная копия.

Если о наличии бэкапов голова уже не болит, а сбой ПК стал явлением редким - настала пора ИТ-отделу выстраивать взаимоотношения с "внешним миром". И в превую очередь с теми, без кого его функционирование невозможно - с внутреними и сторонними поставщиками внешних для ИТ услуг. Во многих реализациях ITIL Управление Окружением (Environmenal Management) считается фундаментом функционирования всей информационной системы. Действительно электрика, вентилвция, кондиционирование, обычно не входвщие в сферу ответственности ИТ-отдела, влияют на его работу принципиально. Поэтому пока нет спокойствия и уверенности в этих вопросах - двигаться дальше опасно.

Когда решена и эта задача, можно наконец переходить к реализации первой функции из ITIL-овского блока Поддержки Услуг - создать в отделе Центр Обслуживания. Это еще не реализация какого-то процесса (в Service Support описаны пять процессов и одна функция - function - Service Desk), но в поддержке услуг - один из ключевых элементов. Центр Обслуживания (иногда его называют Help Desk) должен стать единой точкой контакта отдела с "внешним миром". Таким образом решаются две задачи. Во-первых, это упростит жизнь пользователям - всегда будет к кому обратиться и человек "на телефоне" не сошлется на то, что ему "не до мелочей". Во-вторых, появлвется возможность фиксировать, документировать и измерять поток работ, выполняемый отделом ИТ. Этим будет сделан первый шаг во внедрении блока процессов Поддержки Услуг.

"Создать единую точку доступа - хорошая мысль, но ведь человека выделить придется. А потом еще под каждый процесс - отдельного? А где отдача? И как собственно процессы внедрять?"

Трудно однозначно сказать, приведет ли применение ITIL к увеличению потребности в ресурсах (в том числе кадровых) или нет. Это зависит как от уровня зрелости ИТ-отдела до начала внедрения (если он низок, то оптимизация работ может даже привести к их высвобождению) так и от "глубины" внедрения. Но даже если дополнительные ресурсы на каком-то этапе потребуются, не надо забывать о повышении общего качества работы ИТ. Это именно тот козырь, с помощью которого можно "выбивать" деньги у руководства. К сожалению, пока не измеряется качество услуг или хотя бы удовлетворенность пользователей (а это нереально без Центра Обслуживания), цифр и фактов для аргументации нет. Поэтому на этапе создания Центра Обслуживания придется либо обойтись внутреними ресурсами (могли появиться в процессе оптимизации операционного уровня) либо разработать и представить руководству план по реструктуризации отдела (например, берем дополнительного - дешевого - человека на ЦО, оптимизируем работу, через девять месвцев одного из двоих сисадминов сокращаем). Но в любом случае нужен среднесрочный (примерно на год-полтора) план внедрения.

"Кадры решают все". Продумывав план "ITIL-изации" отдела надо в первую очередь оценить, кто из сотрудников более склонен к аналитической работе, кого можно "допускать до пользователей", а кому вы можете доверить работу, требующую максимальной педантичности. При этом надо ориентироваться не столько на профессиональные навыки сколько на человеческие качества. Исходя именно из этой оценки выбирайте владельцев процессов. Они будут вместе с вами "выстраивать" процессы, а потом контролировать и улучшать их работу. В выполнение конкретных процедур будут вовлечены и другие сотрудники (в том числе и владельцы других процессов), но отвечать должен он один. При этом ничто не мешает при распределении ответственности и полномочий совмещать разные функции и роли в одной должностной инструкции. Один и тот же сотрудник может быть владельцем одного или нескольких процессов и исполнителем - в других. Даже в отделе из двух человек в принципе возможно "поделить" между собой базовые процессы ITIL - причем с реальной пользой для дела. Если же ИТ-отдел состоит хотя бы из четырех человек распределение ответственности за процессы пройдет как по маслу.

Для того, чтобы все эти управленческие телодвижения приносили удовлетворение вам и были оценены руководством, нужны "быстрые победы". На этапе оптимизации операционного уровня это регламентация плановых работ (а соответственно повышение их "прозрачности" и четкое планирование). В результате ИТ-менеджеру уже не будут сниться кошмары на тему "А что если PDC ляжет?!" - теперь у него есть регламентный бэкап, процедура восстановления и ответственный сотрудник. В создании Центра Обслуживания главная выгода - появление точки сбора информации обо всех событиях, происходящих в ИТ. Как результат через два - три месяца вы будете иметь статистику по обращениям пользователей, с которой уже можно идти к руководству с предложением о путях снижения их количества. Это уже те самые "цифры и факты", которые помогают ИТ в разговоре с Бизнесом. С этого и начинается выстраивание отношений "Поставщик - Заказчик".

Кажется, теперь можно было бы и о внедрении процессов поговорить. Но если до сих пор рассказывать об ITIL можно было на "кухонном" уровне, тут уже требуется строгость определений и формулировок, знание терминологии и т.д. Поэтому настал момент погулять по Сети, а лучше всего сразу заказать книги Библиотеки. Не забывайте также о ценности вербального общения - курсы и семинары бесценный источник знаний. Успехов в ITIL-изации!

"Раз ИТИЛ - процессный подход, надо наверно четко описать, а лучше определить - что же такое процесс?"

Можно, конечно, заглянуть в толковый словарь и прочесть там что-то вроде:

1. последовательная смена состояний, каких-л. явлений, ход развития чего-л.;
2. совокупность последовательных действий для достижения какого-л. результата, напр. производственный п.

Это в общем то и так "интуитивно ясно". Однако из п.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).
• Наконец - подробное (пусть черновое, но чтоб по ним работать можно) описание процедур и базовое описание ролей.
• Все, можно "вводить в эксплуатацию" и заниматься:
• корректировкой написанного
• уточнением процедур и ролей
• написанием рабочих инструкций.

"Отлично, можно приступать. Начинать наверно надо с Процесса Управления Услугами - он ведь ключевой."

Действительно Управление Услугами - в своем роде "центральное звено" для всех ИТИЛовских процессов. В создающейся "с нуля" организации или подразделении начинать именно с него может быть правильно. Но для уже функционирующей структуры это не лучший путь. Перед тем, как ответить себе на вопрос "за какой процесс браться в первую очередь", надо понять "что имеем", то есть оценить степень зрелости как всего ИТ в целом, так и групп процессов управления ИТ. Конечно, для оценки группы процессов придется рассматривать каждый, но для того, чтобы решить, с какого процесса начинать, нужна интегральная оценка зрелости групп.

Методик оценки зрелости существует немало и здесь не место обсуждать их и сравнивать. Предположим, что выбрана некая методика, проведена оценка и на выходе у нас для каждого процесса - балл от 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.
И не забывайте - ITIL <=> IMHO :-)