IT Systems Audit& Improvement Review
An independent, evidence-based read on the systems you run today: what exists, what duplicates, what constrains the business, what carries risk — and the order in which to deal with it.
The cheapest engagement we offer, and usually the one to start with.
Organisations frequently arrive certain that a particular system is the problem. Sometimes they are right. Often the constraint sits somewhere else entirely — in a process, in a data quality issue, in a configuration nobody has revisited since it was installed.
A systems review establishes what is actually true before money is committed to changing anything. It looks at the whole landscape rather than one product, because the friction is usually at the joins between systems rather than inside them.
We take no commission from any vendor and we are not trying to sell you a build. If the honest finding is that your current systems are adequate and the difficulty is elsewhere, the report will say exactly that.
Situations that warrant a review.
“We are about to spend a significant sum and we are not certain it is the right thing.”
A review costs a fraction of the decision and frequently changes its shape — sometimes by making the project smaller.
“Everything technically works, but everything takes too long.”
Duplicate entry, manual reconciliation and workarounds are invisible on a budget line and expensive in aggregate. A review quantifies them.
“We have inherited systems nobody chose.”
After growth, staff changes or an acquisition, the estate reflects a series of individual decisions rather than a design. Establishing the current state is the first step.
“Different teams have built their own solutions.”
Departmental tools solve local problems and create organisational ones. A review identifies which to adopt formally and which to retire.
“A supplier has told us we need to upgrade.”
Sometimes accurate, sometimes commercially convenient for them. Independent assessment establishes whether the recommendation serves you.
“We do not know what we would do if that system failed.”
A review identifies dependencies and risk. Where the exposure is significant, it points towards continuity planning.
From current estate to improvement plan.
Findings are separated from risks, and risks from priorities, because conflating them is how review reports become unactionable.
What the review examines.
The scope is agreed in advance. A focused review of one process is a legitimate engagement; so is a whole-estate assessment.
When organisations commission this.
Five stages over two to four weeks.
The demand on your team is modest — typically a series of short interviews and access to systems for observation.
- Stage 01Scoping and accessWhat is in scope, who we need to speak to, and what access is required. Output: an agreed terms of reference so the review cannot drift.
- Stage 02Discovery and interviewsStructured conversations with users at every level, plus observation of the work as it happens. The people doing the work know where the friction is.
- Stage 03Technical examinationConfiguration, data quality, integration points, licensing, support status and dependency mapping for the systems in scope.
- Stage 04Analysis and draftingFindings assembled, risks assessed, recommendations graded. A draft is shared with you so factual errors can be corrected before the report is final.
- Stage 05Presentation and handoverA working session walking your team through the findings and answering questions, followed by the final written report.
What you hold at the end.
- A written review report in plain, non-technical language
- A systems inventory you can maintain afterwards
- Findings supported by evidence and attributed to sources
- A technology risk summary suitable for a board paper
- Graded, sequenced recommendations with indicative effort
- A walkthrough session with your team
And who it is not for.
A good fit
- Organisations facing a significant technology decision
- Businesses whose systems have accumulated rather than been designed
- New leadership wanting an independent baseline
- Boards seeking assurance from outside the operational team
- Anyone unsure whether their frustration is the system or the process
Probably not a fit
- Organisations wanting day-to-day IT support or a managed service
- Penetration testing or formal information security certification
- Hardware, network or infrastructure engineering work
- Anyone seeking a report to justify a decision already made
To be explicit: we will not write a report to support a predetermined conclusion. If you need independent evidence, that independence is the product.
Where a review commonly leads.
Frequently asked.
Less than most people expect. Typically thirty to sixty minutes each with a handful of people, some read-only access for observation, and a nominated internal contact to answer questions as they arise. We work around your operational commitments rather than the other way round.
The report addresses systems, processes and risks — not individuals. Where a supplier arrangement is not serving you, we will state that factually and evidence it, because you are paying us to be straight with you. We do not editorialise about people, and interview contributions are not attributed to named individuals unless you ask for that.
Usually read-only access is sufficient, and it is what we prefer. Where configuration needs to be examined more deeply, we will ask for specific access, explain why, and work under your own security arrangements. We do not make changes to live systems during a review.
Then it says so, and the engagement has done its job. Establishing that current systems are adequate is a legitimate and valuable outcome — particularly where it prevents an expensive replacement that would not have improved matters.
In practice, most reviews land somewhere in between: a small number of worthwhile improvements, several things to leave alone, and one or two risks worth attending to.
Yes. The report is yours. Many clients use it as the basis for conversations with other providers, or to brief an internal team. We have no expectation of being engaged for the work the report recommends, and no clause requiring it.
No. The review covers operational and technical risk at a practical level — unsupported software, absent backups, single points of failure, access arrangements that have not been reviewed. It is not a penetration test, a vulnerability assessment or a formal information security audit, and we will say so plainly if that is what your situation actually requires.