Service quality management is becoming more popular day after day. The reason behind this is the data boom in the mobile communications area.
Service providers are aware that they need to move to service management in order to take control of the quality of their services, at least from the service provider perspective.
After the need is realized, they try to project the scope of such a service management migration. Are our data sources ready? Do we need to pay extra licenses to the OSS vendors? How should we set-up new business processes or change the existing ones? etc.
As you can see, the operator should handle both technical and business aspects of the migration. On the technical side, operators typically prefer to run some assessments with software vendors in order to understand their technical readiness for the SQM.
We are seeing 2 approaches in such assessments which OSS vendors follow.
1-) Top down
2-) Bottom up
Bottom up approach, focuses on collecting as much information as possible. In this approach, vendors look at all the data sources that are available in the resource domain. These include FM, PM and the elements themselves. Then they ask the customer which of these KPI/KQIs are needed by him. Since the customer generally knows very little about the concept at this stage, he asks for all of them. And the scope gets bigger and bigger. After some point, when it is the time to bind these KPI’s and KQI’s to the service itself, we come up with lots of unnecessary details. At this stage, the vendor/customer returns back to square one to re-evaluate the needs.
Top down approach tries to get rid of this situation. It first asks the business need. Why I am moving to SQM? Which services I am going to manage under the SQM process? What should be the least granular service tree that can reflect my operational status? Are there any off-the-shelf products around to guide me in formulating details like modelling?
Staring with questions like these, helps the customer to focus what he needs, nothing more. The outcome would be shorter implementation periods, reduced risk and more importantly a successful SQM project.