Не позволяйте ITIL-проекту развиваться в одиночестве.

Среди участников проекта должны быть представители разработчиков, проектных команд, финансисты, управленцы, поставщики и HR.

Новые процессы должны по возможности использовать имеющиеся практики и наработки. Процессы ITIL должны быть связаны с соответствующими процессами организации, например:.

• Управление бизнесом.

— Стратегия и планы бизнеса.

— Политика в области найма персонала.

— Политика и планы непрерывности бизнеса.

Не спешите использовать ITIL3. Вендоры будут настойчиво советовать вам третью версию, но научатся с ней работать они не сегодня и не завтра. Для тех организаций, которые уже «прошли уровень ITIL2», ITIL3 будет логичным продолжением; для тех, кто только начинает, эта версия может оказаться недостижимо далекой целью.

Потихоньку люди начинают понимать, насколько ITIL3 («обновление») отличается от ITIL2, насколько больше охват и как широко размахнулись авторы. Масштаб изменений впечатляет. Это всё равно что перейти с командной строки в чёрном окошке к Windows-интерфейсу с встроенным потоком работ. Работа вроде та же, но инструкция выглядит несколько иначе! Сказать, что ITIL3 - это просто дополнение, это всё равно что сказать, будто Шевроле Корвет дополнение к мотору, или что Windows - дополнение к MS-DOS. То есть ITIL2 точно можно найти где-то там глубоко внутри, но никак нельзя сказать, что это легко сделать.

Каталог услуг содержит информацию обо всех услугах, предоставляемых пользователям, а также указания на уровни этих услуг, согласованные в SLA. В главе «Каталог услуг», на стр. 40 описана четырёхуровневая модель каталога услуг. Здесь мы говорим об актуальном каталоге, то есть о каталоге в его бытовом, общепринятом значении.

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

Те, кто работают с ИТ, любят мечтать о «кольце всевластья»: реляционные базы данных, корпоративные модели данных, словари данных, хранилища, панели управления, порталы, каталоги и SOA. Идея сложить всё в одно место и по порядку выглядит чрезвычайно привлекательно, но на практике всякий раз оказывается требующей ничем не оправдываемых расходов, а результат никогда не приближается к идеалу.

Управление конфигурациями - отличная идея: давайте организуем сбор информации обо всех ИТ-объектах и их связях, а потом обеспечим удобное представление этой информации, так что сотрудники ИТ смогут отслеживать зависимости и анализировать влияние изменений и событий (в идеале - на бизнес). Место, в котором мы соберем всю эту информацию, назовем CMDB (см. «CMDB не бывает», стр. 32).

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

В результате мы сплошь и рядом начинаем с технологий, и выстраиваем всё решение вокруг системы. Это ошибка. В ИТ практически нет проблем, для решения которых технологии имеют значение.

Вообще-то все они не работают. Во всяком случае, в том качестве, в котором люди пытаются их использовать: они не решают проблемы. Установите систему, и даже окружите её процессами, всё это всё равно сломается. Возможно, не сразу, но непременно. Начинать надо с людей. Измените культуру / отношение / привычки / поведение, и помогите людям разобраться с процессами. Когда требования к процессам в вашей организации будут понятны, можно будет искать подходящую систему для автоматизации. Любая другая последовательность означает попытки внедрения инородных объектов в культуру организации и потому обречена. В модной нынче манере Скептик утверждает: «Инструменты не имеют значения».

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

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

OGC и itSMF пренебрегли такой областью как соответствие ПО ITIL. Официального определения такого соответствия не существует.

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

Особенно раздражают те производители ПО, которые вешают ярлык «ITIL» на отдельные функции (кнопки, формы) своих продуктов - в случайной связи с первоначальными значениями слов, в которых они видят соответствие. («О! Непрерывность! У нас это есть: администратор может делать резервную копию данных. Мы соответствуем!»).

Есть вендоры, которые считают, что за процессы отвечает ITIL: «Мы не проектируем процессы, потому что они есть в ITIL». Они путают процессы (описанные в ITIL) с процедурами (требующими настройки с учетом организации и системы). Лишь некоторые из вендоров догадались продавать вместе с системой процессный консалтинг, большинство же ограничивается базовым учебным курсом по ITIL, или же вообще не предоставляет никаких услуг, кроме инсталляции (и иногда - кастомизации) ПО и обучения работе с ним. Такое случается по двум причинам:.

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

Service Desk.

В теории подойдет и Excel, но на практике всем требуется средство отслеживания «заявок» инцидентов, проблем и изменений. Эти три типа должны быть отдельными объектами, а не подвидами одного объекта.

Неважно, что говорит поставщик. Система учёта заявок (инцидентов, нарядов, тикетов...) - это ещё не Service Desk, хотя система Service Desk и должна отслеживать обработку заявок.