Наверное, не будет слишком уж сильным невежеством утверждать, что максимально возможный эффект для бизнеса от ИТ-решения, отнесенный к стоимости его разработки/внедрения – величина примерно одинаковая для решений разных вендоров, технологий, парадигм и т.п. Есть лишь только одна маленькая деталь – реальный эффект от ИТ-решения, как правило, существенно меньше максимального (часто иногда он меньше нуля) и стремится к максимальному в том случае, если это правильное решение для конкретной компании и внедряется оно правильными людьми. Попытки внедрить 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. С радостью возьмусь за разработку ТЗ на программный продукт в удобном для вас варианте сотрудничества. Подробнее на http://ит-консультант.рф

Большинство решений принимается в условиях недостатка информации и неопределенности. Это связано с тем, что принимаемое решение реализуется в будущем. Соответственно, при принятии решения мы опираемся на некоторое видение (модель) будущего, сценарий развития событий. Однако очевидно, что будущее не может быть спрогнозировано со 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 отражают третичные факторы, влияющие на вторичные.

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

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

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

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

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

Содержание

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

Ролевая модель

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

Схема бизнес-процесса

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

Бизнес-процесс включает в себя пять групп (контуров) работ:

• Контур сбора требований
• Контур среднесрочного планирования
• Контур аналитических работ
• Контур разработки версии (итерация)
• Контур небольших доработок

Контур сбора требований

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

В частности, требованиями являются:

• Ошибки, выявленные при внутреннем или внешнем (ПСИ) тестировании, в процессе эксплуатации решения
• Функциональные требования (доработки)
• Нефункциональные требования (ограничения, которым должно удовлетворять решение)

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

• Представители Заказчика
• Тестеры в составе проектной команды
• Руководства компании

Все требования хранятся в Репозитории требований. Подробнее о требованиях (их атрибутах и жизненном цикле) написано в разделе «Информационная модель».

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

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

Все требования делятся на две группы с точки зрения подхода к их реализации:

• Мелкие доработки

  • o длительность их реализации до 1 человеко-дня И
  • o не требуют аналитической проработки (написания Технического проекта)
• Средние и крупные доработки

  • o длительность реализации более человеко-дня ИЛИ
  • o требуют аналитической проработки (написания Технического проекта)

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

Реализация средних и крупных доработок происходит постадийно:

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

Контур среднесрочного планирования

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

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

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

Планы работ хранятся в Репозитории задач.

Контур аналитических работ

Согласно плану работ Аналитик производит аналитическую проработку требования и составляет документ с утвержденной структурой разделов – Технический проект с описанием логики реализации требования.

Технический проект, подготовленный Аналитиком, согласуется с:

• Руководителем проекта
• Руководителем группы
• Архитектором

После составления и согласования ТП требование помечается как готовое к включению в план разработки версии.

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

Контур разработки версии

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

При планировании работ по версии проектная команда просматривает требования, выбирая среди них те, которые:

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

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

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

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

Рабочий проект, подготовленный Разработчиком, согласуется с:

• Архитектором
• Руководителем группы
• Руководителем проекта

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

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

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

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

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

После того, как все доработки, запланированные в версии, реализованы Билд-инженер производит сборку версии. Билд-инженер, формирует Сопроводительный документ к версии, в котором:

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

Собранная версия тестируется Тестером при участии Аналитика согласно плану тестирования, являющегося составной частью Технического проекта, разработанного Аналитиком. Выявленные ошибки регистрируются в Репозитории требований в виде требований с типом «Ошибка тестирования версии».

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

После того, как ошибки тестирования версии устранены тестирование повторяется. Версия выпускается в следующих случаях:

• Все «Ошибки тестирования версии» устранены
• Принимается решение о выпуске версии с рядом не устраненных ошибок

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

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

Контур небольших доработок

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

Все небольшие доработки делятся на две группы:

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

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

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

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

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

После выпуска промежуточной версии Разработчики вносят изменения, соответствующие критическим мелким доработкам, в основную рабочую версию.

Участие ролей в операциях бизнес-процесса

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

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

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

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

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

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

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

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

Информационная модель бизнес-процесса

Все виды информации в рамках бизнес-процесса разработки распределяются по пяти хранилищам (репозиториям):

• Репозиторий требований
• Репозиторий архитектуры
• Репозиторий документации
• Репозиторий кода
• Репозиторий задач (план работ)

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

