STAR GROUP

TO BE • V1.4 RU
4 СЕНТЯБРЯ 2026

Архитектура корпоративных программных систем

Единая операционная архитектура с 1С:УТ в центре

1С:УТ становится центральной System of Control, а WMS и 1С:Бухгалтерия — постоянными доменными системами. На этапе 1 ProTarget работает как переходный SFA/TMS-контур для обеспечения непрерывности операций. После стабилизации core-контура на этапе 2 выбирается Linko, Doctor Sales или собственная SFA-система, ProTarget заменяется, а PRBC подключается через Integration Platform.

1С:УТоперационный мастер • контрольная точка • официальный источник данных о товарах, заказах и статусах операционных платежей

Основание32 процесса и 302 узла аудита

Этап 1ProTarget — переходный контур • 1С:УТ • WMS • Бухгалтерия

ПлатформаIntegration Platform • Gateway • DWH

Этап 2Целевая SFA + PRBC • отдельные решения Go/No-Go

01 / Executive view

Архитектурные решения, требующие утверждения руководства

0220 страниц

ФАКТ АУДИТАРЕШЕНИЕ TO BEТРЕБУЕТ СОГЛАСОВАНИЯ

1С:УТ — System of ControlЕдиная НСИ, официальный заказ, резерв, реализация, статус операционного платежа и контрольная точка.

ProTarget — переходная SFA/TMS этапа 1Временно сохраняется для непрерывности операций; реализуются только необходимые core-интеграции, неограниченный backlog поставщика не финансируется.

WMS — warehouse executionЯчейка, задание ТСД, план/факт, комплектация, погрузка и физический факт возврата относятся к WMS.

Единая Integration PlatformAPI Gateway, services, RabbitMQ, canonical model, mapping, Outbox/Inbox, журналирование, retry и DLQ — основа замены SFA.

PRBC — System of Engagement этапа 2Финансовый workflow, платёжные запросы, контроль баланса, внутренний чат, задачи и документооборот подключаются после стабилизации core-контура.

PRBC не является финансовым masterPRBC управляет запросами и согласованиями; официальный баланс, лимит, факт оплаты и проводки поступают из 1С:УТ/1С:Бухгалтерии.

Payment/Fiscal Gateway — модуль платформыSplit tender, маршрутизация провайдера, подписанный callback, фискальный статус и сверка; внешние поставщики находятся за адаптерами.

1С:Бухгалтерия — финансовый и налоговый контурНе является операционным master; получает подтверждённые документы из УТ и возвращает результаты банка, налогов и проводок.

DWH → Power BI — аналитическая истинаАналитика опирается не на production DB или Excel, а на исторические витрины данных с контролем lineage и DQ.

DMS — источник миграции и read-only архивПосле ETL, репетиций и сверки приём новых операций прекращается; история хранится согласно политике retention.

Прямая запись в БД и vendor lock-in запрещеныCore-интеграции используют независимый от поставщика API/event-контракт SFA; Excel/Telegram не являются официальной транзакцией.

ProTarget заменяется на этапе 2Linko, Doctor Sales и собственная SFA оцениваются по fit-gap, трёхлетнему TCO, API, переносимости данных и PoC; выбирается только вариант, прошедший gate.

Главный принцип: 1С:УТ — не монолит, поглощающий все функции. Она является единой System of Control, а WMS отвечает за исполнение складских операций. ProTarget используется только как переходная System of Entry на этапе 1. На этапе 2 выбранная или разработанная SFA бесшовно принимает эту роль, а PRBC подключается как System of Engagement. Ни одна из этих систем не становится финансовым мастером.

Ожидаемый бизнес-результат

Один заказ — один номер — один статус

Продажи, склад, экспедитор, касса и бухгалтерия работают по единому идентификатору документа.

Результат контроля

Деньги видны в течение дня

Раздельно отражаются ожидаемые, принятые, фискализированные, переданные в кассу суммы и расхождения.

Технический результат

Ошибки не теряются

Каждый интеграционный запрос журналируется, защищается от дублирования и при сбое повторно обрабатывается из очереди.

02 / Evidence base

На чём основано предложение

03Редакция аудита 3

32процесса охвачено аудитом5а–5г — отдельные потоки

302узла уровня Miro280 AS IS + 22 узла плана

37рисков и проблем4 критических • 8 высоких

11системных и бизнес-контуровв разрезе 11 подразделений

24/32процесса с участием DMSтекущая центральная зависимость

Уровень автоматизации операций AS IS

Вручную

215

Автоматически

Не определено

Расчёт: 280 узлов AS IS; плановые узлы исключены.

Приоритет рисков

Критические

Высокие

Средние

Не оценены

Деньги и фрод

Кассовый контроль запаздывает

Смешанный платёж отражается как 100% наличный; деньги у экспедитора не видны онлайн; расхождение может скрываться до 30 дней.

Риски аудита 2, 9, 13, 23, 25

Данные и учёт

Системы видят разную картину

DMS и 1С:Бухгалтерия не полностью синхронизируют изменения; статусы WMS не возвращаются; причина расхождений остатков не установлена.

