Итак…
поехали.
моделировать смену состояний объектов необходимо чтобы выпускать качественные чек-листы (состояния объектов меняет агент в роли, который выделил из фона объект за счет ролевого интереса, и выполняя работы по методу, которые и переводят объект в требуемое состояние, если такт работ признан успешным).
есть описание путешествия объектов. это более общее описание для смены состояний объектов.
путешествие объекта любят маркетологи, но только они больше говорят о “путешествии клиента”, где описывают как потенциальный покупатель превращается в реального (покупатель в состоянии “потенциальный” переходит в покупатель в состоянии “реальный”).
нам как инженерам менеджерам интересно более широкое представление о путешествии произвольной системы по предприятию-как-конвейеру или его участкам (в контексте маркетинга это путешествие будет называться путешествием клиентеллы). данный вид путешествия интересен операционным менеджерам.
когда мы играли в игру “назови систему” мы пытались определить разные виды систем. на начальных стадиях игры мы в качестве системы рассматривали систему которая покинула границу нашего предприятия и которую эксплуатируют агенты за пределами нашего предприятия.
следующий ход - это заметить что та “наша система” которая покидает границу нашего предприятия на самом деле нужна для создания другой системы. получается что наше предприятие является одним их создателей в графе создателей и “наша система” на следующих этапах может быть использована для создания “целевой системы”.
на примере нефтедобычи:
для нефтедобытчика::роль система = партия/лот нефти. ее (партию) можно передать следующему в цепочке потребителю/создателю в рамках долгосрочного или краткосрочного контракта.
с нашей стороны::агент::нефтеразведчик::роль нефтедобытчику::роль можно оказать услуги по разведке нефтяных месторождений = сервис поиска мест для бурения скважин. тогда “наша вещь” будет географическая локация = точка на земле, в которой скважина (после того как ее построит = выполнит работы по производству скважины компания - бурильщик::роль и скважина - это система бурильщика = его система) должна попасть в месторождение нефти. те тут речь про то что это не любая произвольная точка на поверхности земли. это точка где вероятность получить месторождение значительно выше чем в любой другой точке не поверхности земли (в границах определенного участка, разумеется). если после бурения в предложенной точке скважина попала в месторождение нефти, это означает что работы по сервису/методу поиска мест для бурения были проведены хорошо.
если после бурения в предложенной точке скважина не попала в месторождение нефти, это означает что работы по сервису/методы поиска мест для бурения были проведены плохо (или работы были проведены хорошо, но проблема оказалась в том, что метод не рабочий).
если одновременно 2 точки на поверхности определены 2 агентами по методам, после бурения дали месторождения нефти, но в одной точке оказалось больше запасов нефти, а в другой меньше, то что это означает? метод лучше? работы выполнены лучше? кому-то просто больше повезло?
ок, отвлекся.
в ситуации когда я как сервисная компания предоставляю компании бурильщику информацию об оптимальной точке для бурения чтобы попасть в хорошее месторождение, то конечной/целевой системой для меня и для компании бурильщика будет партия/лот нефти в несколько баррелей.
Нет смысла бурить скважину, если не нужна нефть. Нет смысла бурить - значит нет необходимости в сервисе по поиску месторождений для бурения скважины.
поиск целевой системы = системы приносящей пользу людям (чем бы это ни было) является важной операцией/задачей. но тут есть разброс в позициях что есть в итоге целевая система и до какого уровня тянуть цепочки графа создания?
от нефти можно дойти до жевачки по полке магазина. но такая цепочка может получиться достаточно длинной:
нефть → искусственный/синтетический каучук → эластомеры → жевачка …
нужны дополнительные аргументы. граф можно тащить достаточно далеко. но мы будем останавливаться на такой системе, которая сама по себе обладает ценностью (в примере с нефтью - нефть является предметом торга на бирже как партия/лот нефти) и использование которой далее становится очень многообразным.
остановить свои рассуждения (не тянуться мыслью дальше) на партии нефти как целевой системе на этом этапе - самое разумное.
таким образом получается что в пределе мы имеем 2 широких класса ситуаций:
- предприятие изготавливает целевую систему само = является единственным создателем системы.
- предприятие не изготавливает целевую систему непосредственно, а находится где-то в графе создателей системы (является звеном/узлом графа создания).
в случае (1) нам достаточно просто и легко назвать целевую систему.
в случае (2) с тем чтобы назвать целевую систему придется поднапрячься. создателей целевой системы будет несколько. каждый создатель зависает на своей системе и каждому из создателей выделить вниманием целевую систему сложно. своя система у каждого из создателей может быть как какой-то физический кусок (блок, модуль, материал, деталь), так и эпистема/описание (конструкторская документация, рецепт). в таких ситуациях необходимо разворачивать сложные производственные цепочки (сложные графы), и по этим цепочкам добираться от своей системы (своего объекта) до конечной/целевой системы
один агент в графе создания может занимать разные роли.
агент может физически изготавливать часть системы (деталь системы). далее такие детали, изготовленные другими агентами - узлами графа создания, собираются в другом узле где эти детали собираются в конечную систему и эта система продается покупателю. например - одно предприятие::создатель создает двигатель, другой агент изготавливает коробку передач, другой создает колеса и т.д. а потом все эти детали собираются в узле такой цепи кооперации (граф создания) который отвечает за окончательную сборку автомобиля и далее автомобиль, после испытаний передается на продажу покупателю.
другая история происходит когда компания изготавливает и выпускает не физическую систему, а ее описание (конструкторскую документацию). границу предприятия покидает не “наша система”, а описание системы. “нашей системой” будет по цепочке создания - физическая система, которая будет изготовлена физически (из материалов, энергии, работ агентов) по этим описаниям на другом предприятии (другими создателями).
например, если мы говорим, что выпускаем конструкторскую документацию на прототип нового двигателя, и она покидает границы предприятия, то мы изготавливаем лишь описание. “наша система” в этом случае - это изготовленный на другом предприятии (или по цепочке из нескольких предприятий/создателей) прототип двигателя. конечная/целевая система в этом случае - это серийное изготовление двигателей или выпуск самолетов с двигателем (если речь про авиадвигатели).
двигатель изготавливает другой создатель/предприятие, а наша компания только готовит описание двигателя.
“наша система” = двигатель (изготовленный создателем по конструкторской документации, выпущенной нашей компанией), а не конструкторская документация. тут важно не путать описание/эпистему и систему.
будем считать что всегда когда спрашивают про “вашу систему”, то имеют в виду индивид/физический объект. эпистема/описание, даже не смотря на то что могут быть на носителе, не являются системой.
при поиске системы первым ходом надо выполнить заземление. сначала надо назвать систему вообще, после чего привести конкретный индивидуальный ФО, который принадлежит классу изготавливаемых систем.
эту операцию необходимо проделывать чтобы проверить не произошло ли спутывание системы и ее описания, системы и ее свойства, системы и ее характеристик, системы и ее поведения.
особенное внимание требуется в ситуациях разработки программного обеспечения. следует различать:
- исходный код софта,
- код софта который исполняется на железе
- цифрового двойника предприятия который реализуется работающим софтом на железе
- объекты физического мира (материалы, запасы, товары, персонал и т.д.) которые описываются работающим софтом
Код софта не обладает ценностью сам по себе. база данных наполненная данными тоже не является целевой системой и не обладает ценностью сама по себе.
ценность софта и базы данных с данными заключается в том, что они описывают реальные объекты предприятия и поддерживают реальные работы по выбранным методам работы на предприятии где развернут и работает софт.
разработчики софта должны вникать в суть процессов на предприятии процессы которого они поддерживают с помощью своего софта. они должны разбираться в используемых на предприятии методах работы и что сейчас является sota методами, а какие методы уже не актуальные и начинают устаревать и вытесняться более новыми методами работы.
еще одно отношение в графе создателей. агент создает простейшего неавтономного создателя для создания системы - инструмент. инструментом может быть станок или прибор который используется на заводе производящем систему.
инструмент - это не деталь системы, это не сырье для изготовления системы, это не описание системы.
с инструментом надо быть аккуратными при рассуждениях - инструмент рассматривается в сценариях когда речь идет о изготовлении конкретной штуки/детали ради которой приобретается станок/инструмент.
поясняющий пример про бурильщиков. нефтеразведчики создали для бурильщиков орг-возможность - пробурить скважину в указанной локации. скважина согласно обещания должна упереться в нефть. бурильщики бурят скважину. из скважины нефть пошла. бурильщики продают нефть лотами (целевая система). при этом локация для бурения и скважина не являются частями целевой системы. но и кроме как для целей извлечения нефти эти объекты использовать никак более нельзя. соответственно, место нефтеразведчиков и бурильщиков в графе создания не сложно понять и обосновать.
Возвращаясь на шаг назад к инструменту - у агента изготовителя инструментом может являться сложный станок с чпу, который может изготавливать разные штуки. и когда такой инструмент не участвует в изготовлении конкретной штуки которая нам нужна для нашей или целевой системы, то его с графе создания можно не учитывать и не отражать.
это вот для объяснения этой идеи написано.
еще вариант, когда агент выпускает не вещь, не часть вещи, не описание вещи или описания частей вещи, и не простые инструменты (простейший неавтономный создатель), а изготавливает другого агента-создателя, который обладает помимо автономности еще и своими предпочтениями и своей волей (агентнотсть).
Здесь мы говорим про “консалтинговые проекты” которые в процессе своего исполнения “меняют что-то в методах организации-клиенте”. изменения происходят на основании предложенных консультантом моделей. выполнение таких проектов приводит к тому, что в часть методов предприятия меняется/модернизируется (предприятие обновляется до новой версии"). эта измененная, новая версия предприятия и есть “наша вещь” для консультанта. консультант-агент-создатель изготавливает новую версию части части предприятия чтобы открыть новые возможности = оргвозможность (похожая ситуация как нечто похожее проходило у бурильщиков). обновленный/измененный создатель посла такого проекта над собой, изготавливает целевую систему.
роль такого консультанта может играть собственная внутренняя служба предприятия. или это может быть директор по развитию:роль.
граф создания описывается системной схемой проекта.
ключевая идея этой части текста: создатели могут основывать/изготавливать или менять/развивать других создателей. как части создателей так и полностью. таким образом такие создатели создателей так же попадают в граф создания целевой системы.
но следует помнить что все такие проекты орг-развития и технологического развития создаются и выполняются для того чтобы в конце этой цепочки создания была получена целевая система.
обратная цепочка рассуждений: не нужны лоты нефти → не нужна скважина → не нужен сервис поиска мест для бурения → не нужен проект по изменению методов поиска нефти в регионах.
не стоит сразу браться рассуждать про сложные цепочки создания. со сложность не справитесь, если до этого не натренировались на более простых понятных задачах, чтобы наработать навык. сложность надо повышать постепенно, шаг за шагом. иначе можно надорваться и соскочить с обучения.
разобравшись с тем где организация агента располагается в графе создания вещи, можно перейти на поиск объектов, которые путешествуют через предприятие.
тут возможны 2 сценария:
(1) если предприятие агента единственный создатель системы, то через предприятие путешествует система, которая затем покидает границу предприятия и попадает к покупателю, который ее эксплуатирует и решает свои задачи. в этом сценарии путешествие системы описывается как путешествие через конвейер. измеряются путь, время и скорость движения по конвейеру/пути.
(2) если предприятие является одним из создателей в графе создания, то тут будет сложнее описывать. но, мысль такая: хорошо бы называть объектом, выпускающимся вашим предприятием, будущую целевую систему, которая начнет существовать в какой-то момент в будущем. тут идет отсылка к кейсу с выпуском проектов моста в 3д, и последующим будущим выпуском реальных мостов по этому проекту. если по вашим моделям не будут строить мосты, то вам не будут платить или у вас кончатся деньги.
менеджеры в компании могут считать выпуск иначе и иметь свои представления о нем. им может быть не интересно, что происходит с вещью после того как она покинула границу предприятия.
что бы не выпускало ваше предприятие, важно уметь провести линию отношения “вашей системы” с “целевой системой”. потому что ваша система/ваш объект используется за границами организации для создания целевой системы и ее дальнейшей эксплуатации.
итак, при размышлении об объекте который путешествует через предприятие и выходит за границы, необходимо удостовериться что:
- объект связан с целевой системой
- покидает границу предприятия
- эксплуатируется за границами предприятия
- если этот объект не выпускается, то у целевой системы тоже возникают изза этого проблемы
- интересен операционному менеджеру который измеряет выпуск. для ускорения выпуска надо убедить операционного менеджера провести орг изменения на предприятии. для этого надо уметь показать ему связь между увеличением скорости выпуска или уменьшением затрат на выпуск единицы или партии объектов. тогда менеджер услышит агента и будет готов договариваться.
такие дела.
спасибо за внимание.
время мышления письмом: ( 25 + 40 + 30 + 30 + 30 + 20) минут