Designing Information Systems

I am fascinated by information systems’ failure and miss no opportunity to collect as much information as possible about failed systems. I’ve addressed the issue several times earlier in piecemeal fashion, and of late, I’ve come to realize that there are two fundamental laws that must be adhered to when designing such systems. Complying with these laws doesn’t guarantee success, but helps in minimizing chances of failure. 

Law I: A successful system adds value to the work content of all its stakeholders

To understand this law, we first need to define what the term stakeholder means. A stakeholder is a person whose

functioning is affected by the system. Internal stakeholders are company employees such as managers (who use the information provided by the system) and line workers (who capture transactions). External stakeholders include agents, dealers, and workers.

The essence of this law is that value must be added to the work content of all stakeholders. The system shouldn’t add value for one stakeholder at the cost of subtracting from other stakeholders. Unfortunately, that’s exactly what happens in far too many instances. I cite two instances to illustrate the working of this law.

The first concerns a piece of software that I wrote several years ago. The software was developed for a corporate whose business demanded that it offer a large variety of discount and incentive schemes. Things had reached such a state that the company itself was unsure of what net realizations were. They wanted a piece of software that would allow them to track and audit the impact of each scheme.

Program development went without a hitch and we moved into implementation, where a major roadblock occurred. 

The software we had designed called for specifying incentives by selecting the products the incentive would be on, creating a slab structure for discounts, and then selecting the customers to whom the scheme would be offered. Creating and executing a scheme took about 10 minutes per incentive. This would have been fine, except for the fact that an extremely competitive market had forced the company into offering a different scheme to nearly every customer. The number of schemes to be created was prohibitively large and marketing people would have to spend a substantial amount of time maintaining the data.

People soon stopped using the system altogether and reverted to the earlier way of working, where ledger balances were used to arrive at a gross figure for discounts. This is a prime example of how value can be added for one set of stakeholders (accounting) at the cost of another set (marketing) who’re forced to devote a lot of time on what they consider are unproductive tasks.

The second example concerns the Net. A large number of corporates are now interested in having people order electronically, so that the company can automate the processing of orders. The value addition for the company is clear, it saves a lot of money on coordination. Unfortunately, the same might not be true for the customer. Try to imagine a typical Chandni Chowk wholesaler trading in 15 product lines who orders goods with simple phone calls. It’s extremely unlikely that he’ll log on to place orders unless he perceives a lot of value addition–which is what this law is about in the first place. This also brings us to the second law.

Law II: A successful system is one that not only adds value, but is also perceived to add value 



A system can become successful only if it’s used. And people use a system only if they perceive some benefits. People need relatively little inducement to try the system initially. But they’ll continue to use it, only if they perceive some value addition. This is true not only at the systems level, but also at the features level. For instance, most financial accounting packages have features for budgeting at the cost center level. Most users, I know, have stopped using these features because they don’t think the extra effort yields anything. The point here is not that these features aren’t offering value, but that users don’t perceive any value addition.

The bottom line Don’t restrict yourself to the top management brief when designing a new system. Try to design it keeping all stakeholders in view.