Риски 12, 19, 22, 26, 37

Процессы и управление

Excel стал операционным слоем

Excel используется минимум в 12 из 32 процессов; задания, согласования, сверки и отчёты связываются вручную.

Процессы 1, 2, 4, 5б, 5в, 11, 13–16, 20, 25

Граница доказательности: сроки в аудите противоречивы, поэтому roadmap опирается не на даты, а на gates. Модули PRBC и функционально-стоимостная проблема ProTarget — новые управленческие исходные данные; они подтверждаются через TCO, fit-gap и PoC.

03 / AS IS diagnosis

Ключевые разрывы текущей архитектуры

04Карта проблем

Текущий системный поток — упрощённая схема, подтверждённая аудитом

01ProTarget • переходный контурSFA/TMS работает, однако остаются открытые функции, backlog поставщика и давление на TCO

02DMS24/32 процесса • ручное проведение и перепроведение

03WMS + ТСДскладской документ поступает; статусы возвращаются не полностью

Разрыв с 1С:Бухгалтерией

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

Разрыв платежей

Наличные, карта, QR и Click объединяются в одну запись как наличный платёж.

Разрыв аналитики

DMS → Excel → Power BI; локальный файл и децентрализованное резервное копирование.

Критическая причина: между системами не определены единый идентификатор документа, модель статусов, интеграционный журнал и владелец данных.

Критический

Нет онлайн-контроля денег

Кассир не видит ожидаемую сумму; план/факт и типы оплаты по экспедитору не разделены.

Высокий

Ручное перепроведение

Реализация, смена экспедитора и статус отчёта зависят от повторных действий оператора.

Высокий

План/факт в Excel

WMS не рассчитывает расхождение автоматически; DMS не видит полные статусы приёмки.

Системный

Операторские функции внутри IT

Ручное ведение точек, акций, планов и маршрутов занимает ресурс IT.

Double entryОдин факт вручную вводится в несколько систем.

Hidden failuresДетали ошибок PostPoint и WMS не возвращаются пользователю.

Shadow processExcel, Telegram и бумага выполняют роль официального потока.

Риск поставщика и владенияBacklog и стоимость ProTarget, а также владение процессами, системами и НСИ не управляются как единый риск.

04 / Target architecture

Целевая архитектура с 1С:УТ в центре, готовая к замене SFA

05Модель V1.4

05 / Application portfolio

Роль и целевая судьба каждой системы

06Сохранить / изменить / вывести

Система	Роль TO BE	Решение	Граница / результат
1С:УТ	Центральная System of Control	BUILD / CORE	Единая НСИ, официальный заказ, резерв, реализация, статус платежа и возврат
ProTarget	Текущая SFA/TMS System of Entry	STAGE 1 TRANSITION	Непрерывность + необходимые API; ограничение backlog/TCO; вывод после cutover целевой SFA
Целевая SFA	Будущая System of Entry для продаж/TMS	STAGE 2 SELECT / BUILD	Linko, Doctor Sales или собственная SFA; fit-gap + 3Y TCO + PoC + миграция
WMS + ТСД	Исполнение складских операций	KEEP + 1C INTEGRATE	План/факт, ячейки, комплектация/погрузка, расхождения и факт возврата
PRBC	Корпоративная System of Engagement	STAGE 2 / INTEGRATE	Финансы, платёжные запросы, просмотр баланса, чат, задачи и внутренний документооборот
1С:Бухгалтерия	Финансовый и налоговый учёт	KEEP + RE-SCOPE	Документы УТ; банк, налоги, проводки и статус исполнения платежа
Integration Platform	Управляемый обмен	NEW / CORE ENABLER	API Gateway, services, RabbitMQ, canonical model, mapping, Outbox/Inbox
Payment/Fiscal Gateway	Модуль платежей/фискализации платформы	NEW	Split tender, адаптеры, подписанный callback, статус чека и сверка
DWH / Data Mart	Слой исторической аналитики	NEW	Неизменяемая история, lineage, DQ; события SFA/PRBC на этапе 2
Power BI	Управленческая аналитика	KEEP + REWIRE	Только DWH/data mart; production DB и Excel не являются master
DMS	Legacy / источник миграции	MIGRATE → RETIRE	Репетиции + сверка → закрытие записи → read-only архив
Excel/Telegram/бумага	Теневые операции	REMOVE FROM CORE	Экспорт, уведомления и аварийные доказательства; не официальные транзакции или согласования
1С:ЗУП / UZGPS	Будущий отдельный контур	OUT OF CORE SCOPE	Отдельный charter/fit-gap; не блокирует cutover core, SFA или PRBC

Постоянное ядро: 1С:УТ, WMS, 1С:Бухгалтерия, Integration Platform, Gateway и DWH. ProTarget остаётся только на этапе 1 как контур непрерывности операций.

SFA этапа 2: Linko, Doctor Sales и собственная разработка оцениваются по единой scorecard: fit-gap, трёхлетний TCO, API, SLA и пилотный PoC; победивший вариант заменяет ProTarget.

