Resource Specification Management::Resource Trouble Policy Management

Resource Trouble Policy Management Aggregate Function allows to manage the resource problem typology, actions and rules describing:<br/>• all the types of known troubles related to resource type  <br/>• the actions and rules of triggering, of linking and of results analysis that define the strategies for identifying  <br/>   - the trouble associated to a – or a set of - resource trouble ticket(s)<br/>   - the cause(s) of this trouble and the actions to do to resolve the resource trouble. <br/><br/>The definition of the trouble (with specification and rules) is very important because it defines the sequence logic of the actions to be realized to identify and qualify the problem, one or several associated causes , and to identify the best solution to solve the problem. Specifications and rules may take into account characteristics like urgency level, impact level, priority level of the resource trouble ticket.<br/><br/>The different action types are:<br/>• Diagnostic actions and rules to identify the resource trouble. This step permits to identify the installed resource(s) at fault<br/>   - For example: simple resource test or resource test scenario, inventories consultation to identify installed resource and expected configuration characteristics, test historic consultation, …<br/>• Diagnostic actions  and rules to identify the resource trouble cause(s) and the possible root cause . This step permits to identify why the related installed resource(s) is (are) at fault.<br/>   - For example: Plan workforce intervention to check an equipment, launch resource test scenario, query QoS historic, followed by resource test launch if the installed resource has a decreasing QoS, query resource usage historic, equipment logs, anomaly historic, ….<br/>• Definition of the logic of interpretation of the results of these diagnostic actions, to identify resolution actions. These resolution actions can be temporary or palliative, to quickly stop the trouble, and followed by other actions which will definitely treat the trouble cause <br/>   - For example: if a network cable is cut, we can first decide to migrate all or part of the interrupted installed services on another cable (through dedicated resource orders) to quickly solve the trouble, and secondly initiate a project – often called scheduled work - to repair the cut cable. After the final repair, it’s not always necessary to migrate the installed service back.<br/>• Definition of notification action, depending on the trouble or the trouble cause identified, for example display a message on the web site, or broadcast a vocal message on IVR in case of collective trouble (example: network cable cut, power cut, …) <br/>• Definition of lead action, mainly the need or not to initialize Service Trouble Tickets for all the installed services concerned by the resource trouble.<br/><br/>These different actions will be authorized – or not – depending on actor’s role and associated rights. <br/>For example we could authorized the customer (or user) to directly diagnose a configuration problem on his box and to trigger the upload of a new software version, but reserve the capacity of updating the configuration of a service platform to support level 2 actors.<br/><br/>It is also possible to define rules to manage Resource Trouble Tickets and Resource Trouble priorities, depending on criteria such as:<br/>• Priority of the related Service Trouble Ticket(s) or Service Trouble(s) <br/>• Number of Product Trouble Tickets that can be expected, linked to the usage of the installed resource.<br/>