|
|
|
||
|
|
|
The following project case studies will give you an idea how Ingraham consulting approaches projects. "I have worked closely with Bruce Ingraham for more than ten years, and have always been delighted with his ability to see the big picture and help me solve my problems. He is able to provide expert guidance and thus help me understand the scope of a solution. He than then implemented that solution in a timely, cost-effective, and user friendly way. His ability to sit down with me, look at the kind of problem I have at hand, and then choose just the right tool for the job, has made working with Bruce a pleasure. Taking the time to understand what it is we do is half the battle, and by providing expert consultation during the design phase of our efforts, Bruce has made a major contribution to overall project efficiency." The Atkins Principle One of my first jobs after college, back in the mid-1980s, was with a large California public utility. I worked in a group that was responsible for forecasting how many computers the company would need. We had monthly meetings where various departments would plead their case for additional computer resources. One month, a department sent an advocate to argue for DB2, IBM's new relational database management system. The rationale was that this particular department was tired of waiting for COBOL programmers to do ad hoc reports. With DB2's user-friendly Query Management Facility (QMF), people could do their ad hoc reports. Another attendee at this meeting was Winona Atkins. As she listened to this line of reasoning, she started to fidget, then squirm in her chair. She finally couldn't contain herself any longer, and blurted out "What difference does it make if it's DB2, SAS, or something else? At some point, doesn't thinking have to go on?" This department got it's way, the utility brought in DB2 at great expense, and the department hired a dozen DB2 programmers to do ad hoc reports. Nobody would believe before hand how much thinking was needed to use QMF. This is the Atkins Principle. My job is to ensure that thinking goes on at your company. I try to protect my clients from making costly investments in technology when difficult analysis and policy decisions are really needed. The situation has worsened as more graphical user interfaces (GUIs) for relational databases become available, such as Oracle Browser, Cognos Impromptu, Quadstone, and Ceres, to name a few. The fact is that no matter how good your GUI is, thinking still has to go on in order to comprehend a fifty table database that is documented by a two-hundred page data dictionary.
How a pharmaceutical company improved the quality of its research and development A mid-sized pharmaceutical company had about fifty biologists working on pre-clinical experiments. The purpose of these experiments, called bio-assays, was to identify drugs that might be used to treat medical conditions in humans, from stomach ulcers to pain relief. The company had hired a staff of three statisticians to analyze the results from the assays conducted by the fifty biologists. Since three people can't do that much work, the manager of the department developed a strategy of providing the biologists with turnkey computer applications customized for their assays. Developing that many computer systems is also a big job. I collaborated with the senior biomathematician to create an assembly line for software development. We had three systems under development at any one time. For one system, the biomathematician would work with a biologist to make sure the bioassays were designed correctly and determine what statistical analysis would be required. He would then write a specification for the system. Working from a specification, I would be designing and programming a second system using a set of modules that could be plugged together in custom configurations. A third system would be in testing, installation, and training. A complete system rolled off the assembly line every week.
How a hospital solved its receivables problem A large hospital and medical group had had a poorly run patient accounting department for many years. It had been slow to adapt new technology. The collectors responsible for obtaining payment from insurance companies were still using microfiche in the mid-1990s. The accounts receivable computer application, a mainframe batch process, was over twenty years old. The manager had no performance or aging reports to work from. I
was engaged by the collections manager to help with the
reporting problem. Working with the manager, the data
processing department, and a financial analyst, we developed
collections and management reports. The resulting business
question was how many of the receivables were collectable,
and how many were bad debt? I analyzed the data using a
statistical technique called survival analysis. This method
is used to predict the amount of time for an event to occur
from the present. The event could be death (hence, survival
analysis), recovery from an illness, or payment of a bill. I
found that the chances of an account being paid after a year
and a half were so low as to not be worth the effort to try
to collect. The manager used this information to assign a
task force to write off the bad debt. As a result, the
company had an accurate statement of its receivables on the
balance sheet for the first time in many years, and the
collectors and managers had the tools to keep it that
way. |
|
|
Ingraham Consulting 662 The
Alameda 510/527-5625 |
|
home | services | case studies | competencies | about us | contact us
All Rights Reserved |
|