Выводятся: После сверки DMS переводится в режим read-only/архив, а ProTarget — после cutover целевой SFA. Excel и Telegram не являются официальными транзакционными каналами.

06 / Data ownership

Где данные создаются и где считаются официальными

07Создание ≠ master

Сбалансированное правило: На этапе 1 коммерческие черновики создаёт ProTarget, а на этапе 2 — выбранная целевая SFA. PRBC ведёт внутренние запросы, согласования, задачи, чат и документооборот. 1С:УТ и 1С:Бухгалтерия остаются официальными источниками операционных и финансовых фактов; PRBC показывает баланс, но не пересчитывает его и не создаёт второй master.

Данные	Создание/инициация	Authoritative master	Потребитель	Контроль
Единая НСИ, SKU, штрихкод, ИКПУ, единица, цена	1С:УТ / утверждённый workflow владельца	1С:УТ	Действующая SFA, WMS, Бухгалтерия, Gateway, просмотр PRBC	Версия, срок действия и независимый от поставщика mapping
Кандидат клиента и торговая точка	Действующая SFA: ProTarget → целевая	1С:УТ (после валидации)	SFA, WMS, Бухгалтерия, просмотр PRBC	Черновик/принят/отклонён + canonical ID
Договор, кредит и условия оплаты	Черновик в действующей SFA; внутреннее согласование PRBC	1С:УТ	SFA, Бухгалтерия, PRBC	0/30/50/70%, лимит, срок и версия
Черновик заказа	Действующая SFA: ProTarget → целевая	1С:УТ (после приёмки)	WMS, Бухгалтерия, DWH, просмотр PRBC	Локальный ID SFA + canonical order ID
Резерв, реализация и операционное закрытие	1С:УТ	1С:УТ	SFA, WMS, Бухгалтерия	Lifecycle не меняется при замене SFA
Ячейка, задание ТСД, план/факт, физический возврат	WMS	WMS	1С:УТ, действующая SFA	Событие с actor/device/time
Маршрут, экспедитор и факт доставки	Действующая SFA/TMS	Действующая SFA	1С:УТ, WMS, DWH	Версия назначения и код причины
Платёжная транзакция и технический фискальный статус	Payment/Fiscal Gateway	Gateway	1С:УТ, действующая SFA, Бухгалтерия	Каждый способ оплаты отдельно; подписанный callback
Официальный статус оплаты, задолженность и баланс	1С:УТ; результат банка/проводки из Бухгалтерии	1С:УТ / 1С:Бухгалтерия по доменам	SFA, PRBC, DWH	Фронты только читают; актуальность/сверка
Проводки, банк, налоги и исполнение платежа	1С:Бухгалтерия	1С:Бухгалтерия	1С:УТ, статус PRBC, DWH	Matched/unmatched/rejected reference
Внутренние запросы, согласования, чат, задачи, документооборот	PRBC	PRBC	Integration Platform, DWH; разрешённые события в core	RBAC/SoD, retention, аудит; не финансовый факт
Исторический аналитический факт	Integration/DWH pipeline	DWH	Power BI	Source lineage, source_version SFA и DQ

Golden record

1С:УТ

Единая НСИ, официальный заказ, резерв, реализация и статус операционного платежа.

System of Entry • переходный контур

ProTarget → целевая SFA

Единый канонический контракт: черновик клиента/договора, заказ, TMS, факт доставки и возврата.

Physical truth

WMS

Ячейка, задание ТСД, план/факт, комплектация, погрузка и физический возврат.

System of Engagement

PRBC • этап 2

Внутренние запросы, согласования, задачи, чат и документооборот; финансовые факты здесь не создаются.

07 / Integration catalogue

Интеграционные потоки — основной операционный контур

08INT-01 … INT-08

ID	Поток	Payload	Pattern	Ошибка / приёмка
INT-01	1С:УТ → SFA/WMS	НСИ и цены	Event + delta API	Независимый от поставщика payload; ошибка mapping → DLQ
INT-02	SFA-фронт → 1С:УТ	Черновик клиента/договора	Sync API	Принят/отклонён + причина + canonical ID
INT-03	SFA-фронт → 1С:УТ	Заказ	Sync API	Идемпотентное создание; возвращается официальный order ID
INT-04	1С:УТ → SFA-фронт	Валидация, резерв, причина блокировки	Event/webhook	Пользователю возвращаются статус и business reason
INT-05	1С:УТ ↔ WMS	Задания и факты inbound/outbound/return	Контролируемая интеграция 1С	Канонические документ/строки; без прямой записи в БД
INT-06	WMS → 1С:УТ/SFA	План/факт и статус	Event	Код статуса, время, actor/device, расхождение
INT-07	SFA TMS → УТ/WMS	Маршрут/экспедитор	Event	Версия назначения; без перепроведения
INT-08	SFA-фронт → 1С:УТ	Факт доставки	Sync + event	Delivered/partial/failed + факты по строкам

correlation_id

Заказ и все его дочерние документы отслеживаются в одной цепочке.

Защита от дублей

idempotency_key

Повторный webhook не создаёт новый платёж или реализацию.

Надёжность

retry + DLQ

