Keystrokes are evil. Every keystroke represents a potential root cause of poor data quality by spelling things wrongly, putting the right thing in the wrong place, putting the wrong thing in the right place and so on. Besides that every keystroke is a cost of work summing up with all the other keystrokes to gigantic amounts of work costs.
In master data management (MDM) you will be able to getting things right, and reduce working costs, by killing keystrokes wherever possible.
Killing keystrokes in Product Information Management (PIM)
I have seen my share of current business processes where product master data are reentered or copied and pasted from different sources extracted from one product master data container and, often via spreadsheets, captured into another product master data container.
This happens inside organizations and it happens in the ecosystem of business partners in supply chains encompassing manufactures, distributors and retailers.
As touched in the post Social PIM there might be light at the end of the tunnel by the rise of tools, services and platforms setting up collaboration possibilities for sharing product master data and thus avoiding those evil keystrokes.
Killing keystrokes in Party Master Data Management
With party master data there are good possibilities of exploiting external data from big reference data sources and thus avoiding the evil keystrokes. The post instant Data Quality at Work tells about how a large utility company have gained better data quality, and reduced working costs, by using the iDQ™ service in that way within customer on-boarding and other business processes related to customer master data maintenance.
The next big thing in this area will be the customer data integration (CDI) part of what I call Social MDM, where you may avoid the evil keystrokes by utilizing the keystrokes already made in social networks by who the master data is about.
Hi Henrik
Totally agree. Data having been keyed in once to any system in an enterprise, should never have to be re-keyed into any other system in that enterprise. The only proviso being that the initial system has adequate data validation on all input, otherwise it would be garbage in, garbage everywhere!
The main barrier to using information entered by others and which might relate to a Master Entity is the inability of most enterprises to identify the true unique identifiers of their Master Entities – contrary to popular belief this will never be a code!
In Social MDM the problem is further exacerbated by the fact that one entity can exist in the social ether under many different identities.
Getting enterprises to identify and model the true unique identifiers of Master Entities will be a major means of eliminating duplication and erroneous linking. The mistaken use of unique codes is the primary cause of duplication as unique identifiers is the primary cause of duplication in databases.
Regards
John
Concur. resolving the social identity is fundamental to be able and take advantage of the data out there.
It mainly relies on matching identifiers within semi-structured and unstructured data from many different sources to resolve the identity in a high degree of certainty.
I am not familiar with any vendor that is delivering such matching, de-duplication capabilities.
Thanks,
Ronen
[quote=”Henrik”] … where you may avoid the evil keystrokes by utilizing the keystrokes already made in social networks by who the master data is about. [/quote]
Thank you Henrik. I almost start crying when I read this. Long ago I had a start-up and I thought this would be a killer so we invested a lot on it. Maybe too much. Maybe it was too long ago. So we ran out of money. You can still find some information about our X-Fetch Unifier – Google: republica x-fetch cleansing. I still own the immaterial property rights and have the code though…maybe we should start again 🙂
Thanks for commenting John, Ronen, Jouko.
I believe that the key to embracing social identity is to access social networks in conjunction with traditional external reference data sources, which is on the roadmap for the iDQ project.
@Jouko, yep, it’s not always the first mover who gets the market spot. But may be good to try again.
Reblogged this on drndark.