Варианты участия консультанта

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

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

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

Выделяются три роли консультанта (менеджера) согласно типам решаемых задач управления [23, С. 26-32]:

• Роли в межличностных отношениях – обеспечение взаимодействия с другими сотрудниками организации.
• Информационные роли – получение и распространение необходимой информации
• Роли в процессе принятия решений – выработка и принятие управленческих решений

В зависимости от целей консалтингового проекта и распределения ролей в клиентской организации могут быть следующие варианты участия консультанта [23]:

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

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

Табл. 3.1. Примеры участия внешнего консультанта в стратегическом процессе в области ИТ.

В следующих разделах кратко буду рассмотрены подходы к организации консалтинговых ИТ-проектов.

Типы консалтинговых проектов в области ИТ

Выделяются [14] следующие 3 типа ИТ-консалтинговых проектов:

• Стратегический консалтинг. Отвечает на вопрос «Что делать?». Например: «формирование ИТ-стратегии», «концепция ИТ-проекта».
  
• Продуктовый консалтинг. Состоит в подготовке проектов разработки и/или внедрения конкретных программных продуктов. Например: «повышение эффективности взаимоотношений с клиентами путем внедрения Microsoft CRM».
  
• Интеграционный консалтинг. Заключается в подготовке проектов внедрения интеграционных платформ и архитектур. Например: «план перехода на SOA», «концепция создания единого аналитического хранилища корпоративной информации».
  

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

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

Виды работ в рамках ИТ-консалтинговых проектов

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

По мнению автора можно выделить следующие виды работ в рамках ИТ-консалтинговых проектов:

• Бизнес-аналитика.
• Системная аналитика.
• Представление и защита концепций.
• Обучение.
• Оформление итоговых документов.

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

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

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

Обучение сотрудников компании-клиента происходит при реализации консалтинговых проектов, направленных на дифференциацию, интеграцию и усиление их компетенций (см. 3.1.).

Наконец, в результате консалтингового проекта должен быть подготовлен один или несколько документов: отчет, концепция, стратегия, техническое задание и др. Во многих случаях они должны быть оформлены в соответствии с определенными требованиями и стандартами. Например, техническое задание может оформляться в соответствии с требованиями стандартов семейства ГОСТ-34. В отчетные документы включаются результаты работ других видов (бизнес- и системной аналитики, утвержденные идеи и концепции).

Подходы к выполнению ИТ-консалтинговых проектов

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

Рис. 3.1. Основные этапы консалтингового проекта.

Опустив этап «продажи» консалтингового проекта, положим, что он начинается с момента принятия решения о начале сотрудничества между консультантом и клиентом.

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

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

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

Если концепция принята – она детализируется в рамках одного или нескольких итоговых документов, являющихся формальным результатом консалтингового проекта.

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

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

Российский рынок ИТ-консалтинга

На российском рынке ИТ-консалтинга доминируют крупные системные интеграторы.

Табл. 3.2. ТОP-10 ИТ-консультантов в России в 2008-м году.

По данным «Эксперт РА» (Табл. 3.2.) [25] в 10-ку крупнейших ИТ-консультантов России входят исключительно компании, предоставляющие также услуги по внедрению ERP-систем известных вендоров.

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

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

Поэтому доля стратегического ИТ-консалтинга в общей структуре ИТ-консалтинговых проектов, вероятнее всего, будет расти.

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

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

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

Ссылки на первоисточники:

1. The Standish Group, Inc. CHAOS Summary 2009: http://www.standishgroup.com/newsroom/chaos_2009.php
2. Аналоуи Ф. Стратегический менеджмент малых и средних предприятий: учебник для студ. вузов: пер. с англ. / Ф. Аналоуи, А. Карами. – М.: ЮНИТИ-ДАНА, 2005. – 400 с. — (Зарубежный учебник).
3. Васильев Р. Б. Материалы к лекциям по дисциплине «Разработки ИТ-стратегии» / Р. Б. Васильев – М.: ВШБИ (ГУ-ВШЭ), 2008.
   
4. http://en.wikipedia.org/wiki/McKinsey_7S_Framework
5. http://ru.wikipedia.org/wiki/Миссия_организации
6. http://en.wikipedia.org/wiki/Total_cost_of_ownership
   
7. Грант Р. М. Современный стратегический анализ / Р. М. Грант; пер. с англ. под ред. В. Н. Фунтова. – 5-е изд. – СПб.: Питер, 2008. – 560 с. – (Классика MBA).
8. Данилин А. Архитектура и стратегия. «Инь» и «Янь» информационных технологий предприятия / А. Данилин, А. Слюсаренко. – М.: Интернет-Ун-т Информ. Технологий, 2005. – 504 с.
9. Измерение результативности компании / пер. с англ. – 2-е изд. – М.: Альпина Бизнес Букс, 2007. – 220 с. – (Классика Harvard Business Review).
10. Информационные технологии в бизнесе / Под ред. М. Желены. – СПб.: Питер, 2002. – 1120 с. – (Бизнес-класс).
11. Кендалл Д. И. Современные методы управления портфелями проектов и офис управления проектами: максимизация ROI, пер. с англ. / Д. И. Кендалл, С. К. Роллинз / М.: ПМСОФТ, 2004. – 576 с.
    
12. Кузнецова Т. Целеполагание по правилам / Т. Кузнецова // Новый менеджмент. – 2007. – № 1.
    
13. Ламбен Ж. Ж. Менеджмент, ориентированный на рынок / Ламбен Жан-Жак; пер. с англ. под ред. В. Б. Колчанова. – СПб.: Питер, 2007. – 800 с. – (Классика MBA).
14. Левочкина Г. А. Материалы к лекциям по дисциплине «ИТ-консалтинг» / Г. А. Левочкина – М.: ВШБИ (ГУ-ВШЭ), 2008.
    
15. http://www.bcc.ru/press/publishing/pub04/Lipkin-IT-cons_market_in_Rus.html
16. Минцберг Г. Менеджмент: природа и структура организаций глазами гуру / Г. Минцберг; пер с англ. О. И. Медведь. – М.: Эксмо, 2009 – 464 с. – (Гуру менеджмента).
17. Портер М. Конкурентная стратегия: Методика анализа отраслей и конкурентов / М. Портер; пер. с англ. – 3-е изд. – М.: Альпина Бизнес Букс, 2007. – 453 с.
18. Портер М. Конкурентное преимущество: Как достичь высокого результата и обеспечить его устойчивость / М. Портер; пер. с англ. – 3-е изд. – М.: Альпина Бизнес Букс, 2008. – 715 с.
19. Руководство к своду знаний по управлению проектами, редакция 2000 года / М.: Институт Управления Проектами, Project Management Institue, 2004. – 238 с.
    
20. Сериков А. П. Материалы к лекциям по дисциплине «Эффективность информационных технологий» / А. П. Сериков – М.: ВШБИ (ГУ-ВШЭ), 2008.
    
21. Скрипкин К. Основные модели TVO / К. Скрипкин // Директор информационной службы. – 2005. – № 6.
    
22. Снедакер С. Управление IT-проектом, или Как стать полноценным CIO: пер. с англ. / С. Снедакер – М.: ДМК Пресс, 2009. – 616 с. – (Управление проектами).
23. Уикхэм Ф. Консалтинг в управлении проектами: пер. 2-го англ. изд. / Ф. Уикхэм. – М.: Дело и Сервис, 2006. – 368 с.
24. Учитель Ю. Г. Разработка управленческих решений / Ю. Г. Учитель. – 2-е изд. – М.: ЮНИТИ, 2008. – 383 с.
    
25. http://www.raexpert.ru/rankingtable/?table_folder=/consult/2008/tab9/

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

Можно выделить «горизонтальные» и «вертикальные» границы понятия «ИТ-стратегия».

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

Согласно одному из существующих определений, ИТ – есть совокупность аппаратного, программного и алгоритмического (интеллектуального) обеспечения, а также сеть поддержки этих компонентов [10].

К аппаратному обеспечению (Hardware) относятся компьютерное оборудование, включая разнообразные периферийные устройства, а также объединяющие их телекоммуникационные средства.