Временная ошибка обрабатывается повторно; неисправленное сообщение остаётся в очереди исключений.

Аудируемость

business + tech log

Кто, когда и что отправил, что принято и почему отклонено.

07 / Integration catalogue

Интеграционные потоки — финансы, PRBC и миграция SFA

09INT-09 … INT-19

ID	Поток	Payload	Pattern	Ошибка / приёмка
INT-09	SFA-фронт → Payment/Fiscal Gateway	Платёж/фискальный запрос при доставке	Sync API	order/lines/tenders; signed + idempotent
INT-10	Gateway → УТ/SFA/Бухгалтерия	Результат оплаты/фискализации	Webhook/event	txn ID, cheque ID, статус, детали ошибки
INT-11	1С:УТ ↔ 1С:Бухгалтерия	Реализация, возврат, платёж, банковский/налоговый статус	Контролируемая интеграция 1С	Canonical ID, matching и сверка
INT-12	WMS/SFA → УТ → Бухгалтерия	Возврат	Saga/event	Отслеживаются физический и финансовый этапы
INT-13	Платформа → DWH	События core-бизнеса	Streaming/batch	Неизменяемая история, lineage и DQ
INT-14	DWH → Power BI	Утверждённая витрина данных	Semantic model/refresh	Нет прямого чтения production DB
INT-15	PRBC → Платформа → 1С:УТ/1С:Бухгалтерия	Платёжный/бюджетный/лимитный запрос, согласование, ссылка на документ	API + event • этап 2	Gate стабильности core, SoD, идемпотентность, аудит
INT-16	1С:УТ/1С:Бухгалтерия → Платформа → PRBC	Баланс, лимит, платёж и статус документа	Query API + event • этап 2	Официальный источник, актуальность, masking, сверка
INT-17	PRBC → Платформа → DWH	Метаданные запросов/согласований/задач/документов/чата	Event/batch • этап 2	Retention, область доступа и lineage
INT-18	DMS → Migration staging → 1С:УТ	Миграция legacy	ETL + сверка	Источник read-only; checksum и отчёт об исключениях
INT-19	ProTarget → SFA staging → целевая SFA/УТ	Клиенты, маршруты, черновики/open orders и необходимая история	ETL/API + сверка • этап 2	Экспорт данных, checksum, пилот, rollback и freeze источника

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

Асинхронное событие: складские и фискальные статусы, события BI, согласований, задач и документов PRBC, а также состояния, допускающие задержку обработки.

Запрещается: общая таблица БД, прямая SQL-запись и корректировка статуса без журналирования. Жёсткая привязка контракта SFA к внутренним ID и модели ProTarget также запрещена: при замене целевой SFA core-системы не должны переписываться.

08 / End-to-end process

От заказа до финансового закрытия

10Order-to-Cash

01SFA-фронтProTarget → целевая SFA; агент создаёт черновик заказа

021С:УТпроверяет клиента, договор, кредит, цену и остаток

03WMSвыполняет комплектацию, контроль и погрузку

04SFA/TMSфиксирует маршрут, доставку и факт возврата

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

061С:УТ → Бухгалтерияоперационное и финансовое закрытие

Автоматические контроли 1С:УТ

действительность клиента и договора
правило предоплаты 0/30/50/70%
кредитный лимит и просроченная задолженность
цена, акция и право на скидку

остаток и резерв
статус блокировки/стоп-листа
единый штрихкод/ИКПУ
дубликат заказа и правило даты

Exception handling

Отклонение — не потеря

Бизнес-отказ не смешивается с технической ошибкой. Заказ остаётся в статусе «blocked» с кодом причины, ответственной ролью и маршрутом повторного рассмотрения.

превышен кредитный лимит
договор недействителен
нет маппинга SKU
недостаточно резерва

Сквозная цепочка документов

Черновик заказа SFAзаказ УТрезерв УТзадание WMSотгрузкафакт доставкиоплата/фискализацияфинансовое закрытие

На каждом этапе сохраняются source_id + canonical_id + correlation_id. На этапе 1 фронтом SFA в этой цепочке O2C является ProTarget; на этапе 2 тот же канонический API/event-контракт принимает целевая SFA. PRBC не входит в критический синхронный путь O2C и работает только через Платформу с разрешёнными workflow и статусами.

09 / Warehouse execution

Целевой поток приёмки, комплектации, погрузки и возвратов

11WMS + ТСД

Inbound / приёмка

ОжидаетсяПринимаетсяРасхождениеПринято/ОтклоненоРазмещено

1С:УТ отправляет в WMS подтверждённый плановый документ
ТСД фиксирует факт по SKU/серии/сроку годности
WMS автоматически рассчитывает план/факт
при расхождении создаются электронный акт и workflow
УТ принимает только подтверждённый складской факт

Outbound / комплектация и погрузка

ОчередьКомплектацияКонтрольСтейджингПогружено

WMS выдаёт задание по ячейке и загрузке
изменение приоритета возвращается как событие
«out of stock» выделяется отдельным кодом причины
этап доставки не открывается без факта погрузки
1С:УТ и действующий SFA-фронт видят статус почти в реальном времени

