Карта бизнес-процессов компании: как построить её и найти узкие места до внедрения ERP

Карта бизнес-процессов — визуальное представление работы: последовательность шагов, их исполнители, входы и выходы, ожидаемые сроки. IBM в материале о процессном картировании (сентябрь 2021) описывает назначение прямо: карта делает процесс понятным всем участникам и вскрывает избыточность и узкие места внутри процессов и на стыках.

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

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

Зачем карта нужна до выбора системы

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

McKinsey в работе о следующем поколении операционных моделей (март 2017) формулирует принцип организации улучшений: работать нужно вокруг сквозных процессов, пересекающих функциональные границы, а не внутри подразделений. Там же приведено наблюдение консультантов — концентрация примерно на 15–20 ключевых процессах раскрывает основную часть потенциала за минимальное время, — и отмечена ловушка: улучшение существующих процессов вместо их переосмысления.

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

Уровни карт: от реестра процессов до потока создания ценности

Основная причина, по которой картирование заходит в тупик, — попытка нарисовать всё в одной нотации и на одном уровне детализации. IBM перечисляет типы карт как разные инструменты: базовые блок-схемы, кросс-функциональные схемы (swimlane), детальные карты с раскрытием подпроцессов, верхнеуровневые карты в формате SIPOC и карту потока создания ценности. На практике удобнее работать с уровнями: каждый отвечает на свой вопрос.

Уровень 0. Реестр и архитектура процессов

Иерархически сгруппированный список всех процессов компании. Стрелок и последовательности здесь нет — это классификатор, отвечающий на вопрос «что у нас есть и кто за это отвечает». Логику группировки удобно заимствовать из классификатора APQC — Process Classification Framework. Таксономия разработана в 1992 году и стала самым распространённым фреймворком такого рода, актуальная редакция — восьмая. PCF разделяет процессы на операционные (от разработки стратегии и продукта до продаж, производства и обслуживания клиентов) и группу управления и обеспечения, а внутри раскрывает иерархию до пяти уровней: категория, группа процессов, процесс, действие, задача. Заимствовать стоит принцип: разделять основные процессы, управляющие и обеспечивающие. Деление сразу показывает перекосы — например, что у обеспечивающего процесса пять владельцев, а у основного ни одного.

Уровень 1. Схема сквозного процесса

Карта одного процесса от инициирующего события до конечного результата: 7–15 крупных шагов с ответственным подразделением у каждого. Видно, сколько раз работа переходит из рук в руки. Формат SIPOC добавляет к этому поставщика каждого входа и потребителя каждого выхода — полезно, когда спорят о границах.

Уровень 2. Кросс-функциональная схема (swimlane)

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

Уровень 3. Детальная карта операций

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

Отдельный жанр: карта потока создания ценности

Карта потока создания ценности (value-stream map, VSM) — не более подробная схема, а другой инструмент. Lean Enterprise Institute в материале о фундаментальных основах VSM (август 2022, обновление февраль 2023) описывает её как четыре зоны на одном листе: сверху поток информации; в середине блоки процессов; под ними блоки данных с метриками — время цикла, время переналадки, доля результата, переданного дальше без ошибок; внизу временная шкала, раздельно показывающая время, когда с объектом что-то делают, и время, когда он ждёт.

LEI разводит инструменты по назначению: VSM смотрит на поток целиком глазами потребителя и применяется в начале исследования проблемы, процессное картирование — на отдельную операцию глазами исполнителя, когда точка уже выбрана. В планово-учётных процессах разрыв между обработкой и ожиданием обычно заметнее, чем в цехе.

Тип карты	Что показывает	Когда применять	Чего не показывает
Реестр процессов	Перечень процессов, группировку, владельцев	При выборе приоритетов и построении KPI	Последовательность, длительности, проблемы процесса
Схема сквозного процесса	Крупные шаги от события до результата и ответственных	При согласовании границ и владельца, для разговора с руководством	Детали исполнения, причины задержек
Кросс-функциональная схема	Передачи, разрывы ответственности, согласования	На основной стадии диагностики и при проектировании маршрутов	Количественные потери без слоя данных
Детальная карта операций	Действия, поля, проверки, обработку отклонений	Выборочно — для проблемных и автоматизируемых шагов	Общую картину; быстро устаревает
Карта потока создания ценности	Материальный и информационный потоки, обработку против ожидания	Когда гипотеза — потери во времени и запасах	Логику решений, права и полномочия

