Управление требованиями: как не потерять суть процесса при автоматизации
В прошлых материалах мы разобрали, почему нельзя автоматизировать бардак, как подготовиться к внедрению и зачем описывать процесс в BPMN. Но есть ещё один слой, который часто пропускают. Даже если процесс описан, а данные почищены, автоматизация может пойти не туда. Причина — требования. Точнее, их отсутствие, размытость или потеря связи с реальным процессом.
Что такое требование и чем оно отличается от хотелки
Требование — это формализованное описание того, что система должна делать, вытекающее из процесса и потребностей бизнеса. Хотелка — это «сделайте красиво» или «как у конкурентов».
Пример:
- Хотелка: «Хотим удобный интерфейс для закупщика».
- Требование: «Закупщик должен видеть все заявки, срок согласования которых истекает сегодня, и иметь возможность отправить напоминание согласующему в один клик».
Требование проверяемо. Хотелку нельзя проверить.
Классификация, которая помогает не утонуть:
Функциональные — что система делает. «Система должна автоматически создавать заявку на основе данных MRP». «Система должна поддерживать параллельное согласование».
Нефункциональные — как делает. «Время отклика при поиске позиции — не более 2 секунд». «Система должна поддерживать 50 одновременных пользователей».
Бизнес-правила — ограничения из процесса. «Заявка на сумму свыше 100 000 рублей требует согласования финансового директора». «Закупка у единственного поставщика допускается только при наличии обоснования».
Требования к данным — что должно быть в справочниках. «Код материала обязателен для всех позиций, кроме услуг». «Единица измерения выбирается из справочника, а не вводится вручную».
Если вы описали процесс в BPMN, многие требования уже видны: шлюзы становятся бизнес-правилами, дорожки — ролями и правами доступа, задачи — функциями системы.
Почему теряется суть процесса
Три главные причины.
1. требования собирают с менеджеров, а не с исполнителей. Руководитель скажет, как должно быть, но не всегда знает, как есть на самом деле. Закупщик расскажет, где реально застревает заявка. Спрашивайте всех, кто участвует в процессе.
2. требования пишут «на будущее», а не под текущий процесс. «Давайте сразу заложим возможность тендеров на 10 этапов». В итоге система становится сложной, а текущий процесс — не поддерживается. Сначала автоматизируйте то, что есть. Потом расширяйте.
3. требования не проверяют на полноту и непротиворечивость. Один отдел просит одно, другой — противоположное. Если это не выявить до внедрения, система будет метаться или не работать вовсе.
Как собирать требования: практический подход
Шаг 1. Возьмите процесс «как должно быть». Это ваша основа. Каждый шаг процесса — потенциальное требование.
Шаг 2. Проведите интервью с исполнителями. Не один общий воркшоп, а отдельно с каждой ролью. Вопросы:
- Что вы делаете на этом шаге?
- Какие данные вводите, откуда берёте?
- Что вас замедляет или раздражает?
- Что будет, если этот шаг не сделать?
- Как вы понимаете, что всё готово?
Шаг 3. Зафиксируйте требования в едином реестре. Формат простой:
Смотри рисунок.
Шаг 4. Проверьте на полноту. Пройдитесь по процессу и убедитесь, что для каждого шага есть требования. Не забудьте про исключения: возврат, отказ, срочная закупка, отмена.
Шаг 5. Согласуйте с участниками. Требования должны быть понятны и приняты теми, кто будет работать в системе. Иначе саботаж.
Шаг 6. Передайте вендору и проверьте. Не отдавайте требования «как есть» и не ждите, что вендор сам разберётся. Проговорите, как он их реализует. Попросите демонстрацию по каждому пункту.
Типичные ошибки
- Требования без приоритетов. Всё «важно». В итоге либо не делают ничего, либо делают всё, но плохо.
- Требования без критериев приёмки. Как понять, что требование выполнено? «Система должна быть удобной» — не критерий.
- Требования, которые противоречат процессу. Если процесс изменился, требования нужно обновить. Реестр — живой документ.
- Игнорирование нефункциональных требований. Производи
В прошлых материалах мы разобрали, почему нельзя автоматизировать бардак, как подготовиться к внедрению и зачем описывать процесс в BPMN. Но есть ещё один слой, который часто пропускают. Даже если процесс описан, а данные почищены, автоматизация может пойти не туда. Причина — требования. Точнее, их отсутствие, размытость или потеря связи с реальным процессом.
Что такое требование и чем оно отличается от хотелки
Требование — это формализованное описание того, что система должна делать, вытекающее из процесса и потребностей бизнеса. Хотелка — это «сделайте красиво» или «как у конкурентов».
Пример:
- Хотелка: «Хотим удобный интерфейс для закупщика».
- Требование: «Закупщик должен видеть все заявки, срок согласования которых истекает сегодня, и иметь возможность отправить напоминание согласующему в один клик».
Требование проверяемо. Хотелку нельзя проверить.
Классификация, которая помогает не утонуть:
Функциональные — что система делает. «Система должна автоматически создавать заявку на основе данных MRP». «Система должна поддерживать параллельное согласование».
Нефункциональные — как делает. «Время отклика при поиске позиции — не более 2 секунд». «Система должна поддерживать 50 одновременных пользователей».
Бизнес-правила — ограничения из процесса. «Заявка на сумму свыше 100 000 рублей требует согласования финансового директора». «Закупка у единственного поставщика допускается только при наличии обоснования».
Требования к данным — что должно быть в справочниках. «Код материала обязателен для всех позиций, кроме услуг». «Единица измерения выбирается из справочника, а не вводится вручную».
Если вы описали процесс в BPMN, многие требования уже видны: шлюзы становятся бизнес-правилами, дорожки — ролями и правами доступа, задачи — функциями системы.
Почему теряется суть процесса
Три главные причины.
1. требования собирают с менеджеров, а не с исполнителей. Руководитель скажет, как должно быть, но не всегда знает, как есть на самом деле. Закупщик расскажет, где реально застревает заявка. Спрашивайте всех, кто участвует в процессе.
2. требования пишут «на будущее», а не под текущий процесс. «Давайте сразу заложим возможность тендеров на 10 этапов». В итоге система становится сложной, а текущий процесс — не поддерживается. Сначала автоматизируйте то, что есть. Потом расширяйте.
3. требования не проверяют на полноту и непротиворечивость. Один отдел просит одно, другой — противоположное. Если это не выявить до внедрения, система будет метаться или не работать вовсе.
Как собирать требования: практический подход
Шаг 1. Возьмите процесс «как должно быть». Это ваша основа. Каждый шаг процесса — потенциальное требование.
Шаг 2. Проведите интервью с исполнителями. Не один общий воркшоп, а отдельно с каждой ролью. Вопросы:
- Что вы делаете на этом шаге?
- Какие данные вводите, откуда берёте?
- Что вас замедляет или раздражает?
- Что будет, если этот шаг не сделать?
- Как вы понимаете, что всё готово?
Шаг 3. Зафиксируйте требования в едином реестре. Формат простой:
Смотри рисунок.
Шаг 4. Проверьте на полноту. Пройдитесь по процессу и убедитесь, что для каждого шага есть требования. Не забудьте про исключения: возврат, отказ, срочная закупка, отмена.
Шаг 5. Согласуйте с участниками. Требования должны быть понятны и приняты теми, кто будет работать в системе. Иначе саботаж.
Шаг 6. Передайте вендору и проверьте. Не отдавайте требования «как есть» и не ждите, что вендор сам разберётся. Проговорите, как он их реализует. Попросите демонстрацию по каждому пункту.
Типичные ошибки
- Требования без приоритетов. Всё «важно». В итоге либо не делают ничего, либо делают всё, но плохо.
- Требования без критериев приёмки. Как понять, что требование выполнено? «Система должна быть удобной» — не критерий.
- Требования, которые противоречат процессу. Если процесс изменился, требования нужно обновить. Реестр — живой документ.
- Игнорирование нефункциональных требований. Производи
Просмотры: 4