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

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

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

• Производительность (Продуктивность) – то, сколько мы зарабатываем при помощи процесса
• Затраты (Себестоимость) – то, сколько мы тратим на процесс
• Эффективность – соотношение Производительности и Затрат, что позволяет нам оценить «стоит ли игра свеч», а также сравнить между собой разные варианты осуществления одного и того же процесса

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

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

Какой софт может помочь нам это сделать? Например, следующий:

• Oracle Hyperion Profitability and Cost Management (семейство продуктов Oracle EPM) – стоимость одной лицензии около 3.500 долларов, время на освоение 1-2 месяца
• IBM WebSphere Business Modeler Advanced – стоимость одной лицензии около 11.500 долларов, время на освоение от 1-й недели до 1-го месяца
• ARIS Business Performance Edition – стоимость одной лицензии около 2.600 евро, время на освоение от 1-й недели до 1-го месяца
• Business Studio Enterprise (от российской компании «Современные технологии управления») – стоимость одной лицензии около 63.000 рублей, время на освоение от нескольких дней до 1-го месяца

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

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

Описание методики

Предлагаемая методика оптимизации бизнес-процесса состоит из последовательности следующих шагов:

1. Подготовка к расчетам
2. Составление модели процесса «как есть» в виде BPMN-диаграммы в Bizagi Process Modeler
3. Определение и указание примерной (средней) длительности для каждой операции процесса
4. Определение календаря рабочего времени
5. Определение и указание примерных (средних) потребностей в трудовых и материальных ресурсах для каждой операции процесса
6. Определение и указание для «развилок» процесса примерных (оценочных) вероятностей следования по каждому маршруту
7. Симуляция исполнения данного процесса с указанными параметрами в Bizagi Process Modeler статистически значимое или необходимо для расчетов число раз
8. Расчет производительности, себестоимости и эффективности процесса в варианте «как есть»
9. Мозговой штурм, разработка нескольких альтернативных вариантов процесса, настройка и симуляция их в Bizagi Process Modeler, расчет их производительности, себестоимости и эффективности
10. Сравнение, выбор оптимального варианта и внедрение оптимизированного бизнес-процесса

Ниже каждый из шагов описывается более подробно.

1. Подготовка к расчетам

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

Наша экономическая модель будет включать в себя следующие элементы:

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

Для сведения всего воедино будем использовать Excel.

На картинке выше в строках представлены параметры и показатели экономической модели, в столбцах – различные рассматриваемые сценарии, а в ячейках – значения данного параметра или показателя для данного сценария.

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

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

2. Составление модели процесса «как есть»

Для создания модели процесса запускаем Bizagi Process Modeler. По-умолчанию у нас сразу откроется новая пустая BPMN-диаграмма. Сохраним ее в файл с именем, соответствующим названию бизнес-процесса, который мы оптимизируем — «Обработка заказа в интернет-магазине».

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

• Операция – элементарная (на данном уровне абстракции) единица работы
• Поток управления – переход от одной операции к следующей
• Развилка «И» — параллельная, обозначает, что один входящий поток управления одномоментно превращается в два или более параллельных (одновременно исполняемых) исходящих потоков управления (или несколько потоков управления после «прихода на развилку» всех их превращаются в один поток)
• Развилка «ИЛИ-ИЛИ» (исключающее «ИЛИ», логическая операция «XOR») — обозначает, что один входящий поток управления в зависимости от условия на развилки превращается в один и только один из нескольких возможных исходящих потоков (или первый из нескольких возможных входящих потоков управления после «прихода на развилку» превращаются в один исходящий поток)
• Стартовое событие – обозначает «точку входа», с которой начинается процесс (может быть только одно)
• Завершающее событие — обозначает «точку выхода», на которой заканчивается процесс (может быть несколько)

Наш бизнес-процесс может быть представлен следующим образом с использованием этих шести операций.

Рисование такой схемы в Bizagi Process Modeler не представляет особых сложностей, интуитивно понятно и похоже на создание аналогичных схем в Microsoft Visio или других визуальных графических редакторах схем.

3. Определение длительности операций

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

Теперь нам необходимо задать временные и стоимостные характеристики отдельных операций процесса, на основании которых Bizagi Process Modeler посчитает нам показатели производительности и себестоимости процесса в целом.

Настройка и симуляция моделей процессов в Bizagi Process Modeler происходит в интерфейсе «Simulation View», который открывается по нажатию одноименной кнопки на Ribbon-панели «Home».

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

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

Для каждой операции мы можем задать:

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

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

4. Определение календаря рабочего времени

Настройка календарей рабочего времени производится в окне «Calendars», открывающегося по нажатию одноименной кнопки на Ribbon-панели в «Simulation View».

Для нашего случая принимаем, что наш интернет-магазин работает 7 дней в неделю с 10-00 до 20-00 (10 часов) без перерыва на обед и настраиваем соответствующий календарь.

5. Определение необходимых ресурсов для выполнения операций

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

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

Создаем ресурсы и задаем имеющиеся у нас их количества на вкладке «Availability» (в окне «Resources», которое открывается по одноименной кнопке).

Менеджер у нас работает с почасовой ставкой 300 рублей. Курьер получает деньги за каждую доставку вне зависимости от ее длительности – 200 рублей.

Задаем описанные условия использования ресурсов на вкладке «Costs».

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

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

Все вместе это позволит в дальнейшем (при симуляции) ответить на следующие вопросы:

• Хватит ли имеющихся у нас ресурсов для осуществления требуемого количества экземпляров процесса в единицу времени
• Во сколько обойдется нам привлечение ресурсов с повременной и фиксированной оплатой
• Какова будет общая себестоимость процесса

6. Определение вероятностей на «развилках»

Далее задаем оценочные вероятности того или иного варианта развития события на «развилках» — элементах модели процесса «ИЛИ-ИЛИ».

7. Симуляция процесса «как есть»

Последнее, что нам осталось настроить – это параметры запуска экземпляров процесса:

