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

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

Технические инновации порождают инновации в сервисах

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

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

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

  • изучить весь спектр преимуществ, которые может обеспечить инструмент, например программная система управления сервисами;
  • спланировать и провести внедрение инструмента таким образом, чтобы он давал преимущества для организации в целом.

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

Связь с ITIL

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

Потребность в интеграции подобного рода повысила важность роли управления знаниями в таком широко используемом руководстве, как ITIL, свидетельством чему является ввод понятия [I]системы управления знаниями о сервисах[$] (Service Knowledge Management System, SKMS) в ITILv3. Эта система базируется на концепции конфигурационного управления — централизованных данных, на которые опирается ИТ-инфраструктура, но эта концепция поднята на такой уровень, когда обеспечивается по меньшей мере поддержка всего жизненного цикла сервиса, а в идеале — достижение корпоративных целей организации.

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

По сути, данные и информация — это всего лишь инструменты, которые помогают организациям принимать грамотные решения и конструктивные меры, поэтому, например, создание центральных репозиториев, объединяющих данные по всей организации, следует рассматривать как средство, а не самоцель. Чтобы такой репозиторий принес реальную пользу, необходимо понять, какие преимущества с его помощью можно получить, а затем разобраться, как интеграция и объединение данных и информации может помочь в обеспечении этих преимуществ. Другими словами, не надо просто отправляться за покупкой CMDB, CMS или любого другого «модного» новшества, а вместо этого необходимо задаться целью дать организации возможность решить задачи, которые она не способна решить сейчас, либо по крайней мере помочь ей справиться с нынешними задачами быстрее, дешевле или экологичнее.

Пять простых шагов

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

Все это можно свести к ряду простых шагов:

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

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

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

Новые шансы и ловушки

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

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

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

Повторение пройденного

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

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

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

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

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

***

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

Айвор Макферлейн (ivormacf@uk.ibm.com) — cпециалист по управлению сервисами IBM Tivoli. Xорошо известен в сообществе ITIL, принимал участие в разработке этой методологии с самых ее истоков. Ведет свой блог .

Ivor Macfarlane. Why People Buy Software? At Your Service, Official Magazine of the IT Service Management Forum, Vol. 1, No. 3. Все права сохранены. Перевод публикуется с разрешения ITSMf International в рамках партнерства издательства «Открытые системы» и ITSMf Russia.

1 Автор этого примера — Джон Захман, авторитетный американский консультант по бизнесу и ИТ (прим. автора).