Сервис-ориентация. Мир провайдеров.
Переход в мышлении от поставки продуктов как целевых систем к оказанию сервисов для изготовления чужих целевых систем оказался очень продуктивным и в современном языке называется сервис-ориентацией. Поставщики сервисов называются всё чаще «провайдерами» (providers, «интернет-провайдеры» как раз отсюда, «поставщики сервиса доступа к интернету»).
Например, традиционный продукт --- чугунные чушки, «чугун серый литейный»:
Если учесть сервис-ориентацию, то услугой/сервисом будет «поставка чугуна», и это резко увеличивает возможности предприятия, превращающегося из «поставщика» в «службу» или «провайдера доступа к чугуну»: сам чугун, как продукт, остаётся тот же самый --- но могут существенно меняться условия его поставки. Поставка точно вовремя, через склад предприятия или прямо к точке переплавки, поддержание минимального запаса в течение года или просто поставка одной крупной партии, возможности кредитования при поставке, поставка от третьих фирм, и т.п.
Сервисы (как и соответствующие им функции: сервисы от системы поставляются в надсистему, функции наоборот --- получаются от системы со стороны надсистемы) обычно легко распознать в языке --- это отглагольные существительные, в которых скрыт глагол (поведение), но тем не менее в языке сохраняется словоупотребление по их поводу, как для вещи. Если действие/процесс «обучить», то сервис будет «обучение». Если действие/процесс «поставить», то сервис будет «поставка». В английском языке сервисы обычно выражены глаголами в их ing-форме.
Сервис-ориентация чудесным образом расширяет возможные рынки: разных типов/видов/категорий/классов действий в мире не так много, несколько тысяч (и поэтому глаголов в языках всего несколько тысяч), а вот разных видов вещей --- миллионы и миллионы (поэтому существительных миллионы). Мышление о сервисах экономно: с миллионами и миллионами разных товаров работают одни и те же всё более и более универсальные сервисы. Эти сервисы соответствуют самым разным функциям в самых разных надсистемах.
Переход от «вещей» к «поведению», изменениям, динамике оказывается очень продуктивен, поэтому сервис-ориентация стремительно вытесняет ориентацию на продукт. Операционная система Windows 10 уже рассматривается фирмой Microsoft не столько как продукт (целевая система, которая передаётся клиенту), но как сервис по её поддержанию (целевая система принадлежит клиенту, но Microsoft меняет версии, добавляя возможности --- улучшает целевую систему своим внешним поведением). Microsoft из поставщика программных средств стал провайдером программных сервисов. Переход к Windows 11 по факту означал просто маркетинговое событие, смену имени, ибо ничего принципиально нового не привнёс: Windows 11 по факту просто очередная версия того же сервиса фирмы Microsoft.
Современный магазин тем самым поставляет не продукт, а сервис по продаже продукта. Программы не нужно поставлять клиенту, ему нужно поставить сервис (внешнее поведение) этой программы --- сама программа может остаться в датацентре компании, которая эту программу разрабатывает. Так появляются системы SaaS --- software-as-a-service, поставщики софта становятся провайдерами сервиса. Нужно при этом понимать, что целевая система для провайдера сервиса --- у клиента, его сервис что-то меняет в системе клиента. Например, сервис может менять описание целевой системы, отражая это в документации. Сервис может менять содержание своей базы данных с описанием клиентской целевой системы --- а затем это описание может быть использовано для физических изменений воплощения целевой системы, и вся затея с задействованием провайдера может быть именно для этого конечного физического изменения. Все такие связанные с провайдерами сервисов/службами/серверами цепочки изменений, тянущиеся до физического мира, обязательно нужно отслеживать и продумывать.
Если вам поручили «сделать сервис», то можно совершить крупную ошибку: считать, что целевой системой является оказывающая сервис система. Нет, целевой системой является та система, которую мы изменяем сервисом, а сервис в данном случае --- это поведение создающей системы-провайдера, это «наша система» (а ещё вы сами создающая система для нашей системы, и вам нужно ещё и самому создать себя как производителя работ по созданию провайдера, то есть речь идёт о цепочке создания). Нужно потом будет ещё убедиться, что сделанный вами провайдер/служба/сервер своим сервисом таки создаёт целевой продукт/систему с нужным уровнем качества, а ещё вы демонстрируете достаточные скорость и эффективность создания вами самого этого провайдера.
Целевой системой парикмахера является причёска, сервисом --- стрижка (когда делают ножницами чик-чик, происходит работа, изменения в мире), а парикмахерская вместе с парикмахером --- создающая система, выполняющая практики жизненного цикла причёски. Причёска изменяется из «не было» в «стало», с ней работают --- эти выполняемые практики выбора фасона, стрижки волос, укладки, возможного смешивания их с лаком и всякими ленточками (если они предусмотрены) и есть жизненный цикл причёски. Парикмахерская выполняет практики этого жизненного цикла как свои работы.
Шикарный сервис стрижки (работы парикмахерской с волосами клиента, золотыми ножницами на кресле-троне под живой оркестр) с результирующей плохой причёской --- это ведь не то, что нам нужно? Причёска для спорта вместо причёски для свидания --- это ведь тоже не то, что нам нужно? Никогда не нужно забывать о целевой системе и её надсистеме, когда мы занимаемся системой создания, чтобы получить сервис создания целевой системы: легко забыть, для чего вообще существует система создания/провайдер, для чего существует её сервис --- и в этот момент целевая система перестаёт быть успешной, довольные клиенты вдруг становятся недовольными, и вы их теряете. Если менеджер думает о заводе по выпуску самолётов, то завод может быть супер-пупер каким продвинутым, люди супер-пупер какими сотрудничающими, рабочие процессы супер-пупер какими отлаженными, но если выпускаемые самолёты не летают, то и завод по выпуску таких самолётов не нужен (более того, он вреден: прожигает деньги инвесторов).
Если вы думаете о целевой системе и её внешних проектных ролях, то думайте явно: документируйте эти мысли и обсуждайте их с командой и этими внешними проектными ролями. Системное мышление заставит вас это сделать, не даст допустить ошибку, поможет преодолеть эту сложность проектов с длинными цепочками создания.
Почему цепочки создания длинные? Например, вам поручили организовать парикмахерскую. Вот и длинная цепочка создания:
- вы организуете вашу небольшую команду и поставщиков в проект, который создаст парикмахерскую (и мы даже не рассматриваем начало цепочки: вам ведь «поручили создать» парикмахерскую, то есть вы ещё и не в начале цепочки!)
- проект, который создаёт парикмахерскую (и который организовали вы)
- парикмахерская, созданная проектом по её созданию
- причёска, созданная парикмахерской в ходе кейса/проекта стрижки.
Вот эту цепочку хорошо бы себе ясно представлять. Без чёткого понимания кто какую систему создаёт, за что отвечает, нельзя разобраться в проекте, риск провала будет велик.