Industry Guidebook

In ERP, there is no such thing as a standard process

October 7, 2020

I’ve been selling standard software for 30 years now and in my experience, when you implement “standard” software, it’s very seldom that you actually implement it without any changes.

The same way in an organization, some processes are easier to call standard processes. But there’s always an angle on whatever a single customer is doing there. And in many cases, some customers are actually bending backwards to accept the standard process.

And they’re doing it for the wrong reasons. They think it will be effective when instead they’re actually causing commotion and disturbances in their own employees and organization.

Your business processes are like a car. All cars start with the same pieces. But within that standard process are a million variations: color, size, motor, etc. They might all start from the same basic pattern, but the end result is meant to be tailored to the driver. Does your company need a Volkswagen or an Audi? Only you know for sure.

Take maintenance processes for example. When you actually implement a standard process, you need to have the organization aligned with that process: not just management, but also the people who carry out the process.

When one of our customers started optimizing their maintenance processes, they agreed at the management level: “this is how we would like to steer our maintenance operations in our group”.

But the way they were organized on different sites was contradictory to what they wanted to achieve. There were people in the company with responsibilities and roles that didn’t exist in their new “standard” processes.

And these people had vitally important jobs: they were definitely not redundant.

This isn’t an isolated incident. It’s a typical discrepancy between how a wished “to be” scenario has not been aligned in reality—to the “as is”.

If you look at any given company now, you will have as-is situations in every standard process:

How do we do purchasing?
How do we retrieve goods from the warehouse?
How do we create a fault report?
How do we invoice?

But depending on how the company is organized, they could have split up the processes in many roles—or merged many roles into one road. If they’re not careful, they can put things upside down, in many cases.

So I want you to challenge the idea of “yeah, we have a standard process for this. Yes, we have the best practice for this.”

It’s not as simple as just saying an idea is a best practice.

Why? Because there’s no such thing as a standard process. There’s only processes that work and processes that don’t.

So, what can you do to make your processes better?

In the example mentioned above, the customer was already using Novacura Flow. With Flow they could see that each site was carrying out the same processes but in different ways.

You see this a lot in maintenance. Sometimes one central maintenance department serves every area of the site. Sometimes you have different maintenance areas depending on the process. Some companies have a central maintenance department that stays on-call for emergency repairs and activities. And some companies only have people working with the current shift—and maintenance tasks are only handled during regular office hours.

In each of these cases, there might be a standard process for maintenance service. But there are variations in:

Technician availability
Working hours
Number of sites
Tasks and responsibilities

The point here is that every process will have variations. Even the most structured process needs to account for variables, small variations, and only the people regularly carrying out those processes will be able to tell you what the variables are.

The standard processes in your ERP system are based on industry best practices, and as such, they’re designed to meet the needs of many. If you don’t already have a documented process, they’re a good place to start.

But these standard processes are not tailored to your organization. Forcing your business to change to fit the processes in your ERP system is a lot of work. It’s better to find a middle ground—processes that follow industry best practices, but also let people work in the most productive and efficient way.

A common issue in many organizations is the purchasing process. You make a purchase. It doesn’t matter the value of the purchase, the process is the same. If you buy a cake for a colleague’s 50th birthday party, the process is the same as when you buy that turnkey project for four hundred million:

create a purchase requisition
get an authorization
make the purchase
submit the invoice for payment

And this works for bigger purchases. But as soon as you have small things like buying a cake, do you need to be that strict?

Does the bakery have to be a registered supplier in the system before you place the order?
Does the bakery have to pass a credit check before you can buy the cake?
Do you really need to match a Purchase Order receipt with an invoice line?

When you apply the standard process across the board without exceptions, it leads to inefficiency (and maybe a sub-par birthday cake).

In some companies they force employees, if they buy small pieces of equipment or cable or whatever you need, to put that on an expense report. It’s the employee’s job to put it on the expense report. And they get reimbursed once a month or whatever, when they deliver an expense report to the company.

OK, that’s fine, but it doesn’t solve the underlying issue. It just puts the problem on the employee—and now he’s mad because he needs to do a lot of administration to get reimbursed. And now the purchasing department doesn’t know how much has been spent until all the expense reports come in, so they don’t have accurate spending numbers until next month.

And in the end, the cake cost a lot more than what you paid for it. It cost money, yes. But it also costs a lot of administration time: data entry, authorization, etc.

But even if you’re not using IFS Applications, with a tool like Novacura Flow, you can create workflows and apps that let account for how different people perform your standard processes.

You can use Flow to make sure the end user is actually running a process that delivers the same output as they do with their colleagues on another site. But they can do it in different ways. There are different steps to do with it. Could be more or less people involved. It could be different ways of authorizing what they have reported, etc.

But you need to have this layer—what we call the Flow Layer—to take care of the discrepancies, bridging the gap between the people and the solution.

So to end on a provocative note, as I like to do:

There is no such thing as a standard process. Not in reality.

In the system, yes. But not in reality.