Functional Process Improvement Fundamentals
Chapter 5: Process Analysis: Looking for Problems and Opportunitites

Department of Defense
Topic(s): Government BPR, Reengineering / BPR

[Previous] [Next]

Chapter 5

Please note: This chapter contains references to Figures which are actually portions of the text itself. They do not link to any external graphics images.

Process Analysis:

Looking for Problems and Opportunities

"A primary goal in implementing the Defense Information Management (IM) program functional management process is to minimize the time and resources necessary to identify, validate, and implement process improvements. This must be done in a manner that is consistent with common sense, sound business practice, and the provisions of DoDD 8000.1 and other DoD directives and instructions."

DoD 8020.1-M, Interim

Management Guidance, August 1992


1Figure 5-1. Chapter Introduction.

INTRODUCTION

This chapter discusses the basic elements of baselining an organization through process and data modeling and activity-based costing; and how these techniques can be used to identify process improvement opportunities in your organization. The discussion of each of these techniques will not be in any detail, however, we will be addressing the reasons why the use of IDEF0, Activity Modeling, IDEF1X, Data Modeling, and Activity-Based Costing (ABC) have been identified as the techniques of choice by DoD and many other Federal and private sector organizations.

Before we begin our discussion on activity analysis, it is important to understand what we are going to analyze. We will begin with a look at the central focus of our efforts in Functional Process Improvement (FPI), the functional process.

PROCESS MANAGEMENT

The Organization

Before we begin our discussion of process management, we need to have an idea of where processes come from. To do that we must talk about the basics of the organization. In many respects organizations dominate our society and our lives. In addition to our involvement in natural human groupings, such as families and friendship groups, we are typically born in organizations, educated by organizations, and spend our working lives employed by organizations.

An organization may be simply defined as a human grouping established to accomplish specific objectives. It is expected to perform a mission or turn out products or services, and as members of that organization, undertake to do the work involved, several observable characteristics of an organization emerge, including:

Division of work and specialization

Coordination of varied activities (processes)

Communication

Definition of relationships between activities, or people.

The word organization comes from organism, which is a structure with parts so integrated that their relationship to each other is governed by their relationship to the whole. This points out the two basic elements of an organization, parts and relationships. The parts being described by this definition are the activities (or processes) necessary for the accomplishment of the work and the people assigned to these activities. Parts should relate to each other, as the complimentary tasks of production and sales in a manufacturing firm. If they do not, that would be a very good place to start your analysis, however the most significant relationships arise among the people performing the activities.

The part of the organization that this text will address is the study of the activities, or processes, which are performed in the accomplishment of the mission of the organization. If we concentrate our management efforts on the activities being performed and look for ways to improve them, we would see a significant increase in the efficiency and effectiveness of the organization.

ACTIVITY ANALYSIS UNDERSTANDING THE BUSINESS

This section begins an in depth discussion of the steps and techniques involved in accomplishing the task of analyzing the function. The section focuses on how activity analysis and activity modeling help an organization understand how it currently does business, and how achieving this understanding is the first step in improving an organization's business practices. The focus is on documenting the current baseline (the "as is") and projecting functional process improvements into the future (the "to be").

We will explain the various techniques of activity analysis and activity modeling, and describe the types of resources and skills required to perform these techniques. We will also discuss what information activity analysis and modeling provide, what decisions can be made based on that information, and how to make those decisions. The IDEF0 technique of activity modeling is introduced in this section at a macro level. An exercise is used to demonstrate key activity modeling concepts.

General Activity Analysis Techniques.


...Keep in mind that different kinds of problems require different kinds of techniques; different aspects of any particular problem may require different kinds of techniques; and there are no panaceas. This means that to be a really effective analyst, you must keep a rich bag of tricks and know when and how to apply the right one at the right time.




Software Requirements Analysis &


Specifications, p. 57


1Figure 5-2. An Analyst's Bag of Tricks.....

This segment of the lesson provides a brief introduction to a variety of activity analysis techniques. There is no single activity analysis methodology that is suitable for all situations. In fact, most activity analysis methodologies are collections of different techniques that only address certain portions of activity analysis. The analyst's job will continue to require initiative and ingenuity to respond to different situations:

When choosing the activity analysis techniques that are appropriate for a given situation, the analyst should choose an integrated set of techniques that have the following traits.


Desirable Traits of Problem Analysis Techniques




Facilitate communication (probably via an easytounderstand language)




Provide a means of defining boundaries




Encourage the analyst to think and document in terms of the problem as opposed to the solution




Allow for opposing alternatives but alert the analyst to their presence




Make it easy for analysts to modify the knowledge structure




Adapted from: Software Requirements



Analysis & Specifications, p. 57


2Figure 5-3. Desirable Traits of Problem Analysis Techniques.

Let's look at an overview of several different general activity analysis techniques. The techniques are grouped into four different categories:

Observation and Interviewing

Modeling

Facilitated Group DecisionMaking

Performance Analysis

A very important message to convey at this point is that these categories of techniques are not mutually exclusive and are not sequential. In many situations, all four categories of techniques need to be applied to the analysis of a problem. For example, it is unlikely that an accurate model of an activity can be created without first observing the performance of the activity and interviewing the people who are involved in the activity. On the other hand, observation and interviewing will be much more organized and productive if these tasks are performed to gather information that can be used to build a model.

Let's take a look at each of these categories more closely.

Observation and Interviewing.

Before the observation and interview process begins, the analyst should have proposed an initial definition of the problem and specified the purpose of the analysis. It is also useful to identify the different viewpoints from which the problem is to be analyzed. The problem definition, purpose, and viewpoints should be reviewed and validated with the sponsors of the analysis. In the Structured Analysis and Design methodology, the purpose is defined by explicitly stating the questions to be answered by the creation of the activity model, and the viewpoint is defined by selecting the proper perspective from which to describe the system.

It is important to note that activity analysis is an iterative process. The initial problem definition, purpose, and viewpoints are useful in organizing the activity analysis but may be modified based on new information.

Benefits and Risks of Observation

BENEFITS: Gain firsthand knowledge about daytoday operations; provide basis for question formulation and problem verification.

RISKS: Too much observation can lead to identifying too closely with the way things are currently done; this loss of objectivity can inhibit the identification of alternative ways of describing and accomplishing system activities.

Interview Questions for Activity Analysis

1. Describe the activities you perform, or have direct authority over. Try to put them into 3-6 categories, then describe the sub-activities of each category.

2. What inputs, in the form of information, objects, or material do you need in order to perform each of these activities? Who gives them to you?

3. What are the outputs of the activities? Who do they go to?

