Workflow Blog

It has been a long time since I have written anything but I have been really busy.  If anyone is interested I was just in CIO magazine in an article about workflow.  If you would like to read it you can visit: http://www.cio.com/article/148309/Making_Workflow_Work_and_Flow_for_You/1

Enjoy and happy 2008

In the following article a couple of guys discuss their reasons behind their view that Workflow and BPM are different.

http://www.transformmag.com/showArticle.jhtml?articleID=16400140

I disagree with many of there arguments. 

 Nathaniel Palmer writes:

Workflow is concerned with the application-specific sequencing of activities via predefined instruction sets, involving either or both automated procedures (software-based) and manual activities (people work)…BPM is concerned with the definition, execution and management of business processes defined independently of any single application.  BPM is a superset of workflow, further differentiated by the ability to coordinate activities across multiple applications with fine grain control.

First off I have not heard of a modern workflow system that did not control the definition, execution and management of business processes defined independently of any single application.

Second workflow systems coordinate activities across multiple applications.

Third the phrase fine grain control does not differential between anything.  A bicycle is a bicycle whatever the size.

 Palmer then writes:  As workflow processes are tied to single applications, process flow is hardwired and does accommodate alternative means for reaching the same task or goal.

 Again I have not come across any modern workflow system where this is the case, perhaps he is confusing a system with workflow and a workflow system.

 Finally Palmer writes:  Distilled into single-word definitions, workflow is about repetition and BPM is about coordination (also automation and orchestration, respectively)

 So if workflow is not about coordination, automation and orchestration what is workflow about?

 Next in the article Jim Sinur gives his definition:

BPM is supercharged workflow that has sophisticated flow design through process modeling and analysis. BPM supports hyper volumes of work and numbers of users with sophisticated event-state engines for long-running business events and transactions.   It is user friendly, “insanely open,” has smart agility features supported by rules engines and utilizes commodity integration technologies.

OK I have highlighted all the rediculous sales adjectives here.  What he is saying essentially is BPM is workflow with more adjectives.  According to Sinur BPM is more supercharged, sophisticated, hyper, long-running, friendly, open, and smart workflow.  So he is either saying BPM is workflow with more adjectives in front of it.  A bicycle is a bicycle whatever the hyper-superchargedness it may have.

In summing Sinur declares:

Finally, BPM links to legacy composite components and applications, orchestrates Web services, measures business activity and optimizes processes for better business result and work throughput.

Again workflow systems have done all of the following for a long time now, except for web services which is a relatively new technology.  In addition Business Activity Monitoring in someform has always been a part of some workflow systems it just didn’t have such a fancy title.

Now this may be an almost religious belief but to me it seems that workflow + marketing = BPM, and that is the only real difference. 

PS let me apologize for the long delay between posts.  I have been away alot.

Hi I am back from a very interesting holiday to thailand.  Alot of fun but very touristy unlike when I was there 20 years ago.   I just am doing a quick post about the new workflow patterns website http://www.workflowpatterns.com .  For those of you who dont kow about this site they are effectively organising and naming all the different types of workflow patterns that they encounter.   Sort of like a botanist would the first time he or she enters a jungle.  And it is a jungle out there.  There are so many types of patterns out there and even more names for those types of patterns.  That is why this site is so important.  It is definately giving order where there was chaos.

PS you can even check out how Kontinuum satisfies the patterns (or doesn’t in some cases) since many, many new names for patterns have arised since our control patterns document was created by clicking http://www.workflowpatterns.com/vendors/kontinuum.php 

Since Kontinuum is a web based product alot of our clients simply subscribe to our service.  There are various factor which determine when it is best to subscribe to a workflow software service or simply to buy the workflow software and host it locally.  Here are a few factors which should be considered.  Furthermore many of these factors can be applied to the Software as a Service adoption whether it be workflow/BPM or not.

What is the level of risk aversion?

With SaaS you don’t have to make a huge initial investment.  You can try before you buy.  You can then buy a little and a little bit more as need be.  

 How dispersed are your users?

With SaaS everything is generally set up so that it can be accessed from anywhere.  This does have alot of benefits but there are some drawbacks when it comes to security

How transaction intensive are the workflow applications in dealing with legacy systems?

With web services you can exchange information with legacy systems via web services.  You can do it.  That doesn’t mean it may be all that worth doing.  If you transaction rate is very high exchanging information over the web gets ugly.

