When I got my first car, a used Ford, I expected it to work from day one and take me anywhere, as long as I fuelled it and kept it maintained. That is exactly what happened. Cars are complex machines, but they work as expected for many years and miles. All that complexity is hidden behind a simple user interface comprising a steering wheel, pedals, displays, levers and other controls. Of course, we must learn how to drive and obtain a licence, which can be tough in some countries, and from time to time learn the features and improvements of a new model. Each brand and model offers functions that users can easily configure, such as driving mode, seat and mirror position, music selection and cabin temperature, among others.
Today, no one expects to buy a car the way people did in the early 1900s, when each car was built by hand, one at a time, through slow, meticulous craftsmanship by a team of automotive engineering experts. Nowadays, car makers are responsible for understanding what customers need and want and delivering a fully functional finished product. If something does not work, there is a warranty, authorised dealers handle regular maintenance, and if you have an accident, insurance covers it.
So why do we continue to accept the way enterprise software is delivered today?
We are told to select the best module for each part of our business, add code to make them fit our needs, and set up integrations and three-way matching tools to move data between modules. If something goes wrong, we are told that the software is great and that the fault lies with the users or the company. Imagine if a car maker blamed you for your car not working because the engine and transmission you chose did not fit together, even though both were top quality. Would you pay and wait for a custom-built torque converter, only to be blamed if it still did not work because the part had been wrongly created? Would you accept that?
If you would not, why do we accept being blamed for problems in enterprise software that should not have happened in the first place? And what can we do about it?
The answer is to select an enterprise software platform built the way Henry Ford chose to build cars: with all the required functions already available and fully integrated from day one. It should hide complexity behind an intuitive user interface and be ready to run integrated, beginning-to-end business processes online and in real time, without disruptions or interruptions. It must adapt to your organisation today and to your evolution tomorrow, using business parameters that users can understand, with zero code, and require only reasonable training and certification to operate.
As with a car, enterprise software has its limits. Sometimes you need to connect additional applications to expand functionality and meet business needs. It is like plugging your smartphone into your car’s media centre, adding a toll tag, attaching a trailer or changing the tyres. In the same way, you might add an e-commerce platform, a prospecting CRM or a front-end platform for hospitality, healthcare or banking. With appropriate API connectors and clear instructions, these should be ready to run within a few days.
The modular, customised-by-code enterprise software paradigm emerged in the 1990s, driven by fears of a potential Y2K crash, when available software was immature and incomplete. Most implementations have been limited to Finance and Accounting after years of struggle just to make these functions work, leaving Operations out of scope. It is like accepting a car without seats for half the family because the effort required to fit the front seats was so burdensome and time-consuming.
More than 30 years later, most software providers have retained this model because it is difficult to break away from their origins. Organisations and universities have reinforced and perpetuated the paradigm. It is time to break with what everyone else is doing, stop struggling to run the software, and find the right way to run your business.
Safe travels.
Rafael Funes
LOVIS