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

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

подход к разработке ИТ стратегии

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

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

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

Компонентная модель бизнеса

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

Ожидания руководителей от ИТ в разрезе компонент бизнеса

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

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

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

Степень значимости бизнес компонент

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

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

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

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

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

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

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

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

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

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

Модель взаимодействия систем

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

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

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

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