As the level of maturity increases in the operators, they focus more on improving the quality of services they give. As I explained in my previous posts, SQM (or sometimes call BSM-Business Service Management) is the key to measure the quality of the overall service. In SQM, we model the service and the service is composed of multiple service components. These components can be HLR, Charging, Core Network, Packet Network, Applications, Databases etc. and each of them is managed by a functional unit in the organization.
In an SQM”less” scenario, from the top-down approach, when a service problem is identified on the very top level, it is questioned the source of the problem. Identifying the root source of the problem may be time consuming. (The departments will most probably blame each other). SQM can pinpoint the source and take necessary actions that increases the effectiveness. But who runs the SQM?
According to eTOM, SQM belongs to the Service Management & Operations functional grouping, so in best practice, it is advisable to assign a department for this process. (eTOM does not mandate it should be separate. This could be a role that can be assigned to an existing department. But as we will see, it won’t be effective to consolidate functions)
A new term, Service Operation Centers arise with the introduction of service quality management concept. Service Operation Center or SOC is an organizational “department” that monitors the quality of the overall service and take the necessary actions in the case of service degradations and outages. The main data source for the SOC screens will be the SQM. The operators in the SOC will continuesly monitor SQM and coordinate with other departments to decrease the MTTR of the service outages.
A typical operator has a Network Operation Center or NOC inside it’s organization. This NOC, manages the NMS systems, monitors faults and events, track the performance of the network and troubleshoot the problems at the first hand. (L1 support). However, as the name implies, the main purpose of the NOC is to manage the network.
The network is only one part of the service. There are other components from IT. There may even some components from outside the organization such as content. NOC’s primary responsibility is to deal with those network specific complex problems. They should not communicate with the content provider to resolve a problem.
Because a network service provider’s main product is “network”, up to now, NOCs were sufficient to achieve overall assurance activities. But, as the services get more diverse and complex, SOC concept became much more logical.
As SOC deals with cross-functional teams, they should be sponsored by a upper level organizational entity to be effective. SOC should also have necessary interfaces to the other units (most likely the TT system) where strict OLAs are applied to. The people in SOC should include experts with skills in networking, IT and other necessary topics to streamline the troubleshooting activities.
Hi, Murat,
The SOC is an interesting topic. I wonder the relationship between SOC and NOC, if the operator has to build SOC which is parallel to the existed NOC?
A network problem may bring both the KPI and KQI descent, for instance, an increase of call drop caused by RF problem may result in the voice service quality down. In this case, will both SOC and NOC generate tickets?
Wish your answer, thanks a lot
Hi,
Yes, both NOC and SOC will generate tickets but it different contexts. SOC ticket will say that the service is down due to a resource problem,but the NOC ticket will have a more detailed resource view. NOC and SOC tickets should be different mechanisms. The SOC will open a ticket to NOC. The NOC uses another ticketing mechanism to track the internal troubleshooting steps. After the NOC solves the problem, they close their ticket and solve the SOC ticket. The SOC checks the service status and if it is ok closes the SOC ticket as well.
Hope this helps,
Regards,
Murat