KEDB Ticket - categories

[fulhamn]

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:

[UKVIKING]

Fulhamn

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

[Diarmid]

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

[fulhamn]

[fulhamn]

[UKVIKING]

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
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[KenLuo]

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.
_________________
Luo, Tian-Hong (Ken)
Regional Operation Lead

ITIL Expert Certified

[bkupexec]

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