Разработка ИТ стратегии. Описание одного кейса из практики

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

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

Мы на тот момент согласились с тем, чтобы ИТ-стратегия разрабатывалась в классическом IBM-подходе, через построение и анализ компонентной модели инвестиционно-девелоперского бизнеса, в силу четкости и наглядности задач развития ИТ при данном подходе. Что такое компонента? Ответ на этот вопрос, обзор и оценка подхода CBM (Component Business Model) компании IBM находится здесь по ссылке. (CBM, Component Business Model™ – методика, используемая для представления деятельности компании в виде набора отдельных бизнес-компонент, распределенных по компетенциям бизнеса и уровням управления (ответственности), для анализа и идентификации возможностей улучшения и инновации.) Методика неоднозначная, и ее неоднозначность связана с субъективностью формированием компонент, экспертные оценки всегда субъективны. Компонента не равна бизнес-процессу, например, в блоке Продажи выпал достаточно важный процесс «вывод объекта на реализацию». Но такие моменты были признаны несущественными для выполнения поставленной задачи, — сформировать ИТ стратегию компании.

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

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

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

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

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

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

 

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

 

Для оценки потенциала важно знать рынок ИТ-решений в целом и иметь представление о текущем уровне автоматизации в рассматриваемой отрасли (девелопмент, строитльство), понимать уровень автоматизации конкурентов, используемые типовые решения.

Что хочется сказать… Когда идет опрос руководителей подразделений, каждый из которых отвечает за свой участок, о системе бизнеса в целом, то получается не очень выразительная картина, «игра в демократию». Суждения руководителей не всегда могут опираться на стратегические цели и задачи, могут срабатывать факторы текущей оценки ситуации, — «и так удобно работать, зачем что-то менять», или «надо поменять/автоматизировать процесс, потому что не устраивает качество текущего взаимодействия».

Приоритеты автоматизации компонент

 

 

Охват компонент системами автоматизации

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

Модель взаимодействия систем — возможно не самый удачный пример модели. На слайде Модель взаимодействия систем, критичность и частота информационного потока — довольно эфемерные факторы, воспринимались руководством как достаточно абстрактные вещи… И тем не менее, данная модель взаимодействия систем выполняет полезную и наглядную функцию для руководства, —  показать, например, что аналитическая система необходима в интересах всех заинтересованных подразделений компании, и если коммерческий департамент «узурпировал» аналитическую систему (в данном примере Qlick Sense), то этот момент провоцирует дополнительные затраты на создание другой аналитической системы, — отдельный аналитик администрирует Qlick Sense в интересах отдельного департамента (коммерческого), другая система и ресурс выделяется на поддержку в интересах других подразделений (финансы, производство и др.).

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

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

Минусы: субъективность руководителей подразделений, которые могут искренне или мнимо не понимать реальной пользы ИТ в зоне ответственности своего подразделения, слабый анализ конкурентов в используемых ИТ решений.

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