4. What people, equipment, computers, and/or software are used in each activity to perform the work?

5. What problems do you encounter in performing these activities?

6. What opportunities do you see for improving the cost, quality, or responsiveness of these tasks?

Modeling techniques.

The purpose of this section is to introduce activity modeling as an essential component of activity analysis. Since the last four segments of this section deal specifically with activity modeling, we are not going to discuss modeling techniques in detail at this point.

Benefits of Modeling

Systems are usually difficult to understand, since they are often large, complex, and confusing. It is also difficult to remember all that is known about a system. (A model provides a method for capturing, organizing, and retaining information about a system.)

It is difficult to know if the conception of a system is correct. (A model provides a means for understanding and visualizing a system and validating the system through discussions with users).

Facilitated group decisionmaking techniques.

Facilitated group decision-making techniques provide a different approach to gathering the information required to perform an activity analysis and to construct an activity model. In this approach, structured group sessions and a workshop environment is used to extract information from users in a compressed time frame. The essence of this approach is the interaction of users and analysts working cooperatively as a team to address system requirements.

Some of the strengths and weaknesses of this approach are:

STRENGTHS:

Encourages commitment of senior management and participants.

Because the approach depends on the commitment of senior management, participants should feel that their time and contribution to the definition and analysis of requirements is important because of the organizationwide impact.

Condenses and accelerates activity analysis tasks. By combining the numerous activities that comprise the traditional requirements analysis process, facilitated group decisionmaking techniques accelerate the process for significant time savings.

Enforces topdown analysis by a joint team.

Fosters a spirit of cooperation between functional and technical staff. Participants gain a sense of "ownership" of the system.

Enhances understanding and analysis of the overall system through sharing of knowledge and communication. Both functional and technical knowledge of the overall system is increased through open communications during the workshop sessions. Participants often uncover things during the sessions that traditional procedures would have missed, such as redundancies, overlapping procedures, and commonalities with other functional areas.

WEAKNESSES:

Requires upfront dollar and time commitment.

Depends upon strong management and user commitment. A lack of management commitment may result in poor participation during the process.

Increases procedural and logistical difficulties. There are procedural difficulties in scheduling session times that are convenient for all participants and in involving all participants in all sessions.

Requires trained facilitators, analysts, and scribes.

Performance analysis.

Performance analysis is another form of activity analysis that may be used to define and bound activities. Measures of performance, i.e., cost, time, and quality, can help an organization set its priorities for detailed activity analysis.

Components of Performance Analysis Cost, Time, and Quality

Cost analysis allocates departmental budgets by cost element across the activities performed in the organization. COST ANALYSIS reveals the highcost drivers within the organization and reveals where the most significant impact can be made.

In many instances, certain activities within the business do not appear to be cost drivers and are not laborintensive, but may impact the ability of the business to operate. TIMELINE ANALYSIS allows the analyst to locate the bottlenecks within a system.

A function may not be costing a lot of time or contributing significantly to lead time, but may consistently generate poor quality output, which indirectly undermines the effectiveness of the organization. QUALITY ANALYSIS determines which activities have the greatest bearing on overall product quality.

ACTIVITY MODELING

What is activity modeling and why do you need to do it?

First let's define what a model is. A MODEL is a representation of a complex reality. MODELING is the act of developing an accurate description of a system.

Given these definitions,

ACTIVITY MODELING is the act of developing an accurate description

of the activities performed by a system.

At this point, it is important to emphasize that SYSTEM does not connote "automated system", but rather is a business system, which will be a combination of manual and automated components. In highlevel activity modeling, the distinction between manual and automated components is not important.

When we model a process, we can easily see the interrelationships of the specific activities that make up a process at any level of detail we desire.

This allows us to critically analyze each activity (task) that make up the process in our search for improvement opportunities. Because the facts about activities are displayed in both graphical and narrative form, this analysis can be objective, rather than subjective. If there are problems with an activity, these problems will be highly visible.

Activity models are hierarchial in nature. This means that we can start with a high-level view of our process, then successively break it down (decompose it) into layers of increasing detail.

The following are general steps in performing activity modeling:

Identify

Describe

Bound

Validate

Analyze

Why do we build both baseline (AS-IS) and target (TO-BE) activity models?

A baseline (AS-IS) activity model provides an accurate description of the way activities are currently performed. In addition to providing a means for bounding, validating, and analyzing activities, the model permits accurate performance measures of the activity's cost, time, and quality to be developed. Without such a baseline, it is impossible to analyze alternative methods of performing the activities.

A target (TO-BE) activity model provides a description of how the activities will be performed in the future. The boundaries of the target activity model should correspond to the boundaries of the baseline activity model (or differences should be clearly delineated). Performance measures for the target activity model are estimated to compare to the baseline activity model.

In an ideal situation, separate and complete baseline and target activity models would be developed for a system. However, often resource and time constraints do not permit two model to be built and maintained.

How can models be used to compare alternative methods of fulfilling requirements?

There is no easy answer!

In an ideal situation, a complete model of each alternative system for fulfilling a set of functional requirements would be constructed. Then these alternative models would be compared to the baseline and target models and to each other. This argues for an automated procedure for performing the comparisons. Some CASE tools do provide the ability to compare models and identify differences, but this is done at such a minute level of detail that the results are difficult to interpret. In performing comparisons that are meaningful, there is no substitute for the astute analyst.

In reality, time and resources are usually not available to construct complete models of each alternative. One possible approach is to model only those portions of each alternative that represent the greatest potential payoff in terms of improved business practices. This has a number of advantages:

Assists in Defining and Understanding the Alternative

Alternatives Can Be Defined in Equivalent Terms

Focuses on and Bounds the Change

Facilitates Definitive Comparisons

Reduces the Time and Resources Required to Perform the Comparisons

What is the difference between business activity modeling and information systems activity modeling? What are the relationships, and why is it necessary to do both?

This can be a controversial topic, especially from the viewpoint of information systems (IS) personnel, who may believe that IS modeling techniques are sufficient for modeling the business and that they have been modeling the business for years. In addition, there is really not a black and white distinction between business activity modeling and information systems activity modeling. Many of the differences are gray and are more a matter of perception than reality.

The following will help to show the differences between business activity modeling and information systems activity modeling. IS modeling is essentially the converse of the business side, which may present IS modeling in an unfair context. However, this does permit comparisons of the two techniques.


Distinguishing Characteristics of Business Activity Modeling



Models the Business from a Functional Perspective.




Focuses on Understanding and Changing Business Practices, not Automation of Business Practices.




Inputs and Outputs do not Represent Data.




Provides a Complete Description of a Set of Activities.



