Browse Prior Art Database

Embracing the "open code" philosophy for professionals, to achieve the ultimate goal of: " best of breed, on demand products and services"

IP.com Disclosure Number: IPCOM000029261D
Original Publication Date: 2004-Jun-21
Included in the Prior Art Database: 2004-Jun-21
Document File: 2 page(s) / 43K

Publishing Venue

IBM

Abstract

In the traditional support organization, there are various levels of support personnel, each with a different level of knowledge and expertise. Many times this bureaucracy is efficient and works to perfection and in a timely fashion. However, too often the bureaucracy is misused.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 41% of the total text.

Page 1 of 2

Embracing the "open code" philosophy for professionals, to achieve the ultimate goal of: " best of breed, on demand products and services "

As much as organizations strive for excellence and bug-free products, the products and services they sell can still leave a lot to be desired. Companies have for many years been using the traditional support organization. There are various levels of support personnel, each with a different level of knowledge and expertise. Most problems are resolved by the less knowledgeable staff, albeit not less qualified, as most of the problems are already well documented and their solutions are trivial.

    For the "few" more difficult problems, on the other hand, an escalation process is put into action. Many times this bureaucracy is efficient and works to perfection and in a timely fashion. However, too often the bureaucracy is misused. Many of the tough problems are difficult to re-create and thus require back-and-forth communication between the customer and the highest support level. At these times, the bureaucracy can become a burden. The more levels of support that are involved
(i.e. up to the developers), the longer it takes to solve the problem. In these "rare" cases, each support line tries to pass on the "hot potato" to someone else. It is not unusual to have such a problem going back and forth for months, if not years. If the customer or end user carries enough clout, then the crisis management process is invoked and makes sure that the problem is addressed and solved in a timely fashion. The above "normal" support procedures and their respective "fast lane" techniques are expensive and, besides making a big dent in a company's pocket, also leave many unhappy clients. When a given client is favored over others, those others are surely not happy. Even favored clients don't like to get their higher management involved too often. They would rather deal with their core business.

    The support organization described above has been around for many years. At one time, this was the only way to support customers. The computer business was in its infancy, and writing new code, let alone fixing someone else's code, was a skill, or rather a craft, that only a select few possessed. Also, in those days, the fastest communication among colleagues was via the phone, and cooperation and information sharing among colleagues was just a dream. Under those conditions, the development and support hierarchy described above was the right answer.

    Today, however, computer programming is just another profession, and many people around the world have the skills to write new code and to review other people's code. To leave the development task as well as the right to read and fix existing code to only a select few makes those few a bottleneck and also prevents the company from utilizing a precious resource: its capable people. One could argue that the layered hierarchy is justified because the people at the first level of suppo...