Онтология путешествий объектов

Для описания путешествий объектов нам нужны типы мета-мета-модели. Но «так просто» нам их никто не даст, придётся их восстанавливать самим из данных. Для этого мы можем:

1. Попросить ChatGPT описать онтологию путешествий объектов на предприятии;
2. Проконтролировать типы в составленной онтологии, задействуя знания, полученные по итогам работы согласно этому руководству;
3. Проверим мета-мета-модель, снизив уровень абстракции: возьмем предметную область, в которой принято описывать путешествия объектов, например, маркетинг, попробуем сопоставить типы мета-мета-модели с типами мета-модели путешествий в маркетинге. По итогам сравнения добавим/уберем какие-то типы в мета-мета-модели;
4. Проверить, насколько онтология «рабочая», как минимум на своем предприятии: составим мета-У-модель для предметной области операционного менеджмента, затем – мета-С-модель для нашего предприятия, в ней укажем экземпляры объектов.

Начнем с пункта 1, «попросить ChatGPT описать онтологию путешествий объектов на предприятии». Зачем делать это? ChatGPT может помочь нам получить первую версию онтологии. Как вы уже знаете, первые версии моделей, онтологий и прочих рабочих продуктов неверны, но некоторые из них полезны. Первые версии – это заготовки, которые готовятся для того, чтобы их покритиковать и сделать на основе этой версии рабочего продукта следующую версию, например, следующую версию описания метода, которая уже будет «не совсем плохой»: по описанному алгоритму можно выполнить работы по методу и посмотреть на результат. Сейчас нам нужна именно такая первая версия. Создавать такие первые версии/заготовки довольно долго, кроме того, многим тяжело. А вот покритиковать имеющуюся версию описания куда легче. Поэтому мы сейчас попробуем использовать ChatGPT для описания первой версии онтологии, затем покритикуем её, используя знания, уже полученные за прошедшее время стажировки.

Мы рекомендуем работать с ChatGPT не ниже версии o1. Предыдущие модели еще недостаточно умные, бреда/галлюцинаций в них многовато. А вот модель o1 уже способна давать достаточно качественные ответы – при условии, что вы умеете спрашивать, задействуя знания по моделированию, а также проверять ответы по принципу «доверяй, но проверяй». Мы ожидаем от единомышленников, что вы сможете получать от ChatGPT или иных LLM-моделей качественные ответы. Необходимые знания для этого у вас уже есть.

Начнем с формулировки запроса/промпта/prompt для ChatGPT o1 и выше. Чтобы ChatGPT ответила нам не совсем неправильно, искусственной нейросетке требуется задать роль – так же, как и естественной. Кроме того, нужно указать и уровень знаний: от новичка до эксперта, потому что это повлияет на способ формулировки объяснения^[1]. Делается это просто: «Представь себе, что ты – профессиональный онтолог». (Можно попробовать другие варианты формулировок, например, ‘Answer me at a top ontologist level’). Зачем мы требуем сразу профессиональное объяснение? Потому что оно будет точнее. По умолчанию ChatGPT отвечает среднестатистическому пользователю со средней подготовкой, поэтому ответ будет упрощен и дан на понятном среднему пользователю языке. Однако такой язык зачастую неправильный, объяснение, сформулированное на этом языке, будет «попсовым» и ошибочным^[2], первая версия онтологии будет и неправильная, и бесполезная. Отловить ошибки в таком ответе будет сложно без знания и предметной области, и онтологического моделирования, и (эпистемологических) методов формулирования хороших объяснений.

Далее надо задать ситуацию: описать, что ИИ-агенту надо отмоделировать. Нам нужно отмоделировать онтологию путешествий любых объектов, которые могут протекать через предприятие. Поскольку без примера будет непонятно, попросите в запросе привести пример предприятия из вашей отрасли. Далее вы как онтолог знаете, что нам интересны объекты и отношения между ними, а также уровни моделирования. Включите в запрос просьбу выделить уровни моделирования, описать объекты и отношения между ними^[3]. Дополнительно можно запросить:

• Подумать подольше и скорректировать ошибки в описании, как сделал бы это профессиональный онтолог. Опционально можно попросить показать промежуточные версии рассуждений (черновики) и финальную (беловик);
• Учесть информацию, которая появилась после 2022 года, так как ChatGPT может не включать её в описание. При необходимости в дальнейших запросах можно попросить что-то исключить;
• Указать источники информации, на которые опиралась ChatGPT при составлении ответа;
• Составить шаблон таблицы для заполнения, и так далее.

Рекомендуем отправить отдельный запрос на составление такой онтологии и отдельный – на её заземление для конкретной предметной области, например, маркетинга или операционного менеджмента. Затем при желании можете проэкспериментировать, смешивая разные уровни моделирования в запросе. Если ChatGPT начал выдавать что-то не то, вы всегда можете удалить контекст или попросить забыть содержание последних разговоров.

