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

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

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

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

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

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

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

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

3. Идеи от IT

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Метод суда

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

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

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

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

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

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

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

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

Метод Дельфи

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

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

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

Заключение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Теория игр

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SWOT-анализ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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