July 22, 2020

Current ‘technology stacks’ fuel tension between business and IT

Poor outcomes due to lack of autonomy

Current trends in enterprises have been focusing IT efforts on deploying solutions that ensure better quality data, while insisting on simplification and rationalization of systems. Meanwhile, business units, such as Procurement, have been deploying solutions that facilitate transactions.

This has led to countless sub-optimal configurations, based on highly recognizable set-ups. For example, you might see a single vendor tech stack approach involving the deployment of P2P solutions, such as Ariba to handle purchasing transactions, in combination with SAP MDG to provide governance for the integration with an ERP for invoice payment.

But even in the case of this simplest single vendor tech stack approach, activities such as supplier management remain difficult, while procurement is left without the autonomy to optimize workflows and processes relating to their function. The situation can cause friction between IT and business units and has led to poor outcomes, such as data that cannot be used to evaluate wider business questions or decisions. For example, in a recent HICX survey conducted with Raconteur, 88% of total respondents said that ownership of supplier data management was shared between Procurement and at least one other function – which in 85% of cases included IT.

The outcome: 89% of total respondents also confirmed that they do not have total oversight into their suppliers. This issue became particularly salient during the COVID-19 crisis, when many companies found that they did not have the supplier data they required to make the most rapid decisions.

This article investigates how the current configuration of systems has become the de facto standard, how the issues arise, and the negative impacts of this.

Utilizing existing available solutions in the tech stack

Let’s take an enterprise that has invested in SAP architecture as an example, and that is in need of a supplier portal in order to onboard suppliers. In terms of SAP architecture, we’ll assume that there is an SAP ERP in the environment and SAP Master Data Governance (MDG) as part of the Master Data Management (MDM) configuration.

In this case, SAP MDG is not domain specific and, although it will include screens for the vendor master, decisions would have to be made regarding how the data is handled – for example the internal approval process to verify supplier information. As SAP MDG is a competent data governance tool, internal approvers could log in to MDG to carry out this function. However, it would either be a poor user experience that would need back office support; or it would require building customized workflows as it is not a supplier portal. In either scenario, the drawback is not having a front end to enable the user. In this case, it would be preferable for IT to put forward SAP’s P2P solution, Ariba, as the logical front end.

Perhaps inevitably, organizations that have invested heavily in P2P solutions would like them to do more to help some of the underlying issues that procurement teams (and the business buyers they support) face. This means using SAP Ariba as the front end and having the P2P system become the master for supplier data and the single portal for all suppliers to the business.

This is a logical conclusion and it aligns well with IT’s preferred architectural landscape, utilizing options already in the toolkit. It is, however, for enterprises that have embarked on this journey, where the issues in this configuration arise. It’s taking the wrong tools to the job when it comes to the wider objective of data quality and – the business case for the supplier portal in the first place – supplier onboarding.

So what’s going on? What can we learn from enterprises that have this set-up?

It’s all to do with how data enters the enterprise and is handled going forward.

The headache of how data flows

The first point to note is that the P2P is built for transactional data, not for master data. This is an important distinction because it defines the relationship of the P2P to the ERP, in which instance the P2P is subservient to the ERP.

Think of it in the consumer world. If a customer pays with a loyalty card, it creates one profile for the customer. If the same customer does not use the loyalty card and makes a cash payment, then the transactional data means a second profile is – has to be – created to complete the transaction, and the customer is counted as two, instead of one. The emphasis is on the efficient completion of the transaction. The same applies for supplier data. The data is created at different times, in different ways, for different purposes. This could be for contractual negotiations or sourcing, for example. The outcome is also the same – and, due to the myriad permutations in supplier relations, is decidedly worse: If you have a second ERP instance, even if it’s from the same vendor (and it so often isn’t), your P2P will have a second vendor master – creating duplicated supplier data, resulting in inaccurate or incomplete analytics, as well as inefficiencies for the business user and procurement team. As one example, when sourcing is carried out, there will be profiles for suppliers who send in RFIs that may not end up being used, but who do end up in the system – and that in itself creates more noise and difficulties (for example if you extract a list of suppliers, you then need to determine who is actually an active supplier).

So, while the flow of data works, the data is not going to be robust as it is already compromised due to the necessary relationships between each system.

Further, as a transactional system, Ariba just passes the data on, and that’s it. It cannot accept corrections back the other way. So there is inevitable disconnect between Ariba P2P and the vendor master in the ERP. But what of SAP MDG? The same applies. If a vendor fills out details in Ariba, this goes to SAP MDG – and if the governance takes place here, then the workflows necessarily should be built here. As mentioned already, this is not optimal as the data is already circulating and there is no need to have the correct or complete data  – provided that the transaction completes. There is, then, no easy workflow, if the data is wrong, for MDG to reject this and send it back to Ariba for the vendor to correct.

Sub-optimal outcomes and hot fixes

If data from SAP Ariba, or any P2P, is wrong you are left with three sub-optimal options:

  • Manually fix it, in which case you end up with a manual process anyway
  • Simply allow bad data into the ERP(s)
  • The most common choice: Allow the data through, have the ERP flag a mismatch and send the known data back to Ariba to allow transactions and accept that are discrepancies between the Ariba sourcing (contract) data and the P2P master data

The net impact of these compromises means that performance or supplier management is impossible, there will be ongoing pressure to initiate data cleansing programs and, when data is required for emergency reports, for example in the case of COVID-19, the reliability will be questioned. Longer-term, this will erode any trust in the data, reduce its value and potentially create tension or mistrust between departments or functions, such as Procurement and IT; and even Procurement and Finance.

Conclusion

Many organizations are waking up to the fact that this is a compromise too far.

The importance of the P2P suite in a modern buying organization inside a large, complex business, is undeniable, but experience in recent years has shown that a system designed to manage spend, invoicing and transactions really shouldn’t be forced so far out of its comfort zone.

Instead Procurement needs to become more focused the strategic rather than purely tactical considerations:

  • Determine and document the use cases for the data (both in Procurement and for the wider organization) and evaluate technologies’ abilities to meet the criteria of the use cases
  • Evaluate how supplier master data management can be best supported by a domain-specific solution that also matches the strategic direction of IT
  • Work in collaboration with IT and other functions to drive forward digital transformation as it relates specifically to the Procurement division

For more information about how to put these steps into practice, please refer to our detailed white paper ‘Supplier Master Data Governance.’

If you found this blog useful, then you may want to check out our other detailed resources as well, covering different aspects of master data management, data cleansing, data governance and more.

or

Explore our solutions

The answer to all of your third party and supplier management problems.

Learn More

Try for yourself

Give our sales team a call +1 (312) 948-0391 (US) or +44 (0) 203 325 4244 (UK)

Live Demo

© Copyright 2020 HICX Solutions. All rights reserved.