3Figure 5-4. Distinguishing Characteristics of Business Activity Modeling.

Compare to:


Distinguishing Characteristics of Information Systems Modeling



Models the Business from an Information Systems Perspective.




Focuses on Automation of Business Practices and Development or Modification of Automated Systems.




Inputs and Outputs Represent Data.




Does not Provide a Complete Description of a Set of Activities.


4Figure 5-5. Distinguishing Characteristics of Information Systems Modeling.

(Next Page)

INTRODUCTION TO IDEF0 MODELING AND OVERVIEW OF IDEF0 MODELING TECHNIQUES

What is IDEF?

IDEF0 is the DoD standard activity modeling technique. It has been proven effective and easy to use by functional people. There are many modeling tools based on IDEF0 which are used to create the models and supporting documentation. These tools also allow activity model data to be loaded into repositories for support of Computer-aided Software Engineering (CASE) tools.

IDEF is an acronym for Integrated DEFinition Language. It is a structured methodology for functional process analysis which has a long history of successful application.

As has been mentioned before, there are two forms of activity models. The first is the AS-IS model, which shows the current (baseline) structure of a functional process. The second is the TO-BE model which shows the objective (target) structure of a functional process. The difference between each form can be thought of as a set of improvements. Therefore the AS-IS model plus improvement actions equals the TO-BE model. Since improvement proposals are represented by the FEA, we can also say the AS-IS plus all FEAs equals the TO-BE model.

Seven Fundamental Concepts of IDEF0 (extracted from Wizdom Systems, Inc.)

Seven Fundamental Concepts of Activity Modeling as Implemented with

IDEF0

1. You cannot solve a problem if you don't understand it!

IDEF0 attacks a problem by building a model of the subject. The model answers questions about the subject.

2. Analysis of any problem is: topdown, modular, hierarchical, and structured.

3. IDEF0 is an activity model. It is independent of both organization and time.

It is not an organization chart!

It is not a flow diagram!

4. IDEF0 is a diagramming technique showing component parts, interrelationships between them, and how they fit into a hierarchical structure.

5. IDEF0 methods support disciplined, coordinated teamwork.

This does not mean you model by committee.

This does mean that an IDEF project is a team effort.

This does mean that the results will reflect the best thinking of a team.

6. IDEF0 is structured and rigorous!

IDEF0 methods follow rules and require all analysis and design decisions and comments to be in written form.

7. IDEF0 follows the principle of gradual exposition of detail.

This last concept is a very important one that deserves more explanation.

Keep the top levels simple!

IDEF0 diagrams progress from more general to more specific.

An IDEF0 model starts by representing the whole system as a simple unit in a single box. The single box has a general name and the interface arrows are general.

The single box is decomposed into its, subactivities. They will have more specific names and the arrows will be more specific.

Each of those boxes will be decomposed into its subactivities. They will have more specific names and their interfaces will be more specific.

Even though the diagrams may have fewer activities and interfaces, the information on them will get more detailed.

IDEF0 Components

Now let's look at the component parts of an activity model. Each of the components presented below are applicable to both AS-IS and TO-BE models. The components are:

Node Trees, which Graphically Portray Activities in a Hierarchical Format

Context Diagram, a Single Diagram that Illustrates the Highest Level Activity and Its Information or Materials

Decomposition Diagrams, which Represent Refinements of an Activity by Showing its Lower Level Activities and their Information Relationships

FEO (For Exposition Only) Diagrams, which are Used to Focus Attention on a Particular Portion of a Node Tree, Context, or Decomposition Diagram

CONTEXT, PURPOSE, AND VIEWPOINT.

The CONTEXT establishes the subject of the model as part of a larger whole. It creates a boundary with the environment by describing external interfaces.

The PURPOSE establishes the intent of the model or the goal of communication it serves. Purpose embodies why the model is created (functional specification, implementation design, customer operations, etc.).

The VIEWPOINT determines what can be "seen" within the context, and from what "slant". It states the author's position as an observer of or participant in the system for the benefit of an audience.


2Figure 5-6. ICOMs.

ARROWS: INPUTS, CONTROLS, OUTPUTS, AND MECHANISMS (ICOMS).

Input Information or Material Used to Produce the Output of an Activity

Control Information or Material that Constrains an Activity; Controls Regulate the Transformation of Inputs into Outputs

Output Information or Materials Produced by or Resulting from the Activity

Mechanism Usually People, Machines, or Existing Systems that Perform or Provide Energy to the Activity

Benefits of IDEF0 Modeling (extracted from Wizdom Systems, Inc.)

1. IDEF0 provides an understanding of the "asis" environment.

The model answers the questions "What do I do?" and "What information do I need to do what I do?"

2. IDEF0 provides a means for communicating and presenting results.

Everyone is looking at the same model.

Everyone is using the same definitions.

Everyone is talking about the same thing!

3. IDEF0 identifies and categorizes information entities which form the foundation for information modeling.

The IDEF0 arrows represent things. Entities in data modeling represent things we wish to store information about.

Therefore, the arrow labels in IDEF0 diagrams form a list of potential entities for IDEF1X.

4. IDEF0 provides a tool for managing projects.

It structures how the team is organized.

It enforces a stepbystep approach.

It tracks the evolution from problem to solution.

It requires strict documentation, overseen by the project librarian.

5. IDEF0 establishes a forum and a structure for interviewing people.

You have specific information to find out and a specific agenda to follow.

The diagram provides a way of depicting the information gained from the interviews and verifying that you got it right.

6. IDEF0 identifies opportunities for improvements.

The IDEF interview and modeling process bring opportunities to the surface.

7. IDEF0 reveals information flow relationships and incongruities.

You often find that the people who need the information are not the people getting it, and the people getting it don't need it!

8. IDEF0 reveals redundant activities.

You often find out that the same activity is unnecessarily performed in more than one place in the organization!

9. IDEF0 documents the "asis" for baseline evaluation and further analysis.

You have to know what you have, to know what to do to fix it!

10. IDEF0 begins the roadmap from the "asis" to the "tobe".

You now know where you are starting from so you can go to where you want to be! Even if you know where you want to go, you can't get there if you don't know where you're starting from. Ask any pilot!

Difficulties of IDEF0 Activity Modeling

Complexity of Diagrams.

Distinguishing and Separating the "AsIs" from the "ToBe".

Distinguishing and Separating Different Viewpoints.

Identifying and Distinguishing Between Controls and Inputs.

Establishing the Proper Boundaries for the Model.

Activity models have many uses. For our purposes, we are most concerned about their use in the Functional process Improvement Program. Activity models (AS IS form) help us understand what we are actually doing to carry out our organizational mission and business objectives. These models are developed by the functional community working in facilitated decision teams.

