Что такое референтная модель бизнес процесса

Реализация Frameworx в телекоммуникационном API

Скорость развития рынка телекоммуникаций вынуждает его участников непрерывно совершенствовать свои бизнес-процессы, снижая себестоимость и максимально сокращая время разработки и вывода новых услуг на рынок. Большой проблемой при этом становится построение правильных бизнес-моделей внутри организации. В процессе реализации услуги YouMagic.Pro мы столкнулись с тем, что каждый продуктолог, который начинал заниматься этим проектом, видел его развитие по-своему. Менялись интерфейсы, формы, мы переписывали код, и все это приводило к ошибкам в работе сервиса. В какой-то момент заявленные требования уже перестали быть совместимыми с изначальной архитектурой и мы решили посмотреть, как реализованы бизнес-процессы в других телеком-компаниях. В результате анализа мы пришли к решению внедрить референтные модели SID Frameworx от ТМ Forum. В этой статье мы расскажем, что же такое референтные модели и с чего нужно начинать разработку телеком-сервисов, которые в дальнейшем будут способны адаптироваться под различные изменения бизнес-требований.

Референтные модели

Итак, что же такое референтные модели и откуда они взялись.

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

Формализованные знания — это знания, которые можно описать, задокументировать и рассказать о них другим людям. Их представляют в графической форме, в виде рисунков, спецификаций, учебников, процедур. Они могут быть словами, номерами и объектами. С точки зрения практики повторно используемые ресурсы и формализованные знания можно разделить на следующие категории:

Во всем разнообразии повторно используемых ресурсов нас заинтересовали референтные модели разработки, внедрения и эксплуатации программного обеспечения для телекома. Они представляют собой эталонные схемы, процедуры и методы организации бизнеса, разработанные на основе реального опыта внедрения в различных компаниях по всему миру. В рамках этой статьи мы остановимся на концепции референтных моделей Frameworx для телекоммуникационных компаний.

Преимущества реализации существующих моделей над проектированием с нуля

Телекоммуникационные и информационные технологии, а также ассортимент предлагаемых компаниями связи услуг развиваются и изменяются чрезвычайно динамично. Сейчас бизнес не может тратить на разработку услуги 1–2 года, как было в связи ранее. В настоящее время срок выхода сервиса на рынок измеряется месяцами. Вместе с ними в постоянном развитии находятся компоненты управляющих информационных систем, а также сами бизнес-процессы. При этом компании довольно часто не располагают временем для проведения полномасштабного проектирования новых процессов. Что уж говорить о разработке, тестировании и внедрении управляющих модулей, которые будут реализовывать в системах новые услуги.

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

Большинство программистов, или просто технарей, на вопрос про бизнес-процессы в компании ответят: «Это описание того, как заявка от сотрудника поддержки передается в CRM техническому специалисту». Или приведут другой пример из жизни любой компании. Мы посмотрели на это с другой стороны. Подключение клиента и его работа в личном кабинете — это тоже бизнес-процесс. Также существует большое количество скрытых от пользователя бизнес-процессов. Например, разблокировка при пополнении баланса; активация скидок при заказе определенного набора или объема услуг. Все эти бизнес-процессы в подавляющем большинстве случаев автоматизированы в услугах. Когда бизнес-процесс автоматический, то субъекты (люди) практически отсутствуют, и код управляет объектами бизнес-процесса. И поскольку субъекты — это код, то он не может принять человекоподобные решения в условиях недостаточности информации. В таком варианте на первое место выходит построение универсальных и эффективных моделей данных для манипуляции ими автоматическим кодом.

В процессе проектирования ядра продукта «МТТ Бизнес» мы изучили существующий опыт и нашли решение: использовать информационные фреймворки. Они описывают типовые структуры построения моделей, данных для отраслей или предметных областей. Начиная от общего описания основных объектов (для нас, например, это клиент, услуга, тариф и т. д.) и вплоть до конкретных диаграмм компонентов, уже описанных в нотации UML. В них уже заложены best-practices опыта специалистов, которые решали аналогичные проблемы ранее.

