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

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

Перечислим основные причины, по которым было решено совершенствовать процессное управление в ИТ-подразделении.

Необходимость соответствовать уровню зрелости бизнес-подразделений. Разработка программного обеспечения в компании организована на основе модели SEI CMMI. Подразделение контроля за качеством регулярно отслеживает метрики процесса, которые являются одним из важнейших параметров при оценке эффективности операционной деятельности, поэтому менеджмент ожидает аналогичных метрик и от поддерживающих подразделений.

Необходимость соответствовать требованиям внутренних стандартов Motorola. Для обеспечения требуемого уровня информационной безопасности корпорация адаптировала международный стандарт ISO 17799, а другие области работы ИТ-подразделения приводятся в соответствие со стандартами внутреннего контроля (Standards of Internal Control). Различные сферы операционной деятельности в ИТ-подразделении регулируются так называемыми стандартными операционными процедурами (Corporate Standard Operating Procedures, SOP).

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

Стремление к совершенствованию планирования и управления ресурсами. Рациональная деятельность ИТ-подразделения подразумевает постоянный контроль и оптимизацию затрат.

Два источника

Основными источниками совершенствования процессов ИТ-подразделения стали ITIL и COBIT. Инструмент COBIT был выбран для контроля за деятельностью ИТ-подразделения и предоставления отчетности менеджменту компании по метрикам, а также как подход, используемый в Motorola для ИТ-аудита. В свою очередь, ITIL — признанный набор передовых практик, помогающий реализовать рациональное и продуктивное управление ИТ.

Существуют и другие модели, на которых можно основываться при внедрении процессного подхода (такие, как HP ITSM Reference Model [1], Microsoft Operations Framework [2] и иные методологии, в разной степени приближающие идеи ITIL к практической реализации), но они имеют ряд ограничений. Так, ITSM Reference Model не является свободно доступной и используется HP в рамках собственных консалтинговых проектов, однако в нашем случае широкомасштабного привлечения внешних консультантов не предполагалось. Microsoft Operations Framework, одна из составляющих инициативы Microsoft Enterprise Services, фокусируется на эксплуатации информационных систем, преимущественно построенных на платформе Microsoft, а ядро инфраструктуры Центра Motorola базируется на Sun Solaris.

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

COBIT был выбран не только потому, что Motorola планирует использовать его в качестве инструмента внутреннего ИТ-аудита. Он также служит неоценимым источником структурированной информации по измеримым показателям деятельности ИТ-подразделения (метрикам), характеризующим как продуктивность работы (Key Goal Indicators), так и ее рациональность (Key Performance Indicators). Кроме того, COBIT содержит наиболее полный перечень процессов, что помогает стратегически оценить самые важные направления совершенствования деятельности ИТ.

COBIT основан на многих методиках и стандартах — ISO 9000, ITIL, SPICE, TickIT, Common Criteria, COSO. Как и ITIL, он базируется на процессах, является открытым и независимым от конкретных производителей, платформ и технологий.

Итак, основными целями проекта совершенствования процессного управления в ИТ-подразделении были:

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

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

Опыт совместного применения методик

Для совершенствования процессов в первую очередь необходимо оценить текущий уровень их зрелости. Для этого можно использовать как формальное аудирование, методика проведения которого подробно изложена в книге COBIT Audit Guidelines, так и широко распространенные инструменты самооценки процессов, описанных в книгах ITIL «Поддержка услуг» и «Предоставление услуг». Какой бы подход ни был выбран, результатом должна стать картина относительной зрелости процессов управления ИТ. В нашем случае применялась самооценка по 34 процессам COBIT.

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

Мы выбрали пять из 34 процессов, на которых было решено сосредоточить усилия: Document Management, Request Management, Security Management, Change Management, SLM. Не все они в точности соответствуют процессам, описанным в COBIT и ITIL. Так, сферы действия Document Management и AI4 (Develop and Maintain Procedures) у нас полностью перекрываются, причем Document Management является составной частью Configuration Management из ITIL. С другой стороны, активность процесса DS7 из COBIT (Educate and Train Users) у нас распределена между Request Management и Security Management. И COBIT, и ITIL вполне допускают подобную адаптацию к специфике конкретной организации.

Для определения измеримых результатов первого этапа по каждому из процессов были сформулированы цели: уровень документированности (требуется только высокоуровневое описание процесса либо необходим полный набор рабочих инструкций), собираемые метрики (вводить ли их на первом этапе, и если да, то какие и сколько), осведомленность/тренинги (кого и в каком объеме необходимо обучить, какие информационные материалы имеет смысл подготовить, нужны ли ресурсы на обучение в сторонней организации - какой потребуется механизм сертификации), способы контроля (как убедиться, что результат по данному процессу достигнут).