Understand our Processes

From this understanding, we can develop improvement options or alternatives that will add value to the process and/or lower the cost of the process. With this information, TOBE models are constructed, which test and/or illustrate the proposed changes. This way it is possible to simulate the proposed set of changes to verify their effectiveness.

Data Models

Activity models are also required to develop data models, which we'll discuss next. Since ICOMs show data flows between activities, they are critical in gaining a full understanding of how to structure data resources and information systems.

Aid in ActivityBased Costing

Activity models are mandatory for performing activitybased costing studies, which we'll discuss in the next module.

Supporting Documentation

Activity models provide supporting documentation for briefings, presentations, and development of Functional Economic Analyses (FEA).

Communication

Finally, activity models are wonderful vehicles for employee and contractor orientation and training purposes.

An IDEF0 Example.

To explain Activity Modeling, or IDEF0, let's go through a simple example of painting your car.

The first level of activity modeling we'll discuss is called a Context Diagram. This shows the scope of the activity and the major inputs, controls, outputs and mechanisms in this activity. Here we have an example of the highest level ICOM for the "process" of painting a car.

For our example, the input is the car that needs to be painted. The controls may include budget constraints and time limitations. The output is what you expect to


3Figure 5-7. Example -- Context Diagram.

receive at the completion of the activity, a painted car. Finally, the mechanisms that support painting the car are the owner and the painter (or vendor).

Also note that the context diagram specifies the viewpoint in the lower right comer of the visual. This activity is going to be modeled from the point of view of the car owner. Do you think the activity might be modeled differently if it were being done from the point of view of the car painter?


4Figure 5-8. Example -- Node Tree.

The next step in the activity modeling process is to decompose the context diagram into the specific activities that must be completed to paint the car. In IDEF0 this is called creating a Node Tree. A node tree is like a work breakdown structure that project managers use.

In our example, "Paint Car', has been decomposed into four activities: select vendor, select color, arrange financing and paint car. For the purposes of this session, we will stop at this level of decomposition. However, do you think it might be

possible to decompose any of these activities further? What about arrange financing?

Node trees provide a fast means of identifying a sequential series of steps or tasks that are performed in the functional process. Each entry in the node tree is given an identifier. The top entry which represents the process, is called the "A-0" node. This node represents the context diagram for the model. All of the nodes directly below the "A-0" node are numbered sequentially, such as A1, A2, A3. If further levels are needed, an additional level of numbering is used, such as A11 , A12. These numbers would represent the nodes below the A1 entry.


5Figure 5-9. Example -- Decomposition Diagram.

Once the node tree has been created, we can build a decomposition diagram of our model using ICOMs. First, we array four boxes in a descending, stair step fashion. This arrangement facilitates drawing the lines on the diagram. It does NOT necessarily indicate the sequence of events or the time required for each step.

Once the boxes are drawn, we create the inputs, outputs, controls and mechanisms for each box, thereby creating an ICOM for each activity. Notice that the output of the Select Vendor activity is Vendor. That becomes the mechanism for the Paint Car activity. Next, notice that some controls are shared by more than one activity, such as budget and time.

The output of the Select Color activity, Color, becomes the control on the Paint Car activity. And the mechanism Owner supports three activities: Select Vendor, Select Color, Arrange Financing.

This simple example of IDEF modeling illustrates most of the features of a typical decisionmaking process model. Some key points to remember about IDEF modeling are:

The analysis must reflect a specific viewpoint

The ICOM is the working element of the IDEF diagram

IDEF diagramming follows a structured approach from the A-0 level through decomposition to the lowest level needed for the analysis

The first time through an activity analysis process does not need to be perfect. Subsequent iterations of the analysis will continue to improve the model at all levels

Activity modeling is a methodology for using facilitated functional/technical teams to make decisions and reach consensus on the working relationships of the functional process.

INTRODUCTION TO DATA MODELING AND OVERVIEW OF IDEF1X MODELING TECHNIQUES

Data models, like activity models, provide a graphical tool that aids in our search for improvement opportunities. Data models also identify "business rules" which portray or constrain the way activities function. These constraints are enforced in information systems that are designed to support functional processes.

For instance, in a payroll process, our data model would prevent the issuance of a paycheck to someone who was not an active employee. However, it's important to understand that data models are necessary whether or not an automated information system is involved in the process. Activity models and data models are built iteratively, working back and forth until the models are synchronized and mutually supporting.

The DoD standard technique for building data models is called IDEF1X. As with activity models, there are automated tools that help us document our data models and provide a means of storing data model representations in repositories.

Data Modeling -- Purpose.

Data models graphically display the data and information required to support functional processes. Data models are rigorous, structured models of the business relationships or business rules and data needed by data administration to support the needs of a functional area. Data models support shared data concepts, help reduce costly data redundancy, improve data integrity, and lower the cost of managing the data resource.

Data models can be developed at various levels of technical detail and complexity. In general, data models are developed at the same level of depth and detail as the activity models they support. Functional users are only required to develop data models to a sufficient level of detail to support the purposes of the FEA. This skill is learned by functional users through training and process improvement experience.

Data Modeling -- Formats.

Like activity models, data models are developed in ASIS and TOBE formats. The ASIS model shows the current (baseline) relationships, while the TOBE model shows the proposed or target data environment. Both forms of data models must be synchronized with their activity model counterparts. Like activity models, data models are developed by facilitated decision teams.

Data Modeling -- Components.

We will overview three levels of data models:

Entityrelationship diagram

Keybased data model

Full attributed data model

But, before we look at these models, let's review some basic definitions related to data modeling.

Data are defined as facts about real world objects.

Information is two or more facts (data items) expressed in some meaningful form in the context of a functional process or activity.

An entity is a collection of data (facts) about a person, place, thing, concept, idea or event.

An attribute is one characteristic (fact or data item) of an entity.

A relationship describes how two or more entities interrelate. A relationship is also called a business rule.

A key attribute describes a data item that acts as a means of accessing an entity.

If these terms and definitions make sense to you, you have most of what you need to create data models.

Entityrelationship diagrams are the highest level data model. In an entityrelationship diagram, we notate each entity that is involved with our functional process. For instance, in our simple car painting example, we would show entities for such things as automobile, vendor and financing.

As we note the entities, we draw lines between the entities that illustrate how they relate to each other. Our vendor entity would be related to all of the automobiles that are painted and also to all of the financing which pays for the paint jobs. Relationships (the lines between entities) are the heart of the matter.

