Introduction: why shared services must speak ‘the language of business’
One of the challenges for shared services functions is generating interest in the value of data across the business.
To try and fix this, it’s important for shared services to ‘speak the language’ of the business, while effectively communicating the importance of data governance. Unfortunately, it’s often the case that business users only take an interest in data when something has gone wrong.
But this can be avoided and the benefits of doing so help cement support for the data project.
Step one is an audit and mapping exercise. This means evaluating fundamental data flows and determining how these relate to business use and stakeholders.
Next, and only after this stage, these findings should be translated into the necessary business conversations, using terminology that’s both relevant to and exciting for your internal customers.
Connecting data flow to business use
Business users typically deal with business processes, rules, requirements, metrics, reports and so on.
If shared services can show how these aspects rely on having the highest-quality supplier data, then you initiate business-relevant conversations about it.
We recommend considering the following steps:
- Create a register of all the systems which rely on supplier data. Normally these are transactional systems for finance, procurement, compliance and legal. As such, this will include ERP, S2P / P2P, health and safety, quality and contract management tools.
- Next, map out the different functions and the respective stakeholders which interact with the systems.
- Finally, map these systems into the overarching data management processes, documenting clearly how data is created, viewed, updated or deleted in each one. Ideally those activities should be centralised away from those systems, but in many cases, you don’t want to replace all those systems.
With this information you can define future processes for data management, but in a business context.
In terms of supplier information management, there are four main processes which you need to define:
- Create or Extend Supplier (Supplier Onboarding) – the process of how an organisation commences a new business relationship with a supplier
- Update Supplier Management –the process of making changes to an existing record
- Deactivate (Phase Out) Supplier – more commonly referred to as Supplier Offboarding. It commences from the point a user makes a request to deactivate a supplier, the subsequent approval and updates to block it in the relevant ERP / P2P systems
- Reactivate Supplier – let’s say you have a supplier you have not worked with for the last three years and you want to use them again. Would you just turn them on for use? Probably not because a lot will have changed in that time. In most cases the reactivation process is very similar to initial supplier onboarding
All of these processes will have varying degrees of applicability based on factors such as the type of supplier, location, services / goods, risk level and so on, and will engage different stakeholders.
Armed with this information, it’s possible to define what conversations need to take place and with which stakeholders.
Starting business-relevant conversations
Many large organisations have specialised shared services functions that group together skills and knowledge. Separating functions and duties also ensures that there is separation between those operating the business and those controlling it.
But as you’ll be aware, by their very nature, these silos make collaboration across the business and with different internal partners more difficult. Each separate area has its own focus and even terminology, making the act of building a shared understanding difficult.
Data integration projects are often approached as technical exercises. However, the key to bridging silos and creating a lean data landscape is for everyone in the organisation to understand how data is used. Unless you connect information flow to its business usage, data will remain siloed.
As such, it’s vital that you engage with all stakeholders and emphasise that this is an enterprise-wide project designed to connect data creators with data users. Effective master data governance is more than just a project for shared services or IT – it’s about enabling overall business transformation.
The first step to having meaningful conversations with business users and internal partners about data is to not frame them as data conversations.
Translate technical terms into business language
You may be familiar with the standard data-related processes that are referred to as CRUD operations, namely create, read, update and delete. However, you shouldn’t assume that everyone is. Speaking to other business users in this way is unlikely to get the kind of response you want, and as such you’ll be unable to get the buy-in you need from internal partners.
Instead, translate these terms into what they mean in a real business context. For example, in the case of supplier management, this would be:
- Create = supplier onboarding
- Read = reporting / analysis
- Update = supplier management
- Delete = phasing out a supplier
These are all important processes that involve different stakeholders. By linking fundamental data processes to real business processes, shared services can clearly communicate the value of having great data and how it leads to greater efficiency and transparency.
Transparent processes and stakeholder engagement
The important take away is that business users and internal customers should be involved as part of how data changes when the data quality is important to them. The one who cares about (uses) the data should be involved in the process. For example:
- Finance – will be interested about bank account data and changes
- Procurement – a category manager is trying to drive volumes to specific suppliers so they want to review all new onboards for their category
- Quality – if a manufacturing location changes this is normally not desirable, so they should be aware so that they can take appropriate action
Problems are always more cost effective to resolve at the point of entry / change than fixing them in the future. The later you try to correct the data, the more expensive and inefficient it is.
The ultimate objective for shared business services functions is to put processes in place that make the sharing of supplier data and information governance straightforward, efficient and transparent.
Communicating the value of data for procurement transformation
Data governance isn’t about a single person, or group, taking sole responsibility for data management and quality, but rather about collaboration and everyone playing a part. The answer is to clearly explain to your stakeholders that you will be sharing efforts.
The problem is that most people want to distance themselves from data as it’s perceived as low-value or admin work. However, if you’re thinking about solving your data challenges by isolating them in a data function, shared services or IT to ‘protect’ your internal partners, then think again. All you are doing is creating another type of data silo.
Supplier master data management implies the idea of ‘centralisation’ – managing everything centrally. While everyone puts in some effort, what you get out of it makes the effort worthwhile.
The benefit of thinking in terms of broad (and collaborative) business processes is that you can embed this mindset in your organisation and your internal customers. As part of a data governance initiative, the business community needs to take ownership of its data and see it as something that is high, rather than low, value work.
Encouraging business users to take ownership and stay engaged on the basis of a shared understanding is not only more productive, it also lets them make far more informed and responsible decisions that have a greater impact. Your business is data, but remember that your data is about the business.
If you found this article informative, you may also want to take a look at our other resources on our blog here.