|
(2/15/00) New! XML process definition.
Our next trick is the organization of a trade show. This was the second of the scenarios proposed in the original
RFP, and after the chair scenario was so easy to model, I thought this was going to be simple.
Let's look at the actual things done in this scenario. First, the person who initiates the workflow this time isn't
a spectator, as the chairless employee was in the chair scenario. In this case, the person who initiates the process
is the organizer. In the jargon, this role is often called a case worker because each instance of a process is
a case (so, for instance, an insurance case or a loan application). The case worker is responsible for the entire
process, even if other people are doing some or most or even all the actual processing.
So OK. Our first role is thus the Organizer, who is responsible for monitoring the process and making sure everything
gets done. If people have problems, the organizer is the person who solves them. If special action is required, the
organizer is the person who takes that action.
Since I've never organized a trade show, I made up four actions required. You can elaborate as you see fit. But in
general, the whole process is kind of like this:
- Organizer assigns roles and starts process.
- Somebody books the hotel.
- Somebody creates a floor plan.
- Somebody roughs out a schedule.
- Somebody books the caterer.
- Produce a brochure listing the hotel, showing a floor plan and the schedule.
Obviously the entire process would be considerably more complicated: the booths are reserved, the rooms are blocked out,
the tickets are sold, and so on and so forth. But this much already illustrates all that this example will illustrate,
so I'm not going to waste time going into too much detail (although it might be interesting later to show a really complex
example and this one would certainly be interesting to see in full-blown glory, with pictures and arrows and four-part
harmony. For instance, booth reservation is a completely asynchronous task, depending on people outside the organization,
communicating by mail or something.)
PERT charts and task dependencies
When I got down and started drawing the RAD for this process, I noticed a few things. First, the order of the tasks needn't
be linear -- but they can't be done in just any order, either. For instance, the caterer could be booked before
the hotel is booked, but we can't create a floor plan without knowing which hotel we're going to be in because we don't know
the size or layout of the convention rooms there. The RAD isn't set up to represent this sort of
prerequisite relationship. The graphical formalism most people use to show tasks which depend on one another is a bunch
of boxes with arrows between them: a PERT chart. (PERT was formalized by the military and it stands for Program
Evaluation and Review Technique. Sigh. These are the people who call a pair of glasses a Vision Correction Device.)
The thing about the PERT chart is, everybody uses it automatically. It's the most natural way to show tasks in a project
and which tasks have to be done first. Unfortunately, the PERT chart doesn't really show roles well, so it abstracts away
some of the information most useful in the RAD.
Here is this project shown as a PERT chart:
As you can see, PERT charts are extremely easy to understand, which is the main reason everybody uses them. But after I
drew this, I realized that it can be translated back into the RAD pretty easily, and this is the result:
 | where:
