Примеры сервисов и их провайдеров

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

Вопрос в запоминании чеклиста из типов, о типизированных ими объектах которых вы должны подумать, выделить их вниманием в ваших рабочих и личных проектах. Все эти типы из нашего руководства связаны между собой отношениями, и легко проходить в мышлении по этим отношениям, перенося дальше внимание с этих отношений и типов мета-мета-модели на конкретные объекты вашего проекта.

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

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

Если вы не различаете все эти виды систем в проекте, вы будете пропускать во внимании важные объекты. Если у вас проект создания учебного курса (скажем, вы хотите делать onboarding, знакомить новых сотрудников с вашей организацией), то должна быть и целевая система — мастерство (скажем, мастерство надлежащего поведения сотрудника в организации). Если у вас проект какой-то системы доставки (провайдер сервиса доставки), то это создающая система, а целевая — «доставленная посылка» (вручённая в руки получателю, а не которая «в пути»). Главное тут: выявить все эти системы и убедиться, что вся команда проекта понимает, каковы эти системы, даже если вы каждый раз не приговариваете тип из мета-мета-модели (то есть говорите «мы все тут делаем причёски, наша парикмахерская нужна только для причёсок, а не сама по себе», а не «у нас целевая система причёска, наша система парикмахерской нужна только как создатель целевой»).

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

Типы понятий из системного подхода (например, предлагаемые нашим руководством) сами по себе полезны в момент обучения, но потом для обсуждения в рабочем проекте того, о чём уже подумали, а о чём хорошо бы подумать, надо ещё и пойти побеседовать со знающими людьми в проекте и не только (с некоторыми можно беседовать путём чтения их книг, статей, регламентов), потому как многое не нужно выдумывать, а нужно выявлять/discover: искать в мире объекты уже заданных в наших руководствах типов, а не вообще «какие-то» объекты, которые просто бросаются в глаза. «Какие-то» объекты могут оказаться как важными, так и неважными. Объекты тех типов, которые задаются системным мышлением**,** с максимальной вероятностью являются важными. Их типы и важность кажутся банальными, но попробуйте спросить членов вашей команды, что же в проекте создаётся и развивается (в наших терминах — целевая система, а в небольшой команде в большом проекте — «наша система»), и вы удивитесь разнообразию мнений. Как можно что-то создавать и развивать быстро и эффективно в таких условиях всеобщей недоговорённости?

Небольшие нюансы каждого проекта (например, по-другому организованная команда проекта) дают большую разницу в том, как удобно выделить разные системы в проекте. Каждый раз для каждого проекта нужно заново делать работу по выявлению целевой системы и нашей системы, определению потребных сервисов, и всему остальному системному мышлению. Поэтому дальше идут не «типовые ситуации» и «алгоритмы мышления», а просто примеры. Берите их как начало рассуждений и обязательно адаптируйте.

Рассмотрим простейший пример: проект, полностью эквивалентный созданию парикмахерской (и мы говорили, что ситуации сервисов на уровне мета-мета-модели все эквивалентны, объекты там типизированы одними и теми же типами и связаны одними и теми же отношениями) — но вы будете делать шлифовальную мастерскую. Удивительно, но редко сталкивающиеся со шлифованием люди мало задумываются над ровно теми же вопросами, которые им могут прийти в голову, когда они думают над хорошо знакомой им ситуацией стрижки в парикмахерской, просто потому что с парикмахерской они все сталкивались, а со шлифовальной мастерской — нет. И вот это «задуматься над важным, когда оно пропущено» — в этом и проявляется сила системного подхода, сами понятия системного мышления, типы из его мета-мета-модели (система в вариантах её видов, функция/метод/сервис/культура, работа, роль, агент и т.д.) тут являются ключевыми подсказками, чеклистом «о чём надо подумать», «о чём надо рассказать, когда спросят, чем занимаемся», «о чём надо спросить, чтобы разобраться».

Шлифовальная мастерская как провайдер сервиса шлифования имеет какую целевую систему? Шлиф: та самая зашлифованная работами сервиса шлифования поверхность (физический объект! Шлиф как целевая система занимает место в пространстве, характеризуется своей шероховатостью, с одной стороны прилегает к телу шлифуемого объекта, с другой стороны касается какой-то системы в окружении). Так что шлифовальная мастерская в целом (или шлифовальный станок в её составе, это смотря какой у вас проект) — это система создания шлифа.

Обязательно нужно рассмотреть надсистему: для чего шлифуем? Что будет соприкасаться со шлифом, или шлиф просто должен блестеть для красоты? Нужно ли закрывать шлиф лаком, чтобы он не окислялся? Каков класс обработки поверхности? Важно, что все эти вопросы автоматически придут в голову опытному шлифовщику. Но мы-то не опытные шлифовщики, а нам надо, чтобы эти все вопросы тоже пришли к нам в голову! Системное мышление даёт ровно это, когда заставляет подумать

