This blog post is part of a series of posts on new ideas to structure information in SharePoint. There are 5 parts in this series:
– Part 1: Every document has its process … (this post)
– Part 2: … with its own pattern of workflow …
– Part 3: … with its own author(s) and audience …
– Part 4: … and its own collaboration and publication structure.
Every document has its process
If I remember well this was the tagline of Lotus Notes when it was launched in the early 80’s. Think of it: can you name any document in an organization that is not related to any business process at all?
If we accept this idea, then maybe BPM can help us in understanding better how documents are created, modified and published in an organization.
Types of processes
BPM classifies business process in 3 categories:
– Core Processes: these are the processes that serve the external customer of the organization
– Supporting Processes: these are the processes of which the customer is an internal customer
– Management Processes: these are the processes that given direction to the organization and that control the compliance too what was agreed.
What strikes most is that the audiences of these processes, i.e. the people that create and consume information in these processes are different groups of people: people working in the core operations of the organization, management, etc. Let’s keep that in mind.
Types of documents
Another consideration is that the types of documents that are used in these processes are very different.
There is a big difference in behavior between:
– Procedural Documents, and
– Operational Documents.
Procedural documents describe HOW the organization operates. Examples of procedural documents are: procedures, manuals, training material, etc.
Characteristics of Procedural Documents are:
– They have 1 author, or a limited number of authors, sometimes a reviewer and approver, and a large audience (some procedures are applicable to the whole organization, some to the whole department, etc.)
– They can all share 1 workflow to manage and control new versions (see Part 2 on workflow patterns)
Remark: this is where Document Management originated, in the controlled environment one needs to manage versions of documents.
Operational documents support the actual operations of the organization. In fact in many cases, the Operation Document IS the process. Examples of Operational Documents are: Proposal, Expense Note, New Hire Request, etc.
Characteristics of Operational Documents are:
– The authors of the document and its audience are equal to each other: each actor in the underlying process reads the document, enhances it with his or her information, and then forwards it to the next actor in the process
– Each document has its own workflow (see Part 2)
Operational Documents are fundamentally different from Procedural Documents.
Also because by definition business processes run across different departments in an organization, Operational Documents cannot be stored and processed on a departmental site; they must be placed in location that is accessible to all actors in the process.
Templates are the linking pin between Procedural and Operational Documents
Part of a procedure is often the form or template one has to use to apply the procedure. In fact by using the template, one creates an Operational Document that will follow its prescribed flow in order to be processed. Let’s keep this in mind: it confirms that templates should not be stored with the procedures in the Procedure Library, but should be linked to the libraries in which the operational documents are created (see Part 4)