Автоматизация бизнес-процессов

Автоматизация не должна начинаться с выбора CRM, BPM-платформы или написания кода. Сначала нужно понять как процесс работает сейчас, кто принимает решения, где возникают задержки, какие данные используются и что должно считаться успешным результатом.

SoftTech рассматривает автоматизацию как инженерную задачу: формализуем процесс, выбираем подходящий способ реализации и только после этого определяем, нужен ли готовый продукт, интеграция существующих систем или заказная разработка.

Какие процессы имеет смысл автоматизировать

Хороший кандидат обычно имеет несколько признаков:

• повторяется регулярно;
• имеет понятный вход и результат;
• сотрудники выполняют одинаковые ручные действия;
• данные переносятся между таблицами, письмами и системами;
• заявки или задачи теряются между участниками;
• статус процесса приходится выяснять вручную;
• есть формализуемые правила принятия решений;
• требуется журнал действий;
• рост объёма операций приводит к пропорциональному росту ручной работы;
• ошибки можно классифицировать и обрабатывать по правилам.

Не каждый процесс стоит автоматизировать. Если он выполняется редко, постоянно меняется или ещё не сформирован, автоматизация может лишь быстрее воспроизводить хаос.

Сначала текущий процесс

До разработки фиксируем текущую модель:

1. что запускает процесс;
2. кто участвует;
3. какие данные нужны на каждом шаге;
4. где происходит ручной ввод;
5. где принимается решение;
6. какие исключения возникают;
7. где процесс ждёт внешнюю сторону;
8. какие документы формируются;
9. где хранится статус;
10. что считается завершением.

После этого становится видно, что действительно нужно менять.

Не вся автоматизация требует заказной разработки

Есть как минимум три базовых пути.

1. Готовый продукт

Если задача уже решена специализированным продуктом и он подходит по процессу, интеграциям и стоимости владения, рациональнее внедрить его, чем писать аналог с нуля.

В экосистеме SoftTech есть собственные продукты для конкретных задач — например семейство CTRL. Выбор продукта зависит от реального сценария, а не от желания любой процесс назвать «цифровизацией».

2. Интеграция существующих систем

Иногда основная проблема не в отсутствии ПО, а в том, что уже существующие ERP, WMS, CRM, сайт, оборудование или другие приложения не обмениваются данными.

Тогда основной слой проекта — интеграции и API, а не новая система целиком.

3. Заказная разработка

Заказная разработка оправдана, когда процесс действительно специфичен, готовые решения не покрывают его без чрезмерных компромиссов или требуется новый функциональный контур вокруг существующих систем.

Как выглядит целевая модель

После анализа формируется целевой процесс.

Он описывает:

• роли;
• статусы;
• переходы;
• правила;
• автоматические действия;
• ручные контрольные точки;
• исключения;
• уведомления;
• данные и источники истины;
• интеграции;
• журналирование;
• показатели результата.

Важно сохранить возможность ручного вмешательства там, где решение нельзя безопасно формализовать.

Пример: согласование заявки

Простейшая схема может выглядеть так:

создание → проверка данных → определение ответственного → согласование → исполнение → закрытие → отчёт.

Но реальный процесс обычно содержит:

• разные маршруты по сумме или типу заявки;
• замещение отсутствующего сотрудника;
• возврат на доработку;
• внешний документ;
• таймаут;
• эскалацию;
• отмену;
• аудит действий.

Именно обработка таких исключений отличает рабочую систему от красивой демонстрации на презентации.

Автоматизация между системами

Бизнес-процесс может проходить через несколько приложений.

Например:

• заявка создаётся в одном интерфейсе;
• клиент хранится в CRM;
• товар и цены — в ERP;
• остатки — в WMS;
• платёж подтверждается внешней системой;
• итоговый статус возвращается пользователю.

Тогда автоматизация требует не только интерфейса, но и корректной архитектуры обмена данными.

Данные и источник истины

Для каждой сущности определяется система, в которой хранится эталонное состояние данных.

Если клиент, товар, цена или статус могут независимо изменяться в нескольких системах, автоматизация быстро создаёт конфликты.

Поэтому проект должен ответить:

• где создаётся сущность;
• где хранится основной идентификатор;
• кто может менять критичные поля;
• как синхронизируются изменения;
• как обрабатываются конфликты;
• что происходит при временной недоступности одной из систем.

Исключения важнее идеального сценария

Автоматизация проектируется не только под штатное прохождение процесса.