• Интервалы между заказами – исходя из 10-ти заказов в течение 10 часового рабочего дня, это 60 минут
• Общее количество запускаемых экземпляров процессов для симуляции – в сводной таблице мы рассчитываем параметры за месяц, поэтому укажем 300 (общее количество заказов за 30 дней)

Вуаля, нажимаем на кнопку «Run». Открывается новое окно симуляции и в нем нажимаем «Start».

Процесс пошел в прямом смысле этого слова!

Симулятор нам показывает в online:

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

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

В дополнении к уже перечисленным выше сведениям здесь мы можем дополнительно увидеть:

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

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

8. Расчет экономических показателей процесса

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

Что скажем? Мы «в минусах», т.е. терпим убытки (-40.875 руб. каждый месяц). Но, не все так плохо. Важно то, что маржинальность заказа (1.000 руб.) существенно больше себестоимости его обработки (520 руб.). А это значит, что мы начали заниматься оптимизацией не зря J

Также видим, что наши ресурсы большую часть времени не работают.

Выводы:

• Мало заказов
• Недозагрузка ресурсов

9. Проработка альтернативных вариантов процесса

Итак, мы увидели, что в варианте 1 (КАК ЕСТЬ) у нас элементарно мало заказов.

Что делаем? Устраиваем мозговой штурм, вырабатываем альтернативные варианты действий, создаем новые сценарии и симулируем их в Bizagi, рассчитываем их экономические показатели в соответствии описанным выше подходом.

Для создания нового сценария в Bizagi открываем окно «Manage scenarios» по ссылке в выпадающем меню кнопки «What-If Analysis». В этом окне создаем новый сценарий посредством копирования существующего.

Затем выбираем созданный сценарий по ссылке в выпадающем меню кнопки «What-If Analysis» и вносим необходимые изменения.

А теперь, собственно, альтернативы.

Вариант 2. Усиливаем рекламу

Основные идеи и допущения:

• Увеличение рекламного бюджета в 5 раз (до 50.000 руб. в месяц)
• Допускаем, что вследствие этого произойдет увеличение количества поступающих заказов в 3 раза (до 30 в день)

Изменения в сценарий:

• Интервал между процессами – 20 минут (вместо 60-ти)
• Общее количество кейсов в месяц – 900 (вместо 300)

Экономические показатели:

Что видим:

• Уменьшение убытка почти в 10 раз (до -4.390 руб. в месяц)
• Неприемлемое общее время исполнения заказа (больше 4-х дней)
• Узкое звено – курьер (среднее время ожидания доставки больше 4-х дней)

Выводы:

• Нехватка ресурса «Курьер»

Вариант 3. Привлекаем еще одного курьера

Основные идеи и допущения (дополнительно к варианту 2):

• Привлекаем еще одного курьера

Изменения в сценарий (дополнительно к варианту 2):

• Доступность ресурса «Курьер» — 2 (вместо 1)

Экономические показатели:

Что видим:

• Уменьшение общего времени исполнения заказа до приемлемого (около 1-го дня)
• Убыточность деятельности
• Высока доля отказов от заказов при получении (21,11 %) — плохой вариант, т.к. при этом терпим издержки на доставку, не получая дохода от реализации

Выводы:

• Много отказов при получении и надо с этим что-то делать

Вариант 4.1. Делаем доставку платной

Основные идеи и допущения (дополнительно к варианту 3):

• Устанавливаем стоимость доставки равной 200 рублям
• Допускаем, что это приведет к уменьшению количества заказов примерно на 20% (до 25 в день)
• На доле отказов от заказа при получении это не скажется

Изменения в сценарий (дополнительно к варианту 3):

• Интервал между процессами – 24 минуты (вместо 20-ти)
• Общее количество кейсов в месяц – 750 (вместо 900)

Экономические показатели:

Что видим:

• Увеличение чистой прибыли (до 174.755 руб. в месяц вместо чистого убытка в -4.390 руб.)
• Уменьшение общего времени исполнения заказа до отличного (4 ч. 04 мин.)
• Незначительное максимальное среднее время ожидание ресурса (18 мин.)

Выводы:

• Приемлемый вариант

Вариант 4.2. Вводим обязательную предоплату

Основные идеи и допущения (дополнительно к варианту 3):

• Вводим обязательную предоплату
• Допускаем, что это приведет к уменьшению количества заказов примерно на 30% (до 20 в день)
• Допускаем, что это уменьшит отказа покупателей от заказа при получении на (с 20% до 5%)
• Доставку оставляем бесплатной

Изменения в сценарий (дополнительно к варианту 3):

• Интервал между процессами – 30 минут (вместо 20-ти)
• Общее количество кейсов в месяц – 600 (вместо 900)
• Вероятности на развилке после доставки заказа покупателю – покупатель отказался от товара – 5% (вместо 20%), все ОК – 75% (вместо 60%), покупателя нет дома – 20% (без изменений)

Экономические показатели:

Что видим:

• Увеличение чистой прибыли (до 9.585 руб. в месяц вместо чистого убытка в -4.390 руб.)
• Уменьшение общего времени исполнения заказа до отличного (3 ч. 05 мин.)
• Незначительное максимальное среднее время ожидание ресурса (7 мин.)

Выводы:

• Приемлемый вариант
• Низкая чистая прибыль

Вариант 4.3. Делаем доставку платной и вводим обязательную предоплату

Основные идеи и допущения (дополнительно к варианту 3):

• Устанавливаем стоимость доставки равной 200 рублям
• Вводим обязательную предоплату
• Допускаем, что это уменьшит отказа покупателей от заказа при получении на (с 20% до 5%)
• Допускаем, что вкупе эти два фактора приведут к уменьшению количества заказов примерно на 60% (до 10 в день)

Изменения в сценарий (дополнительно к варианту 3):

• Интервал между процессами – 60 минут (вместо 20-ти)
• Общее количество кейсов в месяц – 300 (вместо 900)
• Вероятности на развилке после доставки заказа покупателю – покупатель отказался от товара – 5% (вместо 20%), все ОК – 75% (вместо 60%), покупателя нет дома – 20% (без изменений)

Экономические показатели:

Что видим:

