Discover how continuous software improvement fuels business growth and innovation with agile methodology and technology advancement strategies.
Most businesses treat their core systems as infrastructure. Something implemented once, then maintained, then eventually replaced. It sits in the background like the plumbing, and attention goes to it only when something breaks.
That framing was reasonable when software genuinely was static, and it is now a competitive disadvantage. Platforms update continuously, capability arrives without anybody buying it, and businesses that treat their systems as finished are steadily accumulating a gap between what they are paying for and what they are using.
This article covers what continuous improvement actually looks like operationally, and why it produces more than the occasional project.
The pattern is recognisable. A business implements a system, goes live, the project team disperses, and the configuration is treated as settled.
Change requests then arrive as exceptions rather than as normal. Each one is a small project requiring a decision, a budget and somebody's attention, which means most of them do not happen.
Meanwhile the business changes. New products, new channels, new entities, new processes. The system reflects the business as it was at implementation, and the gap widens.
People close that gap themselves, with spreadsheets and workarounds, because they have work to do. Within a few years the operation runs partly on the system and partly on a layer of informal process nobody designed.
The system did not fail. It stopped being improved, which produces the same result more slowly.
The specific reason this matters more than it used to is that cloud platforms deliver capability continuously.
NetSuite releases twice a year, applied to every account. Each release contains functionality that is included in what you already pay for, and that a business receives whether or not anybody notices.
Businesses that never read release notes therefore accumulate two problems. They do not adopt things that would help, and they continue maintaining custom solutions to problems the vendor has since solved natively.
That second one is the more expensive. A script written three years ago to fill a gap that no longer exists still needs testing at every release, still needs maintaining, and still constrains what else can change.
An hour spent reading each release with your own account in mind is one of the higher return activities available and one of the most consistently skipped.
The phrase suggests a programme, and the useful version is considerably smaller.
It means somebody is responsible for the system rather than for projects on it. Somebody who notices when a process has become awkward, who reads the release notes, who knows what people are working around.
It means change requests are normal rather than exceptional, with a light path from somebody having a problem to it being addressed.
It means a small ongoing budget rather than an occasional large one, because a modest continuous spend produces more than the same amount concentrated into an eighteen month project.
And it means a rhythm of review, so improvement is scheduled rather than dependent on somebody raising it.
Businesses that do this well have several sources feeding it, rather than relying on requests.
Support requests are the most useful and the most underused. What people ask about is a direct measure of what is unclear, awkward or missing, and a recurring question is a systematic problem rather than an individual one.
Workarounds are the second. Every spreadsheet is a statement of an unmet requirement, and cataloguing them once produces a substantial improvement backlog.
Release notes are the third, read with the account in mind rather than in general.
Watching people work is the fourth, and it finds things nobody reports. People do not raise problems they have solved their own way.
And the deferred list from the original implementation is the fifth, which in most businesses still contains items nobody has looked at.
Improvement programmes fail more often through process weight than through lack of ideas.
The useful ordering is by time returned relative to effort. A change that saves somebody two hours a week and takes half a day to make is obviously worth doing, and it does not need a business case.
Beyond that, prioritise by whether the change removes a workaround, since workarounds carry both effort and data quality risk.
Then by whether it removes a dependency on a person, since that reduces a risk as well as effort.
And then by whether it enables something the business is trying to do, which is where the strategic connection sits.
Where a request cannot be justified against any of those, it usually should not be built, which is a faster conversation than a formal evaluation.
Continuous improvement produces a steady stream of requests, and the discipline that keeps the account healthy is solving each at the lowest level that works.
Configuration before declarative customisation, declarative before code. Each step down the ladder is a maintenance obligation you did not create and a dependency that does not need testing at every release.
A great many requests that arrive labelled as development turn out to be configuration nobody explored, or a saved search nobody built, or a training gap wearing a technology costume.
The check that catches this is asking what outcome the business actually wants rather than accepting the solution somebody has already imagined.
Our piece on when customisation is the right answer covers that judgement in detail.
The practice that distinguishes sustainable improvement from accumulation.
Every improvement programme has an intake process. Almost none have an exit process, which is why accounts only ever grow and eventually become difficult to change.
An annual review of what exists, asking of each customisation whether it is still used, whether the need still exists, whether the platform has since delivered the same thing, and whether it is still the right method, keeps the count roughly stable.
The third question catches the specific and common situation where a custom solution outlived the problem it solved.
Retiring needs the same care as building. Check dependencies, tell people, disable rather than delete initially, and remove properly once a cycle has passed without anyone noticing.
None of this works without somebody who can actually make changes, and that is where most businesses are constrained.
Where every change requires an external engagement with a lead time and a quote, most changes do not get made. The friction filters out everything except the urgent, which means the small improvements that compound never happen.
Where somebody internally can configure a field, build a saved search, adjust a form or modify a workflow, requests become afternoons and the business keeps pace with itself.
Building that capability is usually the highest return investment available, and it is more about time and training than about hiring. Our overview for system administrators covers what the role requires.
Where it will not sit internally, an ongoing arrangement provides it, which is what managed services is for. The important thing is that it exists rather than where it sits.
If a business is going to improve one thing continuously, reporting returns more than anything else.
The reason is that reporting is almost always under built at go live, because transactions are more urgent and reporting is deferred to a phase that does not arrive.
People then meet their needs with exports, and the spreadsheet becomes the trusted version, which is both effort and a data quality risk.
Closing that gap incrementally, one report at a time, moves analysis back into the system where it is shared, scheduled and auditable.
It also compounds, because each report built makes the next question cheaper to answer and demonstrates that asking is worthwhile. Report writing as an ongoing capability rather than a project deliverable is what keeps that going.
Releases are the clearest instance of continuous improvement being available and unclaimed.
The defensive half is well understood. Test your critical processes in the release preview account, confirm scheduled scripts and integrations still run, and know what is changing in the modules you use.
The opportunity half is the one that gets skipped. Read what is new with your own account in mind, identify anything that addresses a known problem, and schedule adoption.
That second activity is where the value is, and it takes an hour by somebody who knows the account well enough to recognise relevance.
Businesses that do this consistently find their customisation count falling over time, because the platform keeps making custom solutions unnecessary.
Improvement work is invisible by nature, since its output is the absence of a problem, and invisible work loses funding.
A short record of what changed and what it returned is what keeps it supported. This report now runs automatically, saving four hours a month. This process lost two steps. This workaround has been removed.
That record also serves a second purpose, which is demonstrating to the people who raised things that raising them produces results.
Where requests disappear into silence, people stop raising them and start working around instead, and the improvement pipeline dries up because the source stopped contributing.
Publicising fixes is therefore not self promotion, it is maintaining the input.
The financial framing that makes this sustainable is treating systems as an ongoing cost rather than a periodic capital event.
Most businesses budget for implementation and then for nothing, which means every subsequent change competes against operational priorities and loses.
A modest continuous allowance changes the dynamic entirely. Improvements happen because there is capacity rather than because somebody made a case.
It also produces better economics. A small continuous spend on a system that keeps pace with the business costs less over five years than the same total concentrated into a large remediation project when the gap becomes intolerable.
And it avoids the pattern where a business runs a system into the ground and then faces a reimplementation, which is the most expensive version of the same requirement.
The case for continuous improvement is mostly the case against its absence, and the absence has a recognisable trajectory.
Workarounds accumulate, and each one carries effort and data quality risk.
Reporting drifts further from what the business needs, so decisions get made on spreadsheets.
Customisations built for a previous version of the business remain, constraining what can change.
The gap between what the platform offers and what the business uses widens, so you pay for capability you never adopt.
And eventually somebody concludes the system is not working and proposes replacing it, when what actually happened is that nobody improved it for five years.
Our piece on the signals that genuinely indicate reimplementation covers how to distinguish that situation from a genuine structural problem.
The entry point is smaller than the concept suggests.
Assign somebody responsibility for the system, with time attached, even if it is a portion of a role.
Catalogue the workarounds once. Every spreadsheet, every manual step, every thing people do because the system will not.
Read the next release notes with the account in mind and identify one thing worth adopting.
Fix the highest return item from the workaround list.
Then set a rhythm, meaning a monthly hour on requests and a twice yearly release review, and keep it.
That is enough to change the trajectory, and the trajectory is what matters over years.
The businesses that get the most from their systems are not the ones that implemented best. They are the ones that kept improving after the project ended, which is a habit rather than a capability.
The useful first step is cataloguing the workarounds, because that list is both the improvement backlog and the honest measure of how far the system has drifted from the business.
Our piece on maximising the value of a NetSuite investment covers the first year after go live specifically, and managed services covers where the ongoing capability sits when it will not be internal.
If your system has stopped keeping pace with your business, get in touch.
