( This article is excerpted from the report Agile ERP, available for download here. )
Agile ERP Implementation
The Little Bang Theory
Big bang ERP implementations are out. Rapid, incremental ‘little bang’ implementations are in. Leading edge software engineering organizations have embraced agile development principles for years, based on rapid, incremental releases.1 It’s about time ERP implementers learned and adopted similar principles. As the speed of business increases every year, companies can no longer tolerate long, expensive, enterprise software implementations. Now is the time for Agile ERP Implementation.
Agile Implementations Build Value Incrementally
Technology is often best absorbed in bite-sized chunks. In the same way that agile startups seek to ship the minimum viable product2 as soon as they are able, agile business seeks to implement the ‘minimum viable implementation,’ to speed time-to-value. From that foundation, they make adjustments and add capabilities in ongoing, rapid, incremental steps.
Continuous Improvement Throughout the Lifecycle of an ERP System
With Agile ERP, a business continuously improves. It implements small but meaningful improvements at a frequent cadence. These include continually improving and refining processes and keeping up with the latest functional and technology improvements (big data, mobile, analytics, and so forth). This requires an ERP solution that is architected to provide a continuous flow of upgrades and improvements without disrupting the business. In contrast, for ERP systems designed around big bang implementations, the initial experience and upgrades are so painful and disruptive, that it is literally years (in some cases a decade or more) between upgrades and hence companies lag further and further behind their competition (see Figure 1).
Going Live vs. Realizing Value
It’s not enough to turn on the ERP switch and declare victory. The critical goal for a company is having a system that is usable, the business’s processes and people executing as they should, and the solution is creating value for the firm. Sometimes the go-live is just the beginning of a painful period of trying to make things work; in a few cases companies have not even been able to ship product after turning on the switch (See sidebar, Going Live is Not Enough!). 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.
Industry-specific ‘Successful Practice Blueprints’ Accelerate Implementation
ERP implementations 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 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 implementations out in the field within that specific industry, learning what really works and doesn’t work in real world scenarios. Implementation also benefits a lot if the solution provider has a large, deeply engaged user community within that industry that actively helps one another, with 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 rapid initial implementation and the agile ERP approach.
Figuring Out When and What to Customize
No blueprint can deliver 100% of what every customer needs. It is important that the system can be easily configured and, as needed, customized in a way that survives any future upgrades without disruption. Some SaaS ERP systems, such as NetSuite, have been designed with this kind of future-proofed customizability in mind.5
But just because a 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, as it will greatly extend the initial implementation cycle, requiring much customization of the system. More importantly, it misses a rare opportunity to move the organization forward to best practices.6 There is even less excuse if the ERP solution provider, as NetSuite has done, 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 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.
The Value of Agile Engagement from the Start
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 pieces7 first. This is where leveraging the 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 approach starts right from the beginning of the sales cycle with the ERP solution provider/implementer.
A good example is the SuiteSuccess program from NetSuite. They start with a half-day meeting of all key stakeholders, including representatives from all departments that will influence or be impacted by the system. Crucially, the meeting also includes the professional services team from NetSuite that will be responsible for actually doing the implementation. They do 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 — getting alignment early and often. The team uses the Scrum methodology throughout the sales cycle and implementation to continually keep the customer aligned with what they are getting. No big surprises at the end!
This kind of early engagement also helps the prospective customer to see whether the 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.
Speeding up Data Loading, Cleansing, Enriching
Usually, existing data is incomplete and contains many duplicates and incorrect data, especially for companies coming off manual systems. 8 Cleanup and enrichment/completion of the data is a critical part of 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, Training, and Adoption
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 adds another layer of change management, especially for companies not used to working at that kind of speed or approach.
Change management can also be done in an agile manner: bringing 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 ERP implementation (agile or otherwise).
NetSuite’s SuiteSuccess methodology is a good example of an Agile ERP implementation approach. In part two of this series (Examples of Agile ERP Implementation) we will look at two examples of firms that have used SuiteSuccess to achieve quick time-to-value and ongoing improvements.
1 Agile software development principles include things like continuous frequent delivery of working software, daily face-to-face cooperation between business people (the users of the software) and developers, simplicity (focusing only on the essentials), and continual course adjustment. — Return to article text above
2 A minimum viable product (MVP) has just enough features to allow the product to be sold and used by early adopters in the market, thereby enabling the developers to conduct field-validated learning at lower cost and risk. — Return to article text above
3 Thankfully I had several years of experience in that position when the ERP system was implemented, so had a pretty good feel for what I was spending and was able to stay within budget as a result. It could have been much worse had I been a greenhorn manager! — Return to article text above
4 Source: Panorama Research, Clash of the Titans 2016, survey of 519 implementations for SAP, Oracle, Microsoft, Infor. — Return to article text above
5 Upgradeability is critical for a true SaaS system (i.e. a single instance, multi-tenant architecture) where everyone is sharing the same codebase, and system upgrades happen for everyone on that instance at the same time. Having customizations crash when an upgrade happens would be a disaster, so these providers need to take great pains to ensure survivability of customizations. NetSuite’s customers depend heavily upon customizations, having implemented tens of thousands of them and successfully gone through scores of upgrades. This track record means the system has been thoroughly battle tested, creating a very high confidence that customizations, done right, will survive upgrades without a hitch. — Return to article text above
6 In most cases, moving to built-in best practice processes will be an improvement over a company’s existing process which they often want to keep because ‘that’s the way we’ve always done it.’ Existing processes usually have grown haphazardly from a series of arbitrary historical decisions, rather than a deliberate process design, based on successful practices, repeatedly proven out in real-world settings. As one CIO succinctly put it, “I’m through with automating bad processes.” — Return to article text above
7 Frequently businesses want to implement non-core capabilities first. For example, the business may want to start by putting up a warehouse management system or an e-commerce site. However, without a foundational core ERP system in place, it is hard to maintain the clean, complete master data (customers, products and product-related content, suppliers, etc.) required to get value out of other systems. Furthermore, the core ERP system is needed to automate transactions, provide the system of record, and reduce rekeying of data between systems. These are lessons that a good ERP implementer has already learned and can help create a proven implementation roadmap that fits the business’s needs, goals, and current situation. — Return to article text above
8 Manual systems and processes allow for and/or cause a lot incompleteness and error in the data. Because people are involved in these manual processes, they can compensate for the weaknesses of the data by filling in missing data from one step to the next, thereby allowing incomplete data to persist in the source files/databases. People entering or re-entering data also make mistakes and create duplicates, creating more issues that need to be cleaned up before a reliable automated system can be implemented. Often the ERP implementation is the first time this bad data is exposed and the implementation itself is incorrectly blamed for the bad data. — Return to article text above
To view other articles from this issue of the brief, click here.