We all thought it was an ERP failure, but then…
ERP (Enterprise Resource Planning) software deployments scare a lot of people, and with reason. Usually when ERP failures hit the news it’s because it’s newsworthy and onerous. In August 2018, retailer Lidl reported a near $600M (€500m ) failure with SAP. News from the same quarter show National Grid and Indian IT vendor Wipro settling a lawsuit for $75M and the Government of Canada scrapping the Phoenix pay system– having to pour another $430M into a software solution driving the cost above $1B for something that still does not work. So “Yes” ERP failures are downright scary.
But even though failures get much news coverage, there are far many more successes in ERP deployment than failures. On average there are over 12,000 ERP deployments in the US per year. Few of those ever hit the news because of a ‘botched’ implementation; at Horizon, we can boast 0 failed implementations…ever. ERP do solve problems, many of them. Whether you struggle with Omnichannel sales, inventory tracking, Demand and Supply chain, ERP are the solution to the business problem, but it must be deployed successfully to do that.
So, how do you succeed your implementation of a new ERP? It’s not a single element that will cause success; it is a number of elements. Although in many cases an ERP is a Commercial-Off-The-Shelf (COTS) product, it should still be viewed as a software development project. We say ‘development’ as opposed to ‘deployment’ because every business is slightly different due to their history. Think of an entrepreneur who had a good idea and created a successful business. Before long the business needs to track finances, gets surrounded by a team, creates processes and builds system. Usually none of those are experts. An entrepreneur’s book keeper is often a low paid clerk since the business does not have the resources to get a CFO. Same goes with much of the team. That team builds business processes (more by default than design) to ‘keep the lights on’ as best as they can- since they are not enterprise architects. Thousands of businesses exist this way. [That’s how we got to a business that required the printing of an invoice before the quote was generated (yup bizarre!)] While all businesses are the same (buy goods/employee time, transform good or deliver goods/service, collect money) there are nuances in the way they operate or perform particular processes, hence why every implementation is a development.
An organization can select a COTS ERP or decide to create one. In the 90’s or 2000’s creating an ERP might still have been a good idea. But the maturity of COTS ERP has made this a bad idea nowadays- it’s akin to an organization creating their own automobiles for their employees’ use rather than buying them. In the case of a COTS implementation, business will have 2 choices: either accept the processes, workflows and nomenclature of the selected ERP or customize them.
If a business chooses to deploy the software as it is designed, then it has to change a number of internal processes. That in itself is not a bad idea since many processes might have been created by default and are likely not helping the organization. We noted a bizarre process above: the sales reps were unable to query the inventory, a query required an invoice; once the invoice was created, reps could validate the in-stock quantity and generate the quote. The process worked fine with one sales rep but when it grew to many reps, it failed. Sometimes it’s best to adopt the processes that were engineered from best practices. After 20 years of development and over 20,000 deployments, NetSuite created the SuiteSuccess products. They come bundled and prepare for your specific needs and minor adjustments to your processes are required to go live- as a matter of a fact, we can take you to the Cloud on a new ERP in less than 100 days. The clear advantage is to use a tool that’s been tried and proven true. Referring back to the automobile illustration, using SuiteSuccess features is akin to operating a vehicle already built- so when you turn on the wipers, they wipe the windshield as it is expected. The SuiteSuccess brand applies to Manufacturers, Retailers/e-commerce, Software Mfg., Professional Services, Distributors, etc.
A business may chose to customize a COTS. This is when a Software Development Cycle should begin. There are many software development methodologies but two of them that should come into play in this situation are: agile and waterfall. The Agile Methodology consists of early and continuous delivery of features with multiple beginnings and endings whereas the Waterfall approach is more linear, with one beginning and one end. The truth of the matter is that in an ERP deployment both methods are and should be at play.
There is the beginning of the deployment (after an agreement has been reached) and a planned end (when the system is live) but depending on your organization, there may be either a waterfall or agile approach to deploy the ERP for various business units. An organization may choose to deploy each business unit separately: start and complete the finance business unit, then move to a Sales business unit, etc.; or it may choose to do all business units simultaneously (Big Bang). In the latter, the Agile methodology would prevail. The Big Bang approach is faster but much more risky since requirements are defined in parallel. The Big Bang approach requires very skilled and capable Project Manager(s) who can communicate quickly and effectively and managers in each business units who can collaborate and communicate on ever changing requirements.
Finally, a business could attempt at building an ERP from scratch. This is a complete software development project with multiple Agile and Waterfall phases; but at the risk of repeating, this is likely not a sound decision in most cases.
There are two common mistakes made by organizations when deploying an ERP. Being too involved and not involved enough. If business managers are not involved enough, the development team lacks direction and makes decisions that may not be in line with what the business needs/wants to do; while being too involved means that critical components that should be delivered by the software vendor are taken up by the client. The overall project management should be a collaborative effort by the client and the vendor. The single and most important criteria for your success if the life cycle of the Business Requirements document (BRD). Think of the BRD has the menu in a restaurant. Your desire is for a steak supper so you go to a restaurant and make a selection between the Ribeye with a Caesar salad, Filet Mignon with garlic potatoes or T-bone with mashed potatoes. Whatever your choice will be, you will get to eat exactly what you ordered. That’s how a BRD should work.
Defining and delivering the BRD through either the Agile or Waterfall methodologies is tantamount to the success of your deployment. HorizonAssociates can successfully deliver an ERP for your team. Contact us to learn the next steps in your quest to solve a business issue.