Новый ИТ-директор: методика выявления проблемных зон компании с точки зрения CIO

Владимир Алёшин
Консультант, системный аналитик, проектировщик баз данных и прикладных систем в области систем автоматизации. С 1985 года руководитель проектов в области управленческого консалтинга, ИТ-консалтинга и разработки систем автоматизации различного назначения. С 2004 года наряду с основной работой является профессором Школы ИТ-менеджмента Академии народного хозяйства при Правительстве РФ.

Анатолий Каращук
ИT-директор компании Golder Electronics, входящей в международный холдинг Vitek International. Окончил Московский государственный университет им. М.В. Ломоносова (специальность — физика), а также Академию народного хозяйства при Правительстве РФ (MBA — специализация CIO) в 2006 году.

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

Обзор литературы показывает, что проблема вхождения в должность CIO затрагивается не так часто. Например, в работе [1] даются рекомендации на период от трёх до шести месяцев. Однако российская специфика такова, что вряд ли новому CIO дадут больше месяца на адаптацию. В этой связи в данной статье вхождение в должность рассматривается как проект, который необходимо выполнить силами одного человека (CIO) за 80 часов. Мы исходим из того, что новый CIO не может весь рабочий день посвятить исключительно знакомству с новой компанией; параллельно ему придется решать и оперативные задачи. Именно поэтому из месячного ресурса времени в 160 часов (20 рабочих дней) берется половина. Качество этого проекта определяется исключительно знаниями, опытом и квалификацией специалиста, вступающего в должность CIO (уровнем его зрелости).

Внимание к бизнесу

Еще в XVII веке Рене Декарт говорил: «Определите значения слов, и вы избавите человечество от половины его заблуждений». К сожалению, ситуация с неточностью и неоднозначностью в понимании значений не только слов, но и важных понятий в целом не изменилась и сегодня. К таковым относятся понятия ИТ-директор и CIO — продолжается путаница при их использовании. Наиболее яркой иллюстрацией этого является выход в 2005—2006 годах двух работ [1, 2], в одной из которых (хотя и там и там речь идет именно о CIO) предложен перевод CIO Wisdom как просвещенный ИТ-директор. В данной статье мы будем исходить из того, что разница между ИТ-директором и CIO заключается в том, что первый действует в интересах своей службы, а второй — в стратегических интересах всей компании. Именно этим и объясняется тот перечень действий, который с нашей точки зрения должен выполнить CIO при выявлении проблемных зон компании.

Исходя из сказанного выше в сферу интересов CIO входят не только и не столько программно-аппаратные средства, но весь бизнес в целом. Другими словами, CIO при вхождении в должность должен посмотреть и оценить состояние компании в нескольких аспектах:

• с точки зрения топ-менеджеров компании предметом его интереса должны являться видение, миссия, стратегия, цели, задачи, основные направления деятельности компании, её бизнес-среда и уровень зрелости, основные бизнес-процессы и т. д.;
• с точки зрения CIO как специалиста по ИТ предметом его рассмотрения должны выступать архитектура ИТ (инфраструктура, сети, приложения, организация ИТ-службы), уровень их зрелости.

Логика и этапы работ

Чтобы пояснить логику организации работы и взаимосвязи между отдель-ными их этапами, используем функциональную модель (стандарт IDEF0) «Выявление проблемных зон компании», построенную с точки зрения CIO (см. рисунок). При чтении модели необходимо исходить из следующей трактовки каждого её блока: вход (I) при наличии управления (C) преобразуется в выход (O) с помощью (M) механизма (исполнителя) [3]. Поскольку в нашей модели большинство входов одновременно является и управляющими воздействиями, в соответствии со стандартом IDEF0 мы показываем их только как управление.

Выявление проблемных зон компании (O2) и формирование ранжированного плана дальнейших действий (O1) выполняются CIO в результате реализации четырех функ-ций (блоки 1 — 4): управление деятельностью, изучение и оценка бизнеса, изучение и оценка ИТ, выявление и оценка рисков.

