Бизнес-сервисы (услуги)

"Сервисная ориентация представляет собой такое идеальное видение мира, в котором ресурсы четко разделены и последовательно представлены в терминах сервисов".

J. Schekkerman. "Structuring the Enterprise around Services.
The Differences between Hype, Hope and Reality?"
IFEAD publishing, 2006.

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

Для сегодняшнего состояния дел в этой области существенно, что современные подходы и стандарты системного проектирования понимают систему, в том числе, и как предприятие (обобщенное) и предусматривают применение сервисной идеологии в той или иной форме с самых первых шагов проектирования предприятия, а также его ИС. При этом первыми и определяющими обычно являются шаги определения  бизнес-сервисов самого высокого уровня рассмотрения (а также других бизнес-объектов и внешней деловой среды). 

Так, стандарт ISO/IEC 15288 начинает анализ и проектирование системы с выяснения потребностей заинтересованных лиц (ЗЛ), выраженных в "необходимых им сервисах". В контексте проектирования АП речь идет, по сути, о бизнес-сервисах как о продуктах особого рода. (Слово бизнес понимается здесь и далее в наиболее общем смысле, то есть как любое дело, распространяющееся на все виды деятельности людей и не обязательно связанное с извлечением прибыли.) Это особенно важно, поскольку побуждает смотреть на систему не как на ИС в узком ее смысле, а как на автоматизированное предприятие (подразделение, организацию, объединение или кооперацию организаций или их подразделений). Однако отметим наличие и в самих стандартах многих "недосказанностей". Так, тот же стандарт ISO/IEC 15288 не говорит ничего про то, как с бизнес-сервисами связываются сервисы других типов, а выявление потребностей ЗЛ в терминах сервисов не предполагает или в недостаточном объеме предполагает решение специфической проектной задачи преобразования самого предприятия к сервисной форме.

В связи с этим надо уточнить трактовку услуги или сервиса как понятия - по крайней мере, для использования в ССП и в сервисно-ориентированной АП (которая существенно шире SOA). При этом наибольшее внимание мы будем уделять т.н. бизнес-сервисам и вопросам перехода от них к прикладным сервисам ИС.

В отечественной языковой практике, нормативно-правовой, нормативно-методической и технической документации наблюдается большое многообразие трактовок понятия услуги, в частности, услуга может рассматриваться в словарном понимании этого слова или как обязательно платная, иногда - только коммерческая деятельность, как государственная услуга в современной трактовке правительственных документов, как техническая служба в смысле терминологии "открытых систем", как программный сервис прикладной ИС, как Веб-сервис, как сервис СУБД или ОС, и т.п.

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

Во избежание подобных последствий начиная со следующего раздела здесь употребляется единственное слово "сервис". (Конечно, этим не делается попытка искоренения из ИТ-обихода слов "услуга" и "служба" как таковых.)

Для выбора трактовки в ССП рассмотрим три толкования слова "услуга": общенормативное толкование в русском языке, термин service в ISO 9000:2005 и тот же термин в рамках архитектурного подхода IFEAD и ряда других организаций.

Современная редакция толкового словаря Ушакова первым значением определяет услугу как ДЕЙСТВИЕ, приносящее пользу другому.

По ISO 9000 service - это РЕЗУЛЬТАТ действия. При этом сервис самостоятельно не определяется, но вводится как одна из разновидностей ПРОДУКТА (product), возможно запрошенного заказчиком, хотя явного указания на это нет, но всегда предоставляемого поставщиком заказчику. Для этой разновидности продукта говорится, что в общем случае результат действия носит "нематериальный" (intangible) характер. Однако, трактовка сервиса-услуги именно как результата действия (данная не в определении как таковом, а в примечаниях к определению термина product) даже в рамках этого стандарта не совсем однозначна, т.к. в пояснениях к стандарту service - это в одних случаях транспортировка (процесс), а в других - данное продавцом объяснение (результат).

В трактовке IFEAD (более близкой Ушакову, чем ISO 9000), см. [2], service - это осуществление хорошо определенной деловой функциональности, которая действует независимо от состояния любого другого сервиса, определенного в системе. Сервисы имеют хорошо определенный набор интерфейсов и действуют через предопределенный контракт (Примеч.: т.е. посредством строгого выполнения некоторых соглашений) между клиентом сервиса и самим сервисом. Сервис - это единица работы, выполненной поставщиком сервиса ("сервис-провайдером") для того, чтобы достигнуть желаемых конечных результатов для потребителя сервиса. И поставщик и потребитель - роли, которые играют организационные единицы или программные агенты от имени их владельцев.

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

1.      необходимо отделить сервис от его описания (по аналогии со стандартом IEEE 1471-2000),

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

Итак, в данной работе и в ССП принимается вариант более близкий к Ушакову и к IFEAD, поскольку он

1.      ближе к реальной практике словоупотребления не только в русском языке, но и в нормативно-методических, методических и технических документах других стран,

2.      ближе к содержанию, вкладываемому в термин "service" во многих эталонных архитектурных моделях.

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

Вместе с тем, большое внимание уделяется доставке сервиса (service delivery) клиенту (заказчику) и доступу к сервису (service access), причем действия по доставке результата и организации доступу к нему также могут рассматриваться как сервис.

Актуальность рассмотренных вопросов подтверждается тем, что и в начатой разработке эталонной модели сервисно-ориентированной архитектуры SOA [13]  проблема понятия сервиса рассматривается  отдельно.

Среда и качества бизнес-сервисов

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

Независимость сервиса, его определение через интерфейсы и другие его системные свойства, которые выделяют в современном системном сервисном подходе, весьма важны в ССП, но на бизнес-уровне также являются идеализацией, границы разумного применения которой должен определять бизнес.

Различение и определение в бизнес-сервисе непосредственного результата (output), конечного результата (outcome) и итогового воздействия (impact) является необходимым требованием для планирования и мониторинга эффективности и результативности бизнеса и инвестиций в сервисы, в том числе в ИТ-системы, их выполняющие и/или поддерживающие. Вместе с тем, также важны характеристики действия (процесса), вырабатывающего результат.

Пример: сервис (государственная услуга) по выдаче гражданину иностранного паспорта. Для нее нужно определять и оценивать:

1.      непосредственный результат (выход) услуги: например, т.н. "заграничный" паспорт, полученный гражданином в результате оказания ему государственной услуги ПВС ФМС РФ или МИД РФ (тут видно, что на самом деле за одной государственной услугой скрывается несколько реально различных услуг); описываются и оцениваются КАЧЕСТВА непосредственного результата («выхода процесса»): правильность указания персональной информации и других паспортных данных, вероятность скрытого брака, параметры соответствия требованиям стран, в которых паспорт должен признаваться, характеристики защищенности (физической, информационной), вероятность физической несовместимости с устройствами чтения (особенно за рубежом) и др.

2.      характеристики действия, например, время, за которое услуга оказывается,  удобство запуска действия (процесса), возможность контроля потребителя за ходом процесса, охват действием и доступом к нему разных групп населения и территорий, процент рекламаций к выполнению действия (вызванных разными причинами, например, доставкой не по адресу), и др.

3.      конечный результат: планируемый  эффект, достигаемый потребителем услуги и другими ЗЛ за счет получения и использования непосредственного результата услуги. Например, успешная реализация гражданином своих прав, получение им новых возможностей, получение пользы людьми, пригласившими гражданина в другую страну, и др. То есть описывается и оценивается ЦЕННОСТЬ конечного результата.

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