А как вы разрабатываете ТЗ на автоматизацию бизнес-процесса?
Большинство компаний всё чаще произносят слово “бизнес-процесс” в нужное время и в нужном месте. Это значит, что рассматривая ИТ-систему в какой-либо предметной области, готовя требования к проекту, разговаривая с поставщиками, Команда выбора и ЛПР говорят о процессах.
Какие аспекты работы бизнес-процесса стоит учесть при написании ТЗ для его автоматизации?
На уровне отдельной операции процесса Пол Хармон в книге Business Process Change выделяет 5 аспектов, которые необходимо учесть при стандартизации операции бизнес-процесса, которые влияют на производительность операции:
- Activity Specification. Стандартизирована ли операция? Знает и понимает ли исполнитель ожидаемый результат? Разделяет ли исполнитель мнение о том, что стандарт операции достижим?
- Activity Support. Может ли исполнитель с легкостью понять момент, когда нужно начать выполнение операции? Может ли операция быть выполнена без влияния на другие активности исполнителя? Имеются ли необходимые ресурсы для исполнения операции?
- Consequences. Соответсвуют ли выходы операции желаемой производительности? Результаты операции значимы для исполнителя? Выходы операции контролируются по времени?
- Feedback. Получает ли исполнитель информацию о своей производительности? Получает ли исполнитель обратную связь по соответствию выходов операции ожиданиям?
- Skill, knowledge and capability. Имеет ли исполнитель необходимые компетенции и знания? Понимает ли исполнитель общую значимость своей производительности? Имеет ли исполнитель эмоциональную возможность достичь необходимую производительность?
Попробуем переосмыслить аспекты, которые важны для операции, и распространить их на бизнес-процесс в целом.
Схема подготовки требований
Как разработчик BPM-системы мы сталкиваемся с тем, что графическая схема процесса (построенная, например, в Business Studio) не является техническим заданием для его автоматизации. Информация, изложенная на схеме процесса, дает лишь первичное представление о процессе, она является необходимой, но недостаточной для подготовки задания на автоматизацию.
Схема инициации процесса. Необходимо предусмотреть правила, мотивы и удобство старта бизнес-процесса. Это гарантирует, что им будут пользоваться сотрудники или клиенты. Различные способы запуска процесса позволяют “органично встроить” процесс в работу компании.
Схема создания ценности. Коротко о ценности процесса. Для чего он нужен компании? Что от процесса ожидает его заказчик? Можно проанализировать приоритеты заказчика процесса, исходя из них выбрать логику процесса и средства автоматизации.
Схема работы процесса. В этом пункте можно использовать графическую схему процесса, она исчерпывающе объясняет то, как работает процесс. Если схемы процесса нет, то можно коротко в табличном виде описать входы, выходы и преобразования внутри процесса. Подробнее на рисунке выше.
Схема данных процесса. Достаточно крупноблочно определить набор данных процесса, каждую группу данных выделить отдельным названием. Если необходимо, отдельные группы данных можно проработать достаточно подробно. Усилия, вложенные в схему данных процесса, окупятся за счет снижения потерь информации в процессе.
Схема контроля процесса. Внутренние и внешние показатели процесса имею громадное значение для всех его стейкхолдеров (заинтересованных лиц). Необходимо определить Что и Как планируется контролировать внутри процесса. Важно, что отчеты во многих случаях просто не работают! Поэтому схема контроля процесса вынесена на верхний уровень нашего обсуждения.
Схема обратной связи процесса. Без предоставления обратной связи и без мотивации сотрудников не будут работать многие ценные процессы. Необходимо рассказать участникам процесса “что такое хорошо и что такое плохо”, сделать прохождение процесса прозрачным, и где надо замотивировать.
Схема компетенций процесса. Квалифицированный участник процесса может выполнить свою задачу качественно и быстро. Если просадка по качеству может быть отловлена и исправлена по ходу процесса, то финальное чистое время исполнения задачи — это вопрос компетенций. Более того, многие компании ставят задачу упрощения бизнес-процесса, применения бизнес-правил и оптимизации принятия решений. Все это делается для того, чтобы снизить требования к компетенциям участников процесса.
Проработка приведенных на рисунке требований не должна превратиться в написание многостраничных ТЗ. Результатом может быть небольшой документ в табличном виде, который убивает сразу несколько зайцев:
- Создается единое понимание/видение процесса, которое разделяется бизнесом компании, ИТ-специалистами компании и будущим исполнителем;
- Прорабатывая требования в комплексе, компания лучшим образом понимает приоритетные и вторичные требования к системе. Компания прорабатывает сценарии использования будущей системы;
- У компании появляется фундамент для оценки применимости различных инструментов автоматизации.