Управление бизнес-процессами: как построить систему, которая работает после окончания проекта

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

По определению Gartner, которое приводит IBM, BPM применяет методы обнаружения, моделирования, анализа, измерения, улучшения и оптимизации бизнес-стратегии и процессов. Ключевые слова здесь — «измерения» и «улучшения»: дисциплина предполагает, что за процессом кто-то регулярно наблюдает и что-то с ним делает. Ниже — методика целиком: цикл управления, разграничение понятий, AS IS, TO BE, роль владельца процесса и связь модели с информационной системой.

Цикл BPM и границы дисциплины

IBM в материале сентября 2021 года описывает жизненный цикл BPM как пять этапов: проектирование, моделирование, исполнение, мониторинг, оптимизация. Цикл замкнут — результат мониторинга возвращается в проектирование, и этим управление процессами отличается от разового обследования с приёмочным актом. У каждого этапа свой артефакт: паспорт процесса, модель с матрицей ответственности, регламент, разбор отклонений, портфель изменений.

Там же зафиксированы два разграничения. BPM — не управление задачами: task management смотрит на отдельную задачу и её исполнителя, процессное управление — на повторяемую последовательность и на то, что происходит между задачами: ожидания, передачи, возвраты. BPM — не проектное управление: проект даёт уникальный результат один раз, процесс повторяется сотни раз в год, и сокращение шага на два часа превращается в сотни часов ежегодно.

IBM выделяет три типа BPM: integration-centric (процессы идут между системами почти без участия человека), human-centric (решения принимают люди, система маршрутизирует и контролирует) и document-centric (ядро процесса — документ и его жизненный цикл). Договорной контур производственного предприятия относится ко второму и третьему типу, связка «планирование — производство — отгрузка» — к первому, и требования к системе здесь разные.

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

Процесс, функция, процедура, проект

Совещание, где под «процессом закупки» один понимает работу отдела снабжения, второй — маршрут согласования заявки, третий — регламент, заканчивается ничем.

Понятие	Что это	Ключевой признак	Кто отвечает
Бизнес-процесс	Повторяемая последовательность, преобразующая вход в результат для потребителя	Событие входа, результат, измеримые срок и качество	Владелец процесса
Операция (шаг)	Минимальная единица работы с исполнителем, входом и выходом	Не делится между двумя ролями	Исполнитель
Функция	Вид деятельности подразделения: снабжение, учёт, техподготовка	Отвечает на «что делает подразделение», а не «как получается результат»	Функциональный руководитель
Процедура	Документ о порядке выполнения процесса	Форма фиксации, а не объект управления	Владелец процесса
Проект	Разовый объём работ с уникальным результатом	Не повторяется в той же форме	Руководитель проекта

Процесс и функция пересекаются, но не совпадают. «Снабжение» — функция; «от возникновения потребности до оприходования материала на склад» — процесс, проходящий через планирование, снабжение, склад, бухгалтерию и производство. К функции задают вопросы про компетенцию и загрузку, к процессу — про срок и стоимость.

Процессное и функциональное управление

Спор «процессный подход против функционального» бесполезен: работающая структура содержит оба измерения. Вертикаль отвечает за ресурс — людей, квалификацию, стандарты, оборудование; горизонт — за результат, создаваемый при пересечении вертикалей. Проблема возникает, когда горизонт никем не представлен: снабжение оптимизирует цену закупки, производство — загрузку оборудования, продажи — объём заказов; локальные показатели улучшаются, сквозной срок и запасы растут, и предъявить это некому.

McKinsey в работе о следующем поколении операционных моделей (март 2017) рекомендует организовывать улучшения вокруг сквозных процессов, а не внутри функциональных подразделений, и отмечает, что концентрация примерно на 15–20 ключевых процессах раскрывает основную часть ценности; средней производственной компании достаточно 6–10. Значимость перераспределения ответственности подтверждает McKinsey Global Survey по цифровым трансформациям (октябрь 2018; опрос 16–26 января 2018 года, 1793 респондента, из них 1521 участвовал минимум в одной трансформации): переопределение ролей под цели трансформации повышало вероятность успеха примерно в полтора раза.

Реестр и карта процессов

Карта верхнего уровня делит процессы на основные, обеспечивающие и управленческие; её задача — полнота, то есть показать, что ни один значимый вид деятельности не остался без хозяина. Опора при составлении — APQC Process Classification Framework, таксономия бизнес-процессов, разработанная APQC в 1992 году (актуальная кросс-отраслевая версия 8.0): её используют как чек-лист полноты и источник единой терминологии, а не как шаблон для копирования.