Программное обеспечение (Software) обеспечивает работоспособность аппаратного обеспечения (системное ПО) и решение прикладных задач бизнеса (прикладное ПО).

Алгоритмическое (интеллектуальное) обеспечение (Brainware, Knoware) в зависимости от намерений, ожидаемых результатов и целей, должно обосновывать целесообразность использования и развертывания аппаратного и программного обеспечения, а также его конфигурацию в каждом конкретном случае [10, С. 11-12].

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

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

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

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

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

Рис. 2.1. ИТ-стратегия и другие элементы ИТ.

На Рис. 2.1. [8] наглядно показано соотнесение ИТ-стратегии с другими понятиями ИТ. Так, ИТ-стратегия отражает направление и способы перехода от текущего к целевому состоянию архитектуры ИТ. Сам переход осуществляется посредством реализации ИТ-программ и проектов. Управление проектами представляет из себя отдельную область деятельности. Кроме того, отдельной областью в рамках ИТ является управление ИТ-активами (оборудованием и программными системами), в т.ч. их поддержка (например, упомянутая ранее процедура замены картриджей).

Содержание и структура ИТ-стратегии

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

В этих условиях мы приведем одно из возможных содержаний ИТ-стратегии (Рис. 2.2.). Так, ИТ-стратегия может содержать в себе:

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

Рис. 2.2. Структура ИТ-стратегии.

Стратегический процесс в области ИТ

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

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

1. Анализ текущей ситуации с ИТ в организации: существующих аппаратных, программных, человеческих ресурсов, степени зрелости ИТ, других элементов архитектуры предприятия.
2. Разработка ИТ-стратегии, включая определение целей для ИТ (в соответствии с критериями SMART), а также направлений, проектов, иных организационных процедур для их достижения.
3. Реализация ИТ-стратегии – выполнение намеченных проектов, осуществление запланированных организационных преобразований в «семи S».
4. Мониторинг эффективности ИТ и корректировка ИТ-стратегии. В данном случае речь может идти не только об осведомленности о реализуемых стратегических действиях, но и об анализе показателей эффективности бизнеса по результатам выполнения ИТ-проектов. ИТ-стратегия, как и любая другая стратегия, должна рассматриваться как «живой документ», представляющий из себя хранилище общей и некоторой детальной информации о планируемых, реализуемых и реализованных проектах в области ИТ. Соответственно, ИТ-стратегия для ее поддержания в актуальном состоянии должна корректироваться при принятии решений о значимых изменениях в ИТ.

Анализ текущей ситуации с ИТ в организации

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

В частности, могут быть рассмотрены следующие элементы:

1. Существующая корпоративная и бизнес-стратегия компании (в случае их наличия), видение руководством будущего своей компании, направлений развития, факторов, обеспечивающих конкурентное преимущество.
2. Требования бизнеса к ИТ в контексте основных направлений развития, оценка роли ИТ в развитии бизнеса.
3. Критерии и инструменты для оценки эффективности бизнеса и его отдельных элементов, в частности, ИТ.
4. Бизнес-архитектура предприятия – организационная структура, ключевые бизнес-процессы, основные регламенты и др.
5. Имеющиеся проблемы и ограничения в развитии бизнеса и ИТ.
6. Архитектура ИТ – архитектура информации, приложений, технологической инфраструктуры.
7. Уровень зрелости ИТ – может быть представлен в виде «матрицы согласия», по осям которой отложены факторы влияния ИТ на бизнес компании и несколько уровней зрелости. Ячейки матрицы содержат критерии достижения определенного уровня зрелости по каждому фактору. Далее определяется текущий уровень зрелости по каждому фактору и сводный индекс зрелости ИТ в целом, как средний по всем факторам.
8. Существующие инициативы и проекты по развитию ИТ.

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

Формулирование целей и задач для ИТ

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

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

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

В качестве примера инструмента, помогающего в формулировке и обосновании целей можно привести «дерево проблем, целей и задач». С помощью «дерева проблем» (Рис. 2.3.) можно декомпозировать проблемы «верхнего уровня» на обуславливающие их проблемы более низких, функциональных уровней. Дерево проблем, с одной стороны, может быть полезно в поиске причин тех или иных «глобальных» проблем. С другой стороны, дерево проблем может быть «инвертировано» в дерево целей и задач (Рис. 2.4.), отражающее пути решения указанных проблем.

Рис. 2.3. Дерево проблем.

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

Рис. 2.4. Дерево целей и задач.

Существуют подходы [8, С. 339], в рамках которых предлагается рассматривать в ИТ, вообще, и в ИТ-стратегии, в частности, две различные составляющие: внедрение новых прикладных систем (1-я составляющая) и поддержку существующей инфраструктуры (2-я составляющая). В связи с этим, может быть полезно разделить цели ИТ на цели по развитию архитектуры прикладных систем и цели по развитию операционных процессов ИТ-службы.

Итоговой набор целей для ИТ должен удовлетворять следующим требованиям:

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

Разработка ИТ-стратегии

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

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

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

• Системы управления производством (планирование выпуска и необходимых для этого ресурсов) – ERP.
• Системы корпоративного документооборота – DocFlow.
• Корпоративные хранилища данных – Data Warehouse.
• Системы управления эффективностью бизнеса – BPM.
• Системы управления цепочками поставок – SCM.
• Системы управления материально-техническими ресурсами – Inventory.
• Системы управления персоналом – HRM.
• Системы управления взаимоотношениями с потребителями – CRM.
• Системы управления финансами и бухгалтерского учета.
• Системы управления проектами.
• Другие…

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

По части определения направлений развития процессов ИТ-службы следует рассмотреть следующие «общие» возможности:

• Внедрение сервис-ориентированного взаимодействия между ИТ-службой и подразделениями основного бизнеса, включая соответствующие программные средства Service Management.
• Вынесение части функций ИТ-службы в аутсорсинг для их выполнения с лучшим соотношением цена-качество.
• Развития инфраструктуры аппаратного и программного (например, переход на SOA) обеспечения.
• Создание репозитория бизнес-процессов компании.
• Формальная регламентация деятельности ИТ-службы.
• Развития персонала.
• Выстраивание отношений с ИТ-вендорами.
• Другие…

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

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

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

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

Реализация ИТ-стратегии

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

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

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

Выделяются [22, С. 31-42] следующие 8 факторов успеха ИТ-проектов:

1. Поддержка проекта на уровне руководства компании.
2. Вовлечение пользователей в проект, начиная с самых ранних стадий для лучшего понимания их требований, с одной стороны, и завоевания их поддержки, с другой стороны.
3. Опытный руководитель проекта.
4. Четко определенные цели проекта.
5. Четко определенный объем проекта.
6. Детальное планирование с большим количеством промежуточных целей и результатов.
7. Четко регламентированный процесс управления проектом.
8. Максимально возможное использование существующих стандартов и типовых решений.

Также для эффективной работы в политическом окружении могут быть использованы следующие меры [22, С. 117-133]:

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

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

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

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

• Предотвращение.
• Уменьшение степени воздействия.
• Принятие.
• Страхование (в данном случае может выглядеть как перераспределение финансирования проектов между этапами «до» и «после» вероятной рисковой ситуации).

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

Мониторинг эффективности ИТ

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

Однако, определение и, соответственно, мониторинг эффективности ИТ – крайне непростая задача.

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

Несколько более сложно измерить «внутреннюю» эффективность ИТ как соотнесения значений показателей функционирования ИТ с затратами на поддержание этих значений. Например, стоимость обработки одного обращения пользователя в службу Service Desk, стоимость поддержки одного сервера на базе Solaris/Windows, «себестоимость» конкретного ИТ-сервиса, предоставляемого бизнес-подразделениям в модели ITSM.

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

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

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

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

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

Качественные подходы:

• Соответствие ИТ-стандартам. ИТ-стандарты, например, ITSM создаются исходя из «лучших практик» компаний-лидеров с априори высокой эффективностью использования ИТ. Поэтому, логично предположить, что в организации внедрившей у себя определенные стандартные методики ИТ более эффективны, чем в отсутствии таковых. Естественно, могут быть и исключения из этого правила. В качестве примеров подобных ИТ-стандартов можно упомянуть ITSM, MOF, COBIT, MSF.
• Уровни зрелости. Считается, что вновь созданная организация в процессе своего становления проходит через несколько уровней зрелости, каждый из которых характеризуется наличием определенных признаков. То же самое относится к развитию ИТ в организации. Уровни зрелости описываются соответствующими моделями. Наблюдая текущую ситуацию в корпоративных ИТ, можно соотнести ее с определенным уровнем зрелости. В организациях с более зрелыми ИТ они более эффективны, чем в организациях с менее зрелыми ИТ. Примеры моделей зрелости – CMM, «матрица согласия».

Количественные подходы:

• Функционально-стоимостной анализ (ФСА, ABC). Данный подход позволяет рассчитать стоимость осуществления определенного бизнес-процесса, просуммировав стоимости реализуемых в рамках него операций с учетом частот их выполнения. Далее рассчитываются стоимости процесса до и после реализации ИТ-проекта. Уменьшение стоимости автоматизируемого бизнес-процесса за счет внедрения ИТ, соотнесенное со стоимостью самого ИТ-проекта представляет из себя эффективность ИТ в данном случае [9].
• Расчет возврата от инвестиций (ROI). Считаются доходы, которые предполагается получить от реализации ИТ-проекта и соотносятся с расходами на него (инвестициями) в виде дисконтированного денежного потока и рассчитывается соотношение доходы/инвестиции. Однако, в большинстве случаев ИТ-проект является лишь частью более общего бизнес-проекта и выделить в рамках общего дохода от бизнес-проекта долю ИТ-проекта можно лишь очень грубо и умозрительно [11].
• Расчет совокупной стоимости владения (TCO). Полезен для отслеживания динамики «внутренней» эффективности ИТ-инфраструктуры и процессов, а также сравнения конкурирующих ИТ-решений. Состоит в расчете и суммировании абсолютно всех расходов (прямых и косвенных), связанных с владением определенной системой или технологией [6].
• Расчет индекса ценности возможностей для бизнеса (TVO). Суть подхода состоит в создании модели, устанавливающей связь между используемым в компании набором показателей эффективности бизнеса и набором показателей результативности ИТ. Далее для конкретного ИТ-проекта с известными целевыми значениями результативности ИТ (обычно относительно несложно оцениваются) рассчитываются целевые значения показателей бизнеса. Это соотносится со стоимостью реализации и дальнейшего владения решением и определяется некоторый индекс, отражающий перспективности инвестиций в данный ИТ-проект [21].

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

ИТ-стратегия как «живой документ»

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

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

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

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

Субъекты стратегического процесса в области ИТ в коммерческой организации

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

Табл. 2.1. Субъекты стратегического процесса в области ИТ.

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

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

Ссылки на первоисточники:

1. The Standish Group, Inc. CHAOS Summary 2009: http://www.standishgroup.com/newsroom/chaos_2009.php
2. Аналоуи Ф. Стратегический менеджмент малых и средних предприятий: учебник для студ. вузов: пер. с англ. / Ф. Аналоуи, А. Карами. – М.: ЮНИТИ-ДАНА, 2005. – 400 с. — (Зарубежный учебник).
3. Васильев Р. Б. Материалы к лекциям по дисциплине «Разработки ИТ-стратегии» / Р. Б. Васильев – М.: ВШБИ (ГУ-ВШЭ), 2008.
   
4. http://en.wikipedia.org/wiki/McKinsey_7S_Framework
5. http://ru.wikipedia.org/wiki/Миссия_организации
6. http://en.wikipedia.org/wiki/Total_cost_of_ownership
   
7. Грант Р. М. Современный стратегический анализ / Р. М. Грант; пер. с англ. под ред. В. Н. Фунтова. – 5-е изд. – СПб.: Питер, 2008. – 560 с. – (Классика MBA).
8. Данилин А. Архитектура и стратегия. «Инь» и «Янь» информационных технологий предприятия / А. Данилин, А. Слюсаренко. – М.: Интернет-Ун-т Информ. Технологий, 2005. – 504 с.
9. Измерение результативности компании / пер. с англ. – 2-е изд. – М.: Альпина Бизнес Букс, 2007. – 220 с. – (Классика Harvard Business Review).
10. Информационные технологии в бизнесе / Под ред. М. Желены. – СПб.: Питер, 2002. – 1120 с. – (Бизнес-класс).
11. Кендалл Д. И. Современные методы управления портфелями проектов и офис управления проектами: максимизация ROI, пер. с англ. / Д. И. Кендалл, С. К. Роллинз / М.: ПМСОФТ, 2004. – 576 с.
    
12. Кузнецова Т. Целеполагание по правилам / Т. Кузнецова // Новый менеджмент. – 2007. – № 1.
    
13. Ламбен Ж. Ж. Менеджмент, ориентированный на рынок / Ламбен Жан-Жак; пер. с англ. под ред. В. Б. Колчанова. – СПб.: Питер, 2007. – 800 с. – (Классика MBA).
14. Левочкина Г. А. Материалы к лекциям по дисциплине «ИТ-консалтинг» / Г. А. Левочкина – М.: ВШБИ (ГУ-ВШЭ), 2008.
    
15. http://www.bcc.ru/press/publishing/pub04/Lipkin-IT-cons_market_in_Rus.html
16. Минцберг Г. Менеджмент: природа и структура организаций глазами гуру / Г. Минцберг; пер с англ. О. И. Медведь. – М.: Эксмо, 2009 – 464 с. – (Гуру менеджмента).
17. Портер М. Конкурентная стратегия: Методика анализа отраслей и конкурентов / М. Портер; пер. с англ. – 3-е изд. – М.: Альпина Бизнес Букс, 2007. – 453 с.
18. Портер М. Конкурентное преимущество: Как достичь высокого результата и обеспечить его устойчивость / М. Портер; пер. с англ. – 3-е изд. – М.: Альпина Бизнес Букс, 2008. – 715 с.
19. Руководство к своду знаний по управлению проектами, редакция 2000 года / М.: Институт Управления Проектами, Project Management Institue, 2004. – 238 с.
    
20. Сериков А. П. Материалы к лекциям по дисциплине «Эффективность информационных технологий» / А. П. Сериков – М.: ВШБИ (ГУ-ВШЭ), 2008.
    
21. Скрипкин К. Основные модели TVO / К. Скрипкин // Директор информационной службы. – 2005. – № 6.
    
22. Снедакер С. Управление IT-проектом, или Как стать полноценным CIO: пер. с англ. / С. Снедакер – М.: ДМК Пресс, 2009. – 616 с. – (Управление проектами).
23. Уикхэм Ф. Консалтинг в управлении проектами: пер. 2-го англ. изд. / Ф. Уикхэм. – М.: Дело и Сервис, 2006. – 368 с.
24. Учитель Ю. Г. Разработка управленческих решений / Ю. Г. Учитель. – 2-е изд. – М.: ЮНИТИ, 2008. – 383 с.
    
25. http://www.raexpert.ru/rankingtable/?table_folder=/consult/2008/tab9/

В бизнесе многих организаций ИТ используются неэффективно или недостаточно эффективно. Так, по результатам ежегодного исследования «СHAOS Summary 2009» компании The Standish Group Internation, Inc. лишь 32% ИТ-проектов завершились в срок, в рамках выделенного бюджета и с требуемой функциональностью, 44% ИТ-проектов превысили, как минимум один из этих показателей и 24% ИТ-проектов не были завершены вовсе [1].

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

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

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

Исходя из этого, в этой работе:

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

Эти темы будут последовательно раскрыты в предлагаемой подборке из трех статей, посвященных ИТ-стратегии:

1. Общий стратегический процесс в коммерческой организации.
2. Стратегический процесс в области ИТ как часть общего процесса.
3. Консалтинг в области стратегического управления ИТ.

Общий стратегический процесс в организации

Понятия стратегии, стратегического менеджмента и стратегического процесса

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

Наиболее общим является понимание стратегии как набора целей компании и средств для их достижения.

Стратегия – это определение основных долгосрочных целей и задач предприятия, направлений действий и распределения ресурсов для достижения этих целей [2, С. 61].

Стратегия – это цели и средства, причем цели представляют собой намерения и задачи организации. Это то, что делает бизнес, путь, которым он следует, и решения, которые принимаются, чтобы достичь заданных пунктов и успеха [2, С. 62].

Подходы различаются степенью детализации «целей» и «средств», рассматриваемых в рамках стратегии. Так, в состав стратегии могут входить лишь «долгосрочные цели и общий набор средств, при помощи которых предприятие намеревается их достичь» [2, С. 66]. При этом детальное планирование относится не к стратегической, а к оперативной деятельности. В противоположность этому стратегия может рассматриваться как «унифицированный всеобъемлющий и интегрированный план, который соотносит стратегические преимущества компании с вызовами и возможностями ее внешней деловой среды» [2, С. 64].

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

Руководствуясь мудрым высказыванием о том, что истина обычно находится где-то посередине между противоположными точками зрения в ряде современных работ утверждается: «Если мы обозначим первое определение как «желаемую» стратегию, а второе – как «реализуемую» стратегию, это позволит нам отделить «намеренные» стратегии, в рамках которых заранее сформулированные намерения реализованы, от «эмерджентных», внезапно возникающих стратегий, в рамках которых модели, разработанные в отсутствие намерений или вопреки им, оставляют намерения нереализованными» [2, С. 65].

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

Так, в работе [2, С. 65] авторы выдвинули четыре взаимосвязанные определения стратегии: как плана, перспективы, модели и положения.

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

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

Процедуры работы со стратегией (разработка, реализация, корректировка и др.) в организации называют стратегическим процессом. А управление организацией в соответствии с выработанной стратегией – стратегическим менеджментом.

Уровни стратегии

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

• Уровень руководства корпорации
• Уровень руководства бизнес-единицы
• Уровень функционального руководства

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

Корпоративная стратегия определяет широту охвата деятельности фирмы в тех отраслях и рынках, на которых она конкурирует, т.е. чем она занимается. Бизнес-стратегия отражает то, как фирма конкурирует в данной конкретной отрасли или рынке. Если фирма процветает в данной отрасли, то она должна получить конкурентное преимущество над своими соперниками. Поэтому, эту область стратегии нередко называют «конкурентной стратегией» [7, С. 36].

Функциональная стратегия связана с такими функциональными сферами деятельности фирмы, как производственные процессы, маркетинг, финансы, человеческие ресурсы, ИТ, исследования и разработки. Это подход, используемый каждой функциональной сферой для достижения корпоративных целей и целей бизнеса усилиями каждого отдельного подразделения стратегически, путем максимизации производительности ресурсов. Важно, что функциональные стратегии согласованно формируются и управляются таким образом, что они взаимосвязаны и в то же время в совокупности позволяют должным образом реализовывать конкурентные стратегии [2, С. 75].

Очевидно, что все три уровня стратегического процесса взаимосвязаны между собой (Рис. 1.1.).

Рис. 1.1. Уровни стратегии.

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

Ниже (Табл. 1.1.) приведены основные вопросы, которые обычно затрагиваются при разработке стратегий на каждом из трех уровней.

Табл. 1.1. Вопросы стратегий различных уровней.

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

Этапы стратегического процесса

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

1. Даже хорошая стратегия, будучи единожды созданной, может быть реализована под давлением внешних непредвиденных обстоятельств совершенно иначе, чем это было описано в ней первоначально. По весьма авторитетным оценкам обычно реализуется лишь 10-30% планируемой стратегии [7, С. 38]. С точки зрения бизнеса это может быть вполне правильно, т.к. является проявлением гибкости организационного управления. Однако, с точки зрения формализации стратегического процесса из этого следует, что он не очень хорошо описывается «линейными» моделями (с определенной последовательностью этапов: анализ среды, разработка стратегии, реализация, контроль и т.п.). Наличие многочисленных «обратных связей» (в направлении от реализации к стратегии) в виде неожиданных (эмерджентных) стратегий требует взгляда на стратегию как на «живой» документ, непрерывно корректируемый при изменении условий внешней среды.
2. Стратегия, как и любой другой продукт, требующий творческого подхода, не может быть получена исключительно путем применения формального аналитического аппарата. Ключевые, действительно оригинальные и эффективные идеи являются результатом «творческого озарения» автора стратегии. А интересные мысли приходят к нам не запланировано, вне связи с календарными сроками этапа разработки стратегии. При этом, они, безусловно, должны найти отражение в том, куда движется организация.

Описанные выше сложности приводят к тому, что, по мнению Генри Минцберга, «эффективные стратегии разрабатываются довольно странным образом» [16, С. 45].

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

Так, стратегический процесс может включать в себя четыре периодически повторяющихся этапа:

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

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

Рис. 1.2. Этапы стратегического процесса.

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

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

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

Анализ текущей ситуации

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

Из этого следует, что на первом этапе формировании стратегии необходимо:

1. Сформулировать четкие, простые, понятные и согласованные друг с другом цели.
2. Глубоко понять конкурентную окружающую среду.
3. Объективно оценить собственные ресурсы.

Таким образом, необходимо проанализировать внешнюю среду компании (возможности, угрозы) и ее внутреннюю среду (цели, сильные и слабые стороны). Одним из наиболее простых и широко используемых для этого инструментов является SWOT-анализ (Strengths, Weaknesses, Opportunities, Threats) [24].

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

Рис. 1.3. SWOT-матрица первого этапа анализа.

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

Рис. 1.4. SWOT-матрица второго этапа анализа.

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

При проведении SWOT-анализа стратегические альтернативы предлагаются исходя из целей, стоящих перед организацией. Анализ целей является одной из задач анализа текущей ситуации при формировании стратегии. Цели организации формулируются исходя из целей заинтересованных в ее деятельности сторон (stakeholders). Заинтересованные стороны могут быть как внутри организации (собственники, менеджеры, сотрудники), так и вне ее (потребители, регулирующие органы, поставщики). В процессе анализа цели заинтересованных сторон, по-возможности, увязываются друг с другом с учетом степени влияния сторон, несогласуемые цели отбрасываются. В итоге получается исходный набор стратегических целей, на достижение которых должна быть направлена разрабатываемая стратегия (Рис. 1.5.).

Рис. 1.5. Пример дерева целей заинтересованных сторон.

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

Анализ отраслевой структуры (в рамках анализа внешней среды) часто используется для определения привлекательности отрасли и ключевых факторов успеха для успешной конкуренции в ней. Для этого может применяться модель «пяти сил Портера» [17], в соответствии с которой определяется сила конкуренции в отрасли по пяти возможным направлениям: конкуренция между существующими фирмами, возможности выхода на рынок новых участников, угрозы со стороны товаров-заменителей, рыночная власть поставщиков и рыночная власть покупателей. Чем выше конкуренция в отрасли, тем менее привлекательной она считается, что должно учитываться при принятии стратегических решений, относительно работы компании в ней.

Деление рынка на сегменты (группы потребителей, имеющих схожие потребности и поведенческие характеристики) позволяет оценить привлекательность отдельных сегментов и собственные конкурентные преимущества в них с тем, чтобы сформулировать соответствующие стратегические альтернативы [13, С. 268].

Также существует масса подходов, направленных на анализ внутренней среды компании. Стратегический интерес для компании представляют ресурсы, позволяющие добиваться ей устойчивых конкурентных преимуществ (компетенций). Компетенция представляет из себя положительный результат использования определенных ресурсов компании для достижения КФУ в отрасли или сегменте.

С этой точки зрения могут быть проанализированы имеющиеся у компании ресурсы. Например, по следующей схеме [7, С. 164]:

1. Идентификация главных ресурсов и способностей. Какие КФУ определяют успех фирмы в отрасли? Какие способности и ресурсы позволяют реализовать эти КФУ?
2. Оценка ресурсов и способностей по их важности (для достижения конкуретных преимуществ) и относительной силе (по сравнению с конкурентами).
3. Выработка стратегических альтернатив в отношении ресурсов. Важные сильные стороны – максимально использовать. Важные слабые стороны – развивать, вывести в аутсорсинг и др. Неиспользуемые («лишние») сильные стороны – отказаться от инвестиций в их развитие, выйти на новые рынки, требующие данных ресурсов, и др. Неиспользуемые («лишние») слабые стороны (соответствующие им ресурсы) – ликвидировать, продать и др.

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

Разработка стратегии

Стратегические альтернативы и система целей заинтересованных сторон не являются соответственно стратегическим планом и стратегическими целями, а являются лишь «сырьем» для их определения на этапе разработки стратегии.

Считается, что в состав стратегии компании должны входить следующие последовательно разрабатываемые составляющие:

• Видение.
• Миссия.
• Цели.
• Cтратегический план.

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

Видение обязательно отражает бизнес-идеи, положенные в основу деятельности организации.

Следующим элементом стратегии является миссия организации.

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

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

Обычно миссия формулируется в двух вариантах. Короткий вариант миссии представляет собой 1 — 2 коротких предложения — брэндовый слоган организации, направленный прежде всего на формирование имиджа организации в обществе. Второй — расширенный вариант миссии чаще всего формулируется для внутреннего пользования и должен подробно раскрывать все необходимые аспекты миссии, среди них:

• Цель функционирования организации.
• Область деятельности организации.
• Философия организации.
• Методы достижения поставленных целей.
• Методы взаимодействия организации с обществом.

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

Стратегические цели – это, в отличие от достаточно абстрактных видения и миссии, очень конкретные результаты, которых планирует достичь компания путем реализации стратегии. Цели должны быть качественно сформулированными. Один из самых распространённых и действенных способов — это постановка «умных» (от англ. «smart») целей, т.е. постановка целей с использованием S.M.A.R.T. критериев [12].

В соответствии с ними, цели должны быть:

• Конкретными (Specific).
• Измеримыми (Measurable).
• Достижимыми (Achivable).
• Ориентированными на результат (Result-oriented).
• Соотносимыми с определенным сроком (Timed).

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

Измеримые цели (M) — если у цели не будет каких-либо измеримых параметров, то будет невозможно определить, достигнут ли результат.

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

Ориентированные на результат цели (R) — цели должны характеризоваться исходя из результата, а не процесса (проделываемой работы).

Цели, соотносимые с конкретным сроком (T) — любая цель должна быть достигнута в определённом временном интервале.

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

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

Другими словами, на первом этапе определяется «в принципе» за счет чего фирма будет добиваться преимущества перед конкурентами. Считается, что у фирмы есть всего три способа сделать это. Эти способы называются «базовыми стратегиями» [17, С. 72-86]:

1. Абсолютное лидерство в издержках.
2. Дифференциация.
3. Фокусирование.

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

Стратегия дифференциации – создание такого продукта или услуги, которая воспринималась бы в рамках всей отрасли как уникальная. Дифференциация может осуществляться в разнообразных формах: по престижу (автомобили «Mercedes»), по технологии (компьютеры «Apple»), по функциональным возможностям (шампунь «Три-в-одном»), по обслуживанию потребителей (сервис «Альфа-Банка»), по дилерской сети (программное обеспечение «1С») или по другим параметрам.

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

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

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

Указанные выше решения принимаются на уровне разработки конкурентной (бизнес-) стратегии (см. 1.2.). На уровне корпоративной стратегии рассматриваются иные стратегические направления, которые, фактически, являются направлениями роста фирмы [2, С. 180-191]:

• Специализация и диверсификация – будет ли фирма заниматься бизнесом в одной отрасли (специализироваться) или станет многопрофильным холдингом (диверсифицироваться). Рост за счет открытия новых направлений деятельности [18, С. 509-515].
• Интернационализация – будет ли фирма работать на одном или нескольких зарубежных рынках, будет ли ее предложение в большей степени ориентировано на внутренний или внешний спрос. Рост за счет выхода на новые региональные рынки.
• Вертикальная интеграция – приобретения контроля над дополнительными областями деятельности в рамках цепочки создания ценности. Рост за счет включения в свой состав смежных областей, например, создание производителем собственной дилерской сети (интеграция «вперед») и/или собственных ресурсов по производству комплектующих для своей продукции (интеграция «назад»).

После того как основополагающие принципы определены на всех уровнях составляется стратегический план.

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

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

Реализация стратегии

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

Тем не менее, существует модели, позволяющие лучше определить с какими элементами организации предстоит работать при реализации стратегии. Одна из наиболее распространенных моделей для этого – схема «семи S» консалтинговой компании McKinsey & Co [4]:

1. Стратегия (Strategy). Собственно реализуемая стратегия.
2. Структура (Structure). Разработка уместной организационной структуры и приведение ее в соответствие с требованиями стратегии считается фундаментальной задачей при реализации стратегии.
3. Системы (Systems). Совокупность всех установленных в организации формальных и неформальных процедур, обеспечивающих ее работу. Очевидно, что определенные стратегические решения требуют изменения существующих систем.
4. Стиль (Style). Стиль действий высшего руководства компании также должен соответствовать стратегическим направлениям развития.
5. Персонал (Staff).
6. Знания и умения (Skills). Совокупность знаний и умений сотрудников компании, которые обеспечивают в рамках ежедневной оперативной деятельности устойчивые конкурентные преимущества компании. При реализации стратегии может потребоваться добавить в свой портфель компетенций новые знания и умения.
7. Общие ценности (Shared values) – организационная культура, которая, как и стиль поведения высшего руководства, должна соответствовать стратегическим целям компании.

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

Стратегический контроль и корректировка стратегии

Задача контроля и оценки деятельности компании является одной из основных задач менеджеров. Однако, это более общее понятие, чем понятие «стратегического контроля». Считается, что стратегический контроль – это осведомленность руководства обо всех стратегиях, реализуемых в пределах подразделений. Таким образом, стратегический контроль сосредоточен на содержании стратегических действий, предпринимаемых для обеспечения желаемого, заранее намеченного результата. Иначе говоря, стратегический контроль представляет собой отслеживание хода реализации стратегий, выявлении проблем или изменений исходных условий (предпосылок, на которых была построена стратегия), осуществление необходимых корректировок стратегий [2, С. 293-294].

Существует четыре типа стратегического контроля:

• Стратегическое наблюдение.
• Контроль исходных условий.
• Контроль хода реализации стратегии.
• Контроль непредвиденных обстоятельств.

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

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

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

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

К контролю непредвиденных обстоятельств прибегают в том случае, если произошли неожиданные события. Если фирма внезапно сталкивается с непредвиденными обстоятельствами, которые могут оказать решающее влияние на ее деятельность, ей следует немедленно пересмотреть свою стратегию. Этот вид стратегического контроля позволяет вовремя переоценить и пересмотреть как стратегию фирмы, так и ее текущее положение, в которое ее поставили непредвиденные обстоятельства [2, С. 299].

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

Место ИТ-стратегии в общем стратегическом процессе

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

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

В следующей статье мы подробно рассмотрим стратегический процесс в области ИТ.

Ссылки на первоисточники:

1. The Standish Group, Inc. CHAOS Summary 2009: http://www.standishgroup.com/newsroom/chaos_2009.php
2. Аналоуи Ф. Стратегический менеджмент малых и средних предприятий: учебник для студ. вузов: пер. с англ. / Ф. Аналоуи, А. Карами. – М.: ЮНИТИ-ДАНА, 2005. – 400 с. — (Зарубежный учебник).
3. Васильев Р. Б. Материалы к лекциям по дисциплине «Разработки ИТ-стратегии» / Р. Б. Васильев – М.: ВШБИ (ГУ-ВШЭ), 2008.
   
4. http://en.wikipedia.org/wiki/McKinsey_7S_Framework
5. http://ru.wikipedia.org/wiki/Миссия_организации
6. http://en.wikipedia.org/wiki/Total_cost_of_ownership
   
7. Грант Р. М. Современный стратегический анализ / Р. М. Грант; пер. с англ. под ред. В. Н. Фунтова. – 5-е изд. – СПб.: Питер, 2008. – 560 с. – (Классика MBA).
8. Данилин А. Архитектура и стратегия. «Инь» и «Янь» информационных технологий предприятия / А. Данилин, А. Слюсаренко. – М.: Интернет-Ун-т Информ. Технологий, 2005. – 504 с.
9. Измерение результативности компании / пер. с англ. – 2-е изд. – М.: Альпина Бизнес Букс, 2007. – 220 с. – (Классика Harvard Business Review).
10. Информационные технологии в бизнесе / Под ред. М. Желены. – СПб.: Питер, 2002. – 1120 с. – (Бизнес-класс).
11. Кендалл Д. И. Современные методы управления портфелями проектов и офис управления проектами: максимизация ROI, пер. с англ. / Д. И. Кендалл, С. К. Роллинз / М.: ПМСОФТ, 2004. – 576 с.
    
