For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone
Note: ® ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.
The Itil Community Forum: Forums
ITIL :: View topic - Customer name as a information in KEDB
Joined: Mar 16, 2006 Posts: 12 Location: Rennes, Brittany, Fr
Posted: Mon Dec 24, 2007 11:50 pm Post subject: Customer name as a information in KEDB
Hello,
we sell and support IT platforms to several customers. Each platform is a combination of IT softwares but the combination can be different from a customer to another.
The goal of KEDB is to help incident management to find an incident or a permanent solution. Each KEDB record contains a "technical context" field. This field is indexed by the tool in order to easier the search.
Some of the users want to add a "customer" field. To my point of view, problems do not occur on a customer specific platform but rather on a specific combination of software. The KEDB is (to my opinion) a way to go from a particular case to a more general one. So I would not agree to discriminate the KEs by customer.
Maybe this is not pragmatic. Have you got an opinion on this ?
Joined: Jan 03, 2007 Posts: 189 Location: Redmond, WA
Posted: Tue Dec 25, 2007 12:10 am Post subject: Re: Customer name as a information in KEDB
I would say that this could make sense if by "customer" the organization making this requesting means "operational area" or "business unit". In a large company with multiple lines of business, it might be important to segregate the data.
If an organization has a Sales unit, Manufacturing unit, R&D unit, then it would make sense to separate the knowledge into silos so people searching for an issue that only affects the Sales group doesn't have to wade through entries that are specific to the Manufacturing group. There would still need to be a group of knowledge that is common to all units, but setting up partitions that prevent getting hits on entries that aren't applicable to a specific customer base makes sense.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum