Hi all,
I am trying to create a new KEDB Ticket system. Can you provide me with some categories that I should include.
Error Summary:
Status:
Linked Incidents:
Linked Problems:
Workaround:
Root Cause:
Change Req Ref:
Target Resolution Date:
KEDB Ticket - categories
Fulhamn
Here ya go
Categories:
Fruit: Banana, Cherry, Date, Guava
Vegetable: Tomato, Lettuce, Celery
Meat: Chicken, Beef, Turkey
Fish: Cod, Halibut, Salmon
Here ya go
Categories:
Fruit: Banana, Cherry, Date, Guava
Vegetable: Tomato, Lettuce, Celery
Meat: Chicken, Beef, Turkey
Fish: Cod, Halibut, Salmon
John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
What is a "KEDB ticket system"? and What is it for?
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
William Penn 1644-1718
I am creating a SharePoint page to store Known error's. This will have text boxes and drop down menus. I want to know what categories I should include. I want to get an idea of how other people store known errors and how they categories them.Diarmid wrote:What is a "KEDB ticket system"? and What is it for?
fulhamn
No comment as to the useful or useless ness of the categories I presented in my first answer ?
Only you and the environment you are setting it up for can be used to define the categories for the KEDB
Note: if you are not all of the following - Incident mgr, Problem mgr, release mgr, change mgr and configuration mgr, I recommend asking them for guidance
In addition, the services that are managed via the IM process would most likely give you an idea - as would the classification system in the ticket system.....
Of course, you could use my sugegestions
No comment as to the useful or useless ness of the categories I presented in my first answer ?
Only you and the environment you are setting it up for can be used to define the categories for the KEDB
Note: if you are not all of the following - Incident mgr, Problem mgr, release mgr, change mgr and configuration mgr, I recommend asking them for guidance
In addition, the services that are managed via the IM process would most likely give you an idea - as would the classification system in the ticket system.....
Of course, you could use my sugegestions
John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Knowledge capture is a very big challenge to company or organization.
Don't make it too formal, try to use OneNote to document whatever people want to document with free style.
Also if you want to create a KEDB, you should also get ready about how you're going to train people in your organization and how to ensure training or knowledge sharing is well communicated, acquired and assessed.
Otherwise, suggest you not to create any KEDB, it's a waste of time.
Don't make it too formal, try to use OneNote to document whatever people want to document with free style.
Also if you want to create a KEDB, you should also get ready about how you're going to train people in your organization and how to ensure training or knowledge sharing is well communicated, acquired and assessed.
Otherwise, suggest you not to create any KEDB, it's a waste of time.
Luo, Tian-Hong (Ken)
Regional Operation Lead
ITIL Expert Certified
Regional Operation Lead
ITIL Expert Certified
It really depends on what you want to achieve - it can be as light or as heavy as you want.
Some fields you might want to consider - pick and choose as you feel fit...
Word of warning - think carefully about how many you make mandatory before you annoy your Problem Analysts!
Known Error Phase
Known Error Status (Open, Deferred, Closed, Awaiting Change, Risk Accepted, etc)
Known Error Title (Short summary)
Known Error Description (more details of the Known Error/Risk)
Known Error ID
Known Error Impact
Possible Impacted Data Centres
Impacted Services
Assignment Group (which group does your Problem Analyst reside in)
Problem Analyst
Affected CI Name
Accountable Application/Infrastructure
Business Unit Responsible person
Known Error Categorisation (Trigger, Root Cause, etc)
Known Error Sub-Categorization (finer details)
Known Error Closure Code
Known Error Closure Details
Next Review Date
Incident Recurrence Threshold
Permanent Fix Determined (Y/N)
Will Permanent Fix Be Deployed
Estimated Fix Date
Incident Count
Expected Incident Serverity on recurrence
Business Critical Outage Threat
Approximate Cost To Fix (USD)
Workaround Information
Workaround Information Provided By
Permanent Fix Information
Permanent Fix Information Provided By
Some fields you might want to consider - pick and choose as you feel fit...
Word of warning - think carefully about how many you make mandatory before you annoy your Problem Analysts!
Known Error Phase
Known Error Status (Open, Deferred, Closed, Awaiting Change, Risk Accepted, etc)
Known Error Title (Short summary)
Known Error Description (more details of the Known Error/Risk)
Known Error ID
Known Error Impact
Possible Impacted Data Centres
Impacted Services
Assignment Group (which group does your Problem Analyst reside in)
Problem Analyst
Affected CI Name
Accountable Application/Infrastructure
Business Unit Responsible person
Known Error Categorisation (Trigger, Root Cause, etc)
Known Error Sub-Categorization (finer details)
Known Error Closure Code
Known Error Closure Details
Next Review Date
Incident Recurrence Threshold
Permanent Fix Determined (Y/N)
Will Permanent Fix Be Deployed
Estimated Fix Date
Incident Count
Expected Incident Serverity on recurrence
Business Critical Outage Threat
Approximate Cost To Fix (USD)
Workaround Information
Workaround Information Provided By
Permanent Fix Information
Permanent Fix Information Provided By