Вопрос «кто, что и когда должен сделать» звучит на каждом втором проекте по автоматизации — и почти всегда оказывается, что ответ у компании есть, но живёт он в головах сотрудников, а не в системе. На портале cio-navigator.ru вышел разбор «Workflow: кто, что и когда должен сделать? Как работает рабочий поток и чем отличается от BPM», где эта тема разложена от определения до конкретных классов решений. Ниже — наш пересказ ключевых мыслей и несколько практических замечаний для тех, кто сейчас выбирает инструмент.
Рабочий поток: что это и зачем формализовать очевидное
Workflow в переводе с английского — «поток работ». В ИТ так называют заранее описанную последовательность действий, через которую проходит задача или документ. Регистрация письма, определение ответственного, рассмотрение, подготовка ответа, согласование, отправка — это и есть маршрут.
Пока маршрут не формализован, процесс держится на людях: кто-то помнит, кому передать заявку, кто-то вручную сверяет сроки. Ушёл сотрудник в отпуск — процесс встал. Формализованный рабочий поток убирает эту зависимость: система сама передаёт задачу дальше, фиксирует статус и результат каждого этапа.
Важный смысловой сдвиг, о котором говорится в материале: бизнес переходит от управления людьми к управлению процессами. Человек здесь — один из ресурсов наряду с оборудованием, деньгами, данными и информационными системами. Поэтому если согласование договора вечно буксует, вопрос не только к конкретному менеджеру: возможно, маршрут построен неправильно или согласований просто слишком много.
Workflow и BPM: где проходит граница
Эти понятия часто путают, и на переговорах с вендорами это дорого обходится. Workflow — конкретный исполняемый поток работ. BPM (Business Process Management) — более широкая концепция: моделирование, автоматизация, исполнение, мониторинг, анализ и улучшение процессов. Рабочий поток — часть BPM, а не его синоним.
Практическая разница видна в деталях, которые редко попадают в презентации:
- Экземпляры процесса. Схема — это модель. Каждое новое письмо или заявка порождает отдельный экземпляр: один уже закрыт, второй на согласовании, третий только зарегистрирован.
- Версионность. Регламент поменялся — выпускается версия 2.0. Но экземпляры, запущенные по версии 1.0, обязаны доработать по старым правилам. Иначе процесс посреди пути получит новый этап согласования, и результат станет непредсказуемым.
- Состояния версий. Черновик, тестирование, согласование, продуктивная, устаревшая. В крупных организациях это связывают с практиками CI/CD: новая версия проходит разработку и тест, затем уходит в продуктив.
На практике первым ломается именно версионность. Нарисовать схему можно и в бесплатном редакторе, а вот корректно провести изменение регламента без остановки текущих процессов — задача уже для платформы.
Где рабочий поток окупается быстрее всего
Правило простое: маршрутизация нужна там, где задача проходит несколько этапов и нескольких участников. В обзоре выделены три классических контура.
Документы
Договор идёт от инициатора через юридическую и финансовую службы к руководителю, затем на подпись и контрагенту. Так же обрабатываются письма, счета, акты, техническая документация, распоряжения. Инструменты — СЭД и ECM, а если речь о корпоративном контенте в целом, включая публикацию и совместную работу, — CSP-платформы.
Заявки и обращения
Заявка на замену оборудования может последовательно пройти через Service Desk, системного администратора, службу безопасности и закупки. Исполнителю не нужно знать весь маршрут — он видит свой шаг. Здесь работают Service Desk и ITSM, а при распространении подхода на HR, закупки и АХО — ESM. Методологическая рамка вроде ITIL помогает договориться, как классифицировать и закрывать типы обращений.
Клиенты и продажи
Лид поступает в систему, квалифицируется, назначается менеджеру, двигается по воронке. В сложных сделках подключаются технический специалист, юрист, финансы, безопасность. Основной инструмент — CRM.
Как выбирать: от лёгких конструкторов до BPM-платформ
В материале решения разделены на три группы, и это удобная рамка для короткого списка.
Первая — инструменты для работы с рабочими маршрутами. Сюда отнесены open-source-набор для моделирования в нотации BPMN, российская платформа автоматизации рабочих процессов и решение, стоящее уже на границе с полноценной BPM. Оговорка важная: редактор диаграмм сам по себе ничего не исполняет — модель либо становится документацией, либо уходит в процессный движок.
Вторая — полноценные BPM-системы. В обзоре разобраны четыре российские платформы, где маршрутизация задач лишь один из механизмов, а рядом стоят управление версиями, роли и права, справочники, интеграции и мониторинг. Третья — зарубежные продукты, которым ищут замену: процессный движок для разработчиков, корпоративная платформа Workflow-приложений, low-code инструмент интеграции приложений и две комплексные платформы автоматизации.
Мы советуем начинать выбор не с демо, а с честного ответа на вопрос о масштабе. Если в компании три-пять повторяющихся маршрутов и нет сквозных процессов между подразделениями — тяжёлая платформа избыточна, её возможности останутся неоплаченным резервом. Если процессов десятки и они пересекают отделы, лёгкий конструктор довольно быстро упрётся в отсутствие версий и нормального контроля исполнения.
С чего начать
Главное, что стоит забрать из разбора: workflow — это не про софт, а про проектирование. Сначала вы рисуете маршрут, определяете этапы, ответственных, сроки и условия перехода, и только потом переносите его в систему. Обратный порядок даёт автоматизированный хаос.
Рекомендуем начать с одного регулярного процесса, который пересекает два-три подразделения и заметно тормозит, — описать его как алгоритм и посмотреть, сколько шагов реально нужно. Уже на этой стадии обычно выясняется, что часть согласований можно убрать без всякой автоматизации. А полный текст с разбором этапов создания рабочего потока и списком платформ доступен на портале.