Организация системы управления ИТ в территориально распределённом холдинге на основе международного передового опыта

Савандер И.В.
выпускник группы МВА CIO-32В
Школы IT менеджмента
РАНХиГС при Президенте РФ

Введение

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

Зачем

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

Началось всё в 2011 году, когда внезапно, стали возникать, на наш взгляд необоснованные и неадекватные ситуации претензии к работе департамента ИТ в компании. Мы считали, что работаем если не на 5 с плюсом, то уж на 4 точно. И к сожалению, доказать это топ-менеджерам компании я не мог. Методик оценки деятельности ИТ в компании не существовало. А это означало, что оценка нашей работы была субъективной, зависящей от настроения того, кто оценивал, от  взаимоотношений с ним. Это натолкнуло меня на мысль, что необходимо как то измерять нашу деятельность. На том этапе эта мысль просто отложилась в голове, но как её реализовать я не знал.

Следующим толчком стало обсуждение ИТ бюджета на очередном бюджетном комитете. Бюджет ИТ был составлен, как и обычно, в разрезе серверов и прочего железа. Я убеждал директорат компании, что если не выделить много денег на аппаратные средства, то компания впадёт в кому и разорится. Именно убеждал, поскольку доказательств у меня не было. И в какой то момент финансовый директор компании спросила меня «- Вот вы просите ..цать миллионов на железо для головного завода компании. А что мы с этого будем иметь?»  Слова о быстродействии, надёжности, объёмах хранимой информации и прочих технических тонкостях не удовлетворили руководство компании. Тут то я и осознал, что мы с ними говорим «на разных языках» и никакого диалога у нас с ними не получится. Это как разговор слепого с глухим. Это навело меня на мысль, что нам нужно перейти на другой уровень общения, где бы ИТ и бизнес понимали бы друг друга.

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

• Как нам померить деятельность ИТ?
• Как заговорить на понятном бизнесу языке?
• Как сделать нашу деятельность сонаправленной бизнесу?

и начался наш путь к коренной реорганизации деятельности департамента ИТ.

С чего начать

В начале нашего пути к «правильному» ИТ встал вопрос – с чего начать. И начали мы с политической части. Почему именно с политики? Потому, что я понимал, без поддержки высшего руководства компании этот проект не провернуть!

• Финансовый директор. Она стала нашим первым могучим союзником, поскольку в её интересах было получить прозрачность расходов на ИТ. Почему ИТ стоит компании именно столько, а не больше или не меньше? Предложив ей показать, сколько стоят услуги ИТ мы получили её политическую поддержку. И должен сказать, что своё обещание мы выполнили.
• Руководители бизнес-подразделений. После того, как они раскритиковали текущую деятельность ИТ они уже не могли возражать против каких-либо действий направленных на улучшение  нашей работы. А фраза о «измеримости качества» работы ИТ оказала на них большое впечатление. ИТ всегда было некоторым «чёрным ящиком» для наших пользователей. Свой жаргон, специфичные термины – всё это окружало ИТ некоторой «неизвестностью и тайной». Предложение дать инструмент для объективной оценки нашей деятельности в купе с обещанием работать на бизнес дало нам ещё союзников в этом проекте.
• Производственные площадки. Директора большинства заводов изначально поддержали нашу идею о наведении порядка и упорядочении деятельности. Весьма часто, подразделения заводов списывали свои неудачи на работу информационных систем.  Наиболее часто этим страдали финансисты, которые не формировали во время свои отчёты, производственники, которые не выполняли планы по отгрузке, мотивируя тем, что мол система не работала. Перспектива контроля за работой информационных систем, за работой ИТ-специалистов на местах и централизация приёма обращений могла снизить количество недоработок предприятий, что безоговорочно поддерживалось директорами, которым наиболее важен был результат работы завода а не разборки, кто виноват в невыполнении плана и непредоставлении отчётов.
• Исполнительный директор компании. Исполнительный директор компании – человек новаторского склалда. Он любит всякие «новые технологии» и прогресс. На этом мы и сыграли. Внедрение в его компании лучших мировых практик и научной организации деятельности он одобрил и поддержал.

