Many organizations have implemented a Document Management Systems (DMS). But that doesn’t mean that documents are now more integrated in the line-of-business applications than before. What is your strategy to integrate document flows in your ICT Architecture?
The problem is that, although documents are the most common information carriers in many organizations, they lead a separate life at a fair distance from transactional systems and even more from the process-based applications, if they exist. As a consequence the information worker, in his day-to-day job, has to joggle and switch between applications like the transactional systems he is using, the DMS and his e-mail in- and outbox. Compare this to having a car to drive on flat roads, a SUV for driving up- and down-hill and a little truck to go to the supermarket, without the possibility to drive your car on mountainous roads, the SUV on flat roads, or load any kind of groceries in your car or SUV: how practical would that be?
What is needed is an understanding of the relationship between documents and business processes, and documents and transactional data. This bog post explores those relationships.
A Classification of Documents
The distinction that I would like to make here between very different types of documents stems from the distinction that is commonly made between different classes of business processes. Every book on Business Process Management will tell you that
there are 3 fundamentally different types of business processes in every organization: Core Processes, Supporting Processes and Management Processes. Core Processes are the processes in your organization that deliver to your (external) end-customer (typically the Marketing and Sales Processes, Production, Delivery, etc.). Support Processes are the processes that deliver to internal customers (e.g. HR, Finance, and ICT processes). Management Processes deal with reviewing and setting the direction and objectives of the organization, defining how the organization should operate, and controlling the execution.
Now let’s get back to the reason for existence of the early DMS: the documents stored in the DMS have long been the output of the Management Processes in an organization. They are the type of documents that describe how the organization should work. That means that they contain meta-information on the organization, not operational information. Let’s call them Procedural Documents. Compare e.g. a document containing the procedure for approving offers with a document containing the offer itself. The first one describes how the process should be executed, the second one contains information on (1 instance of) the process itself. Let’s call the latter Operational or Process Documents.
Again this distinction is very important because it leads to 2 different sets of requirements when it comes to supporting the underlying processes in the life cycle of these documents. Whereas a DMS was used mainly for procedural documents so far, it is used more and more for operational documents.
Operational Documents and the Information Worker
An Information Worker typically uses mainly Outlook (or another mail client) and Office in his/her day-to-day job. The mails themselves and the attachment in those mails are increasingly operational documents that used to be sent on paper by snail mail (you know, in the era when animals could talk).
Whereas before there was no real need to integrate Outlook/Office with the DMS for the procedural documents, this integration is becoming more and more essential to the productivity of the Information Worker: how easy is it to save an e-mail in the DMS or to save the attachments of the e-mail in the DMS. And ideally, the act of saving an e-mail or an attachment to the DMS should trigger the right workflow to get things moving. (But that will be the content of a next post: the difference between workflows for procedural documents and for operational documents). The message of this blog post is: it’s time to get the work of the Information Workers organized and make it more productive by integrating 2 worlds of work: Office tools (including the mail client) and the DMS.
(Guess what: that type of integration is one of the big innovative improvements of Microsoft Office 2010, SharePoint 2010, e.a. … but that’s again a subject for a different blog post.)
The Integrated Information Worker World
So the ideal information worker’s world looks more or less like this:
– The IW saves e-mails and documents from his/her Outlook client to the DMS
– By saving the document in the DMS, a workflow is triggered
– A step in the workflow may trigger transactions in the back-end system (*)
– When a workflow step is completed, the next step is added to the task list of the IW, who will receive an e-mail notification in his Outlook client.
(*) See also the article ‘The back-end database doesn’t need to know everything’