Почему мы выбрали ТМ Forum и Frameworx

Tele Management Forum (TM Forum) — это некоммерческая ассоциация, которая объединяет предприятия электросвязи и их поставщиков с целью написания стандартов, рекомендаций и моделей для информационных технологий в телекоммуникационной отрасли. Ассоциация основана в 1988 году по инициативе компаний British Telecom и AT&T и сначала называлась OSI/Network Management Forum. К началу 1989 года была одобрена первая спецификация протокола OSI/NM Forum, а уже в 1990 году в организацию входило 85 компаний из 13 стран. В дальнейшем TM Forum объединила практически все мировые телекоммуникационные компании.

Основными направлениями исследований и разработок TM Forum стали:

Концепциями TM Forum пользуются во всем мире лидеры рынка информационных и телекоммуникационных услуг.

Frameworx

Frameworx — это развитие концепции NGOSS. Как уже было сказано, основная задача этой концепции состоит в определении стандартов для бизнес-процессов операторов связи, а также в унификации форматов представления используемых в системах управления данных и интерфейсов. Особенности концепции Frameworx стали несколько факторов.

1. Разделение бизнес-процессов и применяемых технических компонентов.
Любой бизнес-процесс должен управляться как часть централизованной инфраструктуры. Для этого используются механизмы, которые обеспечивают последовательность выполнения действий. Они также отвечают за осуществление контроля хода бизнес-процесса от одного приложения до другого.

2. Распределенная система с нежесткими связями между ее элементами.
Frameworx подразумевает под собой создание «распределенных систем» с нежесткими связями между их элементами. Это означает, что вместо единого монолитного приложения для управления всеми операциями телекоммуникационной компании предлагается использовать набор интегрированных и взаимодействующих друг с другом приложений.

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

Основу концепции образуют карты и модели бизнес-процессов. Frameworx включает в себя следующие структуры:

SID Framework

Информационная модель (information framework) является составной частью Frameworx и определяет подход к описанию и использованию данных, задействованных в бизнес-процессах компании связи.

Информационная структура (SID) представляет собой базовую модель и общий словарь всей информации, необходимой для осуществления бизнес-процессов. Использование SID снижает сложность обслуживания, системной интеграции, разработки и проектирования.

С точки зрения практики SID Framework можно представить в виде схемы.

Как и где мы применили SID

Продукт «МТТ Бизнес» имеет двухуровневую архитектуру:

При принятии такого решения мы также понимали, что помимо одного портала продукта «МТТ Бизнес» к тому же API могут быть подключены другие порталы, реализующие аналогичные услуги и бизнес-правила. Наши ожидания оправдались, и через год после запуска в продакшен продукта «МТТ Бизнес» мы подключили к API двух партнеров с аналогичными услугами без каких-либо существенных доработок.

Для реализации бизнес-логики в API мы реализовали несколько доменов SID Framework: Product, Customer, Service, Resource. Реализация услуги «МТТ Бизнес» на этапе разработки не потребовала реализации всех бизнес-сущностей (ABE) из этих доменов. Это связано с тем, что, например, процесс сопровождения услуги реализован в других системах и такие бизнес-сущности, как Customer Problem, Customer SLA, Service Trouble и т. д., покрываются этими системами. На схеме ниже отражены бизнес-сущности, реализованные в «МТТ Бизнес».

«МТТ Бизнес» имеет приватное API, которое позволяет партнерам МТТ реализовать аналогичные телеком-услуги с его помощью. Если при этом ориентироваться только на интерфейсы API, то можно заметить, что они не в полной мере отражают SID Framework. Он реализован внутри и составляет скрытое от пользователя API ядро. Такой выбор был намеренным — в самом API отражены конечные бизнес-процессы, а не абстракции.

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

