Skip to content

Системы-продукты и сервисы/методы провайдеров/создателей

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

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

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

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

Даже со всеми нюансами ситуация выполнения сервисных работ сводится к тому, что никакого продукта/изделия у вас в проекте не будет, но вы просто примете участие в работах создателей какой-то целевой системы по какому-то методу, и даже не непосредственно создателей, а каких-то работах создателей из графа создателей, достаточно далеко от целевой системы. Метод, которым вы меняете состояние чужих систем (чужой целевой системы, чужих конструктивов, которые потом составят чужую целевую систему, или даже чужого инструментария в графе создания), называется сервис/service/услуга**.**

Ваши тут будут только работы/поведение/изменения по вашему методу (то есть работы вашего мастерства и инструментария по знаниям/теориям/алгоритмам метода) вас как создателя над не принадлежащей вам целевой системой, изменение её состояния. Вы будете тут только системой создания, ваша команда будет предоставлять клиенту только внешнее поведение — работы сервиса.

В литературе (в том числе англоязычной, там та же ситуация, что и в русском языке) можно найти много разных мнений, что такое «сервис»[1], основные из них:

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

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

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

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

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

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

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

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

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

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

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

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

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

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


  1. https://yadi.sk/d/4hIEcpcn3Ny9iN ↩︎