Альтернативно можно попросить составить прикладную онтологию для описания путешествий клиентов из предметной области маркетинга и онтологию для описания путешествий объектов, проходящих через предприятия, из предметной области операционного менеджмента (для операционного менеджера). Затем сравнить онтологии, выделить классы, которые можно отнести к одному более широкому классу (клиент как объект путешествия и work item/предмет работ как объект путешествия), выделить этот класс (объект путешествия) и получить таким образом более верхнеуровневую онтологию.

Если вы составите такой запрос (напомним, не рекомендуем работать с моделями ниже версии o1), то вы увидите примерно такой список^[4]:

• Объект путешествия, например, сырьё, полуфабрикаты, готовые изделия, коробки на складе, документы, клиент;
• Процесс/операция как действия по изменению состояния объектов^[5];
• Событие как изменения мира или смены состояний объектов;
• Место/точка контакта– место, где происходит контакт;
• Агент/Agent – тот, кто вступает в контакт и что-то активно делает, чтобы контакт был успешен;
• Роль , например, клиент;
• Стадии путешествия;
• Документ/запись/Record.

Начнем чистить этот список.

Объект путешествия – название класса указано правильно, но не указано, что объекты путешествия могут быть функциональными физическими объектами или материальными физическими объектами. Для методологического описания путешествия класса объектов / объектов «вообще» требуется работать с функциональными физическими объектами. А при моделировании потоков работ нас будут очень интересовать материальные физические объекты. Поэтому добавляем разбивку объектов на функциональные физические объекты и материальные физические объекты. Кроме того, нам также может быть интересна классификация физических объектов как уже существующих и будущих. Даже если конкретный ленточный конвейер №234 (будущий МФО), который будет выполнять функцию доставки руды до пункта погрузки или обогатительной фабрики на конкретной шахте №456 (будущий ФФО), еще не собран на предприятии, мы можем говорить о нём как об индивиде, который будет существовать где-то в будущем. Такая классификация будет особенно полезна тем, кто составляет описания вещей: им всё время нужно думать об этом будущем индивиде, который будет создан по их описаниям и пойдёт в эксплуатацию. При описании вещи нужно представлять себе МФО, который будет исполнять функцию у клиента / эксплуатироваться за пределами предприятия (совпадёт с ФФО).