• Увеличение чистой прибыли (до 151.700 руб. в месяц вместо чистого убытка в -4.390 руб.)
• Уменьшение общего времени исполнения заказа до отличного (2 ч. 52 мин.)
• Незначительное максимальное среднее время ожидание ресурса (2 мин.)

Выводы:

• Приемлемый вариант

10. Выбор и внедрение оптимизированного бизнес-процесса

Наконец, просто взглянем на все рассмотренные варианты вместе.

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

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

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

Однако, мы допустим, что нам важнее всего общий объем чистой прибыли. Поэтому, для нас оптимальный – «Вариант 4.1».

P.S.

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

Дополнительные материалы:

• Ссылка для скачивания Bizagi Modeler
• Файл Bizagi Modeler со схемой процесса и сценариями, описанными в статье
• Файл MS Excel со сводными данными

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

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

Представляя одну из таких команд, хочу поделиться своим опытом создания небольшой системы для управленческого учета внутри своей команды в формате «IT-кейса».

2. Бизнес-цели, имеющиеся проблемы и ограничения

Основные цели:

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

Ограничения:

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

3. Идеи от IT

Исходя из стоящих целей и имеющихся ограничений, рассматривались следующие альтернативные варианты:

1. Использовать какое-то готовое решение из области «общего» учета (например, на базе 1С)
2. Использовать какое-то готовое решение из области автоматизации процессов разработки (например, Redmine)
3. Сделать что-то свое

После рассмотрения «за» и «против» каждого из этих трех вариантов было принято решение остановиться на варианте «3».

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

Вариант «2» лучше подходил с точки зрения отражения специфики IT-команды, но финансово-расчетная часть функционала там либо отсутствовала, либо была недостаточно развита.

Как в случае «1», так и в случае «2» смущала также необходимость оплаты стоимости лицензий и наличие «в нагрузку» дополнительного функционала, который в обозримом будущем не требовался или уже был внедрен на базе других систем (например, работа с планами-графиками проектов из функционала Redmine уже реализована при помощи MS Project, а работа с проектными документами и внутренний портал взаимодействия при помощи Alfresco ECM).

В варианте «3» подкупала возможность сделать ровно то, что нужно сейчас и постепенно это развивать по мере расширения и изменения требований.

Что касается платформы для создания учетной системы «с нуля», то сначала я планировал сделать все в рамках внутреннего портала взаимодействия на базе Alfresco ECM, однако потом решил использовать MS Access. Access позволял сделать все несколько быстрее и, что самое главное, вносить изменения в функционал по мере необходимости практически одновременно с его использованием. Это позволяет с низкими накладными издержками отработать информационную модель и пользовательской интерфейс в реальной жизни. Потом при необходимости можно перенести уже отработанные технологические решения на более производительную платформу. С другой стороны, с учетом небольшого размера команды и, соответственно, небольших объемов обрабатываемых данных Access вполне подходит для этих целей.

4. Концепция решения

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

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

Несколько упрощенная информационная модель предлагаемого мною варианта приведена на схеме ниже.

Центральным элементом данной модели является «Проект». Проекты различаются по типам с точки зрения направленности (внутренние, внешние и пресэйлы), а также с точки зрения способа взаиморасчетов по ним (фиксированная оплата за согласованный объем работ – fixed price, оплата потраченных часов – time&material, без оплаты – некоммерческие).

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

Модель позволяет производить начисления (биллинг) для Клиентов по Проектам двумя способами в зависимости от типа договора Проекта:

• На основании фактически потраченных часов (для T&M проектов) – экземпляров сущности Трудозатраты
• На основании выставленных счетов, отражающих этапы и условия расчетов из договора (для FP проектов) – экземпляров сущности Начисление

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

Далее в рамках определенной Задачи создаются Назначения конкретным Ресурсам. Ресурс – это человек, член нашей команды. В будущем планируется также реализовать поддержку не только трудовых, но и материальных ресурсов. Каждый Ресурс имеет определенную стоимость (почасовая ставка).

Назначение представляет собой договоренность с определенным Ресурсом выполнить определенный объем работ (согласованная с Ресурсом оценка трудозатрат) во исполнение определенной Задачи. Например, по Задаче «Создание прототипа» могут быть созданы три Назначения:

• Подготовка функциональной спецификации – для аналитика Иванова
• Разработка прототипа – для программиста Петрова
• Тестирование – для тестировщика Сидорова

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

По факту выполнения Назначения руководитель проекта оценивает их качество и фиксирует в виде оценки выполнения. Эта оценка впоследствии используется при анализе эффективности Ресурсов.

Завершающими элементами бизнес-процессов и предложенной информационной модели являются платежи от Клиентов и для Ресурсов. Как и в реальной жизни, выделяются два вида платежей:

• Входящий платеж – любое поступление денежных средств в общий бюджет команды (расчетные счета, наличные), в частности, поступление по договору от Клиента
• Исходящий платеж – любой расход денежных средств из общего бюджета команды, в частности, оплата работ Ресурса

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

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

5. Задачи по реализации

Для реализации концепции, описанной выше, были выполнены следующие работы.

Итого: 40 человеко-часов.

6. Оценка затрат

Затраты на создание решения в разрезе статей расходов приведены в таблице ниже.

Итого: 48.000 рублей.

7. Оценка выгод

7.1. Прямой экономический эффект

Итого: 12.000 руб. в месяц.

7.2. Косвенные выгоды

1. Повышение прозрачности взаиморасчетов
2. Уменьшение количества ошибок в расчетах
3. Повышение качества принимаемых решений за счет появления дополнительных аналитических инструментов
4. Улучшение взаимоотношений с клиентами за счет четкой и централизованной фиксации договоренностей о плановых сроках и трудозатратах на выполнение задач
5. Улучшение взаимоотношений внутри команды за счет четкой и централизованной фиксации договоренностей о плановых сроках и трудозатратах на выполнение назначений

8. Анализ эффективности

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

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

Т.е. можно с уверенностью утверждать о высокой экономической эффективности данного решения.

Цели и задачи описания бизнес-процессов

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

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

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