Return-to-stock / возврат

01SFA-фронтProTarget → целевая SFA; позиция, количество, причина, фото и подтверждение клиента

021С:УТразрешение на возврат и ожидаемая приёмка

03WMS/ТСДфизическая приёмка, решение по качеству и годности

041С:УТкорректировка остатков и баланса клиента

051С:Бухгалтериядокумент финансовой/налоговой корректировки

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

Устраняется: план/факт в Excel и уведомление по email.

Устраняется: только статус «проведено/отменено» в DMS.

Проверяется: версия WMS и фактическое покрытие по филиалам.

10 / Money control

Платежи, фискализация и кассовая сверка

12Payment/Fiscal Gateway

01ExpectedУТ рассчитывает ожидаемую сумму по заказу

02CaptureЭкспедитор выбирает способы оплаты в мобильном приложении

03ProcessGateway направляет запрос банку/QR/POS/фискальному провайдеру

04ConfirmВозвращаются статусы транзакции и чека

05CollectКассир принимает деньги в разрезе экспедиторов

06ReconcileУТ/Бухгалтерия закрывает план-факт или создаёт исключение

Split payment

Один заказ — несколько способов оплаты

Наличные, карта, Click, Payme и Rahmat/QR сохраняются как отдельные транзакции; их сумма сверяется с суммой заказа. Это поток денег, принятых от клиента, тогда как «управление платежами» в PRBC — корпоративный workflow платёжных запросов и согласований.

Fiscal control

Состав чека на уровне позиций

SKU, штрихкод, ИКПУ, количество, цена, налог и скидка берутся из официальных данных 1С:УТ.

Provider independence

Провайдер через адаптер

Выбор PostPoint, SmartPOS или ePOS не требует перестройки кода действующей SFA/1С:УТ; тот же принцип адаптеров сохраняется при переходе с ProTarget на новую SFA.

Рабочее место кассира — в разрезе экспедиторов

Показатель	Значение
Ожидается	Сумма, которую необходимо сдать по доставленным заказам
Принято	Сумма в реальном времени по наличным/карте/QR/Click
Фискализировано	Часть, подтверждённая ID чека и фискальным статусом
Сдано	Деньги, фактически переданные экспедитором в кассу
Расхождение	Ожидалось − принято/сдано; причина и ответственный

Fail-safe

Фискальная ошибка не закрывает заказ скрыто

бизнес-платёж и фискальный статус разделены
подпись callback провайдера проверяется
повторный callback обрабатывается идемпотентно
лимит повторов и dead-letter queue
ручная корректировка — только с комментарием и audit log
выдача клиенту электронного/печатного чека подтверждается

11 / Control model

Единая модель статусов и закрытие дня

13State machines

Заказ

ЧерновикВалидацияЗаблокированПодтверждёнРезервWMSПогруженДоставкаЗакрыт

Платежи и фискализация

ОжидаетсяИнициированоАвторизованоОжидает фискализацииФискализированоПринятоСвереноЗакрыто

Платёжный запрос PRBC • этап 2

ЧерновикОтправленСогласование руководителяФинансовый контрольСогласовано / ОтклоненоПередано в УТ/БухгалтериюИсполненоСверено

Исключения

Бизнес-отказТехническая ошибкаОчередь повторовРучная проверкаРешено

Правила закрытия дня

Для всех доставленных заказов рассчитывается ожидаемая сумма.
Платёжные транзакции агрегируются по типам оплаты.
Проверяются статус фискального чека и сумма провайдера.
Баланс экспедитора закрывается актом сдачи в кассу.
При расхождении смена остаётся в статусе «exception».
День закрывается только после подтверждения причины и решения ответственной ролью.

Банковский платёж

Банковская выписка автоматически загружается в 1С:Бухгалтерию.
Сопоставление по контрагенту, договору, сумме и назначению.
Подтверждённое платёжное событие возвращается в 1С:УТ.
Неидентифицированная сумма попадает в очередь исключений.
Оператор только разбирает исключение, не вводя данные повторно.

Отменяется: ежемесячная фотосверка, запись «100% наличные», закрытие предыдущего дня без сравнения с ожидаемой суммой и слепая отметка «оплачено» по Excel-выписке.

12 / Data & engagement

Контур интеграции DWH, Power BI и PRBC

14Read model + workflow

ИСТОЧНИКИ1С:УТ • WMS • SFA-фронт • 1С:Бухгалтерия • PRBC*SFA: ProTarget → целевая система; PRBC — только на этапе 2

ПРИЁМIntegration Platformвалидация схемы • mapping • lineage • журнал ошибок

ХРАНЕНИЕDWH / Data Lakehouseистория • факты/измерения • медленно изменяемая НСИ

ВИТРИНЫData Martпродажи • запасы • деньги • финансы • workflow

ИСПОЛЬЗОВАНИЕPower BIролевые дашборды и управленческие KPI

Правило Power BI

Нет прямого подключения к production DB

Отчётная нагрузка не замедляет операционные системы; показатели берутся из пересчитываемой витрины данных с контролируемыми lineage и DQ.

