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.
The SharePoint Swiss Army Knife 
Look forward to next three posts
Great topic! Looking forward to seeing your opinion on the products.
Henry,
I believe you have overstated your conclusions based on a very cursory evaluation of SharePoint workflows, to the detriment of your readers. Many of the points on which those conclusions are based are simply incorrect.
While I would agree with the title of your post, namely that SharePoint Workflow != BPM. You could also make the more general statement that Workflow != BPM. BPM is by definition a much broader topic than Workflow. Whereas Workflow attempts to codify a single process, BPM focuses on the aggregation and orchestration of those processes, which is outside the scope of most SharePoint workflow deployments.
The implication that SharePoint workflows must be initiated by a human action is also incorrect. They can be initiated, interrupted and modified by other processes quite easily.
Finally, your statement that SharePoint workflows “don’t scale outside of SharePoint” needs further explanation. What exactly are you referring to?
John F. Holliday
SharePoint Server MVP
Hey John! Firstly, thank you for commenting. You’ve made some very good points especially in terms of my conclusions being overstated and cursory.
My first intention is not to degrade SharePoint in any way but to point out the differences between the 2 subjects as they are often misunderstood to be one in the same. I think this is especially true amongst business users since Microsoft doesn’t have a BPM product that also enables business users to design and implement processes outside of Visual Studio (does BizTalk have a non-Visual Studio tool for business users?).
My second intention, which should’ve been stated from the beginning, is that my analysis is based on solely what you get out of the box and through SharePoint Designer. Without creating custom actions or opening up Visual Studio, I stand by my statements unless I’m smoking a crack pipe and am totally missing it (you can tell me that, I won’t be offended ).
The statement I made in regards to SharePoint workflows not scaling outside of SharePoint only applies to OOTB + SharePoint Designer. I believe once you get into Visual Studio there really are no boundaries and practically anything is possible.
If there’s anything else that’s sticking out as incorrect, please do let me know. We learn something new everyday!
I agree with John, Workflow != BPM. While the features fall well short of a mid to high end Enterprise BPM tool there are some very useful features there that provide much needed functionality to the business to help bridge the gap.
The biggest exception I take is its ability to scale and integrate with other systems. I’ve managed to integrate SharePoint’s workflows with a number of third party tools and have instantiated a workflow automatically from an outside system. There are no real limitations here.
I think you may want to revisit some of these points.
Hey Mike! Thank you for the comments as well. I’ve updated my post to hopefully make it more clear to future readers that my intentions were not to confuse them about what you can’t do with SharePoint workflows but to use it as a lead-in to future posts about third-party SharePoint workflow/BPM solutions.
Henry, I agree there is a lot of confusion out there, and I appreciate your efforts to shine the light of clarity on this increasingly important topic. I look forward to reading your next posts and hearing more about your experiences.
I think the term “SharePoint Workflow” is inherently misleading, because there are 3 kinds of SharePoint Workflow. There are “Sequential”, “State-Machine” and “Declarative No-Code” workflows, each with its own set of strengths and weaknesses. The “SharePoint Designer” workflows you are describing in your post are “Declarative No-Code” workflows, which admittedly are much more limited in scope than the other two.
However, even the declarative no-code workflows can be extended with custom activities so that you end up with very powerful capabilities that are accessible directly from SharePoint Designer. In the same way that a well-designed library of server controls can greatly improve the productivity of web developers, a well-designed activity library can enable power users to automate fairly complex business processes.
Sharepoint is more of a human workflow type of tool … even if one can do lots of things via code … in the 2010 version Visio will non IT people help in designing flowcharts, so it will more BPM-like
for system workflows Biztalk is more appropriated …
MS doesn’t have a well-rounded BPM offering (which IMHO, MS is missing a huge boat to let non-IT people easily knit MS software together), so for more advanced all-in-one environment one needs to go to buy third-party software …
Hi Henry, like John sayd there is a lot of confusion in SharePoint Workflows and about SharePoint WWF Visual Studio based workflows capabilities. Lack of functionalities, versioning, reporting, assignment policies too many code to write. In SP2010 we have little enhacements like reusable workflow but nothing more. In my opinion the real problem relies inside the workflow engine adopted by SharePoint: WWF. WWF demonstrates a lot of problem when hosted inside an IIS process. More, WWF is a very basic Workflow engine.
I think you are bang up against many issues … all of which I explored in great depth in my White Paper – SharePoint as a Strategic Weapon … which is all about the issues associated with Shpt and Process, down to and including the underlying Windows Workflow Foundation, which IMNSHO is a bit limiting.
Have a look at the web site – you will find the paper on Page 5 of the White Papers area, but you will need to register to get it (BTW – registration on the BPM Focus site requires use of a valid email address … don’t worry we wont spam you and you can easily opt out of future communication later)
Should have included a link to the site … http://www.bpmfocus.org
Henri,
Excellent Post! I’m completely with you, except with respect to what you attach to the term “SharePoint Workflow”. If you used “Microsoft’s SharePoint Workflow System” then you’re right on. However, if you referred to, say, http://www.spsworkflow.com/sharepoint-workflow.ashx, with the associated capabilities listed in http://www.spsworkflow.com/sharepoint-workflow-designer.ashx, then you can do all of the things you mentioned you can’t do using “SharePoint Workflow”.
Hope this makes sense. The reality is that Microsoft’s tool just isn’t very functional, while other tools provide true cross-system Business Process Management in their workflow system.
Allow me to add something here.
i read the marked off content –> “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? ”
Note in BizTalk server, the business rules component allows a business manager to change business rules on the fly. So you really don’t need a developer to be keeping jumping in to change the workflow bases on changing business rules.
Again this is about business process workflows/managements and not the human centric workflow, even if i always think BizTalk can do that with a SharePoint/InfoPath front-end.
Sarbjit
Henry,
I understand your view in comparing the SharePoint Workflows and BPM. Few of the capabilites of SharePoint WorkFlows have been supressed in the post. Overall its a nice read.
Thank you for these points. I still want more interms of functionalities, capacity, flexibility and scalability.