Пошаговая методика построения карты

Шаг 1. Задать вопрос и очертить границы. Работа начинается с формулировки того, что мы хотим выяснить: «почему срок исполнения заказа 52 дня при трудоёмкости в 12», «почему себестоимость расходится с бюджетом на 20%». Из вопроса выводятся границы — инициирующее событие и конечный результат. Границы должны пересекать подразделения: процесс, помещающийся внутри одного отдела, редко содержит крупные потери.

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

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

Ориентир: черновик на уровне swimlane собирается за одну сессию 3–4 часа, типичный размер карты — 15–40 шагов и 4–8 дорожек. Больше сотни шагов означают, что границы выбраны слишком широко.

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

Шаг 5. Сверить с фактом. Нарисованное на сессии — процесс, каким его помнят участники. Реальный отличается: в нём есть варианты, о которых не упомянули, и обходные пути, о которых неудобно говорить.

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

Шаг 7. Вовремя остановиться. Детализации достаточно, когда у каждого шага есть один исполнитель, входной и выходной артефакт и измеримая длительность, а проблемные зоны локализованы до шага, а не до подразделения.

Количественный слой: какие данные собирать

Карта становится диагностической, когда к шагам и стрелкам привязаны цифры.

Первое и главное — раздельный замер времени выполнения и времени ожидания, разделение, заимствованное из логики VSM. Время выполнения показывает, сколько исполнитель фактически работает с объектом, время ожидания — сколько объект лежит в очереди между шагами. Считать их вместе бессмысленно: ускорение двадцатиминутной операции внутри процесса длительностью три недели ничего не даст. Рядом фиксируется общая длительность прохождения — календарное время от события до результата, обязательно медиана, а не среднее. Полезен и разброс: процесс со стабильными 12 днями управляем, процесс со средними 12 днями и разбросом от 3 до 40 — нет.

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

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

Как увидеть фактический процесс, а не декларируемый

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

IBM (октябрь 2021) выделяет три типа такой работы, опираясь на исследования Вила ван дер Аалста и «Манифест process mining», опубликованный IEEE в 2011 году: discovery — построение модели из журналов без опоры на существующее описание; conformance — сверка фактической картины с заявленной моделью; enhancement — обогащение модели данными о производительности, в том числе для поиска узких мест.

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

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

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

Как читать карту и находить узкие места

Карта с количественным слоем читается по набору устойчивых признаков.

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

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

Типовой пример: сельхозработы — исполнение — затраты по полю

Рассмотрим типовую ситуацию растениеводческого предприятия с земельным банком порядка 20–30 тысяч гектаров, тремя производственными участками и собственным парком техники. Ситуация собирательная и приведена как иллюстрация метода.

Вопрос, ради которого строится карта. Фактическая себестоимость по культурам расходится с бюджетом на величину, которую не удаётся объяснить: агрономическая служба ссылается на погоду и изменение технологии, экономисты — на перерасход топлива и материалов, но назвать конкретные поля и операции не может никто.

Границы. От формирования технологических карт под сезон до закрытия периода с расчётом затрат по полям и культурам. Карта уровня 2 дала восемь дорожек и 31 шаг.

Фрагмент процесса	Выполнение	Ожидание	Ввод данных
Формирование техкарт по культурам	3–4 недели сезонно	—	Файлы агрономов
Сведение потребности и передача в снабжение	3–5 дней	1–2 недели до бюджета	Повторный ввод в заявку
Выдача сменных заданий на участке	15–20 минут в день	—	Устно и в журнале бригадира
Ввод первички в учётную систему	4–6 часов в неделю	10–20 дней от даты работ	Повторный ввод с бумаги
Списание топлива и материалов	1 день	до закрытия месяца	Свод суммой на культуру

Что прочиталось на карте. Между планом и фактом нет общего объекта учёта: технологическая карта строится на поле, а списание материалов выполняется на культуру целиком, поэтому сопоставить план и факт по полю невозможно — данные разной размерности. Лаг ввода фактических данных в 10–20 дней делает оперативное управление бессмысленным: к моменту, когда перерасход виден, операция завершена, техника переехала. Сменное задание не является документом, оно передаётся устно, а сверка выполненного объёма с площадью поля отсутствует — учётный лист может содержать обработку 140 гектаров на поле площадью 120. Справочник полей ведётся в двух местах и расходится.

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

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

Что меняется в результате. Перерасход перестаёт быть общей цифрой по культуре и локализуется до операции на конкретном поле в конкретный день. Разговор агронома и экономиста меняет предмет: вместо спора о причинах отклонения бюджета обсуждается, почему на поле №14 расход топлива на культивации превысил норму на 18%. Замерять нужно не «внедрённость», а показатели процесса: лаг между выполнением работы и появлением факта в системе, долю площадей с рассчитанной себестоимостью, отклонение расхода от нормы.

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

От карты к требованиям к системе

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

Элемент карты	Во что превращается в системе	Что решить до настройки
Последовательность шагов с ответственными	Статусная модель документа и переходы между статусами	Какие состояния различимы и кто имеет право их менять
Точка согласования	Маршрут с условиями, сроками и эскалацией	Кто согласует, когда шаг пропускается, что происходит при просрочке
Контрольная точка	Проверка при проведении или блокирующее условие	Критерий в виде правила, а не экспертного суждения
Передача между подразделениями	Событие, уведомление, задача исполнителю	Кто получает работу и в какой срок
Разрез, в котором задаются вопросы к процессу	Аналитика учёта: объект затрат, заказ, поле, партия	До какого уровня нужна детализация и хватит ли данных на входе
Справочные данные шага	Справочник НСИ с владельцем и версионностью	Кто ведёт, как часто актуализируется, что считается дублем

Порядок формулирования требования идёт от бизнес-задачи к системе. Бизнес-требование: «локализовать перерасход материалов до поля и операции в течение суток». Процессное: «факт выполнения работ регистрируется в разрезе поля и операции не позднее следующего рабочего дня, норма расхода берётся из технологической карты». Функциональное: «сменное задание формируется из плана работ с плановыми нормами, отклонение факта от нормы рассчитывается автоматически и выводится в отчёт по полю». И только после этого — вопрос платформы.

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

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

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

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

Одинаковая детализация по всему периметру. Попытка описать каждый процесс до уровня операций съедает бюджет на этапе описания. Детализация должна быть неравномерной.

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

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

Нотация вместо смысла. Полгода уходит на обучение BPMN и выбор инструмента моделирования, содержательная работа откладывается.

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

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

Что измеряем	Показатель	Как считать	Когда проявляется
Упрощение процесса	Число шагов и передач между подразделениями	Сопоставление AS IS и TO BE по схеме	Сразу после перепроектирования
Согласования	Число согласований в маршруте и доля возвратов	Данные системы документооборота	1–3 месяца
Соотношение времени	Доля времени обработки в общей длительности	Сумма времён выполнения / общая длительность	3–6 месяцев
Длительность процесса	Медианная длительность от события до результата	Данные учётной системы, медиана и разброс	3–6 месяцев
Оперативность учёта	Лаг между операцией и её отражением в системе	Разность дат операции и регистрации, медиана	1–3 периода

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

Вывод

Карта бизнес-процессов полезна ровно настолько, насколько отвечает на заданный ей вопрос. Уровень детализации, тип схемы и объём собираемых данных выводятся из этого вопроса, а не из желания описать всё. Рабочая последовательность: сформулировать вопрос и границы сквозного процесса, собрать в комнате владельца, исполнителей и смежников, нарисовать черновик за один проход, наложить количественный слой, сверить его с журналами учётной системы, прочитать карту по признакам узких мест, разделить найденное на организационные изменения и задачи для системы.

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

FAQ

Сколько времени занимает построение карты процессов?
Реестр процессов верхнего уровня для среднего предприятия собирается за одну-две сессии. Карта одного сквозного процесса на уровне swimlane — сессия 3–4 часа плюс неделя на сбор данных и сверку с системой. Полный цикл по трём-пяти приоритетным процессам, включая диагностику и проектирование целевого состояния, укладывается в шесть-десять недель. Дольше всего идёт не рисование, а согласование спорных стыков.

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

Нужны ли специальные инструменты process mining?
Для среднего предприятия обычно нет. Журнал регистрации, история изменений документов и лог маршрутов согласования дают достаточно данных, чтобы восстановить фактическую последовательность, длительности и частоту переделок. Специализированные инструменты оправданы при большом числе вариантов процесса, множестве систем-источников и потребности в постоянном мониторинге.

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

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

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

---

Что дальше

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