Relationships have a property called cardinality. Cardinality expresses a quantitative property of the relationship.

Let's look at the principle types of cardinality using a sociological example:



Cardinality Sociological Rule

One-to-one Monogamy

One-to-many Polygamy

Many-to-many Group marriage

5Figure 5-10. Cardinality.

In our car painting example, we would have a onetomany relationship of vendor to automobile, and a onetomany relationship of vendor to financing. The way we would say this is, "A vendor can paint many automobiles, but each automobile can be painted by only one vendor. A vendor may have many financing arrangements, but each financing arrangement can pay only one vendor."


6Figure 5-11. Entity-Relationship Diagram.

There are other types of cardinality, but one to many is the most common. Do you see why we sometimes call relationships "business rules?" They work to constrain the way we want to do business. The complete entityrelationship diagram shows all of the collections of data (entities) that are needed to support our functional process, and the way these entities are used together to constrain the activities in our functional process. This is why functional users must build the model, because only they fully comprehend the import of the business rules imposed by a data model.

A keybased data model is a refinement of an entityrelationship diagram. In this level of data modeling, we show the primary data items (elements or attributes) that define each entity. The keybased data model also indicates which of these attributes will serve as a unique identifier or key so that we can access the entity. This is needed whether the entity data will be stored in a computer file or in a file cabinet.

We may also show secondary keys which become, in effect, means of sorting data for report or query purposes. In this example, an attribute of automobile with "car license,' as the unique identifier or key for every car being painted is shown. No two cars could have the same license number. Likewise, vendor and financing would have unique keys.


7Figure 5-12. Key-Based Data Model.

A fully attributed data model has all of the information contained in the keybased model, but it also has all of the dataitems (attributes) for each entity. Notice that the attributes for vendor include name, cost, reputation, and quality.

Functional users are seldom required to identify all of the attributes they need in each entity without some support from the technical elements.


8Figure 5-13. Fully Attributed Data Model.

Most functional people and the construction of activity and data models to be an enjoyable and fascinating experience. Even oldhands who have worked in a functional area for many years learn something new about their business as a result of building and refining these models.

Data Modeling Uses.

Data models, like activity models, are used for a variety of purposes. The principle use in this context is to support the FPIP.

Unlike activity models, which are often constrained to one functional area or activity within an agency of DoD, data models have to be considered in the light of the entire DoD data resource. This is because DoD has a mission to construct a shared data resource that supports the entire Department. Data models are an indispensable component of this effort.

Apart from this special use, data models share all of the uses we described for activity models.

PROCESS MODELING -- SUMMARY

Activity and data modeling techniques using IDEF0 and IDEF1X are proven methods for use in the Functional Process Improvement Program. These techniques are appropriate for both major process redesign projects involving new or redesigned information systems, and continuous process improvement projects.

Modeling provides a clear, consistent, structured approach to analyzing the workings of functional processes (ASIS) as well as a technique to develop, test and implement improved functional processes (TOBE).

IDEF Modeling sessions have been refined through years of practice within DoD and proven to be the most economical and effective way of proceeding with process improvement programs.

How can IDEF0 models be used to reveal non-value-added activities, problem areas, and opportunities for improvement?

In the process of building the baseline IDEF0 model, problem areas and opportunities for improvement may be identified simply as a result of defining and describing the activities, inputs, controls, outputs, and mechanisms.

For example, building a model is an effective way of identifying redundancies and disconnects in the activities performed within a system. After the model is built, applying cost and performance measures to the baseline activities will also identify the high and low cost activities, nonvalueadded activities, and activities in which cost and performance measures are substantially higher or lower than in related activities.

Later in this course, we will talk briefly about specific ways to exploit improvement opportunities. But for now, let's take a look at another important technique that aids a functional manager in defining the AS-IS environment --- Activity Based Costing.

OVERVIEW OF ACTIVITY BASED COSTING

ActivityBased Costing (ABC) is a form of cost accounting that focuses on the costs of performing a functional process rather than on the costs associated with an organizational unit.

ABC analysis allows an organization to determine the actual resource cost of each product or service it produces.

When these costs are known, it becomes possible to analyze each activity in the functional process to determine if the performance of that activity adds value to the outgoing product or service. ABC analysis also highlights nonvalue added costs associated with value adding activities.

With this information, you can identify improvement opportunities that will help lower the cost of producing products and services or add value to our products and services without increasing costs.


9Figure 5-14. Activity Types.

ABC analysis depends on the existence of ASIS models because that's where information about the activities you want to analyze is stored.

In this section, we will define activities from an activity cost perspective, overview the sixstep process for conducting an ABC analysis, define the terms activity measure and cost basis, discuss how to identify improvement opportunities, and finally, how to use TOBE modeling to test or prototype improvement options.

As we have seen from the previous section on activity modeling, activities are the stuff that make up functional processes. When you perform activity modeling, you are identifying the sequence of tasks necessary to accomplish a functional process objective along with information about how each activity interacts with others. You can then study the functional process in terms of its component activities in our search for improvement opportunities.

Let's start out this section with a discussion of types of activities.

Repetitive

Repetitive tasks are those performed over and over in our functional process. Generally it is a sequence of repetitive activities that define the purpose of the functional process.

Non-repetitive

Non-repetitive activities are generally those associated with exceptional conditions in our functional process. Non-repetitive activities are also associated with one-time or seldom-used projects that support main-line functional processes.

We can find improvement opportunities in both types of activities, but as we will see, they are different in nature and in impact on business unit goals and objectives.

Primary

Primary activities contribute directly to the mission of the organizational unit. Take away a primary activity and you can no longer develop the products and services of the functional process. It is a sequence of primary activities that transform inputs to a process into output products and services.

Secondary

Secondary activities are associated with overhead on a functional process or with producing products and services that are used wholly within the functional process. Overhead costs are not necessarily undesirable.

In looking for improvement opportunities, we often want to optimize primary activities, perhaps with automated information system support, but we want to safely minimize secondary activities, thereby reducing the cost of a product or service but not its value.

Required

Required activities pertain to secondary activities that are mandated by higher authority. (It is assumed that primary activities are also required activities.) If the required activity is justified, or cannot be modified, then we want to perform it at the least cost. If it is not justified and we can change the requirement than we want to eliminate the required activity.

Discretionary

Discretionary activities are secondary activities that have been imposed by management within the process. This type of activity often results from a problem that occurred with the functional process in the past. Discretionary activities need to be reviewed periodically to see if they are still needed. The terms "bureaucracy" or "red tape" are sometimes applied to discretionary activities.

Value Added

