Вещь и граф создателей вещи
Мы обсуждали смены состояний объектов не только для того, чтобы писать чеклисты, но и для того, чтобы описывать путешествия/journeys объектов. Часто о путешествиях говорят маркетологи: возможно, вы слышали термин «клиентское путешествие»/customer journey, при помощи которого описывают, как потенциальный покупатель превращается в реального, а также его описание в виде карты/customer journey map. Нам сейчас будет интересно путешествие вещи (в разных её состояниях) по предприятию-как-конвейеру – обычно именно такой тип путешествия интересен операционным менеджерам.
Вещь вы уже попытались определить ранее, когда играли в игру «Назови вещь» или «Барышня-мадам»[1]. Напомним: нас интересует вещь, покинувшая границу предприятия (для начала) и эксплуатирующаяся/использующаяся за его пределами. Потом мы аккуратно говорим, что тот объект, который покинул границу предприятия, мог быть нужным для создания другой вещи – иными словами, что предприятие является одним из создателей в графе создателей и создаёт «нашу вещь»/нашу систему, которая в дальнейшем используется для создания вещи/целевой системы. Например, вы можете быть нефтедобытчиком, для которого вещь – это партия/лот нефти, которую можно передать по долгосрочному контракту или продать по краткосрочному контракту на бирже. Но вы можете оказывать услуги по разведке нефтяных месторождений («сервис поиска мест для бурения нефтяных скважин»), тогда «вашей вещью»/вашей системой будет пробуренная скважина, которая должна упереться в месторождение нефти (то есть, не любая скважина! Пустая скважина означает, что работы по сервису/методу поиска мест для бурения были проведены плохо!), а вот вещью/целевой системой – по-прежнему партия/лот в сколько-то баррелей нефти. Если нефть не нужна, то пробуренная скважина тоже не нужна. Соответственно, и сервис/метод поиска мест для бурения нефтяных скважин тоже не нужен.
Таким образом, при определении вещи мы имеем дело с двумя широкими классами ситуаций:
- Предприятие изготавливает вещь само (является единственным её создателем)****, назвать вещь относительно легко. Нефтедобытчики добывают нефть и формируют партию/лот нефти в n баррелей на продажу, подрядчик строит дом, парикмахерская создаёт прическу, компания-создатель конвейеров продаёт ленточные конвейеры для шахт;
- Предприятие не изготавливает вещь непосредственно, а находится где-то в графе создателей вещи**, таких создателей несколько****; выделить вещь вниманием и назвать сложно**. В таких случаях приходится разворачивать причинные цепочки/графы, выделять нашу вещь/нашу систему и по цепочке рассуждений добираться до вещи/целевой системы.
Во втором случае полезно взглянуть на самую простую схему графа создателей:
У нас имеется граф с отношением «создания». Нефтеразведчики:: создатели создают для нефтедобытчиков:: создатели оргвозможность – пробурить скважину, которая упрётся в нефтяное месторождение, и добывать оттуда нефть (их вещь – скважина). Нефтедобытчики используют эту оргвозможность: бурят скважину, откуда добывают нефть и продают её партиями/лотами нефти в n баррелей на рынке, где ею могут торговать или отправлять на нефтеперерабатывающие заводы, где получают нефтепродукты, например, искусственный/синтетический каучук. Из этого каучука в дальнейшем могут сделать эластомеры, которые придают эластичность жвачке, купленной вами в магазине[2]. Граф создания можно продолжать достаточно далеко (от нефтеразведчиков до продавцов жевательных резинок, например), однако обычно имеет смысл остановиться на такой вещи, которая ценна сама по себе, например, является предметом торга на бирже, как партия/лот нефти[3].
Если вы один из создателей в графе, то вы можете делать разное. Вы можете физически изготавливать часть вещи, например, двигатель автомобиля, который совместно с другими деталями собирается на отдельном предприятии и продаётся покупателю в составе автомобиля:: вещь. Это тоже достаточно простой случай.
Ваша компания может изготавливать не вещь, а её описание, например, инженерно-конструкторскую документацию для прототипа авиадвигателя или 3Д модель моста. В этом случае границу предприятия покидает физически не «наша вещь», а описание вещи – по крайней мере, так вам скажут менеджеры[4]. «Нашей вещью» будет прототип авиадвигателя, изготовленный за пределами предприятия по нашим чертежам, а вещью/целевой системой –серийно выпускающиеся по нашим чертежам авиадвигатели (прототип нужен для того, чтобы потом перейти к серии, количество неуспешных прототипов хотим минимизировать!) или построенный мост. Авиадвигатель и мост изготавливаются другими предприятиями, мы только описываем их. При этом само описание располагается на носителе описания, например, в софте для моделирования мостов или на бумажном документе. Носитель описания физичен, но нас интересует не носитель, а содержащаяся на нём информация:: ментальный объект. Поэтому, если вас просят назвать вещь:: индивид/физический объект, а вы внезапно говорите «3Д модель моста» или «инженерно-конструкторская документация», то вы не удержали внимание на типе: перепутали носитель описания с самим описанием (носитель без нужного описания не нужен!), назвали описание:: ментальный объект вместо вещи:: физический объект.
В случаях, когда вы делаете описания, вам надо будет найти вещь, описание которой делаете. Назвать эту вещь (точнее, класс вещей, например, «лот нефти», «мост»), предъявить индивида:: индивидуальный физический объект, принадлежащий к классу вещей («лот нефти, проданный по поставочному контракту №124», «мост через реку Обь в таком-то месте, введённый в эксплуатацию с такого-то числа»). Заземление, те предъявление индивидов, принадлежащих к классу выпускаемых вещей, позволит проверить, не допустили ли вы ошибку при определении вещи (не спутали ли вещь и её описание, вещь и её свойства/характеристики, вещь и её поведение). Если вы работаете в проекте по разработке софта, например, ERP-систем для предприятий, то вам надо особенно внимательно следить за тем, чтобы ни вы, ни ваши коллеги не путали софт:: цифровой двойник (части) предприятия, который описывает какие-то объекты на предприятии, и сами объекты, описания которых поддерживает ваш софт. Не делайте ошибку, не считайте, что ваш софт ценен сам по себе, как материальный носитель информации (если только вы не в дата-центре работаете). Нет, он обычно ценен тем, что как-то описывает объекты на предприятии и поддерживает работы по выбранным методам, например, по методу учёта запасов. И разработчики должны понимать, какие объекты будут во внимании тех, кто использует этот софт, какими методами они пользуются, какие методы сейчас SoTA[5], какие устаревают и не должны поддерживаться вашим софтом.
Наконец, ваше предприятие может выпускать и не вещь, и не части вещи, и не описания вещи или её частей, а изготавливать другого создателя (на картинке это «мемом» во времени создания, dev time). В таких случаях можно часто услышать про «консалтинговые проекты», в рамках которых «что-то меняется в организации-клиенте» на основе предложенных компанией моделей. Фактически в рамках таких проектов меняется часть предприятия или предприятие в целом (обновляется до новой версии), вот эту часть предприятия в новом состоянии можно назвать «нашей вещью». Вы помогаете другому предприятию изготовить новую версию части предприятия, вероятно, создать новую оргвозможность, как создают её нефтеразведчики для нефтедобытчиков. А уже изменённый создатель изготавливает вещь/целевую систему. Более подробно на системной схеме проекта это выглядит так:
Если сейчас не всё понятно, не застревайте на этом. С этой схемой вы еще не раз встретитесь в руководствах второго семестра, где и разберетесь, что означает каждый прямоугольник. На данный момент нас волнует принципиальная идея: одни создатели могут создавать/основывать или менять/развивать других создателей, таким образом они оказываются включёнными в граф создателей итоговой вещи/целевой системы. Все проекты оргразвития и основания нужны для того, чтобы появилась вещь в конце цепочки. Не нужна нефть – не нужна скважина – не нужен сервис поиска мест для бурения – не нужен проект по изменению методов поиска нефти в регионах.
Если вы работаете с софтверными проектами, то велик шанс, что вы не работаете над вещью напрямую, а находитесь где-то в графе создателей. Например, разрабатываете платформу AIsystant для МИМ, чтобы инженеры-менеджеры могли пользоваться руководством и отслеживать статистику по его применению. Но платформа нужна не сама по себе: она нужна для того, чтобы инженер-менеджер мог сформировать у себя нужное мастерство, например, мастерство рациональной работы:: вещь, которое затем используется на предприятиях в проектах оргразвития для ускорения выпуска вещей. Разработчики должны учитывать это, помнить, что они не просто «делают софт», а участвуют в изготовлении мастерства инженеров-менеджеров, пусть и не напрямую.
Вещей, в создании которых участвует организация, может быть много, в таких случаях говорят о «широкой продуктовой линейке». В ходе сесий рабочего развития мы предлагаем для начала выбрать одну вещь и потренироваться рассуждать о ней. Если вы сразу попытаетесь рассмотреть сложную ситуацию с предприятием, выпускающим много вещей, то вы просто не справитесь со сложностью. Сначала учимся моделировать на более простых примерах, затем усложняем модели. Так вы придёте к результату быстрее и не отвалитесь по пути.
Итак, вы примерно поняли, какая у вас вещь и где ваша организация в графе создателей[6]. Теперь нужно понять, какой объект путешествует через ваше предприятие. Если ваше предприятие – единственный создатель вещи, то через предприятие путешествует вещь, которая затем покидает границу предприятия и попадает к покупателю, который её эксплуатирует, и мы будем описывать её путешествие через конвейер и измерять путь, время и скорость прохождения пути. Если ваше предприятие – один из создателей в графе создателей, то назвать объект, путешествующий через предприятие и выпускающийся на выходе, чуть сложнее. Хорошо бы называть объектом, выпускающимся с вашего предприятия, будущую вещь, которая начнёт существовать в какой-то момент в будущем. Например, если вы делаете 3Д модели мостов, лучше всего считать выпуск/проход/Throughput в штуках будущих мостов, которые будут построены по вашей 3Д модели. Ведь если вы регулярно делаете модели, которые потом не используются – то вам перестанут платить.
Но мы понимаем, что менеджеры, с которыми вы будете разговаривать, могут считать выпуск иначе. Рассуждения о том, что происходит с вещью после начала её эксплуатации, часто оказываются вне внимания даже топ-менеджеров, и уговорить их перенаправить камеры внимания в нужное место не так просто. Даже на разборах второго семестра этому приходится посвящать порой несколько тренировок. Поэтому, чтобы договориться (у нас не просто «моделирование», а «прагматичное, целеориентированное моделирование»!), мы аккуратно говорим, что вы можете считать выпуск не в «вещах» (будущих или уже существующих), но в штуках (или иных единицах измерения) других объектов. Причём объекты, которые для операционного менеджера покидают границу предприятия/выпускаются с предприятия, могут быть любого типа: хоть часть вещи, хоть её описание, хоть вообще инструмент, который другой создатель будет использовать для создания вещи, и так далее. Но при определении выпускаемого объекта вы должны показать причинно-следственную цепочку, т.е. как этот объект за пределами предприятия используется для создания вещи и её дальнейшей эксплуатации. Например, нефтеразведчики могут считать выпуск не в лотах/партиях нефти, но в штуках пробуренных скважин. Также могут сказать, что выпуск будут считать в штуках сейсморазведочных профилей[7] (описаний возможных мест для бурения) – но только если при таком разговоре во внимании команды удерживается как минимум скважина, которую будут бурить в месте, которое в сейсморазведочном профиле указано как наиболее перспективное. Если во внимании команды этого нет, то они радостно проигнорируют все ваши слова про «их вещь» и тем более «целевую вещь» и будут полировать описания, ничуть не заботясь об их связи с физическими объектами. Мы выпускаем сейморазведочные профили так, что перспективные для разработки скважины находятся в 50% случаев (а у конкурентов – в 75%)? Ну и что, находятся же, и даже довольно часто! Почему эти клиенты жалуются?! Если сталкиваетесь с таким восприятием команды, то проще запретить говорить о выпуске описаний и искать пусть не «вещь» (целевую, итоговую, например, партию/лот нефти, реально поставленную покупателю), но хотя бы «нашу вещь» («пробуренную скважину»).
Таким образом, при определении объекта, который путешествует через предприятие и выпускается наружу, надо убедиться, что этот объект:
- Связан с вещью каким-то отношением, и вы можете указать, каким именно (отношением часть-целое, отношением описания, отношением создания, еще каким-то), и вы не забываете об этом отношении в работе;
- Покидает границу предприятия и эксплуатируется/используется за его пределами,
- Вы можете рассказать, как отсутствие выпускаемого объекта или проблемы с ним приведут к проблемам в создании и дальнейшей эксплуатации вещи;
- Интересен операционному менеджеру, измеряющему выпуск предприятия – чтобы вы смогли убедить менеджера в необходимости провести оргизменения на предприятии, вы должны показать связь между оргизменением и увеличением скорости выпуска или уменьшением затрат на выпуск единицы или партии объектов. Тогда менеджер вас услышит и будет готов договариваться.
Попробуйте выделить объект, путешествующий через ваше предприятие. Далее будем пробовать описать его путешествие.
Для примера можно посмотреть на фьючерс на нефть на Московской бирже. Фьючерсный контракт – это контракт, обязывающий продавца продать, а покупателя – купить лот нефти в 1 или 10 баррелей. Фьючерсный контракт бывает двух типов: поставочный и расчётный. Поставочный фьючерс означает, что продавец поставит реальный лот нефти, а покупатель должен его принять и разместить в своём нефтехранилище. При заключении поставочного фьючерсного контракта произойдет обмен реальным товаром и реальными «кучками золота»/деньгами. Расчётный фьючерсный контракт используют в том случае, если продавцу и покупателю не нужен обмен товаром в реальном мире, они только хотят поспорить: продавец контракта ставит на то, что рыночная цена актива к концу срока контракта будет ниже цены в контракте (то есть, продавец «продаст» этот виртуальный лот:: предмет спора покупателю по цене выше рынка), а покупатель ставит на то, что рыночная цена актива будет выше цены в контракте (и он «купит» этот виртуальный лот по цене ниже рынка). В конце срока контракта поставки лотов нефти:: физических товаров нет, продавец и покупатель обмениваются только «кучками золота». Тот, кто ошибся, выплачивает разницу между рыночной ценой и ценой по контракту тому, кто был прав, и заодно оплачивает комиссию устроившим сделку, например, бирже, брокеру. ↩︎
С таким определением объекта (не вещи!) есть проблемы, которые описаны ниже. ↩︎
State-of-the-art, современные/последние ↩︎
В ходе первого семестра вы получите лишь первое представление о том, что такое вещь и граф создателей. Мы не ожидаем, что вы сразу найдете вещь и сможете выделить всех её создателей. Но мы точно ожидаем, что вы начнете думать, что такое вещь, в создании которой вы участвуете, что ваше предприятие выпускает, чтобы вещь появилась – и что при этом не допустите онтологических ошибок: не будете пытаться назвать описание вещи, поведение вещи, свойства/характеристики/атрибуты вещи вещью. ↩︎