In the answer to a question posted here a few weeks ago, I mentioned that, in our current project we are trying to implement as much of AIIM’s ECM Roadmap in SharePoint as we can. I first saw the Roadmap during the ECM Master Class that I took in 2008, but it is available on the web (see Today & Tomorrow). The Roadmap starts with Input as a general topic and includes a variety of human and machine-based capture methods. Of course, you may have guessed by the title that I am going to start a little bit ahead of this point; I am, that’s the beauty of SharePoint! This time, our process begins before Input, because SharePoint can provide a collaborative workspace in which to create the report.
The nice thing about building a document in SharePoint is something that I’ve written about numerous times here – proximity. In a modified Team site, I can make the author’s job easier by having all the tools, templates and lists of people on the same page as a Web Part view of the Document Library.
Another nice thing is that it gives the author the opportunity to start defining metadata early and it enables us to start collecting information about the process. For this particular process, I am starting by creating a new Content Type. Content Types are one of the most useful SharePoint features, and I don’t use them often enough. By creating a Content Type, I can specify a template, define required metadata and insure that it is collected consistently; everywhere these documents are developed or stored.
Those things are all important, but there is an even more important reason to start this process in SharePoint. I want the authors, technicians and managers to know that they are part of a managed process. Letting people develop the document on the K: drive, and then upload it to SharePoint, sends the message that the document isn’t being managed until it is written; that’s the wrong message. We are participating in a business process, and creating a company record; every step of this process should be managed. The final benefit I mentioned about starting the process in SharePoint is collecting information. Even at this early stage, since one of our required metadata columns is the date the activity occurred, we automatically know how long it takes between the activity and the creation of the report. Later, if we want to build reports or indicate status from this (and other) data, we can.
Another important benefit of building the document in SharePoint is the ability to store material related to the document. I want the author to be able to upload images, charts, illustrations and I want him or her to be able to define links to websites that they find useful. Most of these items are not things we want to preserve as records, but we may not want to toss them out either. For example, we frequently receive requests like this: “do you know where I can get a copy of the illustration Joe used in this report?” These things can stay in the collaborative workspace; other employees can reuse this material. Also, in SharePoint 2010, they can comment on the items, tag them or rate their usefulness.
Bonus – Now that we are working with SharePoint 2010, this process can be even smoother and automated to an even greater degree. As long as the author is working on the report, the document remains in the collaboration workspace. As the author changes the status, SharePoint Workflows can establish review tasks for other people, and update additional tracking metadata. Once the author stops referring to the report status as some form of ‘Draft’ and sets the status to ‘Final’, a SharePoint workflow moves the document to the permanent repository. Since the repository is a Record Center, the report can be “moved” (see last week’s post), I can leave a link behind in the original library, and the Document ID is preserved. While the workflow is moving the document, it can automatically set most of the metadata columns in the Record Center. Oh wait, it looks like we just merged onto the roadmap.