На рынке 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-х месяцев даже при рассмотрении только лишь прямого экономического эффекта.

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

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

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

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

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

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

Содержание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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