На основании знания и опыта (I1) CIO адаптирует методику С2 (стандарты, методики и лучшая практика) и готовит план-график проведения работ (блок «Управление деятельностью»). При выполнении этой работы CIO руководствуется С1 (документацией компании). В соответствии с планом-графиком он приступает к серии интервью с топ-менеджерами компании (механизм СЧО в блоках «Изучение и оценка бизнеса», «Изучение и оценка ИТ», «Выявление и оценка рисков»). В процессе этих интервью, а также взаимодействия с персоналом ИТ-службы (механизм «ИТ-персонал» в блоках «Изучение и оценка ИТ», «Выявление и оценка рисков») CIO формирует документы «Ранжированный план дальнейших действий» (O1) и «Проблемные зоны компании» (O2).

Из приведенной модели понятно, что подготовка этих документов — многоэтапная итеративная процедура. Результатами изучения и оценки бизнеса (блок «Изучение и оценка бизнеса») являются:

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

Учитывая значение будущих потребностей бизнеса для своей деятельности в компании, CIO готовит документ «Потребности бизнеса (draft)» и согласует замечания к нему с топ-менеджментом.

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

Использование модели Захманаи стандарта CoBIT

Анализ деятельности предприятия, особенно крупного, дает огромные объемы информации. Понятно, что её структурирование и систематизация станут основой успешной деятельности CIO. По нашему опыту, ключевым инструментом, позволяющим реализовать проект вхождения в должность и далее обеспечить успешную деятельность на новом месте, является моделирование, последовательное и целенаправленное построение и использование моделей в качестве инструмента передачи понимания. Речь идет о множестве моделей, описывающих бизнес в различных аспектах.

Для анализа проблемных зон компании как с точки зрения топ-менеджмента, так и с позиции вступающего в должность CIO специалиста по ИТ можно использовать единый подход. Однако учитывая дефицит времени, отводимого на осмысление проблемных зон и структурирование плана дальнейших действий, в рамках предлагаемой методики экспресс-диагностики используются два различных подхода. При анализе проблемных зон компании с точки зрения её руководства предлагается подход, базирующийся на модели архитектуры Захмана (John A. Zachman) [4]. Проблемные зоны в части ИТ предлагается анализировать, основываясь на идеях стандарта CoBIT (www.cobit.org).

В основе модели Захмана лежит идея (при описании деятельности даже очень большой организации) использования ответов на следующие простые вопросы: что? как? где? кто? когда? почему? Полученные ответы структурируются в зависимости от того, чью точку зрения они отражают. Это могут быть как бизнес-руководители (планировщик, владелец бизнеса, менеджер), так и ИТ-менеджеры (проектировщик, архитектор систем автоматизации) или разработчики систем автоматизации [3].

В рамках предлагаемой методики используются следующие уровни модели Захмана:

• сфера действий (контекст) с точки зрения планировщика;
• модель предприятия с точки зрения владельца бизнеса (менеджера);
• модель системы (речь идет о системе автоматизации) с точки зрения проектировщика (архитектора).

В рамках предлагаемой методики первые два слоя модели Захмана объединяются, матрица транспонируется, и в нее добавляются три новых аспекта:

• уровень существующей в организации поддержки ИТ;
• удовлетворенность этой поддержкой;
• критичность.

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

Таблица 1. Рабочая форма, используемая для сбора информации и её последующего анализа

Параметр	Сфера действия (контекст) и модель предприятия	Модель системы (логическая)	Уровень существующей в организации поддержки ИТ	Удовлетво-ренность поддержкой	Критичность
Функции	Карта бизнес-процессов*	Архитектура приложений, отвечающих бизнес-процессам
…	…	…
Время	Основные этапы и события	Структура обработки событий

*Карта бизнес-процессов — структурированная совокупность данных по всем бизнес-процессам компании, включающая:

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

Оценку удовлетворенности существующей поддержкой предлагается рассматривать двояко: с точки зрения участ-ников бизнес-процесса и его владельца.

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

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

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

Приоритизация работ

Любая проектная деятельность базируется на трех китах: ресурсы, время, качество. Как отмечалось выше, вхождение в должность рассматривается как проект, который необходимо выполнить силами одного человека за 80 часов. В связи с этим имеющееся в распоряжении CIO время необходимо распределить таким образом, чтобы охватить все аспекты, о которых шла речь выше. Еще раз отметим, что глубина проработки во многом определяется квалификацией и опытом CIO. Приоритеты и примерное распределение времени при составлении плана-графика (см. рисунок) показаны в табл. 2.

Таблица 2. Приоритеты рассмотрения различных аспектов деятельности компании

