ИТ-стратегия 2.0

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

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

Иногда даже предполагается, что такой внутренний интегратор станет источником дохода для холдинга за счет оказания услуг внешним клиентам.

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

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

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

Проблемы создания ИТ-стратегий

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

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

Действительно, в компании крайне редко имеется формализованная бизнес-стратегия, а если даже она и есть, то на практике ей не следуют. Мало того, даже единых целей у организации, как правило, не существует, поэтому результаты любых действий непредсказуемы, а вдобавок ситуация осложняется отношениями взаимодополняемости (комплементарности) между корпоративными ИТ, бизнес-процессами, компетенциями персонала и т. д. [2]. Эти отношения не позволяют сосредоточиться только на ИТ, а требуют согласованного изменения всего набора связанных практик, что немедленно выводит ИТ-менеджера за рамки его компетенции. Феноменом комплементарности объясняется также то, что процесс внедрения любой ИТ-системы фактически является процессом изобретения способов ее использования, в котором участвуют представители различных служб и различных уровней иерархии. Именно поэтому внедренная система никогда не соответствует техническому заданию, а процесс ее доработки и донастройки после формального окончания внедрения продолжается бесконечно.

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

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

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

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

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

Создание ИТ-стратегии 2.0

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

Один из наиболее популярных сегодня подходов к описанию бизнес-моделей [4] предусматривает девять структурных блоков (рис. 1).

Рис. 1. Бизнес-модель организации

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

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

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

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

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

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

Формирование программы изменений

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

Для разработки программы преобразований с учетом отношений комплементарности между ИТ-системами и другими активами можно воспользоваться матрицей изменений (рис. 2) [5]. В горизонтальной прямоугольной области 1 перечисляются существующие информационные системы, поддерживающие текущую операционную модель. В горизонтальной области 2 перечисляются текущие практики: бизнес-процессы, наблюдаемые эффекты (такие как «большое число уровней управления»), бизнес-правила (например, «сдельная оплата труда рабочих» и т. д.) — изменение которых предполагается. Область 3 служит для отображения парных отношений комплементарности между текущими практиками — если практики дополняют друг друга, ставится знак «+», если они противоречат друг другу — знак «-». На основании этого анализа выявляются множества комплементарных практик, которым будут соответствовать блоки треугольной матрицы из области 3, заполненные знаками «+». Область 4 служит для перечисления целевых ИТ-систем, а в области 5 перечисляются целевые практики с треугольной областью над ними, содержащей описания отношений комплементарности. Область 6 в центре матрицы служит для выявления взаимодействия между существующими и целевыми практиками и определения возможных трудностей перехода от одного набора практик к другому. Области 7 и 8 служат для получения обратной связи от всех заинтересованных сторон по поводу предлагаемых изменений. Необходимо определить, как различные менеджеры и владельцы предприятия относятся к сохранению текущих практик и внедрению целевых. Для каждой практики выставляется оценка по пятибалльной шкале от «+2» (практика чрезвычайно важна) до «-2» (есть сильное желание ее изменить).

Рис. 2. Матрица изменений

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

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

***

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

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

Литература

1. Юрий Зеленков. ИТ-стратегия на практике // Открытые системы. СУБД. — 2010. — № 9. — С. 42–45. URL: http://www.osp.ru/os/2010/09/13005735/ (дата обращения: 12.11.2014).
2. Юрий Зеленков. На пути к адаптивным корпоративным системам // Открытые системы. СУБД. — 2014. — № 3. — С. 17–20. URL: http://www.osp.ru/os/2014/03/13040779/ (дата обращения: 12.11.2014).
3. Зеленков Ю. А. Искусство бега по граблям. Стратегическое управление ИТ в условиях неопределенности. — М., 2013. — 139 с. URL: http://lib.rus.ec/b/459027 (дата обращения: 12.11.2014).
4. Остервальдер А., Пинье И. Построение бизнес-моделей: Настольная книга стратега и новатора. — М.: Альпина Паблишер, 2012. — 288 с. (Osterwalder, A., Pigneur, Y. Business model generation: a handbook for visionaries, game changers, and challengers. — Wiley, 2010.)
5. Brynjolfsson E., Renshaw A.A., Van Alstyne M. The Matrix of Change: A Tool for Business Process Reengineering. MIT Sloan School of Management, 1997. URL: http://ccs.mit.edu/papers/CCSWP189/CCSWP189.html (дата обращения: 12.11.2014).

Юрий Зеленков (yuri.zelenkov@gmail.com) — профессор, Ярославский государственный университет.