Правило PRBC

System of Engagement, а не master

PRBC управляет внутренней работой. Официальными источниками финансового факта, баланса, лимита и проводок остаются 1С:УТ и 1С:Бухгалтерия.

Правило NAS

Резервные копии и файлы, но не БД

NAS может хранить документы, файлы и резервные копии; он не является интеграционной БД реального времени или master-источником Power BI.

Рекомендуемые витрины данных

Sales	order, line, price, discount, client, agent
Warehouse	stock snapshot, movement, pick, discrepancy, return
Доставка	route, expeditor, stop, delivered/partial/failed
Cash	expected, collected, fiscalized, handed-over, variance
Finance	receivable, bank matching, realization, correction
Workflow	запросы PRBC, согласования, SLA, статусы задач и документов

Шесть модулей PRBC и граница интеграции

Финансовый блок: просмотр бюджета/лимита и внутренние запросы
Управление платежами: платёжный запрос, маршрут и согласование; исполнение в 1С:Бухгалтерии/1С:УТ
Контроль баланса: чтение официального баланса через Платформу, контроль актуальности и сверка
Внутренний чат: сообщения, файлы и контекст с политиками retention/RBAC
Управление задачами: владелец, SLA, Kanban и эскалация
Внутренний документооборот: версии, согласование и аудит; без прямой записи в БД

13 / Security & reliability

Требования к безопасности, инфраструктуре и качеству сервиса

15Предлагаемые NFR

Identity

AD/SSO + MFA

Централизованный жизненный цикл пользователей, ролей, устройств и администраторских прав. PRBC также подключается к корпоративным SSO/MFA; при увольнении доступ автоматически отзывается.

Access

RBAC + SoD

Права кассира, экспедитора, оператора, бухгалтера, инициатора/согласующего PRBC и администратора разделяются; self-approval и сочетание request + approve + pay в одной роли запрещены.

Trace

Immutable audit log

Платёж, лимит, договор, согласование PRBC, задача, версия документа, модерация чата и ручной override журналируются с указанием исполнителя.

Resilience

Backup + DR test

Критерием приёмки служат не наличие backup, а результат тестового восстановления и runbook.

NFR	Предлагаемый target	Комментарий
Availability	≥99.9% в операционном окне	подтверждается нагрузкой и SLA вендоров
API latency	p95 ≤3 с	валидация и пользовательские запросы
Event delay	в норме ≤60 с	события статусов WMS/фискализации/PRBC
RPO	core ≤15 мин	1С:УТ и состояние интеграции
RTO	core ≤4 часов	измеряется DR-тестом
Message safety	0 неотслеживаемых потерь	за счёт DLQ и сверки

Эти значения не являются замерами аудита — это целевые TO BE показатели, утверждаемые в ТЗ и нагрузочном тесте.

Инфраструктурные зависимости из аудита

отдельная VM и фактический замер ресурсов для 1С:УТ
резерв мощности на период параллельной работы с DMS
центральный firewall, защита endpoint и сегментация сети
топология серверов/сети и реестр активов
автозапуск и мониторинг принтеров/VM WMS
стратегия хранения Kerio/NAS — отдельный проект

Риски аудита 14, 27–31

Service account: интеграции не работают под личными учётными записями.

Безопасность этапа 2: для целевой SFA обязательны SSO/RBAC, безопасность API, экспорт данных, pentest и DR; для чатов и документов PRBC — retention, шифрование и DLP.

Мониторинг: технический alert отделяется от бизнес-исключения; также контролируются SLA и очереди PRBC.

14 / Operating model

Роли и ответственность — в разрезе функций

16RACI

Деятельность

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

IT/Архитектура

InfoSec

Операционная роль

Правила и KPI процессов core/SFA/PRBC

Выбор SFA, 3Y TCO и PoC

НСИ и качество данных

ТЗ, независимый от поставщика API и security baseline

A R

Разработка/тест интеграций и миграции

A R

UAT/приёмка core, целевой SFA и PRBC

A R

Релиз, rollback и gate этапа 2

Поддержка L1 и пересмотр доступов

Responsible

Фактически выполняет работу.

Accountable

Владелец итогового решения и результата.

Consulted

Участвует как эксперт до принятия решения.

Informed

Получает информацию о результате/статусе.

Обязательный жизненный цикл изменений

01Владелец процессапроблема, KPI и ожидаемый результат

02Регламентроль, триггер, правило, исключение

03Бизнес-требование / ТЗданные, API, безопасность, тесты

04Разработка + тестинтеграция, UAT, производительность

05Релиздокументы, обучение, поддержка, rollback

Граница ответственности: Владельцы процессов продаж, склада и финансов отвечают за правила core-контура; product owner SFA — за функциональный scope, TCO и миграцию; владельцы модулей PRBC — за workflow, SLA, согласования и сроки хранения контента. IT отвечает за платформу, интеграции, мониторинг, безопасность и поддержку, но не за ежедневные операторские операции.

15 / Transition roadmap

Последовательность перехода core-контура, целевой SFA и PRBC

17Волны 0–11

Governance и baseline

