Knowledge, Processes and Masterdata

For an organisation to operate, having the correct IT strategy is critical to the operational efficiency of doing business as usual. However, unless you start to pull out your key performance indicators (KPIs) from your systems, it is hard to know what business as usual actually is. Without that benchmark, you have little understanding of the underlying trends that affect your key tangible metrics such sales volumes, hours worked or cost of sales.

Some of your KPIs will be obvious, some a mixture of combined data from multiple sources and others more subjective such as customer satisfaction.

The most important thing to remember is how you join the dots between your disparate data sources. In an ideal world, you would create your initial masterdata in the first system that an entity is created in. Then when that entity is referenced in other systems, that data has been received from the primary masterdata system and therefore everything remains synchronised. This could be via an API or batch imports.

The other thing to remember about your masterdata is that during the life of an entity that you are recording, the primary system recording that data may change over time. This is an integral part of your business process to map the path that data follows through your systems. The key thing is to have a unique ID that passes through the systems for you to be able to link that data together to analyse it.

An example:

A job applicant applies on your website and this is the initial contact and data creation. A unique ID is created and that passes on through the subsequent systems as it transfers. This applicant data then moves into the recruitment system for processing and this system is now the masterdata owner.

When the recruitment process successfully completes, the applicant becomes an employee and then the data moves again. At this point it will move into both the operational systems which will handle deployment and the HR system which will record personal data. When this transition occurs from applicant to employee, the masterdata moves from a sequential ownership to potentially a shared ownership.

It could be that both systems own parts of the masterdata for that employee, however one system should ultimately own the core record. If the employee gets married and changes their surname and status etc, ideally this change is entered into only one system and then feeds the other related systems automatically.

So why is this unique ID and conformity important? It is the part that lets you join your data together and view it throughout the life of your systems. It could be employees, it could be locations or contracts, or all of them linked together so you can fully understand how each element works and impacts on other elements.

Getting data from your systems will probably fall into one the following categories:

- Adhoc real-time queries on the system.

- Monthly or period reports that probably feed your management accounts.

- Other standard reports used in regular management functions.

- KPIs and dashboards that summarise data and use a RAG rating.

- Exception alerts if something has triggered within the system.

- Adhoc reporting using business intelligence tools or the good old spreadsheet.

Working with our customers, we help to identify with you what your needs are and how you then make it happen. It could be enhancing the systems you already have through to building a data warehouse. The key thing is to get access to your data so you can do more of the good stuff and less of the bad!

If you think we can help, please contact us to discuss your requirements.