then analyze the issue and isolate the cause of the problem. If the problem is caused by a module developed by the service provider, then the ticket is assigned to the team that developed the module to fix the issue. On the other hand (as in our example) if the problem is caused by a module developed by an external vendor, then the trouble ticket is assigned to the vendor trouble submission queue. When the vendor is notified about trouble in their product, based on the sup- port level offered, the vendor will work with the service provider to resolve the issue. Once the issue is fixed, the information is communicated to the service pro- vider. The service provider will update the status of the trouble ticket as closed in the ticket database. This activity will generate an event to the customer support desk, SO that they call up and inform the customer that the issue has been resolved. The customer can call the customer support desk not just to enquire the status of the trouble ticket but also to close the ticket if the issue was temporary or was caused due to some issue that the customer was able to fix as part of self-service. It is therefore important that all the processes that update the ticket status with the database, first queries the database and checks the status before making any updates. In addition to ticket status and problem description, the trouble ticket will also contain a history of activities performed to resolve the trouble ticket, dependencies on other trouble tickets that need to be resolved 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 