Владельцы процессов/данных/PRBC/SFA, модель статусов, core scope и charter этапа 2

G0: утверждён architecture charter

Инфраструктура и security foundation

VM 1С:УТ, backup/restore, мониторинг, AD/SSO/RBAC, service account

G1: пройдены тесты восстановления и доступа

MDM и очистка данных

SKU, штрихкод, ИКПУ, клиент, договор, цена, mapping и дубликаты

G2: 100% критических master-data сопоставлено

Каркас Integration Platform

Независимый API SFA, RabbitMQ, canonical ID, mapping, Outbox/Inbox, DLQ

G3: пройдены тесты failure/retry/replay

Переходный MVP ProTarget ↔ УТ ↔ WMS

Только необходимые потоки заказа, резерва, статусов WMS, доставки/возврата и pay/fiscal

G4: UAT core O2C; freeze backlog

Payment/Fiscal + 1С:Бухгалтерия

Split payment, fiscal, рабочее место кассира, bank matching, корректировка возврата

G5: закрыта ежедневная сверка

DWH / Data Mart → Power BI

События core, DQ/lineage, витрины продаж/запасов/денег/финансов

G6: KPI сверены с источниками

Пилот core и fit-gap региона

Выбранный склад/филиал, offline, локальная фискализация/касса и support runbook

G7: Go/No-Go пилота core

Вывод DMS + стабилизация core

Parallel run, закрытие расхождений, read-only, архив/retention, контроль SLA

G8: запись в DMS закрыта; core стабилен

Этап 2A • выбор SFA / buy-build

Linko, Doctor Sales и собственная SFA: обязательный fit-gap, 3Y TCO, API/export, SLA, security

G9: решение по weighted scorecard

Этап 2A • PoC SFA и cutover

Пилот, mobile/offline/TMS/pay-fiscal, миграция данных, parallel run, rollback; freeze ProTarget

G10: сверка целевой SFA + sign-off

Этап 2B • интеграция PRBC

6 модулей, просмотр официального баланса/статусов, согласование платежей, события задач/чата/документов

G11: UAT PRBC + SoD + финансовая сверка

Подход к срокам: календарная дата и обязательство go-live не фиксируются, пока для каждой волны не утверждены владелец, результат и gate. Противоречивые сроки из аудита не приняты как план.

16 / Acceptance & cutover

Критерии Go / No-Go для core-контура, замены SFA и PRBC

18Stage gates

Обязательный набор сквозных сценариев

1Обычная доставка с оплатой наличными

2Доставка с оплатой картой/QR

3Смешанный платёж

4Сопоставление банковского перевода

5Блокировка по кредитному лимиту

6Частичная доставка

7Полный/частичный возврат

8Расхождение план/факт WMS

9Ошибка фискального провайдера + retry

10Повторный webhook

11Offline/reconnect

12Совместимость API-контракта SFA

13PoC mobile/offline/TMS для SFA

14Экспорт данных ProTarget + checksum

15Параллельные заказы/сверка целевой SFA

16Rollback целевой SFA/freeze ProTarget

17Платёжный запрос PRBC + согласование

18Актуальность баланса PRBC + сверка

19Аудит и доступ к документам/задачам PRBC

Критерии допуска к go-live

1Критических дефектов = 0

2Master mapping утверждён

3Входящие остатки сверены

4Тест дубликатов/rollback

5Тест восстановления backup

6Фискальный чек доставляется клиенту

7Есть L1/L2 runbook и owner

8Monitoring/alert работают

9Security access review

10Business UAT sign-off

11Weighted fit-gap score SFA

12Утверждён 3Y TCO SFA

13PoC API + экспорта данных SFA

14Сверка миграции SFA

15Право выхода/rollback из ProTarget

16Решение по DMS exit/retention

17Стабильность core до PRBC

18UAT PRBC по SoD/RBAC/retention

Parallel run

Сопоставление фактов

Cutover невозможен до сверки остатков, заказов, реализаций, платежей и возвратов.

Rollback

Проверенный путь

Backup/restore и rollback runbook проверяются на практике до релиза.

DMS exit

Только чтение + архив

Новые записи блокируются; история остаётся доступной для чтения согласно политике retention.

Критерии входа в этап 2

SFA и PRBC — отдельные решения Go/No-Go

SFA: scorecard, PoC, экспорт, миграция/rollback. PRBC: версионируемые API/event, SoD, официальный баланс и UAT.

Триггер No-Go: критическое финансовое расхождение, дубликат документа/платежа, непроверенное восстановление backup, неизвестный master mapping, потеря фискального чека или неготовность поддержки L1/L2. Дополнительные No-Go для этапа 2: core-контур нестабилен; SFA не прошла PoC API/экспорта данных или сверку миграции; отсутствует путь выхода/rollback из ProTarget; PRBC ведёт баланс как второй master либо не прошла UAT по SoD/RBAC/retention.

17 / Risk closure

Как критические и высокие риски аудита закрываются в TO BE

19Control mapping

Приоритет

Проблема аудита

Контроль TO BE

Владелец

R-2

Критический

