Where should you put the documents?

Most organisations have line of business application for the various elements of their core activities. Whether it’s a Finance System, a CRM, a Patient Records Platform, a Student Management System, a Logistics ERP, an HR Management application, or a Contract Management database; at the heart of every organisation is a collection of information, almost always coalesced in the form a structured database, that drives the organisations core activities.

For UpFlow Solutions, our approach has been one of integration. It’s been about using our capture and workflow platforms to streamline the manual parts of a business process. We want to get the information where it needs to go quickly and with minimal human effort, while still going through the required approval / routing / coding / validation steps along the way. And it works! The information hits the various databases through API (Application Programming Interface) / Flat File / RPA (Robotic Process Automation) integrations and everyone is happy. However, the question that is often plagued with uncertainty is, “Where do you put the source document afterwards?” The data is in place, reporting happens as scheduled, users have the information at their fingertips – but what happens to that PDF that began the whole process?

Over the last few weeks I’ve found myself in several conversations about various Line of Business applications and their potential role in ongoing document storage. This is not unusual in of itself, in fact these conversations happen quite often. However what made these discussions different was the nudge in thinking I had from reading a white paper out of Upland entitled, “Thinking of Attaching Documents to your Line of Business Application?”. In the past I’ve usually taken a more neutral position on whether that could be a good idea or not and I’ve used phrases like, “There are several schools of thought about that” or, “What’s right for one business isn’t necessarily right for another” or the even more bland, “There isn’t necessarily a right or wrong way to do it”. However, when I look at those kinds of comments objectively, they are more about finding a point of agreement with the person I’m talking with, rather than actually offering any kind of insight. Or to put it more bluntly, it was more about me trying to sell than it was about me trying to inform.

So with my new-found self-awareness, I set out to move away from this 50/50 coinflip of equivocation, to find the best default position of what one ought to do in the absence of compelling contributing factors. For me it came down to three main considerations, each comprised of a few different factors:

1. Information Silos
   When you incorporate the source documents into your line of business application you have effectively created an information silo. You’ve essentially put all your eggs in one basket. Ignoring for the sake of conversation the disaster recovery implications of doing this, you’ve also introduced some practical limitations on your future options. If you ever want to move away from that system at some point, even if that point might be five or ten years down the track, you’ve just made the change process a lot more complex. In a few cases, usually limited to the more bespoke ERP offerings, the system could even be converting the document to a proprietary format.As a general observation, I find the rate at which companies change their backend systems, especially their finance systems, is quite surprising. While some businesses have never changed and are still using their original solution, others have gone through several different platforms and are still considering other alternatives. Even if you aren’t actively planning change, there is an argument to be made about not closing doors before you know whether or not you are going to need to walk through them. Ultimately, having both the data and the source documents hooked into that ERP is going to make it harder to move away should you ever need to.

2. Interconnectivity
   Another factor worthy of consideration is the inter-connectivity of your systems. By moving your document into that ERP, you’ve likely created a single point of convergence for accessing that document. In other words, to find that document you now have to use that particular system. But what if more than one system needs access to that document? What if you have something like say a sales proposal that needs to be in the finance system as a supporting document for the billing department, but then it also needs to be in the CRM against the customer engagement history? Do you load the document into one and force users to continually jump between systems? Or do you load a copy in each, at which point you no longer have a single source of truth and have to contend with version controls?The third option is the more sensible option. That is to manage documents in a dedicated document management system and upload dynamic links into the line of business applications to reference the same instances of those document. This can also mean that by using search functions you can cluster together different document types that are related to the same project / customer / matter.

3. (De)centralised document management
   Line of business applications are function specific. They are designed to do a particular set of tasks and to do them well. However, those tasks are almost never the entirety of an organisation’s operations and it is rare to find a truly all-encompassing system that handles every single moving part of the modern business machinery. For the sake of example, consider a school that may have a student management system for managing the student history and school roll, a classroom management system for lesson planning and teacher to student/parent communications, a finance system for running the business side of the school, and perhaps even an asset management system for site maintenance and contract management. With enrolment forms in one system and invoices in another, where exactly do things like Board of Trustees meeting minutes go…?Now imagine what that looks like for your business. Where are the gaps between systems where your unstructured data is falling through…? Without centralised document management you are left with pockets of orphan content and unstructured data residing in loose PDF’s outside of any managed process.

After considering these points (as well as many others omitted for the sake of brevity) my opinion is that a default position for an organisation ought to be that source documents are managed outside of the line of business applications in a centralised document management system. Unless of course there is a compelling reason to ingest them into the line of business applications.

So the next time someone asks me whether at the end of their workflow they should push their AP Invoice PDF’s into their finance system, my answer will begin with “Just because you can, doesn’t necessarily mean you should. Let’s take a moment to consider the big picture beyond just those invoices…”

If you have any questions or would like to have a chat about how we can help, please contact us today.

Kris Elliott
Solution Sales Executive