Blog

(Three compelling reasons to reshape your business processes, not your software)

Has your computer ever crashed while you were doing something important, causing you to lose all your work? A natural first reaction to this situation is frustration: your work is gone, your effort went in vain, you’ll never do it as well as you did it the first time…

And yet, when initial frustration is gone, and you start doing it over again, from scratch, you are more likely to produce results of higher quality than the first time. Why? The reason for this is simply called—experience.

When you do anything for the second time, you have something you didn’t have the first time: the experience of doing it. This makes your next attempt more likely to succeed. You’ve been there, done that; plus you get a second chance at thinking it all over—something that doesn’t necessarily always get done unless there is a compelling reason.

Now, imagine you had a chance to re-start your company from scratch.

Would you be able to design better, more effective processes? Could you eliminate all your monkey policies?

So, why don’t you?

Of course, you can’t just do it; your processes are tightly interwoven with your environment: people, software, culture, ecosystem, you name it. Even though things are sometimes ineffective, and you know it, maintaining the status quo might be an opportunity cost; compared to a radical change. Changing one of the factors could easily cascade to the other ones, and it is simply too risky.

But now that you are implementing a new ERP system, you are already changing one of the factors: the software. How many processes that you have are really shaped the way they are just because of the old software you had? Are you now simply applying your old process knowledge to the new software, and bending and twisting it to match your existing processes? Why not do it the other way around: rethink your processes, and map them to the new software?

I’ve heard complaints such as: our business processes are our competitive advantage, if we change them, we lose that edge.

It might very well be so.

But are you absolutely sure it is? Do you have metrics on that, or is that just your gut feeling? Especially if you are a small to mid-sized company which experienced a fast growth, a lot of your processes might have simply got their shape along the way, without proper thinking or reasoning, probably to match the software you had at hand at the time. Could you get them better if you gave them a decent dose of fresh brainpower?

Now that you are getting a new software, do you think that at least considering changing your processes to be a closer match for the new software would be worth a try?

I see three compelling reasons: best practices, total cost of ownership and freedom. Let’s take a short glance at them.

Best practices

ERP systems come with a lot of best practices. What price would you pay to be able to know how a successful company next door conducts their business? What price would you pay to get insight into hundreds of companies? Thousands?

Well, now you have that chance—at the license cost of your new ERP system.

Hundreds or thousands of engineer/years invested into research and development and making the software better must be worth something. Lessons learned on tens of thousands of implementations must be worth something. These are the things built into ERP best practices.

Do you think it would be worth giving them a try?

Total cost of ownership

ERP implementation costs can be huge. They generally break down into three categories: licenses, consultancy and maintenance. Licenses are typically a fixed price, you pay them and forget about them.

Consultancy is going to cost you dearly if you decide to change the system. But your biggest pain is just about to start.

If you reshape your ERP software completely to match your existing processes it’ll stop being what it is, and will cost you a lot of money down the road. Just think of maintenance and support cost. Or about switching partners—who is going to be able to support your totally customized solution? (Is even the partner who implemented it going to be able to support it? Sometimes, a single ninja developer can turn your NAV into the Mother-Of-All-ERPs, then quit their job—are you really willing to risk that.)

How about upgradeability? How much will it cost to get your customized solution upgraded to the latest version? Will it be possible at all? Will you be able to deploy the latest hotfix?

Freedom

If you are an agile small or midsized company, your processes are probably changing at a faster pace than your ERP software. Investments into ERP software are long-term ones; sometimes it can take several years just to break even, especially if you did heavy customizations. If you shape your software today based on your current processes, what are you going to do if your processes need to change in a year or two? Or a month or two?

Investments into ERP systems are long term ones—you are looking into five to ten years of lifecycle, sometimes even much more. Ten years down the road, do you believe you’ll conduct your business the way you do it today?

Tying your processes tightly to your software is bad. Changing a process typically costs some money. But changing a process and software at the same time can easily cost more than twice as much. And this is exactly what you’ll get if you adopt a practice of customizing the software to match your processes during implementation. When the wind of change swirls, your (outdated) processes are either going to have to stay (because they are tightly tied to your software), or you will have to pay expensive customizations every time you decide to change anything about your processes.

In my opinion, your best shot is loosely coupling your processes to the software, having the software do what belongs to the software, and do all that the software can’t do outside of it. Yes, this calls for extreme self-discipline from your entire workforce, but gives you flexibility to change your processes (or your software) without affecting the other. It gets you on a lean road and saves you a lot of implementation costs up front, and a lot of maintenance and support costs down the road.

Don’t you think it’s worth a try?

Let’s discuss.