Деятельность	Приоритет рассмотрения	Трудозатраты, количество часов
Интервью с руководством компании (виды деятельности компании, основные* бизнес-процессы)	1	4 — 8
Изучение бизнес-среды компании	2	4 — 8
Выявление и уточнение бизнес-процессов, построение карты бизнес-процессов (draft)	1	20 — 40
Изучение архитектуры приложений	2	8 — 16

* Под основными понимаем такие бизнес-процессы, которые:

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

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

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

Результат экпресс-диагностики

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

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

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

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

***

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

1.  Лейн Д. Просвещенный ИТ-директор: лучшие примеры из практики Кремниевой долины. — М.: «Альпина Бизнес Букс», 2005. — 500 с.
2. Броадбент М., Китцис Э. CIO — новый лидер. Постановка задач и достижение целей. — М.: Компания «АйТи»; «ДМК-Пресс», 2006. — 288 с.
3. Марка Д., МакГоуэн К. Методология структурного анализа и проектирования. — М.: «МетаТехнология», 1993. — 240 с.
4. Данилин А., Слюсаренко А. Архитектура и стратегия. «Инь» и «Янь» информационных технологий предприятия. — М.: Интернет-Университет информационных технологий, 2005. — 504 с.

Новый ИТ-директор: уроки деловой игры

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

Этап 1. Сферы деятельности CIO

На первом этапе большинство участников деловой игры одинаково определили сферы деятельности CIO. Обобщенные ответы на этот вопрос примерно таковы:

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

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

Ситуация здесь действительно противоречивая: с одной стороны, понятно, что ИТ-служба не должна заниматься реструктуризацией бизнес-процессов — она не имеет для этого ни необходимой глубины компетенции, ни полномочий. Но с другой стороны, никто, кроме ИТ-директора, не в состоянии организовать работу по выявлению бизнес-процессов, проведению границ между ними, их формализации и построению карты процессов. ИТ пронизывают всё, и это положение очень выгодно для решения таких задач. Кроме того, в силу исторических причин кроме ИТ-специалистов навыками структурированного мышления и структуризации при построении различных моделей на предприятиях никто не владеет.Обсуждение этой проблемы в ходе деловой игры подсказало и пути её решения. Скорее всего оно кроется в более точном определении того, какую именно деятельность мы понимаем под оптимизацией бизнес-процессов. Если эту работу разделить на содержательную и процессную части, всё встанет на свои места. Безусловно, генератором идей в области оптимизации бизнес-процессов должны являться функциональные топ-менеджеры, здесь их заменить невозможно. А вот исполнителем и помощником по этой части может и должен быть CIO. Здесь он должен действовать как консультант, оказывающий не экспертный, а процессный консалтинг и предлагающий соответствующую методику. Это ни в коем случае не консалтинг в общепринятом виде, это методическая работа, обучение и помощь в формализации — не более того. CIO должен понимать, каким образом следует структурировать описание и карту бизнес-процессов, чтобы дальше из этих структурированных описаний получались сервисы систем автоматизации. От него требуется именно структурно-архитектурная работа, прежде всего методологическая помощь. Это ключевой момент — например, в западных компаниях за построение архитектуры отвечает исключительно CIO. И другой возможности понять бизнес для него нет.

Этап 2. Зоны первоочередного внимания CIO, вступающего в должность

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

1. Анализ текущего состояния бизнеса, включающий следующие вопросы: какая продукция и на каких рынках предлагается компанией? каковы потребности этого рынка? кто ее основные конкуренты? каковы основные бизнес-процессы? какова организационная структура компании?
2. Анализ структуры подчинения и принципов разделения власти в компании, причем как формальной, так и неформальной. Очень многие CIO наступали на одни и те же грабли — не уделяли необходимое внимание менеджеру, который вроде бы по должности занимает не очень значимое место, но в неформальной структуре власти его позиция очень высока. Так что важно с первого же дня не «вляпаться» в такую ситуацию.
3. Оценка текущего состояния ИТ-архитектуры компании.
4. Оценка системы управления ИТ-департаментов, подчинение, распределение ролей и т. д.
5. Оценка рисков. Без этого нельзя начинать какие-либо действия — нужно хотя бы в общих чертах представить, какие неприятные ситуации здесь возможны.

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

Этап 3. Объекты диагностики и структурирование информации

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

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

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

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

Константин Зимин