Organizations are surrounded by software.
Project management platforms. CRMs. ERPs. Workflow engines. Collaboration tools. AI assistants. Automation platforms. Dashboards for almost everything.
And yet, adding another tool does not necessarily make an organization more productive.
This distinction is becoming increasingly important.
Software is becoming cheaper, faster and easier to build. AI is accelerating implementation even further.
The scarce resource may therefore no longer be the ability to create software.
The Spreadsheet Is Often Not the Problem
Consider a familiar situation.
A department runs a critical operational process using a large spreadsheet.
Someone proposes replacing it with a sophisticated web application.
The proposal sounds reasonable.
The spreadsheet is slow. Multiple people edit it. Data is copied between sheets. Errors occur. Nobody likes maintaining it.
So the obvious conclusion is:
But before building one, a better question might be:
The answer can reveal something much more important.
Perhaps the official enterprise system does not contain a piece of information required by the people actually doing the work.
Perhaps the approval process changed six months ago, but the official workflow never changed with it.
Perhaps employees created the spreadsheet because the formal system no longer reflects reality.
It may be evidence.
Evidence that the organization's formal model of work and its actual operating model have diverged.
The Automation Trap
This creates a dangerous pattern.
An organization discovers friction.
Technology is proposed as the solution.
The existing process is translated into software.
The organization then becomes very efficient at executing a process that was never actually correct.
It can make bad logic faster.
This is why digital transformation projects sometimes produce surprisingly little transformation.
The organization digitizes its existing assumptions instead of questioning them.
Two Paths: Automate the Process vs. Understand the System
Consider another fictional thought experiment. It is illustrative, not an OSENIX client case study.
A company asks for a multi-department project management portal.
Start with the requested software.
The team compares project-management platforms.
They design dashboards, status tags, approval workflows, notifications and integrations.
The implementation is successful.
Everyone now has a beautiful new system.
Six months later, the organization discovers that projects were rarely blocked by a lack of visibility.
They were blocked because nobody had clearly defined who was responsible for approving a project handoff.
Start with the broken interaction.
Before discussing technology, the analyst asks:
“What specific agreement is failing between Team A and Team B before a project can move forward?”
Interviews reveal that the real problem is not visibility.
It is an ambiguous approval boundary.
The first intervention is therefore much smaller: clarify the responsibility, define the handoff and make the decision rule explicit.
Only then does the team determine which parts actually deserve automation.
The second approach may initially produce less software.
But it can produce a much larger improvement in the system.
The difference is not technology versus no technology.
Understanding Always Comes Before Automation.
This does not mean organizations should stop buying software. It means software should enter the conversation after the underlying problem has been made sufficiently clear.
A system is more than its software.
It includes people, responsibilities, decisions, incentives, information, constraints, handoffs and feedback loops.
Change the software without understanding those relationships and the organization may simply create a more sophisticated version of the same problem.
The goal of technology is not to digitize everything. It is to improve the system that produces the outcome.
Before You Automate the Next Process
- The Reality Test. How does the work actually happen today — not how does the official process document say it happens?
- The Constraint Test. Where does the process actually stop, slow down or create costly rework?
- The Automation Test. If we removed the software request entirely, what underlying rule, decision or interaction would still need to change?
“What software should we deploy?”
Start asking:
“What system are we actually trying to improve?”
Better Thinking.
Better Systems.
Better Decisions.
What process in your organization have you been trying to automate that actually needs to be understood first?