Смешанный платёж отражается как 100% наличный

Split tender + Gateway + платёжный ledger УТ

Финансы + IT

R-4

Критический

Ручная оплата по Excel-выписке

Импорт/matching банка + очередь исключений

Финансы

R-9

Критический

Фотосверка и фрод до 30 дней

Ежедневная кассовая сверка + закрытие смены

Касса/Контроль

R-13

Критический

Деньги у экспедитора не видны онлайн

Рабочее место кассира + expected/collected/variance

Логистика/Финансы

R-1

Высокий

WMS не считает план/факт автоматически

Факт ТСД + workflow расхождений

Склад

R-7

Высокий

Нет IT-бюджета/тендера/план-факта

Отдельное управление IT-закупками

Руководство/IT

R-12

Высокий

Ручное перепроведение реализации

Событийные статусы + идемпотентное проведение

IT/Операции

R-14

Высокий

Слабый реестр активов и актов

CMDB/lifecycle активов + HR offboarding

IT/HR

R-15

Высокий

Кредит и договор ведутся вручную

Rule engine договоров/кредитов УТ

Финансы/Продажи

R-16

Высокий

Экспедитор/территория устаревают

Независимое от поставщика master-событие SFA + версия

Логистика/Продажи

R-18

Высокий

Функция UZGPS не используется

Отдельный fit-gap вне core scope

Транспорт

R-19

Высокий

Изменения DMS и Бухгалтерии разорваны

Канонические документы УТ→Бух + статус возврата

Финансы/IT

Средние риски: BI/закупки, точки/акции, отзыв доступа и загрузка планов закрываются через data governance.

17 неоценённых рисков: включаются в реестр с severity/owner в ходе discovery и fit-gap по филиалам.

Остаточный риск: возможности поставщиков, покрытие филиалов и capacity не отмечаются как «закрытые» без измерений.

Новый управленческий риск: Функциональный backlog ProTarget, несоответствие затрат результату и vendor lock-in контролируются через TCO/PoC; для PRBC предусмотрены отдельные gates по dual master, SoD и retention.

18 / Decision log

Вопросы для утверждения до старта

20Approval pack

Q-01Кто является владельцем workflow согласования клиента/договора и итоговым data steward?

Q-02Каковы покрытие WMS/SFA, локальные процессы и offline-различия по филиалам?

Q-03Кто утверждает единый обязательный функциональный fit-gap для Linko, Doctor Sales и собственной SFA?

Q-04Каков трёхлетний TCO каждого варианта SFA: лицензии, customization, интеграции, support, инфраструктура и внутренняя команда?

Q-05Каковы weighted scorecard и минимальный проходной балл для решения buy versus build по SFA?

Q-06Каковы условия exit, notice, экспорта данных, API, истории/архива и интеллектуальной собственности в договоре ProTarget?

Q-07В каком филиале/складе, с каким числом агентов/экспедиторов и какой peak load проводится PoC целевой SFA?

Q-08Каков план freeze/rollback для open orders, маршрутов, клиентов, договоров и истории при миграции ProTarget → целевая SFA?

Q-09Каковы финальный payment/fiscal provider и правила refund: API, SLA, цена и фискальная корректировка?

Q-10Кто утверждает business/product owner, MVP, SLA баланса, SoD и retention для шести модулей PRBC?

Q-11Каковы capacity, HA/DR и SLA поддержки для 1С:УТ, Платформы, целевой SFA и PRBC?

Q-12Какие должности принимают три отдельных решения Go/No-Go по Core Go-Live, cutover SFA и запуску PRBC?

Рекомендуемое решение: Утвердить документ как концептуальную архитектуру; по завершении Wave 0 принять baseline ТЗ по владению данными, каталогу интеграций, security/NFR и scope пилота. Для этапа 2 утвердить два отдельных charter: (A) fit-gap, TCO, PoC и миграция вариантов Linko, Doctor Sales и собственной SFA; (B) MVP PRBC, SoD и gate стабильности core-контура.

Бизнес-спонсор / руководствоУтверждает scope core-контура, решение buy/build по SFA, бюджет TCO и charter этапа 2 для PRBC.

Дата / решение

Владельцы операций, продукта SFA и модулей PRBCУтверждают обязательные функции, приёмку пилота, статусы/сверку, согласования, SoD, SLA и retention.

Дата / решение

IT-архитектура и безопасностьФиксирует baseline независимого от поставщика контракта SFA, экспорта/миграции данных, NFR, безопасности, API/event PRBC и модели поддержки.

Дата / решение

Основной источник

«Star Group — аудит процессов», редакция 3: 32 процесса, 11 подразделений, 37 рисков, 17 пунктов roadmap и 10 противоречий.

Основа архитектуры

1С:УТ — System of Control; WMS — warehouse execution. На этапе 1 ProTarget является переходной System of Entry, а на этапе 2 заменяется Linko, Doctor Sales или собственной SFA-системой. PRBC подключается только через Integration Platform.

Статус документа

Концептуальное предложение TO BE. Технические параметры, возможности поставщиков и покрытие филиалов подтверждаются через discovery/test.