Thorough Checking Yields the Greatest Returns
The increase in delivery complexity (more communication channels), legal obligations (compliance), and customer requirements (personalized mass mailings) makes a stringent quality check indispensable in document processing. Yet at the same time, shorter throughput times are expected.
The fact is that production reliability when processing such data volumes simply is not possible without automation. The risk of misprints and expensive legal entanglements ensuing from rule violations and delivery errors is too great. An IT-supported document check is absolutely essential for one hundred percent certainty.
The benefits are obvious:
- Error-prone manual checking is eliminated
- It guarantees that every document, regardless of format, structure, scope, quantity or output channel, complies with defined quality standards
- Productivity increases because employees can concentrate on their core business
Check before the document is created
The question therefore is not if, but how to set up computer-supported document checking. Where in the document cycle does it make the most sense? Naturally, where the document is created. If the data in an ERM or ERP system is not absolutely correct and complete, for example, it needs to be checked long before document output. The sooner, the better. Statistics prove that the later an error is detected, the greater the effort to correct it.
It turns out the investment needed to correct an error at the end of the process chain is tenfold that needed to correct it right at the beginning. Even then, cost savings warrant integrating another check, such as in the output center for opportunities to bundle mailings to the same recipient to save postage or if documents have all the required control characters for post-processing to prevent returns.
The Bertelsmann subsidiary Arvato, for instance, uses a system that checks the data stream for correct content and positioning of saved objects even before the document is created (composition), formatted and sent. Say an invoice number is always located at a defined position and has a specific length.
If the tool determines that its placement in the final document is wrong or it has only eight characters instead of ten, production is immediately stopped. Alternatively, the "flagged" data stream could be sorted out first and other jobs continued. At the end, a report lists all the changes or interruptions, and the affected procedures are submitted to the responsible individual (specialist or customer) for a decision to release or cancel.
Document checking without centralization is meaningless
One thing's for sure. Quality assurance can be performed at any or many points during document production. In the end, it is the defined processes that determine when what documents are checked and by whom. A frequent phenomenon in customer communication, however, is that documents are created decentrally, outside the standard processes. A call center or local branch office still produces and sends a lot of communications on site, without the main office knowing anything about them. Important business information gets lost in the process. Therefore quality assurance in document processing is also tied to centralization.
All mail deemed to be customer communication is collected and transmitted to a central system, regardless of in what area, in what format, and on what physical and digital channel the correspondence is created and output. While the processor prints the document at his or her workstation or sends it as a PDF attachment to an e-mail, it can be indexed and archived at the same time.
Everything runs in the system background. Ideally, a rules check is integrated here, including for compliance with corporate identity (wording, layout, fonts, etc.) and legal obligations (archiving, reporting, data protection) and even release mechanisms (four-eyes principle, etc.) In particular, banks, insurers, and telecommunications providers are faced with a complex maze of regulatory requirements. How can they possibly meet them without a reliable and central IT-supported check procedure?
First the analysis, then the check
One thing is for certain. Quality assurance encompasses a multitude of things, such as a check of the content (Is the data correct and complete? Are all CI and compliance regulations observed?) and well as a technical production check (Can the files be output and further processed? Are all the control codes for enveloping, franking, etc. present?), and of course, validating the IT itself (How do modifications and updates affect a specific system, other applications and the document? If documents were converted, does the content of the original match the output file?)
For these reasons, a thorough quality check is always tied to a process analysis. Where can rule violations or bottlenecks occur in production? Is data consistent? What document-generating systems are subject to frequent updates? Do these modifications affect document creation at all? The answers ultimately determine what type of check is needed at what point during document processing. Processors and specialist users must be included in that analysis so the entire document cycle can be examined for possible weak points.