• и о целевой системе (это не так просто понять, что это шлиф — хотя это полностью эквивалентно «причёске» в случае парикмахерской, только вместо стрижки и укладки — шлифовка и полировка, а вместо волос на голове — поверхностный слой вещества на заготовке),
• и о надсистеме (шлиф в соприкосновении со шлифуемой деталью с одной стороны и пока непонятно чем с другой стороны шлифа),
• и о потребностях внешних проектных ролей (зачем шлифуем? Что интересно получить инженеру от надсистемы, если в составе надсистемы будет шлиф?)
• и о концепции использования шлифа (какое поведение шлифа хотим получить в ходе его задействования в надсистеме, что от него ожидается?)
• и концепции шлифа (каким будет шлиф, не будет ли дополнительных покрытий, напылений, лакировки?),
• и о том, как обосновать результат (как убедиться, что все интересы удовлетворены?).

Если речь идёт о сервисе шлифовки, то можно подумать и о функциях создателя шлифа (заметили, что «функции создателя шлифа» это синоним «сервиса шлифовки», а также «метода работы шлифовальной мастерской»?), которые он будет выполнять по отношению к заготовке целевой системы в надсистеме создания детали в целом: функция «сделать блестящую поверхность» — для этой работы можно просто покрасить поверхность, или никелировать её, или даже заклеить блестящей плёнкой; «сделать гладкую поверхность» — для этой работы тоже можно предложить ряд способов, кроме шлифования.

Как выбирают обращение к шлифовальной мастерской:

• сначала определяется конечное состояние предмета метода/сервиса/функции,
• а затем можно выбирать из ряда вариантов возможных методов/сервисов/функций/практик.

Ещё один вариант сказать то же самое, но чуть подробней (близко к системной мантре):

• сначала определяется функциональный объект как предмет метода («гладкая поверхность» — и определяется, что там за свойства гладкости нужны в окружении этого предмета метода в момент использования этого предмета), концепция использования поверхности
• а затем предлагается конструктивный объект для воплощения функционального объекта (шлиф на болванке, гладкий слой краски, наклеенная сверху пластиковая плёнка и т.д.), концепция поверхности.
• Дальше думаем, каким сервисом/способом/методом это можно осуществить, (шлифовка! А предмет метода шлифовки — шлиф. С этого момента «гладкая поверхность» конкретизируется: «шлиф»::«гладкая поверхность»).
• Дальше думаем, кто может быть создателем, то есть провайдером такого сервиса (провайдером сервиса по созданию шлифа может быть шлифовальная мастерская, или даже шлифовальный станок, или даже шлифовка своими силами вручную, хотя в последних двух случаях «наших сотрудников, наших инструментов» продолжаем говорить о методе, но в первом случае «внешней мастерской» говорим о сервисе).
• Выбираем конструктивный объект, выполняющий роль шлифовальной мастерской (например, ООО «Вжжж»).

Системное мышление заставит подумать и о внешних ролях (инженер::клиент, которому нужен шлиф), и о внутренних/командных::роли (кто будет шлифовать?) и о внешних по отношению к создателю::система (кому нужна шлифовальная мастерская, но не нужны сами шлифы). Заставит документировать интересы внешних проектных ролей и концепцию использования шлифа (описать надсистему шлифа — что хотят внешние проектные роли от шлифованной поверхности плюс того, что к ней прилегает), концепцию самого шлифа, которая даёт ожидаемые свойства (класс обработки поверхности, необходимость какого-то покрытия после шлифовки, например, лакирования: как обеспечить те характеристики шлифа, которые важны в момент использования).

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