An activity is defined as value added when the costs of the inputs plus activity costs is less than the worth of the output product to service. Worth or value only have meaning when customers have more than one choice for the same goods or a choice not to use the goods.

Non-value Added

An activity is defined as non-value added when the costs of the inputs plus activity costs is greater than the worth of the output product or service.

The purpose of activity-based costing analysis is to define activity types, then optimize those that are value added and reduce or eliminate those that are non-value added. Knowing the type and purpose of each activity is an aid to doing this.

Outputs consume activities. This will hold for every activity that we have rationalized down to one primary output.

If you can identify a primary output that reliably models an activity's consumption of resources, you then have a means of optimizing that activity. It is not always easy to find the primary output measure as its called, but get as close as you can. If you are having a problem finding the output measure, than you haven't rationalized the activity.


10Figure 5-15. Activity Characteristics.

If your activity produces purchase orders, you may find that purchase orders is the measure, or you may find that line items is the measure. The point is to find an output that patterns the characteristics of the activity.

We are now going to look at how to determine activity costs. Remember that the procedure for determining activity costs is performed after the procedure for activity analysis.

Activity costs are dependent on external and/or internal factors.

External factors include (with examples):

Markets (cost of inputs)

Competition (output features and pricing)

Weather (cost of resources)

Economy (cost of money)

Internal factors include (with examples):

Policy (nonvalue added constraints)

Employee skills and experience (labor efficiency)

Capital base (investment funding for new equipment)

Analyzing activity dependencies helps us identify both improvement opportunities and risks associated with improvement analysis.

Leverage

Finally, activities are analyzed based on their impact, or leverage. Leverage is a modem way of saying "more bang for the buck." Highleverage activities offer the best potential for worthwhile improvement opportunities including automation.

High leverage activities include (with examples):

Design activities (innovative products)

Production activities (lostcost products)

Marketing activities (more customers)

Lowleverage activities are candidates for downsizing or even elimination. Lowleverage activities generally should not be automated at least until we have satisfied the automation needs of highleverage activities.

Lowleverage activities include:

Compliance/oversight

Administrative

Inspection

Empowering work teams to be self managed is one technique organizations are using to reduce and eliminate lowleverage activities.

Now that you have an understanding of activity types and characteristics, we can discuss a sixstep program for performing activitybased costing (ABC). Remember, ABC is an extension of activity modeling that adds cost and time factors to our models.

The sixstep process of ABC analysis is a refinement and supplementation of activity modeling. The six steps are (with explanations):

Determine activity analysis scope (mission and objectives)

Determine activity analysis units (functional processes)

Define activities (ASIS activity models)

Rationalize activities (level of detail and complexity)

Classify activities (type and characteristics)

Create an activity map


11Figure 5-16. Steps of ABC Analysis.

1. Scope. Before you can proceed very far with an improvement program, you must have a clear, consistent and acceptable statement of mission and organizational goals and objectives.

2. Units. This step clarifies the functional process (or subprocess) that you are going to analyze. You must have a clear understanding of the boundaries of the problem. This step is accomplished during strategic planning and illustrated in your activity model context diagram.

3. Define Activities. Activity modeling provides about 70% of what you need for this step. For ABC analysis, you need to determine the nature and extent of the major resources used in each activity. The primary concerns are labor grade and costs, and equipment.

It is also useful to find out which are the most laborintensive, costly and timeconsuming activities.

Generally, after the activity modeling phase of an improvement project is complete, the project team uses the activity models as a basis for interviewing key people associated with the functional process and researching accounting data and computer records to fill in the gaps from activity modeling.

In most cases, the labor hour data will be the most critical for most DoD functional processes. There are two rules to keep in mind:

The Pareto principle that says that 80% of the data needed can be gotten with 20% of the effort it would take to get 100% of the data. 80% is usually sufficient for improvement project purposes.

The cost of the analysis must not exceed the value of the results. This requires judgement on the part of the project team.

4. Rationalize Activities. This step in the process assures you that you have a sufficient level of detail to continue the analysis, but not too much detail, which would lead to unnecessary complexity or unacceptable analysis costs.

An activity is at the proper level of detail for ABC analysis when two main criteria are satisfied:

One primary output of the activity is determined to represent or define the purpose of the activity. All other outputs can be considered byproducts of the principle output.

The activity is decomposed in such a way that it is a complete unit of work that could be contracted out. This implies a welldefined activity.

Please note that both of these criteria must be satisfied simultaneously.

You may want to note that activities can be decomposed into tasks and tasks can be decomposed into operations or steps. We are not interested in working at the task or operation level because this is too much detail for our purposes.

5. Classify Activities. This is the step where primary and secondary activities are separated.

The rule of thumb to use is that primary activities produce outputs, or contribute to the production of outputs, that are used outside of the organizational unit. Primary activities are the reason the functional process exists.

Secondary activities produce outputs that are used within the organizational unit. Secondary activities are "overhead". This does not mean that secondary activities are not important. They are often related to oversight, safety and security functions.

Studies have shown that a wellrun organization will have an 85:15 ratio of primary activities to secondary activities. You can use this guideline in your analysis. If you find a larger proportion of secondary activities, investigate to see if they are absolutely necessary.

When assigning costs to activities, determine the actual cost elements for all primary activities, but allocate costs to secondary activities. This is done to decrease the cost of the analysis. Of course, if secondary activity costs are easily determined, they should be documented.

6. Activity Map. The final step in the process is to create an activity map. An activity map shows the alternatives available to satisfy the requirements of each activity in our model.

Some of the common alternatives in an activity map are:

Make vs buy

Inhouse vs contract

Lease vs buy

Manual vs automated

Off theshelf vs custom

Draft quality vs highresolution

An activity map provides information that drives our redesign or improvement process. It also can help support the requirements of an FEA.

The six step process of activity analysis is a refinement of activity modeling, which provides information related to the classification and costing of each activity in a functional process.

With this information, we can move on to the process of determining the actual cost of each product and service that our process produces. Once you know those costs and analyze them, you can support such initiatives as feeforservice, unit cost management, and continuous process improvement.

Activity Costs

The key to understanding activity-based costing is to remember that:

Outputs consume activities

Activities consume resources

Outputs consume activities --This will hold for every activity that we have rationalized down to one primary output. If you can identify a primary output that reliably models an activity's consumption of resources, you then have a means of optimizing that activity. It is not always easy to find the primary output measure, as it is called, but get as close as you can. If you are having a problem finding the output measure, then you haven't rationalized the activity.


12Figure 5-17. Activity Cost Analysis.

If your activity produces purchase orders, you may find that purchase orders is the measure, or you may find that line items is the measure. The point is to find an output measure that patterns the characteristics of the activity.