Реестр процессов ведётся постоянно. Минимальные поля: границы, владелец, участвующие подразделения, регламент и его версия, показатели, поддерживающая система, дата последнего пересмотра. Без двух последних полей реестр мёртв через год — непонятно, какие модели актуальны.

AS IS: описание процесса по фактам

Модель AS IS фиксирует не то, как процесс должен идти по утверждённому положению, а то, как он идёт. Разрыв между этими картинами — первый результат обследования.

Что описывают. Событие входа и результат; шаги с исполняющей ролью; точки принятия решений и правила; документы и данные на входе-выходе; фактическую длительность шага и время ожидания перед ним; объём экземпляров процесса за период; места контроля; типовые отклонения. Редкие исключения на первом проходе и оценки вроде «неэффективно» в модели не нужны.

Уровень детализации — до операции, у которой есть исполнитель, входной документ, результат и длительность. Мельче дробят там, где шаг будет автоматизирован либо где сосредоточена основная потеря.

Источники данных. Журналы учётных систем дают даты создания, согласования и корректировки документов, авторов, смены статусов, число перепроведений. Формализованный вариант этой работы — process mining: по описанию IBM (октябрь 2021) это применение специализированных алгоритмов к журналам событий для восстановления фактической модели процесса. IBM выделяет три типа — discovery (построение модели по логам), conformance (сверка исполнения с утверждённой моделью) и enhancement (дополнение модели данными для поиска узких мест). Ограничение, на которое указывает сама IBM: метод не видит операций вне информационных систем, а на производстве таких много.

Наблюдение на рабочих местах показывает то, чего нет в логах: согласования голосом, параллельные таблицы, бумажный журнал кладовщика, переписку, из которой мастер узнаёт об изменении приоритета. Lean Enterprise Institute формулирует это прямо: смысл карты текущего состояния не в идеально нарисованной схеме, а в том, чтобы пройти понимание потока целиком, «от двери до двери». Интервью добавляют правила и историю появления шагов, но участники описывают процесс задуманным, а не исполняемым. Замер объёмов отличает значимую потерю от единичного случая. Правило триангуляции: любое утверждение подтверждается минимум двумя источниками, и расхождение между регламентом, словами участника и данными системы — самая ценная находка.

Нотации: какую и когда применять

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

Нотация	Что передаёт хорошо	Ограничения	Когда уместна
Кросс-функциональная схема («дорожки»)	Передачи и зоны ответственности, точки разрыва	Нет строгой семантики, ветвления читаются плохо	Сквозные процессы, обсуждение с руководством
BPMN 2.0	События, шлюзы, исключения; транслируемость в исполняемую логику	Требует обучения аналитиков, избыточна для бизнес-аудитории	Процессы для реализации в системе маршрутизации
EPC	Связку «событие — функция — исполнитель — документ — система»	Логика ветвлений менее строгая, модели громоздки	Регламентация больших массивов процедур
Карта потока создания ценности (VSM)	Материальный и информационный поток, время цикла против ожидания	Не описывает ветвления и варианты	Производственные и логистические потоки
Табличное описание (SIPOC)	Вход, поставщик, выход, потребитель, ответственный	Не показывает параллельность и время	Инвентаризация, паспорта процессов

BPMN 2.0 принята OMG в декабре 2010 года как де-факто стандарт диаграмм бизнес-процессов: нотация понятна тем, кто проектирует процессы, и достаточно точна, чтобы диаграммы транслировались в программные компоненты. Разные представления одного процесса для разных аудиторий — нормальная практика, смешение нотаций внутри одной модели — нет.

TO BE: проектирование и проверка

Целевая модель — не отредактированная AS IS, а ответ на вопрос, как должен идти процесс, чтобы достигалось заданное значение показателя.

Принципы. Отправная точка — результат для потребителя процесса и целевой измеритель. Сокращается число передач ответственности, а не длительность операций: в административных и планово-учётных процессах основная часть календарного времени уходит на ожидание между шагами. Решение принимает тот, у кого есть данные и полномочия; согласующий без права отклонить из маршрута исключается. Контроль переносится в точку возникновения данных. У сквозного процесса один владелец результата на всём маршруте. Проектируются сценарии отклонений, иначе ответ на вопрос «что делать, если срок нарушен» участники достроят стихийно. Редкий вариант получает отдельный короткий маршрут, а не усложняет основной.

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