• Поскольку речь идёт о софте (хотя мы пока и не знаем, «система оформления командировок» включает ли в себя людей, не является ли каким-то оргзвеном, или это таки просто софт-инструмент без отдельного оргзвена для него), то этот софт что-то описывает в своих данных. Что описывает? Командировку, или на формальном языке — «деловую поездку». Итак, целевая система (ради которой всё затевается, включая оформление через ваш будущий софт) — деловая поездка, которая понимается как набор/composition вполне материальных объектов: человек (необязательно сотрудник!), который куда-то едет, пункт начала поездки, пункт конца поездки, транспорт, зарезервированное место в транспорте (описывается административно значимой записью на серверах перевозчика, а раньше это было «билетом», описание собственно «езды»), место проживания (описывается административно значимой записью на серверах гостиницы, но обычно достаточно выписки — квитанции) — и всё это на каком-то отрезке времени.
• Уточняем теперь целевую систему. Кандидатов в рассмотрение целевых систем становится три: 1. Удалённая работа (поездка тут не волнует, волнует то, что надо добиться каких-то изменений в объектах, хотя эти изменения без поездки невозможны). Например, начальник поручает сотруднику удалённую работу, или сам сотрудник решает, что надо провести работу. 2. Собственно, деловая поездка — как её для себя определяет сотрудник. В неё входит выполнение работы, а также собственно поездка — транспорт, ночёвки. 3. Оформляемая часть деловой поездки — это тот объект, который интересует бухгалтерию: только те части поездки, которые как-то связаны с оплачиваемым (а не всем) транспортом и оплачиваемыми (а не всеми) ночёвками. В большинстве связанных с администрированием ситуаций надо выделять похожие три целевых системы.
• Клиент при этом не бухгалтерия, а те, кому нужны удалённая работа (например, начальники командируемых) и деловая поездка (командируемые), а бухгалтерия оказывается в подчинённой роли внешнего провайдера сервиса по созданию оформляемой части деловой поездки. Так что дальше надо определяться: софт этот как инструментарий чей — инструментарий начальника для оформления удалённой работы, сотрудника для помощи в деловой поездке или бухгалтерии для оформляемой части деловой поездки.
• Если это понять, чей инструментарий из этих троих создаваемый софт и поддержать начальников и сотрудников в первую очередь, а бухгалтерию — в последнюю очередь (а не наоборот — удобный для бухгалтерии метод оформления, неудобный для начальников и сотрудников как клиентов бухгалтерии, а затем загонять начальников и сотрудников в неудобный сервис под угрозой отнять их деньги и нервы, зато сэкономить нервы бухгалтерам), то команда проекта с результатами её работы будет нужна прежде всего всем начальникам (которые хотят удалённой работы) и сотрудникам (которые хотят отправиться в деловые поездки), а не только бухгалтерам фирмы, которые эти поездки должны оформить, но им этого по большому счёту не надо («не смог оформить — не поехал, последствия неисполнения удалённой работы разгребаем не мы, бухгалтерия, так что заткнитесь и выполняйте любые дурацкие правила оформления»). Это существенно меняет переговорные позиции в проекте! Из врага всех начальников и сотрудников команда разработки инструментария (софта оформления удалённых работ/деловых поездок) становится другом всех начальников и их сотрудников! И дружат они все против бухгалтерии, для которой ноль поездок (ноль работ по предоставлению сервиса, да это и не классический сервис, они за него денег не получают!) — это идеал/предпочтение, ибо уменьшает количество их забот по оформлению. Такие развороты ситуаций типичны, когда речь заходит о системном мышлении: приходится честно отвечать на вопрос, кому что нужно и договариваться о балансе интересов для создаваемой системы, какой бы она ни была. При этом помощь со стороны типов мета-мета-модели в том, что становятся понятными объекты, по поводу которых надо договариваться (предметы договорённостей, обычно это предметы каких-то методов, которые используют договаривающиеся агенты-в-ролях) и понятно, кому договариваться.
• Какие методы работы нужно задействовать, чтобы целевая система «оформляемая часть деловой поездки» была создана, предмет этих методов из состояния «оформляемой части деловой поездки нет» превратился в «оформляемая часть деловой поездки создана», затем через несколько стадий «оформляемая часть деловой поездки выполнена»? Что содержательно нужно сделать, то есть каким способом поменять состояние каких предметов/объектов, (но пока не рассматриваем агента: кто или что будет проводить работы по этим методам)? Создатель с помощью инструментов (люди бухгалтерии с софтом, но мы уже выяснили, что там надо учитывать и командированных, и их начальников и даже случаи «сам себе начальник», самопосыл в командировку) должен зарегистрировать потребность в поездке и открыть мини-проект удалённой работы, выделить финансирование на поездку (но там может быть ещё и часть финансирования на сами работы!), купить билеты, возможно, забронировать гостиницу, выдать командировочные, оформить документы (командировочное удостоверение, билеты, бронь в гостиницу, грузовые документы для какой-нибудь провозимой с собой аппаратуры, если нужно), принять отчёт о поездке — и тут есть множество вариантов, зависящих от принятых методов ведения командировок. Где-то не нужны командировочные удостоверения, где-то не нужны даже отчёты, где-то юристы больше защищают сотрудников, где-то юристы настаивают на выполнении стандартов деловых поездок ещё советского времени (когда полёт на самолёте был чем-то экстраординарным).
• Какой создатель должен эти методы выполнить? Софт (и там создатель софта — команда программистов, «создатель создателя»), или служба/«провайдер сервиса» оформления (софт на серверах плюс люди из бухгалтерии, работающие с этим софтом как операторы? Терминология «службы» и «сервиса» будет задействована только в этом случае, но и тут варианты: чем более внешняя эта служба, например, внешний провайдер сервиса бухгалтерии, тем больше будет уместна эта терминология, а вот если это делают сотрудники той же фирмы, которая оформляет для других своих сотрудников командировки — вот тогда слово «сервис» для выполняемого там метода работы или «служба» для самих этих людей с их мастерством и инструментами-софтом можно не услышать, «язык сопротивляется»)? Что будет сочтено успехом проекта создания софта, создания службы, создания деловой поездки? Какие роли требуются для этих разных проектов создания создателя деловой поездки (создания службы оформления, а там внутри ещё и создания инструмента оформления, то есть софта), создания деловой поездки (и мы сходу там нашли оператора службы, начальника командированного, самого командированного — а роли программистов и менеджеров службы остались в прошлом проекте создания службы и там внутри создания софта)? Кто исполняет эти роли в команде программистов, в команде создающих службу менеджеров, в команде создающих деловую поездку (даже если в этой последней команде нет ощущения команды и даже проектом это никто не считает, но это же проект, и участвует в нём много людей, им надо договариваться и уметь сыграть свою ролевую игру!). Беда, если вы считаете «нашим проектом» проект создания софта, а в момент приёмки проекта в эксплуатацию, или в момент возникновения трудностей в связи с тем, что нет исполнителей других ролей в полноценной службе оформления поездок (время эксплуатации системы создания поездок) спрашивать начнут с текущего разработчика софта! Объяснений, что «мы считали, что от нас нужен только софт, а людьми займётся кто-то другой», слушать ведь никто не будет! В конечном итоге нужны оформленные деловые поездки, или даже сами полные деловые поездки (в которых сотрудники ухитрялись сходить в неоплачиваемый ресторан или переночевать в гостинице, которая не выдала никаких платёжных чеков), а то и выполненные удалённые дела — ибо важны в конечном итоге именно они, и если они сорвались по причине трудностей деловой поездки или оформления деловой поездки, то это «внутренние ваши трудности, а вот за выполненные дела отчитайтесь»! В зачёт идут только ожидаемые общие результаты деловой поездки, и если без каких-то людей-сотрудников службы оформления деловой поездки софт их сам выдать не может, то нужно будет «изготовить» и этих сотрудников, т.е. обучить новым методам работы ещё и каких-то людей, а ещё нужно будет обучить новым методам работы и начальников командированных, и самих командированных агентов!

