Rix Bits

On Tuesday, I’ll be the guest speaker at the Dayton SharePoint User Group (www.dayspug.org).  I’ll be speaking on Business Process Management/Automation using SharePoint and Workflow.

As I consider this topic, I thought I might share some guidance on the process of automating your organization’s business processes, regardless of whether you use SharePoint or any other automation technology.  Anyone who has endured the fun of auditing, documenting, and ultimately automating the way in which their company does things will tell you that the planning side of it is just as significant, if not more so, than the technical implementation.

Here are some tips that could help you and your team have a smoother and less frustrating experience:

• Talk about your process first, not the process technology – Many times, a company begins to consider automating their processes because they’ve recently acquired a new tool that can help them do it.  A kickoff meeting is scheduled to begin the process, and what tends to happen is that the conversation centers around the capabilities, or lack of capabilities, of the new tool.  Instead, what’s really needed first is a conversation about the specific details of the process itself, regardless of what tool or technology will be used to automate it.  It may be true that later you’ll discover that the specific feature set of the tool limits your ability to automate certain parts of your process, but at least you’ll have a clearer understanding of where you need to make those compromises.
  
  
• Be on the same page – literally – It’s important to document your process before you begin designing an automation strategy.  Visual flowchart diagrams are best, especially since they allow the viewer to focus on the big picture rather than the wordy details.  But what’s also important about this document is that it can become the Bible from which all future discussions on the topic can start.  Someone who believes there should be a change in the organization’s process should express their view by discussing how the official flowchart should be changed.  Discussing the issue separate from the flowchart results in vague conversations and wasted time.
  
  
• No frills for the 1st iteration – Business process automation should use an iterative approach. Even the most complex process, with dozens or hundreds of steps, can probably be abstracted at a high level into a flowchart of just a few steps. For instance, the process of getting approval to publish a new company document might involve many steps that include multiple people, revision strategies, and document management.  But, at a basic level, it may just involve 1) storing the new document in a specific location, 2) emailing a single approver, and 3) publishing the document to its final location.  A lot of value can be gained from making the Beta version of your new Approval process be an automation of simply these three tasks.  Not only does it allow people to get a feel for things like the having approval emails arrive in their inbox, or using some 1-click publishing tool, but as the design grows in complexity, it helps users see early on where there may be functionality gaps that need to be addressed.

By using an iterative and well-documented design strategy, a team tasked with automating a process in their organization should be able to do so with far less frustration, producing a final product that contains a level of detail that the team can have confidence in.