Привет, Хабр! Я Владимир Хрыпун, руководитель центра компетенций по развитию BPM-систем. Если кратко, то когда у вас в компании есть бизнес-процесс – регулярно повторяющиеся действия приводящие к нужным и прогнозируемым результатам, и вы хотите (или собственник бизнеса), чтобы эти результаты были лучше, потерь меньше и вообще все были счастливы и купили по ламбаргини, то вам нужна такая команда как наша. Мы помогаем частично или полностью автоматизировать бизнес-процессы компании.
Эта статья о чек-листе анализа полноты бизнес-требований для проектов цифровой трансформации.
Чем больше людей работает в процессе, тем больше будет эффект от внедрения bpm-системы. Представим, что операционный бизнес – это грузоперевозки, в бизнесе около 100 000 вагонов. У вас тысячи клиентов и сотни сотрудников. И допустим, что один из процессов – это согласование с клиентом маршрута, по которому пойдет груз. Результат: маршрут согласован, вагоны готовим под погрузку. В процессе участвует несколько отделов, выполняющих различные роли, и ежедневно сотрудники компании делают сотни действий, чтобы добиться результата – такие процессы называют сквозными, они большие, сложные, но жизненно важные для бизнеса. Экономические эффекты в таком проекте можно достичь упростив процесс, сложные или редко используемые шаги сделать понятными для сотрудников. Самый яркий пример – это “Вкусно и точка” *). Они не делают самые вкусные бургеры, зато они делают их быстро и с гарантированным уровнем качества. Сложные процессы упрощены и там, где это возможно, автоматизированы. Поэтому за 5 минут мы можем купить дешевый бургер, а компания на этом зарабатывает миллионы – все счастливы (особенно акционеры))).
Так вот, когда вы автоматизируете бизнес-процесс, успешность проекта зависит от множества факторов. Ключевой – качество бизнес-требований. Бизнес-требования с одной стороны достаточно понятное определение, но как показывает практика, каждый вкладывает в это свои смыслы. Из 100 бизнес-аналитиков на рынке РФ и СНГ, только трое досконально изучили BABOK ( Business Analysis Body of Knowledge), а остальные, как у классика “Мы все учились понемногу чему-нибудь и как-нибудь”. Как следствие бизнес-требования могут не охватывать весь процесс, не упрощать, а усложнять шаги этого процесса. Когда бизнес-требования сделаны плохо, работа остальных команд будет бесполезна. А это десяток ИТ-сотрудников: системные аналитики, разработчики, архитекторы, тестировщики и другие. Представьте, если повар Мишлен приготовит блюдо из просроченных продуктов, да еще и не все ингредиенты будут. Повар может все сделать идеально, вот только есть это блюдо будет опасно для здоровья. Тоже с проектами, где плохо сделан бизнес-анализ.
Ставки в проектах автоматизации сквозных процессов высоки – 3-12 месяцев и бюджет на всю команду разработки. Для того, чтобы исключить риски связанные с качеством бизнес-требований мы разработали чек-лист: “Проверка бизнес-требований на полноту и непротиворечивость”. Это своего рода проверка ингредиентов прежде, чем приступать к готовке. Все ингредиенты для нужного блюда у нас есть? А все они свежие и надлежащего качества? Если да, то посетители ресторана будут в восторге.
Чек-лист разбит на блоки и бизнес-требования мы проверяем, опираясь на каждый из блоков. Чем меньше пунктов будет заполнено, тем выше риски того, что сроки проекта и бюджет кратно увеличатся.
Состав проекта и его цели
Зафиксирован список заинтересованных лиц и владельцев бизнес-процессов. Указано, за какой процесс отвечает, либо в каком процессе принимает участие заинтересованное лицо.
Описаны эффекты от внедрения бизнес-процесса(ов). В документе указан как минимум один из перечисленных ниже эффектов:
экономические выгоды;
экономия трудозатрат;
соответствие условиям законодательства РФ и требованиям информационной безопасности;
иные эффекты, выраженные в качественных и количественных показателях.
Документ содержит перечень бизнес-процессов, трансформация которых позволит достичь эффектов, заявленных в проекте. Если наименования процесса нет в реестре компании, то проектная команда предлагает свое наименование. Наименование процесса должно быть не более 1-2 предложений.
Для каждого бизнес-процесса есть краткое описание, умещающееся в одном абзаце (не более 150-300 слов). Текст должен содержать суть бизнес-процесса без отсылок на другие тексты.
Описание Бизнес-процесса
Применимо для каждого бизнес-процесса, заявленного в составе проекта. Бизнес-процесс описан от начала до конца, то есть учтены все действия в рамках процесса.
Обозначены границы бизнес-процесса
Определено и описано стартовое событие, инициирующее бизнес-процесс.
Описаны предварительные условия, которым должна удовлетворять система до начала бизнес-процесса для его успешного запуска.
Описаны варианты входа в бизнес-процесс.
Перечислены результаты и итоги успешного завершения бизнес-процесса.
Описан основной сценарий бизнес-процесса
Текстовое описание бизнес-процесса последовательно, процесс разобран шаг за шагом. Сначала разобрана основная ветка процесса— успешная, затем альтернативные и отказные ветки.
Для составления целостной картины о бизнес-процессе нет необходимости переключаться между частями документа. Процесс описан последовательно и линейно.
Если описывается бизнес, функциональное или нефункциональное требование, использующееся на нескольких этапах (или шагах) процесса (или процессов), оно полностью описано в каждом этапе (не вынесено отдельно).
Бизнес-процесс должен включать все действия пользователей, обеспечивающие достижение результата бизнес-процесса, в том числе за рамками системы.
Если для достижения планируемых эффектов заказчик планирует изменить бизнес-процесс, то документ должен содержать детальное описание бизнес-процесса с приложенными схемами as-is и to-be, которые сопровождаются текстовым пояснением. Описание процесса «as-is» — как процесс работает сейчас, то есть до проекта цифровой трансформации. Описание процесса «to-be» — целевое состояние процесса, которое позволит достичь заявленных в проекте эффектов.
Если заранее определены системы, в рамках которых осуществляется бизнес-процесс, для каждого шага/этапа в явном виде должна быть прописана система, в которой шаг выполняется. Если операцию (шаг/этап) сотрудники выполняют вне систем, это также должно быть отражено и указано в текстовом описании и схемах.
Рекомендованная нотация для описания бизнес-процесса — BPMN 2.0. Допустимы: EPC, IDEF0 совместно с IDEF3, блок-схемы, если соответствуют всем требованиям чек-листа.
Описаны все альтернативные ветки бизнес-процесса
Перечислены все альтернативные ветки, для каждой альтернативной ветки указан шаг/этап основного сценария, где может произойти ветвление.
Альтернативные ветки описаны с явным указанием событий и основных этапов процесса, на которых происходит переход в альтернативный сценарий.
Перечислены результаты и итоги успешного завершения альтернативных веток бизнес-процесса.
Описаны все отказные ветки бизнес-процесса
Описаны отказные ветки: события и результаты неуспешного завершения бизнес-процесса.
Отказные ветки должны учитывать альтернативные ветки, если таковые имеются: для каждой альтернативной ветки должен быть рассмотрен отказной путь.
Определены требования к отчетности на основе бизнес-процесса
Метрики, при помощи которых проектная команда определяет достижение целей проекта, должны быть частью отчетности.
В явном виде прописана бизнес-логика расчета метрик, необходимых для оценки эффектов проекта.
Определены требования к отчетности, запрашиваемые бизнес-заказчиками. Описаны необходимые отчеты: есть список с названием отчета и указаны метрики, которые необходимо включить в отчет.
Для каждого вычисляемого параметра в отчетности указана формула и бизнес-логика расчета.
В бизнес-процессе учтены действия и шаги, обеспечивающие получение данных для конкретной метрики/отчета.
Описание интеграций систем
Идентифицированы и описаны точки интеграции с внешними системами, или указано, что их нет.
Есть описание, на каком шаге процесса используется информация (данные), полученная из другой системы.
Есть описание, с какой целью в рамках бизнес-процесса используются данные из другой системы.
Данных, полученных в результате интеграции, достаточно для достижения целей бизнес-процесса / шага в рамках бизнес-процесса, для которого нужна информация из внешней системы.
Указана частота обмена данными (например, временной интервал или событие).
Дополнительные требования к описанию бизнес-процесса
Применять опционально: рекомендуем делать описание статусной модели, если бизнес-процесс состоит из более чем 7 этапов и включает 2 и более исполнителей.
Описана статусная модель бизнес-процесса, которая позволяет упростить понимание промежуточных результатов, возникающих в ходе выполнения процесса.
Статусная модель учитывает отказные и альтернативные ветки бизнес-процесса.
Указаны необходимые для бизнес-процесса роли и права доступа. Описана связь с операциями бизнес-процесса и указана информация, к которой должен иметь доступ пользователь (с точки зрения бизнес-логики).
Определены требования к мониторингу изменений: кто должен видеть историю изменений, на каком уровне детализации.
Прописан глоссарий. Определены все термины и сокращения, используемые в документе.
Требования непротиворечивы - нет ситуаций, когда одно требование противоречит другому.
Требования к сценариям использования
Использовать, когда заранее понятна ИТ-система, в рамках которой будет выполнена операция (шаг/этап бизнес-процесса), и есть представление о целевом поведении системы.
Обеспечена трассировка (связь) сценария использования и элемента бизнес-процесса. В явном виде показана взаимосвязь сценария и элемента бизнес-процесса, то есть указано, на каком шаге/этапе бизнес-процесса работает сценарий.
В случае осуществления бизнес-процесса в двух и более системах, в явном виде отражено, в какой системе выполняется сценарий.
В сценарии использования отражены конкретные действия пользователя и системы в рамках бизнес-процесса.
Описание сценария использования достаточно и атомарно для реализации. Нет необходимости искать дополнительную информацию, которая существенно повлияет на его реализацию, вне сценария.
Кто учился в автошколе, мог слышать от инструкторов, что ПДД написаны кровью. Так и наши чек-листы — это реакция на сорванные сроки и неэффективно потраченные бюджеты. За каждым пунктом одна или несколько «аварий». После внедрения в работу Чек-листа: «Проверка бизнес-требований на полноту и непротиворечивость», мы начали экономить от 15 до 30% от первоначально заявленного бюджета проекта, точность сроков реализации бизнес-требований приблизилась к 95%.
Надеюсь, эта статья будет вам полезна. Пишите в комментариях, что стоит добавить или удалить из чек-листа, мы постоянно улучшаем свои процессы и подходы.
P.S. Несмотря на то, что статью я пишу со своего аккаунта над чек-листом работало много людей: Валерия Навогорская, Анастасия Серегина, Александра Довбыш. Обратную связь, наставничество, полезным опытом поделились руководители ПГК Максим Елисеев, Антон Пантелеев и Александр Долгов.
