SharePoint as Catalyst

I’m going to stay within my chemical past for another post. Activation energy, the energy required to overcome the barriers to a reaction or, in our case, a process, always comes at a cost. Instead of looking for ways to coax activation energy out of our coworkers, what if there was a way to lower the barriers? If we were in a lab, we would be looking for a catalyst – something that makes a reaction happen faster by lowering the activation energy. That sounds like technology to me.

In fact, using technology as a catalyst for ECM is a perfect role. The job of a catalyst is to make it easier for a process to proceed, technology does that. The definition of a catalyst also requires that the catalyst doesn’t alter the outcome and is not consumed. OK, here’s where we have to be careful. Let’s dispense with the second condition first – other than drive space, our technology isn’t consumed during document management and we could argue that if we’re moving documents from file shares, inboxes and local drives, it may be a wash. If we’re eliminating duplicates, we may be gaining ground.

The first point is more important and it’s also where SharePoint shines. SharePoint makes ECM easier in many ways but it doesn’t alter the documents. We’re not converting documents to a proprietary format, we’re not adding the burden of different software to view or edit our documents and we’re not leaving traces of SharePoint in the documents themselves. SharePoint adds value through additional features and associated information. Metadata, custom columns, effective organization, permissions and rights management and search are a few of the things SharePoint couples with our documents. But wait, these things don’t make ECM easier, they are ECM, they are the result but we still have to do the work – how is this lowering activation energy?

SharePoint’s role as a catalyst relies on the other features SharePoint offers. For example, an email enabled document library can have a workflow attached to the arrival of new documents. This means contributors don’t even have to know where the library is, they just have to send the document to an email address and the approval or review process begins. In another library, Content Types deliver the right template to an end user so that the development of the document is easier and fewer edits are required. Staying with production, SharePoint’s awesome collaboration features can make it much easier to develop and manage documents. Consider the following example.

We recently moved the maintenance of our public web site into SharePoint. We have several people inside the company involved in authoring and approving content and we have an outside firm, Centroid Communications, helping with design, editing and production. New ideas are described in a SharePoint wiki. Draft articles are written, edited, commented upon in the wiki and ultimately published from the wiki. In the past, these articles would traverse multiple inboxes and were often delayed. Even if they moved quickly, the comments had to be weighed and merged and the “final” article reviewed again. I can point to more than one document in our file share whose title includes “final-final” as a result of the old process.

Some people in the industry complain that SharePoint’s wikis are not “best of breed”. Maybe that’s true but you have to consider everything that’s included. First, we have a browser-based platform to build the content in. SharePoint provides the access control, allows us to review the history (who changed what) and alerts us when changes are made. Combined with the wiki editor and feature set, this is a very powerful tool; it’s making the job of web publishing easier and it doubles as the archive. How much better does it get?