Certainly the COLLECTING of the transaction information is simple and easy.
That doesn't necessarily need an expert system. But the PROCESSING of the
transactions once collected is complex. We deal mostly with hospitals, so there
are issues of shift differentials, overtime, bonuses, etc. And each place has
there own way of paying their people. Sometimes overtime occurs after 40 hours,
sometimes it occurs if you work more than 8 hours in a day. Some people move
from department to department, and the hours/overtime must be distributed
between departments. That distribution can be any number of different ways.
We've had 20 years of experience collecting all the different rules different
places use to pay their people. And we need a system that can accomodate, well,
most of them.
So, ultimately, there are alot of rules involved. Certainly more than the page
suggested as a rule of thumb. These could be written in the traditional way
using a procedural language. We have done it in COBOL before. That was a big,
hairy mess after it was tweaked and modified and fixed over time. We are in the
process of a rewrite. So I was considering whether using a rule based system
would provide the benefits that I've heard that they provide: A better
separation between different rules allowing easier maintenance.
Maybe an ES a good fit. Maybe not. There will certainly be advantages and
disadvantages to solving our problems using this type of solution. We
ultimately need to decide which advantages out weigh the disadvantages for each
solution. And these discussions are invaluable for that process. So I thank
you and all who have answered for their feedback.
-Chuck.
DATA <[EMAIL PROTECTED]> on 06/05/2000 01:36:29 PM
To: Chuck V. Sterbis/DDI@Timeweb
cc:
Subject: Re: JESS: Questions on when to use Rule Based System
Chuck,
I know this is not addressing the question you asked but I am curious why
you would be using an Expert System for a time and attendance system? I
have done several of these and it seems to me that the rules for such an
application are analytic and very well understood so a Database Management
system would be a better choice. But may be I am missing something?
Tom Savell
-----Original Message-----
From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Monday, June 05, 2000 9:29 AM
Subject: JESS: Questions on when to use Rule Based System
>
>
>I've seen the recommendations on when to use a rule base system (RBS) (re.
>thread "JESS: Need of a Rule Based System!!!" started by Sachin and the
thread
>"JESS: Data constraint management " started by Robert Quillen.) I wonder,
>though, about when you have a REALLY big system. I am now working on a
project
>for a time and attendance system. I can imagine it handling ten to twenty
>thousand employees. (So that would be ten to twenty thousand facts.) The
rules
>to pay these individuals are very complex (on the order of hundreds of
rules).
>Each employee would have two to six "clocking events" per day. (That would
>potentially be six times twenty thousand more facts.) There can be ten to
a
>hundred different people adding/changing facts at any given time.
>
>So I'd like to use an RBS, but can it handle it? I can't imagine keeping
all
>that data in memory. So how efficient would the engine be at
>reading/representing this information in an SQL table? I've seen Thomas
>Barkenow's RDBS extension. It basically is wrapper for creating individual
>SELECT statements for each rule to find it's facts. But I can't imagine
that is
>very efficient. It gets the job done, but it would be murder for a large
>system. I can see a case where it would use two SELECT statements instead
of
>using a JOIN.
>
>How efficient are these RBS when there is a large number of facts being
>added/changed? What would happen if power was suddenly lost. Would
anything
>get lost? (That would be a bad thing, especially since we are dealing with
>people's pay!) How would it recover?
>
>In the case of JESS, how thread safe is it?
>
>-Chuck.
>
>
>---------------------------------------------------------------------
>To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
>in the BODY of a message to [EMAIL PROTECTED], NOT to the
>list (use your own address!) List problems? Notify
[EMAIL PROTECTED]
>---------------------------------------------------------------------
>
---------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the
list (use your own address!) List problems? Notify [EMAIL PROTECTED]
---------------------------------------------------------------------
