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.