12. Кузнецова Т. Целеполагание по правилам / Т. Кузнецова // Новый менеджмент. – 2007. – № 1.
    
13. Ламбен Ж. Ж. Менеджмент, ориентированный на рынок / Ламбен Жан-Жак; пер. с англ. под ред. В. Б. Колчанова. – СПб.: Питер, 2007. – 800 с. – (Классика MBA).
14. Левочкина Г. А. Материалы к лекциям по дисциплине «ИТ-консалтинг» / Г. А. Левочкина – М.: ВШБИ (ГУ-ВШЭ), 2008.
    
15. http://www.bcc.ru/press/publishing/pub04/Lipkin-IT-cons_market_in_Rus.html
16. Минцберг Г. Менеджмент: природа и структура организаций глазами гуру / Г. Минцберг; пер с англ. О. И. Медведь. – М.: Эксмо, 2009 – 464 с. – (Гуру менеджмента).
17. Портер М. Конкурентная стратегия: Методика анализа отраслей и конкурентов / М. Портер; пер. с англ. – 3-е изд. – М.: Альпина Бизнес Букс, 2007. – 453 с.
18. Портер М. Конкурентное преимущество: Как достичь высокого результата и обеспечить его устойчивость / М. Портер; пер. с англ. – 3-е изд. – М.: Альпина Бизнес Букс, 2008. – 715 с.
19. Руководство к своду знаний по управлению проектами, редакция 2000 года / М.: Институт Управления Проектами, Project Management Institue, 2004. – 238 с.
    
20. Сериков А. П. Материалы к лекциям по дисциплине «Эффективность информационных технологий» / А. П. Сериков – М.: ВШБИ (ГУ-ВШЭ), 2008.
    
21. Скрипкин К. Основные модели TVO / К. Скрипкин // Директор информационной службы. – 2005. – № 6.
    
22. Снедакер С. Управление IT-проектом, или Как стать полноценным CIO: пер. с англ. / С. Снедакер – М.: ДМК Пресс, 2009. – 616 с. – (Управление проектами).
23. Уикхэм Ф. Консалтинг в управлении проектами: пер. 2-го англ. изд. / Ф. Уикхэм. – М.: Дело и Сервис, 2006. – 368 с.
24. Учитель Ю. Г. Разработка управленческих решений / Ю. Г. Учитель. – 2-е изд. – М.: ЮНИТИ, 2008. – 383 с.
    
25. http://www.raexpert.ru/rankingtable/?table_folder=/consult/2008/tab9/

Для начала мы опишем термин «системная интеграция», приведем различные определения. Затем рассмотрим его структуру с точки зрения видов работ, выполняемых в рамках системной интеграции: технический аспект, управленческий аспект и др. И, наконец, подробно остановимся на техническом аспекте – опишем виды, технологии системной интеграции, специализированные программные продукты.

Определение системной интеграции

Понятия «системная интеграция» и «системный интегратор» весьма емкие, под которые часто попадают виды деятельности и компании, которые не являются таковыми в классическом определении этих терминов.

Например:

• Системный интегратор <> Крупная многопрофильная ИТ-компания
  
• Системная интеграция <> Поставка и внедрение технологических решений определенного вендора (например, Cisco или Microsoft)
  
• Системная интеграция <> Комплексные проекты по созданию сетевой инфраструктуры компании (для этого существует термин «сетевая интеграция»)
  

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

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

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

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

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

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

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

Не менее сложной задачей является технико-экономическое обоснование предлагаемых вариантов создания единой КИС.

Общее определение термина «системная интеграция».