Вместо стадий, которые могут появиться в ответе на ваш запрос, нас будут интересовать **состояния объектов/**states. Стадии жизненного цикла – устаревающая концепция, предполагающая наличие более-менее четкой последовательности выполнения работ по методу. Однако в реальной жизни все «стадийные» концепции описания смен состояний потерпели крах. В реальной жизни работы по методам выполняются по факту обнаружения объекта в определённом состоянии, поэтому путешествие объекта через предприятие часто очень нелинейное, что не отражают концепции стадийности. В биологии концепция «Древа жизни» также более не является SoTA, она используется лишь для того, чтобы «на пальцах» объяснить детям, что такое эволюция и как она происходит. Поэтому заменяем стадии на состояния объектов. Также нам будет интересно разделение состояний на реальные/подтвержденные измерениями и предполагаемые/оценочные. Откуда мы знаем, в каком состоянии объект – благодаря измерениям или по нашим предположениям, опирающимся на представления из головы и смутные интуитивные ощущения? Если первое, то о состоянии можно говорить как о реальном, если второе – о предполагаемом/оценочном.

Смену состояний мы отмечаем при помощи **событий/**events. События, как уже не раз говорили, представляем как трехмерные срезы/сечения объектов во времени:

Событие «авария в 22:03 25.12.2023 на перекрестке улиц Пушкина и Гоголя» включает в себя как пространственные части объекты «машина Мерседес номер РР45678 на 22:03 25.12.2023» и «машина Волга номер ФБ43332 на 22:03 25.12.2023»**.

Событие может быть однократным/дискретным/one-time event. BORO предлагает выделять еще сложные события, например, событие «мероприятие» – концерт, на который вы ходили с семьей. Но тогда возникает проблема: такое сложное событие надо считать набором простых (набором трехмерных срезов объектов в каждый момент времени). Каждая часть сложного события имеет длительность 0, соответственно, и сложное событие как сумма простых имеет длительность 0. Но вы прекрасно знаете, что это не так: вы можете указать, во сколько концерт начался и во сколько закончился, подсчитать, сколько времени он длился. Это время никак не равно 0!

Поэтому «событиями» мы называем только срезы трехмерных объектов во времени, которые отделяют одни состояния объектов от других. Например, мы выделяем события «начала концерта» и «завершения концерта», поскольку после начала концерта мы можем говорить о том, что объект «концерт» начал воплощаться в жизни (и, соответственно, мы как зрители будем демонстрировать зрительское поведение: слушать, хлопать и так далее), а после завершения – что объект «концерт» закончил воплощаться в жизни (и мы как зрители должны теперь покинуть концертный зал). Всё, что происходит между началом и завершением концерта, трактуем как «процесс», то есть, нечто длящееся во времени^[6].

События нам нужны, чтобы отмечать смены состояний объектов, которые происходят, пока объект путешествует через предприятие (или преобразуется на нём). Например, операционных менеджеров будут очень интересовать события «начала работы» и «завершения работы». После события начала работы предмет работ/work item должен начать менять своё состояние, а после события завершения работы – прийти в нужное состояние. Шкаф должен быть «сдвинут» в угол. Если не сдвинут, работа окончилась неуспешно. Описания вещи делаются для того, чтобы произошло сначала событие «начало существования вещи» (вещь из «будущей» стала «существующей»), а потом – событие «начала эксплуатации вещи». Успешность составленного описания вещи оценивается после наступления события начала эксплуатации вещи!

События обычно происходит в некотором месте/location/точке контакта/touchpoint/узле перемещения/transferpoint. Это некоторое физическое место, в котором в определённое время происходит **взаимодействие/interaction/контакт/**touch с объектом путешествия. Это взаимодействие ещё может называться вовлечение/engagement, если мы говорим о пути, например, клиента, или обработка/processing/transformation, если мы говорим о пути, например, детали. Мы отделяем само взаимодействие от места, где оно происходит, и называем эти объекты разными словами. Но если вы работаете с ChatGPT или даже читаете профессиональную литературу (!), например, по маркетингу, то вы можете встретить слово точка контакта/touchpoint в значении «контакт/touch» (а через пару страниц оно же – в значении «место контакта»). Мы предлагаем разные объекты называть разными именами и не путать их.

При взаимодействии создатель/агент, которого в данном случае мы можем назвать также «контактёр» (тот, кто производит контакт с объектом в фокусе внимания), демонстрирует поведение: выполняет работу по методу. Но и сами объекты, с которыми взаимодействует контактёр, тоже могут демонстрировать поведение. Например, если в фокусе объект типа «клиент», то клиент вполне агентен, и может сам решать, что ему делать, а что нет. Он может оборвать взаимодействие и уйти. Он также выполняет работы по методам^[7] – но по своим, и мы не можем запретить ему это делать^[8]. Объект типа «деталь» сам уйти не может, но с ним может случиться какая-то незапланированная неприятность (деталь упала и погнулась), из-за которой придётся применить какие-то новые методы, выполнить незапланированные работы по другим методам (попытаться выпрямить деталь, отправить на переплавку). То есть, поменяется путь/path/маршрут объекта, то есть, расстояние или длина траектории, реально пройденной объектом по точкам контакта^[9]. Возможно, не одного объекта, а целого потока объектов. Поток объектов мы выделяем как набор объектов (обычно одного типа/класса), у которых сохраняется общий путь (то есть, поток можем описать кортежом <класс объектов, путь>). Например, мы можем говорить о потоке клиентов на предприятии или о потоке работ, материалов и прочих объектов.

Помимо пути, нам будет интересно **путешествие/**journey. Если интересует нас как физически пройденное расстояние, то путешествие/journey – как поведение/изменения/activity объекта и смены его состояний после наступления события «начало путешествия» и до наступления события «конец путешествия» (включительно). Когда мы хотим подчеркнуть, что смотрим со стороны «объекта путешествия», то мы используем термин/слово «путешествие». Когда то же самое мы хотим описывать с точки зрения контактёра на предприятии, который выполняет работы по методам, чтобы привести объект в нужное ему состояние, то мы можем использовать слово/термин обработка/превращение/transformation. Именно этот термин часто встречается в книжках по операционному менеджменту.

Конечно же, у нас будут какие-то описания путешествия. Например, у маркетологов будут карты клиентского пути/customer journey map/CJM, у операционных менеджеров – модели потоков работ на предприятии. В описании нередко вам придётся расписывать причины, по которым объект путешествует. Например, нам может потребоваться описать причины, почему клиент начинает взаимодействовать с компанией (это обычно называют «описать болевые точки»/pain points).

Конечно же, поскольку упомянуты работы по методу, потребуется далее учесть объекты, которые держим в фокусе внимания при разговоре о методе (например, польза от применения метода) и о работе (например, ресурсы и сроки). Вы уже знакомы с этими объектами.

С такой онтологией можно идти описывать путешествия объектов. Как вы могли заметить, она довольно сильно переработана по сравнению с тем списком, который приведён ранее (а также по сравнению с вариантами, которые вы получите при формулировке запросов). Конечно, мы могли сразу взять нужную онтологию из руководств МИМ по рациональной работе и системному мышлению и добавить нужные объекты из стандарта ISO 15926-2:2003^[10]и вообще не мучиться с запросами. Но это можно делать, если ты знаком с нужными учебниками и стандартами, умеешь их истолковывать*, то есть, уже имеешь мастерство достаточной квалификации*. А вам часто придётся моделировать в ситуациях, когда вы не владеете нужным мастерством и вам откуда-то нужно получить первую версию модели. Вот в таких ситуациях и пригодится ChatGPT. Да, модели будут довольно кривыми. Но если вы примените алгоритм онтологического моделирования при формулировании запросов, а затем покритикуете выданный ответ как онтолог, то получившаяся первая версия модели будет кривой, но рабочей/actionable. С ней уже можно будет идти выполнять работу, параллельно изучая учебники для повышения квалификации в мастерстве. Тогда вы сможете ускорить выпуск результатов. На первых этапах эволюции побеждает тот, кто быстрее, на следующих – тот, кто точнее. Тот, кто сможет скомбинировать высокую скорость выполнения работ (которую может обеспечить LLM) с постепенным улучшением качества/точности выполнения (за которую отвечает биоагент), тот сможет выиграть в конкуренции.

Итак, получившуюся онтологию мы теперь можем использовать для того, чтобы в первом приближении описать, как вещь (или другой объект) путешествует через ваше предприятие. Вы можете выделить ключевые состояния этого объекта, ключевые события смены, ключевые точки контакта и создателей, которые работают какими-то методами. Вы можете получить первое описание принципиальной модели предприятия, которая в учебниках операционного менеджмента может называться модель Demand-Stock-Production (DSP).

СхемыDemand*-Stock-*Production для производства электронных компонентов и лекарств

Мы еще встретимся с этой моделью. Пока предлагаем вам сделать первую попытку добавить к графу создателей вещи примерное описание путешествия объекта, связанного с вещью, через ваше предприятие.

---

1. Для примера посмотрите, как музыкант Джейкоб Кольер/Jacob Collier объясняет концепт «музыкальной гармонии» на 5 степенях сложности. Обратите внимание на разницу в формулировке объяснений! ↩︎

2. https://ailev.livejournal.com/1749371.html ↩︎

3. В разделе «Построение онтологического описания» вы увидите алгоритм онтологического моделирования. Мы используем его, чтобы составлять запросы/промпты к ChatGPT, которые дадут полезную первую версию описания – такую заготовку, которую уже можно критиковать и доделывать до пригодного к употреблению состояния. ↩︎

4. Ответы могут очень отличаться в зависимости от запроса, поэтому ваш список и список в руководстве могут не совпадать точь-в-точь. ↩︎

5. Как вы видите, ChatGPT при описании процесса отсылает нас де-факто к методу как аспекту поведения (интересует смена состояний объектов, а не то, кто физически это делает, за счет каких ресурсов и в какие сроки). Но при этом в качестве синонима процесса ChatGPT предлагает слово «операция», которое обычно используется в операционном менеджменте и отсылает к работам, а не к методу. Вы не раз встретитесь с примерами подобного дребезга в работе. Чтобы избавиться от него, можно принять такое решение: по умолчанию толковать «процесс» как синоним «поведения» и подозревать, что, говоря о «процессе», будут отсылать к методу (чаще всего), реже – к работам. ↩︎

6. Мы не уточняем тут, к чему отсылает процесс – к методу или работе, поэтому в этом случае процесс можно считать синонимом активности/activity/поведения (т.е может отсылать как к методу, так и к работе). В данном случае нам важно другое: то, что в отличие от «события», «процесс» имеет временнУю продолжительность. ↩︎

7. В методологии Jobs to Be Done (JTBD) придумали слово jobs в значении «выполнение работ клиентом по каким-то методам». Суть методологии – навести камеры внимания создателей на то, как клиент (а не они!) выполняет свои работы по методам, используя вещь, произведённую создателем. ↩︎

8. Да и в целом наше воздействие на поведение «внешнего контактера» ограниченное. ↩︎

9. В физике траектория сама по себе считается воображаемой линией (прямой или кривой), вдоль которой движется физический объект/физическое тело. Если вы встанете и походите по комнате, то каждый ваш шаг можно отметить (в голове или в экзокортексе) точками, затем соединить их – вы получите траекторию вашего движения. Можно сказать, что она описывает ваш путь (реально совершённый). ↩︎

10. ISO 15926-2:2003 Industrial automation systems and integration — Integration of life-cycle data for process plants including oil and gas production facilities — Part 2: Data model ↩︎