Hi Jigna,
I think that your use of "incident" may be different from what is used within ITIL and TMF. Maybe you can explain further if it doesn't match with the definition below.
For example, I reviewed the information posted by
@Jacob Avraham as the TMF621 owner on the difference between an incident and a problem on the
TMF API project:
-
- BMC reference:
- incident management: http://www.bmcsoftware.in/guides/itil-incident-management.html
- problem management: http://www.bmcsoftware.in/guides/itil-problem-management.html
- Incident Vs. Problem:
- http://www.conceptsolutionsbc.com/it-service-management-mainmenu-60/30-it-service-management/182-incident-and-problems-what-is-the-difference,
I personally liked the example provided by Concept Solution that an incident is a disruption of service that needs attention now; while a problem may occur, but no service is affected, and you may decide that the solution is too costly to implement and leave it as is.
Incident vs. Problem: What is the Difference?
To illustrate this further, let's take a practical example.
You are driving your car, and you got a flat tire. This is an incident because it disrupted the service: transportation to a destination. You fix this by either changing the tire yourself or calling roadside assistance. Once the tire has been changed, the incident is closed. But now, you have a problem; you are running on your spare tire.To fix the problem, you need to repair the flat tire and put it back.
Another example would be that you are driving on an almost bald tire. This is a problem. If you continue to drive your car with that bald tire, you are bound to have an incident.Normally, an incident needs to be fixed within a specific timeline. Problems can be left indefinitely until an incident happens.
From a NaaS domain perspective, you can report on both incidents/problems (as per their definition above) via the service problem management API. The TT system is listening to the create/update/status changes/delete. This is typically to let other systems know of service affecting issues so CSRs are aware (or info accessible from a customer portal via APIs) and can pass this on to the customer.
From a prediction of service degradation, there is a new white paper on performance management/assurance on most APIs used (SLA, PM, Threshold, alarms, SQM, etc) and their role waiting for approval before being published on confluence. Once it is released we plan on adding best practices in the
IG1224 NaaS Service Fulfillment project.
Hopefully, this helps with what you are trying to do.
------------------------------
Johanne Mayer
MayerConsult Inc
------------------------------
Original Message:
Sent: May 21, 2021 11:42
From: Jigna Srivastava
Subject: Service Problem Management
Hello All,
I was checking the Service problem management API and automating the service problem management in fault management domain of NaaS.
As per this process, the operational domain is concerned with performing the root cause analysis and correlations to pre-empt the service problems and identify the actual fault, location, related alarms and affected resources etc. After this should the related ticket to the TT system should be a problem ticket or an incidence ticket?
Also in cases where there is going to be prediction of service degradation, will that qualify for a problem ticket or an incidence ticket (621)?
More light on the use cases and corresponding APIs in these scenarios will be very helpful.
@Johanne Mayer
Warm Regards,
Jigna
------------------------------
Jigna Srivastava
LIGHTSTORM TELECOM CONNECTIVITY PRIVATE LIMITED
------------------------------