We are now going to look at how to determine activity costs. Remember that the procedure for determining activity based costs is performed after the procedure for activity analysis.

The seven step procedure for performing a cost analysis follows:

Select cost basis

Trace resources

Determine activity performance measure

Select activity measure

Allocate secondary activities

Calculate cost per activity

Create a billofactivities

1. Cost Basis. Selecting a cost basis is one of the most critical decisions in activitybased costing exercises. The cost basis identifies the type of dollars to use.

There are several choices:

n Actual: Financial transaction analysis

n Budgeted: Management opinion

n Standard: Management fiat

n Planned: Business planning

n Engineered: Formal study and analysis

Two major considerations when selecting a cost basis are the availability of cost data and applicability of cost types to the activities that make up our process.

You also have to select a time horizon. This is also a critical decision because some activities vary by business cycle. For instance, if your activity was selling toys, picking a three month time horizon would give different results if you used September through November rather than January through March.

You may select one cost basis for ASIS analysis and a different one for TOBE analysis.

2. Trace Resources. Once a cost basis and time horizon have been selected, begin using available records, interview data and other means to calculate the amount (in dollars) of each resource type consumed by each activity in the functional process.

The following list of resources or factors of production may be selected:

. Inhouse labor . Contract labor

. Material . Technology (equipment)

. Utilities . Plant and facilities

. IS resources . Freight

. Travel . Training

Labor is usually the major expense category in government functional processes.

Labor costs can be traced to activities by:

Percentage of time spent by each employee on each activity

Percentage of time spent by each employeetype on each activity

Average labor cost per activity

3. Performance Measure. Next, select a performance measure. Performance measures are not the same as activity measures. Performance measures can be one of the following:

Dollars

Actual and elapsed time

Quality measures (rejects, returns, scrap)

Flexibility (react/response capability)

One of the considerations to keep before you is that you cannot have an improvement in one performance measure area at the expense of some other measure. For example, a cost savings at the expense of quality or flexibility may be very undesirable.

4. Activity Measure. You need to confirm the selection of the activity measure based on the cost basis, time horizon, resource selections and performance measures. Remember the rule that the activity measure must reflect the way the activity consumes resources or it is of little use.

Also keep in mind the fact that you are working with incomplete data, averages, and approximations. When working with numbers, the result is only as accurate as the least accurate component of an equation.

Finally remember that this is a program of continuous process improvement. Solving half the problem on the first iteration is a great accomplishment. More of the problem can be solved in the following iterations.

5. Allocate Secondary Activities. Secondary activities are measured in overhead costs. Overhead costs are allocated to primary activities based on some meaningful ratio or algorithm.

Of course, this analysis would first look at ways of eliminating or reducing secondary activities before allocating their cost to primary activities.

Secondary costs are usually allocated to primary activities by labor cost. For instance, if a primary activity consumes 20% of the total labor for the functional process, you might allocate 20% of all overhead costs to that activity.

If you have sufficient information to more accurately allocate overhead, use that information. For instance, training may be considered a secondary activity. If more training dollars are spent on engineers than clerical personnel, allocate training overhead not by percentage of labor hours but by type and percentage of labor hours. In this way, the primary activities consuming more engineering hours would carry more of the training overhead.

6. Calculate Cost per Activity. The next step is mechanical and can be performed using computer tools.

Activity cost = (Traceable resource costs + Allocated costs)

Activity measure

Results are expressed in dollars/unit of measure.

7. BillofActivity. The final step is to construct a billof activities for each major product and service our functional process produces.

A billofactivities is similar in concept to a billofmaterial, which calculates the total cost of materials used to build one unit of product. A billofactivities is a listing of the activities that are used to perform or produce a product or service plus the costs associated with each activity. It summarizes the total activity costs to produce one unit of product.

If the billof-materials represents the total costs of the inputs (raw materials) for a product, and the billofactivity represents the total costs of the resources used to produce that product, you have all of the information needed to support feeforservice and unitcost management.

For instance, using the car painting example discussed earlier, a bill of activities might look like this:

Select Vendor (Associated Costs)

Select Color (Associated Costs)

Arrange Financing (Associated Costs)

Paint Car (Associated Costs)

Total Costs for this Activity

ABC -- Summary

Activitybased costing is a natural and integral component of the functional process improvement concept. ABC analysis provides an understanding of what it really costs to produce the products and services you are in business to provide to your customers. Appendix E of 8020.1M maintains a summary of activitybased costing.

Some key points about activitybased costing:

1 . ABC is based on the use of approximations which are refined each time the analysis is iterated.

2. A key problem is finding the data you need to support the cost basis for analysis. This becomes less of a problem with each iteration because you can begin to collect appropriate data for the improved functional process.

3. Activitybased costing is not financial accounting. The books and records of the organizational unit must still be kept based on transaction costs.

4. The activity model upon which ABC is based need only be accurate, in general, in terms of the Pareto principle.

5. Because overhead costs are usually allocated to primary activities based on an approximation, the calculated cost of an output product or service is an approximation.

6. ABC analysis is more accurate when the results are based on how a functional process actually works, not how people think it works.

7. All assumptions and approximations should be documented so that the next iteration of the analysis can build them.

FUNCTIONAL PROCESS IMPROVEMENT ANALYSIS TOOLS AND TECHNIQUES

Once you have established the AS-IS environment of the function, you can use one or several of the following process improvement analysis tools and techniques to analyze the models for improvement opportunities. This course does not go into all of the tools and techniques available to the analyst, however, we hope this brief list will give you a start.

1. Benchmarking.

What: Method of measuring your processes against those of recognized leaders. It helps you to establish priorities and targets leading to process improvement.

Why: When you know where you stand with respect to your competitors or other worldclass operators, you can target various processes for improvement.

How:

Identify processes to benchmark and their key characteristics.

Determine who to benchmark: companies, organizations or processes.

Determine benchmarking by collecting and analyzing data from direct contact, surveys, interviews, technical journals, and advertisements.

From each benchmark item identified, determine the "best of class" target.

Evaluate your processes in terms of the benchmarks and set improvement goals.

2. Cause and Effect Diagrams

What: Represents the relationships between an effect (problem) and its potential causes, opinions of a small group (10-15 people).

Why: The diagram is drawn to sort and relate the interactions among the factors affecting a process.

How:

Name the problem.

Decide the major categories of causes major causes may include: data and information systems, dollars, environment, hardware, materials, measurements, methods, people and training.

Brainstorm for more detailed causes.

Eliminate causes that do not apply.

Discuss the remaining causes and decide which are most important.

Work on most important causes.

