SharePoint Applications: Process Redesign & Capabilities Mapping

By Joe Shepley (@joeshepley) Feb 23, 2012

For those of you keeping score at home, I’m in the middle of a series on how to build and deploy successful SharePoint document management applications, with the goal of migrating end-users off of the most prevalent legacy document management system out there: that unholy trinity of shared drives, hard drives and email.

Last post, I began walking through a process that, while by no means a silver bullet, in my experience will give you a better chance of success than the typical approaches, e.g. if you build it, they will come.

Process mapping
Process triage
Process redesign
Capabilities mapping
System design and testing
Migration planning
Communication and training
Go live

We covered the first two steps there, and that’s the place to start if you haven’t already done so. In this post, we’ll dive deeper into the next two: process redesign and capabilities mapping.

Step #3: Process Redesign

After completing the first two steps, you wind up with a list of ranked document-centric processes for the business unit you’re working with. For example, if you’re working with the sales organization, you might have landed on the following list of processes:

Contracting
RFP response process
Forecasting

You would have also stepped through each of these processes at a high level to better understand them and the documents involved. For example, the contracting process:

Populate contract template with deal specifics
Route to sales team for approval
Send approved version to legal for review
Finalize contract draft
Send to client for review
Revision cycles with client, sales and legal
Deliver final version to client to sign
Route to sales for signature
File hard copy in file room, keep scanned copy on department drive

What you turn to do now is build the target future state, the to-be process that you’ll enable in SharePoint. This will be an iterative process, one that begins with the team talking through both the problems of the current state as well as what’s possible and desirable in the future state.

Remember, in the room you’ve got all the relevant business, compliance and IT stakeholders, so those of you used to more waterfall approaches to system development will have to adjust to the blending of business requirements gathering, system requirements gathering and solution design that characterizes these JAD-type working sessions.

The basic idea is to collectively sketch out how the current process could be modified to improve it (take less time, require less people, have higher quality, have lower risk, etc), with particular attention to how SharePoint can support those improvements.

Unlike some of the other steps, there’s no real trick or repeatable formula for process redesign. It requires judgment and cooperation, and the results in large part are dependent on the specific context of each case.

That having been said, here’s what our hypothetical contracting process might look like after a redesign effort:
Shepley - SharePoint Implementation - Back to Basics for Success (Part 2) - FIGURES.jpg

As you can see, SharePoint can only optimize so much here: steps relating to internal document management get a real boost from workflow, versioning and link sharing; external document management remains largely the same, mostly because exposing SharePoint externally goes beyond the bounds of the typical shared drive replacement project at most organizations.