Например, если целью является последующая автоматизация, то целесообразно строить модели в нотациях и средствах моделирования, рекомендуемых для тех систем, которые планируется внедрять: eEPC и ARIS для SAP ERP, BPMN и BizAgi ProcessModeler для BPM-системы BizAgi и т.п. У многих крупных разработчиков IT-решений в линейке продуктов есть и соответствующие средства для моделирования бизнес-процессов, в свою очередь многие независимые разработчики средств моделирования обеспечивают средства конвертации моделей в форматы для использования внешними информационными системами. Учет этих моментов на раннем этапе позволит на выходе достичь лучшего понимания описанных процессов участниками будущего проекта автоматизации и сэкономить время на перерисовке одних и тех же процессов в разных нотациях и/или средствах моделирования.

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

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

Бизнес-процессы описаны и что дальше?

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

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

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

Итак, начнем с начала: бизнес-процессы описаны, работа завершена J! А теперь подумаем, что можно с ними сделать дальше.

Первое. Доведем информацию о бизнес-процессах до всех их участников!

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

Второе. Дадим возможность высказаться!

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

Третье. Воспользуемся современными решениями для оптимизации бизнес-процессов!

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

Четвертое. Подумаем о внедрении BPM-системы!

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

Пятое. Не забудем о SMART!

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

Шестое. Система важнее всего!

Можно, конечно, принять это как субъективное мнение человека, обладающего системным вариантом мышления J. Однако, очевидно то, что развитие бизнес-процессов должно строиться по тем же законам, что и общее организационное развитие, поскольку является его неотъемлемой частью. А в современном менеджменте уже давно господствует системный подход, в который, тем не менее, отлично вписываются различные «иррациональные компоненты»: личная инициатива, лидерство и тому подобные понятия. Возвращаясь к описаниям бизнес-процессов, это означает то, что для развития процессов в конкретной организации необходимо разработать и формализовать новый «мета-процесс», назначить ответственных лиц, при необходимости написать должностные инструкции и «регламент совершенствования бизнес-процессов». Скелетом этого мета-процесса, как ни крути, будет являться классический цикл Деминга, который необходимо развить и приложить к особенностям предметной области, отрасли и конкретной организации. Помочь в этом могут многочисленные методологии и программные средства (например, методология «Business Process Excellence» и соответствующее ПО ARIS). Хотя, по моему скромному мнению, отличных результатов можно добиться и «подручными средствами», вполне доступными даже совсем небольшим компаниям.

Седьмое. Подумайте о привлечении консультанта!

Здесь без комментариев J. Пишите — обсудим любые удобные для Вас варианты сотрудничества!

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

В силу наличия в голове описанных выше установок, я был настроен весьма скептически, когда впервые столкнулся с BPM-системами. Обещания разработчиков систем выглядели фантастически: комплексная автоматизация целых бизнес-процессов практически без программирования и с копеечной стоимостью лицензий. Здесь и далее я привожу в качестве примера систему BizAgi BPM Suite, хотя существует целый класс подобных систем под общим названием BPMS (Business Process Management System). Сразу возникали закономерные вопросы: для чего тогда существуют ИТ-подразделения, занимающиеся внедрением и стыковкой между собой систем разных классов и вендоров? Для чего существуют команды разработчиков почти на каждом предприятии, пишущие свои собственные системы «с нуля»? Для чего пользователям приходится ежедневно работать с десятком разных приложений? Ведь можно поставить одну BPM-систему «из коробки», посадить за нее продвинутого пользователя, который настроит в ней все бизнес-процессы компании, а другие менее продвинутые пользователи будут исполнять их в этой системе в соответствии со сделанными настройками! Конечно же, тогда я не поверил в то, что это возможно и был прав, но лишь отчасти…

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

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

От общего к частному: бизнес-кейс по внедрению BPM-системы

Что за бизнес?

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

Какие есть проблемы?

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

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

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

Этим обуславливаются следующие проблемы:

1. Высокие ручные трудозатраты на ведение сводной информации по выполняемым заказам, их статусам, плановым датам отдельных операций и т.п.
2. Недостаточное качество и актуальность подобной информации. В целом, невозможно быстро и точно сказать какой заказ на какой стадии находится в данный момент, в чьей зоне ответственности и т.п.
3. Дополнительные издержки, связанные с недостаточно эффективным использованием оборудования и трудовых ресурсов.
4. Отдельные виды проблем с качеством.
5. Прочие стандартные проблемы, связанные с недостаточной автоматизацией основных бизнес-процессов и процессов управления.

Какое предложено решение?

Внедрение BPM-системы BizAgi BPM Suite, в частности:

1. Описание бизнес-процесса выполнения типового заказа (и вариаций нетиповых заказов в качестве дальнейших направлений развития).
2. Настройка данного бизнес-процесса в системе: сама схема процесса, схема данных и формы ввода данных, правила автоматического назначения исполнителей операций.
3. Интеграция с системой 1С: получение из 1С исходных параметров заказа и передача в 1С информации о текущем статусе его выполнения.
4. Интеграция с системой учета брака собственной разработки для передачи информации о браке между участниками бизнес-процесса.
5. Выполнение заказов в рамках BPM-системы, накопление статистики по фактическим параметрам выполнения заказазов.
6. Анализ и совершенствование выполнения бизнес-процессов (внесение соответствующих изменений в BPM-систему, в качестве дальнейших направлений развития).

Как это выглядит?

Описанный выше бизнес-процесс выполнения типового заказа, прорисованный в деталях в нотации BPMN, являющейся в настоящее время де-факто стандартом описания бизнес-процессов и поддерживаемой BizAgi BPM Suite:

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

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

Формы в свою очередь получают и сохраняют информацию в базе данных BPM-системы. Информационная модель данных в BizAgi BPM Suite настраивается при помощи визуального редактора в соответствии с требованиями предметной области:

Также можно увидеть как это функционирует «в живую» на моем демонстрационном стенде: demo.kholodkov.ru

Какова стоимость данного решения?

