Глава 6. Примеры ИОБ-диаграмм процесса

Процессное взаимодействие

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

Для тех, кто заинтересован в более глубоком понимании менеджмента бизнес процессов "TOM Application Notes: Process Re-engineering, Development and ManagementЧSimple Methodology StepsФ - документ, выпущенный параллельно с TOM, содержит высокий уровень представления технологии "картографирования" бизнес процессов, которая является процессной технологией, позволяющей наиболее просто учесть точку зрения клиентов.

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

Описанные процессные потоки совместимы с процессами, описанными в разделе 5 настоящего документа, но не отражают все взаимодействия. Это потому, что они показывают примеры услуг или сегментов процессных приложений лишь с конкретными целями. Раздел 7 содержит описание жизненного цикла входов и выходов каждого их процессов, когда Рис. 6.1 - 6.3 объединяют в себе только частные примеры.  Эти диаграммы также используют более детализированные процессные потоки, описанные в Network Management Detailed Operations Map ) , которая поддерживает процессы менеджмента уровнями сети.

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

TeleManagement Forum использует объединенный потоковый подход как стандартный подход к построению диаграмм процессов. Он позволяет идентифицировать существенные и несущественные операции. Что наиболее важно, он дает сжатое представление внутренних сервисных процессов с точки зрения клиента в рамках TOM-структуры. По мере развития  TOM Application Notes эти примеры процессных потоков будут замещаться более подробными и ясными потоками процессов завершенного цикла, использующими методологию объединенного потока.

Пример  потока  процесса исполнения услуги

Процесс исполнения услуги начинается с операций, предшетвующих продаже, и заканчивается:

Рис. 6.1. Обобщенный пример исполнения типового процесса 

Пример  запроса распоряжения и инсталляции

This example of a fulfillment process shows a possible sequence of activities to support a customer inquiry, subsequent order for service, the configuration of the service, and the installation and completion of the request. Depending on the service provider process, orders can be placed through the sales process and/or directly through the order management process. For a specific service provider, some customers may be supported by a specific sales team that places some or all orders for the customer and tracks them to completion. These dual trigger process interfaces and follow-ups are shown as 3/3A and 20/20A.

For this representation, the Network Provisioning process has one of its sub-processes explicitly displayed: Network Configuration and Routing (Reference 2). The complete fulfillment flow-through may not actually be required every time for some simple services, which have pre-assigned service capacity. For example, the flow for an instance of a service set-up could be bypassed at Network Provisioning, when configured and tested facilities have been pre-provisioned. This depends upon a particular providerТs operational process and policy. It will also impact the timing of interactions with Network Inventory Management; hence, the interface sequence number has been omitted.

In other cases, more process activities may be required for a variety of reasons, e.g., due to the complexity of the service being offered, due to a new SLA requirement, etc. Interfaces to the customer are shown, as well as the output interfaces required to support Service Assurance and Billing processes, i.e., trouble/problem management, SLA management and billing. Interfaces are required with other service providers or network operators when the service offered to a customer involves joint service arrangements.

As mentioned in the diagram note, security is critical and applied at every interface. Security, like test management, may be a functional sub-process applied across the map or be managed as part of the specific process and handled as requirements for the process and system involved.

Сегмент потока сервисного процесса обеспечения

Процесс обеспечения исполнения услуги начинается с фиксации условий СУПУ специфическим клиентом и производящей обновления системами разрашения проблем для конкретной услуги и клиента, а заканчивается:

Рис. 6.2. Обобщенный пример фрагмента потока процесса поддержки

Обнаруженная сетью ошибка \ Пример качества сервисной проблемы

Figure 6.2 shows a possible sequence of activities in response to a network-detected problem. The problem could be non-service-affecting because of inherent Сself healingТ capabilities in the underlying network and information technology infrastructure (for example, SONET/SDH networks have some instant redirection capabilities). The service providerТs policy could be to decide on how to repair the problem at the network layer and, subject to Сno-break in serviceТ, may not even inform the service layer of the event.

The figure shows two ways a potential service-affecting problem could be identified, i.e., by either an Сalarm eventТ or by synthesis of network data, through Network Data Management. Neither is exclusive. Network Data Management collects and processes both performance and traffic data, as well as usage data. The usage data is used in the Billing Process.

Most service providers are driving their Service Assurance processes to become primarily proactive, meaning triggered by automation rather than triggered by the  customer. This is important for improving service quality, customer perception of service and for lowering costs.

Customer Care Processes have been reactive until recently. The extreme pressure to reduce cost, customer demand for more control and customer demand for more proactive, customer-enabled service support are driving a major shift to interactive

support through automation. With the advent of Internet access, interactive customer-enabled service includes giving the customer the ability to see and act on service performance or the performance of Сhis/her network.Т Superior companies are also recognizing the value of customer provided information at each customer interface point. They are capturing that information for use in other ways across the enterprise, e.g., to customize offers to customer needs, to relate to the customer in future interactions, etc.

If the service provided is a joint service type arrangement, the main service provider must interface with other service providers or network operators to monitor and support the service provided.

Пример процесса биллинговой услуги

Процесс обслуживания биллнига начинается с создания и обновления счетов клиента, фиксации СУПУ позиций для конкретного клиента, а заканчивается удовлетворением клиента и :

Рис. 6.3. Упрощенный пример потока биллингового процесса

Пример фиксированного платежа , требования к оплате и формирования СУПУ в отношении счета

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

Когда услуга реализуется несколькими разными провайдерами услуг, требования к оплате и\или другие данные биллинга могут агрегироваться "основным" провайдером услуги с выходов "вторичных" провайдеров услуг для предъявления клиенту единого счета. Это является тенденцией, которая находится в зависимости от биллинговой стратегии провайдера услуг, желаний клиента,  предлагаемого ряда услуг в целом и\или возможностей и политики провайдера услуг.