You know this moment from board meetings. A wave of frustration goes through the company: the sales team complains that the CRM "crawls", the warehouse has lost an important order again, and accounting asks for the hundredth time to have invoices corrected by hand. Then someone says the magic sentence:
"Our current system is holding us back. We need a modern ERP. That will finally force people to work in an orderly way."
Decisions get made. You pick a reputable vendor, and the budget runs to hundreds of thousands of zloty. Twelve months of exhausting implementation go by. And what do you find after the big launch?
The company has spent a fortune on enterprise-class software, and the staff still quietly export data so they can work in their own private Excel sheets. The logo on the login screen has changed. The problems with information flow and the operational errors are exactly the same.
According to hard market data (including research by McKinsey and Gartner), as many as 70% of digital transformation projects fail to deliver the business results they promised. Why? Because companies keep falling into the oldest trap in IT: they confuse buying software with solving an organisational problem.
Software doesn't cure dysfunction. It exposes it
The truth I often have to put to CEOs and directors is brutal: technology is not a manager. It won't fix a lack of competence, blurred responsibility or missing procedures.
IT vendors sell licences, not a well-organised business. A typical implementation firm asks, "Which fields do you want on the form?" instead of the basic engineering question: "Why does this document have to travel between three different departments at all?"
Say your information flow is chaos: a salesperson has to phone the warehouse to find out whether the goods physically exist, and accounting retypes data from PDFs into the finance system by hand. Then the most expensive software on the market won't help. All it does is digitise your own mess.
In business process engineering I have a simple definition for this: digitising chaos just means making the same mistakes, only much faster and for a lot more money.
A real case: the system that wanted 25 fields filled in
Let's come back down to earth with a real, anonymised example from a Polish B2B company that came to me after a "failed implementation".
The company had a dramatically long handover time between the salespeople, who closed the deals, and the delivery department. The board's diagnosis: "We lack a tool, everything gets lost in email." They bought licences for an advanced document workflow system. The implementation cost tens of thousands of zloty. The result? The process got even slower, and the open conflict between departments got worse.
When I walked into the organisation as iStrus Advisory to run an audit, I found the real source of the problem. The new, "rigid" system had been designed around what the board wanted. It required a salesperson to fill in as many as 25 hard data points on a form (exact dimensions of the shipment, detailed conditions for getting a lorry onto the building site) before the system would even let them click "Hand over to delivery".
The catch was that when a deal closes, the salesperson knows the answers to only 5 of them. The technical team works out the rest much later.
What did the people on the front line do to save their bonuses and keep things moving? They created Shadow IT, the IT grey zone. To push a deal through, they typed random strings into the form ("123", dots, "no data"), anything that let the program move to the next step. The delivery department got an "empty" project with nonsense data in the shiny new system and... still had to pick up the phone and ring the salesperson to ask for the details.
The company spent a fortune on software that added pointless work for its people. The foundation was ignored: the process itself was never standardised, and nobody had settled who needs which data, and when. They tried to patch an organisational, procedural hole with an expensive IT plaster.
Why a ruthless diagnosis is Step Zero
In a mature enterprise IT architecture, nobody writes a single line of code before the business logic has been mapped. Before you pour the concrete for a tower block, you need geological surveys and the architect's drawings. Implementing operational systems in a company has to work exactly the same way.
So before the name of any software comes up, whether an off-the-shelf SaaS product or a custom-built application, you need an engineering diagnosis. You have to take your company's operating engine apart, piece by piece:
Down in the trenches (mapping the As-Is state)
How a process looks on paper in the CEO's office almost always differs sharply from how it looks at the workstations. I draw the actual flow of data. I look for "tribal knowledge": situations where the company keeps running only because Basia from admin remembers every exception to the rule.
Surgical cuts and paying down process debt
If approving a trivial 500 PLN expense invoice in your company takes sign-off from three directors, I don't automate that broken workflow. I cut it first and change the procedure. Only the shortest, leanest, repeatable processes go into the system. You don't negotiate with machines. They need iron logic.
Breaking down data silos
Often, after the diagnosis, it turns out the company doesn't need to replace its whole ERP and burn hundreds of thousands of zloty. Instead of a revolution, it's enough to build a clean integration (say, a data bus over API) between two programs you already use, so nobody has to copy and paste data by hand any more. The time saved? Hundreds of working hours a month.
Don't buy blind. Build the foundation.
Buying an IT licence is the easiest part of business. You sign the contract and pay the invoice. The real engineering starts where you have to organise the company so that technology becomes a powerful lever for scaling, not a ball and chain forcing people to "click rubbish".
If there is strong pressure in your company to change software, stop that train for a moment. Don't buy technology just to put out operational fires. Turn away any IT salesman who wants to sell you the system without first going through the fabric of your procedures with a magnifying glass.
Take a step back. Have a look at what I do to see how I map and audit business processes at iStrus Advisory. Let's first build a healthy, well-ordered organisation on paper, and only then pour an intelligent IT architecture into it.
Otherwise, a year from now you'll hear it in the boardroom again: "This system is hopeless, we need a new one."
How does your organisation approach IT implementations? Do you diagnose the processes first, or go straight to looking for a tool? Tell me on LinkedIn.
