Британское собрание прошедших проверку на практике процессов ИТ (IT Infrastructure Library, ITIL) находит все большее распространение.

В статье описываются возможности использования ITIL на малых и средних предприятиях и даются некоторые полезные советы.

Исходной точкой и основой ITIL (см. врезку «Что такое ITIL?») являются парадигмы управления услугами ИТ (IT Service Management, ITSM), базовые принципы которых можно сформулировать следующим образом: на предприятии ИТ находятся в положении поставщика для клиента, а единственным оправданием существования ИТ служит вклад в деловой успех клиента. Иначе говоря, услуги, предоставляемые информационными технологиями, должны согласовываться с клиентом, причем таким образом, чтобы полезность ИТ можно было оценить.

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

в компании, что, в свою очередь, предполагает управление необходимыми процессами и тем самым определение процессов ИТ.

СТРУКТУРА ОБЩЕСТВЕННЫХ ДОМЕНОВ

ITIL следует понимать как схему, в соответствии с которой эксперты описывают собственный опыт и дают согласованные рекомендации по формированию процессов ИТ. Соответствующие рекомендации можно — но вовсе необязательно — использовать полностью. Ориентация на ITIL не является самоцелью: приоритет остается за эффективными процессами ИТ.

ITIL делает ставку на построение деловых отношений между ИТ и клиентом. Эти отношения фиксируются в соглашениях об уровне сервиса (Service Level Agreement, SLA) и, с переходом отдела ИТ на оказание услуг, проникают во все области. ITIL считается «значимой» для предприятий любого масштаба и, соответственно, фокусируется скорее на «что», а не на «как», поскольку непосредственная реализация концепций индивидуальна для каждой организации.

Рисунок 1. Обзор взаимосвязей ITIL: процессы ITIL должны адаптироваться в соответствии с индивидуальными потребностями предприятия.

Целенаправленное управление процессами ИТ позволяет постоянно улучшать качество как самих процессов, так и предоставляемых услуг ИТ, для чего необходимо иметь возможность измерять и те, и другие. На Рисунке 1 изображены важнейшие взаимосвязи, среди которых отдельно выделены:

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

В общей сложности ITIL в трех основных книгах описывает 11 процессов, причем пять оперативных объединены под названием «Сервисная поддержка». По каждому ITIL дает конкретные советы, приводит подтвержденные практикой факторы успеха и наряду с преимуществами указывает на предполагаемые сложности при реализации процессов.

ПРИМЕР КОНТРОЛЯ ПРОИСШЕСТВИЙ

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

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

Затем, в соответствии с рекомендациями ITIL, следует создать службу технической поддержки в качестве «единственной точки контакта» (Single Point of Contact, SPoC): все пользователи получают «одно окно» для обращений со своими вопросами к отделу ИТ. Это позволяет централизованно координировать любые отказы вместо того, чтобы постоянно загружать специалистов (которых на небольших предприятиях и так немного) незапланированной деятельностью. Однако успех концепции зависит от того, примут ли SPoC пользователи: если служба поддержки не докажет делом, что ее существование полезно, контроль происшествий не достигнет своей цели.

В рамках ориентации на услуги выигрыш от этого и других необходимых действий достигается благодаря последовательному, направленному на целевые группы маркетингу — как при планировании, так и позднее, во время эксплуатации процессов.

ПРЕИМУЩЕСТВА ОРИЕНТАЦИИ НА ITIL

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

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

Рисунок 2. Согласно стандартизованной модели действия ITIL, небольшому или среднему предприятию предстоит преодолеть шесть этапов от формирования видения до обеспечения качества.

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

  1. Разработка видения/определение целей: введение ITIL должно опираться на четкое представление о том, чего необходимо достичь. Это касается как сотрудников отдела ИТ, так и клиентов и служит мотивацией для совместной работы. После чего в соответствии с принятым видением определяются измеримые цели проекта, для которых с самого начала вводится мониторинг.
  2. Сознательное отношение: переход к работе с ITIL требует и поддержки со стороны менеджмента, и увлеченности команды ИТ. На этот аспект следует обратить особое внимание, к примеру путем мероприятий по внедрению или моделированию ITIL.
  3. Анализ фактического состояния: по причине своей ориентации на использование ранее накопленного опыта ITIL не представляет собой ничего принципиально нового. Практически в каждой организации уже используются подходы ITIL. Их необходимо рассмотреть, описать, спланировать концепцию и определить последующие шаги и необходимые меры.
  4. Планирование процесса: на основе реализуемых процессов ITIL проектная команда моделирует будущие процедуры. Особое внимание следует обратить на то, чтобы не только точно выполнить все требования, но и обоснованно применить их в небольшой или средней организации. Важнейший критерий — практичность процессов, поэтому необходимо подключить к работе тех сотрудников, кому позднее придется реализовывать процессы.
  5. Реализация методов ИТ: ITIL вводит правила, в соответствии с которыми предоставляется услуга ИТ. Разработанные процессы необходимо преобразовать в инструкции по использованию, в спецификации, описания рабочих мест и прочие документы и утвердить их для применения на предприятии. При этом предприятию не следует изменять функционирующие методы «из принципа». Наибольшую пользу принесет интеграция проверенных структур в оптимизированные процессы. Этот этап является решающим для успеха проекта.
  6. Обеспечение качества/обзор: как и в любом проекте, необходимо проанализировать полученный опыт и сохранить результаты на будущее. Для только что введенного процесса ITIL первостепенной мерой становится процедура его постоянного усовершенствования. Сюда относятся регулярное измерение эффективности процесса и принятие определенных мер по результатам анализа измерений.

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

НАИБОЛЕЕ ЧАСТЫЕ ОШИБКИ

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

