Как стать автором
Обновить
89.67
Первая грузовая компания (ПГК)
Крупнейшая цифровая логистическая компания на ж/д

Как сэкономить четверть бюджета проекта внедрения с помощью чек-листа качества бизнес-требований

Время на прочтение7 мин
Количество просмотров4.9K

Привет, Хабр! Я Владимир Хрыпун, руководитель центра компетенций по развитию 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. Несмотря на то, что статью я пишу со своего аккаунта над чек-листом работало много людей: Валерия Навогорская, Анастасия Серегина, Александра Довбыш. Обратную связь, наставничество, полезным опытом поделились руководители ПГК Максим Елисеев, Антон Пантелеев и Александр Долгов.

Теги:
Хабы:
+1
Комментарии3

Публикации

Информация

Сайт
pgk.ru
Дата регистрации
Дата основания
Численность
1 001–5 000 человек
Местоположение
Россия