Is Panorama Consulting Correct Companies Should Not Develop Custom ERP Systems?

Executive Summary

• ERP software selection advisors tend to have a blinding focus on selecting from several ERP alternatives.
• This typically blinds them to the implications and often lack of fit of ERP systems.

Introduction

In an article titled Custom ERP Software: Should You Even Consider it? Panorama Consulting makes some claims about why customers should not customize their ERP systems. We evaluate this advice to see how it checks out.

See our references for this article and related articles at this link.

Customization is to Avoid Process Improvement?

Organizations like having full control over their solution, and they want to build it exactly to their specifications. This way, they can avoid process improvement and business process reengineering. Process work costs time and money, and so does transitioning employees to accept the new processes (i.e., doing organizational change management). – Panorama Consulting

This is a frequent claim by both ERP vendors and consulting firms. However, the evidence supporting the benefits of business process reengineering, after all the extraordinary claims have failed to materialize, as I cover in the article Is a Lack of Business Process Reengineering Why ERP Projects Fail?

As is covered in the article, BPR made a lot of money for many consulting companies for a short period of time, but the claims of BPR enthusiasts turned out not to be true. In fact, the book and the concept are basically a scam promoted by ERP vendors and consulting companies because Michael Hammer was telling companies what the ERP vendors and consulting firms wanted them to hear.

The main incentive that ERP vendors and consulting firms have to keep promoting BPR is that their functionality is often a big mismatch for the client’s requirements. ERP system functionality is mostly generic, and implementing the ERP system, often means removing advantages in processes the company has built up over the years. ERP vendors want to state that all of their functionality is “best practices,” and all of the functionality required by the customer is not approved. However, this is an excuse so that the ERP vendor can sell a generic solution to a customer with more complicated requirements.

To reiterate, neither Panorama Consulting nor any software vendor nor Michael Hammer of BPR fame has ever produced any evidence that companies do better than implement generic ERP functionality.

Companies Like Building Their Own Solutions?

Finally, organizations like the lower upfront costs of building their own ERP solution. Rather than buying an all-in-one solution that might be too big for their needs (and budget), they can scale the investment by developing applications on an as-needed basis.

This is absolutely untrue. Companies prefer to buy turnkey solutions. They only customize applications or create custom applications because the application they buy does not have the functionality that they need. Before the 1980s, custom applications were the norm, but now most functionality purchased from a vendor is purchased from one.

Companies Don’t Have Skills in ERP?

Unless your company specializes in ERP systems, chances are your employees are not especially skilled in this realm. This isn’t your core competency, and it shouldn’t be.

However, when you build your own software, you’re suddenly forced to fill the shoes of an ERP vendor. Your in-house resources become dedicated to learning the technology and skills required to create the ERP application and keep it up and running.

Companies had internally developed applications long before ERP systems appeared on the scene in the 1980s. So they had and have skill in building these systems. This paragraph assumes only ERP vendors know how to create functionality, and calling a custom application created by a company an ERP system is very confusing.

The paragraphs just odd, because it asserts that creating one’s own systems or customizations makes the company and ERP company or “fills their shoes.” Secondly, developing one’s own system does not make the customer an ERP company. Furthermore, the ERP company is not skilled in its requirements and is not offering them functionality customized to their needs. The ERP vendor is offering generic functionality that it developed for other previous customers.

Drawn Out Delivery Times?

When your workforce is stretched thin, it could place a strain on your staffing levels. This could cause the project to slip in the ranks, becoming lower and lower on your executive team’s priority list.

When this happens, you may find that development, configuration, and testing take longer than normal. Eventually, you end up exceeding your project budget and timeline.

Customizations will have to be created one way or another, and if not, it will mean the business requirements will not be met. Only the simplest of companies can buy an ERP system and do no customization. So how does Panorama Consulting recommend dealing with that? It is not hard to see by accepting the generic functionality offered by the ERP vendor.

Secondly, using an external consulting team is far more expensive than using internal resources. Panorama Consulting is (as they are in the pocked of ERP vendors) entirely leaving out the cost comparison and, by doing so, making it appear as if the costs are somewhat equivalent.

Support from the ERP Vendor

One of the major benefits of buying ERP software? When you work with a vendor, you have access to teams of people that can offer expertise in a range of areas.

In contrast, if you have homegrown ERP software, you have fewer options when technical issues arise. You have to lean on your limited internal resources. Unless they’re strictly dedicated to the project (which is unlikely), this will mean taking time away from their other business activities.

