Continue in 2 seconds

DQ Point 9: Break Down Barriers, Part 2

Published
  • November 01 1998, 1:00am EST
More in

This is the fourteenth in a series of discussions of quality guru W. Edwards Deming's fourteen points of quality and their ramifications on data quality. Here I conclude my discussion of Deming's quality point 9, "Break Down Barriers Between Staff Areas." This month I describe the characteristics of quality application development methodologies that break down barriers between business areas. Application and data development methodologies are business processes such as business planning and product development or engineering. As such, they are subject to improvement as is any other process. In fact, the application and data development methodologies are vital processes because they create the "system" that enables or hinders the work of the organization. While application and database "products" may be built in three months to two years time, the resulting applications and databases will constrain or enable business processes for five to twenty-five years. Some organizations have core "legacy" applications and databases that are now more than thirty-five years old.

Quality application and data development methodologies must have a customer focus. This customer focus does not mean focusing on the customer who is paying for the application. Rather, a customer-focused methodology asks who are all the customers of the information products delivered by the application and who are the suppliers of information products required by the application. The best place to electronically capture information required by the application may not be within the scope of the application area.

Quality development methodologies will focus on the horizontal business value chain rather than vertical functions being automated. Only by focusing horizontally will a development methodology ever produce applications and databases that are seamlessly integrated and satisfy downstream information-product customers as well as the immediate beneficiaries of the developed applications and databases.

Checklist of quality application development and delivery characteristics:

The methodology is defined adequately and consistently so that different project teams, adequately trained, can produce quality applications and databases consistently.

Has a role of business project manager as well as a systems project manager.

Has a role of data architect, data administrator, whose purpose is to assure common definition of data among all information stakeholders.

Focuses on applications as a part of a larger business value chain and not simply a stand-alone application.

Views applications and databases not as end products in and of themselves, but as tools that enable business products to be produced. Applications and databases are to business processes what manufacturing equipment is to manufacturing processes.

Defines application objectives in context with the enterprise goals and business drivers along with how the application supports or enables enterprise goal attainment.

Uses business value chain, information and technology architectures as input to the development process and identifies how the application fits into them.

Defines the scope of an application within the context of the business value chain of which its processes are a part.

Identifies information customers and suppliers outside of the scope of the "project" and considers their information requirements that are within the scope of the application developed.

Has a step to assess whether business activities add value or add cost from the end-customer perspective.

Has a step to define and model information to meet all information customer (internal and external) needs, not just those of the application project. The only way to develop such a business information model is to have representative participation by all areas that have a stake in a common information subject. Information modeling is best done by modeling and defining information requirements about the various business resources or subjects. Business resources (subjects) include people and organizations (customer, supplier and human), products and materials, facilities and other assets, financial and other business resources. These business resource classifications are sometimes called "subject areas." They must be modeled and defined to support all business processes and knowledge workers who require or produce the information about the various resources. These kinds of models cannot be developed with "interview and assimilate" techniques. They can only be developed with interactive modeling sessions involving business subject-matter experts from the different parts of the organization so they can see how their views and processes fit within the context of the other enterprise views and processes. Those who argue this cannot be done must believe teamwork is not possible or desirable within their organizations. Those who argue it's too expensive must justify the costs of redundancy that result from doing it fast without regard for how well it integrates within the enterprise information environment or how much it costs to support.

Separates the funding of application development into three categories:

1) Infrastructure costs (shared databases, authoritative data capture applications at the point of data origination and shared information technology). Infrastructure costs must be allocated equitably across the enterprise.

2) Value delivery (the applications that use existing information to add value to the business processes). Value-delivery programs should be charged back to the beneficiary business area.

3) Redundant, cost-adding development (applications creating redundant data, inter-business area interface programs, redundant databases). Redundancy and cost-adding development, whose result is proprietary and inconsistently defined databases, must be dis-incented. Business areas that insist on un-integrated applications and non-shared databases with inconsistently defined data must directly bear the costs of the development and the costs of maintaining consistency of their data with the enterprise shared data. In addition, they must bear the cost of fixing the problems caused by the redundantly or inconsistently defined data.

Prior to the selection of application software packages evaluates the packages against the enterprise data architecture, not just functional requirements.

Prior to the selection of application software packages evaluates the packages against the enterprise technology architecture.

Prior to the selection of application software packages evaluates the ramifications and costs of interfacing (it is a misnomer to call this integrating) the package data and technology architectures into the existing environment.