Для наглядного представления того, как использованы эти бизнес-сущности и домены в «МТТ Бизнес», на диаграмме ниже отражены маркетинговые наименования услуги «Виртуальная АТС», которая является одной из ключевых в «МТТ Бизнес».

Что дальше?

Любой выбор предполагает последующую оценку эффектов, к которым он приводит. Формализовано или нет. Конечно, когда мы выбирали этот подход, мы не были уверены, эффективен ли он будет в дальнейшем развитии кода, систем, услуг и продукта. И предполагали, что потребуется формальный аудит и оценка, пусть, возможно, и внутренняя, для себя. Однако сама собой прошла «проверка жизнью». В процессе многочисленных доработок, внедрений новых услуг, реализации маркетинговых акций и пр. доработки кода во многих случаях были минимальными, что позволило реализовать больше идей бизнеса, чем это было возможно в услугах с проектированием архитектуры без оглядки на референтные информационные модели. Сейчас в планах реализовать этот подход к управлению данными на уровне всего предприятия для реализации стратегической цели по интеграции и созданию любого сервиса на платформе МТТ за 2 недели.

Референтные модели и технологии бизнес-инжиниринга
Кудрявцев Д.В. Технологии бизнес-инжиниринга: учеб. пособие / Д.В. Кудрявцев, М.Ю. Арзуманян, Л.Ю. Григорьев. — СПб.: Изд-во Политехн. ун-та, 2014. — 427с.

Источник

Референтная модель

руководитель проектов, Фирма «1С»

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

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

Существенно упростить и ускорить получение результатов, а, значит, сократить сроки и свое участие в проекте консультанту позволяет использование референтной модели.

Что такое референтная модель?

Референтная модель — концептуальная модель, формализующая рекомендованные практики ведения бизнеса в определенной области.

Отличительными признаками референтной модели являются:

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

Кому это нужно?

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

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

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

Здесь на помощь консультанту может прийти

Референтная процессная модель — модель, которая уже однажды была детализирована до операций и затем была свернута до уровня подпроцессов и блоков операций.

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

В случае наличия на предприятии процессных моделей «как есть», консультант может провести анализ различий существующей и референтной процессной модели, что позволяет:

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

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

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

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

В ходе обследования консультант должен найти ответы на ряд вопросов:

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

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

Избежать длительного процесса построения функциональной модели и последующего анализа и перепроектирования позволяет референтная функциональная модель.

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

Функциональная модель «как должно быть» будет отражать, в том числе, функции, которые должны быть автоматизированы.

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

Наличие на предприятии нескольких несвязанных систем автоматизации может привести:

Существует два варианта решения этой проблемы — замена существующих систем автоматизации комплексной системой планирования ресурсов предприятия (ERP-системой) и связывание существующих систем в единый программный комплекс с помощью интеграционного решения.

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

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

Стоит отметить еще одно применение точек интеграции — в них можно измерять параметры информации, переходящей из одной ИС в другую. Это может стать информационной основой для создания инструмента контроля, используемого менеджерами для управления предприятием.

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

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

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

В общем случае, референтная модель торгово-промышленного предприятия позволяет:

Таким образом, референтная модель служит не только рабочим инструментом консультанта на проектах внедрения таких видов инноваций, как комплексная автоматизация, но и инструментом поддержки принятия решений управленческим составом предприятия.

В конечном счете, результатом работы консультанта будут не просто отчеты и модели, а внедренное автоматизированное решение, за которым стоят реальные изменения в работе предприятия, обеспечивающие его конкурентными преимуществами.

Источник

Референтная модель бизнес-процесса

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

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

Проведение предпроектного обследования предприятий

Обследование предприятия является важным и определяющим этапом проектирования ИС. Длительность обследования обычно составляет 1-2 недели. В течение этого времени системный аналитик должен обследовать не более 2-3 видов деятельности (учет кадров, бухгалтерия, перевозки, маркетинг и др.).

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

К началу работ по обследованию организация обычно предоставляет комплект документов, в состав которого обычно входят:

1.Сводная информация о деятельности предприятия.