Заметим, что всё сказанное по поводу проекта создания софта для оформления командировок не даёт чёткого ответа на вопрос: как же организовать оформление командировок. Но зато показано, как системное мышление даёт набор объектов, который удобен для обсуждения альтернатив. Можно не обсуждать то, что же именно нужно обсуждать. Обсуждать нужно сразу системы, их окружение, внешние проектные роли, графы создателей и отдельных создателей в них (как инструментарий, как провайдеров/службы с их сервисами, как агентов индивидуальных или коллективных), методы работы, роли и т.д. — мышление задействует объекты не любых типов, а именно этих типов, и эти типы берутся как раз из руководств по программам рабочего и исследовательского развития).

Ещё один пример: магазин предоставляет сервис покупки — он создаёт покупку как какой-то набор товаров, находящихся в собственности покупателя в его руках на выходе из магазина, и деньги покупателя на счетах магазина (о деньгах думаем как о физическом золоте, можем не отвлекаться на безналичные расчёты и их «нефизичность»). Магазин помогает сделать/создать/изготовить (инженерная терминология!) покупку: он сводит покупателя со своими полками и кассовыми аппаратами.

И тут надо различить два значения термина «покупка»:

• Процесс/метод/сервис, шоппинг/shopping — метод работы магазина, меняющий состояние товара с «выложен на полке» на «стал товаром в покупке», а денег «в кошельке покупателя» стали «платежом за покупку». Например, «чтобы завершить покупку, нажмите кнопку «оплатить»».
• Товар, который был куплен и собственность на который перешла в руки покупателя. Например, «разверни свою покупку, посмотрим, что купил».

Если это интернет-магазин, то «покупка» в этом значении становится наряду с платежом «поставкой», и там такая же путаница поставки::метод/сервис товара::«предмет поставки» и «платежа»::сервис денег:: «предмета платежа» с поставкой::«предмет поставки-сервиса» как уже бывший товар, а ныне собственность покупателя у него в руках, а также платежа::«предмет платежа-сервиса» как деньги, но уже на счетах у продавца. Иногда вводят и термин «поставка против платежа» — это тоже иногда конечное состояние товара и денег, но иногда — сервис интернет-магазина или маркетплейса (агрегатора магазинов плюс службы доставки).

Сервис::поведение и «предмет сервиса»::«предмет поведения» в бытовой речи тоже нещадно путаются, как и сервис::повдение и сервис-провайдер (в IT сервис-провайдер может быть назван микросервис или сервис, но не микросервер или сервер). поэтому внимательно следите за типами: что там объект, а что поведение объекта. В случае проекта магазина путаются метод/процесс покупки/поставки и предмет, который куплен-поставлен (его тоже назовут «покупка» или «поставка»). Если вы купили три килограмма сахара, потратив на это десять секунд в интернет-магазине, то в одном случае можно будет сказать «моя покупка заняла десять секунд», в другом случае — «моя покупка весит три килограмма».

Сервис покупки (поставки) и платежа — поведение провайдера сервиса в части паттернов этого поведения (способ/метод работы провайдера, когда он работает над чужим предметом метода, подразумевается, что магазин не производитель товаров/изделий/продуктов, а именно сервисная организация, «переработка чужого»), а в итоге у нас в руках (а у магазина на счетах) покупка (поставка) и платёж как материальные объекты — это результат предоставления/оказания сервиса/услуги, проведения работ сервиса: (бывший) товар в руках покупателя и деньги на счёте магазина.

В парикмахерскую приходят за стрижкой как работой сервиса или за причёской как результатом стрижки, итогом предоставленного сервиса? По большому счёту, за причёской. За результатом сервиса. Но главное там — стрижка и укладка как процессы/методы/сервис. В магазинах (и практически везде в других системах создания, по факту это часто предприятия или их части) то же самое. Сервис доставки в интернет-магазине имеет целевой системой «доставку», понимаемую как уже доставленный и оплаченный пакет уже в руках счастливого получателя этой «доставки». Этот интернет-магазин с его сервисом «доставки» (процесс/метод/способ работы) задействуется для получения «доставки» (бывший товар в его конечном состоянии нахождения у покупателя) примерно так, как парикмахерская с сервисом стрижки и укладки задействуется для получения причёски и шлифовальная мастерская с её сервисом шлифования задействуется для получения шлифа. Само слово-термин «доставка» в разных случаях может обозначать как сервис, так и целевую систему, обрабатываемую этим сервисом, так что его значение нужно обязательно уточнять. Отглагольных существительных нужно бояться: иногда они означают поведение**/«глагол»,** а иногда и какую-то вещь**/«существительное»** как результат этого поведения.

