Программа не исправит противоречивые правила сама. Если данные расходятся, а нестандартные случаи держатся в памяти сотрудников, новая система лишь добавит ещё одно место для работы.
Поэтому перед CRM, ERP, личным кабинетом или интеграцией полезно провести ограниченный аудит. Его глубина зависит от цены ошибки, числа ролей и систем. Для одного отдела может хватить нескольких интервью и карты процесса. На предприятии потребуется описать связанные процессы, данные и порядок внедрения.
Когда аудит особенно полезен
- одну операцию сотрудники описывают по-разному;
- руководитель получает статус из ручного отчёта;
- данные повторно вводят в несколько программ;
- готовой системой пользуются частично, а основная работа остаётся в таблицах;
- команда составила большой список функций, но не определила первую пользу;
- предыдущее внедрение не прижилось и причины не зафиксированы.
Аудит не обязательно заканчивается заказной разработкой. Результатом может стать настройка действующего продукта, изменение регламента, очистка справочника, небольшая интеграция или решение пока ничего не автоматизировать.
Шаг 1. Определите вопрос и границы
Формулировка «провести аудит компании» слишком широкая. Начните с решения, которое нужно принять: как перестать терять обращения; как обещать срок с учётом ресурсов; где возникает расхождение остатков; почему сотрудники повторно вводят документы; какой процесс войдёт в первую версию системы.
Затем зафиксируйте начало и конец процесса, роли, подразделения, географию и период данных. Отдельно перечислите то, что не входит. Граница защищает работу от бесконечного расширения и позволяет назвать проверяемый результат.
Шаг 2. Попросите показать работу на примерах
Интервью нужны, но человек обычно описывает нормальный сценарий и пропускает привычные обходы. Просите показать реальную заявку, документ, таблицу, экран программы и последний сложный случай. Смотрите, где сотрудник ждёт, копирует, уточняет, исправляет и обращается к личной записи.
Для каждой роли полезно записать: что запускает работу, какие данные получает человек, что проверяет, какое решение принимает, что создаёт, кому передаёт результат и как понимает, что этап завершён. Отдельно собирайте исключения: срочное изменение, отсутствие данных, возврат, отмена, дубль и недоступность внешней системы.
Схема считается проверенной, когда будущий пользователь узнаёт в ней реальную работу, включая неудобные и редкие случаи.
Шаг 3. Разберитесь в причине проблемы
Долгий отчёт может быть следствием не отсутствия панели, а разных определений статуса. Повторный ввод — следствием того, что системы не договорились о главном источнике. Просрочка — следствием обещания срока до проверки ресурсов. Для каждой проблемы задавайте вопрос «почему» до тех пор, пока решение не перестанет быть просто новым экраном.
Оцените потери по доступным данным: время ожидания, число ручных операций, ошибки, возвраты, обращения без ответа, отклонение плана, стоимость исправления. Если точных цифр нет, заранее договоритесь, как измерить текущее состояние до внедрения.
Шаг 4. Спроектируйте будущий порядок
Не переносите текущую схему в программу один к одному. Отделите обязательные юридические и операционные правила от привычек. Уберите лишнюю передачу, определите владельца каждого статуса и поля, согласуйте главный источник данных и действия при конфликте.
Будущий процесс должен отвечать на вопросы: кто выполняет действие; какие данные видит и меняет; что обязательно; что происходит при ошибке; кому приходит уведомление; какое действие можно отменить; что записывается в историю; как проверить результат.
Шаг 5. Выберите первую очередь
Первая версия должна решать одну задачу для ограниченной группы сотрудников. Выберите участок с заметной пользой, доступными данными, ответственным владельцем и группой пользователей, готовых проверять решение. Сложность интеграций и возможность безопасно вернуться к прежнему процессу важны не меньше ожидаемого эффекта.
До разработки сформулируйте критерии приёмки обычным языком: диспетчер создаёт рейс без повторного ввода; менеджер видит обращения без следующего действия; клиент получает документ без звонка; руководитель видит план и факт из одного источника.
Что должно остаться после аудита
- цель, границы и участники;
- карта текущего процесса и исключений;
- данные, документы, системы и владельцы;
- проблемы с причинами и доступной оценкой потерь;
- будущий процесс и согласованные правила;
- первая очередь, требования и критерии приёмки;
- риски, зависимости и план внедрения.
В MAXGROUP это оформляется как отдельная услуга бизнес-аналитики перед автоматизацией. Результаты можно передать другой команде или продолжить с нами разработку рабочей системы.
Итог
После аудита команда одинаково понимает проблему, будущий порядок и состав первого этапа. Ограничьте вопрос, проверьте процесс по реальным следам, найдите причины, договоритесь о данных и выберите первую очередь с измеримым результатом. Только после этого список функций становится основанием для разработки.