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 …
– 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. ((this post)
Every type of document needs its own collaboration or publishing structure
The dynamics of creating and processing a document is SharePoint must not be forgotten when defining an Information Architecture for SharePoint. As described in the previous posts of this series, documents are not uploaded or created in SharePoint just for the sake of it. Every document is part of a business process or has its own process. In this post I would like to explore the document type / workflow / audience combinations and their place in a Information Architecture.
Procedural documents describe HOW the organization operates (e.g. Quality Manuals, Procedures, Manuals, etc.). Procedural documents most often originate from a project or a work group or committee.
Creating a new Procedural Document
E.g.: the new procedure for applying for ordering a new lease car is written by a work group with employees from HR and Purchasing. That work group collaborates on the new procedure in a dedicated work group team space in SharePoint. After they finished the new procedure, it is submitted to the management team for approval. After approval it is published for all employees.
I know that it is hard to fully implement this approach as such. Nevertheless this is the reality behind all procedural documents. In more workflow-mature organizations this way of working can be easily adopted, whereas in organization with a lower maturity level, this will be conceived as impossible to implement.
Modifying an existing Procedural Document
When it comes to modifying existing Procedural Documents the solution is more simple: by using a standard Review-and-Approval workflow the document can be changed ‘in-place’ by using versioning and minor versions, and can be published as a major version after approval.
Conclusion 1: for Procedural Documents your Information Architecture must comprise
– Collaboration Spaces for Committees, Work Groups, Projects, etc.
– Meeting Spaces
– A ‘General Availability’ Space
Operational Documents are used in the business processes of the Organization. They don’t describe how the process is executed, but they are part of the content of the business processes. E.g. a Purchase Order contains information about the business process of a specific purchase. Sometimes the document even is the process.
Business Processes may have just 1 underlying document, but in many cases the process uses different documents: this is typically true for Case Management processes.
In one of the previous posts I stated that the ‘writers’ and ‘readers’ of Operational Documents are actually the same group of people, comparable to a group of people collaborating on a document or group of documents. In the case Procedural Documents however, people ‘collaborate’ in a very structured way: the follow the business process.
Business processes are implemented in SharePoint by means of workflows. The assignment of a workflow step to an employee leads to the creation of a task on that person’s task list. When an employee works in different business processes he/she will get tasks from different flows on his/her task list. These tasks operate on different documents. Therefore it seems like a good idea to concentrate all Procedural Documents in one part of the Information Architecture.
Conclusion 2: for Operational Documents your Information Architecture must provide for a workflow environment for Business Processes.
Hierarchy-oriented versus Process Oriented Architecture
Today, most SharePoint implementations offer a structure that is based on the organizational hierarchy in which each department, business unit, etc. has its place. This is ok for the information that can be limited to each department or business unit. Whenever content in SharePoint is targeted to an audience that goes beyond the boundaries of the department, it should be moved up to a destination for all employees.
Business Processes, by definition, operate beyond the boundaries of 1 department. Therefore the business processes and related workflows must be hosted in a separate structure from the departments.
Conclusion: suggested structure
– All: contains all content that’s is published for the wider audience
– MyWork: contains all Operational Documents-related content, including the related workflows
– Committees: contains all content on which employees are still collaborating (i.e. unpublished content)
– Projects: same as Committees, but limited in time
– Departments: for all content that is strictly limited to the employees of a department
See also: www.spikestogether.be