1 minute read
My colleague Mauro Cardarelli wrote a good post yesterday about workflow. We’ve had many philosophical as well as reality-based discussions about workflow over the last few months and I wanted to toss a few more ideas into the mix. Sharepoint 2007 (MOSS) provides the tools to build incredibly complex and rich workflows. However, the toolset is a minor part of what needs to happen to implement workflows right.
In my experience, no one ever really wants workflow, or at least not workflow that will be applied to them. Workflow is, by its very nature, about enforcement. Workflows make people do things a specific, rigid way. For this reason, it is most useful in high transaction rate circumstances, both in number of transactions and in the number of people involved. A good example is online travel sites: they all force us through a specific workflow to make airline reservations because it is the best way to get the task done. We don’t mind so much because the path makes sense to us and it gets the job done.
In a business setting, I would argue that thinking about implementing workflow inherently changes the underlying business processes. In a sense, an observed process is a changed process, and until we spend the time to understand a business process in considerable detail, there’s no way that we can implement a workflow. Changing processes is often uncomfortable for folks.
So, to paraphrase Mauro, take the KISS approach. You can always make things more complicated (read: rigid) later if the user base accepts the simple approach. Also, definitely design the workflow up front with the users (or the "dictators" who are forcing it on the users!) by showing them how a workflow actually works, using real world examples as starting points for the discussion. On some level, implementing the workflow may seem like it is going to hurt, and they need to understand that for you to succeed.