Этот сервисный подход (сдвиг с изделий/продуктов как наших или целевых систем на заказ отдельных работ по каким-то методам для их получения) сдвигает внимание с рассмотрения только собственных проблем создателей «меня волнует мой завод, производящий товар/продукт» на рассмотрение также и проблем многочисленных подролей «клиента/заказчика», делает шаг к более детальному описанию подролей. В сервисе «продажи» магазина-провайдера (тут ещё важен и референтный индекс, то есть от чьего лица делается референция/«описание предметов/референтов» — для магазина этот сервис «продажи», для клиента во всех его подролях — сервис «покупки») надо бы учесть минимально:

• Бенефициар («конечный пользователь» создаваемой системы, хотя и пользователь тут слишком общее имя — мы говорили, что лучше для игры говорить не «пользователь», а игрок, для токарного станка говорить не «пользователь», а токарь, для мороженого — едок, а не «потребитель»). Скажем, девочка, которая будет носить купленное в магазине платье.
• Плательщик — с чьего счёта (кредитной карты) уйдут деньги. Например, кредитка папы, оплатившего покупку платья для девочки.
• Собственник, на чьё имя оформляется купленная вещь, выписывается гарантия. Это и будет обычно «покупатель». Например, это мама, покупающая платье девочке.
• Получатель (представитель) собственника. Например, дедушка, который встретит курьера из магазина — ибо девочка в садике, мама и папа на работе.
• Консультант. Например, подружка, которая запретит девочке носить платье, ибо оно не удовлетворяет её представлениям о моде. И поэтому уговаривать купить платье (магазин и производитель платья ведь занимаются маркетингом!) надо в том числе и консультанта!
• … и этот набор подролей «покупателя/клиента» можно продолжать.

Провайдер сервиса (участник графа создателей целевой системы) со всем своим мастерством и инструментами проведения работ по сервису выживает в долгосрочной перспективе только в том случае, когда нет вопросов к качеству результирующей целевой системы как результата сервиса. Если целевая система в итоге оказания сервиса получается плохая, а создатель-провайдер при этом восхитителен, то жизнь этого провайдера сервиса закончится в момент окончания инвестиций её создателя^[1].

Если владелец магазина будет заботиться не о состоянии покупателя и размере покупки в момент ухода покупателя из магазина, а просто о своём торговом зале, то покупатели будут только мешать торговому залу быть в идеальном состоянии! Корабли лучше всего сохраняются в порту, в гавани. Но их строят не для того, чтобы они стояли в гавани: их место в открытом море, где много опасней и хлопотней, но без этого не будет создана целевая система: груз в месте его назначения. В конечном итоге нужен не столько нетронутый инструмент и незадействованные работы мастерства, сколько, целевая система и какая-то работа и тем самым износ создателя целевой системы — та самая «покупка» или «доставка» для магазина, та самая «оформленная деловая поездка» для бухгалтерии. Тут, конечно, требуется лидерство, ибо если магазин не будет торговать, его просто закроют, а вот если бухгалтерия не будет оформлять деловых поездок, будет делать всё, чтобы этих деловых поездок не было и ничего не надо было бы оформлять, то её могут и не закрыть. Но это уже вопросы системного менеджмента, само по себе системное мышление только даёт объекты, которых достаточно для подобных обсуждений.

Давайте ещё раз разберём пример целевой системы «лот», там тоже акцентируем внимание на сервисе. Нефтеперерабатывающий завод производит небольшие порции какой-то фракции перегонки нефти. Эта фракция почти ничего не стоит, «отходы производства». Провайдер сбора::сервис лота::целевая система железной дорогой доставляет эти порции к месту на побережье, где сливает их в арендованный огромный резервуар. Потом, после заполнения этого резервуара провайдер сбора лота переливает фракцию в танкер и отправляет на переработку на один из химических заводов. И получает на выходе весьма дорогое сырьё. Почему ему нужно собирать лот на побережье в резервуаре, который ему даже не принадлежит? Химзавод не примет маленькую партию фракции, ему подавай сразу большой танкер. Почему не собирать маленькие порции в танкер? Танкер дорого стоит, и лучше бы ему быть в пути, а не стоять в порту и ждать прибытия маленьких порций фракции-сырья. Целевая система для провайдера сбора (предмет сбора) — лот::«единица торговли или переработки». Если не будет собранного лота, то не будет переработки фракции химзаводом. Вот поэтому провайдер сбора изготавливает лот путём накопления маленьких порций дешёвой фракции, получая большую порцию, которая позволяет ему заключить контракт на переработку: эта большая порция и есть лот. Следовательно, у нас в рассмотрении — провайдер сбора::сервис лота::«предмет сбора» (и этот же «лот» — целевая система для проекта создания провайдера — а не организация провайдера!). Провайдер изготавливает этот лот путём ведения работ по сбору лота как прохождения «сеансов» сбора как закупки и перевозки к резервуару отдельных порций сырья.

