You’ve found a broken business process. Approvals stall in email. Status lives in a spreadsheet someone forgets to update. A request bounces between three systems that don’t talk to each other. The instinct is to go buy software. The harder question — the one that separates a successful project from an expensive one — is whether you need new software at all, whether you need to redesign the work, or both.
This framework is for the people who own that decision: IT, operations, and digital-transformation leaders who get held accountable for the result. It draws on a classic HDI white paper by Roy Atkinson, Process and Tool, Chicken and Egg, which laid out six steps for selecting technology tools. The steps hold up. What’s changed is the answer most organizations reach at the end of them — because you no longer have to choose between living with broken processes and replacing the systems underneath them.
1. Get the right people involved
The first step is the one teams are most tempted to skip. Staff at different levels and in different departments each see a different slice of the process, and the gaps between those slices are usually where the breakage lives. Pull them together before you scope anything.
One job for this group is financial justification. As Atkinson put it, “Business leaders will want to know the value that any change will provide, especially when it will require a substantial investment of money, resources, and time.” Decide up front how you’ll quantify that value — labor saved, cycle time cut, errors avoided — so the business case writes itself later.
The other job is finding a sponsor who can absorb the organizational friction. “Entrenched behaviors can erect barriers at every level,” Atkinson noted. “You’ll need someone to help overcome this resistance.” The most reliable way to disarm that resistance is to avoid a big-bang rollout. Ship a series of small, visible wins that prove value to skeptics before you ask anyone to change how they work.
2. Ask the right questions before you start
Before evaluating a single product, answer two questions plainly: what problem are we actually solving, and why does that require new software?
“If the answer is ‘our tool doesn’t do what we need it to do,’” Atkinson wrote, “then you need to lay out the unmet needs carefully and completely so that you don’t make a mistake when you buy new technology.” Vague requirements are how organizations end up paying for a platform that solves a problem they didn’t have.
This is also the moment to challenge the rip-and-replace reflex. A lot of process pain isn’t a system-of-record problem at all — it’s the manual handoffs, the missing visibility, and the dead space between systems. You rarely need to replace the systems that hold your data to fix that. You need a layer that coordinates work across them.
Most broken processes aren’t broken systems. They’re the gaps between systems that nobody owns.
3. Define your processes before searching for tools
Define what “fixed” looks like before you go shopping. Start with the end in mind: what would this process look like if it worked perfectly for the person on the receiving end — the employee, the citizen, the customer — and for the organization running it?
Then do a gap analysis between today’s process and that target. “This gap analysis can point out where you can best leverage technology,” Atkinson advised, “and where you can make changes to current processes and procedures to achieve your goals.” Some of those gaps close with better process design and no new software. The ones that remain — the cross-system steps, the routing, the approvals — are your real requirements.
4. Find the hidden expenses
The sticker price is the cheapest part of most software decisions. The expensive parts hide: skills gaps that turn into training programs, outside consulting to stand the thing up, and — the big one — customization.
Heavy customization is a recurring tax, not a one-time cost. Every modification you bury inside a system of record is something you have to retest and often rebuild at the next version upgrade. The way out is to keep your changes at the experience and orchestration layer rather than in the underlying applications. Configure the workflow, the forms, and the user interface; leave the systems of record alone. Changes made above your core systems survive upgrades. Changes made inside them do not.
5. Decide whether to customize — and where
Customize your processes, or customize the software? It’s an uncomfortable question because it forces an honest look at your own operation. Most enterprise software is built around industry best practices. If your process is messier than the leaders in your field, adapt your process — don’t pay to enshrine inefficiency in code. But if your process is genuinely better than what the software assumes, that’s a real competitive edge worth preserving.
There’s a cost either way. “Customization can be very expensive,” Atkinson noted, “but large organizational changes are themselves not inexpensive.” The useful reframe is to separate where the customization lives. Fitting work to a rigid system means changing how your people operate. Fitting the system to your work usually means brittle backend code. A third option avoids both: orchestrate the process in a layer that sits on top of your existing systems, so you keep the workflow you want without modifying the systems of record beneath it.
6. Have a plan for measuring success
Decide how you’ll measure results before you implement, not after. Ideally the platform itself produces the analytics — every step timestamped, every action logged — so you’re reading a record instead of reconstructing one.
Operationally, track time saved, manual steps eliminated, support requests reduced, and user satisfaction improved. For leadership, translate those into money: the labor cost of a support call avoided is easy to count; the value of a process people no longer route around takes more work to quantify but is often larger. A platform that logs execution by default makes this measurement a byproduct of running the work, not a separate reporting project.
Where this leads in 2026
These six steps were never meant to pick a winner from a shortlist of competing apps. They’re meant to give you a solid foundation: define the process, isolate the real requirement, and avoid paying for the wrong thing.
Run them honestly and most organizations land in the same place. The systems of record — the ERP, the ITSM tool, the HR system, the identity directory — are usually fine. The pain is in the manual coordination across them. That’s exactly the problem a workflow orchestration platform is built to solve.
Kinetic is an enterprise workflow orchestration platform that acts as a modernization layer: it sits on top of the systems you already run, orchestrates work across them, and gives users a unified experience — without replacing anything underneath. That’s how you fix the process without the rip-and-replace project. It’s also why this approach holds up in the most demanding environments; Kinetic carries an IL5 authorization and more than twenty years in defense and government, where deterministic, auditable execution isn’t a feature request but a requirement.
It’s also where AI fits, on the right terms. Build with AI: use it at design time to draft workflows and accelerate configuration. Run with Kinetic: let AI participate as workflow steps that classify, extract, recommend, and summarize, while the engine executes the routing, approvals, and fulfillment deterministically. AI advises. Humans decide. Workflows execute — repeatably and on the record.
If your honest answer to step two is “we need to coordinate work across systems we’re not replacing,” see how the Kinetic platform works, browse real-world use cases, or look at customer outcomes to pressure-test it against your own process.
Share this article