На схеме ниже показаны примеры содержимого репозиториев и взаимосвязи между ними. Затем в таблице дается краткое пояснение по содержимому репозиториев и описаны взаимосвязи между их элементами.

Средства автоматизации бизнес-процесса

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

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

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

Содержание

• Определение и границы процесса поддержки клиентов
• Модели процессов поддержки

  • Многоуровневая модель обработки обращений

    • Вариант 1. Одноуровневая обработка обращений
    • Вариант 2. Двухуровневая обработка обращений
    • Вариант 3. Трехуровневая обработка обращений
  • Управление предоставлением ИТ-сервисов (ITSM)

    • Соглашение об уровне сервиса (SLA)
    • Основные понятия ITSM в процессе обработки обращения
• Мониторинг эффективности процессов поддержки
• Заключение

Определение и границы процесса поддержки клиентов

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

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

• основные и вспомогательные бизнес-процессы
• основные средства для обеспечения сервисной деятельности
• специализированные информационные системы и оборудование (Service Desk, ПО Contact-центра и др.)
• персонал
• CRM-система, увязывающая информацию о предоставлении сервиса в общее хранилище данных по взаимоотношениям с потребителями, а также с другими ИС предприятия (ERP и др.)
• бизнес-процессы управления сервисной деятельностью, методики ее планирования и оценки эффективности
• соответствующий раздел стратегии компании, описывающий политику в области сервиса

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

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

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

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

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

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

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

Модели процессов поддержки

Многоуровневая модель обработки обращений

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

Вариант 1. Одноуровневая обработка обращений.

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

Плюсы такого подхода:

• Минимальное время решения проблем.
• Удобство общения для клиента.

Минусы:

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

Вариант 2. Двухуровневая обработка обращений.

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

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

Плюсы:

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

Минусы:

• Клиенту приходится общаться с разными сотрудниками поддержки, ждать соединения, объяснять проблему несколько раз.

Вариант 3. Трехуровневая обработка обращений.

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

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

Плюсы:

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

Минусы:

• Обработка обращений может занимать несколько часов или дней.

Ну и наконец, стоит напомнить о том, что обработка обращений может вестись без участия оператора.

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

Управление предоставлением ИТ-сервисов (ITSM)

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

В этом разделе мы рассмотрим отдельные идеи методологии по управлению ИТ-услугами (IT Service Management), являющейся центральной частью библиотеки ITIL. В ITSM описывается взаимодействие между ИТ-службой и остальными подразделениями какой-либо компании. В качестве основного элемента этого взаимодействия рассматривается ИТ-сервис – услуга, которая оказывается ИТ-службой и используется бизнес-подразделениями. Примеры ИТ-сервисов: поддержка работоспособности компьютеров, администрирование и поддержка учетной системы и т.п. При этом ИТ-служба и бизнес-подразделение рассматриваются как достаточно обособленные субъекты, которые в общем случае могут находиться и в разных компаниях (аутсорсинг ИТ-услуг). Более того, в методологии ITSM многие базовые идеи не являются специфическими для ИТ и применимы не только для ИТ-услуг, но и для описания взаимодействия между поставщиком и потребителем услуг в иных сферах. В частности, если в качестве поставщика сервиса «Поддержка клиентов» рассматривать службу поддержки банка, а в качестве его потребителя клиента этого банка, то мы получаем возможность воспользоваться отдельными инструментами ITSM для описания процессов универсальной поддержки клиентов этого банка или какой-либо другой компании.

Рассмотрим две такие «универсальные идеи» ITSM:

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

Соглашение об уровне сервиса (SLA)

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

В самой компании при предоставлении услуги осуществляется определенный бизнес-процесс или группа процессов. Операции этих бизнес-процессов имеют определенные характеристики, влияющие на соблюдение значений параметров SLA. Задача менеджера, проектирующего услугу, в данном случае состоит в том, чтобы оценить и зафиксировать характеристики операций внутри компании в Operational Level Agreement (OLA), на их основе определить реалистичные значения показателей уровня сервиса для клиента, зафиксировать их в SLA и впоследствии отслеживать их соблюдение при каждом обращении клиента за данной услугой.

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

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

Основные понятия ITSM в процессе обработки обращения

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

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

На следующей картинке изображен пример обработки обращения в службу поддержки с использованием этой терминологии.

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