Провайдер обучения::сервис изготавливает мастерство::система, которое обучаемые будут эксплуатировать после обучения. Мастерство определяем как специализированный вычислитель (устройство), реализуемое частью мозга, а сам мозг рассматриваем как универсальный вычислитель. Вычислитель можем рассматривать вместе с устройствами ввода-вывода (в том числе манипуляторами и датчиками, ушами-глазами-руками-ногами-зубами — телом), а если нужно как-то задействовать силу тела, то обучение тренирует не только мозг, чтобы в нём выросло мастерство, но и тело, чтобы как-то наросли мышцы и фасции, нужные для эксплуатации мастерства. Телу можно дать инструменты, так что мастерство задействует не только себя самого (только обработка информации) или себя с телом (даже ввод-вывод информации для размышлений — это уже действия не только мастерства-вычислителя, но и тела), но и инструменты. Тело тут можно считать тоже инструментом, а мастерство — контроллером всех телесных и внешних (экзотелесных) инструментов. Подробней об этом всём говорится в руководстве по инженерии личности, ибо личность — это совокупность всех видов мастерства какого-то агента.

Создание провайдера обучения::сервис/метод мастерству::«целевая система» какого-то метода («создание создателя мастерства», но в этой формулировке нет сервиса/функции/метода создания, то есть не упомянуто «обучение») тоже может служить примером, который легко модифицировать как прототип для разных других проектов обучения::сервис: от классического программирования компьютера (трудно считать это «обучением», тем не менее) до корпоративных/организационных изменений (самых разных людей в фирме надо научить выполнять с удовольствием свои рабочие роли), и даже маркетинг можно рассматривать как частный случай (научить человека использовать какой-то продукт или пользоваться сервисом, начиная с того, что научить его покупать, как только увидишь, а если не увидел, то ещё и искать, чтобы купить!). Создание провайдера чего угодно имеет целевой системой не самого этого провайдера, а предмет его сервиса или какую-то иную целевую систему, которую помогает создать предмет его метода (если, например, предмет его сервиса/метода — описание, то целевую систему надо искать где-то ещё дальше в графе создателей).

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

Если речь идёт о провайдерах безопасности, то никто не понимает, что это такое, договориться невозможно. Но как только вы скажете, что делаете, например, сигнализацию для каких-то понятных неприятностей (а непонятное слово «безопасность», похожее на название свойства, табуируете) — всё волшебно налаживается. И тут надо разобраться, что вообще обсуждается:

• Событие «неприятности» — можно ли тут рассуждать о нём как о мероприятии, по типу «танцевального перформанса», или это просто момент во времени и такого рассуждения не получится?
• Сигнализация — это что: инструмент, который выдаст сигнал, или метод/функция/сервис такого поведения? С отглагольным существительным надо быть осторожным.
• Тем самым: вы делаете сигнализатор::инструмент или провайдера сервиса сигнализации (например, людей плюс сигнализатор::инструмент, и это будет «служба сигнализации», а не «сигнализатор»)?

Целевые системы бывают самые разные, сервисы и их предметы бывают самые разные, типовых в плане объектов предметных областей (метаУ-модели) и тем более в ситуациях конкретных предприятий (метаС-модели) вы не найдёте. Но рассуждения про целевые системы, сервисы и их предметы — однотипны, если вы используете типы мета-мета-модели из наших руководств. Вопросы к самым разным видам сервисов задаются по одинаковым шаблонам, осмысленность ответов на эти вопросы легко проверяется.

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

• Какого-то из создателей целевой системы (команду с мастерством в каком-то методе и/или инструментарий). Создатель в ходе его работы (тут реже говорят «эксплуатации») будет задействован во время создания целевой системы, находиться где-то в графе создателей. Это часто будет называться «наша система», если вы создаёте и развиваете этого создателя, да и вы сами попадаете в граф создателей, разве что в нескольких отношениях создания от целевой системы.
• целевую, которая будет задействована где-то в потребительской надсистеме в ходе эксплуатации/использования/функционирования целевой системы. Это означает, что вы в графе создателей стоите в одном шаге/ребре от узла целевой системы (или её частей).

В первом случае будет граф создателей: вы как оргзвено-1 создаёте и развиваете оргзвено-2, которое в свою очередь создаёт и развивает целевую систему. Например, вы консультируете пиццерию (проводите серии консультаций::сеанс), которая выдаёт после этого пиццы всё лучшего и лучшего качества. И тут можно рассматривать пиццерию как производителя пиццы::системы, а можно как провайдера сервиса быстрого питания::поведение.

Это могут быть и очень длинные пути/цепочки создания в довольно «кучерявых» графах. Вот пример такого пути/цепочки: вы консультируете совладельца холдинга, который проталкивает проект реорганизации цеха красок в штаб-квартире красильного холдинга, штаб-квартира занимается организацией реорганизации цеха красок, потом цех красок занимается собственной реорганизацией, потом реорганизованный цех выпускает новую краску. Вот эта новая краска — это и есть целевая система! А вот это путь в графе её создателей: консалтинг — совладелец холдинга — штаб-квартира холдинга — цех красок как реорганизатор — цех красок как выпускающее краски оргзвено. Но для всех них выпускаемая краска — целевая система, по поводу которой все и договариваются. А те системы, которыми они занимаются при создании целевой по этой цепочке создания, разные «наши системы» (engineered systems) для разных команд в этой цепочке. Подчеркнём, что целевая система, в которую целится весть граф создателей, одна: выпускаемая новая краска, если об этом не помнить, то трудно обсуждать, что связывает в один проект все эти проекты создания и развития «наших систем» в графе создателей. При этом у реорганизованного цеха «наша система» совпадает с целевой.

Не забывайте, что в обширных графах создателей все системы создают одна другую только для того, чтобы надлежащим образом создать и развивать целевую систему. Повторим, речь не идёт обязательно о «создании целиком с нуля», но может быть и создание MVP, затем продолжительное развитие системы, а ещё создание и развитие может быть частичным: может быть только описание создаваемой системы, изменение какой-то одной характеристики, настройка-регулировка, но всё это будут действия создателя во времени создания и развития создаваемой системы.

Если целевая система оказывается не нужна каким-то клиентам (не учитывает интересов клиентов), то у вас довольно скоро не будет денег поддерживать работу всех систем в графе создателей — неучёт интересов внешних проектных ролей в пользу облегчения работы команды ведёт к созданию неуспешной системы. Большая вероятность того, что облегчившая себе жизнь в ущерб клиентам команда денег не получит. Клиенты (внешние проектные роли) просто не заплатят ей за работу и поток денег на весь граф создателей окажется нулевым.

При этом всё сказанное про формулирование целевой системы как принадлежащей клиенту и обслуживаемой/изменяемой каким-то провайдером сервиса создания (в том числе не полному созданию, а части создания, например, только описанию, или такому частному изменению как модификация/настройка, проведение одной производственной операции, например, операция окраски для красильной службы), не является «объективной истиной» или даже «типовой ситуацией». Может быть и просто поставка товара как целевой системы из собственного сырья поставщика товара, а не провайдера сервиса создания. Не всё в мире пока сервис-ориентировано. Но это для системного мыслителя практически не означает смены мышления. Если понимать, что метод и сервис — это синонимы, разве что принято говорить о них немного по-разному, ибо речь идёт по большому счёту только о том, «чьё сырьё и чей продукт», а это не так уж много меняет в проекте.

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

Конечно, в этом подразделе был дан только минимальный набор понятий онтики сервиса. Дальше, конечно, нужно рассматривать множество самых разных ситуаций, к которым эта онтика может быть как-то адаптирована. Скажем, прохождение сервиса будет у сырья/заготовки::«предмет сервиса», а также может быть не одиночной заготовкой, а их партией/batch, заготовка и конечный предмет сервиса/метода могут быть на разных системных уровнях (если это сервис сборки, то это и есть цель), сам сервис может состоять в неоднократном приложении каких-то методов к предмету сервиса (сеансы).

Вот несколько примеров рассуждений, где мы покажем использование разной лексики и чуть более детальные описания с использованием онтики сервиса с адаптацией к различным проектным ситуациям:

• Шлифовка (шлифование) — это операция::сервис/метод провайдера шлифовки, который изготавливает шлиф::«предмет метода» в заготовке. Заготовка тут — сырьё для будущей готовой системы как носителя шлифа, надсистемы шлифа — то есть тут готовая система «отшлифованная деталь» на системный уровень выше, а целевой системой операции шлифовки будет шлиф — если провайдер шлифовки мастерская, то целевая система у неё — шлиф, а если это просто шлифовальный станок где-то на заводе, то даже готовая «отшлифованная деталь», где шлиф только её часть — это вряд ли целевая система, но может быть «нашей системой») в ходе операции::сервис шлифовки. Заготовка принимает участие в сеансе шлифовки, равно как и провайдер шлифовки (подключаясь на интерфейсе к болванке). Будет ли переименована болванка/заготовка детали в деталь как готовую систему после шлифовки, зависит от того, насколько выполнение операции шлифовки и создания шлифа::«функциональная часть готовой детали» будет последней работой/сервисом (грубо говоря, «гусеница» переименовывается в «куколку» только если метаморфоз завершён). Дальше можно рассматривать, что тут провайдер шлифовки: шлифовальный станок, шлифовальный станок и обслуживающие его люди («оборудование и приписанные к нему люди») или люди и приписанный к ним шлифовальный станок (это одно и то же, но если «станок и его люди», то проще обсуждать автоматизацию, устранение людей, а если «люди и их станок», то проще обсуждать, с кем договариваться, если станок не работает). Чем больше людей в составе «провайдера», тем больше шанс, что это будет сервис и провайдер сервиса (будут какие-то передачи материалов в шлифовку, затем будут забирать результаты — у людей, а не у станка), если нет — то просто инструмент какого-то создателя как сотрудника и метод работы этого создателя (никто ничего не «отдаёт в работу» и не «забирает из работы», это всё внутренние передачи между своими, ничего «чужого», никто никого не обслуживает, просто совместная работа в команде).
• Курс обучения — это сервис провайдера курса, который изготавливает мастерство в студенте::заготовка (тут тоже студент — надсистема-носитель для будущего мастера::«готовая система», носителя целевого для курса мастерства) в ходе «прохождения курса», состоящего из занятий::«сеансов сервиса». Студент::роль в 4D принимает участие (participation, специализация part_of) в «прохождении курса», то есть наборе занятий, равно как и провайдер курса, говорят о «наборе занятий». Будет ли агент, отыгрывающий роль студента переименован затем в мастера:: «готовая система» — точно так же зависит от того, последний ли это набор занятий курса в какой-то их серии курсов. Моделировать ли курс как мероприятие (система) или как процесс (прохождение курса студентом у провайдера курса) — обсуждаемо, лексика будет чуть разной. Несколько студентов, проходящих курс и их преподаватель можно представить, например, потоком::системой (с точки зрения провайдера курса, разные группы — разные потоки), группой — с точки зрения деканата, ибо группа сохраняется, проходя разные курсы в какой-то последовательности, как «сеансы». В потоке агенты, отыгрывающие роли студентов::«заготовки мастера» взаимодействуют не только с преподавателем (или компьютером, к которому приписан преподаватель — если планируем автоматизацию и в конечном итоге убрать людей), но и друг с другом при групповой работе. Подробней это всё разбирается в руководстве по инженерии личности.
• Игра — это сервис провайдера игры, который стимулирует продуцирование дофамина в организме игрока в ходе работ по задействованию сервиса («прохождение игры», состоящее из «сеансов» игры::сервис/метод работы провайдера игры). Игрок принимает участие в прохождении игры через участие в сеансах, равно как провайдер игры (и в групповых играх участники могут взаимодействовать и с провайдером, и друг с другом). Игрок не становится после игры «готовой системой» (хотя меняет состояние! Устаёт, или отдыхает, или злится от проигрыша) и тем более не становится «готовой системой» после сеанса игры (нет аналога переименования «гусеницы» в «бабочку» с возможными промежуточными состояниями, ибо нет какого-то радикального изменения, даже такого не слишком выраженного, как превращения «студента» в «мастера»).
• Курс лечения — это сервис провайдера лечения (курс считаем сервисом::поведением, а не мероприятием), который изготавливает здоровую часть организма в пациенте::«заготовка будущего здорового человека, носителя уже здоровой после курса лечения части») в ходе прохождения курса, состоящего из «лечебных процедур»::«сеансов лечения».