1. Стоимость лицензий BizAgi Xpress – 20 лицензий – 70.000 рублей.
2. Стоимость работ по внедрению – 150.000 рублей.
3. Стоимость оборудования (1 виртуальный сервер на платформе VMware vSphere) – 20.000 рублей.
4. Стоимость системного ПО (Microsoft Windows Web Server 2008 R2) – 20.000 рублей

Итого: 260.000 рублей.

От частного к общему: области применения BPM-систем

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

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

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

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

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

Наконец, приведем некоторые примеры отраслей и «процессов для BPM-системы» в них.

Заключение

Если Вы видите в своей организации «процессы для BPM-системы» и написанное выше для Вас интересно – предлагаю Вам рассмотреть возможность внедрения BizAgi BPM Suite. Это не потребует от Вашей организации никаких материальных затрат в том случае, если вы все же решите, что BPM-система Вам не нужна. Почему? Потому что, сотрудничая с нами, Вы платите только за результат, который Вас устраивает. Более подробную информацию Вы можете найти здесь

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

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

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

Потребность в бизнес-аналитике в организации, как правило, не ограничивается отдельными фиксированными во времени проектами повышения прозрачности, уровня регламентации и автоматизации бизнес-процессов, оптимизации. Устойчивый результат может принести ведение этой деятельности на регулярной основе в рамках классического цикла Деминга по нескольким причинам. Во-первых, жизнь не стоит на месте, изменяются сильные и слабые стороны организации, появляются новые возможности и угрозы, что требует изменений на всех уровнях. Здесь, конечно же, весьма полезными оказываются имеющиеся модели деятельности организации. Во-вторых, каждый этап оптимизации при должной оценке его результатов дает стимулы и бесценную информацию для следующих шагов, которые могут быть сделаны на этом пути. Широкое распространение получили различные подходы «класса» Business Process Management (BPM), предусматривающие непрерывное циклическое совершенствование бизнес-процессов и приведение их в соответствие с меняющимися стратегическими целями организации. В качестве примера такого комплексного подхода, включающего в себя помимо методологии еще и ПО моделирования и автоматизации бизнес-процессов (Workflow Management System), можно привести «Business Process Excellence» компании IDS-Scheer.

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

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

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

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

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

Однако, найти хорошего бизнес-аналитика действительно непросто. По многолетнему опыту автора в реализации различных ИТ-проектов не более четверти людей, занимающихся бизнес-аналитикой, обладают необходимыми знаниями, способностями и навыками для того, чтобы не просто описать некоторую организационную систему «КАК ЕСТЬ», а придумать решение «КАК УЛУЧШИТЬ». Далее, не более четверти из той четверти имеют достаточно широкий кругозор в области менеджмента для того, чтобы взрастить это решение в системе бизнес- и функциональных стратегий, существующих в организации в формальном или неформальном виде, и обосновать его перед руководством заказчика, разговаривать с ним на одном языке. Если вам удалось найти такого действительно высокопрофессионального бизнес-аналитика, то это большая удача и такой специалист способен принести отдачу для бизнеса в десятки, сотни и тысячи раз превышающую его стоимость.

Например, мы создали дома файл, который нам потребовался на работе. Он себе лежит на выключенном домашнем компьютере… Ах да, надо было записать его на флэшку. Нет, все равно не выйдет, программа для его открытия установлена только на том компьютере. Вы ходите на работу с ноутбуком? Тогда с файлом проблемы нет, а вот как быть с доступом к корпоративной базе данных? У вас настроен удаленный доступ к корпоративной сети? Отлично! Да вот беда, ваш провайдер блокирует эти порты из соображений безопасности. Ничего! Сейчас подключимся через мобильник и зайдем на сервер терминалов. Ой, к вам еще не пришел 3G? Как же все тормозит! Да вот еще как назло под рукой только коммуникатор, а срочно нужен этот файл. Вы не выложили его в Sharepoint? У вас дома нет личного вэб-сервера с настроенным доступом к файлам через WebDAV? Вообщем, в это раз вам, похоже, не повезло и к своей информации в самый нужный момент вы доступ не получите, не смотря на то, чтобы для того, чтобы мало-мальски иметь ее под рукой вам приходится использовать все 33 системы.

VPN, RDP, Web-access, FTP, Web-client, Terminal, Sharepoint, VM, portable-версия, флэшки, переносные жесткие диски – вот далеко не полный список того, что придумало человечество для того, чтобы получать доступ к своей информации и средствам работы с ней из любой компьютеризированной точки. Честно сказать, использование такого количества технологий и необходимость перекачки данных между ними не очень удобны.

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

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

Выходят элементы облачных сервисов и на массовый рынок. Простейший пример – Google.Документы, позволяющие иметь доступ к своим файлам и средствам работы с ними из любой точки интернета и с любого устройства, только лишь при наличии браузера. Аналогичный сервис обещает к концу 2011-го года запустить и Microsoft – Office 365. Однако, все это пока что лишь фрагменты идиллического «привычного рабочего стола», описанного выше.

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

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

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

Мое руководство? Оно обычно в разъездах, но при необходимости выйдет нам меня в любое время дня и ночи в любой точке моего местонахождения. Свои указания оно предпочитает отправлять электронными письмами, чтобы в случае чего мне было не отвертеться, что я чего-то не знал.

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

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

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

Я думаю, что грядет эра виртуализации офисов компаний. Виртуализация (независимость от физического местонахождения) сама по себе уже давно является одним из ведущих направлений в ИТ. Gartner уже который год включает ее в свой ИТ-шный TOP-10. Виртуализируется постепенно все, что можно: сервера, рабочие станции, программные компоненты и др. Но когда дело дойдет до целых офисов… Масштабы и значение для общества этих процессов поражают воображение.

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

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

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

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

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

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