Another problem with relying on only internal support is key resources may leave the company, taking their system knowledge with them. You’ll be forced to find, teach, and train new employees on how to use your custom system, which is both laborious and time-consuming.

A customer gets from an ERP vendor access to resources that understand the vendor’s ERP system at a very high price. Anything that is outside of this functionality and technical foundation is not worth hiring from the ERP vendor. That is, the “range of areas” is the ERP application’s functionality.

However, what if that functionality won’t work for the customer — well, the ERP resource is incentivized to push the customer towards using the ERP functionality, often by lying to them. So the ERP resources are also highly biased and, in many cases, willing to provide misleading or false information to the customer.

As for the last part of the quote, finding and hiring employees to manage an internal system will always be less expensive and more sustainable than hiring resources from the ERP vendor or less knowledgeable resources from the consulting firm partnered with the ERP vendor. Furthermore, supporting software internally will normally allow far better support at a much lower cost. Most ERP vendors use the support contract to get a lot of their profits, so the support offered is typically quite cut down. And the larger the software vendor, the more they tend to gouge the customer on support, with companies like SAP and Oracle being the worst in this regard. Basically, when you buy support from a vendor, you can’t exactly control what they give you. Many promises will be made, but it is not like when you hire your own support team and have full control.

ERP Systems Are More Scalable Than Custom Developed Systems?

A main selling point of pre-built ERP systems is that they’re scalable. This means they can evolve as your business grows and as your requirements change.

In many cases, upgrading is as easy as “turning on” specific features that are pre-implemented into your system and ready to deploy.

However, with a custom ERP system, you need to continuously add pieces of customization to fit your changing processes. Not only are these additions costly, but they can take a long time to build.

This is a claim often made, but it’s not clear why are ERP systems particularly scalable? If the topic is the volume of transactions, an open-source ERP system sitting on an open-source database is quite scalable. Wikipedia runs on MariaDB.

It was interesting to find a separate article from Panorama Consulting called Lessons Learned from the University of Massachusetts ERP Failure.

4. Ensure Software Scalability
One of the factors that contributed to the UMass failure was a system overload. Put simply, there were too many people trying to access the PeopleSoft platform at once. Even when the main bugs were fixed, student access was still staggered to prevent the same issue from occurring again.

The lesson here is that software scalability cannot be overlooked. Instead of selecting ERP software that just barely meets your current needs, look ahead and consider how you can plan for an increased number of users or transactions. Then, choose software with built-in scalability that can support this expansion.

Wait, are ERP systems naturally scalable, or is that something one has to be careful of? Because in the first article the simple act of buying an ERP system assured scalability. However, in the second article, scalability issues with an ERP system caused a major outage at a university. Can we get a clear explanation for what Panorama Consulting is saying about ERP and scalability because the picture now looks a bit muddled.

As for upgrading being easy, Panorama Consulting has got to be kidding. Upgrading ERP systems is quite expensive, and I know this because upgrading an ERP system is a significant line of business for large IT consulting firms.

As for why the customization keeps changing, it is not clear what that statement is true. When customization is developed, it is designed to fit the requirement. Many requirements have stayed the same for decades. Why is a custom, or should I say non-generic ERP-supported process changing? The quote does not explain this. This is just an assertion without evidence, and the reader is expected to accept the assertion.

Customizations Only Useful As Long as Employees Stay

Once built, these customizations are only viable as long as the employee who developed them stays with your company.

This can happen, but customizations are normally documented. After all, how did the technical and functional specs get written to develop the customization? The company has to keep these documents. Overall, this is a ridiculous assertion. It would mean that every custom developed by companies begins to malfunction when the employee who developed the specification leaves the company. That can only be a statement by someone who is lying or has never worked in systems.

Customizations Become Quickly Outdated Technology?

We don’t have to remind you of the rate at which even the most cutting-edge technology becomes outdated. This is why you need a modern ERP system that’s regularly updated.

Sure, you can update a custom ERP system, but many companies experience roadblocks when seeking budget approvals. When you’re only permitted to budget so much for your project, you could miss out on valuable hardware and software upgrades that could improve your system and optimize team performance.

A workaround, of course, is to budget for these upgrades on a regular basis. However, you’ll also need to make sure the system stays visible and doesn’t fall behind other systems your executive team deems a higher priority. If this happens, you could still miss out on valuable upgrades, making your system more susceptible to bugs and crashes.

This quote is just bizarre.