Нужно заранее определить:

• неполные данные;
• дубли;
• отказ внешнего сервиса;
• отсутствие ответственного;
• просрочку;
• изменение решения;
• отмену операции;
• повторную отправку;
• ручное восстановление после сбоя.

Если исключения не описаны, их всё равно обработают — только уже сотрудники в Excel и мессенджерах.

Уведомления и эскалации

Автоматизация не должна превращаться в генератор бесконечных уведомлений.

Для каждого сообщения определяется:

• кому оно действительно нужно;
• какое действие ожидается;
• что происходит при отсутствии реакции;
• через какое время нужна эскалация;
• какие события достаточно оставить в журнале.

Контроль и наблюдаемость

После запуска важно понимать не только бизнес-статусы, но и состояние самой автоматизации.

В зависимости от архитектуры предусматриваются:

• журнал операций;
• журнал ошибок;
• метрики обработки;
• контроль очередей;
• уведомления о технических сбоях;
• трассировка критичных операций;
• отчёты по процессу.

Как измерять результат

Метрика должна быть согласована до разработки.

Это может быть:

• время прохождения процесса;
• количество ручных операций;
• число возвратов;
• доля просроченных задач;
• время до реакции;
• число ошибок ввода;
• прозрачность статуса;
• пропускная способность процесса.

SoftTech не обещает фиксированный процент экономии до анализа исходного процесса и наличия измеримой базы сравнения.

Собственные продукты как готовая автоматизация

Часть бизнес-задач уже покрывается CTRL-продуктами SoftTech.

Например:

• YMS CTRL — процессы двора и транспорта;
• PP&E CTRL — учёт и инвентаризация активов;
• QR CTRL — контроль конкретного технологического процесса розлива;
• Parking CTRL — парковочная сессия и связанные бизнес-правила;
• Mark CTRL — маркировка, партии, мобильное сканирование и исключения;
• другие CTRL-решения — для своих подтверждённых сценариев.

Если готовый продукт закрывает задачу, его имеет смысл рассмотреть раньше заказной разработки.

Посмотреть семейство CTRL →

Подтверждённая компетенция разработки

SoftTech Development поддерживает:

• разработку web-, mobile- и desktop-приложений;
• архитектуру;
• сложные интеграции;
• API, шины данных и ETL;
• тестирование и DevOps;
• наблюдаемость систем;
• поддержку и развитие;
• собственные программные продукты, автоматизирующие конкретные операционные процессы.

Кейсы Burger King Belarus и MOSTRA-GROUP подтверждают интеграционные задачи и специализированную автоматизацию, но детали бизнес-логики находятся под NDA и не раскрываются публично.

Где проходит граница

Автоматизация и интеграция

Интеграция отвечает за обмен между системами. Автоматизация описывает сам бизнес-процесс, его правила, статусы и действия. Интеграция может быть одним из слоёв автоматизации.

Автоматизация и корпоративный портал

Портал может быть пользовательским интерфейсом для процессов, но процесс может существовать и без отдельного портала.

Автоматизация и CRM/ERP/BPM/RPA

Эти классы решений могут быть инструментами реализации, но не являются автоматическим ответом на любой процесс. SoftTech не заявляет собственную универсальную BPM/RPA-платформу; внедрение конкретной CRM/ERP-системы предлагается только при отдельно подтверждённой компетенции и требованиях проекта.

Что не обещаем автоматически

• автоматизацию любого неформализованного процесса;
• фиксированный ROI;
• «сокращение ручного труда на X%» без измеримой исходной базы;
• универсальную BPM/RPA-платформу SoftTech;
• внедрение конкретной CRM/ERP без подтверждённой компетенции, совместимости и требований проекта;
• полное исключение человека из процесса;
• AI как обязательный компонент;
• интеграцию с системой без технического интерфейса без предварительного исследования.

Что подготовить для первичного разбора

Полезно описать:

• какой процесс необходимо изменить;
• что запускает процесс;
• кто участвует;
• какие системы используются сейчас;
• какие действия выполняются вручную;
• где возникают задержки или ошибки;
• какие исключения известны;
• какие документы и данные участвуют;
• примерный объём операций;
• какой результат нужно улучшить;
• есть ли измеримая исходная база.

После этого можно определить, нужен ли готовый продукт, интеграция, настройка существующей платформы или заказная разработка.

Обсудить автоматизацию процесса →

Компетенции группы в разработке программного обеспечения также представлены на SoftTech Development.