Нередко предприятие концентрируется исключительно на одном или нескольких процессах. Конечно, неразумно вводить все 11 процессов одновременно, поскольку слишком большое количество параллельно вносимых изменений неизбежно затруднит текущую деятельность предприятия. Однако зависимости между процессами настолько велики, что с самого начала надо учитывать требования процессов, введение которых запланировано на более поздние сроки. Кроме того, часто во время внедрения отсутствует управление. Между тем проект не развивается сам по себе: своевременная и постоянная координация ввиду его сложности и многоплановости крайне необходима. Многие проектные команды не проводят никаких измерений для документации промежуточных достижений. Поскольку речь, как правило, идет о долгосрочных проектах, очень важно уметь продемонстрировать полученные результаты. В противном случае есть опасность того, что менеджмент в какой-то момент не захочет поддерживать проект и финансировать дальнейшую деятельность.

Если предприятие неправильно определило состав проектной команды, то возникает опасность, что в ее составе не окажется тех, кто располагает необходимыми знаниями. Часто такие сотрудники заняты в других проектах или вынуждены отвлекаться на выполнение своих повседневных обязанностей. Решающим фактором при введении ITIL являются люди, которые, однако, по своей природе стараются избегать всего незнакомого. Чтобы их переубедить, необходимы маркетинговые мероприятия, а также — что еще важнее — информация о методах и (промежуточных) результатах.

Угрозу для проекта ITIL предоставляет и недостаточная поддержка руководства: если с его стороны нет активной помощи в убеждении сотрудников, проекту не хватит настойчивости. На сложных этапах ответственному за внедрение всегда требуется определенное прикрытие «с тыла».

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

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

Лотар Буль — генеральный директор компании Masters Consulting. Дирк Зёльнер — организационный консультант компании MOD IT.

Что такое ITIL?

ITIL в качестве инфраструктурной библиотеки ИТ была разработана в конце 80-х гг. центральным компьютерным и телекоммуникационным агентством (Central Computer and Telecommunications Agency, CCTA) по заказу британского правительства. Она состоит из ряда книг, в которых наряду с управлением услугами ИТ затрагиваются такие темы, как управление эксплуатацией (ICT Infrastructure Management) и жизненный цикл разработки программного обеспечения (Application Management). С тех пор ITIL утвердилась в качестве стандарта дефакто для формирования процессов ИТ и, таким образом, представляет собой признанный подход для управления услугами ИТ с применением имеющегося опыта. Тем временем CCTA вошла в Управление государственной торговли (Office of Government Commerce, OGC), которое сегодня и является хранителем библиотеки. В этой роли OGC продолжает заботиться о дальнейшем развитии и распространении идей ITIL.

Публикация OGC для использования небольшими и средними предприятиями

Ориентируясь на потребности небольших и средних предприятий, Управление государственной торговли выпустило брошюру «Маломасштабное внедрение ITIL» (ITIL Small-Scale Implementation), где вводится понятие «жизненно необходимая ITIL» (Vital ITIL) и описываются наиболее важные процессы ITIL. К наиболее значительным этапам относятся следующие.

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

Создание центрального пункта приема запросов всех типов, касающихся ИТ. На небольших предприятиях необходимо создать центральный коммуникационный пункт (Single Point of Contact, SPoC) для любых сообщений, связанных с ИТ. Однако разные пути передачи сообщений об ошибках с одной стороны и остальных сообщений с другой (заявка на переезд, заказ нового конечного устройства и т. д.) реализовывать не стоит. Для обеспечения постоянного предоставления услуг необходимо обрабатывать все сообщения. Это позволяет добиться того, чтобы ни одно из сообщений не потерялось или не обрабатывалось с задержкой. Кроме того, в первую очередь служба технической поддержки должна обрабатывать отказы с наихудшими возможными последствиями.

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

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

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

Процессам ITIL нужны специальные инструменты

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

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

Автоматика делает процессы устранения ошибок более эффективными

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

Промежуточное решение устраняет последствие отказа, но не его причину. Устранением причины ошибки в соответствии с рекомендациями ITIL занимается управление проблемами. Но каким образом служба технической поддержки распознает проблему, если она лишена централизованного обзора случившихся отказов? Решающее значение поэтому имеет коммуникация между системами контроля происшествий и проблем. Анализу должны подвергнуться и частота возникновения ошибок, обрабатываемых системой управления проблемами. Устранить проблему можно заменой неисправного устройства или даже перестановкой компонентов ландшафта ИТ. И то и другое порождает запрос на изменение (Request for Change, RFC), а он, в свою очередь, проходит через систему контроля изменений.

Рисунок. Инструмент контроля за проблемами в соответствии с ITIL использует централизованную базу данных для определения причины проблемы.

Специальное программное обеспечение позволяет поручить параллельный поиск ошибок сразу нескольким сотрудникам, причем их деятельность и результаты могут контролироваться централизованно внутри одной системы. Менеджер проблем и сотрудник поддержки первого уровня в любой момент оказываются осведомленными о состоянии обработки. Если причина ошибки заключается, к примеру, в сетевых неполадках, то задача менеджера проблем — создать RFC. Затем запрос передается процессу контроля за изменениями.

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

Для того чтобы избежать подобных проблем, программные решения, соответствующие ITIL, поддерживают формирование RFC в виде перечня пунктов конфигурации: в соответствии с различными критериями все затронутые системы могут быть переданы в одном пакете одному RFC. Календарь планирования отображает уже проведенные изменения и предотвращает влияние RFC на элементы конфигурации, которые срочно нужны в другом месте.

Увэ Айзингер — директор по маркетингу компании Realtech.

? AWi Verlag