First, a lot of ERP systems look dated to me. I see weak and dated user interfaces, unchanging functionality, problematic functionality, etc.. If one creates a custom system, it is by definition more modern than the ERP system it is being compared against.

Second, a company has a lot of options that just are not being listed in this article. A company does have to develop an ERP system from scratch, which appears to be the assumption of the Panorama Consulting article. One can start (for example) with an open-source ERP application that has quite a bit of functionality and is nearly free. It can then begin to add customizations or other applications to it. This entire article is setting up the logical fallacy of a false dichotomy. One only has the choice between buying an ERP system and creating an entire ERP system from scratch.

Third, even if a company does buy an ERP system, there will still be customizations, so the interpretation of the alternatives available to a company is entirely discombobulated in this article.

The Risk of a Custom ERP?

Any benefits that you might gain from custom ERP software will soon be overshadowed by the risks of this type of solution.

Not only is a DIY system time-consuming to create and roll out, but it can also be more expensive as you add customizations. You also risk losing institutional knowledge if a key employee leaves or changes job roles. 

Commerical ERP systems are time-consuming to create and roll out. With the cost and time overruns of ERP vendors and consulting companies, is ERP really in the position to be throwing stones at other options? ERP vendors often partner with corrupt consulting companies (in return for recommendations) that provide false information to the account, gouge the customer, and lengthen the implementation. So the idea that one is safe and “managing risk” if one buys a commercial ERP and uses a major IT consulting firm is quite ludicrous. In fact, let us review a quote from another Panorama Consulting firm article Lessons Learned from the CityTime ERP Failure.

To understand how the CityTime ERP project ultimately failed, let’s start by looking at how it began.

First planned in 1998, it was scheduled to take a total of five years to complete. During that time, a brand-new commercial payroll system would be built. The system would replace the paper timesheets and hand scanners that were currently in use.

One of the leading technology application companies in the nation, SAIC was a natural choice to lead the effort. However, as early as 2005, suspicions arose about a kickback scheme siphoning money from the project.

The scheme, which included wire fraud and money laundering, caused the project budget to skyrocket. Eventually, the total estimated cost to taxpayers was close to $760 million.

In all, 11 people were indicted in the scandal, including top SAIC executives, as well as the city official overseeing the project.

However, the project officially finished in 2011 with only half of those workers using it.

This ERP project took 13 years and had an exploding budget. However, in the previous quote Panorama Consulting stated that the reason to buy a commercial ERP system as to keep risks down. So is Panorama Consulting saying that ERP systems do not normally take far longer than initially planned and cost far more?

Also, I am unaware of any research or even empirical evidence that demonstrates that commercial ERP is less time-consuming than custom development. And again, it is not necessarily either-or. There is good ERP functionality sitting in open source systems, which allows the customer to bypass a conventional vendor and conventional consulting firms. There is little reason not to leverage these ERP systems for that generic functionality. And even if a commercial ERP system is purchased, there will be customizations required.

Its Best to Stick With Vendor Provided ERP Software

In short, it’s usually best to stick with vendor-provided ERP software, especially if you anticipate periods of business growth in the near future.

Sound like you? Then, you’ll benefit from hiring an ERP consultant to help you navigate the ERP selection process. Request a free consultation below to learn more.

Really? Based on this poorly researched, quite ignorant, and financially biased article riddled with false and or non-supported claims?

Who was convinced by this article to actually call Panorama Consulting after reading this article?

Conclusion

This article is typical not only of Panorama Consulting’s articles on ERP but articles on ERP generally. The information contained in this article is a duplicate of what ERP vendors want customers to think is true. If Panorama Consulting is independent of ERP systems, why don’t they seem to have any original ideas?

Why does everything line up with the marketing collateral of ERP vendors? When I see this, it invariably means that the entity has financial conflicts with vendors. And this is the case with Panorama. However, nowhere in this article does Panorama declare these financial conflicts.

The quality of content created around ERP is very poor, with this article being a perfect example of the typical ERP content. The article is littered with obvious, financially biased assertions. It often focuses on convincing prospects that they should not do any custom development and that all the answers can be found “out of the box” with their ERP system. These same claims were first made in the 1980s when ERP systems were first introduced. At that time, no one knew anything about ERP systems, so vendors and consulting companies could say anything they wanted. However, the idea that they are still saying these things has been disproven and that even the advisory firms parrot the same falsified claims is amazing. The very idea that vendors, consulting firms, and software selection advisory firms would still be promoting Business Process Re-engineering after its failure many years ago demonstrates the lack of concern for what is true.