Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Сервисная ориентация и определение целевой системы

Как выбирать целевую систему, если речь идёт о сервисе? Прежде всего нужно вспомнить, что всё зависит от конкретного набора стейкхолдеров и их интересов, конкретной конфигурации контрактов. Ответа из учебника на вопрос про выбор целевой системы не будет. Могут быть только разрознённые замечания, помогающие размышлениям.

Если речь идёт о сервисе, то скорее всего в названиях будут фигурировать отглагольные существительные -- использование таких существительных (а в английских текстах ing-овой формы слов) должно сразу настораживать. Какая-нибудь "окраска" или "стрижка", "поставка" или даже "обучение". Тут засада: что считать сервисом, а что его результатом, что целевой системой, что использующей? Ибо это не так очевидно, консенсуса на эту тему нет, до сих пор актуальна работа Chris Partridge об онтологии сервиса 2010-2011 годов (http://www.modelfutures.com/file_download/17/MOD+CIO+-+Service+Analysis+Report+-+v1.3.pdf и https://www.oasis-open.org/committees/download.php/41420/Chris%20Partridge.pdf).

Мы предлагаем подход, который максимально подходит под моделирование в ArchiMate. Другими словами, сервис -- это внешне видимое поведение, поведение на канале доставки сервиса (поведение, видимое в "окошечке" оказания сервиса снаружи).

Поведение мы вполне можем определить в 4D, как набор взаимодействующих в процессе оказания сервиса объектов. И дальше рассортировать их по целевой системе (результат оказания сервиса -- "стрижка" как то, что случилось на голове после стрижки, "окраска" как то что случилось на заборе после его покраски) и обеспечивающей системе (стрижка -- это часть парикмахерской, которая стрижёт голову; окраска -- это та часть малярной бригады с её оборудованием и красками, которая красит забор).

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

И тут я бы советовал целевой системой всё-таки считать результат, который потом уносят из "окошечка сервиса", обеспечивающей -- всё, что помогает результату стать результатом (что находится за окошечком и не видно клиенту). Причёска+человек-с-настроением -- это результат сервиса стрижка, т.e. целевая система. А парикмахерская это обеспечивающая система, станочки по стрижке и станочки по настроению вместе с людьми-операторами этих станочков. Унесённые товары+человек-с-настроением это результат шоппинга. А вот торговый зал и его оборудование вместе с сотрудниками магазина -- это обеспечивающая система. Человек-со-знаниями+человек-с-настроением -- это целевая система для обучения (ничего не мешает рассматривать сразу два входящих в целевую систему объекта, при этом они физически совпадают в 4D).

Для чего такие сложности? Ну, обеспечивающей системой занимается обычно CTO/CIO и менеджер, а вот целевой -- системный инженер. Кто-то должен делать парикмахерскую, но кто-то должен проконтролировать, что всё сработало правильно, и стрижка+настроение получились, уши не обрезали, именно этот клиент ушёл довольный (а не "есть все условия, чтобы клиенты довольными уходили") и дальше его с такой причёской и настроением не выгнали из дома или с работы. Кто-то должен разбираться в каждом случае, когда что-то пошло не так с конкретным целевым результатом, конкретной целевой системой.

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

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

И ещё раз повторю: это всё не типовые примеры и рассуждения, которые нужно воспроизводить в реальных проектах. Нет, это просто некоторые заметки для прочтения перед тем, как включить голову и подробно рассмотреть свой проект, стейкхолдеров и свою роль в этом проекте. Даже если вашим проектом окажется парикмахерская, покраска забора или магазин, всё в вашем конкретном случае может оказаться не так, как у меня тут написано.

UPDATE: Дискуссия в https://www.facebook.com/ailevenchuk/posts/10208926503093879
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 17 comments