Re: [Phpgroupware-developers] workflow as a feature in phpgroupware

[Brian Johnson]

This sounds good.

How far have you got in your project?

Is it available as a potential base to build upon?



Craig Allan (address@hidden) wrote:
>
>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 mailing list
>address@hidden
>http://mail.gnu.org/mailman/listinfo/phpgroupware-developers
>

--
Brian Johnson

This is where my witty signature line would be if I bothered to edit this line 
:)