The Hindu Business Line : <I>Porcupines have quills and programs have bugs </I>

How does a company survive in `the incredibly competitive large computer system market'? This is how Scott Duncan, the protagonist in Necessary but not Sufficient, goes about the game, where `average sale is a few million dollars, and deals of several hundred million are not rare': he carves out a unique sales force that targets the techies, that is, "the people who are likely to be the ones to do the more technical evaluations of the proposed systems."

Scott's people educate these professionals `while the competition is busy trying to locate and build bridges to the decision-makers'. The education is not on how the BGSoft system works. "But how in general a computer system suitable for the prospect's type of industry should be designed; the pluses and minuses of the various possible configurations; which features are key, and which ones are just good at impressing the novices."

What is the result? "By the time the real match is reached, and the proposals are compared by the selection team for best fit, the know-how planted by Scott's people is taken as the standard. In an industry where no real standards exist, it gives Scott's company a huge advantage."

The book by Eliyahu M. Goldratt, from Productivity & Quality Publishing P Ltd (www.productivityquality.co.in) is a `TOC business novel for IT' that offers many takeaways such as the techie approach. For starters, the abbreviation TOC stands for `theory of constraints', which comprises two components, viz. the thinking processes, and applications to various areas in an organisation, as one learns from www.goldratt.com.

Continuing with the story, you'd meet Lenny Abrahms, behind the electric doors of the systems development section. He is battling with the challenge of integrating vendor-performance measures before the release date. Roger, the VP is worried about quality assurance. "We must give our programmers clear priorities," he tells Lenny. "Some of our people are really excellent programmers, but I can't keep constantly interrupting them. The need to stop work to answer questions and fix bugs is turning their work into havoc." Too real a problem, as most professionals would acknowledge.

"It's not such an impossible mission to write a computer system that will work right the first time," says Lenny. "Just design a system that does nothing, and you have about a 12 per cent probability it will work smoothly. In all other cases it'll do something - which means there are bugs somewhere." Porcupines have quills and programs have bugs; that's life, philosophises the author.

"The ERP vendors have to constantly increase their speed. Forty per cent a year to be exact. And no one is blinking an eye; everybody in the industry behaves as if the cliff does not exist." These thoughts keep Scott turning in his bed, sleepless. "The main market is saturated and he can't do a thing about the fact that there are a limited number of large companies... There are not that many companies who are so dissatisfied with their ERP systems that they will consider writing off their huge investment and starting all over again with a new vendor." We'll have to concentrate on the mid-market, decides Scott. But he remembers Lenny's warning: that the product has become too complex to hand. "It will not be easier to add new features, it will not shrink the time to bring new people up to speed, and most importantly, it will not be easier to locate or fix bugs."

Many pages later, you encounter Dinesh Nagpal, a Ph.D in Math from Cornell, and the chief scientist behind optimisation methods in Intelogic. He tests out a case that Lenny presents. "The first objective is to see that all the customer orders can be shipped on time, considering material availability, capacity constraints, and tool availability," says Dinesh. And Goldratt continues the narrative: "He runs the program. In seconds they get a split screen with blinking data lines... "

A book that merits a quick read before the touchdown.

Put policies in place

By taking action now, "companies can put policies in place that will protect their employees and their businesses."

"The Internet and other technologies will provide a vital lifeline for business during a pandemic crisis. Yet many continuity plans are based on the assumption of normal power supplies. But is that a safe assumption?"

That's one of the many questions that Colum Murphy poses in Flu Action Plan: A Business Survival Guide, from Wiley (www.wiley.com) . The blurb has startling numbers: that the estimated deaths from a major flu pandemic range from 1.4 million to a staggering 142 million. "The World Bank says the global economy could take an $800 billion hit. Other economists say even this figure is way too low." Don't forget that the `mild' Asian flu of 1957-58 `managed to claim two million lives'!

The message of the book is not that you should panic, but that by taking action now, "companies can put policies in place that will protect their employees and their businesses."

Using mathematical modelling, you can foretell 10 years in advance what might happen, affirms a quote of Gabriel Leung, cited in the book. Murphy mentions about a model that proved to be close to reality — that of Professor Roy Anderson of Oxford University. Drawing from the laws of physics, Anderson had studied in the early 1990s the HIV/AIDS disease among sex workers in Kenya, and predicted the massive impact of the infection. "His predictive curve foretold the nightmare that was in store for global health and gave an advance warning to the world's health authorities of the sheer enormity of the task that lay ahead."

In the case of flu, "even elementary models can help us get a sense of scale," says Murphy. FluAid, a free software developed by the CDC (www2.cdc.gov) in the US finds mention as an example. "Although still officially in its test phase, the software is designed to help public-health officials gauge the impact a flu pandemic might have on their communities." How does the software work? Users key in data such as `estimated mortality rates for three different scenarios' and the program calculates `the likely impact in terms of the number of people that will seek hospitalisation, the expected number of outpatients, as well as the total number of deaths.' For instance, using the software and data from past pandemics, Singapore's Ministry of Health estimates that 4.5 lakh of its 46-lakh inhabitants could develop a `mild' form of the disease, which could result in "the hospitalisation of 11,000 residents and the death of 1,900 people."

Another model is by Neil Ferguson, mathematical biologist at the Imperial College London. Murphy notes how, using a computer model that mapped the evolution of a hypothetical bird flu outbreak in rural Thailand, researchers could show "that, under certain conditions, it might be possible to stop human-to-human transmission of bird flu in its tracks at an early stage, and deny the virus the chance to escalate into a global pandemic." The author alerts that realistic models demand a staggering number of parameters; also, "the dynamics of a pandemic are much more erratic than traditional risk modelling techniques can accommodate."

He also emphasises how `cross-cutting infrastructure' such as electricity grids, the Internet, telecommunication, transportation and shipping networks that form the backbone of economies can be affected by flu pandemic. According to Marshall Sanders, vice-president for global security at Level3 Communications (which operates `one of the largest communications and Internet backbones in the world'), the Internet was designed to withstand a nuclear attack, and demonstrated its resilience on September 11, 2001. The book cites the view of Steven Ross, director of enterprise risk services for Deloitte & Touche - that information-technology related pandemic-flu preparation be thought of "as a means of improving worker productivity."

One of the case studies included in the book is of Intel, which had "first-hand experience with Sars when one of its employees in Hong Kong became infected with the disease in 2003... "

Must read!

Tailpiece

"We created a flu model software that could track infections but... "

"But?"

"It got hit by viruses!"

"Oh, a case of infections tracking the software before it could track infections."

http://BookPeek.blogspot.com