R1.1 Задания ЦС, эксплуатация, польза, создатели, действия

Моя должность менеджер ИТ продукта WMS (управление складом) в маркетплейсе в Казахстане.
Текущий рабочий проект: Интеграция с новой логистикой СДЭК.
Это третий подход к разбору ЦС и создателей в компании.
Первый подход - Целевая система в моём софте в Teez - #8 от пользователя ilia-kukhar
Второй подход - разбор тех же систем но с вьюпоинтом в другом проекте: Системы моего проекта для s2r репозитория

Задача поста: Описываете систему, ситуации её эксплуатации и извлекаемую из эксплуатации пользу, создателей системы, действия по созданию системы. Это будет «нулевая» версия вашего рассуждения (0.1).

Что я понял ранее:
Вещь 1: конкретный товар в момент его использования.
Создатели: Селлер::партнёр, подсистемы в б2б домене, моя пара систем двойников.
Вещь 2: деньги::выручка селлера.
Создатели: тут надо подумать над графом.
Вещь 3: деньги::наша выручка/комиссия.
Создатели: тут надо подумать над графом.

UPD по Заданию 1.2
Что я понял после обработки критики от клода с FPF, ознакомлением его с моими паками предметной области и разбора с Виктором.

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

-Ты точно сказал: все слова в определении важны. Я схлопнул «ИТ-продукты поддержки логистики» до «складская логистика» и потерял различение между системой-создателем и физическим процессом. А оно ключевое — именно через него видно, что посылка это ЦС, а не «предмет трансформации».

Итог:

Целевая система

Правильно собранная и вовремя доставленная посылка

Физический объект с FSM состояний (MP.ENTITY.001), проходящий путь от создания заказа до вручения получателю. Acceptation criteria: правильный состав, без брака, в срок SLA (MP.ENTITY.003).

Система создания

Два ИТ-продукта поддержки логистики — цифровые двойники физических процессов:

Продукт Физический двойник Этап жизненного цикла посылки
WMS Складская логистика Приёмка товара → хранение → сборка → отгрузка
PVZ Работа ПВЗ Приёмка посылки на ПВЗ → выдача клиенту

Оба продукта — U.Episteme (описания), которые описывают и меняют физические системы (склад, ПВЗ). Архитектура цифрового двойника — event-driven (DP.SOTA.001), персистенция через event sourcing (DP.SOTA.004).

Моя роль

Автоматизатор процессов поставки (TransformerRole, A.3). Связывает причины проблем/узких мест в физической системе с решениями в цифровом двойнике. Меняет физическую систему через WMS и PVZ — добавляет роли агентам, меняет методы работы текущих ролей.

Метрики качества ЦС

Этап 1 — WMS (запуск товаров к продаже):

  • Количество брака

  • Количество потерянных товаров

Этап 2 — PVZ (выдача заказов клиенту):

  • Вовремя доставленные заказы (SLA compliance)

  • Доставлено то, что нужно (правильность сборки, целостность)

Расширяющийся контур ЦС

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

Цепочка создания (движение вещей)

Товар от поставщика → Склад [WMS] → Хаб → ПВЗ [PVZ] → Клиент
                      \___________ моя зона ответственности ___/

Сеть доставки по MP: склад → хаб → ПВЗ → курьер → получатель (MP.ENTITY.002).
_____________________

R1.1.3 Ситуации эксплуатации и польза

Ситуация 1 — Самовывоз (M1 / SP, PP)

Покупатель приходит в ПВЗ, называет номер заказа. Оператор ПВЗ находит посылку, верифицирует получателя, выдаёт. Покупатель вскрывает посылку — товар соответствует заказу, в целости.

  • Место: пункт выдачи заказов

  • Время: в часы работы ПВЗ, в пределах срока хранения

  • Частота: десятки выдач в день на одном ПВЗ

Польза: покупатель получил нужный товар в срок — потребность закрыта. Селлер получает выручку. Teez получает комиссию. SLA выполнен.


Ситуация 2 — Доставка курьером до двери (M2 / PA, AA)

Курьер приезжает по адресу в согласованное окно. Вручает посылку получателю, фиксирует доставку в приложении Coube.

  • Место: адрес получателя

  • Время: согласованный интервал доставки

  • Частота: маршрут курьера — 10–30 посылок в день

Польза: покупатель не тратит время на поездку в ПВЗ. Для товаров 21+ (алкоголь) — единственно возможный сценарий. SLA выполнен.


Польза для каждой из сторон:

Сторона Польза
Покупатель Получил нужный товар, в целости, вовремя
Селлер Выручка разблокирована после подтверждения доставки
Teez Комиссия с продажи + операционный доход TeezPost
Отправитель (B2B) Посылка доставлена получателю по SLA без собственной курьерской службы

Создатели системы и действия по созданию

Агент Эпистема Действие Переход FSM
Складской оператор WMS Принимает товар от селлера, верифицирует, размещает на хранение created → at_warehouse
Складской оператор WMS Собирает заказ по заданию, упаковывает, клеит этикетку at_warehouse → sorted
Водитель Вывозит партию посылок со склада на хаб / ПВЗ sorted → in_transit → at_hub / at_pvz
Администратор ПВЗ PVZ Принимает партию от водителя, сканирует каждую посылку → at_pvz
Администратор ПВЗ PVZ Создаёт маршрутный лист на курьера → передаётся в LM app как заявка → out_for_delivery
Диспетчер LM app (веб) Редактирует заявку (проставляет точный адрес), назначает курьера
Курьер LM app (мобильное) Доставляет посылку до двери / клиент забирает в ПВЗ → delivered

Критерии приёмки целевой системы (acceptanceSpec)

Критерий Метрика
Правильно собрана Состав заказа соответствует заказанному; нет брака при сборке
Вовремя доставлена delivered_at ≤ sla_deadline (SLA compliance rate)
Целостность Нет повреждений при транспортировке; нет потерь

Если ваша система - работающий на складе ИТ-продукт поддержки логистики, то правильно собранная и вовремя отправленная посылка - это нормальная целевая система.

Обратите внимание - все слова в этих определениях важны!

Сделку в целом и оплату как её часть - можно включать в расширяющийся контур целевых систем, учитывая ИТ-системы финансового учёта, платежные системы и т.п. Если текущий проект - это интеграция логистической системы с логистикой внешней, то в сторону сделки можно, видимо, пока не двигаться.

1 лайк

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

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

так?

да

Это метрики описывают как работают ваша система, ЦС(как выопределил в пости) это один доставленный продукт.