New technology is often best absorbed in bite-sized chunks. In the same way that agile startups seek to ship the minimum viable product as soon as they are able, the agile ERP concept encourages businesses to implement the ‘minimum viable implementation,’ in order to speed time-to-value. From that foundation, organizations are able to make adjustments and add capabilities in ongoing, rapid, incremental steps.
With agile ERP implementations, businesses can continuously improve as they grow, scale, and evolve. The agile ERP concept calls for S implementing small but meaningful improvements at a frequent cadence. This includes continually improving and refining processes and keeping up with the latest functional and technology improvements (big data, mobile, analytics, and so forth). Abiding by the agile ERP concept requires investing in an ERP software solution like Microsoft Dynamics or NetSuite — which are specifically architected to provide a continuous flow of upgrades and improvements without causing disruption.
In contrast, when ERP systems are designed around big-bang implementations, the initial experience and upgrades are so painful and disruptive, that there are literal years (in some cases a decade or more) between upgrades. This causes companies to lag further and further behind their competition (see Figure 1).
It’s not enough to turn on the ERP software switch and declare victory. The primary goal for a company should be to implement an ERP system that is engaging, has a fluid user experience, creates value, and functions as expected. Sometimes the go-live is just the beginning of a painful adoption period of trying to make things work — in a few cases companies have even been rendered unable to ship products after their ERP system migration! Some research has shown that 50%-75% of the ERP implementations from major solution providers cause operational disruptions at go-live and that disruption often lasts for several months.
Many years ago, I was a department manager at a large multi-national firm. We implemented a major ERP system in nine months—at the time, the fastest implementation ever of that solution. While the ERP consultants were busy patting themselves on the back, I stopped receiving the monthly budget reports that I had been receiving for years under the old system. These reports told me how much I was spending in my department and what it was being spent on (including contractors’ fees and payroll). It took another nine months before I started receiving those reports again, during which time I was ‘flying blind,’ not knowing what our department was spending or whether we were over budget or not. For me ‘going live’ meant going dead as far as my visibility into spend! One of the reasons it took so long for the IT folks to get around to fixing our department’s problem was that they were busy fixing more critical issues that were preventing us from shipping products!
ERP implementation approaches take longer when they are initially installed as a ‘blank slate’ that can be configured to ‘do anything you want.’ That often requires a tremendous amount of work and time creating the different roles, screens, reports, workflows, system configurations, mappings, and customizations to make the system work as desired. Furthermore, in some cases, the customizations cause trouble during upgrades—the system breaks or requires extensive new debugging and rewriting of customization code. As a result, customers may delay badly needed upgrades for years.
One way to solve this ‘last mile’ problem and get up and running more quickly is by using industry-specific successful practice blueprints. These blueprints are comprised of industry-specific configurations, based on past successful agile implementations, including things like system-to-system data mappings, user roles, and role-specific workflows, business rules, dashboards, reports, and analytics. Together these capture the practices and particular way of doing business that have proven to be successful within specific industries and sectors.
Creating effective industry-specific blueprints requires that the ERP solution provider has many years of experience doing agile ERP implementations out in the field within that specific industry — learning what really works and doesn’t work in real world scenarios. IThe solution provider should also have a large, deeply engaged user community within that industry that actively helps one another. This includes online and in-person mechanisms for asking for and sharing advice and knowledge about implementing.
This pre-built blueprint approach can shortcut a tremendous amount of upfront configuration and setup work, as well as making it much more likely that things won’t be forgotten in the process. The industry-specific blueprint is a key enabler of a rapid and agile ERP implementation approach.
NetSuite has created several different industry-specific blueprints, including one for nonprofit organizations. To identify successful practices and processes for the Nonprofit Blueprint, they focused on those customers who have achieved the most and done the best with their agile ERP implementation. From those successful implementations, NetSuite finds and identifies success-yielding practices and processes to configure into the blueprint; the roles, reports, dashboard, process workflows, and so forth. They draw from many resources to find this knowledge:
The team that built the blueprint was not theorists, but people who have done many, many agile ERP implementations. The Nonprofit Blueprint took thousands of hours of configuration work to create.
This, of course, does not mean there is no place or right time for configuration or customization of these pre-built blueprints. Companies can evaluate their processes and needs against the blueprint and identify areas where customization is really justified. These customizations do not have to be in the first release (remember, it is a minimum viable release). The core system can be put in place and then improvements made in a series of increments.
Just because customization can be done doesn’t mean it should be done. Some companies moving onto a new ERP system want to customize the software to make the system work just the way they currently do things. That is almost always a bad idea. For one thing, it is definitely not agile, and it will greatly extend the initial implementation cycle. More importantly, it misses a rare opportunity to move the organization forward to ERP best practices.
There is even less excuse if the ERP solution provider has taken the knowledge and insights it gained through thousands of implementations with others in the same industry and embedded that into the pre-configured blueprints they have built. Leveraging this knowledge is an opportunity for most organizations to realize dramatic improvements.
This, of course, does not mean there is no place or right time for configuration or customization of these pre-built blueprints. Companies can evaluate their processes and needs against the blueprint and identify areas where ERP customization is really justified. These customizations do not have to be in the first release (remember, it is a minimum viable release). The core system can be put in place and then improvements made in a series of increments.
Businesses may struggle in figuring out which customizations are truly needed and when it is better to adapt their business to use the blueprint. They often overestimate what they need in their first minimum viable ERP implementation and/or focus on the wrong pieces. This is where leveraging the an ERP solution provider’s experience can be valuable, especially for those initial decisions. To ensure that good critical roadmap decisions are made, it is important that an agile ERP implementation approach starts right from the beginning of the sales cycle.NetSuite’s SuiteSuccess Program.
A good example of a successful agile ERP implementation approach is Withum’s migration process, which is modeled after the SuiteSuccess program from NetSuite. SuiteSuccess starts with a half-day meeting of all key stakeholders, including representatives from any department that will influence or be impacted by the new ERP system. Crucially, the meeting also includes the professional services team that will be responsible for actually doing the ERP implementation. The services team does a step-by-step walkthrough of all the major processes in the blueprint to reach consensus with the key stakeholders that these will work for the business as preconfigured.
Any areas where the prospective customer wants to do things differently are identified and discussed to reach a mutual decision on whether a deviation from the blueprint is really going to add value, and if so, when in the roadmap it should be implemented. Often the professional services team will then put together a demo, to show the prospect exactly what the system will look like. In this way, clear alignment of expectations about precisely what will be delivered is achieved very early in the process … even before the deal is closed. This is a key aspect of the success of Agile ERP implementation —getting alignment early and often. Using the Scrum methodology throughout the sales cycle and implementation keeps the customer aligned with what they are getting and ensures there are no big surprises at the end!
This kind of early engagement also helps the prospective customer to see whether the ERP solution provider truly understands their business and industry, and gives them a chance to see the provider in action, observing how they work through the issues. A good solution provider continues to be an ongoing strategic partner throughout each stage of their customer’s journey.
Smaller companies usually have constrained resources, few or no dedicated IT personnel, and lack of technical expertise within the firm. Their employees wear many hats and their time is very constrained, with little or no time to work on implementing, testing, or learning a new system. They barely have time to do their ‘day jobs.’ These same challenges are faced by many larger companies as well. A blueprint approach, with an experienced, knowledgeable, supportive solution partner can help resource-constrained firms quickly implement and start realizing value.
Usually, existing data is incomplete and contains many duplicates and incorrect data, especially for companies coming off manual systems. Cleanup and enrichment/completion of the data is a critical part of an agile ERP implementation. The amount of time it takes to clean up the data and the effectiveness of the process are an important factor in the time-to-value equation. When these take a long time, it can dramatically reduce how agile the implementation really is. Therefore, the data loading, mapping, cleansing and enriching processes, tools, and resources that a solution provider brings to bear will have a significant impact on the implementation time, as well as the usability of the system.
Change management is critical to the success of any new system. Frequently the amount, intensity, and repetition of change management outreach required is dramatically underestimated, leading to low, slow, or no adoption, and in some cases outright rebellion. An agile, continuous improvement approach to change management brings the front-line users into the process from the start— providing education of new concepts incrementally (rather than one big dump), continually confirming that there is alignment and understanding of what is changing and why, and soliciting feedback from ‘the troops’ on the front line who may spot genuine issues much earlier in the process (rather than disruptive discovery of those issues after go-live). Getting employees onboard, helping them understand what is being done and why, and getting them enthusiastic about what is happening is critical to the success of any agile ERP implementation.
An agile, blueprint-driven approach to ERP implementations brings tremendous benefits:
Agile ERP’s time has come. Businesses that want to be agile themselves should embrace it now.
Marketing language tends to blur the lines between ERP solution providers and makes it harder to distinguish actual capabilities. Everyone claims to have rapid and agile implementation methodologies, but not all do. Some things to look for include: