Учебные пособия / Усков М.В., Гольдштейн А.Б., Кисляков С.В. Программирование систем управления ИКС (черновик)

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

Для определения процессов, управляемых и контролируемых BPMсистемой, используют различные языки описаний бизнес-процессов. Наиболее широко известны и используются средства нотации BPEL, BPMN.

BPEL (Business Process Execution Language) — язык на осно-

ве XML для формального описания бизнес-процессов и протоколов их взаимодействия между собой [34] . BPEL расширяет модель взаимодействия веб-служб и включает в эту модель поддержку транзакций. Чаще всего используется для описания процессов, происходящих без участия людей (описание процессов взаимодействия с оборудованием, либо так наз. «сквозная автоматизация»).

На рисунке 17 показано, как BPEL-последовательность mathProcess принимает переменную $numIn, возводит её в квадрат и возвращает результат в переменной $numOut [35].

Рисунок 17. Фрагмент описания процесса с помощью BPEL

BPMN (Business Process Model and Notation) — система условных обозначений для моделирования бизнес-процессов. Последняя версия BPMN — 2.0, предыдущая версия — 1.2.

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

31

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

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

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

Одним из таких шаблонных решений является jBPM.

jBPM (Java Business Process Model) - кросс-платформенная система управления бизнес-процессами, которая имеет открытый исходный код, выпускается под лицензией LGPL, предоставляет фреймворк и инструменты разработчика для создания собственных процессов любой сложности

[36].

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

Каждое исполнение определения процесса называется "процесс экземпляра". jBPM управляет этими процессами. Некоторые процессы являются автоматическими, такие как отправка электронной почты или вызов службы. Другие выполняются из состояния ожидания. jBPM управляет и сохраняет данные по процессам все время. Описание процессов выполняется с помощью языка BPEL либо специализированного языка описания процессов jPDL.

Для jBPM существует workflow окружение RunaWFE, содержащее компоненты для работы конечного пользователя: систему аутентификации и авторизации, оповещатель о поступивших заданиях, редактор бизнеспроцессов и т.д. Система RunaWFE внесена в Единый реестр российских программ для электронных вычислительных машин и баз данных по классу ПО "системы управления процессами организации".

32

Язык jPDL предназначен для разработчика-программиста и не может использоваться как средство общего назначения (в отличие, например, от BPMN). Описание процесса сохраняется в формате XML в файл processdefinition.xml. Наиболее важное, что в нём хранится - это граф бизнес-процесса. Его можно редактировать напрямую (любым текстовым редактором, подходящим для файлов формата .xml) или с помощью какого-либо визуального редактора (например, редактор GPD входящий в состав пакета RunaWFE). Также файл processdefinition.xml содержит информацию о действиях (actions) и задачах (tasks) Также описание может включать другую относящуюся к процессу инфомацию, например ссылки на классы и интерфейсные формы UI для работы с отдельными задачами и др.

3.3. Типовой бизнес-процесс организации предоставления услуги абоненту с помощью OSS

Процесс приема заявок – один из основных и наиболее часто повторяющихся в компании Оператора связи. Ежедневно Оператор принимает множество заявок от уже существующих и новых абонентов на подключение/отключение/изменение услуг связи.

На рис. 18 изображен наиболее простой процесс выполнения некоторых услуг (работ) по заявке абонента.

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

Оба процесса описаны с помощью средств jPDL.

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

33

Рисунок 18. Диаграмма и jPDL-описание процесса «Общие работы».

34

Рисунок 19. АО - процесс установки.

3.4. Типовой бизнес-процесс организации устранения неисправности с помощью OSS

КТП это система, предназначенная для автоматизации процессов устранения неисправностей на сети Оператора.

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

Система КТП состоит из трех подсистем:

Подсистема Service Desk;

Подсистема Техническая Поддержка NGN;

Подсистема ЦБР (Централизованное Бюро Ремонта). Подсистема Service Desk выполняет все абстрактные функции, свя-

35

занные с приемом обращений абонентов. Предметную нагрузку этим функцям дают подсистемы ЦБР и ТП NGN.

ЦБР предназначена для обработки инцидентов, связанных с предоставлением услуг традиционной телефонии, в то время как ТП NGN занимается обработкой инцидентов на мультисервисных IP/NGN сетях.

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

Работа с абонентской карточкой

Тестирование услуг и ресурсов

Управление инцидентом

Управление процессом решения проблемы

Взаимодействие с системой Inventory

Управление персоналом

Редактирование пакетов услуг

Справочно-информационная система

Настройка и выполнение бизнес-логики системы (BPM) Система КТП структурирует техническую поддержку Оператора в ви-

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

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

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

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

36

непосредственно от самого оборудования или от систем мониторинга, и зафиксирована в системе как инцидент.

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

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

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

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

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

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

37

Рисунок 20. Простой случай процесса обработки инцидента (заявка о неисправности от абонента телеком-оператора SMB-сегмента)

Рисунок 21. Диаграмма сложного бизнес-процесса крупного телекоммуникационного оператора.

3.5. Элементы геоинформационных систем (ГИС) в составе

OSS

ГИС, геоинформационная система – в общем случае это система сбора, хранения, анализа и графической визуализации пространственных (географических) данных и связанной с ними информации о необходимых объектах [37].

38

В составе OSS, для модуля Network Resource Inventory (технического учёта) есть непосредственная необходимость наличия функций ГИС применительно к телекоммуникационному оборудованию, размещаемому на местности.

Обычно ГИС в составе NRI отображает геоинформацию о регионе (картографическую подложку), совмещенную с данными о линейнотехнических объектах в виде интерактивного плана города.

Слои ЛТО накладываются поверх слоёв картографической подложки (кварталы городской застройки, зелёные насаждения и др.) и отображают расположение объектов на местности, а также связи между ними.

Настольная ГИС, как самостоятельный программный продукт, обладает функциональностью реляционной СУБД и позволяет оперировать произвольной структурой хранения информации об отображаемых объектах. При использовании отдельных ГИС-компонентов для построения OSS, нет необходимости создавать структуру таблиц для слоёв: данные уже сохранены в собственной структуре БД OSS. Поэтому для работы функций ГИС необходимо задать соответствие между объектами, отображаемыми в ГИС, и их данными, сохранёнными в БД OSS, после чего «перенацелить» ГИС на работу с подключенными данными.

При работе с пространственными данными, используемая для хранения данных СУБД должна поддерживать расширение языка SQL для составления пространственных запросов, а также поддержку специализированных пространственных индексов (чаще всего используются индексы на основе R-деревьев [38] [39],см. рисунок 22). Также, при работе в ГИС часто используются специализированные встроенные языки программирования для выполнения операций над географическими объектами и для настройки внешнего вида отображения карты.

39

Рисунок 22. Простой пример R-дерева

Среди широко распространённых ГИС, работающих с векторными электронными картами, можно выделить семейства продуктов ArcGis (ESRI) [40] и MapInfo (Pitney Bowes) [41]. Каждое из них имеет как само-

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

роко известны Oracle Spatial, MS SQL Spatial, PostGIS для PostgreSQL и

др.)

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

40