Согласование между подразделениями. Сквозной TO BE меняет баланс нагрузки: у кого-то работы прибавляется, кто-то теряет право визировать, и переписка такие конфликты откладывает, а не разрешает. Рабочая схема: сессии с руководителями затронутых подразделений; разногласия фиксируются в протоколе как открытые вопросы с ответственным и датой; нерешённое выносится на арбитра — генерального или профильного директора; итоговая версия утверждается приказом с датой перехода и указанием, какие документы утрачивают силу. Без последнего пункта в компании действуют два порядка одновременно.

Владелец процесса

Роль владельца — конструктивный центр системы. Без неё процессное управление сводится к периодическому обновлению схем.

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

Какие полномочия необходимы. Менять последовательность шагов, состав участников и точки контроля в пределах утверждённых границ. Утверждать регламент. Согласовывать изменения настроек системы, влияющие на маршрут, права или статусную модель. Останавливать инициативы, улучшающие участок за счёт сквозного результата.

Линейным руководителем всех участников владелец при этом не становится: исполнители остаются в подчинении функциональных начальников. Конфликт снимают четырьмя способами. Владельцем назначают не «нейтральное лицо» из аппарата, а руководителя, на чью зону приходится наибольшее влияние на конечный результат. Ответственность разграничивают текстом положения: функциональный руководитель отвечает за ресурс и квалификацию, владелец процесса — за маршрут, сроки и сквозной результат. Мотивацию связывают общим знаменателем: часть сквозного показателя ставится руководителям подразделений-участников. Инстанцией эскалации становится процессный комитет под председательством генерального директора; без неё конфликт решается по личному влиянию.

Оформление. Приказ о назначении владельцев с перечнем процессов и границами, положение о процессном управлении, карточка процесса в реестре, пункт в должностной инструкции, показатели в системе мотивации. Без двух последних пунктов назначение остаётся декларацией.

Как система живёт после проекта

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

Кто ведёт. Достаточно одного-двух методологов, которые не управляют процессами, а обслуживают систему: ведут реестр, хранят версии, готовят материалы к комитету. Смешение ролей даёт либо бюрократию без результата, либо методолога, отвечающего за чужой результат.

Ритм. Ежемесячно владелец разбирает показатели и отклонения, ежеквартально комитет рассматривает портфель изменений, ежегодно пересматриваются реестр и приоритеты под изменившиеся цели компании. Здесь уместно наблюдение APQC (февраль 2024): лишь около четверти организаций связывают работу по управлению процессами с корпоративной стратегией, и при постановке процессной стратегии сначала отвечают на вопрос «зачем», а потом — «что делаем».

Порядок изменения модели. Заявка с обоснованием → оценка влияния (регламент, настройки, обучение, отчётность, смежные процессы) → решение владельца или комитета → новая версия модели и регламента → уведомление и обучение → изменение настроек системы. Обратный порядок за полгода обесценивает модель. Раз в квартал исполнение сверяется с моделью по данным журналов — проверка, которую IBM описывает как conformance; полезный её результат не список нарушителей, а перечень мест, где модель разошлась с реальностью.

Уровни зрелости

Шкала ниже помогает понять, какой шаг следующий, а какой преждевременный. Формализованные модели есть и у профильных организаций: APQC в феврале 2024 года выпустила модель зрелости на основе Seven Tenets of Process Management — семи столпов процессного управления.

Уровень	Что есть в компании	Типичный симптом	Первоочередной шаг
1. Стихийный	Процессы не описаны, порядок передаётся устно	Уход сотрудника парализует участок	Составить карту и реестр, определить границы сквозных процессов
2. Описанный	Схемы есть, но в работе не используются	Регламент трёхлетней давности, порядок другой	Назначить владельцев, привести модели приоритетных процессов к факту
3. Управляемый	Владельцы назначены, регламенты действуют, показатели считаются	Показатели собираются вручную к совещанию	Перевести расчёт на данные системы, ввести ритм пересмотра
4. Измеряемый	Сквозные показатели, приоритеты вытекают из целей компании	Узкие места находят с опозданием	Внедрить сверку факта с моделью, вести портфель изменений
5. Оптимизируемый	Изменения инициируются по данным, настройки меняются через модель	—	Расширять охват на обеспечивающие процессы

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

Модель и настройки системы

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

Границы процесса задают, какой объект системы является его носителем — договор, заявка, заказ — и каков жизненный цикл этого объекта. Шаги и передачи превращаются в маршрут согласования и задачи с нормативом времени. Роли и полномочия — в модель прав доступа и лимиты: кто создаёт, кто видит, кто изменяет, кто утверждает и в каких пределах суммы. Точки принятия решений и правила — в условия ветвления, обязательность реквизитов и проверки на входе шага. Нормативы длительности — в контроль просрочки и эскалацию, типовые отклонения — в классификатор причин. Состояния результата — в статусную модель документа, и требование к ней в том, чтобы статусы были содержательны для смежных подразделений: «на согласовании» бесполезно, «ожидает визы финансовой службы, норматив истекает завтра» позволяет действовать.

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

