Сервис-ориентация. Мир провайдеров.
Переход в мышлении от поставки продуктов как целевых систем к оказанию сервисов (выполнению экземпляров работ услуги/метода провайдером/поставщиком услуги/метода над чужим предметом работы) оказался очень продуктивным и в современном языке называется **сервис-ориентацией.**И мы видим всё больше и больше провайдеров — «интернет-провайдеры» как раз отсюда, «поставщики сервиса доступа к интернету». Предмет их сервиса, он же целевая система — «доступ к интернету», подразумевающий определённое физическое состояние аппаратуры клиента и аппаратуры провайдера, обеспечивающей передачу данных между аппаратурой клиента и аппаратурой всех остальных клиентов всех остальных интернет-провайдеров мира, имеющих «доступ к интернету» в мире.
Поставщики софта, который работает как облачный инструментарий, обрабатывающий по какому-то методу чужие данные, используют бизнес-модель SaaS, software-as-a-service. Тут надо учесть, что в информационных технологиях сервис часто рассматривается как сервер (микросервисы — это вообще-то микросерверы, а не микросервисы как функции/методы серверов), в крайнем случае — неодушевлённый «станок», но не метод/поведение, метод вообще может быть опущен в рассуждениях, и сразу речь идёт о «вызове сервиса» как проведение работы провайдером, метод этой работы не обсуждается отдельно. Всегда пытаемся уточнить, что же имеет в виду собеседник, когда поминает термин «сервис», помним про множество словарных значений каждого термина! Софт-как-сервис — это софт, который оказывает сервис, софт тут — служба/сервер/провайдер сервиса. Но провайдером могут назвать и организацию, у которой есть мастерство проведения сервиса, а софт тут — инструментарий. Если бы это была мастерская, где точили ножи, то рассмотрение тут было бы то же самое — «станок-как-сервис», можно было бы принести свои ножи, как в софт в модели SaaS несут свои данные, поточить ножи, как в модели SaaS обрабатывают свои данные, и забрать ножи после заточки, как в модели SaaS забирают данные после их обработки. Плата только за выполнение (работ) услуги/сервиса, не надо платить за ножи или данные.
Все проекты перехода от товаров/продуктов/изделий к сервисам (сервис-ориентация) похожи в том, как о них думать. Сервис-ориентация начала затрагивать и традиционные продукты и изделия, то есть физические объекты, изготавливаемые как «товар» — то есть поставщики товаров начали тоже переходить на бизнес-модели поставки сервиса (вернее, поставки работ сервера по методу сервиса).
Например, возьмём чугунные чушки, «чугун серый литейный»:
Если учесть сервис-ориентацию, то услугой/сервисом будет «поставка», предметом сервиса будет «чугун» (чугунные чушки) и лучше говорить «поставка чугуна», ибо обычно оставление слишком общих слов в названиях «методов работы»::«паттернов поведения» (поставка, разработка, изготовление, создание, покупка) не позволяет вести содержательного разговора, не хватает конкретизации хотя бы до уровня метаУ-модели, предметной области.
Глаголов обычно мало, и они очень общие, это наследуют и отглагольные существительные (-ing форма глагола в английском), их мало и они очень общие. Поэтому для конкретизации указывают предметы методов, на которые указывают глаголы — и специфика предметной области вносится терминами предметов метода, а не терминами самих методов/функций/культур/способов/стратегий/сервисов.
Переход от «продажи чугуна» к «поставке чугуна» увеличивает возможности предприятия, превращающегося из «поставщика собственного товара» в «службу» или «провайдера доступа к чугуну»: сам чугун, как продукт, остаётся тот же самый — но если обратить внимание не на сам чугун, а на метод поставки, то могут существенно меняться состояния объектов в предметной области поставки. К спецификации чугуна появляется спецификация сервиса поставки, «условия поставки» (в сервис-ориентированном подходе говорят часто о SLA, service-level agreement[1]). Поставка точно вовремя для производства (just in time[2]), через склад предприятия или прямо к точке переплавки, поддержание минимального запаса в течение года или просто поставка одной крупной партии, возможности кредитования при поставке, поставка от третьих фирм, и т.п. — вариантов методов «поставка» для предмета «чугун серый литейный» множество. Получается, мы резко расширили ассортимент за счёт этих вариантов сервиса поставки, хотя предмет сервиса (чугун, который в конечном итоге будет «поставлен», перейдёт во владение получателя чугуна) оставили тем же самым.
Сервисы/функции/методы обычно легко распознать в языке — это отглагольные существительные, в которых скрыт глагол (поведение), но тем не менее в языке сохраняется словоупотребление по их поводу, как для вещи. Если действие/процесс «обучить», то сервис будет «обучение». Если действие/процесс «поставить», то сервис будет «поставка». В английском языке сервисы обычно выражены глаголами в их ing-форме. При этом не надо обольщаться высоким уровнем обобщения в названиях метода/сервиса (обучение, поставка). Помним, что обычно указывается и предмет: обучение азбуке Брайля, танцам, системному мышлению проходит абсолютно разными методами, но термин в названии метода будет «обучение». Поставка свежеприготовленных гамбургеров, литейного чугуна, коробочного софта проходит тоже абсолютно разными методами, но термин в названии метода будет «поставка». Интересуйтесь предметами метода, а также требуйте указать конкретный вариант метода (скажем, «чистка» может быть трубопровода и зубов, «чистка зубов» может быть с использованием разного инструментария — «ультразвуковая глубокая чистка зубов», «чистка зубов щёткой и зубной пастой», «чистка зубов зубной нитью»). Уточняйте: и когда сами говорите, и когда вам говорят про методы/сервисы/культуры! Если не уточните, то вас наверняка поймут неправильно, или вы поймёте собеседника неправильно. Выбирайте всегда правильный уровень абстракции для обсуждения!
Переход от «вещей» к «поведению», изменениям, динамике оказывается очень продуктивен, поэтому сервис-ориентация стремительно вытесняет ориентацию на продукт. Операционная система Windows 10 уже рассматривалась фирмой Microsoft не столько как продукт (целевая система, которая передаётся клиенту), но как сервис, то есть метод/культура поддержания продукта в постоянно обновлённом виде (целевая система как предмет сервиса, то есть Windows 10, принадлежит клиенту, но Microsoft меняет версии, добавляя новые возможности и исправляя ошибки — улучшает целевую систему своим внешним поведением). Microsoft из поставщика «коробочных» программных средств стал провайдером программных сервисов. Переход к Windows 11 по факту означал просто маркетинговое событие, смену имени, ибо ничего принципиально нового не привнёс: Windows 11 по факту просто очередная версия того же сервиса от фирмы Microsoft. А дальше Microsoft переводит клиентов-покупателей бывшего коробочного продукта MS Office на SaaS бизнес-модель, то есть от офисного софта как «товара» предоставляет только внешнее его поведение, делает серверный/облачный MS Office (ныне Microsoft 365) своим инструментом, размещает этот софт в своих датацентрах, оставляя на компьютерах клиентов-абонентов/подписчиков сервиса (а не покупателей коробочного софта) только знакомый им интерфейс MS Office. Предмет этого сервиса — данные клиента (обратите внимание, что методы/сервисы работают не только с системами, но и с самыми разными объектами предметной области методов/сервисов, которые называем предметами, и которые могут менять своё состояние с исходного на входе метода на выходное после применения метода —клиенты в ходе их обработки мастерством и инструментами Microsoft::провайдера::создателя меняют своё состояние с исходных на обработанные выходные после применения софта Microsoft. Предметы, а не целевые системы — методы/сервисы могут работать и с описаниями).
Сервис-ориентация чудесным образом расширяет возможные рынки: разных типов/видов/категорий/классов методов в мире не так много, несколько тысяч (и поэтому глаголов в языках всего несколько тысяч), а вот разных видов вещей — миллионы и миллионы (поэтому существительных миллионы). Мышление о методах/сервисах экономно: с миллионами и миллионами разных товаров работают одни и те же всё более и более универсальные сервисы. Эти сервисы соответствуют самым разным ожидаемым от создателей-провайдеров ролям в самых разных графах создателей. Поставщик чугуна обычно просто поставляет чугун-товар. Если же речь идёт о сервисе, который специализируется именно на методах/сервисах поставки, то легко можно кроме чугуна поставлять что-то ещё. Можно вообще стать «маркетплейсом». Если говорить о платежах, то можно платить за что угодно. Если говорить о поддержке облачного софта, то по большому счёту этот софт может быть каким угодно. Не только с одним продуктом можно делать::метод разное, но одно и то же делание::метод оказывается хорошо приложим к разным продуктам.
Современный магазин (скажем, интернет-агрегаторы розничных торговцев, «маркетплейсы» — «ходят» сегодня туда, Yandex.market, Wildberries, Megamarket, Ozon, Amazon, они сопряжены со службами доставки и сетью пунктов выдачи заказов с примерочными) тем самым поставляет не столько покупаемый продукт, сколько предоставляет сервис (метод работы с каким-то предметом метода/сервиса) по продаже::сервис и доставке::сервис продукта::предмет. Мастерство и инструментарий маркетплейса как провайдера сервиса «поставка против платежа» с предметом «поставка против платежа». Тут легко запутаться с одноимённым сервисом и предметом сервиса, ибо «поставка» и «платёж» с одной стороны отглагольные существительные (имена методов работы с товаром/продуктом::«предмет метода» и деньгами::«предмет метода»), с другой стороны — система в физическом мире, где продукт доставлен и перешёл в собственность клиента, деньги платежа доставлены на счета поставщика продукта и перешли в его собственность (про безналичные деньги думаем примерно так же, как про наличные: там с нюансами, но всё сводится к кучке золота в подвале банка, так что деньги — это про физический мир, а не описания).
Нужно при этом понимать, что целевая система проекта создания и развития провайдера сервиса и предмет сервиса находится у клиента. Сервис провайдера что-то меняет в системах клиента (целевой или каком-то создателе в графе создателей, например, инструменте какого-то метода создания) или даже не системе, а описаниях системы клиента (иногда по длинной цепочке «описаний описаний»). Например, сервис может менять описание целевой системы, отражая это в проектной документации. Сервис может менять содержание своей базы данных с описанием клиентской целевой системы — а затем это описание может быть использовано для физических изменений воплощения целевой системы (изготовления или ремонта), и вся затея с задействованием провайдера может быть именно для этого конечного физического изменения. Все такие связанные с провайдерами сервисов/службами/серверами цепочки изменений, тянущиеся до физического мира, обязательно нужно отслеживать и продумывать.
Если вам поручили «сделать сервис» (обычно это означает «сделать провайдера, который будет предоставлять услуги, то есть проводить экземпляры работ по какому-то методу работ»), то можно совершить крупную ошибку: считать, что целевой системой является сам провайдер: его инструменты и мастерство. Нет, целевой системой является та система, которую мы изменяем сервисом/методом (возможно, по цепочке описаний, если предметом сервиса является какое-то описание, а не система, а иногда предметом будет мастерство или инструментарий создания целевой системы).
Создаваемый сервис в данном случае — это метод::поведение нового создаваемого провайдера (который работает над какой-то чужой целевой системой, по факту входя в команду), и этот провайдер — «наша система». А ещё вы сами создатель для «нашей системы», да вам нужно ещё и самому создать себя как производителя работ по созданию провайдера, то есть речь идёт о каком-то пути создания в большом графе создателей целевой системы. Целевая система остаётся той системой, по поводу которой нужно договориться всем задействованным создателям в графе создателей — ваш проект создания нового провайдера имеет смысл ровно в той мере, что кому-то нужно что-то сделать с его целевой системой, и он приглашает «вашу систему» (провайдера) поучаствовать в проекте.
Нужно потом будет ещё убедиться, что сделанный вами провайдер/служба/сервер работами своего сервиса (работами своего метода, то есть работами своего мастерства с инструментарием) таки создаёт целевой продукт/систему с нужным уровнем качества, а ещё вы демонстрируете достаточные скорость и эффективность создания вами самого этого провайдера.
Почему графы создателей такие сложные? Вот один из путей/цепочек создания в графе создателей причёски (не парикмахерской, ибо целевая система в проекте создания парикмахерской — причёска, парикмахерская тут одна из «наших систем», а в графе создателей есть и другие «наши системы»):
- Система-1: вы, как создатель команды создания парикмахерской. Вы организуете небольшую инженерно-менеджерскую команду и поставщиков товаров (кресла, ножницы, лак) и сервисов (ремонт помещения) в проект, который создаст парикмахерскую (и мы даже не рассматриваем начало цепочки в графе создателей: вам ведь «поручили создать» парикмахерскую, то есть вы ещё и не в начале цепочки, но вас кто-то создал как создателя!)
- Система-2: инженерно-менеджерская команда и поставщики товаров и сервисов, которые создают парикмахерскую (эту команду организовали вы)
- Система-3: парикмахерская (люди с парикмахерским мастерством, помещение с инструментами, менеджеры), созданная вашей инженерно-менеджерской командой
- Система-4: причёска, целевая система всего проекта, создаваемая парикмахерской в ходе кейса/проекта для каждого клиента парикмахерской.
Вот это цепочку/путь на графе создателей хорошо бы себе ясно представлять. Без чёткого понимания кто какую систему создаёт, за что отвечает, нельзя разобраться в проекте, риск провала будет велик.
Так что в проекте создания парикмахерской::провайдер для выполнения работ сервиса стрижки и укладки целевой системой (продуктом) будет причёска чужих волос, которая меняет своё состояние с «не было» в «стало». Частные методы, составляющие все полные методы работ (сервис) по стрижке и укладке — выбор фасона, стрижки волос, укладки, возможного смешивания волос с лаком и всякими украшающими ленточками и цветочками (если они предусмотрены). Это и есть создание и (поскольку эти причёски будут делаться снова и снова, и будут становиться всё лучше и лучше) развитие причёски. Работы по созданию и развитию причёски и есть оказание/работа сервиса/метода ООО «Чикчик» со всеми его людьми-парикмахерами и помещениями с инструментами парикмахеров в роли парикмахерской.
Шикарный сервис стрижки (метод работы парикмахера с волосами клиента золотыми ножницами на кресле-троне под живой оркестр) с результирующей плохой причёской — это не то, что нужно, это явно не будет успешной целевой системой. В сервисе главное — достижение состояния целевого предмета сервиса (предмета метода работы, то есть предмета создания причёски — достижение целевого состояния причёски). Причёска для спорта вместо причёски для свидания — это ведь тоже не то, что нам нужно? Когда мы занимаемся системой создания, чтобы получить сервис создания целевой системы (разрабатываем серверный софт, открываем сервисную фирму-провайдера), никогда не нужно забывать о целевой системе и её надсистеме.
Очень легко забыть, для чего вообще существует создатель-провайдер, для чего будет задействован сервис — и после того, как это забыто, целевая система перестаёт быть успешной (а ведь всё делается для неё), довольные клиенты вдруг становятся недовольными, и вы их теряете. Если менеджер думает о заводе по выпуску самолётов как своей целевой системе, то завод может быть супер-пупер каким продвинутым, люди супер-пупер какими сотрудничающими, рабочие процессы супер-пупер какими отлаженными, но если выпускаемые самолёты не летают (целевая система — используемый, то есть летящий, самолёт), то и завод по выпуску таких нелетающих самолётов не нужен (более того, он вреден: прожигает деньги инвесторов).
Если вы думаете о целевой системе и внешних проектных ролях проекта по её созданию и развитию, то думайте в письменном виде: документируйте эти мысли и обсуждайте их с командой и этими внешними проектными ролями. И проверяйте по самым разным чеклистам, обо всех ли важных объектах проекта вы подумали, не пустили ли вы дело на самотёк, не сделали ли вы ошибок в своём мышлении, не пропустили ли чего в своих работах.