Part 1; You are here.
Part 2: SharePoint Workflow & BPM Vendor Comparison Chart
Once upon a time, I was a fledgling IT business analyst with a concentration in enterprise collaboration tools and processes. So one day, a company executive said, “Henry, we need some tools to help us manage our business processes… you know… like something that can keep track of everyone’s tasks… send emails to the person that has the next action… Then have it email me when everything’s done.”
Well, having looked at oodles of Microsoft SharePoint presentations and pizza charts, I told him, “Mr. Company Executive, I have just the thing in mind. Since we’re already using SharePoint, we can take advantage of the cool workflow capabilities already built into the system!”
And so it began… We started off with some short and sweet implementations like having Joe (the CTO) approve James’ (QA Manager) TPS reports using the OOTB document approval workflows in SharePoint. Then we used SharePoint Designer to make some more robust workflows that enabled James to provide some more information to be used as variables inside the workflow. Then as soon as we outgrew that, we even busted out Visual Studio for some custom SharePoint workflows that copied these TPS reports out to customer extranet sites. Then we wanted to make the workflow talk to our accounting system, and our SalesForce CRM account, and then have it trigger some other processes… yada yada…You get the idea right? But going down this path, we quickly realized this one critical key point:
SharePoint Workflows are only good for managing business processes if your entire business process resides within SharePoint!
<!— Update (1/11/2010):
“Whoa nelly!” you might be saying to yourself. “That’s quite a loaded statement. Care to clarify?”
SharePoint is meant to be an end-user enabler. In our case, of all the self-service things that an end-user can do in SharePoint, the ability to create workflows by their lonesomes had become one of the most empowering tools. But once we got to the point of having to create custom workflows and workflow actions in Visual Studio for all the different systems, the thought of burdening developers to develop, maintain and enhance these proved to be an overhead that simply wasn’t worth it to us (in comparisons to third-party workflow solutions that are available).
Well I guess that’s not entirely true. If you can afford to have a development team dedicated to creating custom workflows in Visual Studio and are willing to have them update the workflows every two weeks (exaggeration?) as the business process changes, then you should be ok. But how many companies out there can actually afford to do that right?
So that’s when I figured out the difference between OOTB SharePoint workflow capabilities and the difference between user-centric workflow and business process management software.
“Hold on one darn second there”, you’re saying. “So what’s the difference between SharePoint Workflows and Business Process Management Software?”
Well, in some ways they’re the same and in some ways the differences are black and white. In its most basic form (OOTB & SharePoint Designer) I would consider SharePoint workflows to have the following characteristics:
- Can be manually or automatically invoked by some human action.
- Workflow states typically consist of Start, Pause, Wait for User Action, End.
- Workflow states can be changed based on predefined business rules or logic.
- Actions are typically confined to the boundaries of SharePoint and in many instances, the actions are confined to even more granular levels like the site or document library.
- Although the results of workflow actions can be recorded and logged in history, multiple versions of the workflow models themselves cannot be saved.
- Changes to the workflow process can not be applied retroactively. Once a workflow process has begun, it can only follow its predefined path or be terminated.
On the other hand, Business Process Management is an idea or strategy typically executed with and supported by the use of Business Process Management Systems (BPMS). I would consider the following features to be available at minimum:
- Can be manually or automatically invoked by some human or system action.
- Actions are never bound to any particular system.
- Should be able to communicate with any software system in the enterprise by way of web services and other service oriented architectures.
- Can be used to model, implement and manage the entire lifecycle of any customer facing or internal business process regardless of the number of different systems it has to interact with.
- Can enable the business to change their process on the fly without detriment to processes already in flight.
<!— Update (1/11/2010):
Why is the title of this post “SharePoint Workflow != Business Process Management”? Because without getting into code, OOTB SharePoint workflow just doesn’t give you much flexibility in really managing full business processes… but it can be close!
There is a huge market space in between the 2 sets of characteristics that I had listed above. This space, which I will call the “SharePoint Workflow solutions that want to be pseudo BPM machines but can’t call themselves BPM machines because SharePoint people only know what workflow means” category. These solutions typically help business users overcome just about all of the issues with the OOTB SharePoint workflow capabilities, yet also include a multitude of custom actions that enable them to interact with things outside of SharePoint, thus sharing some characteristics of a true BPMS.
Now if you just read that and are still scratching your head, my apologies. Just remember this important differentiator: OOTB SharePoint workflows don’t are difficult to scale outside of SharePoint without Visual Studio.
So how does all this information help you and your SharePoint implementation?
If you’ve been working with SharePoint workflows for awhile and have started looking at supplemental workflow solutions, you’ve probably come across quite a few options out there. As these third party products have matured, they are also increasingly blurring the lines between just being SharePoint workflow solutions to including capabilities that also enable them to become full blown business process management systems. In the next few posts, I’m going to take a good hard look at each of these SharePoint workflow/BPM solutions and give you the low down on the pros and cons of each that I will be evaluating. Stay tuned.