Что-ж, попробуем.
Я работаю разработчиком в российском маркетплейсе. С переносом реального мире в модели - большие проблемы.
Приведу для начала по пунктам, что есть, а далее, опишу свой мыслительный процесс.
Вещь - предприятие, в котором я работаю, есть маркетплейс, который создает пункты выдачи заказов.
Как она эксплуатируется - сложно сформулировать
Кто получает пользу - смотря в чем измерять пользу. Пока могу выделить три основных актора, которые получают пользу, подчеркиваю, в вакууме:
- Сам маркетплейс, так как он получает проценты с прибыли поставщиков
- Поставщики, так как продают товары с мЕньшими издержками, нежели они продавали в вещи в обычных магазинах
- Клиенты маркетплейса, так как в среднем цена за товар там меньше, нежели в обычных магазинах.
Кто участвует в создании вещи - также выделю основные акторы:
- Логистический актор - хранение товаров, их доставка до пункта выдачи.
- ИТ-актор (обобщим пока до высокоуровневого актора, который включает себя и людей, ответственных за написание ПО, и людей, отвественных за доставку ПО, и аналитиков и так далее) - создают информационную систему, которая обеспечивает работу пунктов выдачи заказов.
- Юридический актор - пункт выдачи заказов должен работать либо как ООО, либо как ИП, а следовательно для простоты официального оформления, согласно законам РФ, и помощи решения юридических инцидентов, потребуется юристы.
- Финансовый актор - решает вопросы, касательно финансов. Например, все финансы хранятся у маркетплейса, а уже сам финансовый актор решает, какую из этих часть финансов выдать владельцам пункта выдачи заказов.
- Актор аналитики - решает вопросы, основанные на данных. Например, в каком районе стоит открывать пункт выдачи, стоит ли продавать определенные товары (будут ли они нужны клиентам)
Какие действия принимаются для создания вещи - это комплекст мероприятий, которые выполняют вышеперечисленные акторы.
Ход моих мыслей
Я работаю разработчиком, которые больше создает инструменты и решения, упрощающие работы другим людей и зачастую это не физические вещи. Из-за этого у меня сложилось проблема в определении того, что на самом деле является физической вещью для моего предприятия. Для начала мне стоило определить следующее: “почему мои инструменты и решения не являются физ. вещью?”. Обратившись к руководству, мои решения больше подходят к категории поведению агентам, так как они упрощают жизнь другим командам и снижают время, на создание других решений, которые и будут нацелены на физический объект. Также мои решения сложно найти в реальном мире и посчитать, так это реализация алгоритма.
Вернемся к определению конечной физической вещи. Мой выбор пал на два варианта: информационная система маркетплейса, где клиенты приобретают товар (пусть будет веб-приложение для простоты) и пункты выдачи заказов.
Я пришел к тому, что сама информационная система не является физической вещью по той причине, что это аналогичный набор сервисов, которые я и сам создаю для внутренних команд, но который просто направленный на клиентов. То есть это агент, который помогает создать конечную физическую вещь.
Пусть на данный момент будет пункт выдачи заказов. Я шел от противного и это не совсем правильно, как мне кажется, потому что лучше выявлять те категории, под которые будет попадать конкретная физическая вещь.
Пока мне сложновато в категориях, данные в руководстве, так как для меня это в новинку.
Да и вопросов пока слишком много, чтобы выдать хоть что-то осмысленное.
Я вполне допускаю, что физической вещью может не оказаться пункт выдачей заказов по той простой причине, что у меня нет паттерна/алгоритма, которому я бы следовал, чтобы корректно и лучше выделять вышеприведенные категории. Будем учиться.