Why Requisitioning Must Be Part of ERP Conversations

Requisitioning (or asking for what you need) is a key part of the procurement process. So why is it frequently sidelined in ERP discussions?

ERP Requisitioning

This article was first published on the Coupa Blog.

Having either implemented or worked with some of the major ERP systems on the market, I think I’m on safe ground when I say, nobody chooses to do requisitioning through their ERP system. They settle for it.

ERP systems are largely built for finance and the controllership. End users are often not taken into account. Their requisitioning modules are notoriously difficult to use, which is too bad because requisitioning is how most non-finance users — aka. everyone else in the company — will interact with the ERP system.

In fact, people putting in requisitions to get what they need to do their jobs represent a large segment of non-finance users feeding data into the ERP. If you burden them with a system they won’t use, or that they’ll use in a sloppy way, your ERP will have data quality issues. To avoid having to settle for ERP requisitioning, it’s to everyone’s benefit for procurement to be part of the ERP discussion, as a strong advocate for the end user.

Advocating for Procurement

I’m not saying that will be easy. As I’ve written previously, organisations need to think more broadly about their whole finance system, which comprises multiple interconnected processes, from sourcing to the point where something is paid for and entered into the record.

The ERP system addresses the back end, and it’s designed for finance to be able to do what they need to do regardless of how the data gets in there.

So, the discussion doesn’t usually extend to the front end—sourcing, contracts, approvals, requisitioning—which is where a lot of that data comes from, because the thinking doesn’t extend that far. It’s not easy to break down these silos.

In situations where I’ve been the advocate for the needs of procurement, I’ve had to fight pretty hard to get that perspective considered and I’ve often been the lone dissenter in the room.

  • Get Real

You need to be a realist. There are always resource constraints, and there’s a hierarchy of needs within finance, and user-friendly requisitioning is never going to be at the top of the list. But when requisitioning is ranked seventh out of six fundable implementation projects, the potential for settling becomes very real. Hello, heavy ERP requisitioning module.

  • Map it out

One way to avoid that mistake is to map out the whole process, because it’s not completely linear. Data flows from one process into one, or several, others. A lot of times an ERP decision is made before these processes are mapped out. But, when you map it all out, it becomes obvious that quality and consistency of requisitioning is critical for getting finance all the data they need to make the ERP system a single source of truth. 

  • Learn the language

The main requirement for a better-than-ERP experience is that the requisitioning system be user friendly. You can’t push a heavy ERP requisitioning system on a marketing associate fresh out of college, or on a seasonal retail worker.

But usability is one of those subjective, soft terms that may not always resonate with the finance audience. To advocate effectively, understand the needs of finance and speak their language. For example, if you’re talking to a controller who is a worldwide tax authority, framing it in terms of compliance and data quality is a much better approach.

  • Not Amazon-like

You also need to break down what you mean by user friendly. Every ERP vendor is going to say their requisitioning module is user friendly. If no one is looking out for non-finance users, that box just gets checked.

How user friendly does it need to be? You’re probably expecting me to say, “It should be as easy to use as Amazon.” I would personally love it if it could be so, but there are different requirements for business buying that for consumer buying. But, it can be much easier than most ERP requisitioning modules make it.

A good system approaches requisitioning broadly. It’s not just asking people to fill out purchase orders. It should really be a way for an employee to get anything they need to do their job. In fact, I’d rather they didn’t have to even use the words ‘purchase order’ or ‘requisition.’  We’re simply helping them buy things.

Ideally, they should be able to click a bookmark, get to a portal and then get in through a single sign-in. They land on a homepage where they see relevant buying policies and have visibility into all of their transactions

There should be smart search capabilities, tailored towards a user who is probably somewhat resistant to using the system. They can’t get irrelevant results, or come up empty. They have to be able to quickly find what they want, or find out how to get it.

If it’s a catalogue item, the actual policy pops up, which will guide them how to buy it. If they need a new computer monitor, maybe it comes back and says, “OK, you have to log a ticket for IT because they do provisioning.” Or if nothing is there, it will guide them towards making a free form request. But they don’t even need to know these terms. All they need to know is what they want.

Heavy and Cluttered

In contrast, the requisitioning modules of the major ERP systems are often heavy. The home page may be cluttered with lots of finance information that’s not relevant. The email notifications can be complex and confusing.

There are a lot of fields to fill in so finance can get all the codes and data it needs – provided the would-be requisitioner doesn’t take one look at it, decide it would be faster just to run down to their local Staples store, and expense the darn thing. That’s the kind of thing that happens when you settle.

There are good reasons why requisitioning is not the top priority in the ERP discussion, but neither is it right for it to have no presence or priority. The real impact of user-friendly requisitioning is better data and better compliance.

To make sure your company doesn’t settle, somebody needs to advocate for all the people who aren’t in the room, but are going to have to use the system, and convince finance to give it the proper priority.

The ideal situation is that requisitioners don’t have to think about finance at all—or procurement for that matter. The irony is that to accomplish that, the folks in finance have to get together with procurement and think hard about requisitioning.