Выделяются три роли консультанта (менеджера) согласно типам решаемых задач управления [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.
  
• Другие продукты…

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

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

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

Ожидаемая длительность проекта, фактически, является одним из факторов дрейфа требований. За долгий срок даже в достаточно неповоротливой компании может многое измениться, например, появиться новое руководство с новым видением. Если же, напротив, проект небольшой и быстрый, то оптимальный вариант — разработать, согласовать и реализовать одно небольшое и достаточно детальное ТЗ.

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

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

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

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

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

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

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

• Категории (роли) пользователей, работающих с системой — перечислить роли и кратко описать каким должностям из каких подразделений они соответствуют.
• Функционал системы — составить иерархическую структуру, в которой на верхнем уровне перечислены крупные модули (подсистемы), далее детализируемые до более мелких функциональных блоков и даже отдельных функций.
• Модель использования системы — сопоставить категории пользователей системы и используемые ими функциональные блоки, обозначенные выше.
• Сценарии использования системы при выполнении основных бизнес-процессов — наложить видение решения на реальные процессы, описать на каких этапах и каким образом оно будет использоваться. Не пожалейте времени на то, чтобы совместно с исполнителем наглядно схематически разрисовать сценарии хотя бы по основным бизнес-процессам и согласовать их с заинтересованными лицами.
• Прототипы пользовательского интерфейса — схематически изобразить, например, при помощи Microsoft Visio как будут выглядеть основные формы вашего будущего ПО.
• Логическая модель данных — изобразить основные сущности предметной области и взаимосвязи между ними. Это позволит вам и исполнителю разговаривать на одном языке с использованием общей терминологии.
• Источники данных и взаимодействие с другими системами — описать откуда будут загружаться первоначальные данные при внедрении системы и из каких внешних источников они будут поступать впоследствии.

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

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

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

P.S. С радостью возьмусь за разработку ТЗ на программный продукт в удобном для Вас варианте сотрудничества.

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

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

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

Рассмотрим простой пример. Наемный сотрудник в компании заработал 100.000$ и размышляет над тем, как максимально эффективно вложить эти деньги. Ему доступны два инструмента инвестирования: банковский депозит (фиксированная доходность 10% в год) и покупка акций (доходность зависит от ситуации на рынке). Для простоты примем, что вариантов действия в данном случае всего три: 100% средств положить на депозит, 100% вложить в акции и поделить средства пополам между акциями и депозитом. Требуется принять оптимальное решение, обеспечивающее максимальную доходность.

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

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

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

Оценка вероятностей сценариев

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

Если вероятности позитивного, нейтрального и негативного сценариев равны соответственно 40%, 50% и 10%, то ожидаемая доходность будет иметь следующие значения.

Поэтому, следует на 100% инвестировать в акции.

Критерий Лапласа

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

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

Критерий Вальда

Очень осторожная стратегия. По каждому варианту действий выбирается результат для наихудшего сценария. Затем выбирается вариант действий с максимальным из наихудших результатов.

В данном случае с точке зрения гарантированного сохранения средств также лучше 100% депозит.

Критерий Гурвица

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

Отсюда видим, что в зависимости от степени нашего оптимизма мы можем выбрать либо 100% депозит, либо 100% акции.

Критерий Сэвиджа

В данном случае анализируется упущенные возможности, т.е. убытки от неправильного решения. Например, было принято решение инвестировать на 100% депозит, а сценарий будущего оказался оптимистичным, то упущенная выгода для этого варианта действий при реализации данного сценария равна 10.000$ (полученный доход) – 20.000$ (можно было бы получить, если бы было принято решение купить 100% акции) = -10.000$ (получено на 10.000$, чем можно было бы получить).

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

Далее для каждого варианта действий определяем наихудшее значение упущенной выгоды. Решением является вариант действий с наилучшим из наихудших значений. В нашем случае эквивалентны варианты 100% депозит и пополам акции и депозит.

Экспертные методы принятия решений

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

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

Метод совещаний

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

Достоинством данного метода является простота его реализации. Недостатком – зависимость от красноречия ораторов, за которым может скрываться недостаточная компетентность в рассматриваемых вопросах.

Метод суда

Мeтoд «cyдa» являeтcя paзнoвиднocтью мeтoдa «coвeщaний» и peaлизyeтcя пo aнaлoгии c вeдeниeм cyдeбнoгo пpoцecca. В poли «пoдcyдимыx» выcтyпaют выбиpaeмыe вapиaнты peшeния; в poли «cyдeй» — лицa, пpинимaющиe peшeниe; в poли «пpoкypopoв» и «зaщитникoв» — члeны экcпepтнoй гpyппы. Рoль «cвидeтeлeй» выпoлняют paзличныe ycлoвия выбopa и дoвoды экcпepтoв. Пpи вeдeнии тaкoгo «cyдeбнoгo пpoцecca» oтклoняютcя или пpинимaютcя тe или иныe peшeния.

Мeтoд «cyдa» цeлecooбpaзнo иcпoльзoвaть пpи нaличии нecкoлькиx гpyпп экcпepтoв, пpидepживaющиxcя paзличныx вapиaнтoв peшeния.

Мозговой штурм

Мeтoды этoгo типa извecтны тaкжe пoд нaзвaниeм кoллeктивнoй гeнepaции идeй, мoзгoвoгo штypмa, диcкyccиoнныx мeтoдoв. Вce эти мeтoды ocнoвaны нa cвoбoднoм выдвижeнии идeй, нaпpaвлeнныx нa peшeниe пpoблeмы. Зaтeм из этиx идeй oтбиpaютcя нaибoлee цeнныe.

Дocтoинcтвoм мeтoдa «мoзгoвoй aтaки» являeтcя выcoкaя oпepaтивнocть пoлyчeния тpeбyeмoгo peшeния. Оcнoвным нeдocтaткoм eгo — cлoжнocть opгaнизaции экcпepтизы, тaк кaк инoгдa нeвoзмoжнo coбpaть вмecтe тpeбyeмыx cпeциaлиcтoв, coздaть нeпpинyждeннyю aтмocфepy и иcключить влияниe дoлжнocтныx взaимooтнoшeний.

Метод сценариев

Мeтoд «cцeнapиeв» пpeдcтaвляeт coбoй coвoкyпнocть пpaвил пo излoжeнию в пиcьмeннoм видe пpeдлoжeний cпeциaлиcтoв пo peшaeмoй пpoблeмe. Сцeнapий пpeдcтaвляeт coбoй дoкyмeнт, coдepжaщий aнaлиз пpoблeмы и пpeдлoжeния пo ee peaлизaции. Пpeдлoжeния внaчaлe пишyт экcпepты индивидyaльнo, a зaтeм oни coглacyютcя и излaгaютcя в фopмe eдинoгo дoкyмeнтa.

Оcнoвным пpeимyщecтвoм cцeнapия являeтcя кoмплeкcный oxвaт peшaeмoй пpoблeмы в дocтyпнoй для вocпpиятия фopмe. К нeдocтaткaм мoжнo oтнecти вoзмoжныe нeoднoзнaчнocть, нeчeткocть излaгaeмыx вoпpocoв и нeдocтaтoчнyю oбocнoвaннocти oтдeльныx peшeния.

Метод Дельфи

Мeтoд «Дeльфи», или мeтoд «дeльфийcкoгo opaкyлa», пpeдcтaвляeт coбoй итepaтивнyю пpoцeдypy aнкeтнoгo oпpoca. Пpи этoм coблюдaeтcя тpeбoвaниe oтcyтcтвия личныx кoнтaктoв мeждy экcпepтaми и oбecпeчeния иx пoлнoй инфopмaциeй пo вceм peзyльтaтaм oцeнoк пocлe кaждoгo тypa oпpoca c coxpaнeниeм aнoнимнocти oцeнoк, apгyмeнтaции и кpитики.

Пpoцeдypa мeтoдa включaeт нecкoлькo пocлeдoвaтeльныx этaпoв oпpoca. Нa пepвoм этaпe пpoизвoдитcя индивидyaльный oпpoc экcпepтoв, oбычнo в фopмe aнкeт. Экcпepты дaют oтвeты, нe apгyмeнтиpyя иx. Зaтeм peзyльтaты oпpoca oбpaбaтывaютcя и фopмиpyeтcя кoллeктивнoe мнeниe гpyппы экcпepтoв, выявляютcя и oбoбщaютcя apгyмeнтaции в пoльзy paзличныx cyждeний. Нa втopoм — вcя инфopмaция cooбщaeтcя экcпepтaм и иx пpocят пepecмoтpeть oцeнки и oбъяcнить пpичины cвoeгo нecoглacия c кoллeктивным cyждeниeм. Нoвыe oцeнки внoвь oбpaбaтывaютcя и ocyщecтвляeтcя пepexoд к cлeдyющeмy этaпy. Пpaктикa пoкaзывaeт, чтo пocлe тpex-чeтыpex этaпoв oтвeты экcпepтoв cтaбилизиpyютcя, и нeoбxoдимo пpeкpaщaть пpoцeдypy.

Дocтoинcтвoм мeтoдa «Дeльфи» являeтcя иcпoльзoвaниe oбpaтнoй cвязи в xoдe oпpoca, чтo знaчитeльнo пoвышaeт oбъeктивнocть экcпepтныx oцeнoк. Однaкo дaнный мeтoд тpeбyeт знaчитeльнoгo вpeмeни нa peaлизaцию вceй мнoгoэтaпнoй пpoцeдypы.

Заключение

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

Линейное программирование

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

Для примера рассмотрим простую задачу, которую решим графически.

Пусть перед компанией А стоит задача организовать рекламную компанию, длительностью один месяц, на которую выделено в бюджете 10.000$. Имеется возможность разместить рекламный ролик на радио (стоимость минуты эфирно времени на радио 500$) и/или на телевидении (стоимость минуты на местном TV равна 1000$). Имеются статические данные об эффективности маркетинговых каналов. Так 1 минута на телевидении в среднем обеспечивает рекламодателю 15 новых клиентов, а 1 минута на радио – 10 новых клиентов. Кроме того, все рекламодатели должны соблюдать местное антимонопольное законодательство, в рамках которого общая длительность транслированных по всем каналам рекламных роликов не должна превышать 15 минут в месяц.

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

Для принятия решения в данной ситуации воспользуемся методом линейного программирования. Пусть X – общая продолжительность роликов на радио (в минутах), а Y – на ТВ. Тогда целевая функция (эффективность = кол-во новых клиентов от кампании) будет представлять из себя:

F(X,Y) = 10*X + 15*Y

Ограничения:

500*X + 1000*Y <= 10.000 (бюджетное)

X + Y <= 15 (законодательное)

X >= 0, Y >= 0 (очевидное)

Теперь изобразим имеющиеся ограничения графически.

Многоугольник, с вершинами 1, 2, 3 и 4 представляет из себя множество возможных значений X и Y, удовлетворяющих заданным ограничениям (заштрихованная область).

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

Рассчитаем значения F(X,Y) в точках 1-4.

Как видим, максимальное значение новых клиентов (175) достигается при условии размещения роликов на радио с общей длительностью 10 минут и на ТВ с общей длительностью 5 минут.

Календарно-сетевое планирование

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

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

Работы, не лежащие на критическом пути, имеют запас времени на завершение. В нашем примере работа «Проложить дорогу к дому» имеет запас времени 4 месяца, а работа «Закупить стройматерилы» — 2 месяца.

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

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

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

Теория игр

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

Рассмотрим применение элементов теории игр на примере т.н. дилеммы заключенных. Пойманы два преступника (A и B), совместно совершивших одно вооруженное ограбление. Однако, следствие не может доказать, что вооруженное ограбление совершили именно они. Следствие может лишь доказать, что они незаконно носили оружие. По закону за вооруженное ограбление положено тюремное заключение сроком на 10 лет, за ношение оружия – 1 год тюрьмы. В связи со сложившейся ситуацией следователь предлагает каждому участнику сознаться. Также он сообщает, что если сознаются оба участника, то каждому из них срок будет сокращен в два раза до 5-ти лет. Возможности общаться между собой у заключенных нет. Вопрос: следует ли каждому из заключенных сознаться или продолжать молчать?

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

Для краткости и четкости обозначим в ячейках матрицы результаты для игроков A и B в виде: результат А, результат B.

Заключенные хотят получить «гарантированный» оптимальный результат игры при любых стратегиях другого игрока. Для этого, т.к. заключенные не связаны друг с другом, при принятии решения (сознаться или молчать) они рассматривают для каждой возможной стратегии наихудший результат. Так, если заключенный A сознается, то его наихудший результат равен -10 (если B сознается). В случае же, если А будет продолжать молчать, то его наихудший результат равен -1 (если B также будет продолжать молчать). Следовательно, А выбирает для себя стратегию «молчать», как наиболее эффективную при любых действиях B. Нетрудно увидеть, что для B «молчать» — также оптимальная стратегия. В итоге оба заключенных будут молчать и выйдут на свободу через год. Если кто-то из них не владеет аналитическим аппаратом принятия решения, то он в итоге может просидеть в тюрьме 5 или даже 10 лет, за счет чего владеющий им может выйти сразу на свободу.

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

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

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

Наихудшие результаты для А при любых действиях B, если сознаться = -5, если молчать = -10. Следовательно, А выгоднее сознаться. Аналогично выгоднее сознаться и B. Следовательно, оба подозреваемых сознаются и получат по 5 лет тюрьмы.

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

Матрица тогда выглядит так.

Наихудшие результаты для А при любых действиях B, если сознаться = -30, если молчать = -10. Следовательно, А, как и B, выгоднее молчать. В итоге оба получат всего лишь по году тюрьмы.

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

Теория очередей

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

Рассмотрим обобщенную модель очереди.

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

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

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

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

Человеческий мозг, находясь вне конкуренции в качестве универсального средства принятия решений, тем не менее, часто уступает другим инструментам при принятии специфических решений. В качестве примера можно известную игру в 2003-м году чемпиона мира по шахматам Гарри Каспарова с компьютерной программой X3D Fritz, запущенной всего лишь на одном компьютере с четырьмя процессорами Pentium 4 Xeon (почти PC). Как известно, состязание состояло из четырех игр, в двух из которых была ничья, в одной победил Каспаров и в одной победил X3D Fritz. Т.е. компьютерная программа, в основе которой лежат математические алгоритмы, не уступила человеческому мозгу в принятии решения «Какой сделать следующий ход, чтобы выиграть партию?».

Интересен ответ Каспарова на заданный ему после игры вопрос:

Журналист: Вы согласны с утверждением одного из международных гроссмейстеров, который сказал, что человек всегда умнее машины?

Каспаров: Матчи против машины имеют свою специфику. Ты находишься в постоянном напряжении. Ошибаться недопустимо, поскольку человек может тебе простить оплошность, а программа — нет.

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

Об аналитическом аппарате для принятия решения и пойдет речь далее.

Общая схема процесса принятие решения

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

РЕШЕНИЕ (в психологии) – формирование стратегий и последовательности действий для достижения цели, основанное на избирательных мыслительно-поисковых актах и преобразовании субъективных смыслов.

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

РЕШЕНИЕ (в математике) — 1. Выбор одной или нескольких альтернатив из множества возможных (вариантов решения). 2. Процесс (алгоритм) осуществления такого выбора.

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

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

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

Ниже рассмотрены отдельные аналитические методы, разбитые на четыре группы:

«Простые» методы принятия решений

«Визуальные» методы

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

Бостонская матрица

Категории решений: Решения в маркетинге по управлению продуктовым портфелем организации.

Наглядное представление: Матрица 2×2, по осям откладываются доля рынка, темп роста рынка. Далее продукты компании оцениваются с точки зрения этих двух параметров и помещаются в виде точек в эту матрицу.

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

SWOT-анализ

Категории решений: Стратегические решения для организации и индивидуума.

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

Ниже приведен пример заполнения матрицы для производителя автомобилей.

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

Сравнение альтернатив по критериям

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

Включает в себя следующую последовательность действий:

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

Более наглядно пример применения данного метода показан на схеме ниже.

Деревья решений

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

Проще всего проиллюстрировать идею метода деревьев решений на примере. Пусть сотрудник Антон работает в компании X. Компания X предлагает Антону сдать экзамен для получения сертификата по технологии Y. Компания не желает оплачивать обучение Антона, но готова предоставить ему время и на обучение и на самоподготовку в пределах рабочего дня. Компания X желает замотивировать Антона и обещает разовую премию в размере 2000$ в случае успешной сдачи экзамена и вычесть из зарплаты 500$ в случае провала на экзамене в счете рабочего времени, потраченного на подготовку. У Антона есть возможность пройти обучение, заплатив за это 1000$ собственных средств, в этом случае его шансы на успешную сдачу экзамена равны 80%. В случае самостоятельной подготовки его шансы на успех равны 50%. Антон имеет исключительно финансовую мотивацию для сдачи экзамена.

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

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

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

Так в исходной точке 1 Антон принимает решение сдавать или не сдавать экзамен, а затем в точке 2, если экзамен решено сдавать, он принимает решение проходить или не проходить обучение. В случае сдачи экзамена после обучения его шансы на успех возрастут (исход А) по сравнению со сдачей без обучения (исход B).

Расчеты для обоснования решений в точках 1 и 2 начинаются с «листьев» дерева. Так, «стоимость» исхода А равна 500$ (+2000$ * 0,8 – 500$ * 0,2 – 1000$ за обучение). Стоимость исхода B равна 750$ (+2000$ * 0,5 – 500$ * 0,5). Очевидно, что в точке 2 Антон сравнив стоимость исходов A и B, предпочтет B, как более дорогой. В итоге стоимость решения в точке 2 будет равна стоимости выбранного исхода (750$). В точке 1 Антон сравнивает стоимость варианта 2 и C. Он выбирает 2, т.к. 750$ > 0$.

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

Диаграмма Исикавы

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

На представленной диаграмме прямоугольники 1-3 – главные факторы, влияющие на анализируемый показатель качества. Квадраты 4-10 – вторичные факторы, влияющие на главные. А цифры 11-26 отражают третичные факторы, влияющие на вторичные.

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

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