How much data is required to be uploaded / downloaded?

Speed can be an issue with SaaS.  Especially if you need to upload or download 100Mb files.   

How big an issue is security?

Remember SaaS is more likely to be a web based product these days.  There may even be legal requirements for data that the information you have is not available on-line.

How much effort is required to get software installed locally?

Sometimes this can be a major issue.  One of the largest banks in Australia came to us and they wanted a system up and running in under two weeks.  Meanwhile another division within the bank wanted a system to be hosted locally.  The division which wanted a local system had to wait about 4 months to get approval where as the hosted workflow applications were created and deployed in 2 weeks.  So it took 8 times as longer to get something approved as to get something done. 

These factors are just a few off the top of my head but I am sure there are many more

This is a history of workflow not as it actually is but as I understand it. 

The early years: 

A hominid grabs a stick.  With said stick he or she makes decisions on how to best maximize the usefulness of the stick.  After picking us several sticks they start to realize that not all sticks are created equal and eventually the start to carry the really good sticks with them so they can re-use the later.  Continually over time the stick is improved by sharpening tying rocks to it.  The adoption of the stick and other tools and there continuous improvement causes much success within the hominid community. 

After a while certain hominids became good at doing different things with sticks and rocks.  Some became good a making things of sticks into boats, others became good at turning rocks into swords; still others became good making food.  In short the hominids got jobs.  These jobs meant that in order for the hominids to achieve maximum success different people had to become skilled at different things but they still had to communicate with each other to ensure that the processes needed to keep their families and communities alive were followed. 

The middle years/ages 

At some point around 2000 B.C. in
India people came up with the idea of a guild.  A guild being a group of dudes who decide that they really know a lot about something and can deliver whatever incarnation of food, sticks and rocks that they work.  The also can deliver their products at a high quality.  Humankind adopts standards.  Not only do they adopt standards for quality but they standardize the methods in which they make their products. 

The Modern Age 

Some guy in France creates a new kind of standard, a specification.  While other standards govern quality and process this guy decides he wants to create guns to such of a standard that all his guns look exactly the same.  Not only do the guns look the same but bits from Gun A can replace the same bits from Gun B.   

I know what you are thinking, sure this article is incredible well constructed and probably deserves a Pulitzer Prize but are we really talking about workflow?Well yes and no.  I believe that at its core workflow is really about the things that I have talked about.  Getting the most of the tools you have, providing standards for production, eliminating waste, continuous improvement and re-usability.  While workflow software might be a somewhat new thing, workflow itself has been around almost as long as we have.

I was looking at one of my favorite sites today, the workflow patterns site by Wil Van Der Aalst, and it occured to me that if you are writing in a procedural language such as C you are effectively doing the same thing as writing out control patterns.  So then it occured to me that there might be some constructs in languages such as C or VB that are not covered by the existing list of workflow patterns (as I understand them).

 Here are some VB,C language contructs that dont really have the same kind of thing in the workflow patterns.

1) Goto:

Yes an outdated language construct and with good reason.  The goto is used to exit out of a context and goto another one and it pretty much forgets where it came from.  With the workflow control patterns they are alot more controlled.  They don’t skip all over the place as is the case with goto.

2)  Kill Process / Exit Application

If I am in a proces within a process within a process there does not appear to be a way to exit the high level process without creating a whole bunch of control logic with the currently defined control flow patterns.

3)  Wait

I am not really sure if this qualifies as a control flow pattern but it kinda is.  When getting to this stage just don’t do anything for a period of time (irregardless of what else is going on in the system).

4)  Queue and Stack

You could argue that both of these structures are not control patterns but for the sake of arugement I am going to argue that they are.  Lets say we have 3 tasks running in parallel 1.1, 2.1, 3.1

after one point 1.1 comes 1.2 after

after one point 2.1 comes 2.2 after

 after one point 3.1 comes 3.2 after

here is the catch however for queue:  1.2 can only be complete if and only if 1.1 was complete before 2.1 or 3.1 or x.2 is completed i.e. First In First Out

here is another possible scenario 1.2 can only be completed if it has not been completed and it is x.1 has not been completed later than it or x.2 has been completed. i.e. Last In First Out.  The interleaved parallel routing construct doesn’t exactly cater for this behavior.  You may argue that it is more of a resourcing pattern but I would need to be convinced.   You could also argue that this is more of a multiple choice, which in many ways it is.  However the logic at the point of choice could become very difficult to express at the point of choosing which x.2 item is next.

