Building fudgable IT systems

Companies building IT systems to replace a previously offline (paper-phone-fax) based business process often spend millions of dollars on the project. These systems surprisingly similar to one another (given that they represent different business processes in different industries) Actors have particular Roles. The Actors operate on Documents, which are exchanged between actors in a pre-choreographed order that is the Business Process. The system is typically designed to replace a mature paper-fax-phone based process already in existence, be it processing a purchase order or approving an application for insurance.
Companies are often surprised when they face resistance or low adoption to the new systems (something I wrote about a little while ago in hooking small businesses up). A number of the projects that my company Uzanto has tackled in the past year have involved – in some way or the other – fixing broken systems of this type, particularly at the intersection between a large enterprise and it’s much smaller partners (think insurance brokers, or real estate agents, or retail stores). One specific reason for failure that we have encountered again and again is due to the fudgability of paper / voice, and the inflexibility of any software process that tries to replace it.


A signed paper document can have additional data added to it after being signed. Notes in the margins of a paper document can inform other actors that the document should be processed in a particular way. Documents can be faxed to processors who are likely to be understanding of the particular type of situation represented by the document. There is no log that records if a piece of paper is moved from the bottom of a stack to the top. Voice is even more fudgable, and is a critical aspect of most existing business processes: it leaves no paper trail at all, and is usually the medium of choice for any sensitive information.
No business process can function without this flexibility: but enshrining “rule – bending” in a computer system risks giving it the “company seal of approval”, and thus opening the company up to legal liability for the behavior. Most participants in an industry are keenly aware of the regulatory regimes that they live under (examples: sarbanes-oxley, HIPPA , and USEPAP, ), and committing a traceable violation of the regulations could cost a participant millions of dollars. In addition, our lawsuit-happy culture has made all professionals wary of what they write down: anyone who has ever tried to email their real estate agent or stockbroker will quickly learn that such people never say anything in email, because they don’t want to leave a paper trail for a subsequent lawsuit.
It turns out that there are really two types of fudgability: the type that relies on giving humans flexibility in how they process documents, and the type that relies on real (but untraceable) transgressions (violations, even for the best of reasons, of the regulatory frameworks that an industry inhabits). Examples of the second sort to fudgability include communication of information that is protected by privacy laws, adding data to a form anonymously, communicating the desired value of an appraisal, and so on).
An information system can implement the first type of fudgability without exposing the organization to legal vulnerability. A good first step is to give all electronic forms “virtual margins” where clarifying notes, document routing instructions, etc can be added by any user of the system, to any section of the document. For example: “Attn Shiela”, or “We need to split this up into 2 applications” or “NOTE: this transaction brings client over his yearly IRA limit: client says adjust amount to $1500”). A second step is to build a system that has “flex”: allow documents to be browsed and accessed in random order, and allow administrators to route documents to individual processors. Most importantly, while machines should be allowed to suggest decisions, a machine should never be allowed to make the final decision about anything.
The second type of flexibility obviously must remain segregated in a “back channel” of voice communications, which leaves no paper trail. This is only possible if the IT system reveals (rather than hides), the individual participants in the system. A document should always be sent to a person in an office, not simply to an office. Contact information of all parties must be visible from within the system itself.
The personal relationships between participants in a business process are the oil that stops the engine of business from seizing up. This is important not just for the communication of sensitive data, but also for the “favor-bank” effect (which provides a currency to pay for the favors necessary to make special-case exceptions). An anonymous system where offices send documents back and forth at each other makes it impossible to do favors for individual people, because there is no way to collect on the favor later. As in the paper-based process that an IT system replaces, an auditing process of some kind is an essential component to make sure that employee “rule-bending” does not turn into fraud or abuse of the system.
As always, feel free to comment below.

2 thoughts on “Building fudgable IT systems

  1. James Robertson February 20, 2005 / 4:35 pm

    Hi Jon, this is a very interesting perspective, and one that is very relevant for web content management systems (CMS), which is the space that I do most of my work in.
    It also seems like there are parallels in your thinking to some observations I made about workflow in a recent article:
    http://www.steptwo.com.au/papers/cmb_noworkflow/index.html

  2. Jon February 20, 2005 / 5:28 pm

    Nice article James! I like your site a lot,.
    Yes, there are parallels.The main difference is that in your case, you’re talking about interaction between team members _within_ an organization. I’m talking about work that happens between members of different organizations.
    Work within an organization is almost always ad-hoc. Even when workers say they have a “process” (for example in software engineering), the level of compliance is not likely to be very high.
    But in interactions _between_ organizations, there really is a thought-out workflow, with data sheets that have evolved over the last 20-200 years that capture the data I owe you and the data that you owe me back. The situation is more formal and thus in one sense more amenable to automation.
    However, since the interation is between 2 independent parties, there is little ability of one party to order the other party to do something a particular way. Of course, as you point out in your article, even employees will ignore a system if it doesn’t match the way they work. However, you can usually at least order them to give it a try!

Comments are closed.