Все перечисленные выше сущности и взаимосвязи между ними создаются, хранятся и обрабатываются в специализированной информационной системе – Service Desk (иногда ее также называют Order Management или Trouble Ticketing). При этом функции системы Service Desk не ограничиваются поддержкой workflow по работе с обращениями за поддержкой. Также эти системы занимаются формированием базы знаний службы поддержки (на основании информации, собранной в процессе поиска решений проблем), хранением информации об инфраструктуре предоставления услуг, управлением ею и др.

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

Мониторинг эффективности процессов поддержки

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

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

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

Это, несомненно, важные и нужные показатели, однако, называть их показателями эффективности вряд ли правильно. Например, каково «эффективное» среднее время разговора? Может быть, чем меньше – тем лучше – экономия на зарплате операторов!? Тогда как быть с ситуацией, когда в результате длительного 15-минутного разговора клиент приобрел ряд дополнительных продуктов или услуг, а в результате короткого 30-секундного разговора только задал несложный вопрос? Или каков «эффективный» уровень загруженности операторов? Может быть, 100% – ведь надо максимально «эффективно» использовать персонал!? Тогда как быть, если действительно «эффективные» люди не идут работать в условиях такой «эффективности»? Может быть, «эффективный» процент потерянных вызовов – стремящийся к нулю? Тогда как быть со случаями, когда уровень доступности телефонной службы поддержки целенаправленно снижается, чтобы «приучить» клиентов пользоваться инструментами самообслуживания (вэб-портал, IVR) с целью снижения издержек?

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

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

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

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

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

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

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

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

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

Исходя из такого определения, чтобы сделать что-то эффективно мы должны:

1. Сформулировать задачи этой деятельности в соответствии со стоящими целями.
2. Определить критерии соответствия того, что делается стоящим целям – ключевые показатели эффективности (КПЭ).

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

• Для достижения цели «Снижение издержек»
  • Внедрение систем самообслуживания клиентов
  • Повышение производительности труда операторов за счет использования продвинутых систем распределения вызовов
• Для достижения цели «Повышение удовлетворенности сотрудников работой»
  • Внедрение продвинутой системы учета обработки обращений для оплаты по результатам
  • Оптимизация загрузки сотрудников

А показателями эффективности сервисной поддержки могут являться:

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

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

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

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

Технические метрики могут использоваться для:

• Расчета значений КПЭ. Например, КПЭ «Средняя себестоимость обработки обращения» может рассчитываться на основании значений метрик по формуле (Себестоимость обработки оператором + Себестоимость обработки на портале самообслуживания + Себестоимость обработки на IVR) / 3.
• Детализации значений КПЭ в процессе поиска причин отклонений. Например, в процессе анализа причин увеличения значения КПЭ «Средняя себестоимость обработки обращения» может быть обнаружено существенное снижение значения метрики «Процент обслуженных вызовов на 1-м уровне». Это означает, что по каким-то причинам высококлассные (и высокооплачиваемые) специалисты 2-го уровня вынуждены заниматься решением типовых задач. Дальше анализируется почему это происходит (например, переход на поддержку новых продуктов не сопровождался достаточным обучением операторов 1-й линии) и ищутся пути решения.

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

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

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

Вот основные варианты использования собранной информации:

• Сравнений значений КПЭ через определенные периоды времени – Что происходит?
• Анализ абсолютных значений КПЭ и технических метрик – Почему это происходит?
• Сравнение значений КПЭ «до» и «после» планируемого преобразования – Что должно будет произойти? Что же произошло на самом деле?
• Сравнение значений КПЭ компании с аналогичными показателями компаний-конкурентов (при наличии такой информации) – Что происходит у нас по сравнению с тем, что происходит у наших конкурентов?

Согласитесь – весьма актуальные вопросы для любого менеджера!

Заключение

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

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

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

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

Содержание

• Цели и требования к формату описания бизнес-процессов
• Основные документы описания бизнес-процесса
• Укрупненная структура бизнес-процессов
  
• Детальная схема этапа бизнес-процесса
• Описание операций бизнес-процесса
• Структура меню IVR
  

Цели и требования к формату описания бизнес-процессов