It has been a few weeks since my last blog and reason why is that we have just finished implementing the first of a few applications for one of the four major banks here in Australia.  The interesting thing about this project was not the hours spent creating working workflow applications, but the weeks making things look pretty.  Or in some cases not that pretty but to customer specifications.  As a techie I am still struck by how most users would much rather have something semi-functional that looks pretty as opposed to something that actually works.  I think in the end adopting a workflow system is not a rational decision based on return on investment but rather still an emotional decision. 

While the workflow industry is still in growth there is relatively little head to head competition.  However as more and more companies start competing head to head it will not be the feature set that customers will look at in making decisions.  It will not be support.  It will just be, is it pretty to look at and easy to use.  I am not sure any analysis by Garter et al really comes close to capturing this information.

First let me try and tell you what I am babbeling on about.

What is logic synthesis?  According to Wikipedia Logic synthesis is a process by which an abstract form of desired circuit behavior (typically register transfer level (RTL) or behavioral) is turned into a design implementation in terms of logic gates.

What is Multi Level Logic Minimization?  Well once we have reduced a circuit into gates MLLM uses a series of computer algorithms to redesign the circuit using as few gates as possible.

Why should I mention this in the workflow blog?  Well first off workflow design and circuit design are VERY similar.  You only need to look at the www.workflowpatterns.com and see how so many of the patterns are common logic circuit gates.  Second with the uptake of workflow software I think that workflows may become more complicated because the added power will allow people to create more complicated and more variable business rules (but that is a different debate).  In addition workflow systems are being used to handle larger and larger systems with more and more integration.  So effectively our workflow circuitry is getting bigger.  This means it will become more and more difficult for a mean mortal to optimize the workflow.  This is where MLLM steps in. 

Imaging one day having a system that does the requirements gathering from the users and then hitting a magic button and a workflow system is created.  This created system is not an electronic version of the current ‘AS IS’ process but a 100% optimized and re-designed system.  The time delay from when a business decision maker makes a business decision could be non-existent…..maybe I am just dreaming.

This is in reference to the following article:

http://kswenson.wordpress.com/2006/07/09/what-bpm-can-learn-from-a-spreadsheet/ 

Can business users make their own workflow applications, well yes they can. My girlfriend’s father who is an accountant with zero programming training created a simple 3 or 4 step BPM application using Kontinuum. I think the key word here is simple. Programmers are more likely to see the problems a little bit differently and their concerns of maintainability, reuse etc would not be at the forefront of the mind of a business user. This would mean that as workflow systems tend towards greater complexity the non-programmer would create a less and less cost effective solution.

As for the first question of Business office workers will never program software well they are already doing so. Not only in excel type applications but also in creating BPM applications.

Another counter argument is that the application is purpose built. Well every language was built with a purpose. Take C and Prolog. Built for different purposes. Are neither of them programming languages? If you submit that they are because ultimately they could achieve all the functionality of the other albeit in an often convoluted way well then couldn’t a BPM system deliver such functionality albeit in a more convoluted way?

As a final though some people have said that 3gl is not programming. OK why? Because it is to easy? Because you don’t have to type? The important part of programming is logic. If you can deliver to a computer that same logic through dragging and dropping something as opposed to typing it out what should it matter. If not then isn’t 2gl not programming either? Should we real programmers go back to binary?

OK or atleast went hollywood.  Has anyone ever seen the Coen Brothers movie The Hudsucker Proxy starring Tim Robbins, Paul Newman, Jennifer Jason Leigh, the dad from Frasier and my personal fav Bruce Campbell? 

Well it has the best illustration of workflow I have ever seen in film.  The sequence starts with the go ahead to produce a new toy and follows the series of events and signoffs needed to approve the toy for production and then ultimately the production, distribution and sale of the toy.  It is really quite amusing and one of the best parts is when you see hundreds of rubber stamps flying in the air approving various things.  

It does illustrate how long before email, networks or even computers workflow was an important part of the function of large organisations. 

I am just reading the book Crossing the Chasm.  To summarize the book (and not do it justice) the book is about the a period in selling whereby clients transition from people who are deem in the early adopter category (people who see a new technology as way to give them a radical technological advantage over thier competitors) to the early majority (those people who see the adoption of the technology as a way to steadily increase the efficiency of thier business). 

The book also a few other categories: the late majority - those who are very trepid to adopt technology and will only jump onboard when they feel they are being left behind, the laggards - those people who will only adopt the technology when they are forced into it, the innovators generally those who came up with the concept or enthusiasts who are just excited by new technology. 

 So what does this have to do with workflow?  Well I think that the market is crossing the chasm if it has not crossed it already.  It has been my experience that the companies who are adopting workflow software are for the most part doing it because they see an incremental efficiency gain.  They are also not willing to place there bets on unproved technology.  An arguement could be made that we are still in the early adopter phase.  Currently some of our clients see it as a way to dramatically alter they way they compete, however these clients may be less tech savvy or in more niche industries.

When designing workflow systems you may be faced with try to optimize the performs of your resources (by resources mean anything from people, machines, parts, space in a warehouse).  Well there are a few things you may need to consider.  Lets take for example a manufacturing environment.  In order to schedule a resource to perform a task you need to ensure that the task can be done by the resource.

 It may need an array of constituent parts or componenets to perform the task

 It may need to have an allocation of time

 It may need to have capacity downstream

 It may need to have an alignment or syncronization of all of the above.

Lets say I am making computer equipment.  I have a giant machine that can make computers and monitors, I just pour in silicon and out pops a computer or monitor.  In sucessfully make a run of 10 computers I may need to ensure that

A:  I have some silicon

B:  I have a spare slot where I can use the machine

C:  I have space in my warehouse to store the machines once I have made them

D:  I need to ensure I have the silicon, slot and space available at the same time.

In some ways resource scheduling is like a game of chess, you are much better off if you can think several moves in advance.

BTW I am off to Beautiful British Columbia (Victoria and the couv) for a friends wedding - weddingabovetheclouds.com talk about overkill, anyways that means that I will most likely not be posting anything until mid august.

So what is the most important workflow tool?  According to the BPM Trends diagramming software was the most important BPM tool.  I must say I disagree.  The humble pencil is probably the most widely used.  It just didn’t make the list because it is not a software tool.  Yes no matter how complex or sophisticated the software whenever it comes to initial design the pencil or pen or marker is always the place to start.  Sure other tools can automate, make prettier diagrams, report information or all of the above, but without correct pencil usage not technology is going to save you.  Also the user interface could not be easier to understand.  The design capabilities of the pencil are not limited to the workflow BPM arena either.  With Software, Automobile, Graphics, Interior, Building, Landscaping Design generally the pencil is the best place to start.

Over the past couple of weeks we have been including more and more AJAX functionality into our product.  AJAX is quite cool.  It really does enhance the user experience.  It is my personal opinion (I am not speaking for Web and Flo here) that of all the things that people are developing for workflow systems not enough is being done to give users a truly pleasurable experience.  OK pleasurable may not be to strong a word.  I think alot of effort these days is going into modelling and simulation.  Which is alot of use for the tiny percentage of workflow system users who happen to be designing and modelling such high throughput processes that it is really important.  For the vast majority they could not care less.  I believe that many workflow vendors are spending alot of time creating these simulation tools because of the ability to market them not for the actual use to clients.  I guess it may be easier to sell a workflow system that has simulation that you will never use as opposed to one that does not but is easier to use.  Maybe it is just to much selling the sizzle.

PS I may be biased as the companies we deal with are generally smaller.

PSS Also this is just my gut feel and I do not base my assumptions on any hard scientific data.

Please post a comment if you disagree.

A few more quotes before I get back to actually writing my blog.  These ones come from two of my favorite films.

All he’d wanted were the same answers the rest of us want. Where did I come from? Where am I going? How long have I got?

-Bladerunner

Stanislavsky said the actor should constantly ask himself as a character: “Who am I? Why am I here? Where do I come from? And where am I going?”

-My Dinner with Andre 

These top two quotes are essentially the same.  How do you relate them to workflow.  Well I think for every user or character within a workflow system they need to easily see within a processes: where they are, how did they get there, what they are suppose to do, what is going to happen next and how long do they have to complete the step.

And if you’re just operating by habit, then you’re not really living. I mean, you know, in Sanskrit the root of the verb “to be” is the same as the verb “to grow” or “to make grow.”

-My Dinner with Andre 
This quote seems to get at the heart of what empowers workflow management systems or BPMS.  That is the notion of continual improvement or continual growth.  It also implies that if you cease to grow you cease to be.  So many people working in systems today are really just operating by habit, without a thought of how could this process be easier.  It is not their fault they are just not exposed to something that allows them an overall view of what they are doing so they can make suggestions or changes.

