Charles Burns, Elk Grove Unified School District
When the boss wanted a new "On line Requisition System" that would automate the budget checking and authorization process, plus automatically link to our existing purchasing and warehousing system, we decided to look real hard at exactly what problem we were solving. It turns out that what we really needed was a system that imitated the paper flow of many many forms within our organization, all requiring a hierarchy of signatures to get approved.
This is a typical problem of many organizations, both public and private sector based. There are a number of recently developed products that attempt to meet this need by mixing forms and electronic mail. The problem with every one of them is that in order to be all things to all users, they become much too complex, and never quite meet the users' needs. So we decided to build our own.
After a year of exhaustive research on both front end GUI's and back end database engines, we settled on Gupta's SQL Windows as our development language and Sybase System 10 as our database engine. We were strongly drawn to Power Builder due to the enormous amount of publicity, but when we developed a test application, we found we wrote more code and much more easily crashed the system (GPF's). We like the robustness of SQL Windows and Gupta has promised our required Macintosh client sometime this summer. The database engine is running under HPUX on an HP9000 E35. We have been customers of Hewlett Packard's equipment for many years and have been constantly rewarded with phenomenal up-time and excellent field service. Of course their discount structures for education have also helped significantly.
After sending a two-person team of programmers to Gupta training, a system administrator to UNIX training for 2 weeks and a database administrator to Sybase for a week, we began developing our first application. We knew up front it would be a throw away, but we gave it our best shot. We put together a little program to record special requests from our users, rank them and present them to the department manager. It's not easy to move from a procedural language (mainframe COBOL) to object oriented and message driven environment. Our first application wasn't bad, but couldn't make it in prime time. But what a great learning experience for the staff.
In October of 1994 we began the real job of designing our first live client server system. Based on all the recommendations by those that have gone before us, we chose this non-critical application to start with. We quickly created prototypes for two application modules, the Admin module and the Router module.
The Admin module is for defining our organizational chart and "special events" for routing documents. A special event can be defined by cost center codes, certain inventory items or spending limits. We're certain that as time goes on, we will encounter other types of special events, but we have them all defined in one spot so it'll be easy to add on to. The second module is the form filler and router application. Since a form needs to be routed as soon as it's filled in, we combined this into a single application program.
With SQL Windows, we were able to quickly make all the changes requested by our users. Since we didn't have a specific user development team, we asked for input from many sources, all of them future users of the various modules. It was uncanny the way that we were able to respond to their every whim. We're used to writing legacy COBOL that is anything but flexible. We used to try very hard to prototype using our mainframe tools, but it's not anything at all like using SQL Windows.
We were writing code by December and in February were testing integration. By March we were demonstrating the actual code. Once again, true to user habits, we had more changes, but nothing we couldn't handle. We spent the majority of our time customizing the download of accounting information from the mainframe and the upload of output data to our inventory system.
In early April we demonstrated the final product to my boss. His only comment was, "All we gotta do now is copyright it and start selling it." Unfortunately, we can't do that because it was developed with public funds and therefore is in the public domain. After we get the beta completed successfully, we plan on publishing the system on our internet server (http://www.egusd.k12.ca.us) and making it available to any public organization.
The system actually mimics what people do when they have a paper system., It makes it easy to fill in the forms, performs editing up front, and instantly routes the form to the next person that needs to see it. Each user in the system (could be hundreds) logs in each day and leaves the form filler iconized. When a form is routed to a user or if the user has a form already on their "desktop," then the icon flashes every few minutes as a reminder.
Use of the system is straightforward. It's a matter of a single click to approve a form, then a person must add their "electronic signature" to the form. Electronic signatures are just another password which is controlled by the user and aged automatically. But this signature must be entered for every transaction, just as the person would normally sign a paper form and set it in the outbasket. Our first form, the Warehouse Requisition also links to our warehouse catalog for showing the user what they're ordering and to check for valid input.
Training was accomplished during the last two weeks in April and concluded in early May. The first real live forms were transmitted on the system during the second week of May.
Some facts about Elk Grove Unified School District:
The Inbasket (router startup window) looks like this:
The Admin startup window looks like this:
