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

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

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

Поэтому дальше идут не «типовые ситуации» и «алгоритмы мышления», а просто примеры.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Хорошие целевые системы --- игровые сессии, которые создаются провайдерами игр. Целевые системы бывают самые разные, сервисы бывают самые разные, типовых вы не найдёте.

Вы можете менять два типа систем вашим собственным сервисом вас-как-системы-создания:

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

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

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

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

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