Manage Learn to apply best practices and optimize your operations.

How I learned to love Agile ERP and why you should too

CTO Niel Nickolaisen's road to Agile ERP began with an 'insane' ERP experience and a vow.

My first real job in IT was to be the project manager of a large, complex ERP implementation. At the time I thought I had delivered the greatest ERP in the history of mankind. Later, I realized the sad truth -- I had spent the company's money and time and a great team to contort and twist a market-leading ERP and make it look like the legacy system we knew no longer supported the business. In retrospect, what we had done bordered on insanity. Why in the world spend so much time, money and effort to turn something new into the old thing we wanted to replace? 

That anti-ERP experience, as I'll call it, became the defining moment in my career. As a result, I did two things. First, I started to segregate every activity into two categories. In category A are those things that create our competitive advantage. We focus our innovation on the few things in category A. In category B are those things that are mission-critical (we cannot exist without them) but that do not create competitive advantage. Activities in category B constitute the digital core (things like ERP and CRM and SFA and financial reporting and compliance) and they never (yes, never) deserve customization. Why in the world would we invest in customizations to things that will not buy us competitive advantage? Second, to reinforce my new way of looking at IT, I took a vow that I would never customize any part of that digital core.

That was many years ago and I have remained true to my no-customizations vow. I have selected and implemented (either for myself or as an advisor to others) at least a dozen ERP systems.

2016: The year of Agile ERP

But I now find myself in the midst of a new ERP experience -- a large re-implementation. This one is for my current company, which I joined in 2015. First, a little context: About 20 years ago, the company took a market-leading ERP and spent about three years customizing almost every bit of it. This included customizing the Accounts Receivable (AR) module because it was not good enough for them. Now, we can all agree that AR is mission-critical but who ever created competitive advantage with their home-grown or customized AR process and system?

In retrospect, what we had done bordered on insanity. Why in the world spend so much time, money and effort to turn something new into the old thing we wanted to replace?

I started the planning for this re-implementation two years ago and we started the project one year ago. You might ask why it took one year to do the planning: Because I had to convince pretty much everyone in the company that a standard, zero-customizations ERP would support our business. (Remember, 20 years ago the company was convinced of the exact opposite.) This took some doing, in fact, nearly daily conversations and questions about my aforementioned category A and B activities. I asked questions such as, "What do we do better than anyone else?" "What creates our competitive advantage?" "Why does someone choose us over all of the alternatives?" (Our AR is not the reason someone chooses us over the alternatives.)

Such conversations started to change the company mindset about our category B activities. I stressed their importance and that their importance did not come from their uniqueness but from their operational excellence. With the mindset changing, we had to now do the work.

Agile ERP experience prompts new vow

But, how best to pretty much start over with an ERP while proving that a zero-customizations ERP will actually support the business? That is when we came up with the idea of the Agile ERP (and, yes, I am going to trademark that term).

Agile practices break projects into time-boxed, scope-limited iterations. I have found that one of the most important agile practices is to end each iteration with a demonstration of working software. We decided to apply this concept to our ERP and use the end-of-iteration demonstration to show that a zero-customizations configuration would actually work. We would invite critical stakeholders to the demonstration so that they could see a working process and system.

For the past year, this is what we have done. We created a backlog of higher-level objectives tied to our major horizontal processes (order-to-cash, procure-to-pay, planning-to-production, et cetera). We chose an iteration length of three weeks. At the beginning of each iteration, we determined what configuration items (remember, we don't allow customizations) we could get done in the next three weeks. At the end of the iteration, we showed a working, functional system that the process owners could start to use in our ERP sandbox.

Every three weeks, the number of doubters decreased. We are now done and are operating the new ERP in parallel with our legacy ERP while we transition data and clients to the new ERP.

This Agile approach to ERP has worked so incredibly well that, in addition to segregating every activity into Category A (deserves innovation because it creates competitive advantage) or B (mission critical, but will never create competitive advantage and so does not deserve innovation or customization) and to keeping my vow to never customize anything in the digital core, I am committing to take an Agile, iterative approach to everything.

If I ever again implement ERP, it will be Agile ERP. The next time I put in a CRM system, it will be Agile CRM. My next network or phone system upgrade will be Agile Phone or Agile Network. That means I will do things in short, time-boxed, prioritized iterations that reflect my categories and my vows.

Next Steps

From the ERP archives:

ERP implementations will age you (and might enrage you)

A CIO's ERP implementation, blow by blow

A CIO leader's ERP experience that paid off big time

Dig Deeper on Enterprise business applications

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Great article, Niel. I've found over the years that insufficient user training can derail an ERP implementation (users don't accept the system). Do you find the Agile ERP approach makes training easier, since stakeholders see the system throughout its development as opposed to just at the very end?
Great article.

I liked the idea of putting the activities in the category A and B . it makes it simple enough to understand how far one should go spending time and money on the issue/activity at hand.

I have 2 questions though. You mentioned AR module being in Category B but do you put the entire module into categories or pick the functionalities and categorize them?

My question stems from an understanding that - yes AR department is not the reason a customer would choose company X., but (1) if AR dept has somewhat low efficiency and creates some issues that affects how customer's payments are handled, the customer or the account manager is not going to be very happy with the fact. (2) secondly, if AR functionality is very basic and does not provide for robust reporting, it would affect how the incoming dollars are being analyzed.

So the functions that cater to customers indirectly or provide for good reporting, should be considered little more deeply?

any opinions on that?