Эта цепочка определяет момент, когда в проекте появляется конкретная платформа: бизнес-требование → процесс → функциональное требование → система. В российской практике маршруты согласования, статусная модель, контроль сроков и версионность закрываются 1С:Документооборотом (в редакции КОРП — при больших объёмах и сложной ролевой модели), а операционный контур — 1С:ERP. Граница проходит по объекту процесса: где ядром является документ и решение по нему, работает документооборотный контур; где ядром является материальный поток — ERP.

Типовая ситуация: договорной процесс

Ситуация ниже собирательная, цифры условны и приведены для иллюстрации метода.

AS IS. Инициатор берёт шаблон из папки на сетевом диске, правит и рассылает по почте юристу, финансисту, безопасности, главному бухгалтеру и руководителю. Актуальную версию определяют по дате письма, любое замечание порождает новый круг. Реестр договоров ведут три подразделения в трёх файлах, контрольные даты не отслеживает никто — о нарушении узнают от контрагента.

Диагностика. Медиана согласования — около четырнадцати календарных дней при чистом времени работы согласующих порядка четырёх часов. Три визы из шести не дают права отклонить договор. Сорок процентов возвратов вызвано отсутствием на входе обязательных приложений, а юрист тратит основное время на типовые формы. Вывод: сокращать нужно число кругов и состав согласующих, и это делается до автоматизации.

TO BE. Без карточки и комплекта приложений маршрут не стартует. Состав согласующих определяет матрица по типу договора, сумме и отклонениям от типовой формы. Согласование параллельное, с нормативом на шаг и эскалацией при просрочке; юрист смотрит только отклонения. Ведётся один реестр со статусной моделью, контрольные даты связаны с графиком платежей.

Элемент AS IS	Диагностика	Решение TO BE	Требование к системе
Свободный состав согласующих	Половина виз — без права отклонить	Матрица по типу, сумме, отклонению от формы	Автоподбор маршрута по реквизитам карточки
Рассылка по почте по очереди	Ожидание — более половины срока	Параллельные ветви с нормативом на шаг	Контроль срока, эскалация
Возвраты из-за неполного комплекта	40% возвратов возникают на входе	Комплект приложений как условие старта	Контроль реквизитов и вложений
Три реестра договоров	Данные расходятся	Один реестр, один ответственный	Единый справочник, статусы, отчёты
Исполнение не отслеживается	О нарушении узнают от контрагента	Контрольные даты с ответственными	Напоминания, связь с платежами

Эффект без системы дают сокращение состава согласующих, типовые формы с лимитами и правило «не стартуем без комплекта». Только в системе появляются параллельные маршруты с эскалацией, автоподбор согласующих, единый реестр со статусами, связь договора с заказом и платежами. Отсюда и конфигурация: маршруты, версии и статусы — 1С:Документооборот, связь с заказами и платежами — 1С:ERP.

Чек-лист постановки процессного управления

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

1. Сформулированы 3–5 управленческих задач на год-два в измеримых величинах.
2. Составлены карта верхнего уровня и реестр, выделены 6–10 сквозных процессов, влияющих на эти задачи.
3. Владельцы назначены приказом, действует положение о процессном управлении с полномочиями и порядком эскалации.
4. Выбраны 2–3 приоритетных процесса для детальной работы, по остальным есть паспорт.
5. AS IS описан по журналам, наблюдению и интервью, с замером объёмов и длительностей.
6. Потери локализованы и оценены в днях или деньгах, а не перечислены как пожелания.
7. TO BE спроектирован, прошёл четыре теста реализуемости и утверждён приказом с датой перехода.
8. Изменения разделены на решаемые приказом, требующие регламента и данных, реализуемые только в системе.
9. Показатели утверждены, базовые значения зафиксированы до начала изменений.
10. Функциональные требования сформулированы от процесса, а не от названия модуля.
11. Работает ритм: ежемесячный разбор владельцем, ежеквартальный комитет, ежегодный пересмотр реестра.
12. Настройки системы не меняются в обход владельца процесса, а исполнение раз в квартал сверяется с моделью.

Типичные ошибки

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

Владелец без полномочий или владелец из ИТ-службы. В первом случае человек не может ни изменить маршрут, ни повлиять на приоритеты исполнителей, и роль превращается в отчётную нагрузку. Во втором требования будут сформулированы как «повторить текущий порядок в системе»: ИТ отвечает за работоспособность инструмента, а не за срок исполнения заказа.

