7.1.3. Выполнение. Обеспечение. Биллинг

Очевидно, что представленное разбиение процессов на три группы (рис. 7.1) не отражает динамику необходимых для поддержки сквоз­ных процессов выполнения, обеспечения и биллинга. Поэтому на рис. 7.2 изображены три основных направления динамики сквозных про­цессов, имеющих место:

• между абонентским интерфейсом и его поддержкой сетевыми эле­ментами;

• от продаж до выписки счета;

• с другими поставщиками услуг и операторами.

Рисунок 7.2.- Диаграммы сквозного процесса с учетом выполнения, обеспечения и биллинга

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

7.1.4. Трехмерная модель операций

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

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

Рисунок 7.3. - Трехмерный подход к соглашению по предоставлению услуг различного уровня

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

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