Сегодня сложно найти методику, формализующую перечень действий, которые должен выполнить человек, пришедший в компанию на позицию 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).

Проблемные зоны в части ИТ предлагается анализировать, основываясь на идеях стандарта CoBIT (www.cobit.org).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Комментарии: (0)   Рейтинг: