Business Process Workflows


Tech Trek Log – 2010.01.15

I’ve recently completed a workflow project for a client and I must say advances in such technology area really takes business processes management (BPM) into the next level of office automation. Below is a list of features of the 3rd party workflow product we’ve used as compared to the FREE SharePoint Designer by Microsoft.

SharePoint (Designer) K2 blackpoint
Easy to use due to simple conditional logic Drag & drop UI but more complex wizard options
Sequential (linear) steps Branching/looping structure
Reassign or basic routing options Static or dynamic routing; allow redirect, delegate or escalations
Cannot create folders, or start another workflow Allows to create, modify, or delete sites, lists and libraries
Bound to one list or library Access within site collection; save and share templates
Workflow admin per list/library Centralized admin site
Silo of workflow processes Share info between processes

Here are some of the decision points needed before such workflows are implemented:

  • How will the data be collected? What UI is used (InfoPath, SharePoint list, MS Office app, other clients)?
  • How should the process start (automated and/or manual)?
  • How many milestones (i.e. activities or approvals) are needed?
  • What type of events are needed – client (user interaction) or server (system-based)?
  • What is the sequence of steps and its conditions, if any?

To summarize, the implementation team requires knowledge of InfoPath or other client used, including SharePoint concepts for integration/testing purposes regardless of workflow tool choice. The biggest challenge here in any organization is the change in development model and shift of mentality from manual procedural operations. This endeavor then is not taken lightly especially if an organization recently rolled-out SharePoint within the company.

If done correctly, this effort is revolutionary as I initially mentioned in this blog post. Why? It reduces implementation by using rapid “no code” visual-based design approach on form clients and allowing changes to business processes on-the-fly. No more excuses that it will take months to build an application since most of the heavy lifting that developers used to do is already built.

As a lesson learned in these tough economic climate — it is tempting to deploy technologies that brings the biggest bang for the buck without consideration of user acceptance. Thus, it is much wiser to take baby steps first for a succesful adoption within the development team and people using the system. Also, it is good to establish a change management rule of replacing one piece of technology at a time to make system issues more manageable before doing an “all or nothing” approach.

For additional info, I will include them in future postings, or feel free to contact me and I would be happy to share the details.

UPDATED: 2010.02.09

Advertisements

2 thoughts on “Business Process Workflows

  1. Jon

    Great article Fred. BPM toolsets are also revolutionary because they are so effective at bridging the IT/Business “gap”. With these new and powerful visual workflow design tools, we can finally empower direct business ownership of the high level process, with seamless drilldown integration to the actual technical coded functions and methods. This makes analyzing your process for inefficiencies, bottlenecks, and failures so easy as well! In my mind BPM is the promise of object-oriented programming finally realized. The emerging role of “system architect” has matured rapidly over the past decade, in part due to BPM toolsets, and it will be interesting to see whether it continues to be a position held by senior level devs, or if it starts to become more a function of the business teams. Just out of curiousity, what was the “3rd party” offering you evaluated? Excellent first blog post, looking forward to reading more from you!

    1. Fred

      Thanks, Jon for the comment.

      Finally, the technology has matured to point where we can create applications using any client (with the advent of Web Services) as indicated by my next post, and organization’s choice of the backend infrastructure compared to previous monolithic systems.

      There are still areas for improvement since doing integration with these different moving pieces is the most challenging part of the implementation.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s