Смешение уровней детализации и нотаций. В одной модели соседствуют «заключить договор» и «нажать кнопку провести»; BPMN приносят на совещание с директорами, а схему в «дорожках» пытаются использовать для настройки маршрута. Сюда же — реестр, целиком скопированный из отраслевой референсной модели.

TO BE как отредактированная AS IS. Вычёркивают очевидно лишнее и называют результат целевой моделью. Архитектурные потери — избыточные передачи, контроль в конце процесса, отсутствие ответственного за результат — сохраняются.

Изменение настроек в обход модели. Подразделение правит маршрут через ИТ напрямую — формально быстро, фактически это начало расхождения между моделью, регламентом и реальностью.

Как оценить результат

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

Группа	Показатель	Как считать	Источник данных
Результат	Время цикла	Медиана и 90-й перцентиль от события входа до результата	Журналы системы
Результат	Доля результатов в срок	Экземпляры в нормативе / все завершённые	Журналы системы
Результат	Доля возвратов и переделок	Экземпляры с повторным прохождением шага / все	Журналы системы
Качество процесса	Число передач ответственности	Смены исполнителя в маршруте	Модель процесса
Качество процесса	Доля отклонений от модели	Экземпляры с маршрутом, отличным от целевого / все	Сверка журналов с моделью
Зрелость	Доля процессов с владельцем и действующим регламентом	Соответствующие критерию / все в реестре	Реестр процессов

Четыре замечания к методике замера. Считать медиану и 90-й перцентиль, а не среднее: в процессах с длинным хвостом среднее маскирует именно те случаи, ради которых затевались изменения. Фиксировать базовые значения до начала изменений. Разделять эффект организационных решений и эффект системы промежуточным замером. Не приписывать процессным изменениям сдвиги, объяснимые сезонностью или структурой заказов. Рост доли отклонений от модели при этом не всегда означает недисциплинированность — чаще это сигнал пересмотреть саму модель.

Вывод

Управление бизнес-процессами держится на четырёх опорах, и выпадение любой обесценивает остальные: реестр процессов с определёнными границами, владелец с реальными полномочиями, показатели, считаемые из системы, и порядок внесения изменений в модель. Описание AS IS и проектирование TO BE — не самостоятельная ценность, а способ наполнить эти опоры содержанием.

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

FAQ

Чем управление бизнес-процессами отличается от их описания?
Описание — разовое действие с результатом в виде схемы и регламента. Управление — постоянная деятельность: владелец, измеримые показатели, ритм разбора отклонений, порядок внесения изменений. Проверяется одним вопросом: кто и когда в последний раз принял решение об изменении процесса по его показателям.

Какую нотацию выбрать, если нет специалистов по моделированию?
Начинать разумно с кросс-функциональных схем в «дорожках»: они читаются без обучения и показывают передачи ответственности, где и возникает основная часть потерь. BPMN нужен там, где модель станет основой для настройки маршрутов: строгая семантика позволяет транслировать схему в исполняемую логику.

Кого назначать владельцем процесса, проходящего через три подразделения?
Руководителя, на чью зону приходится наибольшее влияние на конечный результат, а не наибольший объём операций. Назначение подкрепляется правом менять маршрут в утверждённых границах, правом согласовывать изменения настроек системы и долей в KPI, привязанной к сквозному показателю.

Как понять, что модель процессов устарела?
По трём признакам: показатели собираются вручную вместо расчёта из системы; участники говорят «по регламенту так, а делаем иначе»; сверка фактических маршрутов по журналам с моделью даёт заметную долю расхождений. Последнюю проверку IBM описывает как conformance checking; периодичность — раз в квартал.

Обязательно ли внедрять специализированную BPM-систему?
Для среднего производственного предприятия чаще нет. Маршрутизация, статусная модель документов, контроль сроков и версионность закрываются документооборотным контуром учётной платформы, операционный контур — ERP-системой. Отдельный BPM-инструмент оправдан там, где велико число вариантов маршрутов, часто меняется логика и нужна независимость процессного слоя от учётных систем.

---

Что дальше

Если процессы в компании описаны, но не управляются — или описания устарели и ими никто не пользуется — начните с инвентаризации: реестр сквозных процессов, границы, владельцы, показатели и источники их расчёта. ERP Band проводит диагностику текущей модели управления, помогает выстроить реестр и распределить ответственность, проектирует целевые процессы и переводит их в функциональные требования, из которых затем вырастает конфигурация решения на 1С. Порядок работ такой, что каждый следующий этап опирается на принятое решение, а не на предположение.