1. Инструмент согласования. Мы разрабатываем перспективные процессы, основываясь на своем собственном видении. При этом сложно переоценить значимость участия экспертов заказчика в оттачивании этого видения с учетом различных тонкостей предметной области. Описания бизнес-процессов должны быть максимально наглядными, интуитивно понятными и вместе с тем достаточно детализированными для того, чтобы облегчить процесс их демонстрации, обсуждения и согласования с заказчиком.
2. Основа для внедрения. Естественно, что после согласования перспективных процессов их предстоит внедрить – написать необходимые регламенты и инструкции, обучить персонал и др. Описания БП должны стать базой для этого. Поэтому, нотация должна включать в себя необходимую дополнительную информацию, например, текстовые сценарии выполнения сложных операций, критерии качества выполнения операций и др.
3. Основа для проектирования прикладного ПО. Одним из важнейших компонентов создаваемого решения является прикладное программное обеспечение. Его проектирование начинается с формулирования функциональных требований и разработки спецификаций, причем делать это по понятным причинам необходимо в увязке с разработкой БП. По этой причине при описании элементарных операций процессов, подразумевающих работу с создаваемыми информационными системами, необходимо описывать и сценарии их использования (алгоритмы работы пользователя с системой).
4. Основа для настройки оборудования и системного ПО. В процессе инсталляции оборудования и системного ПО Call-центра происходит его настройка под специфические бизнес-процессы (схемы маршрутизации, меню IVR, квалификации операторов и др.). Поэтому формат описания БП должен содержать в себе всю необходимую для этого информацию.

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

Основные документы описания бизнес-процесса

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

1. Укрупненная структура бизнес-процесса. Внутри каждого процесса выделяются несколько логически завершенных этапов, составляющих его структуру. Она изображается в виде дерева с краткими пояснениями к элементам. Если бизнес-процесс достаточно простой (короткий), то выделять в нем несколько этапов нет необходимости. Полезно также иметь общее дерево со всеми описываемыми бизнес-процессами и их этапами. Для изображения такой иерархической структуры есть смысл использовать нотацию IDEF0.
2. Детальная схема этапов бизнес-процесса. При всей привлекательности использования IDEF0, схемы, выполненные в этой нотации, все-таки являются недостаточно выразительными. Поэтому для детального описания этапов бизнес-процессов мы использовали формат, представляющий из себя нечто среднее между UML-диаграммой Activity и SDL-диаграммой с учетом специфики описания БП Call-Contact-центра.
3. Таблица с описанием элементарных операций. Этапы работ в конечном счете состоят из элементарных операций, изображенных на схемах. Для целей дальнейшего проектирования ИС, внедрения БП и др. мы снабдили их дополнительной информацией, сведенной в общую таблицу с описанием элементарных операций.
4. Структура меню IVR. Часть операций по обработке вызова осуществляется на IVR. Чтобы не загромождать схему БП мы вынесли структуры меню в отдельный документ.

Укрупненная структура бизнес-процессов

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

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

Взаимосвязь между этапами оформлена в соответствии с методологией IDEF0: входы, выходы, управление и ресурсы.

Детальная схема этапа бизнес-процесса

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

Для описания операций (потока работ) использована идеология «плавательных дорожек» (swim lane), где с каждой дорожкой сопоставлен исполнитель операций. Таким образом, БП последовательно перетекает от одной дорожки к другой при переходе выполняемых операций от одного исполнителя к другому. В качестве исполнителей для наших целей мы выделили операторов разных квалификаций, сотрудников различных подразделений. Также в качестве обработчиков операций мы отдельно показали технологические компоненты: IVR, Web-портал, информационные системы.

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

Описание операций бизнес-процесса

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

Наименование поля	Пример заполнения
Номер операции	2
Название операции	Регистрация запроса
Сценарий выполнения операции	Оператор в процессе телефонного разговора задает клиенту уточняющие вопросы для выяснения сути запроса, после чего вводит полученную информацию в ИС в виде заявки.
Исполнитель	Оператор
Критерии качества выполнения операции	Полнота и четкость заполнения формы запроса.Количество отбракованных заявок как требующих уточнения информации.
Используемые в процессе выполнения ИС	АРМ Оператора
Функциональные требования к ИС	Возможность просмотра истории заявок по конкретному клиентуВозможность регистрации новой заявки
Сценарии работы пользователя с ИС	При поступлении вызова на экране оператора в подсистеме автоматически показывается карточка абонента с краткой информацией о нем, наличие задолженности, перечень заявок от абонента. Оператор имеет доступ к истории заявок абонента. Если заявки нет, то нажимает кнопку «Добавить», всплывает форма создания заявки. Оператор заполняет все необходимые поля и сохраняет заявку, после этого она попадает в список.

Структура меню IVR