[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Phpgroupware-developers] workflow as a feature in phpgroupware
From: |
Craig Allan |
Subject: |
[Phpgroupware-developers] workflow as a feature in phpgroupware |
Date: |
Fri, 2 May 2003 13:09:52 +0200 |
With reference to the discussion between core development team on
http://www.phpgroupware.org/devteam/wiki/index.php?page=WorkFlow
Workflow systems are *very* *very* useful to most organisations.
If you do want to include workflow, it is not a trivial task. But it
is possible to put together a low-end system for general use - the
hardest part is designing a simple UI which hides all the complexity.
My impression from the page above is that the team is immediately
leaping to see how it will work technically without first getting the
underlying concepts right. It is better (IMHO) to work first on the
concepts and then code them.
I have been implementing a basic workflow system for my own use,
mainly to track the aproval and construction of engineering projects,
using Linux/Apache/MySQL/PHP. I provide some of my experience
below...
MY DESIGN APPROACH
Workflow is a way for an organisation to create an assembly line for
any process. Something - we can call it a "Work" object - is fed
through the organisation and various things happen to it as it moves
through.
There are three "R" words (in english) that are important.
ROUTES - there is a path which a Work object follows through the
organisation - this is a route. Almost always the route branches many
times, with each branch being based on a decision. There is thus a
network of routes, which branch (or come together) at decisions -
Decisions can be seen as objects - I call those DecisionPoint objects.
RULES - these are the basis of decisions made at DecisionPoint
objects. Some attribute of a Work object is tested, and the Work
object is then routed according to the result of the test. All
routing is to another DecisionPoint object.
ROLES - this is the duty of a human being, and it is associated with
a DecisionPoint object. The human will apply intelligence to the Work
object, do work on it, add information, change some of its attributes
and submit it to the RULES for a routing decision.
Some technical stuff.
Any DecisionPoint is associated with a input queue. This is simply a
queue of incoming Work objects waiting for a human to do something to
their attributes. The human who belongs to that input queue will
process the Work objects according to his/her ROLE, which changes
their attributes, and will submit them to the RULES side of the
DecisionPoint which will make a routing decision, based on the
attributes, and send them off to the next DecisionPoint.
The human should be able to view the input queue, to open any waiting
Work object, to edit attributes as required and to submit it. There
are various details about the status of Work objects in the queue
which we can skim over.
The input queue should be linked to a notification system, (e-mail,
SMS, other...) to warn humans of arriving Work objects.
More technical stuff...
It is highly desirable that the workflow system works with a document
management system. Much of the work the humans do will be supported
by attached documentation. The humans will want to create, read,
amend and delete the attached documents.
This requires that the Work object contains pointers that identify
associated documents. You can stuff documents into binary large
object (BLOB) fields, but I prefer to leave them in the normal
filesystem and save a unique resource identifier (URI) in the
document fields.
Much more technical stuff...
A Work object only has workflow system intelligence associated with
it. It does not absorb and integrate other databases.
A Work object can be associated with a huge amount of data. For
example a simple workflow for a credit check can have links to
criminal records, salaries and wages, marriage and divorce status
etc, etc. This information is not part of the workflow system. In a
sense it is unrelated attached data. It is data the human will use
to change one or two attributes on the Work object. Don't try and
incorporate it into the system - just point to it with a URI.
(If you are designing a huge single purpose system then you can
integrate everything, but resist the temptation as long as possible.)
Even more and more technical stuff...
An administrator will need to be able to set up the workflow system,
so there has to be a UI for that. The average user will not be trying
to set up a workflow.
The adminstrator will want to design the Work object. The object will
have standard attributes about its status and which queue it is in
and other system details which can be invisible to users, but there
will always be attributes which identify the Work object, attributes
which are changed by the humans, and attributes which will control
routing decisions.
The DecisionPoint object will need to be designed too. Apart from
hidden system details, a human must be assigned to it (see Contact
database for this) and the role of the human must be defined, and all
the possible routing decisions from it must be defined.
Closing technical stuff...
You need a reporting and tracking system, to search and find where
any Work object is in the system, to identify Work objects that have
become stalled in some queue, to report on throughput, to report on
productivity of humans, to report on errors and problems... This is
not so hard to do - simple SQL queries will meet most needs.
- [Phpgroupware-developers] workflow as a feature in phpgroupware,
Craig Allan <=