Desensitize, eliminate or control causes.

3. Nominal Group Technique

What: A technique similar to brainstorming. A very structured approach to generate ideas and surveys the opinions of a small group (10-15 people).

Why: Produces many ideas/solutions in a short time. Structured to focus on problems, not people; to open lines of communication; to ensure participation; to tolerate conflicting ideas. Helps build consensus and commitment to the final result.

How:

Present issues, instructions.

Generate ideas, 5 to 10 minutes of quiet time, no discussion.

Gather ideas round robin, one idea at a time, written on flip chart and posted.

Process/clarify ideasduplicates are eliminated; like ideas are combined. Limit discussion to brief explanations of logic or analysis of an item and brief agreement, disagreement statements. Focus on clarification of meaning, not arguing points.

Set priorities silently.

Tabulate votes.

Develop an action plan.

4. Quality Function Deployment (QFD)

What: A conceptional map that provides the means for cross-functional planning and communications. A method for transforming customer wants and needs into quantitative, engineering terms.

Why: Products should be designed to meet customers wants and needs so that customers will buy products and services, and continue to buy them. Marketing people, design engineers, manufacturing engineers, and procurement specialist work closely together from the time a product/service is first conceived to be able to meet customer, requirements. Provides the framework for the crossfunctional' teams to work within.

How: Ask these questions:

What do customers want (attributes)?

Are all preferences equally important?

Will delivering perceived needs yield a competitive advantage?

What are the engineering attributes that match customers attributes?

How does each engineering characteristic affect each customer attribute?

How does one engineering change affect other characteristics?

5. Pareto Charts

What: A bar chart in which the bars are arranged in descending order with the largest to the left. Each bar represents a problem. The chart displays the relative contribution of each subproblem to the total problem.

Why: This technique is based on the pareto principle which states a few of the problems often account for most of the effect. The pareto chart makes clear which "vital few" problems should be addressed first.

How:

List all elements of interest.

Measure the elements, using the same unit of measurement for each element.

Order the elements according to their measure, not their classification

Create a cumulative distribution for the number of items and elements measured and make a bar and line graph.

Work on the most important elements first.

6. Statistical Process Control (SPC)

What: Method for determining the cause of variation based on a statistical analysis of the problem. Uses probability theory to control and improve processes.

Why: An effective tool for improving performances of any process. It helps identify problems quickly and accurately. It also provides quantifiable data for analysis, provides a reference baseline, and promotes participation and decisionmaking by people doing the job.

How:

Identify problems or performance improvement areas. Identify common and special causes. Common causes are random in nature, often minor. Special causes result from an abnormality in the system that prevents the process from becoming stable.

Do a causeandeffect analysis.

Collect data.

Apply statistical techniques (may need a statistical specialist).

Analyze variations.

Take corrective action.

7. Histograms

What: A graph that displays frequency of data in coluunn form.

Why: It helps to identify changes or shirts in processes as changes are made. it shows how variable measurements of a process or product can be, and it helps in establishment of standards. Once standards have been set, measurements can be compared to these standards.

How:

Determine measurements to be taken.

Collect data.

Organize data into incremental units.

Develop a graph to pictonally sunnmanze results.

8. Check Sheets

What: A list of checkoff items that permits data to be collected quickly and easily in a simple standardized format that lends itself to quantitative analysis. Check sheets are frequently used to collect data on numbers of defective items, defect locations, and defect causes.

Why: Facilitates data collection by providing a standardized format for recording information.

How:

Identify data to be collected.

Design check sheet to collect data.

Collect data.

Tabulate results.

9. Scatter Diagrams

What: Diagram that depicts the relationship between two factors.

Why: Helps lead toward possible causes of problems by determining correlations between two factors.

How:

Develop hypothesis about the correlation between two events (if "X" occurs, then "Y" will occur.)

Collect data to test hypothesis.

Develop a graph to summarize the results.

Analyze results to determine if a cause-and-effect relationship exists.

10. Cost of Quality

What: A system providing managers with cost detail often hidden from view. Cost of quality consists of all the costs associated with maintaining acceptable quality plus the costs incurred as a result of failure to achieve this quality.

Why: The cost of not doing things right the first time can be considerable. This includes administrative work.

How:

Identify quality costs. These are the costs of non-conformance and the cost of conformance.

Develop a method for collecting data and reporting on cost of quality.

Identify the most significant costs.

Identify the causes of these major costs.

Identify the solution to reduce or eliminate causes.

Implement the solutions.

Cost of Quality Examples:

Prevention:

Quality engineering

Quality planning

Design verification and review of manufacturability of new products

Quality training

Quality improvement projects

Statistical process control activities

Appraisal:

In-process inspection

Set-up for testing

Administrative costs for quality assurance personnel

Internal Failure:

Scrap

Rework

Reinspection of rework

Downtime caused by defects

Investigation of failure or reqork

External Failure:

Warranty adjustments

Repairs

Customer service

Returned goods

Investigation of defects

Product liability suits

11. Control Charts

What: A graphic representation of measured actual process performance relative to computed control limits. Control charts are used to show the variation in process variables and identify special causes.

Why: Allows you to distinguish between measurements that are predictable within the inherent capability of the process (common causes of variation) and measrurements that are unpredictable and produced by special causes.

How:

Determine control limits to describe the expected variation of a process.

Collect data.

Plot data on control chart to assess performance and identify points outside established control limits.

Identify ways to eliminate special causes, reduce normal variation, and improve the mean.

12. Work Flow Analysis

What: A structured system to improve a work process by eliminating unnecessary tasks and streamlining the work flow.

Why: There is almost always a better, easier way to do something. Work flow analysis identifies and eliminates unnecessary process steps by analyzing functions, activities, and tasks. Uses cross-functional teams.

How:

Define process in terms of purpose, objectives, start and end points.

Identify functions and major responsibilities of the organization including manpower and planning.

Identify activities below functions.

Identify tasts or basic steps used to perform each activity and to provide the most specific description of a process.

Analyze the process with a cross-functional team.

Identify lengthy tasks, choke points, duplicate tasks, etc.

Determine and implement an action plan for improvement.

13. The Shewhart Cycle (Deming)

What: A cyclical process for planning and testing improvement activities prior to full-scale implementation.

Why: When an improvement idea is identified, it is often wise to test it on a small scale prior to full implementation to validate its benefit. Additionally, by introducing a change on a small scale, employees have time to accept it and are more likely to support it.

How:

Plan a change or test.

Carry out the change or test, preferably on a small scale.

Observe the effects of the change or test.

Act on what was learned.

Repeat step 1, with new knowledge.

Repeat step 2, and onward.