Again I am taking some quotes and applying them in the context of workflow.

“The sculptor produces the beautiful statue by chipping away such parts of the marble block as are not needed -
it is a process of elimination.”
 - Elbert Hubbard

I like this quote and it is in essence what process reengineering is all about. 

Many ideas grow better when transplanted into another mind than in the one where they sprang up. 
- Oliver Wendell Holmes

Although perhaps not immediately apparent this is a key benefit inherent in workflow systems.  That one initial person or team can create something but that it can be improved upon by others.

I am a bit tired of all these so-called standards for workflow running around these days.  In fact I am a little tired for alot of these so-called standards that are plaguing the IT industry in general.  Many of these standards are simply marketing tools.  So I have decided to release my own standard as a silent protest.  The Workflow Area Network Control Standard pronounced Wank.  In order for a site or product to comply with this standard somewhere in the site or product you must have written: This site is WANC Compliant.

I know this will have gone to far when some day someone tells me with great pride that thier site or product is WANCs Compliant or I get a call to do some WANC consultancy.

Show your support against meaningless standards and support this equally meaningless standard by becoming WANC Compliant Today!!!!

Many moons ago I wrote an article on neural workflow.  The concept of taking a neural net approach and adopted it to business processes instead of how they are currently done which is more of a source sink based concept.  I have thought a little bit more about the concept and I thought I would share my thoughts. 

First businesses gain a lot by having systems that help automate and manage their source/sink based processes however businesses are more then the sum of their processes.  If you were to draw a directed graph of communication or the flow of information within an organization it would look a lot like a neural network.  Workflow / BPM as it becomes more advanced is moving away from merely trying to automate ‘Standard Processes’ to automating larger, more dynamic and disorganized processes.   

When you start to embed workflows within multiple other workflows you are starting to create a kind of neural net.  Although I have never had a hand in creating a workflow A, which creates an instance of workflow B, which in turn creates a new instance of workflow A I can envisage many instances where this may be required.  I am sure one if not more tools can already handle these kinds of scenarios, but are they effectively communicating the overlaying structure to designers in an easy to understand way? 

How do we learn to speak neural net as opposed to flow chart?

Well the current tools / Notations / Standards for expressing neural nets are not as easy to work with as with sources as sinks.  Source Sinks can usually be read top to bottom or left to right.  Even the most complex processes can usually be mapped onto a two dimensional piece of paper.  With Neural nets it’s a lot more difficult.  There are just too many interconnections and not enough and there isn’t a side of the page for sources and one side of the page where the sinks are suppose to be.  Maybe we need some sort of 3 dimensional structures.    

I believe ‘neuralness’ is the way forward as businesses are neural entities and not just a series processes.  The challenge for workflow will be to deliver easy to understand solutions for these problems. 

..Yet again I ramble.

HTML is great.  It is everywhere.  It is universally adopted.  Why?
Well first off it has well and truly exceeded critical mass.  It has not changed much.  But perhaps most of all is because it was a technological fit.  Browsers get information in the form of HTML, parse it then display it.  The data in HTML is all very linear.  It is always read top to bottom. 

Data in almost any database is not linear.  Fully normalized databases need different types of data in different places.  They need indexes for quick searching and matching information from location A to location B.  When it comes to having complex information structures or just a lot of information having a flat file that needs parsing just is not going to do the trick. 

Danger Will Robinson Danger.
All standards that people seem to be coming up with these days, not only for workflow but everywhere else seem to have an XML basis.  XML is easy to understand and you can store any kind of hierarchical data in it very nicely.  You can also store normalised data in it.  The problems arrive from the performance issues of trying to retrieve information from the data.  The current technologies are pretty slow.  Without some sort of indexing mechanism they will continue to be slow.  If such an indexing mechanism is built we congratulations you pretty much built a database system.

The second problem I have with XML is the high sugar content.  Syntactic sugar of course.  A while ago I worked with a program where logic rules were written in XML and maybe it damaged me psychologically.  Consider the following VB code
If a > b then c
In the xml language it translated to
<if>
<comparison type=”>”>
<firstvalue>a</firstvalue>
<secondvalue>b</secondvalue>
</comparison>
<then>c</then>
</if>
So instead of 15 characters I now had to type 110.  Now this language may now have been al that well thought out but any kind of XML based language where you have to perform some kind of logic is going to be a little too sweet for my taste buds.

My third problem with the current standards is that there are so many.  How many standards can you have being used before all of them can no longer be called a standard?  There are also many new ‘standards’ on the way.  Oh Tim Berners-Lee where art thou? 

So now that I have rambled seemingly aimlessly for a few paragraphs perhaps I should share with you the point I am trying to make for this article.  My point is this:  is there a better option for an underlying technology for creating standards for all the things in which we are starting to use XML in regards to workflow.  (I don’t really have any suggestions btw).  The technologies like BPEL and wf-XML etc could be good for exchanging information between other compliant systems but I don’t think they should be built upon for doing the grunt work in large multi-workflow implementations. 

PS If you feel that I am wrong or just plain delusional feel free to post a comment.

Christopher Koch writes an interesting article about SOA and BPM, and I think I will weigh in on this debate. 

The Koch Article

In short it is about the disconnect between IT and the commercial side of a business.  It argues that in workflow/BPM business has found its champion to bridge the business/IT divide while IT wants to use SOA to fill the gap.

Well there are a few comments I would like to make on this article. 

First BPM is a Service Oriented Architecture in a sense.  It is just that it is not as open and available as most SOA.  BPM/workflow products can act as services and they are part of architecture. 

Second (and let me point out I am in IT and geek blood pumps through me veins) is to never let IT be the guide.  IT will create the most amazing technically challenging things that will be of not value to the business.

To read the referenced article in its entirety (and it is a interesting way to spend a couple of minutes) visit.

http://blogs.cio.com/node/310 

A lot of BPM/Workflow systems use a state to provide some information to the user as to where a workflow instance is at.  Other systems rely on this state as a key piece of information to keep control of where a workflow is at.

This may be less then a good idea.  The reason only becomes apparent when many tasks within one workflow instance can be worked on in parallel.  Lets pick an example where there is only one task in each of these 3 parallel lines of control.  Each of these steps is either completed or not completed.  Therefore there are 8 possible states.  Having a process that has 8 different states is already at the limit. 

Now consider there are 5 parallel lines of control.  In each of these paths there are 3 tasks which need to be completed and are done some in a series.  So in each path there are 4 states no tasks completed, 1 task completed, 2 tasks completed and 3 tasks completed.  Because we have 5 parallel lines of control we have 4 to the 5th possible states or 1024 states.  And having this many parallel lines of control is not by any means extreme.

All I can say is be weary of any kind of workflow system that is overly reliant on a state concept for tracking the progress of a workflow instance because it can leave you in a very sad state.

In an interesting article http://kswenson.wordpress.com/2006/05/06/workflow-is-back/ K Swenson write about the changing of the word workflow into BPM over time and how the term workflow has gone out of favour.  In fact if you look at Google trends the searches for the words workflow has gone down a few percent over the last few years.  (Although the news items containing workflow seem to have doubled).  Is this the end for workflow as a technology?  As a name?  Well neither.

Workflow as a Technology

 I read via Gartner that workflow is still expected to increase in the 5-10% range over the next few years.  Although referred to workflow systems as Business Process Management Suites by Gartner.  Also an increasing number of companies have recognized that they need to invest in workflow systems. 

Workflow as a Name 

People are starting to use many other terms in place of workflow: such as Business Process Management, Enterprise Application Integration, Service Orchestration Architecture.  That is the way of people that work with computers.  We love a good acronym.  The marketing people also love a good acronym.  It can make their products sound better.  Instead of a workflow systems why not have a Business Process Management Application Integration Service Oriented Uber-Mega Platform.  Well there is one group that is less swayed by all the fancy talk.  The people who buy workflow systems.  Most after initial investigation realize that all these other systems are workflow but just using another name and from my experience they just want it to be called workflow. 

I have an idea.  It may be a good idea and it may be a very bad idea.  To quote spinal tap - "such a fine line between stupid and clever".  What if most of the way in which a company operates was based around a series of workflow applications that used a single workflow suite.  Now what if you decided to give everyone within the company access to create, modify and delete workflow templates?  Would this be a good idea?

Consider Wikipedia. 

Anyone can access it.  Anyone can modify the information.  It seems to be a well-spring of information the vast majority of which is correct.   

The benefits could be immense.

