Most people think of Reporting, Planning and Analytics (RP&A) as “downstream” activities. After all, how can you do any reporting or analysis if you don’t have an ERP or a POS to gather data from? It’s perfectly logical then to put in a reporting & analytics system after you’ve implemented a new and shiny ERP.
But therein lies the trap.
In this article we’ll show you three ways your RP&A infrastructure will lower the risk of a new ERP or POS, and avoid expensive mistakes during their integration.
But be warned – this needs a bit of a mental leap. Read on to find out what that is.
Integrating new systems, like an ERP or POS, is a disruptive process. Your staff need to be trained on operational tasks in the new system (like managing or entering orders). The reports they rely on to make operational or strategic decisions could change. And on top of all that, you have to run two systems together and slowly phase one out while the new one is phased in.
This whole process can be a shock to the back-office, especially for analysts who rely on a consistent view of data to make decisions on a weekly, monthly, quarterly or even seasonal basis.
This is where a solid RP&A infrastructure comes in. It can act as “shock absorbers” to minimize the disruption of a new integration. How? The first mental leap is to realize that ERPs, POS and other systems can and will change throughout the growth and life of a company. But your RP&A infrastructure should outlast them all. Your “data warehouse” is the one constant in your company’s information that records data, its history, and dovetails multiple systems (including that replacement ERP) into one cohesive view of the business.
Some people will fight this view, thinking that the ERP is the system of record. That simply can’t be the case because ERPs can and do change, and it’s a nightmare to move all the data from an old ERP into the new one. At times, it’s impossible.
But if you want to retain any history for reporting, or maintain any kind of consistency and predictability in your reports, you need something external to all your operational systems to act as that “buffer” between the old and the new. This is where your data warehouse, the heart of an RP&A infrastructure will shine. And this is why growing companies should beware vendors that say they can fill “all your reporting needs.” That’s assuming you’ll never grow again after buying their system.
Because most companies treat RP&A as a downstream activity, they don’t evaluate the new vendor on the accessibility and quality of their data. All sorts of problems arise after an expensive implementation when you realize that the new vendor is missing some critical piece of data, or doesn’t provide access in an easy way. Your RP&A infrastructure can be repurposed into a “Data Contract” that’s printed and included in the RFP (Request for Proposal) and requirements document when evaluating a new ERP vendor. Here’s what your contract should include:
Methods of Access. Data should be accessible on a regular basis. In order of preference, data should be accessible through:
Vendors who provide no data access, or distribute data through email attachments should be ruled out immediately as their integration cannot be automated.
Strong Requirements. Your Data Contract should also enforce requirements around:
A new ERP vendor may promise the world when it comes to their features, but if the data isn’t immediately available for extract, or if the granularity doesn’t fit your needs, that system is next to useless when it comes to making strategic decisions.
Most Business Intelligence professionals will tell you there’s at least one vendor that is terrible when it comes to the stability of their data feeds. Support tickets will be opened and quickly escalated to the highest echelons, requiring the customer’s C-Suite to get involved. How do you avoid this when evaluating a new ERP?
The answer is your RP&A infrastructure should be able to record and report how frequently each data source experiences problems, and how long the problem persists for. With this set up, you run your ERP pilot for at least 90-days after integration to see how many problems you encounter.
It will be natural for a new system to experience a lot of stability issues in the very beginning, this is just the nature of integration. But beyond a certain “shake-out” period, you should reach steady-state and that’s when the measurement should begin.
Vendor Scorecards also help you evaluate older vendors to see if any of them are causing grief, and how much that grief is costing your business in dollars and cents.
This is an extension to the Shock Absorber idea. When designed correctly analytics infrastructure allows you to phase in new operational systems while phasing out old ones. Remember we said that your Analytics Systems should outlast all your operational ones? It’s perfectly normal (and expected) for companies to outgrow an ERP or E-commerce system and graduate to something more robust as they grow.
That same “shock absorbing” benefit means your system of record is external to any operational vendor, so no one holds a ransom on your data when you try to move away.
One of the key takeaways here is that, despite an ERP or POS vendor claiming they can give you all the reporting you’ll ever need, it’s simply impractical for a high-growth business to remain with the same operational systems forever. RP&A however is supposed to have a much longer life-span, at least 14 years or more. In this sense it’s imperative to keep your Analytics platform separate from your operational ones.
The mental leap we alluded to earlier is that RP&A should go in before your operational systems, even when all you have are spreadsheets. It’s a sort of “cart before the horse” attitude that, when done properly, can help massively de-risk a new ERP implementation (“absorb shocks”), rule out incompatible vendors (“data contracts”), and keep all vendors accountable (“scorecarding”). It can also reduce vendor lock-in which is super important to growing companies.
All this lets companies use RP&A to define their business needs, rather than retroactively draw on data to respond to those needs. This holds true for any new system – POS, Ecomm, Marketing automation, CRM, or Mobile App.
Are you thinking of implementing a new ERP or other system, and want to explore how to de-risk the project and avoid expensive implementation mistakes? Then please . We’ll show you how to get set up.
TypeSift is a Data Engineering & Design Minimalism Firm. Our expertise is decluttering information and solving problems in your data that are holding back your growth. We build software that corrals data and invokes ingenuity with the fewest moving parts.