Why Enterprise Software Is So Bad, And How Companies Can Fix It
If you work at an enterprise company, whether in telecommunications, automotive, manufacturing, textiles, or another industry, you have probably experienced firsthand the horrors of using your company’s proprietary ERP software.
ERP stands for Enterprise Resource Planning. In plain English, it means a collection of bloated, connected software modules that bring many company functions under one roof. These can include HR, ticketing, purchasing, inventory, sales, ordering, accounting, shipping, and analytics. Together, they allow a company to follow a product through its entire supply and value chain.
It sounds useful when you describe what it is supposed to do. In practice, the ERP dashboard is often filled with long forms containing hundreds of fields. The fields provide little guidance about the information you are expected to enter, and it is easy to lose track of where you are in the process or what you are supposed to do next.
God forbid you need to retrieve information from the system. Be prepared to spend half the day trying to find it. The experience can be so difficult that employees export the information they use frequently into Microsoft Excel just to get their work done.
ERP systems are usually purchased with good intentions. They are supposed to reduce costs, simplify workflows, and automate repetitive work. Instead, they frequently create more work than they save.
To understand the problem, it helps to follow the purchasing and development process inside a large enterprise.
How Enterprise Software Gets Purchased
Someone tells an executive that the company needs to implement a new software system because that is what large enterprises do. It may also happen that the department has a budget it needs to spend. If the money is not spent this year, the budget may be reduced the following year.
The executive, with a bonus or performance target on the line, writes an RFP, which stands for Request for Proposal.
A sales director from an enterprise software vendor picks up the RFP, turns the requirements into a glossy presentation, makes a series of ambitious promises, and offers to take responsibility if everything goes wrong.
The buying process may happen over golf, dinner, presentations, and executive meetings. Eventually, a deal is signed, often in the seven figure range.
The sales director meets the quota, celebrates the deal, and moves on to pursue the next opportunity. The sale is complete. What happens during implementation is now someone else’s responsibility.
What Happens After The Sale
The project moves to research and development. The architects, designers, and developers working on the corporate ERP system may have little influence over what gets built or why. Their responsibility is to deliver the requirements that arrived from above.
They are building for the buyers rather than the users. The people who approve and pay for the software may never have to use it in their daily work.
Dedicated UX teams are often absent from enterprise ERP projects. Requirements can travel from someone who does not fully understand every operational workflow directly to the programmers expected to implement them.
The programmers rarely get to speak directly with the employees who will use the system. They may never hear their requests, complaints, or descriptions of how the work is currently performed.
There are also few incentives for experimentation. Backward compatibility, old integrations, and legacy maintenance can make changes expensive and risky. Combined, these conditions make the work repetitive and discouraging for developers.
Despite all of this, the system gets built because project managers need to meet deadlines. Developers are pushed to deliver what was requested, avoid breaking legacy features, and stay within the agreed scope. User experience and innovation are treated as optional concerns.
Why Vendors Can Get Away With It
The software vendor usually handles the integration of its own products. This gives the vendor little incentive to make implementation easier for anyone else.
Enterprise systems also create high levels of customer lock in. Replacing them can require years of planning, data migration, retraining, and operational disruption. Competitors face enormous barriers to entry, so the pressure to improve is limited.
And here you are, the customer, using another grotesque ERP system that was forced on you by management.
Corporate software becomes software that nobody cares about enough: not its creators, not its investors, and certainly not its users.
The employees who eventually figure out how to use the system may become attached to it. Their knowledge makes them important and difficult to replace. Once they have become indispensable, they may have little interest in seeing the process change.
Here is another thought. Enterprise software can be so difficult to use that it becomes good for the economy. Multibillion dollar consulting industries exist largely to help companies implement, configure, maintain, and understand it.
Enterprise vendors remain stuck in a cycle of releasing mediocre, difficult software because they want to continue earning revenue without disrupting their legacy codebases. This would appear to create an opportunity for smaller and more adaptable companies.
Enter The Startups
Instead of pursuing opportunities in purchasing, logistics, inventory, or other core enterprise functions, generations of talented technology graduates spend their time trying to create the next Instagram.
Many gifted developers and designers have little interest in working on enterprise software. They do not want to spend years building something they would never use and have no personal connection to.
The sharing economy adds another disadvantage. When someone builds a consumer application, their friends and family can see and use the work. When someone improves an internal enterprise purchasing module, almost nobody outside the company will ever know it exists.
Again, the developer asks, “What is in it for me?”
Venture capital firms could help redirect attention toward enterprise innovation. Instead, many chase fashionable categories and search for the next artificial intelligence, green technology, financial technology, marketing technology, or social technology unicorn.
Have you ever heard someone enthusiastically discuss EnterpriseTech or, God forbid, ERPTech? Those terms can sound almost blasphemous on Planet Startup.
If enterprise vendors cannot escape the status quo, and the startup community is busy chasing the latest unicorn category, how do we move forward?
A New Breed Of Innovative Enterprise Customer
Instead of placing the full responsibility for innovation on enterprise vendors or startups, why not place more of it on the enterprise customer?
No amount of technical brilliance can compensate for missing domain knowledge. The people inside the company understand how the work is performed, where the delays happen, which exceptions occur, and which procedures exist only because the current software requires them.
A new type of enterprise customer is beginning to challenge rules that no longer serve the business.
These customers have management teams with a genuine interest in making the company more efficient and improving the employee experience.
They want employees to spend less time on overhead, repetitive administration, and unnecessary paperwork. They want to move more of that time toward revenue producing work, customer service, sales, marketing, and product development.
They create teams made up of customer and vendor representatives who work together to design the system.
They include employees from every affected department. These employees will eventually use the software, so they provide feedback during each stage of the design. The company builds support for the process before moving to the next phase.
Some people may consider this a pipe dream.
I do not.
What Smaller Companies Can Learn From Enterprise Software Failures
Large enterprises can absorb years of implementation work, expensive consulting contracts, and complicated software decisions. Smaller companies usually cannot. A poor technology choice can consume a large part of their budget, distract the team, and leave them dependent on a vendor they do not know how to manage.
The lesson is not that every company should build custom software. The lesson is that companies should understand the workflow before choosing the technology. They should involve the people who perform the work, question unnecessary steps, define what success looks like, and evaluate whether a proposed system will make the company easier to operate.
Smaller businesses also need someone to examine the wider picture. A developer may focus on implementation. A software vendor may focus on selling its platform. An agency may focus on delivering the agreed scope. The company still needs someone on its side who can connect business priorities with technical decisions.
What problem are we trying to solve? Who will use the system every day? Which steps can be removed? Which information needs to move between departments? What will this cost to operate after launch? How difficult will it be to change vendors later?
These questions apply whether a company is replacing spreadsheets, connecting several SaaS products, automating an internal process, or building its own application.
This is also one of the areas I plan to address through my upcoming Virtual CTO program, created for founders and growing companies that need occasional senior technical guidance before making expensive software, vendor, or product decisions.
The best time to question a technology decision is before the contract is signed and before the company has built its operations around it.