Крайне важным оказалось не только согласованно задать целевые уровни зрелости взаимосвязанных процессов (чтобы зрелый процесс не буксовал из-за недостаточно четкого взаимодействия с незрелым), но и составить проектный план с указанием временных этапов по каждому из процессов. В частности, сначала мы решили ограничиться в Document Management только высокоуровневым описанием правил (политикой), поэтому произошла двухнедельная задержка с подписанием процесса Security Management — документ составляли не по шаблону, и потребовалась его переделка. Из-за нечеткого следования проектному плану также возникла проблема: были несвоевременно подготовлены правила хранения документов, поэтому операционные записи процесса Change Management некоторое время хранились бессистемно.

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

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

При составлении плана работ нельзя забывать о такой важной вещи, как «быстрые победы», которые обеспечивают не только динамику ведения проекта, но и крайне необходимую поддержку со стороны руководства и персонала. Например, введение нового интерфейса для приема заявок пользователей дало дополнительную информацию и для процесса Request Management, и для Change Management, а результатом подписания процесса Security Management стало выделение на него дополнительных ресурсов.

Сложным, но очень важным является определение уровня детализации по каждому из процессов и областей их действия. Попытавшись уже на первом этапе максимально детализировать все элементы процесса, можно потратить недопустимо много времени на его поддержание при сомнительной эффективности такой деятельности. Например, для процесса Change Management было решено ограничиться только высокоуровневым описанием, поскольку на данном этапе показалось нецелесообразным затрачивать усилия на формализацию всех шагов прохождения запросов на изменение (Request for Change). Ограничение области действия позволяет сосредоточиться на самых актуальных аспектах. Так, процесс Security Management в части рассмотрения запросов на изменения охватывает только те запросы, которые относятся к документам и внешним каналам.

Дальнейшие шаги

Методики измерения и контроля, подробно изложенные в COBIT, удачно дополняют подход ITIL к реализации процессного управления. К сожалению, источников информации по опыту их совместного применения практически нет, поэтому во многом (в частности, при соотнесении отдельных процессов, описанных в этих источниках) пришлось разбираться самостоятельно, а план проекта — корректировать. Тем не менее результат работы признан в целом успешным, и в 2005 году планируется продолжить совершенствование процессного управления в ИТ-департаменте центра на основе данных подходов.

Организации, начинающие внедрять процессный подход делают первый шаг на пути постоянного улучшения. Для того чтобы планомерно продолжать эту деятельность, необходимо составить Программу постоянного улучшения услуг (Continuous Service Improvement Programme) или План повышения качества услуг (Service Quality Plan), а затем двигаться по шагам:

  • проектирование или реинжиниринг процесса и обеспечение готовности команды к изменению;
  • измерение продуктивности и рациональности;
  • оценка и выявление слабых мест;
  • принятие решений о наиболее эффективных изменениях.

Для нас ключевым вопросом становится система управления качеством. После проведения периодической оценки возникает вопрос, как при ограниченных ресурсах выбирать процессы — кандидаты на усовершенствование. Иными словами, собрав метрики по процессам, мы видим путь и можем определить цену улучшения каждого из них, но как отобразить общее «качество работы» ИТ-подразделения на конкретные процессы — пока неясно. Конечно, у западных консультантов есть такие методики, но неизвестно, насколько они хороши.

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

Обмен знаниями с другими организациями, также занимающимися усовершенствованием управления ИТ-подразделением, является неоценимым источником информации. К сожалению, публикаций об успешно завершенных проектах внедрения процессного подхода крайне мало, причем зачастую они являются не более чем рекламными «ходами» интеграторов.

Возможно, это связано с двумя обстоятельствами. Во-первых, уровень профессионализма сотрудников многих компаний-внедренцев, действующих в сфере ITSM, пока невысок и опыта выполненных проектов у них немного. Во-вторых, внедрение данного подхода предполагает постоянное улучшение процессов, и рапортовать о «полностью внедренных процессах» могут себе позволить немногие. Остается надеяться, что доля организаций, использующих передовой опыт управления ИТ-подразделениями, вскоре будет в России не меньшей, чем в Нидерландах или Великобритании.

Литература

  1. Илья Хает, Сергей Ямов. Простота и сложность ITSM // «Открытые системы». -- № 1. -- 2004.
  2. Владимир Бахметьев. MOF дополняет ITIL. «Открытые системы», 2004, № 1.

Николай Крачун (NKrachun@motorola.com) - ИТ-менеджер Motorola Global Software Group - Russia (Санкт-Петербург).

Центр программных разработок Motorola

Петербургский Центр разработки программного обеспечения входит в подразделение Global Software Group, создающее программные компоненты для продуктов корпорации. Центр открыт в июне 1997 года. Сегодня в нем работают более 350 сотрудников. Его деятельность связана с разработкой программного обеспечения для микропроцессорных систем, используемых в средствах связи, компьютерах, автомобильной и бытовой электронике, в области телекоммуникаций.

Центр создает системы на разных программных и аппаратных платформах. В частности, ведутся разработки в области встроенных систем реального времени, которые направлены на реализацию операционных систем различного применения. Важным направлением деятельности является разработка программного обеспечения для автомобильной электроники и автомобильных телематических систем. Еще одно направление связано с программной реализацией функциональности Java-телефонов.

В 2004 году технологический процесс разработки программного обеспечения, внедренный в центре, был оценен как соответствующий пятому, наивысшему, уровню зрелости согласно модели SEI CMMI.

Источники совершенствования процессов

ITIL

ITIL — наиболее распространенный подход к управлению ИТ-подразделением как поставщиком услуг. ITIL представляет собой взаимосвязанный набор методов, лучших практик из опыта общественных и государственных организаций, а также предприятий частного сектора. Основу подхода дают книги Библиотеки ITIL, издателем которой является британская правительственная организация — The Office of Government Commerce. Библиотека публикуется под эгидой правительства, поэтому все права на нее защищены; воспроизведение или публикация ее материалов должны быть согласованы с ее издателем. Использование подхода, процессов и практик, описанных в ITIL, не ограничивается.

Существующие квалификационные схемы поддерживаются двумя организациями. Это Information Systems Examination Board, подразделение Британского компьютерного общества, и голландский экзаменационный институт EXIN. Квалификационные схемы действуют лишь в отношении отдельных специалистов, а для организаций возможности получить формальный статус «соответствующей ITIL» не существует.

COBIT

COBIT — набор из шести публикаций, созданный организациями ISACA и ITGI. Структурированность проявляется в COBIT очень сильно: четыре базовые группы (домена) содержат 34 процесса, которые управляются 318 сферами контроля. COBIT больше предназначен не для управления ИТ-инфраструктурой, а для аудита информационных систем компаний, поскольку разработан в основном сотрудниками консалтинговых фирм. При этом такие его элементы, как модель зрелости процессов, инструмент проведения аудита и набор инструментов внедрения (Implementation Tool Set), могут оказать неоценимую помощь при внедрении процессного подхода к управлению ИТ-инфраструктурой.

Внедрение процесса Security Management

Внедрение процесса управления информационной безопасностью проходило в несколько этапов: назначение одного из сотрудников ответственным за процесс (Security Manager), сбор обязательных требований к информационной безопасности, пересмотр текущей деятельности в свете этих требований и перечисление видов активности. Возникли следующие вопросы. Как измерять ресурсы, необходимые для этой деятельности? Как удостовериться в том, что и в дальнейшем будут удовлетворяться все требования политик Motorola?

Для облегчения работы за основу взяли два источника. Первый - COBIT, домен Delivery&Support, раздел Ensure Systems Security. Там замечательно описывается, что должно быть сделано (сферы контроля - Control Objectives) и чем это надо измерять (метрики - KPI & KGI). Но оставался вопрос, как внедрять. Тут пригодился второй источник - ITIL, книга Best Practice for Security Management.

Рис. 1. Описание окружения процесса

Следующим этапом внедрения процесса Security Management была структуризация активностей. Хотелось написать простой, а главное — собственный процесс. Было решено построить две диаграммы на основе текущей деятельности: одна описывает окружение процесса (рис. 1), а вторая - его основные элементы (рис. 2):

Рис.2. Описание основных элементов процесса
  • контроли — требования политик Motorola и других предписывающих документов;
  • ресурсы — люди, оборудование и программное обеспечение;
  • входы в процесс — на данном этапе имеются только из процесса Change Management (запросы на изменение конфигурационных единиц, например открытие нового канала связи);
  • выходы — документы, в другие процессы и т.д.

Что внутри процесса? Оказалось, что часть видов активности осуществляется регулярно в течение дня, а часть — время от времени. Ежедневно анализируются запросы на изменения, обеспечиваются тренинги и консультации пользователям, проводится мониторинг предписаний по безопасности корпоративной службой ИТ-безопасности и собирается статистика с отчетами для руководства центра. В оговоренный период, скажем раз в год, выполняется стадия «Оценивание». Она заключается в анализе метрик и создании отчета, на основании которого выявляются слабые места защиты. Стадия «Воплощение» состоит в изменении документов, правил и т.д. В результате получился цикличный процесс.

Следующий этап внедрения процесса Security Management состоял в определении ролей и метрик. Роли нужно было разбить на три типа: кто осуществляет активность внутри процесса, от кого зависит процесс и на кого он влияет снаружи. Это важно для корректного распределения сфер ответственности, регулярного информирования и обучения.

Метрики нужно собирать двух типов:

  • продуктивность процесса — насколько хорош его результат по COBIT;
  • рациональность процесса - хорошо ли используются выделенные ресурсы.

Таким образом, при ограниченных ресурсах был за два месяца написан процесс, который стал первой итерацией внедрения Security Management. Дальнейшее совершенствование процесса зависит в том числе от изменения уровня зрелости связанных процессов, например Change Management.

Виталий Фролов