first, the person who is currently working on the ticket, and SO on. Now let us look into the flaws in this business process for trouble management. Though the explanation gives a clear idea of the flow, the process by itself does not give details of the entity responsible for a specific block. For example, it is not clear if analysis of the service problem is performed by the customer support desk as an initial activity or by the service support team. Another flaw is that several processes Fundamentals of EMS, NMS and OSS/BSS that could have improved productivity of trouble management like centralized tracking and managing that involves searching for similar trouble conditions is missing. Also the customer support desk does not always try and solve technical issues. The customer support desk isolates the issue and assigns it to the service support desk. A problem resolution at customer support could have save more than 70% of the cost the service provider will incur when the problem resolution hap- pens only at vendor support level. It is in these scenarios where standard models like eTOM will help. The cur- rent process needs to be aligned with eTOM using SANRR methodology. Here scope (the S in SANRR) is to align trouble management with eTOM. First of all, eTOM has a detailed process map for each area that helps to clearly identify what entity is responsible for what. For example there are four layers for trouble management in eTOM. At customer level (customer relationship management layer) there is problem handling, at service level (service management and oper- ations layer) there is service problem management, at resource level (resource management and operations layer) there is resource trouble management and at external vendor level (supplier/partner relationship management) there is sup- plier/partner problem reporting and management. There are multiple levels of process definition from Level 0 to level 3 with eTOM. The process effects can be improved by removing invalid processes and adding new processes