Заручившись поддержкой руководства компании мы приступили к разработке плана действий.  Что бы  определить, что надо делать, сначала необходимо было определить где мы сейчас находимся и куда мы хотим прийти.  Чего же мы хотели? По большому счёту мы хотели, что бы пользователи были удовлетворены нашей работой а мы были удовлетворены своим местом и своей ролью в бизнесе. Для определения  точки, где мы сейчас находимся было проведено внутреннее обследование текущего состояния дел в ИТ-департаменте.

Что мы обследовали? Мы обследовали многие аспекты деятельности департамента и его специалистов. Приведу тут лишь те, которые дали нам наиболее интересные и показательные результаты.

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

Проведя обследование и оценив его результаты я был сильно удивлён, если не сказать шокирован.

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

Провести такое обследование можно в любой организации и это не займёт много времени, но оно может дать вам очень много информации для размышления!

Практические шаги

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

• Рассмотрели домен. Его польза для пользователей это та информация, которая содержится в AD. Соответственно выделили услугу – корпоративный справочник. Этот справочник содержит контактную информацию о всех сотрудниках компании и представляет ценность для пользователей.
• Система корпоративной электронной почты. Сама по себе эта система не представляет ценности для пользователей. Им всё равно как построена отказоустойчивость, на каком железе работает почтовый сервер и т.д. А вот услуга «обмен сообщениями электронной почты» уже имеет ценность для пользователей.
• Файловый сервер пользователям не важен. А вот услуга «хранение документов пользователей» весьма полезна для них.

Как описывать услуги? Тут правильным будет вопрос а зачем мы описываем услуги? В нашем случае мы описали услуги для чёткого определения их параметров, некое подобие ТЗ. Рассмотрим подробнее услугу «обмен сообщениями электронной почты». Описание этой услуги должно отвечать на многие вопросы, в том числе и на такие:

• Сколько человек будут пользоваться электронной почтой?
• Каков должен быть объём почтового ящика пользователя?
• Каков должен быть объём отправляемых и принимаемых сообщений?
• В какое время услуга должна быть доступна?
• Как долго услуга может не работать?

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

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

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

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

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

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

В свою очередь, система сетевого хранения данных зависит от других систем и компонентов системы:

Таким образом, опускаясь вниз от услуг к системам и от систем к компонентам систем и возможно к составным частям компонентов, мы отслеживаем взаимосвязь между ИТ-инфраструктурой и ИТ-услугами. Важным вопросом является глубина детализации КЕ в CMDB. Слишком глубокая детализация приводит к увеличению сложности и трудоёмкости процесса. Например, если мышь проходит как КЕ, то запрос на замену мыши уже не должен рассматриваться как запрос на обслуживание, а должен обрабатываться как запрос на изменение. Глубина детализации КЕ должна быть разумной и основываться на том, какая информация о КЕ потребуется в процессе деятельности и какие вопросы к CMDB будут ставить сотрудники ИТ-подразделений. Например вопрос об объёме оперативной памяти на сервере может быть сформулирован по разному:

• Каков суммарный объём оперативной памяти – для оценки нагрузки на сервер или его производительности.
• Сколько модулей памяти и какого типа установлено в данном сервере и сколько слотов для установки модулей памяти имеется на материнской плате – для оценки возможности модернизации.

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

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

Люди – процессы – технологии

Реорганизацию своей деятельности мы начали именно в таком порядке. Сначала люди! И те, кто непосредственно участвовал в проекте и те, кто нас поддерживал. Затем процессы. Услуги, сервисы и процессы по их обеспечению. Когда процессы, которые вам нужны выстроены тогда и только тогда приходит время обратиться к технологиям автоматизации этих процессов! Часто бывает так, что начинают не с того конца, закупают средства автоматизации ИТ-процессов, создают helpdesk и … ждут счастья, а оно не приходит. Ещё раз отмечу, что автоматизировать можно те процессы, которые существуют. Выбор средства автоматизации нужно проводить после определения и описания тех процессов, которые вы хотите автоматизировать.

Почему мы не провалили проект

Скажу несколько слов о тех факторах, которые, по моему мнению, способствовали успеху нашего проекта.

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

Результаты нашего проекта:

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

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