Guest Author: Ahmed Hafeez
Edgewater Technology

Workflow and BPM often get lumped together but it is important to understand the difference between them if you are to pick the right tool for your enterprise. While it is generally agreed that workflow is for modeling simple sequential processes and BPM solutions are more capable of handling complex tasks the distinction between the two needs to be further sharpened.

According to David McCoy of Gartner BPM can be defined as “… a structured approach employing methods, policies, metrics, management practices and software tools to manage and continuously optimize an organization’s activities and processes.” Workflow on the other hand is concerned with tasks and application-specific sequencing of activities through a series of predefined steps, involving a small group of people and/or closely related applications. The distinction between the two is far from crisp and in fact it can be argued that both are part of the same continuum. However, there is a distinct difference in focus and complexity between the two. Here is a chart that attempts to further define the two based on capabilities and task suitability.

According to a recent survey by Forrester Microsoft and SharePoint came in as #1 among the IT decision makers for use as BPM platform followed by Oracle, SAP, IBM, and a host of other BPM centric companies. Forrester report further notes that despite Microsoft’s best efforts to not position SharePoint as a BPM solution (rather as a collaborative workflow solution); the message does not seem to come across clearly. This confusion seems to thrive due to lack of clear and well-defined goals for business process automation and understanding of capabilities of SharePoint and BPM suites (BPMS).  The Forrester report outlines that SharePoint’s features for supporting true BPM are limited. Most of SharePoint’s capabilities in this arena are founded on Windows workflow foundation (WF). While a custom solution can be developed based on SharePoint and WF API to support BPM like capabilities, such an endeavor is bound to be expensive and brittle. SharePoint shines best when OTB capabilities are leveraged to the maximum and customizations are kept to a minimum. SharePoint’s workflow, document management and collaboration features can be used to develop robust workflow applications that can simplify and automate document & form centric business processes. SharePoint can also serve as a hub of cross-department and cross-application integration but only at the user interface level. SharePoint does not pretend to act as middleware or an enterprise service bus (ESB) and therefore does not provide any standards based application integration features – tasks best left to dedicated integration platforms or BPM solutions.

The limitations of SharePoint’s built-in workflow and underlying Windows Workflow surface quickly when tested against complexities of true enterprise business process automation scenarios. SharePoint’s workflow processes are constrained by the Site Collection boundaries. Therefore any workflow that needs to span organizational boundaries and as results site collections becomes difficult to manage and brittle. For example if a budget approval process needs to go through the finance department, corporate office and local approvals and if any of these structures use their own Site Collections the workflow process will require custom coding or manual workarounds. This constraint limits SharePoint’s workflow scope to department or local application level. WF processes are also limited to either sequence or state machine patterns. There is also no support for a user who makes a mistake and needs to go back to the previous step during a workflow. Multi-level approvals are also not supported a document needs to be routed back to one of the earlier approvers rather than the author. SharePoint workflows are executable programs and therefore cannot adopt easily at runtime (after instantiation) to changes in the rules that may result from changes in business process environment (e.g. regulation changes, corporate policy change, etc.)

While SharePoint is not ideal for complex business process automation it can certainly be used to get started. If all you organization needs is automation of simple and commonly used business tasks (approvals, document management, simple HR applications, financial approvals, etc.)  that do not require tight integration with other data systems and do not require complex exception processing, modeling, optimization, monitoring, etc., then it is a good candidate for SharePoint workflow. However, if your organization is truly looking into business process automation and business process improvement (BPI) then there are many 3rd party solutions (AgilePoint, Global360, K2, Nintex etc.) that can be layered on top of SharePoint to create a more robust solution. The advantage of a layered solution is that 3rd party vendors are able to leverage Microsoft’s significant investment in ease of use, collaboration and user interface integration capabilities of SharePoint while adding core BPM functionality. Such solutions are also typically less expensive and deploy more quickly than a traditional full-blown BPM solution (depending on the situation). 

There two basic flavors of the layered BPM solutions (products that leverage SharePoint’s platform & interface for most interactions). The first flavor of these solutions relies on the underlying WF as their workflow engine. Using WF as the base they have built capabilities that are more advanced than out of the box capabilities of SharePoint. Furthermore they are able to maintain a light footprint by leveraging SharePoint and WF infrastructure. However, they naturally suffer from some of the same shortcomings as WF. The second group of solutions relies on proprietary workflow engines that are not built on top of WF. Such solutions typically have larger footprints since they create their own parallel infrastructure for workflow processing and data storage. Their independent foundation allows them to provide capabilities that are not limited by WF but typically at the cost of additional infrastructure complexity. There is a place for either kind of solution and picking the right tool (SharePoint workflow vs. SP layered BPM vs. dedicated BPM) is a vital cog in any business process automation or improvement endeavor.

However, the story does not end at picking the right tool; in fact it is just getting started. Edgewater recently conducted a case study on the effectiveness of such efforts and found that there is a significant disconnect between popular BPM messaging and the companies deploying such technologies. While ROI is considered to be the holy grail of most IT projects the respondents in the survey noted that “ROI was not the most important factor … “, other areas such as customer satisfaction were more important. Survey also found that while BPM tools are more than capable of modeling complex processes organizations implementing BPM preferred to “start with well-defined process that involved fewer people to get a quick win and buy-in first”. Perhaps the most important finding was that the success or failure or an implementation depends on “solid understanding of the business AND the necessary technical skills to implement BPM; just one won’t work.” Business Process Improvement (BPI) needs to be a continuous learning and optimizing cycle. Picking the right tool is only half the battle, having a clear vision of goals and objectives and how BPM may or may not help achieve those is just as essential.

Guest Author: Ahmed Hafeez
Edgewater Technology

Ahmed Hafeez is a Technology Management Consultant based in Massachusetts with over 15 years of experience in solving business problems through information technology. He has worked on a range of projects including: SharePoint, Intranet/Internet/Extranet portals, enterprise product development, technology strategy, technical assessments, and package selection/implementation.  Ahmed holds an MBA degree from Babson College and a Master’s degree in Computer Science from Boston University. His blog can be found at Edgewater Technology and he can be reached at [email protected]