Аудит бизнес-процессов
Проверенная картина текущей работы с причинами затруднений, границами процессов и приоритетами изменений.
РЕШЕНИЯ KERUB SYSTEMS
Когда порядок работы хранится в переписке и памяти сотрудников, новая CRM сама по себе не создаёт управляемый процесс. Сначала нужно договориться, какой результат компания должна получать, кто за него отвечает и что происходит при отклонениях.
KERUB SYSTEMS помогает описать текущую работу, спроектировать целевую модель и перевести её в требования к цифровой системе. Выберите направление по тому вопросу, который сейчас мешает двигаться дальше.
Если участники по-разному объясняют один и тот же процесс, начните с его описания: нужно увидеть реальные действия и передачи ответственности. Если порядок уже понятен, но результат нестабилен, полезнее аудит конкретных причин потерь. Проектирование нужно тогда, когда компания готова определить будущую схему работы.
Эти результаты связаны, но не взаимозаменяемы. Карта текущего процесса не заменяет решения о том, как он будет устроен после изменения. Регламент не заменяет работающий обмен данными, а техническое задание не определяет за владельца бизнеса приоритеты.
| Ситуация | С чего начать | Первый результат |
|---|---|---|
| Нет общей картины работы | Описание и моделирование | Согласованная карта процесса |
| Понятен процесс, видны потери | Аудит и оптимизация | Причины и порядок изменений |
| Нужна новая схема работы | Проектирование | Роли, правила и целевой сценарий |
| Решения приняты, нужна реализация | Техническое задание | Проверяемые требования к системе |
Для проектирования выбирают границы: какое событие запускает процесс и по какому факту он считается завершённым. Между ними описывают участников, необходимые данные, условия решений и точки контроля. Отдельно разбирают ситуации, которые нельзя обработать автоматически.
Пример: заказ согласован, но нужного материала нет в наличии. В целевой модели появляется не просто дополнительный статус. Определяются ответственный за замену, допустимые варианты, порядок согласования с клиентом и сигнал о необходимости изменить срок. Такой уровень конкретики позволяет затем проверить работу системы.
Достаточно выбрать один повторяющийся процесс, назвать участников и используемые сервисы, показать обезличенный пример обычного и проблемного обращения. Полный комплект документов на старте не обязателен: недостающие сведения можно определить в ходе обследования.
Объём работы согласуется по числу связанных процессов, ролей, правил и систем. Сроки зависят также от доступности исходных данных и скорости принятия решений. Итог должен быть пригоден для внедрения: из него понятно, что меняется в работе компании и как проверить результат.
Проверенная картина текущей работы с причинами затруднений, границами процессов и приоритетами изменений.
Согласованная целевая модель процесса, которую можно внедрять организационно и переводить в требования к системе.
Согласованная модель фактических процессов, пригодная для передачи знаний, анализа и подготовки изменений.
Целевая версия процесса с обоснованными изменениями, условиями перехода и проверкой выбранных показателей.
Согласованные регламенты, которые объясняют исполнение процесса, передачу результата и действия при отклонениях.
Связанная модель управления с владельцами процессов, рабочими правилами, показателями и последовательностью внедрения.
Целевая операционная модель с распределением функций, полномочий, правил взаимодействия и требований к данным.
Согласованное техническое задание с функциональными требованиями, зависимостями и проверяемыми сценариями приёмки.
Целевая архитектура систем и данных с обоснованными границами, правилами взаимодействия и последовательностью изменений.
Результат стартовой работы — обоснованный выбор первого процесса, границы этапа, требования к исходным данным и критерии результата.
Опишите, что происходит сейчас, какие сервисы используются, что сотрудники делают вручную и что должно происходить автоматически.