Learn From What Works in Paper-Based Systems

 
 
By Peter Coffee  |  Posted 2005-08-15 Email Print this article Print
 
 
 
 
 
 
 

Opinion: It's easy to "improve" a manual process in ways that lead to new kinds of errors.

I had an opportunity last week to observe a transition, still in progress, from paper-based record keeping to an online operation. The new system was vastly superior when everything—and crucially, everyone—was behaving according to specifications. Its important to remember, though, the dictum of "Systemantics" satirist John Gall, whose "Systems Bible" includes the warning: "Any large system is going to be operating most of the time in failure mode." I was one of the adult leaders taking a group of 32 Boy Scouts to a week of summer camp, where we found that the "Blue Cards" used by generations of Scouts to track their fulfillment of merit badge requirements had been replaced by a Web-accessible database. One unintended consequence of this change was that adult Scout leaders now had to resist—often unsuccessfully—the temptation to check their e-mail, as long as they were logged on to the system to update Scouts records anyway. So much for getting away from everything.
The major problem arose at the end of the week, when Scouts who had attended a class—but not correctly signed up for it—received badge completion reports that did not show their work. I suspect that the system simply did not ask the counselors for input on Scouts that the system didnt know were there. Crucially, I saw the clipboard of one counselor, who had added hand-written rows of names and data to his class roster printout and had carefully tracked the progress of his "phantom" Scouts. When asked, he was therefore able to confirm that they were there and had done the work. There was even a stack of little cards prepared that counselors could use to file late corrections to the office so that oversights like this—once noticed—could be fixed.
With the old Blue Card system, though, this simply wasnt an issue: a Scout showed up at his first class with his Blue Card, which the Counselor then held for the week while adding requirement completion information—and then turned in to the office, effectively combining the sign-up and the completion report in a single operation. The Blue Cards, one might say, were an object-oriented system: The data structure followed the flow of the work and arrived at the end in one piece instead of requiring assembly from several pieces in several different places. With the Blue Cards, moreover, an incomplete class roster would find itself at the end of the week sitting side-by-side with cards—physical objects, difficult to ignore—that did not correspond to roster entries. The system would send, in effect, a tangible signal of a problem.
As I said, the new online system had a lot of advantages. I could export sign-up information to Excel and sort by Scout, or by time of day, or by class. I was able to arrive at camp with printouts that told me, at any given time, which Scouts should be where. The system knew which badges were offered during which sessions of the camp day, and would not allow a Scout to prepare an impossible schedule. Overall, it was a definite improvement, and I commend those who are making the effort to streamline summer camps classic but cumbersome systems. Remember Galls warning, though, that systems are rarely working entirely as they were designed, and his corollary (borrowed from family therapist Virginia Satir) that "Problems are not the problem: coping is the problem." Gall further offers the Unawareness Theorem, phrased as the question: "If youre not aware that you have a problem, how can you call for help?" Both of these statements are important warnings to application developers. Dont merely build a system to work correctly; build a system to fail, when it does fail, both gracefully and also loudly. That is, the system should do as much as it can, rather than collapsing completely, but it should also be designed to anticipate and clearly signal likely failure modes. A system, in short, should be trustworthy, loyal, helpful, friendly, courteous… Oh. Right. I thought that sounded familiar. Application builders, like Boy Scouts, should be prepared. Tell me how you build your systems to do a good turn daily at peter_coffee@ziffdavis.com Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.
 
 
 
 
Peter Coffee is Director of Platform Research at salesforce.com, where he serves as a liaison with the developer community to define the opportunity and clarify developers' technical requirements on the company's evolving Apex Platform. Peter previously spent 18 years with eWEEK (formerly PC Week), the national news magazine of enterprise technology practice, where he reviewed software development tools and methods and wrote regular columns on emerging technologies and professional community issues.Before he began writing full-time in 1989, Peter spent eleven years in technical and management positions at Exxon and The Aerospace Corporation, including management of the latter company's first desktop computing planning team and applied research in applications of artificial intelligence techniques. He holds an engineering degree from MIT and an MBA from Pepperdine University, he has held teaching appointments in computer science, business analytics and information systems management at Pepperdine, UCLA, and Chapman College.
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...

 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Rocket Fuel