To some use of the word 'data' signals the beginning of one of the most boring, technically esoteric and generally useless topics of discussion they can imagine. Data model, data dictionary, data schema, data cleansing, data coding & classification.... or just plain old data.
HELP! How much boredom and technophobia can one person be expected to cope with! Can't those sad techie's keep all that gobbledy-gook stuff to themselves and just talk to the rest of us about normal business things?
Oh dear, a response common to many technophobes we know. We even have some sympathy for this perspective. However, we also know from hard experience that the technophobes are dead wrong to place this conversation on one of the lower rungs of technical hell.
Unfortunately, although we'd never claim the topic was scintillating to most listeners, we know how fundamentally important good data is to modern organisations. It is not too much of an exaggeration to say that without it they are lost with little hope of rescue!
You see, business processes, functions, workflows, metrics, org charts, etc, etc change quite regularly... sometimes at the whim of a passing management fad. Where-as base data on the other hand generally changes relatively little on the whole... while underpinning all the rest of the faster changing artefacts that rest on top of it.
To understand this, while trying to avoid the more technical aspects, it is useful to think of (business) data as being split into three camps: meta data, static data and dynamic data.
Meta data is simply data about data. This camp covers such things as should data be ten digits long or fifteen digits long. Should it be numeric or alpha-numeric. Should it use an existing classification system (e.g. NATO schema) to group and relate items or one you invent for yourself. These basic decisions underpin every data structure (e.g. database) ever devised and are essential to being able to speak a common data 'language' that uses consistent definitions and formats.
A very common business example of meta data is the structuring of an organisation's financial chart of accounts... i.e. what locations and functions, what departmental / budget codes, what time periods, what currency, what consolidation roll-up, what accounting standards, etc.
Look more widely and you will also see that the concept of an invoice, an order, a requisition, a product, a part and many, many other familiar business artefacts are also meta data entities. That is, an object or item with an understood set of data attributes and rules that define and specify it and its relationship to other data entities. In fact, a map of such things is known as an entity relationship diagram or data schema!
Once the basic data entity building blocks are defined, for both operational and maintenance purposes, they are often then divided into two further camps... static data and dynamic data.
Static data, as the name implies is data that either does not change, or more typically, changes relatively infrequently. Into this camp we can place data items such as products, customers, suppliers, BOMs, routings, etc. It is not that these data items never change, but that once created they commonly change little and infrequently... for some organisations, sometimes verging on never... which can be a problem in and of itself!
Finally, we have the camp of dynamic data. As this name implies this is data that changes fairly frequently. Into this camp we can place data items such as quotes, orders, requisitions, GRNs, invoices, etc. These items by definition change regularly as part of the normal cycle and rhythm of conducting business.
However, lets now circle back to our original point... that base data changes relatively little on the whole. How does this reconcile with the idea of dynamic data which changes regularly for instance? Well, as for most things, the distinction is in the definition and the use of the qualifier 'base' in base data.
The point is that while dynamic data changes regularly (e.g. new invoice number, new requisition number, etc) and static data from time-to-time (e.g. new supplier, existing supplier address with a new address, etc) the meta data that defines those entities (e.g. the fact that there is an invoice number or address field) almost NEVER changes!
When is the last time for instance that you can remember a basic data concept like that of an invoice being introduced for the first time?
Hence our use of the phrase 'on the whole' when describing the low change rate of base data. It also explains our desire to illuminate the distinction between the data camps as we did to explain things a bit more clearly and accurately.
With your new understanding of these three data camps... keeping in mind that these definitions have a wide general applicability, but if you went outside the realms of business (e.g. scientific research), you would find far more data camps in use than just these... you should be beginning to see how fundamental data is to everything built on top of it.
And for common business concepts like P&L, ROI, management reporting, project status, etc... that is almost EVERYTHING!!
Now perhaps it is becoming fully clear why an apparently boring and technically esoteric topic like data is actually of PARAMOUNT importance to any business!
After money, it is arguably the lifeblood of any organisation in terms of understanding and deciding where it is, where it needs to go and how well it is progressing on that journey. Without good quality data a business is quite literally lost... even more dangerously so if it actually believes it knows where it is (i.e. based on access to 'bad' data) but in fact does not...
This observation leads the conversation nicely to a few additional important facts about data. Namely, once you have some data, you also need to ensure that it is as:
- Accurate - plus or minus how much?
- Precise - to how many decimal places?
- Timely - when am I going to be able to get this?
- Available - How will I be able to access it?
as it needs to be (i.e. as opposed to as much as it 'theoretically' could be) to fill your legitimate business needs. There are many approaches to accomplishing this list of requirements, e.g.:
- use of mobile technologies (e.g. handheld devices, laptops, etc)
- use of automated technologies (e.g. bar coding, RFID, etc)
- use of rigorous routines (e.g. perpetual inventory / cycle counting, stock counts, trial balances, month-end closes, etc)
and many others too numerous to quantify here, but the message is the same.
If something is important to the organisation then the relevant data relating to it also needs to be defined, instantiated, collected, collated, accurate, precise, timely and available to a level of quality matched to the importance placed on it by the organisation!
The number of times we have seen managers puzzling over 'mysterious' business project failures... especially in the context of large, multi-site, multi-function transformational change programmes... is nothing short of astounding. Failures in which they resolutely believe they broadly got (and perhaps did get) the strategy, processes, metrics, people, systems and other dimensions of change right, but still fell short somehow.
Although not on every occasion of course, but with frightening regularity all the same, one of the most obviously missing considerations in our experience has been a good understanding of the quality of the underlying legacy data landscape.
Had they (i.e. management, not the 'techies' who often do understand but whose views are often not sought or are 'unwelcome') deigned to look, it being a low-level techie subject and all, they might have actually seen (shock horror) that the data landscape was not fit for purpose.
They might have even found that it never had been and was thus never going to be capable of supporting the level of integration of processes, metrics, systems, reporting, etc that everyone had been working towards!
Unfortunately, given its lowly 'techie' status, looking at the data landscape is not a high priority on many a corporate transformational change programme agenda.
And although data is often not the only issue needing attention... it is one of the most commonly overlooked, and thus one of the most inscrutably responsible culprits for the failure to achieve the expected results!
