Вопросы и ответы о сценарных цепочках, визуальном атласе и технологии «Электронная фабрика»
Компания ERP-Мастер завершила разработку технологии визуального атласа сценарных цепочек для проектов на базе 1С:ERP.
Это не просто новый способ красиво нарисовать бизнес-процесс. Визуальный атлас используется для проектирования сквозных маршрутов предприятия, согласования ролей и документов, подготовки операционных инструкций, автоматизированного тестирования пользовательских сценариев и управленческого стресс-тестирования процессов.
Ниже — коротко о технологии в формате вопросов подписчиков и ответов ERP-Мастер.
[Иллюстрация 1. Общий вид. Скачать полную версию]
Вопрос подписчика
Зачем вообще рисовать такие большие схемы, если бизнес-процессы уже описаны в текстовом документе?
Ответ ERP-Мастер — коротко:
Потому что текстовая модель описывает процессы, а сценарная схема показывает, как предприятие реально выполняет заказ, контракт или производственный маршрут.
В одном из промышленных проектов мы столкнулись с типовой ситуацией для внедрения 1С:ERP. По предприятию была собрана большая модель: около 20 объектов автоматизации, 201 бизнес-процесс, и по каждому БП — три слоя описания:
- паспорт БП;
- текстовая блок-схема БП;
- операционная инструкция / реализация БП в 1С:ERP.
Формально модель была сделана правильно: входы, выходы, роли, предметы-драйверы, связи между процессами, операционные шаги и прикладные инструкции.
Но возникла практическая проблема. Когда заказчик видит сотни страниц, он перестаёт видеть предприятие целиком. Он видит фрагменты, отдельные процессы, таблицы, длинные описания. Но ему трудно понять, как через предприятие проходит реальный ГОЗ-контракт, производственный заказ, закупка, изменение КД или закрытие периода.
Именно здесь появляется новый слой работы — сценарные цепочки.
Вопрос подписчика
А откуда берётся сам «кубик» бизнес-процесса? Что он из себя представляет?
Ответ ERP-Мастер — коротко:
Кубик БП формируется из методической модели предприятия: объектов автоматизации, предметов-драйверов, групп процессов, вопросов к владельцам процессов, интервью и прикладной логики 1С:ERP.
В технологии «Электронная фабрика» бизнес-процессы сначала раскладываются по классическим разделам процессной архитектуры: основные, вспомогательные, управляющие и специальные процессы.
Затем они группируются по объектам автоматизации. Объект автоматизации — это крупная область работы предприятия, которую нужно описать и связать с прикладной системой: продажи, ГОЗ, производство, снабжение, склад, бухгалтерский учёт, ЗУП, казначейство, НСИ, качество, сервис и другие контуры.
Внутри объекта автоматизации выделяются предметные области и предметы-драйверы: контракт, заказ клиента, производственный заказ, ресурсная спецификация, материал, партия, полуфабрикат, деталь, готовое изделие, платёж, акт, несоответствие, изменение КД.
Дальше формируются группы процессов. Часть групп является постоянной: они встречаются почти на любом производственном предприятии. Часть групп является конформной: они появляются из особенностей конкретного предприятия, отрасли, ГОЗ, цеховой структуры, учётной политики, интеграций и фактической практики работы.
После этого по каждой группе процессов формируются вопросы к предприятию. Это не свободный список вопросов «о чём-нибудь». Вопросы направлены на выяснение конкретных вещей: какие предметы движутся, кто принимает решение, где начинается процесс, где он заканчивается, какие документы появляются, какие статусы меняются, какие данные должны попасть в 1С:ERP, где возникают альтернативные маршруты.
Ответы на вопросы, интервью и рабочие демонстрации обрабатываются и превращаются в БП. Каждый БП получает паспорт, текстовую блок-схему и операционную инструкцию.
Так появляется тот самый «кубик»:
предмет-драйвер → группа процессов → вопрос к владельцу процесса → интервью → бизнес-процесс → паспорт БП → текстовая блок-схема БП → операционная инструкция / реализация БП в 1С:ERP → тестовый сценарий.
Внутри 18-томной методики ERP-Мастер эта логика поддерживается не только текстом книг, но и Excel-ядрами. Excel-ядра служат машинно-читабельной опорой: в них фиксируются сущности, связи, поля, статусы, роли, KPI, источники данных, мэппинги и контрольные признаки.
За счёт этого сложная модель не собирается вручную с нуля каждый раз. Она разрабатывается как инженерная сборка: быстро, детально, с проверкой связей и с последующим переходом к визуальному атласу, регламентам, инструкциям, KPI и стресс-тестированию.
[Иллюстрация 2. Как формируется “кубик” БП]
Предмет-драйвер → группа процессов → БП → паспорт БП → текстовая блок-схема БП → операционная инструкция / реализация БП в 1С:ERP → тестовый сценарий.
Вопрос подписчика
Что такое сценарная цепочка?
Ответ ERP-Мастер — коротко:
Сценарная цепочка — это маршрут выполнения реального случая на предприятии, собранный из проверенных блоков БП.
Например, есть отдельный процесс «Создание и настройка контракта ГОЗ». Есть отдельный процесс «Плановая калькуляция». Есть отдельный процесс «Управление денежными средствами отдельного счёта». Есть производство, склад, закупки, ЗУП, бухгалтерия, отчётность.
В текстовой модели это отдельные блоки.
Но в жизни предприятие работает не блоками, а сценариями:
появился ГОЗ-контракт → настроили направление деятельности → открыли отдельный счёт → сформировали плановую базу → обеспечили материалы → запустили производство → собрали факт → провели реализацию → получили оплату → сформировали отчёт.
Вот это и есть сценарная цепочка.
Она показывает, как «кубики» модели складываются в исполняемый маршрут. При этом каждый кубик не висит в воздухе. Он связан с прикладным слоем: объектами 1С:ERP, настройками, документами, справочниками, ролями, статусами и инструкциями.
Если на схеме показан блок «Плановая калькуляция продукции по контракту», за ним должен стоять конкретный БП, а внутри БП — операции, которые можно проверить в системе.
Вопрос подписчика
Что такое предмет-драйвер?
Ответ ERP-Мастер — коротко:
Предмет-драйвер — это то, что движется через предприятие и собирает вокруг себя маршрут.
Если предмет-драйвер — ГОЗ-контракт, мы получаем одну сценарную цепочку.
Если предмет-драйвер — производственный заказ, получаем другую.
Если предмет-драйвер — потребность материала под конкретное назначение, получаем третью.
Если предмет-драйвер — изменение конструкторской документации, получаем четвёртую.
И это не игра в термины. От предмета-драйвера зависит вся логика схемы: роли, документы, статусы, развилки, контрольные точки, системы и инструкции.
Поэтому при построении визуального атласа мы начинаем не с вопроса «какую красивую схему нарисовать?», а с вопроса:
какой предмет проходит через предприятие и какой маршрут нужно согласовать?
Вопрос подписчика
Что изображено на примере схемы ГОЗ?
Ответ ERP-Мастер — коротко:
На схеме показана сценарная цепочка первого уровня: как ГОЗ-контракт проходит через предприятие от подписания до отчётности.
На иллюстрации показана схема:
SC-GOZ-01. Сценарная цепочка исполнения контракта ГОЗ.
Это большой широкий лист, который читается слева направо. Сверху идут фазы:
инициация контракта → настройка ГОЗ-аналитик → этапы и нормативная база → финансирование и обеспечение → ТПП и запуск производства → исполнение и себестоимость → реализация и расчёты → завершение и отчётность.
Слева идут дорожки по ролям и подразделениям: заказчик / ЕИС, руководитель проекта ГОЗ, продажи, технолог / ТПП, ПДО / производство, МТО / склад, финансы, бухгалтерия / ЗУП, контролёр данных ГОЗ.
Внутри схемы находятся блоки сценария. Каждый блок связан с исходным процессом модели: GOZ.1.1, GOZ.1.2, GOZ.1.3, GOZ.2.1, UC-4.3 и так далее.
Оранжевые ромбы показывают развилки: контракт поэтапный или нет, есть ли кооперация, утверждены ли нормативы, согласованы ли данные хаба, подписаны ли документы ЕИС.
Зелёный контур показывает хаб 1С:ERP ГОЗ — место, где данные собираются, сверяются, корректируются и готовятся для отчётности.
Внизу идёт строка артефактов: госконтракт ЕИС, направление деятельности, отдельный счёт, заказ клиента, плановая РС, калькуляция, резерв, заказ на производство, выпуск, ГОЗ-хаб, себестоимость, реализация, оплата, отчёт ГОЗ.
[Иллюстрация 3. Как читать схему: фазы, дорожки, блоки]
Фрагмент SC-GOZ-01: верхняя шкала фаз, дорожки по ролям и первые блоки маршрута.
Вопрос подписчика
Почему схема такая большая?
Ответ ERP-Мастер — коротко:
Потому что это не картинка для печати на А4, а электронный визуальный атлас, где важна читаемость.
Обычная ошибка — пытаться втиснуть сложный межфункциональный маршрут в маленькую страницу. Тогда блоки налезают друг на друга, стрелки пересекаются, шрифт становится мелким, а схема превращается в декоративную картинку.
Мы используем другой подход: широкий электронный PDF.
Схема должна быть читаемой на экране. Блоки должны быть крупными. Стрелки — прямыми, ортогональными. Дорожки — понятными. Фазы — видимыми. Текст — не микроскопическим.
Если места не хватает, увеличивается полотно, а не уменьшается смысл.
Вопрос подписчика
Почему это не просто очередная схема бизнес-процесса?
Ответ ERP-Мастер — коротко:
Потому что схема опирается на библиотеку процессных блоков, а каждый блок уходит в модель, объекты 1С:ERP, инструкции и тестовые сценарии.
Обычная схема процесса часто живёт отдельно. Её нарисовали, согласовали, положили в папку, а потом система внедряется по-другому.
Здесь логика другая.
Сначала собирается библиотека БП. Каждый БП описывается строго: зачем он нужен, что получает на вход, что отдаёт на выход, кто выполняет, какие роли участвуют, какие документы и данные создаются, какие статусы меняются.
Затем БП раскрывается в текстовой блок-схеме БП: по ролям, шагам и переходам.
После этого формируется операционная инструкция: реализация БП в 1С:ERP, то есть что именно пользователь делает в системе, в каком разделе, с каким объектом, какой документ создаёт, какие поля заполняет, какой статус устанавливает.
И только потом из этих блоков собирается сценарная цепочка первого уровня. Поэтому визуализация не оторвана от системы. Она является верхним навигационным слоем над уже описанной процессной и прикладной логикой.
[Иллюстрация 4. Связь сценарной цепочки с объектами 1С:ERP]
Сценарная цепочка → БП → объект 1С:ERP → пользовательское действие → операционная инструкция → тестовый сценарий.
Вопрос подписчика
Как схема связана с исходной моделью бизнес-процессов?
Ответ ERP-Мастер — коротко:
Каждый блок схемы связан с конкретным процессом модели, а процесс связан с объектами 1С:ERP, текстовой блок-схемой, операционной инструкцией и будущим тестовым сценарием.
Сценарная схема не должна жить отдельно от модели. Иначе она быстро превращается в красивый плакат.
Поэтому каждый блок схемы получает код.
Например:
SC-GOZ-Б04 / GOZ.1.3 — Плановая калькуляция продукции по контракту.
Первый код — это место блока на визуальной схеме. Второй код — это исходный процесс в модели.
Пользователь открывает модель БП, находит процесс GOZ.1.3 и видит там три уровня детализации:
- паспорт БП: зачем нужен бизнес-процесс, входы, выходы, роли, результат;
- текстовая блок-схема БП: кто и какие шаги выполняет;
- операционная инструкция: как реализуется БП в 1С:ERP, 1С:ERP ГОЗ, ЗУП, ЕИС или другом прикладном контуре.
Схема отвечает на вопрос: как этот участок находится в общем маршруте?
А текстовая модель отвечает на вопросы: кто делает, что делает, в какой системе и каким результатом это заканчивается?
Дальше это можно раскрывать ещё глубже: какой объект 1С:ERP используется, какой документ создаётся, какой справочник заполняется, какой статус меняется, какие данные должны перейти в следующий блок.
Вопрос подписчика
Как показываются основной и альтернативный маршруты?
Ответ ERP-Мастер — коротко:
Они показываются как разные ветки одной сценарной цепочки, если у них общий предмет-драйвер.
Например, производственный маршрут может идти основным способом через заказ на производство, структуру заказа, этапы производства и выпуск.
Но в зависимости от типа производства может использоваться и альтернативная упрощённая схема: отдельный производственный заказ, сокращённый маршрут, иной порядок формирования этапов или другой способ отражения факта.
В сценарной цепочке можно показать и основной маршрут, и альтернативную ветку, не смешивая их в одну неясную инструкцию. Это особенно важно для предприятий, где разные типы производства живут рядом: серийное производство, опытные образцы, ремонт, НИОКР, производство без заказа или упрощённое отражение выпуска.
[Иллюстрация 5. Основной и альтернативный маршрут]
Один предмет-драйвер может идти по основному или альтернативному маршруту в зависимости от типа производства.
Вопрос подписчика
Можно ли автоматически перестраивать такие цепочки по замечаниям заказчика?
Ответ ERP-Мастер — коротко:
Да, если схема построена не как картинка, а как сценарная сборка из кодированных процессных блоков.
Если схема нарисована вручную как набор прямоугольников, каждое изменение превращается в ручную перерисовку. Исправили блок — потеряли связь с регламентом. Передвинули стрелку — забыли обновить инструкцию. Добавили развилку — неясно, где она отражена в модели.
В технологии «Электронная фабрика» схема собирается из блоков, у которых есть коды, источники, входы, выходы, роли, статусы и связь с прикладным слоем.
Поэтому замечание заказчика можно разложить не только как правку картинки, но и как правку модели:
- изменить порядок блоков;
- добавить альтернативную ветку;
- уточнить роль;
- поменять вход или выход;
- добавить документ;
- уточнить объект 1С:ERP;
- изменить операционную инструкцию;
- добавить тестовый сценарий.
Такой подход позволяет быстро перестраивать цепочку и сохранять трассировку: от визуального блока до БП, от БП до объекта 1С:ERP, от объекта 1С:ERP до инструкции и проверки.
Вопрос подписчика
Как проектная группа даёт замечания к такой схеме?
Ответ ERP-Мастер — коротко:
Лучший формат — голосовые замечания с привязкой к кодам блоков, процессов и развилок.
Не нужно просить владельцев процессов писать длинные правки в Word. Это неудобно, медленно и часто убивает контекст.
Лучше открыть схему и пройти по ней вслух:
«SC-GOZ-01, блок SC-GOZ-Б04, процесс GOZ.1.3. У нас плановая калькуляция иногда начинается раньше, ещё до финального утверждения этапов. Нужно показать это как параллельную проработку».
Или:
«Развилка R04. Нормативы утверждает не только технолог. Там обязательно участвует экономист ГОЗ. Нужно добавить роль».
Такое голосовое замечание затем транскрибируется и раскладывается:
- что исправить на схеме;
- что изменить в сценарной цепочке;
- что уточнить в процессе модели;
- что добавить в текстовую блок-схему БП;
- что дописать в операционную инструкцию.
Это быстрый способ превращать живое знание сотрудников в управляемую модель.
Вопрос подписчика
Как такие цепочки можно тестировать автоматически?
Ответ ERP-Мастер — коротко:
Если каждый блок цепочки раскрыт до операции в 1С:ERP, его можно превратить в тестовый пользовательский сценарий.
Например, в цепочке есть участок: создать заказ на производство, сформировать структуру заказа, сформировать этапы, рассчитать график, передать потребность в закупку, оформить поступление, отразить выпуск.
Если для каждого шага есть операционная инструкция, то её можно использовать не только для обучения пользователя. Её можно превратить в проверяемый сценарий: зайти в нужный раздел, создать нужный документ, заполнить поля, провести, проверить статус, сформировать отчёт, убедиться, что следующий блок получил правильный вход.
Именно здесь появляются возможности 1С Automation / Vanessa Automation: сценарий можно описывать не только как текст для человека, но и как проверяемую последовательность действий.
Тогда цепочка становится не просто схемой согласования, а основой для тестирования бизнес-маршрута.
[Иллюстрация 6. От сценарной цепочки к 1С Automation / Vanessa Automation]
Интервью → транскрипт → библиотека БП → сценарная цепочка → операционная инструкция → 1С Automation / Vanessa Automation → тестирование маршрута.
Вопрос подписчика
Сколько таких цепочек может быть на предприятии?
Ответ ERP-Мастер — коротко:
Десятки на верхнем уровне и значительно больше в частных вариантах, поэтому рисовать нужно не «всё подряд», а по приоритету проектной группы.
Если в модели 201 бизнес-процесс, каждый из которых имеет входы, выходы, роли и связи, то из них можно собрать десятки сценарных маршрутов.
На первом уровне обычно можно выделить 25–40 устойчивых сценарных цепочек. Если дробить их по направлениям, типам заказов, исключениям, ГОЗ-веткам, закупочным вариантам, цеховым маршрутам и статусным развилкам, число частных сценариев может вырасти до 80–150 и более.
Поэтому визуальный атлас нельзя строить вслепую по принципу «нарисуйте всё».
Нужно идти от управленческого запроса:
- какие маршруты руководству важно увидеть первыми;
- где чаще всего возникают ошибки;
- какие процессы труднее всего согласовать;
- где много ручной работы;
- где есть разрывы между подразделениями;
- где нужна инструкция для 1С:ERP;
- где нужно обучение пользователей.
Именно проектная группа должна задавать приоритеты: какие предметы-драйверы превращаем в сценарные схемы первыми.
Вопрос подписчика
Что происходит после согласования схемы?
Ответ ERP-Мастер — коротко:
Согласованная схема становится основанием для уточнения модели, регламентов, инструкций и автоматизированных сценариев.
После согласования схема перестаёт быть просто схемой.
Она становится основой для нескольких видов работ.
Во-первых, уточняется модель БП: входы, выходы, роли, статусы, развилки, переходы между процессами.
Во-вторых, уточняются регламенты: кто отвечает за шаг, кто проверяет, кто принимает результат, где фиксируется документ.
В-третьих, уточняются операционные инструкции для пользователей 1С:ERP.
В-четвёртых, появляется материал для автоматизированных пользовательских сценариев. Если процесс описан по ролям, шагам, системам и объектам 1С, его можно переводить в сценарии обучения, тестирования и автоматизации пользовательских действий.
То есть путь выглядит так:
интервью → транскрипт → предметы-драйверы → библиотека БП → объекты 1С:ERP → сценарная цепочка → визуальная схема → замечания голосом → уточнение модели → регламенты → инструкции 1С → автоматизированные сценарии → тестирование цепочки.
Вопрос подписчика
А можно по такой цепочке проводить стресс-тестирование предприятия?
Ответ ERP-Мастер — коротко:
Да. Сценарная цепочка — это не только визуальная схема и не только основа для инструкции. Это ещё и план для управленческого стресс-тестирования.
Если цепочка собрана из БП, а у каждого блока есть вход, выход, роль, статус, объект 1С:ERP и KPI, то по ней можно задавать стресс-вопросы.
Например:
что будет, если по этой цепочке запустить конкретный ГОЗ-контракт?
Где появится узкое место? Что произойдёт, если плановая калькуляция задержится на три дня? Что будет, если отдельный счёт открыт, но аванс не поступил? Что произойдёт, если материалы обособлены не полностью? Где цепочка остановится, если ресурсная спецификация не утверждена? Как повлияет задержка внешней кооперации на выпуск, реализацию и отчёт ГОЗ?
В обычной схеме такие вопросы повисают в воздухе. В сценарной цепочке они привязаны к конкретным блокам:
- у блока есть владелец;
- у блока есть KPI;
- у блока есть вход и выход;
- у блока есть данные в 1С:ERP;
- у блока есть следующий получатель результата;
- у блока есть альтернативная ветка или возврат.
Поэтому сценарная цепочка становится не только инструментом визуализации, но и основой для проверки устойчивости процесса.
Следующая отдельная тема — взять схему SC-GOZ-01 и провести по ней стресс-тестирование: пройти блок за блоком и посмотреть, какие управленческие риски проявятся при запуске реального контракта. Это уже отдельная статья: не о том, как рисуется цепочка, а о том, как по ней проверяется живучесть предприятия.
[Иллюстрация 7. Сценарная цепочка как план стресс-тестирования]
По каждому блоку сценарной цепочки задаются сбойные сценарии и проверяется влияние на KPI, сроки, себестоимость, оплату и отчётность.
Вопрос подписчика
Где здесь программа «Электронная фабрика»?
Ответ ERP-Мастер — коротко:
«Электронная фабрика» — это технология ERP-Мастер, которая связывает интервью, библиотеку БП, объекты 1С:ERP, сценарные цепочки, инструкции и автоматизированное тестирование.
Обычный ERP-проект часто останавливается на настройках, документах и отчётах. Но предприятие остаётся сложным: сотрудники знают куски работы, руководители видят итоговые проблемы, консультанты видят функционал системы, а целостный маршрут теряется между ними.
В «Электронной фабрике» мы собираем эту сложность в несколько слоёв:
- интервью и рабочие материалы;
- предметы-драйверы;
- библиотеку блоков БП;
- модель БП;
- текстовые блок-схемы БП;
- привязку к объектам 1С:ERP;
- операционные инструкции;
- визуальный атлас сценарных цепочек;
- регламенты и обучение;
- сценарии 1С Automation / Vanessa Automation;
- автоматизированную проверку пользовательских маршрутов;
- стресс-тестирование сценарных цепочек по KPI.
В результате появляется не просто документ на сотни страниц, а инженерная карта работы предприятия.
Руководитель видит маршрут. Владелец процесса видит свою зону ответственности. Методолог видит связи. Консультант 1С видит объекты системы. Пользователь получает инструкцию. Тестировщик получает проверяемый сценарий. ИИ получает структурированную опору для последующей обработки, перестройки и проверки.
Вопрос подписчика
ERP-Мастер может провести такую работу на нашем предприятии?
Ответ ERP-Мастер — коротко:
Да, может. Мы можем провести предприятие через самоинтервью, сборку библиотеки БП, построение сценарных цепочек, визуальный атлас, стресс-тестирование и подготовку операционных инструкций для 1С:ERP.
Особенность этой работы в том, что технология уже собрана как производственный контур.
Это не ручное рисование схем с нуля и не бесконечное описание процессов «по мере погружения». В основе лежит автоматизированная цепочка:
самоинтервью → транскрипты → предметы-драйверы → библиотека БП → паспорт БП → текстовая блок-схема БП → реализация БП в 1С:ERP → сценарная цепочка → визуальный атлас → стресс-тест → операционная инструкция → тестовый сценарий.
Поэтому сроки и бюджет могут быть фиксированы заранее после определения периметра работ. Здесь нет прямой зависимости по принципу: «чем больше процессов, тем бесконечнее трудоёмкость». Основная часть обработки, структурирования и сборки выполняется по готовой технологии «Электронная фабрика».
Для машины нет принципиальной разницы, собрать 30, 100 или 200 процессных блоков, если они правильно подготовлены, закодированы и связаны с предметами-драйверами. Разница возникает не в ручном рисовании, а в управленческом выборе: какие цепочки действительно нужны предприятию в первую очередь.
Мы можем помочь:
- подготовить вопросники для самоинтервью;
- обработать ответы и транскрипты;
- выделить предметы-драйверы;
- собрать библиотеку БП;
- связать БП с объектами 1С:ERP;
- построить сценарные цепочки первого уровня;
- оформить визуальный атлас;
- провести стресс-тестирование цепочек;
- подготовить операционные инструкции и сценарии проверки.
Пишите, обращайтесь. Контакты указаны на сайте ERP-Мастер: erp-master.ru.
Финальный вопрос подписчика
Зачем всё это бизнесу?
Ответ ERP-Мастер — коротко:
Чтобы предприятие перестало теряться между интервью, регламентами, ERP-настройками, Excel-файлами и устными договорённостями.
Большое предприятие нельзя понять только через меню 1С. Его нельзя понять только через организационную структуру. И его нельзя понять только через текстовый документ с сотнями страниц.
Но его можно начать собирать через предметы, которые реально движутся через предприятие. ГОЗ-контракт. Производственный заказ. Потребность материала. Деталь. Полуфабрикат. Изменение КД. Сменное задание. Несоответствие. Отчёт. Когда эти предметы становятся видимыми, предприятие начинает видеть свои маршруты.
А когда маршруты связаны с БП, 1С:ERP, ролями, документами, регламентами, инструкциями, KPI, тестовыми сценариями и стресс-вопросами, появляется основа для настоящей автоматизации и управленческой проверки предприятия.
А автоматизации как управляемого перехода от живого опыта сотрудников к работающей цифровой модели предприятия.
Читайте дальше. "Зачем производственному предприятию собственный интеллект, а не цифровые ИИ-бусы"
Кирилл Ледовский
ERP-Мастер / «Электронная фабрика»
1С:ERP, бизнес-архитектура, сценарные цепочки, визуальные атласы процессов