Or is the organizer
Gr is a graphic designer
and X is
everybody else.
|
Now, I find it easier to see the task dependencies in the PERT layout, but you can see the same structure in the RAD as well.
Once this project gets into a sufficiently advanced state that we're considering graphical tools for workflow representation,
I propose that we use both. (Another useful layout is the Gannt chart, which I won't be using in these usage scenarios, but
suffice it to say that Microsoft Office uses PERT and Gannt for project display.)
Task assignment
Although task assignment was part of step 1 in the original description of this scenario, I don't think it belongs in
the process definition at all, for a couple of reasons. First, we don't need to assign roles until each task becomes
active. We might have some ideas about who should do what, but there's no reason to force that early on, because then we
might just have to change it later anyway. Second, task assignment must ultimately be done in every project for every
task, so it's silly to have to represent it in every one.
That said, task assignment could be as complex or as simple as it needs to be. A manager may assign all tasks. Or the
different workers may choose tasks to suit themselves. Tasks may be prioritized, or some other system may be used to force
task assignment: first-in-first-out, last-in-first-out, and so on. In fact, if we consider each role a queue, there is
an entire branch of mathematics (strangely enough, called queue theory) which describes and compares different
strategies of task assignment. Ultimately the workflow engine should support any number of task assignment strategies.
A further lesson about roles and task assignments is apparent from this process: basically, except for the special role
of Organizer, anybody could perform the other tasks. Well, presumably the preparation of the brochure would fall to
a graphic designer, but the other organizational tasks could easily be in a single role. The organizer could perform
some or all of them, or could delegate all of them. They could be performed by one or more people.
Deliverables
This task is different from the chair scenario in a further respect: the process itself, and some of the internal tasks,
have deliverables. A deliverable is an object or document which is created during the task or process, and which is
the point of the process, usually. In this case, one deliverable is the brochure, another the floor plan, another the
rough schedule. The deliverable of the overall process is in a sense all these together, as an information packet or
something.
Usage
It might be a good idea to consider how such a process would be used, especially given that this is a usage scenario.
A process is initiated either by anonymous trigger
(say, a customer clicks on a customer-service form button), or by a system user (the chairless employee or the trade show
organizer.) Each role can be considered a queue, as I mentioned above, and so the tasks which start the process off are
placed in their respective role queues. The tasks are then assigned as specified in their own definitions: either they're
assigned automatically, by hand by a manager, or people who belong to the roles choose tasks from the queue. Once a task
is assigned (or chosen, depending on how you look at it), the task is active and the actor is working on it. A task may then
complete normally, it may be thrown back (say the person assigned calls in sick; the task must be reassigned), or it may
fail. (If it fails, this is an exception, and either the process must define an exception handling procedure, or the
process owner must take some corrective action.)
As tasks are completed, they trigger new tasks, and notification may also be sent to various people. These new tasks
enter their respective queues as they are activated, and so forth.
Compound workflow
(1/24/00) After the above was posted, Anthony O'Krongly came back with some excellent
feedback, to wit:
The trade show flowchart is a good attempt. It doesn't correspond with what
we do, but it does show another example of how the application will work.
Let me see if I can explain what I was thinking when I put that in. (You
don't have to change the existing chart. This is just a demonstration of
our vision.)
#1. Take each item in the existing workflow and make it a separate workflow
similar to the detail included in the "Chair Request" workflow. Booking
hotel, creating a schedule, creating a floor plan, etc. would each be a
separate and distinct workflow.
This does two things.
- It keeps it simple. Each workflow can be set up as needed by the person
who most intimately understands what's involved.
- It keeps it flexible. By "Grouping" (See #2 Below) simple workflows
into "Compound" workflows the system becomes very flexible. If one piece of
the Compound workflow no longer applies, it can be quickly and easily
removed. The same is true if you want to change a piece of a workflow.
Some very simple workflows would be used repeatedly in numerous compound
workflows. I can't think of an example at the moment, but it will happen.
Then if some aspect of that often reused simple flow changes, then all the
others will change automatically.
#2. We saw a workflow as complex as a Tradeshow setup being comprised of
multiple simple workflows that are all GROUPED TOGETHER. Let's call this a
COMPLEX workflow.
Does it sound crazy? Let's call it the Internet Chaos Paradigm. Take
something as complicated as the Internet. Billions of pages, millions of
sites, etc. It's crazy and unmanageable!!! But with each person doing
their own part in their little corner of the web it works out fairly well.
Give users an easy, consistent interface and all of a sudden something which
is Chaos Incarnate becomes smooth sailing.
So, here's how it relates to our little application.
Sally, the buffet booker, sets up a workflow that helps her set up a buffet.
Jon, the media guru, sets up a workflow that helps him coordinate hotel
media for meetings.
Steven, the Tradeshow booth expert, sets up a workflow that helps him plan
booth space layouts
Etc. Etc.
Now Vice President G.O. Devine (GOD for short)- who is over the tradeshow
department wants to set up a master workflow for setting up a tradeshow.
Since he's a bright guy with a Management Degree and a 2 pm Tee Time, he
takes all the flows created by his busy minions and groups them together.
Maybe he adds a little workflow in front of the group that says, "Start the
busy bees on their tasks". His "intro workflow" might notify some people of
deadlines or whatever. He call this Complex workflow "The Hand of GOD"
A client calls and says, "I want a tradeshow". GOD runs his "Hand of God"
workflow. It asks for some info and then starts all the other workflows
when it gets to them. Viola, the simple becomes complex. The hard to
manage becomes easy. The incomprehensible becomes compre.... You get the
idea.
Now, I know I left out some details. But that's the goal. Goal #1 - Figure
out a way to make a simple workflow. Goal #2 - Figure out a way to group
simple workflows TOGETHER both linearly and in parallel. Goal #3 - Go have
a beer because you're done.
In short, the existing RAD works pretty well, as long as you realize that a
task may actually represent an entire process. Actually, we're going to see some more
examples of this in a couple of the other usage scenarios but Anthony's vision of cooperative
workflow is just so impressive I had to include it now. This allows the organization of
workflow to mirror the organization of the work -- Susan knows about buffets and so Susan
defines what it is she does. GOD wants to make sure the whole trade show comes off and so
his workflow coordinates everybody else's. When Susan realizes her process doesn't work
very well, she can change it -- and nobody else is affected in the least! It's beautiful.
Summary
Again, a short list of things that look like requirements:
- Tasks may have deliverables.
- Tasks may have complex dependency relationships.
- PERT charts are nice.
- Roles are queues, and task assignment may be arbitrarily complex.
- Exception handling (what to do when things go wrong) must be handled, if not perfectly then at least gracefully.
- An individual task may represent a subprocess.
|
