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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы:

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

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

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

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

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

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

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

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

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

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

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

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

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

Что видим:

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

Выводы:

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

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

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

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

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

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

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

Что видим:

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

Выводы:

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

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

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

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

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

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

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

Что видим:

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

Выводы:

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

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

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

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

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

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

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

Что видим:

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

Выводы:

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

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

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

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

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

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

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

Что видим:

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

Выводы:

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

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

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

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

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

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

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

P.S.

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

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

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

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

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

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

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

Например, если целью является последующая автоматизация, то целесообразно строить модели в нотациях и средствах моделирования, рекомендуемых для тех систем, которые планируется внедрять: 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.

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

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

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

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

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

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

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

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

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

Содержание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Содержание

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