The Company would adapt quickly to change.  Also if anything happened outside the scope of the workflow the workflow could be quickly adapted so that all information is held together.  There would be no alternative flows because these could easily be catered for in the new system.In short the company would be making its IT systems incrementally better on a daily basis. 

The Risks are enormous

Imagine coming into work one day and some or even all of your core systems do not work.  The problem is many workflows may reference different aspects of many other workflows or systems and changing one could adversely affect many others.  What if changing a workflow sends the wrong information to clients.

What would be required at minimum

Some great things about Wikipedia is that it tracks who made changes, when and why.  It also allows you to easily rollback information to a previous version.  These would be absolute requirements for free for all workflow development environment.

The Workflow Design Studio would need to be as easy to use as something like Wikipedia.

The Workflow Design Studio would need to tell you if you change something what else might be affected.

The Design studio would need to be web based for larger dispersed organizations.

The Design studio would need to ensure that information is not lost when workflow templates are altered.I think some day some small company will try this. 

They will either be very successful or will never want to speak of it in public.

When I started this little blog I wanted it to be both fun and informative.  Well I can't for certain say it has been informative to everyone who has read it.  So hopefully this next post will add a little fun.

 A workflow haiku

Like a flower grow

with all the power to know

just add some workflow

Poetry attempt number 2

Is your staff working in the blind?

Do feel somehow misaligned?

Do your systems have creaky joints,

and far to many chokepoints?

Are things slower then they should be?

Is data not stored centrally?

Is your data safe from attacks?

Are things falling through the cracks?

A simple answer is what you need

and you will find sucess shall breed.

If not much separates you and them.

You just need some BPM.

OK so it wasn't that good but hey nothing rhymes with workflow.

I am a little too busy to write a blog entry this week so I have asked an associate of mine to write one for me. In her article she is drawing on the experienced gained from using a workflow management system in the HR arena.

Human Resource processes cover the entire business, whether you are discussing Travel or Leave Requests or even the task of hiring a new Employee. For every HR process, there is a series of activities that involve other people, managers and staff from at least one other department within the company.

Workflow Management or BPM can automate any HR process where people, systems and businesses interact. It calls upon the appropriate tools and supplies necessary information, business rules, check lists, task lists and reports to the Employee.

A HR process may require interaction from many departments. Therefore, HR processes are well suited for automation because typically these processes are paper based, manual and prone to error and delay.

Employing a workflow management system to automate high throughput, repetitive processes, such as Performance Reviews, can have a profound effect on every aspect of the process. For example, when the Performance Review process is automatically started each month, it can check to see which Employees need to be reviewed and creates an instance of that process in the appropriate Employee and Managers task list for action.

The steps may then follow as such:

The Employee completes their part of the Performance Review
The Manager is then alerted that the Employee has completed their part and the Manager reviews the Employees responses
The Manager and the Employee meet and discuss the results
The Manager may then enter the details of the discussion with the Employee
The Manager marks the review as complete and forwards either to their Manager or to HR
Business Rules are placed throughout each activity or step in the process to ensure that data is entered correctly and escalations occur if any of the steps are delayed unnecessarily
Everyone in the process is notified of the completed process
The results of the review can then be exported to the companies Payroll system if required
Using workflow management to automate these types of process streamlines operations by reducing the data entry to key people; thereby reducing errors. Automated steps do away with many of the Employees most mundane tasks, leaving them time to focus their energy on their jobs. A business process is structured so each instance is managed according to the same business rules, every time. This consistency provides stability in the business and predictability for Employees.
– Anna Fogarty

The driver behind workflow has been around for a long time.  It is only recently that the technologies on which most workflow systems are based have enabled vendors to create quality workflow management systems.  So what was the original driver for workflow.  One word Kaizen.

Kaizen is the Japanese term for improvement; continuing improvement involving everyone: managers and workers. In manufacturing, kaizen relates to finding and eliminating waste in machinery, labour, or production methods. Also see: Continuous Process Improvement (definition taken from schools.cbe.ab.ca/logistics/k.html)

Workflow Management Systems are not about taking an As-Is process and creating something better.  They are about taking a process and providing it with a framework so that is the process is easier to improve over time.

Kaizen originated at Toyota and I have read and heard several comments with how the concept of continuous improvement is what has lead them to become the worlds largest automaker.  Well I am no expert in Kaizen but I do believe that that organizations that seek to continuously improve stand a much better chance survival.

For more information on Toyota and Kaizen you can check out the flash heavy website at http://www.planetkaizen.com