Seeks to place the data create programs with the business processes that are the first and natural point of data acquisition.

Maximizes the reuse of data, application and technology objects already defined and implemented.

Has a step to gather post-implementation feedback of both immediate and downstream beneficiaries (knowledge workers) who are the customers of the application's information products.

Has a step to analyze the post-implementation feedback for the purpose of improving the application and data development processes.

Teamwork for Business Data Quality

Peter Drucker describes the new management models in the information age with the metaphor of the symphony conductor as opposed to the military chain-of-command hierarchy. 1 Working with a single composition, the conductor (chief executive officer) must interpret the music and bring out from the musicians (workers) their skills in performing the music for the enjoyment of the concert-goers (the customers). There are a number of important parallels in this metaphor to Deming's quality point 9.

The musicians are all specialists. The violinists cannot play the trumpet parts nor can the flautists play the cello parts. In the same way, the business "functions" represent specialist roles in the business processes.

The conductor, as the CEO and leader of the orchestra, is accountable for the musical performance and for bringing out the best in the performers. In the same way, management is the leader of the enterprise and must bring out the best in the employees. Management must provide its interpretation of what the enterprise must accomplish. It must make clear what is expected of each section of the orchestra.

The orchestra plays from a single musical composition. In the same way, the business must operate from a common vision to achieve a common end.

A successful performance can only occur when the orchestra works together. It is this teamwork that transforms a simple performance to an enjoyable performance for the concert-goers. A successful business that brings customer satisfaction occurs when all parts of the business value chain work together.

The concert-goers are the customers. It is the customers who judge the quality of the performance by the orchestra. A quality performance may be recognized by a standing ovation. In the end, no matter what "objectives" the enterprise has met, the customers have the final say as to the quality of the products and services. They demonstrate their satisfaction by coming back again--or by going to the competition.

There are no conflicting objectives or competing incentives among the orchestra players. The performance measures are simple. Do the players make music together? Business must examine its performance measures from this metaphor. Performance measures must incent teamwork and encourage working together for common goals without being penalized. Consider performance measures for the musicians such as "how many notes can you play per minute" or "who can finish their part first." This would be ludicrous. If business management creates individual incentive mechanisms, it must expect sub-optimal behavior by talented people, frustration and morale problems along with decreased productivity by those who do not "measure up" and decreased customer satisfaction.

Organizations can achieve significant benefits when they begin operating out of a horizontal, teamwork mind-set rather than a vertical, functional (individual) mind-set. This can be exploited exponentially in the information age, with our ability now to capture and share knowledge in ways not possible before.

For example, service technicians and customer service reps have significant and valuable knowledge about their company's products and their quality problems. The credit department may be the first place in the company to learn of quality problems when customers refuse to pay. Quality can be improved by incorporating this knowledge in product and service design and delivery.

When all departments and business units are working together as a team to accomplish common goals, new ways of productivity can be achieved. This productivity results from eliminating redundant information work or data clean-up that each area has to perform for itself, because it cannot trust the data created by the information supplier departments. Departments must view themselves not as isolated business functions, but as a component in a larger business value chain. While the work may be sequential, unlike the work of a symphony orchestra, there must be a cooperation among all parts of the value chain to assure a product that is perceived as valuable by the end customer.

To accomplish this, however, requires changes to the incentives and budgeting for information creation and maintenance. Performance measures must incent business areas that have upstream activities (information suppliers) to capture information needed by downstream knowledge workers, even though they do not need the data within their business area. They must not be forced to pay for that data capture out of their budget alone. The additional data capture must be funded in a way that is equitable for the data producer area and the ultimate downstream beneficiary areas. "If the reward system is competitive, the people in the system will view this as a competitive situation and act accordingly, despite the inherently cooperative nature of the situation." 2 In other words, if you ask an upstream department to capture your data for you, but do not provide funding to cover the additional costs of capturing data from which they do not directly benefit, do you really expect them to do it?

When you find business areas that do not want to cooperate, challenge and change the reward mechanisms. Management creates the performance measures and creates the "systems" in which the business cooperates--or competes--with each other. Management must change the reward mechanisms and performance "systems" that dis-incent teamwork and cooperation.

What do you think? Send your comments to LEnglish@infoimpact.com or through his Web site at www.infoimpact. com.

References

1 Drucker, Peter. The New Realities. New York: Harper & Row. 1989. P. 212-213.

2 Aguayo. Dr. Deming. P. 195.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access