3.5 Assessing Information-System Deficiencies & Replacement Needs

Diagnose Before Buying

The official Module 2 outline includes upgrading or replacing information systems. The starting question is what information is missing or unreliable and why that matters to a decision. Buying a new system before diagnosing the problem can automate poor definitions, preserve redundant approval steps and make inconsistent data move faster.

Replacement triggers include unsupported software, persistent control weaknesses, inability to integrate a new business, slow reporting, missing strategic measures and unacceptable continuity risk. These are reasons to investigate, not automatic proof that replacement is best. A late monthly margin report could reflect slow system processing, unapproved time sheets, unclear cost ownership or unresolved master-data errors. Each cause requires a different remedy.

Interview report users, observe actual workflows and inspect evidence of delays or errors. Trace a sample from source transaction to decision report. Record where data are created, transformed, approved and reconciled. Separate the symptom, its operational consequence and the proposed cause. This prevents a vendor’s feature list from becoming the organisation’s requirements by default.

A Preliminary Assessment

A preliminary assessment defines the problem and asks whether potential solutions deserve detailed evaluation. It should cover the affected processes and stakeholders, the strategic objective, current performance, essential controls, constraints and the resources required for investigation. Identify the sponsor, decision authority, process owner and users who must accept the result.

A requirements register can make a vague request assessable:

The numerical thresholds belong to the particular business case. Do not invent a universal response time or accuracy percentage. Distinguish essential legal or control conditions from desirable features and optional conveniences. A solution failing an essential requirement should not win because it has a visually attractive dashboard.

Analyse the Existing System

Document current interfaces, manual spreadsheets, data ownership, access rights, reconciliations, failure history and support arrangements. A process map should expose duplicate entry and hand-offs. An information map should show the definition and source of important fields. Together they help distinguish inadequate technology from ineffective use of adequate technology.

Review both formal reports and the unofficial workarounds people actually use. A spreadsheet maintained by an experienced employee may contain critical logic missing from the official process. Capture that knowledge before replacing anything. Examine whether migration can preserve necessary history and whether statutory retention and access requirements can still be met.

Compare at least three credible options where available: improve the existing process and controls, add a targeted reporting or integration layer, and replace the core system. Include a do-minimum alternative with the genuine consequences of postponing action. Its forecast need not stay flat, but deterioration must have evidence. Do not exaggerate future failures to make replacement appear attractive.

Worked Preliminary Decision

Assume a fictional wholesaler takes ten working days to produce customer margins. Investigation finds three days spent extracting files, four days reconciling inconsistent customer identifiers and three days obtaining approval. A proposed new dashboard can reduce extraction to one day but does not repair identifiers or change approvals. The realistic result is eight days, not one.

The accountant proposes a preliminary trial: clean customer identifiers, assign an accountable data owner and simplify approval for routine reconciliations. Assume this cuts reconciliation to one day and approval to one day. With the existing three-day extraction, reporting would take five days. A later dashboard could reduce that to three days. These are testable process assumptions, not guaranteed benefits.

For the trial, measure reporting time, unresolved exceptions and user acceptance over comparable reporting cycles. If data errors remain, the business should understand them before selecting a replacement. The trial may show that a smaller integration project meets the need at lower transition risk, or it may establish a genuine requirement for core replacement.

Common Assessment Pitfalls

A frequent failure is asking users which software they want instead of which decisions they need to make. Others include accepting senior managers’ requests without observing operations, collecting every conceivable requirement without prioritisation, ignoring external stakeholders and assuming all current reports should be reproduced. Redundant reports can be retired when their decision purpose no longer exists.

The accountant should also challenge optimism about implementation capacity. Staff still have ordinary work during migration, testing and training. Record dependencies on scarce people, contractual exit constraints and data quality. Present unresolved matters as investigation tasks with owners. The preliminary recommendation should say which option proceeds to detailed evaluation, what evidence is still needed and what would cause the sponsor to stop or change direction.