Incident logging is a somewhat straightforward activity. However, it is important to note that no matter how simple it may sound, organizations tend to go wrong in its implementation. In the third set of the incident management lifecycle series, I will talk briefly about the incident logging activity. To fully touch base
In the second set in the incident management lifecycle series, we look at the very basic distinction that distinguishes incident from a service request. Often, most organizations confuse (some on purpose) incidents with service requests, and both are handled with the same rigor. This keeps things simple, but in hindsight, it
Most ITSM consultants prefer to start off the blocks with the design and implementation of the incident management process. Also, by hanging onto the low hanging fruits in the form of incident management process development and implementation, you can certainly prove your authority in the ITIL area to the customer. I
Process development and implementation is a skill that is best learnt through experience and maturity. Organizations implementing ITIL processes normally develop workflows, define activities, identify roles and embed all of it in a process document. This is good, but there is a major chunk that is still missing. The design.
Automation is the path forward in the workspace. People are expensive and often unreliable. But, there are a number of activities, which involves wisdom, circumspection, and thought-flow that calls out for human brains rather than machine trained deliveries. You can create significant value in IT service management through automation. A number
A major part of the incident apart from diagnosing and resolving incident revolves around the communication activities between various parties. For starters, when an incident is notified, the service desk needs to notify the support teams. If the organization has scope for an incident manager to play a part, then