Chris Conway
Chief Architect, Quantiv
It’s that time of year when resolutions come thick and fast: “must eat less…”, “must drink less…” or, more positively, “must do more…”
Work resolutions can follow a similar pattern. For example, “must procrastinate less”, “must start/finish meetings on time” (well, at least less late) and “must talk less, listen more”. And these can also become highly specific, often related to personal frustrations or lessons learned.
This year, I have just such a specific IT resolution, but with a wider rationale. My pledge is: to no longer allow the use of reports where documents should have been produced.
Why choose documentation instead of reporting?
At first sight this might seem like a classic example of a simple pet hate or personal preference.
But it’s more than that. In fact, you could say it’s almost a system design principle.
To explain…
- Here, ‘document’ is a process-defined selection and storage of data used for a specific purpose, and usually produced as a direct result of something else being done. For example, a despatch note listing items sent.
- By ‘report’, I mean a user-defined selection of data used to provide an ad hoc view of what happened in a system or application, which is created solely for that purpose. For example, a list of transactions made by a customer between two random dates.
But why the New Year’s resolution? And what’s wrong with reports anyway?
Partly it’s because the creation of reports in IT projects can often be treated as an afterthought. So, they’re only created after developments to support business processing and storing of data associated with those processes have finished. And that means reporting can significantly increase a project’s costs.
But the real answer lies in that very flexibility. Taking a positive perspective, it means you can often bridge a gap in a business process by using a report and a supporting human activity or even an automated task (especially if the report output is produced as a file).
More pessimistically, in part it’s this retrofitting that explains why reporting can often become an unexpected extra cost for a project.
Plus, it means two different users, or even the same user on two different days, will almost certainly produce two different views of the same operational events. This might be interesting or even essential for analytical purposes. However, it’s a real problem for ensuring completeness and consistency of processing, which are the essential elements of business operations. For example:
- An accountant would never consider an invoice as just a report. It’s a formal declaration of a need for payment.
- A banker would never think of a statement as just an ad hoc selection of transactions. It’s an update to the position of an account. But, bizarrely, an accountant might well think of a ‘customer statement’ as an ad hoc (or at least ‘point in time’) view of invoices and receipts.
- And, to a concert promoter, a ticket is not just a printout, although a report could indeed be used to ‘produce’ a ticket.
What all the above examples have in common is they must be issued only once, at a known time, and with a predictable set of contents.
They can’t just be created whenever someone remembers or be based on variable selection criteria. In short, they must be created as a first-hand product of the processing itself, not just an arbitrary, after-the-fact, quick fix.
What’s inside the documents is fixed at the point at which they’re generated, which gives you confidence in their contents. This contrasts with reports where the contents can change depending on when they’re produced. Today’s report of last month’s activities could be different from yesterday’s, so are much harder to use as authoritative records.
How Quantiv can help
To produce reliable documents, you need a strong understanding of organisational processes and activities, which is where Quantiv’s NumberWorks method comes in.
NumberWorks gives you the understanding you need to make sure any documents produced give you consistent records of the outcomes of those processes and activities. And while reports can sometimes be constructed without this information, they then also come without the corresponding authority and reliability.
There are implementation considerations too. You’ll need a specialised, fixed ‘ledger’ data store (such as our NumberCloud service) to hold documents, so there’s no ambiguity about a position in time. And, if such a ledger store is used, you’ll benefit from authoritative ‘point in time’ views from more general reporting.
So, while reporting has its place, especially in analytics, recording operational processing needs a different approach: documentation.
That’s why I’m determined 2026 is (finally) going to be the year when I give up using reports as a cop-out for correcting poorly designed/implemented processing.
Learn more about NumberWorks and NumberCloud
Contact the Quantiv team on 0161 927 4000 or email: info@quantiv.com
