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 ?
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.