“Digital transformation” has been said so many times, by so many people selling so many different things, that it has nearly lost its meaning. Strip away the conference-stage version and there’s a genuinely useful idea underneath: deliberately improving how your business runs by fixing the processes and systems that hold it back. Here’s digital transformation as practical work, not a slogan.
It’s About Problems, Not Technology
The failed transformations start with technology — “we need AI,” “we need to be on the cloud” — and go looking for problems to justify it. The ones that work start with a real business pain: orders take too long, customers wait on hold, staff drown in manual data entry, leadership can’t get a straight number. Technology is how you solve those, once you’ve named them. A transformation with no specific problem it’s solving is just spending with extra steps.
Fix the Process First
Automating a broken process just makes it break faster. Before layering software onto how work happens today, it’s worth asking whether the process itself still makes sense — steps that exist only because “we’ve always done it that way,” approvals that add delay but no value, work done twice. The biggest gains often come from simplifying the process, then supporting the better version with the right system. Digitizing waste is still waste.
Go Incremental, Not Big-Bang
The dramatic “transform everything at once” program is where budgets and morale go to die. Real transformation is a series of deliberate improvements, each delivering value on its own: fix the worst bottleneck, prove the gain, build momentum, move to the next. This keeps risk low, lets you learn as you go, and means you’re never betting the whole company on one enormous project. Progress you can see beats a promise you have to wait years to test.
Bring People With You
Every transformation is ultimately about people changing how they work, and people don’t change because a new system arrives. They change when they understand why, when the new way is genuinely better for them, and when they were part of shaping it. The technical work is usually the smaller half; the human work of adoption is what determines whether any of it sticks.
OneStopSoft approaches digital transformation as pragmatic, problem-first work — process before technology, incremental over big-bang, people brought along. Tell us what’s holding your operations back and we’ll help you fix it, one worthwhile step at a time.
Turning a Named Problem Into a Measured One
A named problem is not yet a measurable one. "Orders take too long" becomes actionable when you pick the trigger event and the completion event, pull the elapsed time between them for the last few hundred records, and look at the distribution instead of the average. The median describes the normal case; the 90th percentile describes the case the customer complains about, and the two often call for different fixes. Separate elapsed time from touch time while you are there. If an order takes six days and forty minutes of that is anyone actually working, automating the forty minutes moves almost nothing. The six days are queue time, and queue time is created by handoffs, batching and approvals, not by typing speed.
Most business systems do not retain the history that measurement needs unless someone switched it on. Field-level change tracking is opt-in in most CRM and ERP platforms and is usually capped: a set number of tracked fields per object, retained for a bounded window, with older entries aged out. Auditing in Dynamics 365 is enabled per table and per column. Versioning on a SharePoint library is a setting with a version limit, not a guarantee. Turning on status history or an audit trail before anything changes is the only version of "before" you will ever get. Without it, every claim about improvement afterward is an argument between memories.
- Ticket and case systems already stamp created, first response, each status change and closed. The created-to-first-response gap is usually the one customers actually feel, and it is rarely the gap anyone reports on.
- CRM records carry creation and activity timestamps, but time-in-stage is derived from stage change history rather than stored. With history off, that number does not exist retroactively and cannot be reconstructed.
- In ERP, the gap between document date and posting date measures how long paperwork sits before it enters the system. A wide or widening gap is a queue, not a data entry skill problem.
- Where the line-of-business system records nothing, shared mailbox timestamps and document version history give an approximate trail: when the quote was first drafted, how many revisions it went through, how long it sat between them.
Choosing Which Increment Goes First
In practice several processes are all plausibly the worst, and the argument about which one is worst is unwinnable in a meeting because each department is measuring its own pain. Four questions settle it faster than debate, and three of the four are answerable in an afternoon.
- Can you draw a boundary around it? One trigger in, one finished state out. A process that hands off into three other departments mid-flow and comes back is not one increment; it is a program wearing an increment's clothes, and it will be scoped as the small thing and delivered as the large one.
- Can you get a before-number out of systems you already run? If establishing the baseline requires a stopwatch study, the gain will be unprovable, and an unprovable gain does not fund the step after it.
- Is there one person who can delete a step? Simplification means removing approvals and handoffs, which requires someone with the authority to remove them. A process owned by committee can be re-implemented but not simplified, and re-implementing it is how you spend the budget without changing the cycle time.
- What reads the output? A faster process that emits a differently shaped record pushes work downstream into whoever consumes it. List the reports, integrations, and people reading that output before you change its shape, because they will not tell you until the month-end number is wrong.
How Each Approach Fails
Configuring a package, building something custom, integrating what you already own, and changing the process without changing any system are all legitimate answers. Each fails in a characteristic way, and the failure typically surfaces a year after the project closes rather than during it. The shape of the failure is more useful to know than a general warning about risk.
- Package configuration fails by exception. The eighty percent that fits is not the problem. The cases that do not fit get handled in a spreadsheet beside the system, and within a year that spreadsheet holds facts the system does not. It also drifts: each configuration that becomes a customization is something to re-validate at every major release, and the accumulated set is what makes upgrades expensive.
- Custom builds fail by ownership. They tend to work well and fit exactly, right up until the person who understood the code changes roles. There is no vendor release note, no upgrade path someone else maintains, and no community that has hit your bug already. The real cost is not the build, it is maintenance nobody put in a budget line.
- Integration fails at the seams. Two systems each keep a copy of the customer, there is no agreed key linking them, sync direction is unstated, retries create duplicates, and the error queue is a mailbox nobody reads. Reconciliation quietly becomes a permanent part-time job, which is exactly the manual work the integration was supposed to remove.
- Process change with no system change fails by decay. It works for a quarter because attention is on it, then reverts, because nothing in the tooling makes the new sequence easier than the old one. If the improvement depends entirely on people remembering, assume it lasts as long as the memory does.
- Lock-in is not mainly about data. Most platforms will export your rows. What does not export is the logic: validation rules, approval routing, calculated fields, permission models, the report definitions people actually run. Ask what a migration off this would carry with it, and what would have to be rebuilt from scratch, before the answer is expensive.
Applying These Principles to Harder Cases
Process before technology, incremental over big-bang, people brought along: these hold as defaults, and the harder cases are about how you apply them, not whether you do. Four situations where the application needs more care than the rule alone gives you.
- Sequencing the worst bottleneck. When the worst bottleneck is also the least documented part of the business, no credible estimate for it exists yet. Taking a smaller adjacent process first is not a detour: it builds the measurement habit, the system access, and the working knowledge of the data that make the bottleneck's estimate believable when you reach it.
- Cutover inside a single increment. The warning about big-bang is about the whole company changing at once, which is a different question from how one step lands. Where two systems hold the same records and one is replacing the other, parallel running means dual entry or dual write, and reconciling two copies that drift apart is its own failure mode with its own defect rate. For that one pair of systems, a short cutover with the old system kept readable is sometimes the lower-risk option, and it is still one increment rather than a program.
- Instrumenting is not automating. Sometimes the current process cannot be described accurately because nothing records it and every account of it differs by role. Recording the steps (status stamps, a visible queue, a shared log) does not entrench the waste the way automating it would; it produces the evidence for which steps to delete. Simplify with that record in hand, then support the simplified version.
- Configure or build. Configuration wins where the process is ordinary and the value is in doing it reliably: invoicing, expense approval, standard onboarding. Where the process is the thing the business actually competes on (a pricing rule, a dispatch model, an inspection workflow customers notice), forcing it into a package's shape trades away the difference to save configuration effort. The question is not which is cheaper to stand up, it is which one you will still be able to change in three years, and who will be able to change it.
Frequently Asked Questions
How do we tell whether it actually worked?
The measures that hold up are elapsed cycle time from trigger to completion, the 90th percentile alongside the median, the rework rate (records touched more than once), the exception rate (cases that left the standard path), and adoption. Compare them against the baseline you captured before anything changed. Adoption is the one most often skipped and the one that invalidates the rest: a process where sixty percent of the work goes through the new path is running two processes, and any report drawn from it describes only the compliant half. A change that improves the median while doubling exceptions has moved work rather than removed it, which is why both numbers have to be read together.
Do we need a process map before we start?
Not a map of the whole business, which is a project in itself and stale before it is finished. What is needed is one process mapped at the level of who touches it, what they wait on, and where the authoritative record sits at each step. Two things make that map accurate: walk one real record end to end instead of describing the intended path, and ask every person what they do when the standard path does not apply. The exception path is where most of the elapsed time lives, and it is almost never in the documented version.
Can we test the decision before committing to it?
Usually, and cheaply. Run the intended sequence manually for one region, one product line, or one customer segment using the tools you already have; if the sequence itself does not hold up when a person performs it, no software will rescue it. For integration work, build the read-only half first, because reading from a system surfaces the data quality problems (missing keys, duplicate customers, free-text fields where a code was assumed) without any risk of writing bad records. If you pilot in a vendor sandbox, remember that sandbox data is typically masked or subset, so the malformed real records that break integrations are the ones missing from it.
Our vendor says the next upgrade fixes this. Does it?
An upgrade changes what the software can do. It does not change the sequence of steps people follow, who has to approve what, or how long a request waits in someone's queue, so if the delay is queue time the upgrade will not touch it. Upgrades do reset one specific debt: customizations written against the old version have to be re-validated, and that is the natural moment to ask whether each one is still earning its place. Treat the upgrade as an opportunity to remove accumulated configuration, not as the process fix itself.
Where does AI fit into any of this?
Useful AI over your own business data has the same prerequisites as everything else on this page. Content has to be in known locations, permissions have to reflect who should actually see what (retrieval inherits the permission model, so an over-shared library becomes an over-sharing assistant), and there has to be one current version of a document rather than five near-identical copies across a file share, a mailbox and someone's desktop. Retrieval returns what matches the question, not what is correct: with three versions of a policy in scope, the answer will cite whichever one most resembles the wording of the question. That groundwork (document management, permissions, retention, consolidating duplicate storage) is work worth doing regardless of whether anything is layered on top of it.
How do we keep the new system from becoming the next thing people work around?
Workarounds start wherever the system refuses a real case, so make the exception path visible instead of pretending it does not exist: an exception log, a status meaning handled outside the system, or simply asking what the spreadsheet open beside the screen is for. Keep one system of record per fact and make the others read it; when two systems both accept edits to the same customer address, staff learn which one is really right and the other quietly decays. And give configuration changes a named owner and a route, because a request with nowhere to go becomes a private spreadsheet within a month.