Системная интеграция – объединение отдельных компонентов (подсистем) в одну систему и гарантия того, что подсистемы функционируют совместно как единая система. В информационных технологиях системная интеграция – процесс связывание между собой различных компьютерных систем и программных приложений физически или функционально при помощи специальных техник, таких как компьютерные сети, интеграция корпоративных приложений, управление бизнес-процессами, программирование и др. [http://en.wikipedia.org/wiki/System_integration]

Интересными являются определения этого термина самими компаниями системными интеграторами [http://www.miks.ru/search/25838.html]:

• СОЗДАНИЕ комплексных решений в области информационных технологий для корпоративных заказчиков (IBM);
  
• СОЗДАНИЕ сложных, взаимоувязанных законченных систем функционирования автоматизированных бизнес-процессов предприятия или организации, интегрирующих разнородные технологии и оборудование разных производителей («Ай-Теко»);
  
• Прежде всего ТВОРЧЕСТВО. Только компания, состоящая из передовых, высокообразованных технически, творческих людей, способных быстро и четко понять потребности заказчика и предложить ему наиболее выгодный вариант решения проблемы, достойна называться интегратором. С точки зрения специалистов, под интеграцией систем понимается проектирование и разработка некой информационной системы, объединяющей в функционально полное решение программные и аппаратные средства, позволяющие заказчику добиться максимально возможного взаимодействия и эффективности различных бизнес-процессов (UAFI-T);
  
• ВЫБОР экономически оправданного, интегрированного информационно-телекоммуникационного решения для реализации конкретных задач заказчика, его комплексная реализация и сопровождение в течение жизненного цикла системы («Информационная Индустрия»);
  
• РАБОТЫ по созданию и запуску в эксплуатацию необходимых клиенту систем (ПО или программно аппаратных комплексов), формируемых, как правило, из независимо разработанных компонентов, либо включаемых в состав уже функционирующих систем (ЛАНИТ);
  
• КОМПЛЕКС РАБОТ, предоставляющих заказчику системные (взаимосвязанные и законченные) решения в части технологий, транспортной среды и оборудования, обеспечивающие эффективный бизнес-процесс оператора («Контур-М»);
  
• РАЗРАБОТКА специализированных решений, включающих поставку аппаратной платформы и разработку ПО, а также интеграцию разработанного решения с другими бизнес-приложениями заказчика (Siemens);
  
• ИНТЕГРАЦИЯ различных аппаратных и программных средств в единые подсистемы, а также разработка, производство, монтаж, поддержка и обслуживание программно-аппаратных комплексов, предназначенных для решения определенных заказчиком задач (Computer Mechanics);
  
• ИСКУССТВО И НАУКА ИНТЕГРАЦИИ процессов, функций, людей и информационных технологий, позволяющей создать IT-систему, удовлетворяющую бизнес-требованиям конкретного предприятия; это умение объединить разрозненные системы заказчика («Энвижн Груп»);
  
• ДЕЯТЕЛЬНОСТЬ по решению бизнес- и/или технических задач заказчика с привлечением информационных технологий, направленная на повышение эффективности бизнеса заказчика, где результатом является изменение информационной и/или коммуникационной систем заказчика («Открытые Технологии»);
  
• ОДНО ИЗ НАПРАВЛЕНИЙ, наиболее востребованных в IT-бизнесе, когда интегратор готов взять на себя головную боль заказчика по интеграции в единое целое всех его систем, а также по расширению его сети, т.е. работы, которые из-за нехватки специфических инженерных ресурсов заказчик не в состоянии выполнить своими силами, в необходимые сроки и с гарантированным качеством («Эквант»);
  
• СПОСОБНОСТЬ обеспечить заказчиков всеми необходимыми механизмами для эффективного управления бизнесом. Сегодня большинство клиентов приходят со своей стратегией и просят помочь ее реализовать. Какими средствами – вопрос вторичный. (IBS).
  

Виды работ при системной интеграции

Ранее было показано, что системная интеграция представляет из себя процесс создания единой информационной системы предприятия из отдельных компонентов.

«Правильная» КИС, реально решающая бизнес-задачи заказчика, может быть построена только в том случае, если системный интегратор, реализующий данный проект:

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

Достаточно крупный интеграционный проект, как правило, включает в себя следующие аспекты (уровни работ) и требует наличия следующих компетенций:

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

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

Общие подходы к интеграции систем

Интеграция систем в большинстве случаев – мера вынужденная, направленная на повышение эффективности бизнес-процессов компании, в которых используются информационные систем [http://citcity.ru/16663/]. Для того, чтобы продемонстрировать ценность интеграции информационных систем и наиболее распространенные подходы к интеграции рассмотрим последовательно несколько ситуаций.

Ситуация 1. Нет интеграции между системами

На схеме выше в компании используются три независимые информационные системы: «Складская система» (учет и анализ товародвижений на складе), «CRM-система» (учет и анализ продаж и других взаимоотношений с клиентами) и «Бухгалтерская система» (бухгалтерский учет и финансовый анализ). Между ними нет информационного обмена. Это приводит к тому, что менеджеры по продажам после выставления счетов клиентам вынуждены печатать их копии и нести в бухгалтерию. В бухгалтерии они регистрируются в бухгалтерской системе. Бухгалтерия регистрирует поступление денег на счет. Менеджеры по продажам, не имея возможность получить оплаты автоматически в CRM-систему вынуждены ежедневно осведомляться в бухгалтерии о поступлении денег от клиентов. Не лучше ситуация в работе склада. Здесь есть обширный документооборот с бухгалтерией, двойная регистрация действий (один раз в складской системе, второй раз в бухгалтерской) и менеджерами по продажам (получение от них распоряжений на отгрузку товара клиентам и информирование их о фактах отгрузки).

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

Ситуация 2. Вертикальная интеграция

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

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

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

Ситуация 3. Интеграция «многие ко многим» (звезда, спагетти)

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

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

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

Ситуация 4. Горизонтальная интеграция

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

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

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

Ситуация 5. Отсутствие необходимости в интеграции

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

Объекты и методы интеграции систем

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

Обычно, информационная система содержит в себе следующие компоненты:

• Платформа, на которой функционируют остальные компоненты системы, включающая в себя аппаратуру (железо) и системное ПО.
  
• Данные, с которыми работает система. Состоят из СУБД и баз данных.
  
• Приложения, реализующие бизнес-логику по работе с данными системой. Состоят из компонентов бизнес-логики, пользовательского интерфейса, вспомогательных компонентов (фрэймворк) и сервера приложений, который обеспечивает хранение и доступ к компонентам приложения.
  
• Бизнес-процессы, представляющие из себя сценарии работы пользователей с системой.
  

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

• Интеграция платформ
  
• Интеграция данных
  
• Интеграция приложений
  
• Интеграция бизнес-процессов
  

Рассмотрим подробнее процесс и технологии интеграции на каждом из этих уровней.

Интеграция платформ

Целями интеграции платформ являются:

• Обеспечение возможности взаимодействия между приложениями, работающими на различных программно-аппаратных платформах (например, между приложениями, работающими на серверах Windows, Solaris, Linux и др.).
  
• Обеспечение возможности работы приложений, разработанных для одной программно-аппаратной платформы, на других программно-аппаратных платформах (например, приложений Windows на платформах Linux, Solaris и др.).
  

Существует несколько подходов, направленных на достижение этих целей. В рамках каждого из подходов существуют различные технологии [http://citcity.ru/10881/]:

• Удаленный вызов процедур (RPC, CORBA, DCOM, Web-сервисы)
  
• ПО промежуточного слоя (Microsoft.Net, Java Runtime)
  
• Виртуализация
  

Технологии удаленного вызова процедур (в широком смысле под процедурой понимается некоторая функциональность приложения) позволяют опубликовать процедуру и обеспечить возможность ее вызова (передачи входящих параметров и получения выходных результатов) для приложений, работающих на других платформах. Элементами таких технологий обычно являются: общий для всех платформ язык описания интерфейсов процедур (IDL, WSDL), «адаптер» (переходник) процедуры, который транслирует внешние вызовы во внутренние и передает результаты обратно (стабы) и менеджеры, отвечающие за доставку запросов и результатов между платформами в сети (брокеры). Примерами технологий удаленного вызова процедур являются: RPC, CORBA, DCOM, Web-сервисы.

Концепция программного обеспечения промежуточного слоя (framework, среда исполнения, виртуальная машина) состоит в разработке прикладного ПО не с использованием сервисов конкретной операционной системы (например, Windows API), а с использованием сервисов ПО промежуточного слоя. Разработчиками ПО промежуточного слоя создаются ее реализации под различные операционные системы, которые транслируют вызовы соответствующих функций фрэйворка в вызовы соответствующей операционной системы. Типичным примером является технология Java Runtime Environment. Приложения, разработанные для этой технологии работают на любых программно-аппаратных платформах (Windows, Linux и др.) без каких-либо доработок самих приложений. Аналогичные возможности предоставляет среда Microsoft .Net Framework.

Интересной и современной концепцией является «виртуализация». К интеграции платформ она имеет отношение постольку, поскольку позволяет существенно упростить использования различных платформ и, соответственно, использование систем, требующих для своего функционирования наличия конкретных платформ. Если без виртуализации возможно одновременное функционирование N операционных сред на N серверов, то применение технологий виртуализации позволяет обеспечить функционирование N операционных сред на M серверов. Если N > M – это позволяет сократить расходы на аппаратное обеспечение путем его более эффективного использования. Если N < M – это простой путь увеличения производительности систем. Например, виртуализация позволяет развернуть и одновременно использовать на одном физическом сервере несколько операционных систем: Windows, Linux и др. На каждом из таких «виртуальных» серверов могут быть развернуты соответствующие системы, которые будут доступны одновременно. Примеры технологий виртуализации: Microsoft Hyper-V, Virtuozzo.

Интеграция данных

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

Подходы к интеграции данных:

• Универсальный доступ к данным
  
• Хранилища данных
  

Технологии универсального доступа к данным позволяют обеспечить единообразный доступ к данным различных СУБД. Посредником для работы с конкретной СУБД в данном случае является драйвер для соответствующей СУБД. Например, один и тот же SQL-запрос на выборку данных «SELECT * FROM TTABLE» может быть использован на выборку данных из таблицы TTABLE, хранящейся в СУБД MS SQL Server, Oracle, IBM DB2 и др. Это позволяет абстрагироваться от специфики конкретных СУБД и легко осуществлять интеграцию данных, хранящихся в различных СУБД. Наиболее распространенные технологии этого класса: ODBC, JDBC.

Концепция хранилищ данных состоит в создании корпоративного хранилища данных. Хранилище данных – база данных, хранящая в себе данные, собираемые из баз данных различных информационных систем, для целей их дальнейшего анализа. Например, может быть создано единое хранилище данных компании, в которое собрана информация из бухгалтерской, оперативной системы, внешних систем партнеров компаний. Для создания хранилищ данных используются технологии (OLAP), отличные от технологий создания оперативных БД (OLTP). В основном это делается для повышения производительности выполнения сложных аналитических запросов по многим параметрам (многомерные запросы). Подходы к созданию и наполнению хранилищ данных отражены в парадигме ETL (extraction, transformation, loading = извлечение, преобразование и загрузка). Технологии и инструментальные средства анализа больших массивов данных с целью выявления закономерностей предметной области объединяются понятием «Data Mining». Термин для совокупности технологий хранилищ данных и инструментальных средств и – «Business Intelligence».

Интеграция приложений

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

Стоит упомянуть следующие подходы к интеграции приложений:

• Интерфейсы прикладного программирования
  
• Обмен сообщениями (Корпоративная шина сервисов)
  
• Сервис-ориентированная архитектура
  
• Интеграция пользовательских интерфейсов
  

Интерфейс прикладного программирования конкретной системы представляет из себя «опубликованный» функционал этой системы, который может быть использован извне. Функционал может публиковаться в виде набора функций (пример – Windows API) или в виде объектной модели (объекты со свойствами и методами, пример – объектные модели приложений Microsoft Office) [4].

В большинстве случае интеграция нескольких систем заключается в передаче информации между ними, например, в форме запрос-ответ. Если системы функционируют в гетерогенных распределенных средах, то принципиальное значение имеет обеспечение гарантированности, безопасности, управляемости доставки информации между приложениями. Эти и другие принципы реализуются в корпоративных системах обмена сообщениями. В данном случае речь идет об обмене сообщениями между приложениями, а не людьми, как, например, в случае E-mail или ICQ. Функциональность этих систем достаточно прозрачна – прием сообщения от одного приложения, транспортировка по заданным правилам и передача этого сообщения другому приложению. При этом может производиться шифрование сообщений (для невозможности прочтения данных в процессе транспортировки), цифровая подпись (для защиты от умышленного изменения данных во время пути сообщения), настройка подписки (для отправки одного сообщения сразу нескольким приложениям), определение метаданных для сообщений (для облегчения использования сообщений со сложной структурой содержимого) и др [http://en.wikipedia.org/wiki/Enterprise_service_bus].

Сервис-ориентированная архитектура (SOA) является современной и модной парадигмой. Она является логическим продолжением концепции Web-сервисов, которая состоит в публикации функциональных блоков какого-либо приложения в виде, позволяющем получить к ним доступ другим приложением через Web. Web (протокол HTTP) в данном случае привлекателен ввиду возможности его использования и, соответственно, использования опубликованных в Web приложений на любых программно-аппаратных платформах. Web-сервис – небольшая программная надстройка над функционалом приложения, преобразующая вызовы, получаемы через Web во внутренние вызовы функций приложения и возвращающая результаты обратно. Основными идеями SOA являются [http://en.wikipedia.org/wiki/Service-oriented_architecture]:

• Публикация функционала корпоративных приложений в виде Web-сервисов. Упорядочивание опубликованных сервисов в виде каталога.
  
• Построение на основе Web-сервисов новых приложений путем их комбинации.
  

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

Например, в компании (оператор связи) существует система Service Desk (техническая поддержка абонентов) и биллинговая система (тарификация услуг). Перед компанией стоит задача сделать новую систему «Личный кабинет абонента», в которой абонент мог бы через Интернет просмотреть состояние своего счета и сообщить о неисправности. Для этого компания вместо того, чтобы создавать «Личный кабинет» с собственной базой данных, синхронизируемой с БД биллинговой системы и системы Service Desk, использует готовые Web-сервисы «Карточка абонента» (опубликованный функционал биллинговой системы) и «Создать заявку в техподдержку» (опубликованный функционал системы Service Desk). Очевидно, что вся работа по новому приложению «Личный кабинет» состоит лишь в создании Web-интерфейса пользователя на сайте компании.

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

Интеграция бизнес-процессов

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

Идеи, лежащие в основе интеграции бизнес-процессов, достаточно просты:

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

Некоторые примеры интегрирующего ПО рассмотрены ниже.

Программные продукты для интеграции систем

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

Можно выделить следующие классы продуктов для интеграции систем:

• Реализующие идеологию SOA
  
• Реализующие идеологию Messaging (промежуточное ПО)
  
• Корпоративные шины сервисов
  
• Средства интеграции на уровне бизнес-процессов (BPEL, Business Process Execution Language)
  
• Средства интеграции данных
  
• Прочие…
  

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

Microsoft BizTalk Server

BizTalk Server представляет собой программный продукт для интеграции приложений и бизнес-процессов. На схеме ниже показана архитектура BizTalk Server, основанная на идеологии обмена сообщениями между приложениями.

Центральной частью системы является механизм обмена сообщениями (Engine), который состоит из двух частей:

• Messaging – транспортный уровень (прием, хранение и отправка сообщений между приложениями), подключение к обмену различных систем, функционирующих на различных платформах, использование учетных записей для подключения к системам и др.
  
• Orchestration – правила (логика) обработки сообщений. Например, при помощи визуального дизайнера можно определить алгоритм, в соответствии с которым, получив сообщение от POS-терминала о продаже конкретному клиенту необходимо создать сообщение для CRM-системы и бухгалтерской системы с целью дальнейшей обработки факта продажи.
  

«Надстройки» над BizTalk Server Engine (Business Activity Monitoring и Services) предоставляют возможности управления бизнес-процессами в организации на основании информации, собираемой в процессе «общения» интегрированных приложений.

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

Также следует отметить, что Microsoft BizTalk Server позиционируется вендором как продукт для B2B-интеграции. Это означает, что интегрируемые бизнес-процессы и приложения не обязательно должны находиться в рамках одной компании, а могут затрагивать несколько взаимодействующих компании, например, в цепочке поставок. В этом случае каждая такая компания использует Microsoft BizTalk Server для интеграции внутренних процессов и приложений и взаимодействует с BizTalk-серверами других компаний для внешнего обмена [http://www.microsoft.com/rus/biztalk/].

Microsoft SQL Server

Общеизвестная СУБД Microsoft SQL Server является также примером платформы для интеграции данных. Функции интеграции реализуются в MS SQL Server следующими компонентами: Integration Services и Analysis Services.

Integration Services является ETL-инструментом, позволяющим [http://www.microsoft.com/sqlserver/2008/ru/ru/default.aspx]:

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

Analysis Services поддерживает процесс интеграции данных на следующих этапах, а именно [8]:

• Создание OLAP-хранилищ, в которое стекаются данные из различных источников в процессе интеграции, и хранение многомерных данных.
  
• Обеспечение доступа к OLAP-данным, выполнения многомерных запросов. Типичный пример – работа с данными при помощи Pivot Table.
  
• Интеллектуальный автоматизированный анализ данных (Data Mining). Простейший пример – имея таблицу с данными наблюдений за пациентами со следующими полями: диагноз, симптом 1 (температура), симптом 2 (головная боль), … существует возможность построить «дерево решений», при помощи которого врач по наблюдаемым симптомам у больного сможет с определенной вероятностью поставить ему диагноз.
  

Oracle SOA Suite

Данный продукт от Oracle похож по своей функциональности на BizTalk сервер от Microsoft. Он разработан на технологиях Java, поэтому может работать на различных платформах (Windows, Solaris, HP-UX, Linux).

Также, в отличие от BizTalk Server Oracle SOA Suite представляет из себя не один программный продукт, а набор относительно программных компонентов, некоторые из которых могут использоваться по отдельности [http://www.oracle.com/global/ru/ip/10g/as/bpel.html]:

• Oracle BPEL Process Manager – средство создания (при помощи визуального дизайнера), «хостинга» и управления бизнес-процессами, включающими в себя взаимодействие между людьми и интегрируемыми ИТ-приложениями.
  
• Oracle Business Activity Monitoring – панель управления (dashboard) интегрированными бизнес-процесами. Позволяет просматривать различные показатели бизнес-процессов (например, KPI), сервисов и их компонентов в «одном окне».
  
• Oracle Business Rules – средство описания бизнес-правил и политик, используемых в интегрированных бизнес-процессах.
  
• Oracle Service Bus – «транспортный уровень», корпоративная шина сервисов (ESB), обеспечивает взаимодействия между различными приложениями в организации.
  
• Oracle Web Services Manager – инструмент централизованного доступа к вэб-сервисам, существующим в организации, обеспечивающий создание учетных записей и политик для приложений, использующих администруемые вэб-сервисы.
  
• Oracle JDeveloper – среда разработки на Java от Oracle.
  
• Connectivity – набор адаптеров (более 300) для подключения к различным программным продуктам и технологиям, используемым в организации.
  

Oracle SOA Suite входит в состав продуктов middleware, для которых вендор использует обобщающее название Oracle Fusion.

IBM WebSphere

IBM WebSphere – это middleware от IBM, аналог Oracle Fusion. В составе IBM WebSphere есть продукты, обеспечивающие интеграцию систем в парадигме SOA (по аналогии с Oracle SOA Suite). Состав и функционал продуктов похож на аналогичное ПО других вендоров [http://www.ibm.com/products/ru/ru/]:

• WebSphere Business Modeler – средство визуального описания интегрирующих бизнес-процессов.
  
• WebSphere Process Server – хостинг и исполнение бизнес-процессов.
  
• WebSphere Integration Developer – среда разработки сервисных компонентов.
  
• WebSphere Business Monitor – инструмент мониторинга бизнес-процессов
  
• WebSphere Enterprise Service Bus – система, обеспечивающая взаимодействие между сервисами, реализованным в компании в рамках SOA.
  
• WebSphere MQ – система обмена сообщениями между приложениями, в т.ч. в рамках SOA.
  
• Другие продукты…