Подписывайтесь на наши каналы и паблики, оставайтесь на связи и получайте уведомления о последних статьях и новостях на нашем сайте.
Как подготовить компанию к автоматизации процессов
Разговор об автоматизации в компании часто начинается с вопроса о системе: какую платформу выбрать, сколько стоят лицензии и сколько времени займет внедрение.
Но выбор системы — далеко не первый вопрос, на который стоит ответить.
До начала автоматизации важно понять, как сегодня устроен процесс, который компания собирается переносить в цифровой контур: кто в нем участвует, как движется задача, где принимаются решения, какие данные передаются между сотрудниками и подразделениями, где возникают задержки, дублирование действий и потеря информации.
При этом опираться только на действующие регламенты или представление руководителя о процессе недостаточно. Реальный порядок работы может заметно отличаться от того, как он описан в документах или выглядит с позиции одного подразделения.
Поэтому подготовка к автоматизации начинается с исследования текущего процесса, определения его ограничений и только затем — проектирования будущей модели и требований к системе.
Что значит подготовить компанию к автоматизации
Подготовка — это управленческие решения, принятые до настройки системы. Автоматизация переносит в цифровой контур только те процессы, которые уже описаны и формализованы.
Готовность компании к проекту складывается из шести элементов:
- Процессы. Выбран короткий список сценариев для первого этапа, у каждого определены границы: где процесс начинается и каким результатом заканчивается.
- Роли и ответственность. У процесса есть владелец, у каждого этапа — исполнитель и согласующий. Права на просмотр и изменение данных описаны заранее.
- Данные. Понятно, какие справочники, карточки и документы участвуют в работе, где они хранятся и в каком виде.
- Исключения. Собраны нестандартные ситуации, операции и правила, которые подразделения трактуют по-разному.
- Интеграции. Определен список смежных систем, направление обмена и критичность каждой связки для запуска.
- Метрики. Согласованы показатели, по которым бизнес оценит результат через квартал после запуска.
Такой подход называют процессным управлением: компания рассматривает свою деятельность не как набор отдельных функций, а как систему сквозных процессов с ответственными владельцами и целевыми показателями. При этом для начала трансформации не требуется выстраивать сложную методологию — достаточно выбрать один значимый сценарий и довести его до рабочего состояния.
Какие процессы брать в автоматизацию первыми
Автоматизировать одновременно все процессы компании обычно не требуется. Важно определить, какие из них действительно нуждаются в изменениях и где автоматизация способна дать заметный результат.
При выборе можно учитывать несколько критериев.
Повторяемость и понятный маршрут. Процесс запускается регулярно, проходит через одни и те же роли и завершается предсказуемым результатом. К таким задачам относятся согласование договоров, обработка заявок, регистрация обращений и предоставление доступов.
Высокая ручная нагрузка.
Сотрудники переносят данные между таблицами и системами, вручную собирают статусы, напоминают коллегам о сроках, повторно вводят одну и ту же информацию.
Задержки, потери заявок и слабый контроль.
Руководителю сложно определить, где находится задача, почему она задержалась и кто отвечает за следующий шаг.
Большое количество участников.
Чем больше подразделений участвует в процессе, тем выше риск потери информации и разного понимания правил работы на точках передачи.
Влияние на выручку, сервис или скорость управления.
Приоритетными могут стать процессы, непосредственно влияющие на продажи, обслуживание клиентов, сроки согласований или качество управленческих решений.
Возможность измерить результат.
До начала изменений желательно определить показатели, по которым впоследствии можно сравнить состояние процесса до и после автоматизации.
При этом сама по себе высокая трудоемкость еще не означает, что процесс нужно немедленно автоматизировать. Сначала важно понять причины проблемы: иногда источник задержек находится не в отсутствии системы, а в распределении ответственности, правилах принятия решений или самом маршруте процесса.
Сначала понять, как работает процесс сейчас
Одна из распространенных ошибок при подготовке к автоматизации — сразу переходить к проектированию будущего процесса.
Чтобы определить, что именно необходимо изменить, сначала нужно получить достоверную картину As Is — фактического порядка работы.
Источниками информации могут быть регламенты, инструкции и существующие схемы процессов. Но этого недостаточно.
Важную часть информации дают интервью с участниками процесса. Причем представления разных сотрудников об одном и том же процессе могут заметно различаться.
Поэтому при исследовании текущего процесса важно зафиксировать:
- участников и их фактические роли
- последовательность действий
- точки передачи задач между сотрудниками и подразделениями
- входы и результаты каждого этапа
- используемые документы и данные
- информационные системы и ручные операции
- исключения и нестандартные сценарии
- существующие правила и реальные способы работы
- проблемные места и ограничения.
Полученная модель AS IS нужна не для того, чтобы автоматизировать существующий процесс «как есть». Ее задача — дать основание для проектирования будущей модели.
От As Is к будущему процессу
После исследования текущего состояния можно переходить к проектированию To Be- процесса, который компания хочет получить после изменений.
На этом этапе важно определить не только, какие действия должна выполнять система, но и что должно измениться в самом процессе.
Например:
- исключить дублирующие операции
- изменить последовательность этапов
- закрепить ответственность
- определить обязательные данные для передачи задачи
- установить условия перехода между этапами
- убрать лишние согласования
- определить контрольные точки
- установить необходимые сроки
- определить, какие операции выполняются автоматически, а какие остаются за сотрудниками.
Таким образом, требования к будущей системе появляются не из набора пожеланий пользователей, а из спроектированной модели процесса.
Именно эта последовательность позволяет избежать ситуации, когда сначала настраивается система, а затем компания пытается встроить в нее реальную работу сотрудников.
Как описать бизнес-процесс перед автоматизацией
Для последующего проектирования системы необходимо зафиксировать основные элементы будущего процесса.
Цель и результат.
Должно быть понятно, зачем существует процесс и каким результатом он заканчивается.
Участники и ответственность.
Для каждого этапа определяются роли, исполнители, зоны ответственности и необходимые права доступа.
Этапы и правила перехода.
Фиксируется последовательность действий, условия перехода между этапами, точки ветвления и параллельные сценарии.
Входы и выходы.
Для каждого этапа определяется, какую информацию или результат должен получить исполнитель и что должно появиться после выполнения его действий.
Исключения.
Необходимо учитывать не только стандартный маршрут, но и возвраты, отмены, срочные согласования, отсутствие ответственного, ошибки во входных данных и другие ситуации, возникающие в реальной работе.
Данные и интеграции.
Определяются необходимые данные, их источники, требования к качеству и системы, между которыми потребуется организовать обмен.
Метрики.
Показатели желательно определить до начала внедрения. Это позволит впоследствии оценить, изменился ли процесс после автоматизации.
Это могут быть срок прохождения процесса, количество просроченных этапов, число возвратов на доработку, объем ручных операций, конверсия между этапами, соблюдение SLA и другие показатели.
Что должно быть готово к началу автоматизации
| Что определено | Что это дает |
|---|---|
| Границы и цель процесса | Понимание объекта автоматизации |
| Модель текущего процесса As Is | Понимание фактического порядка работы и существующих ограничений |
| Перечень проблем и разрывов | Понимание того, что необходимо изменить |
| Модель будущего процесса To Be | Целевой порядок работы |
| Роли и зоны ответственности | Основание для настройки маршрутов и прав |
| Данные и интеграции | Понимание интеграционного контура |
| Функциональные требования | Основание для проектирования будущей системы |
| Метрики | Возможность оценить результат изменений |
Состав документов может отличаться в зависимости от масштаба проекта и сложности процессов. Главное, чтобы к началу внедрения у бизнеса и команды автоматизации было единое понимание будущего порядка работы.
Частые ошибки при подготовке к автоматизации
Проектирование только со слов руководителя.
Руководитель видит процесс на одном уровне, сотрудники — на другом. Без проверки информации у непосредственных участников часть реальной работы остается за пределами модели.
Автоматизация существующего процесса без анализа.
Если просто перенести действующий маршрут в систему, вместе с ним можно автоматизировать лишние согласования, дублирование операций и неэффективное распределение ответственности.
Смешение As Is и To Be.
При исследовании текущего процесса участники часто начинают рассказывать, как «должно быть». В результате вместо фактической картины получается смесь существующих и желаемых правил.
Неучтенные точки передачи.
Проблемы часто возникают не внутри отдельного подразделения, а между ними: один участник считает задачу переданной, другой — еще не принятой.
Неучтенные исключения.
Процесс, спроектированный только для стандартного сценария, быстро начинает обходиться сотрудниками вручную.
Требования к системе формируются как список пожеланий.
«Нужен отчет», «нужно уведомление», «хотим автоматическое согласование» — еще не функциональные требования. Сначала необходимо понять, какую задачу в будущем процессе должен решать этот функционал.
Метрики появляются после запуска.
Если исходные показатели не зафиксированы, объективно оценить эффект от автоматизации значительно сложнее.
Отсутствие владельца процесса.
Спорные решения зависают, команда внедрения ждет ответа от нескольких руководителей.
Как BPM-система помогает реализовать спроектированный процесс
Когда будущая модель процесса определена, можно переходить к выбору и настройке технологической платформы.
BPM-система BPMSoft — российская low-code платформа для моделирования, исполнения, контроля и последующей оптимизации бизнес-процессов, которую разработчик развивает вместе с прикладными решениями класса CRM, SRM, ITSM и HRM.
Платформенный подход позволяет связать в едином цифровом контуре роли, этапы, данные, правила переходов, задачи и контрольные показатели.
При этом бизнес-процессы продолжают меняться и после запуска системы. Появляются новые продукты, подразделения, правила работы и требования. Low-code инструменты позволяют вносить часть изменений без полного цикла разработки, подключая разработчиков для реализации более сложной логики и нестандартных интеграций.
Что делать, если компания еще не готова к автоматизации
Готовность компаний к внедрению может сильно различаться.
В одном случае заказчик уже понимает будущий процесс, роли, требования и ожидаемый результат. Тогда можно переходить к проектированию и внедрению системы.
В другом — разные подразделения по-разному представляют даже текущий порядок работы, а требования к будущей системе существуют в виде отдельных пожеланий. В такой ситуации начинать с технического проектирования преждевременно.
Поэтому в проектах OmniLine этапу автоматизации при необходимости предшествует процессный консалтинг.
На этом этапе исследуется текущая модель As Is, фиксируются роли, процедуры, маршруты движения задач и существующие разрывы, проектируется целевая модель To Beи формируются функциональные требования к будущей системе.
После этого можно переходить к проектированию и реализации решения на BPMSoft или другой выбранной платформе.
Так процессный консалтинг и автоматизация становятся последовательными этапами одной задачи: сначала определить, как должна работать компания, а затем — как технологически поддержать эту модель.
FAQ
С чего начать подготовку к автоматизации процессов?
С понимания текущего состояния. Необходимо определить границы исследуемого процесса, его владельца, участников и фактический порядок работы. После анализа AS IS можно определить необходимые изменения, спроектировать To Be и сформировать требования к автоматизации.
Обязательно ли описывать процессы перед автоматизацией?
Уровень детализации зависит от сложности проекта. Но команда внедрения должна понимать роли, этапы, данные, правила перехода и ожидаемый результат процесса. Для сквозных процессов с большим количеством участников предварительное исследование особенно важно.
Кто должен участвовать в описании процесса?
Не только руководитель или владелец процесса. Информацию необходимо получать и от сотрудников, непосредственно выполняющих операции, а для сквозных процессов — от представителей всех участвующих подразделений.
Зачем фиксировать As Is, если компания хочет его изменить?
Не для того, чтобы перенести существующий процесс в систему без изменений. As Is позволяет увидеть реальные маршруты работы, ограничения и разрывы и на этой основе обоснованно спроектировать To Be.
Как оценить результаты автоматизации?
По показателям, зафиксированным до начала изменений. Это могут быть сроки прохождения процесса, количество просрочек и возвратов, объем ручных операций, конверсия, соблюдение SLA и другие показатели, значимые для конкретного процесса.
Подписывайтесь на наши каналы и паблики, оставайтесь на связи и получайте уведомления о последних статьях и новостях на нашем сайте.