1.Информация об управленческой, финансово-экономической, производственной деятельности предприятия.

2.Сведения об учетной политике и отчетности.

2.Регулярный документооборот предприятия.

1.Реестр входящей информации.

2.Реестр внутренней информации.

3.Реестр исходящей информации.

3.Сведения об информационно–вычислительной инфраструктуре предприятия.

4.Сведения об ответственных лицах.

Таблица 5.1. РЕЕСТР ВХОДЯЩЕЙ ИНФОРМАЦИИ

Таблица 5.2. РЕЕСТР ВНУТРЕННЕЙ ИНФОРМАЦИИ

Таблица 5.3. РЕЕСТР ИСХОДЯЩЕЙ ИНФОРМАЦИИ

Списки вопросов для интервьюирования и анкетирования составляются по каждому обследуемому подразделению и утверждаются руководителем компании. Это делается с целью:

· предотвращения доступа к конфиденциальной информации;

· усиления целевой направленности обследования;

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

Общий перечень вопросов (с их последующей детализацией) включает следующие пункты:

· основные задачи подразделений;

· собираемая и регистрируемая информация;

· взаимодействие с другими подразделениями.

Анкеты для руководителей и специалистов могут содержать следующие вопросы:

· Каковы (с позиций вашего подразделения) должны быть цели создания интегрированной системы управления предприятием?

· Организационная структура подразделения.

· Последовательность действий при выполнении задач.

· С какими типами внешних организаций (банк, заказчик, поставщик и т.п.) взаимодействует подразделение и какой информацией обменивается?

· Каким справочным материалом вы пользуетесь?

· Сколько времени (в минутах) вы тратите на исполнение основных операций? На какие даты приходятся «пиковые нагрузки»? (периодичность в месяц, квартал, год и т.д.) Техническое оснащение подразделения (компьютеры, сеть, модем и т.п.). Используемые программные продукты для автоматизации бизнес-процессов.

· Какие отчеты и как часто вы готовите для руководства? Ключевые специалисты подразделения, способные ответить на любые вопросы по бизнес-процессам, применяемым в подразделении.

· Характеристики удаленных объектов управления.

· Документооборот на рабочем месте.

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

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

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

· классификация субъектов функционирования (категорий и групп работников);

· классификация элементов процесса функционирования (действий, процедур);

· классификация направлений (решаемых проблем), целей функционирования;

· классификация элементов информационных потоков;

· проведение обследования деятельности персонала организации;

· исследование распределения (по времени и частоте) организационных характеристик: процедур, контактов персонала, направлений деятельности, элементов информационных потоков — по отдельности и в комбинациях друг с другом по категориям работников, видам процедур и их направлениям (согласно результатам и логике исследований);

· выявление реальной структуры функциональных, информационных, иерархических, временных, проблемных отношений между руководителями, сотрудниками и подразделениями;

· установление структуры распределения рабочего времени руководителей и персонала относительно функций, проблем и целей организации;

· выявление основных технологий функционирования организации (информационных процессов, включая и недокументированные), их целеполагания в сравнении с декларируемыми целями организации;

· выявление однородных по специфике деятельности, целевой ориентации и реальной подчиненности групп работников, формирование реальной модели организационной структуры и сравнение ее с декларируемой;

· определение причин рассогласования декларируемой и реальной структуры организационных отношений.

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

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

Часть показателей, те, что помечены звездочкой, заполняются в процессе обследования, остальные — после. Содержание записей следующее:

· агент (должность обследуемого работника);

· время, в течение которого выполнялась процедура;

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

· содержание (суть процедуры, которая должна быть классифицирована);

· информация (направление движения информации между агентом и контрагентом);

· инициатива (инициатор начала выполнения данной процедуры);

· контрагент (должность работника, который находится с обследуемым в контакте);

· отношение (отражающая субординацию агента и контрагента форма взаимодействия в данной процедуре);

· проблема (словесная характеристика решаемой проблемы).

Источник