The Hidden Cost of Automation: Why Quick Fixes Fall Short in IT

I see this tendency of services of “automation” arising from newbie non-IT people without proper knowledge of CTO risk management and the consequences of long-term project success.

What do I mean? More and more people suggest, “Hey, let’s do a corporate solution without custom programming, just using Shopify or five different apps as a result of Frankenstein.”

It is because it does not need programming and is quicker because you do not need to create custom adaptations. Is this really true?

Let’s imagine a situation where you try to save money on marketplace integrations. To do that, you choose to save money and use out-of-the-box shop solutions to gather them because the integrations are already made. It seems cheaper, easier, and done!

Then you spot that you do not like administration and there is no easy and massive product administration in the system. Instead of just adding this functionality to the current system, you create another integration with the cloud-based system to solve the massive administration issue. That’s like every time you need something more, instead of scaling, you add a new third-party app.

The result? One shop system without real e-commerce just for integrations. Three third-party modules are installed on the e-commerce site. One custom-made integration is needed to fill all the data into the system. One SaaS system that you depend on now just for better administration. This means that if they change how the system operates, no one asks if you like it or not; you need to adapt.

What could we have here? Here, we could have one PIM system specified for this problem-solving. Yes, the integrations would cost double or triple that, but ultimately, our solution is independent of any third-party service. We also have one dashboard (easier to maintain, more straightforward to teach newbies, processes are transparent), and we can scale this project quickly because there are fewer dependencies. After all, there are no unnecessary integrations that we need to have in mind and usually change every time we think of a new project feature.

Let’s get deeper.

First, the problems start with having almost five different (administrative, e-commerce, data sources, etc.) dashboards and integrations in between. What does this mean? If you have five dashboards and the employees change statistically every two years, you either need to have a hell of good documentation and someone who will explain to every newbie how this Frankenstein works, or it will eventually die because no one remembers and understands how it works anymore.

Secondly, every non-IT or junior project manager or analyst should understand that every integration is an IT risk in the long haul. What does it mean? This means that integrations are changing, and integrations tend to need additional time to test and double-check. So you might calculate the integrations quantity and double this number to get how risky your project becomes: more integrations, more maintenance, more daily questions like “why did this price come this and not that,” etc.

Thirdly, the problem lies with the people who set up these Frankensteins. They usually need to stay on the project longer to see if their product works and solves the issue with the promised low cost. These people measure success by saying, “Hey, it is possible; look what I have done.” However, real IT project success is not measured by the first initial phase but by the 3 or 5 years of maintenance and scalability. I’ve seen many situations in which Frankenstein dies when the creator leaves the company.

Fourthly, suppose you succeed, and the startup project succeeds. In that case, it is only when this Frankenstein becomes so hairy and nasty that you will start thinking about how to simplify everything. You will get back to the custom solutions, one system, one dashboard, and custom programming, because you will learn and understand how you want to have the process, and usually, to do the process how you want, requires custom programming and not adapting third-party apps with their restrictions. This means if you spent the money correctly in the first place, you would just need to scale, and if you are able to redo everything, you will waste time just laying a new process again and increase the risk of re-making.

In conclusion

Automation with no programming or cheap monthly fee-based solutions is an excellent start for the project, like Excel is a great start for any process. This is also a success if you own that startup, and you will not leave the company or the process you built with it.

However, my expertise shows that this is different for big corporate companies with changing project managers, CEOs overwhelmed with lots of other work and lacking attention, and companies that hire outsourced programmers and need to be efficient.

For corporate companies based on IT risk management, scalability, and maintenance, a proper system with programming will save money over 5 years and will save a lot of headaches.

My suggestions: avoid the trap of an easy, almost free setup, which can result in long-term headaches and the risk of redoing everything again in just a year or two.

What is your opinion?