Ещё нужно смотреть на способы моделирования проектов по организации сервис-провайдеров: проекты можно моделировать как работы по каким-то методам (проект::поведение), но можно и считать организацией проекта (проект::организация). Будьте внимательными к типу того, что у вас называется «проект»:

• Проект организационного совершенствования/улучшения/improvement — это экземпляр работы (проект::работа::поведение с чётким сроком начала и конца, понятным результатом принятого метода/стратегии выполнения проекта, известными ресурсами) сервиса службы/провайдера орг-развития, который в ходе прохождения проекта улучшения за время ряда шагов улучшения (сеансы) вносит какие-то настройки/переключения в мастерстве как предмете метода/сервиса без изменения онтики этого мастерства (например, в настройки шлифовального станка вносятся коррективы, а обслуживающие станок операторы проходят тренинг, чтобы не смотреть каждый раз в инструкцию, а делать всё «по памяти». В этой ситуации не появляется никаких новых понятий и отношений, онтика шлифовки не меняется. Вот и в ходе оргсовершенствования ровно такие изменения, а не замена, например, шлифовки на напыление — и поменяется буквально всё, людей и AI надо будет переучивать на новый метод, инструментарий метода заменять). Альтернативный вариант моделирования ситуации — это проект как организация (люди, AI, инструментарий с понятными полномочиями по распоряжению трудом и капиталом). Проект тут провайдер, работы и сервис/метод плохо различимы — оргсовершенствование (работы одного задействования метода/сервиса оргсовершенствования). Как надо? Надо понимать, что бывают эти два варианта. Более классический, конечно, когда проект::«работа по методу»::поведение, а провайдер проекта — рабочая группа проекта.
• Проект оргразвития — это экземпляр работы сервиса офиса/службы::провайдер развития, который изготавливает новое мастерство (развивает уже имеющееся мастерство, то есть добавляет фичу, «модернизирует», что-то делает с текущей онтикой мастерства) и добавляет инструментарий в «новой оргвозможности»/«new capability»::«готовая система» в ходе прохождения проектом оргразвития ряда шагов развития, состоящих из курсов::проект обучения и лидерских мероприятий::проект для людей, а также проектов подготовки инструментов/оборудования (это специализации «шагов развития»::сеанс). Альтернативный вариант моделирования ситуации — проект это рабочая группа проекта (организация) оргразвития, включающая переучиваемых или вновь обучаемых людей, а также работников службы оргразвития. Тут опять-таки будут сложности с тем, что там сервис (оргразвитие::сервис::поведение) и кто над кем трудится. По этой линии (проект как организация) есть сложности моделирования (которые можно преодолеть по линии «программа проектов и портфель проектов — это программа и портфель организаций», но разговаривать в таком языке будет сложно), проще считать проект экземпляром работы по выполнению метода (это классика дисциплины project management, по этой линии проблем не будет).

Так что онтика сервиса/метода вроде как одна и та же для самых разных ситуаций, но всегда будут нюансы, поэтому будет меняться не только терминология, но и сами типы объектов в онтике.

---

1. Социализм этим и отличался: отсутствие инвесторов позволяло почти не обращать внимания на целевые системы, основное внимание было направлено на системы создания, см. http://odesskiy.com/zhvanetskiy-tom-3/parovoz-dlja-mashinista.html ↩︎