Портал без описания процессов — это дорогая импровизация
Компания начинает внедрение корпоративного портала. Руководитель ставит задачу: «Нам нужен портал с согласованием заявок, базой знаний и новостями». Разработчики приступают к работе. Через три месяца выясняется: согласование заявок реализовано не так, как работает реальный процесс в компании, база знаний не учитывает, кто и как ведёт документы, а «новости» — это на самом деле три разных типа публикаций с разными правилами.
Переделки, дополнительные итерации, рост бюджета и сроков. Знакомая история.
Причина почти всегда одна: портал начали делать раньше, чем разобрались, как работает бизнес, который этот портал должен обслуживать. Описание бизнес-процессов перед началом разработки — это не бюрократия и не лишний этап. Это фундамент, без которого всё остальное строится на песке.
Почему важно описывать бизнес-процессы заранее
Единое понимание задачи
У заказчика, аналитика и разработчика в голове могут быть три разных представления о том, как должен работать один и тот же процесс. Пока это не зафиксировано на бумаге — каждый работает по своей версии и уверен, что понимает задачу правильно.
Документация процессов создаёт единое пространство понимания. Все стороны видят одно и то же описание — и могут выявить расхождения до начала разработки, а не в момент приёмки.
Снижение рисков ошибок
Ошибка, обнаруженная на этапе описания процессов, исправляется за несколько часов. Та же ошибка, обнаруженная в готовом коде, — за несколько недель. Разница в стоимости исправления измеряется порядками.
Качественное описание процессов позволяет выявить противоречия в требованиях, нереалистичные ожидания и технически сложные места до того, как на них потрачены ресурсы разработки.
Прозрачность требований
Разработчики реализуют то, что описано. Если описание неполное — они реализуют своё понимание. Если описание противоречивое — принимают решение сами, не всегда правильно.
Подробное описание процессов даёт разработчикам однозначные ориентиры: какие сценарии поддерживать, какие бизнес-правила учитывать, какие исключения предусматривать.
Ускорение разработки
Это кажется нелогичным: трата времени на описание процессов замедляет старт. На практике всё иначе. Разработчики, которые получили детальное описание, движутся быстро и прямо. Разработчики, которые начали без описания, постоянно останавливаются на уточнениях, переделках и «а как должно быть в этом случае».
Что включает описание бизнес-процессов
Текущая модель — «как есть»
Прежде чем проектировать, как будет работать портал, нужно понять, как работает бизнес сейчас. Даже если текущий процесс несовершенен — его нужно зафиксировать. Именно в нём скрыты детали, исключения и неформальные правила, которые никто не описывал, но все соблюдают.
Типичный пример: процесс согласования командировки. На бумаге — сотрудник подаёт заявку, руководитель согласует. На практике: заявку сначала согласовывает непосредственный руководитель, потом административный отдел проверяет даты и бюджет, потом финансовый директор подтверждает при сумме выше определённого порога. Плюс есть исключения для выездов в определённые регионы и для отдельных категорий сотрудников.
Всё это нужно зафиксировать — иначе портал реализует упрощённую схему, которая не будет работать в реальных условиях.
Целевая модель — «как будет»
После того как текущий процесс зафиксирован, формируется целевая модель: как процесс должен работать после автоматизации. Это не просто «перенести текущий процесс в систему» — это возможность улучшить его: убрать лишние шаги, автоматизировать рутинные действия, сократить время согласования.
Целевая модель — это техническое задание для разработки, выраженное на языке бизнеса.
Роли участников
Каждый процесс имеет участников с разными функциями: кто инициирует, кто выполняет, кто согласует, кто контролирует, кто получает результат. Роли фиксируются явно — это основа для настройки прав доступа и маршрутизации задач в портале.
Точки контроля
В каждом процессе есть места, где нужно остановиться и проверить: всё ли в порядке, можно ли двигаться дальше. Это контрольные точки — этапы, на которых система запрашивает подтверждение или уведомляет ответственного. Их нужно определить заранее и заложить в архитектуру процесса.
Как подготовить описание процессов для внедрения портала
Сбор требований от бизнеса
Начните с владельцев процессов — людей, которые несут ответственность за результат. Они знают, что должно получиться. Затем — участников процессов, которые работают с ним ежедневно. Они знают, как это работает на самом деле.
Не полагайтесь на одного человека. Разные участники процесса видят его по-разному — и это нормально. Задача аналитика — собрать все точки зрения и свести их в единую непротиворечивую картину.
Интервью с участниками процессов
Анкеты и опросники дают поверхностную картину. Живые интервью позволяют задать уточняющие вопросы, выявить детали, которые люди не додумались написать сами, и обнаружить противоречия между тем, что описывают разные участники.
Хорошее интервью — это не перечень вопросов, а разговор о том, как человек работает. «Расскажи, как ты это делаешь» даёт больше полезной информации, чем «какие требования к системе». Системная аналитика на этом этапе — ключевая компетенция, которая определяет качество всех последующих этапов.
Фиксация сценариев
Каждый процесс имеет основной сценарий и ряд альтернативных — исключений, нестандартных ситуаций, аварийных путей. Все они должны быть зафиксированы.
Типичная ошибка: описать только основной сценарий и забыть об исключениях. Потом оказывается, что исключений — 30% случаев, и система не умеет их обрабатывать.
Построение моделей процессов
Текстовое описание полезно, но недостаточно. Схема процесса — диаграмма с последовательностью шагов, ветвлениями и ролями участников — позволяет увидеть процесс целиком и быстро выявить противоречия или пропуски.
Для корпоративных порталов хорошо работают нотации, описывающие последовательность действий и ответственных. Сложность схем должна соответствовать сложности процессов: не усложнять простое и не упрощать сложное.
Подробнее о том, как выстроить работу с требованиями на проектах внедрения, мы писали в материалах библиотеки Extyl.
Практические советы
Как избежать типичных ошибок
Не описывайте «как должно быть в идеале» вместо «как есть». Идеальный процесс на бумаге и реальный процесс в компании — разные вещи. Система, автоматизирующая идеальный процесс, не будет работать там, где живут реальные исключения.
Не пытайтесь описать всё и сразу. Начните с ключевых процессов, которые должен поддерживать портал на первом этапе. Полнота описания важна, но не за счёт скорости старта.
Согласовывайте описание с разными участниками. Документ, который согласовал только один руководитель, может содержать ошибки, которые обнаружат рядовые сотрудники при первом же использовании системы.
Как сделать описание понятным для разработчиков
Хорошее описание процесса для разработчика — это не академический текст, а практическое руководство: что происходит, кто это делает, при каких условиях, что происходит дальше. Минимум теории, максимум конкретики.
Схемы процессов должны читаться без пояснений. Если схему нужно долго объяснять — она сделана неправильно.
Бизнес-правила — отдельным списком. Не «как правило, согласует руководитель», а «согласует непосредственный руководитель; при его отсутствии — замещающий, указанный в кадровой системе; при сумме свыше 100 000 рублей — дополнительно финансовый директор».
Как связать процессы с функциональностью портала
Каждый шаг процесса должен иметь явное соответствие в функциональности системы: какой экран, какое действие, какие данные вводятся или отображаются. Это связующее звено между описанием бизнеса и техническим заданием на разработку.
Разработка и внедрение корпоративных порталов компанией Extyl начинается именно с этого этапа: прежде чем проектировать систему, мы разбираемся, как работает бизнес заказчика.
Описание процессов — это инвестиция, которая окупается
Качественное описание бизнес-процессов перед автоматизацией — это не дополнительный этап, который удлиняет проект. Это инвестиция, которая сокращает общее время проекта, снижает количество переделок и повышает вероятность того, что система заработает так, как ожидал бизнес.
Моделирование бизнес-процессов создаёт общий язык между бизнесом и разработкой. Оно делает требования прозрачными, риски видимыми, а результат — предсказуемым.
Компании, которые пропускают этот этап в погоне за скоростью, как правило, тратят на переделки больше времени, чем заняло бы качественное описание с самого начала.
Участие опытных аналитиков на этапе описания и моделирования процессов — один из ключевых факторов успеха проекта. Аналитик умеет задавать правильные вопросы, структурировать ответы и переводить бизнес-логику на язык требований, понятных разработчикам.
