This book is about the underlying principles that enable systematic approaches to innovation. It will help readers become better innovators by learning and understanding the principles of the function analysis system technique (FAST). We want to encourage readers to experiment with function analysis in new and challenging situations. Therefore, the focus is on uncovering the underlying principles as well as the procedures. Each chapter covers one or more key principles and the logic behind them. To help the reader to apply these principles, a variety of practical examples and case studies are included that explain and demonstrate the steps involved. We begin by providing a brief outline and history of the topic. Many books have been written about innovation and techniques promising to improve the ability to innovate. What makes this book different, and how will you benefit? The book will guide you through many innovative, value-adding applications. In product analysis you will learn how to reduce development and product cost, when and how to extend product model offerings, and when to consolidate the number of models while protecting or improving the customer’s value perception. You will also gain knowledge of what features to incorporate into a standard product and which features should be offered as product options. The book will also help you focus on incorporating high-valued functions in new product development ventures; to gain the competitive edge that drives the need for new, advanced products. Applying the principles contained in this book to major projects and programs in fields such as oil and gas exploration and chemicals and their by-products will result in significant reductions in capital expenditures (capex) and operating expenses (opex) while improving process time, net present value, internal rate of return, throughput, and other projected outcomes. The processes described in the chapters that follow will help you plan projects, develop technical and business processes and procedures, and modify organizations for leaner, more effective performance. The technique discussed throughout the book will also help task teams innovate by changing the way we normally think about solving problems and capturing opportunities. That technique is a modeling process called the function analysis system technique, or as it is known and referred to by practitioners of the process, FAST. At the heart of the FAST modeling process rest two powerful questions that if asked strategically in researching for information will open the door to a wealth of knowledge waiting to be freed, hidden under levels of assumptions and misinformation. Those two questions are how? and why? The key to problem solving is knowing how to ask questions, what questions to ask, when, in what sequence, and how to interpret the answers. The FAST modeling process responds to each of these key questions. Another important part of the FAST process described in this book is to think and speak in terms of functions. Once this process is learned, thinking and speaking functionally will allow team members to communicate with anyone, regardless of their technical or professional background. Is thinking and speaking functionally difficult to learn? No; it is no more difficult then learning to solve crossword puzzles; and like crossword puzzles, proficiency improves with practice.
THE MEANING OF FUNCTION Function is a common word used in everyday language by many who do not appreciate the depth of its meaning. A passenger expressing concern about the erratic behavior of a bus is overheard to say: “I don’t think this bus is functioning properly.” A manager berating an employee for some infraction of the rules begins: “Exactly what is your function in this organization, Mr. Smith?” One friend questions another by asking, “When do you think this function will end? Are these examples of proper uses of the word function? If so, what is the function of a bus? Do you think Mr. Smith will be able to answer the question that he was asked? And can the friends explain functionally where they are or why they are there? Have you learned anything yet about the process? Probably not, so let’s start with a simple FAST model and see what we can make of it. Figure 1.1 is a FAST model describing how to make a cup of tea. Since an American created the model for a group of Englishmen as an example to demonstrate that anything can be modeled functionally, the model was inspected critically to ensure that the FAST model properly represented an Englishman’s version of the art of making a good cup of tea. To read and appreciate the FAST model shown, we took a page from the way that manufacturers instruct buyers on how to set up and use their equipment. In addition to the principles and applications of function analysis and FAST and the direct link to innovation that is the main theme of this book, presented below is a quick reference guide to reading a FAST model. First, note the arrows labeled how, why, and when in Figure 1.1 and the direction in which the arrows are pointing. The arrows tell you to what you are addressing your questions. Although we can start asking questions anyplace on the model, let’s begin on the left side and question how. We explain later why that direction was selected. Notice that there is one block on the right side of the left dashed line. That block is a function. In fact, almost all the blocks on this model are functions. Therefore, we are going to use the description of one function to question another. The function questioned has the answer to the question asked. Ready to start? How do you Produce Tea? Produce Tea is our outcome, our goal. If we were developing a process or procedure describing how to achieve our goal, we would answer the question by jumping to the beginning and start building the procedure saying something like, “First, we get a teapot and fill it with water. Then. . . .” However, Figure 1.1 is not a process or a procedure. It is a FAST model. The difference, as you will learn later in the book, is that a FAST model tells you what you must do; a process model tells you how to do it. The answers to the arrowed questions asked must answer that question specifically. Answering the question “How do you Produce Tea?” with “First we . . .” is not the specific answer to the question asked. Let’s explain briefly how to read a FAST. The process is not complex, it is simply new to you. Therefore, we will move slowly until you become more comfortable with the process. In the following chapters we unfold an explanation that allows you easily to master the challenge not only of learning how to read a FAST model but also how to analyze and create one.
Reading FAST Remember that in this introductory chapter we are merely trying to give you a flavor of FAST. This section is intended to set down some learning points that will help you realize that the FAST model helps multidisciplinary teams to share their common theory of how something works. In FAST modeling terms, the correct answer to questions such as “How do you Produce Tea?” can be found by looking at the functions to the right of the function questioned (i.e., to the right of the function Produce Tea). The how arrow will remind you of the left-to-right orientation. Note that we have two answers to the question, connected by a symbol, the or symbol, identified by two lines exiting the function asked. The two lines are optional paths and are read “How do you Produce Tea?” “By directly Releasing Flavor ‘or’ Modifying Flavor.” This is “function-speak” for “Do you want your tea straight, or flavored?” If you answered “flavored,” the when arrow guides you to the response. ‘When you Modify Flavor, you can do so by:
Reducing Acidity. How? By Adding Milk
Or, by Increasing Sweetness. How? By Adding Sugar
Or, by Increasing Tartness. How? By Adding Lemon
Or, by a combination of the three options
At this point one of our English friends said, “Ha, got you. One never combines milk and lemon in the same cup of tea.” Our response was: “Maybe neither you nor we would think of that combination, but somewhere, in some faraway land, maybe there is someone who likes his tea that way. Why deprive him of the option?” Can we question the FAST logic? Yes, that’s the purpose. To explore, question, create alternative functions and generate innovative ideas to achieve the project study’s objective. Notice that symbol labeled “Taste Tea”? That’s an event note which advises, “Taste the tea prior to modifying the flavor.” ’ Continuing, let’s ask how we Release Flavor. The answer is found to the right of the function questioned, Brew Tea. When we brew tea, we Fill Cup. But how do we Brew Tea? By Boiling Water ‘and’ Adding Tea Leaves. Note the and branch. Unlike the or branch, where you are given a choice of paths to follow, the and branch says that you must both Boil Water ‘and’ Add Tea Leaves. Why? (See the why arrow.) So that you can Brew Tea. Let’s continue along the main how–why path and come back to the when functions a bit later.
How do we Boil Water and Add Tea Leaves? By Preparing Process.
How do we Prepare Process?
By Transferring Water ‘and’ Acquiring Tea Leaves ‘and’ Transferring Heat. We can now ask the how question of Transfer Heat and Transfer Water, following their paths to the three functions past the right dashed line. The dashed lines in Figure 1.1, called scope lines, define the study boundaries. The functions to the right of the right scope line are input functions and identify the abstraction level where we wish to start the analysis. Functions to the left of the left scope line are the reason that you are, in this case, Producing Tea. Now that we know how to Produce Tea, let’s find out why. Starting with the input functions, ask: Why do we want to Access Water? To Fill Kettle.
Why? To Transfer Water (from the tap to the pot).
Why do we want to Access Energy? To Create Heat.
Why? To Transfer Heat.
Why do we want to Transfer Water ‘and’ Transfer Heat ‘and’ Acquire Tea Leaves? To Prepare Process. I’m sure you noticed that we passed two when functions: Control Flow and Control Heat. We are confident that at this point, you know how to read them. Later in the book we discuss the logic associated with the questions asked and answered.
FAST Logic
The answers to the function questions asked and answered must appeal to your sense of logic and your knowledge of making a cup of tea. When building a FAST model with a team representing different disciplines, that sense of logic must appeal to all the team members. The logic flow must also hold when following the how and why directions. If it doesn’t, there is something wrong with the FAST model. Reading the FAST model in both directions is a way to test the logic flow of the model. Good FAST model builders have learned to build the model in the how direction and validate the model in the why direction. That’s why we opted to start in the how direction. Shall we continue validating the FAST model? Why do we Prepare Process? So we can Boil Water ‘and’ Add Tea Leaves. When you Add Tea Leaves, you should Measure Quantity ‘and’ Select Emersion Time. How? By Determining Taste. Why? So you Attain Desired Flavor. You should now be able to read the FAST model with some level of understanding of the mechanics of how the three logic questions how, why, and when are used. Let’s then jump to the function identified as the goal or outcome. That function, Produce Tea, is called the basic function, and all functions to the right of the basic function are support functions, describing in function terms the method selected to implement the basic function. What do we mean by “method selected,” you ask? It means that the FAST model describes one way, among many, to Produce Tea. Therefore, all functions to the right of the basic function can be changed, eliminated, or combined to describe a better way of making a cup of tea, but the basic function, Produce Tea, cannot change. We prefer to pour hot water over a teabag in a cup but would never suggest that to an Englishman. Later in the book we show you how this insight can help you to plan whether you want radical innovation or tame innovation. Let’s now look at the functions to the left of the basic function and left scope line. We do this by continuing our why questions. Why do we want to Produce Tea? So that we can Serve Tea. Why do we want to Serve Tea? To achieve some higher purpose. That purpose could be a social gathering or some other event. If we treated the social gathering as the basic function, Produce Tea would be a supporting function to that event. This would allow the FAST model builder to consider a soft or “adult” drink in place of the tea. Much more will be said about functions and their important role in stimulating innovation as you read the book. Getting back to our English friends, after a detailed examination of the FAST model, one particular fellow threw back his shoulders, raised his head, looked down his nose, sniffed, and said, “The model is invalid.” “How so?” we asked. To which he replied, “You forgot to preheat the teapot.”
Some Observations
Teaching FAST modeling usually starts with a hardware or artifact example so that the student can visualize and relate the product’s components to their functions. However, using such examples tends to mentally lock in to the configuration, which, for the untrained, blocks innovative thinking. Our purpose in selecting a process example first to explain FAST is to try to stimulate your innovative talents while having fun doing it.
What Have We Learned?
FAST is an excellent way to create business and technical processes. FAST displays functionally what needs to be done and identifies dependent functions (how) and the reason for selecting those functions (why). Once the team, made up of those affected by the process, agrees to its function description, the process steps can be described sequentially and responsibilities assigned. Designing processes in this way reduces a significant amount of time iterating the published procedure to satisfy the concerns of those affected later. A project plan can be developed in the same way. The function model justifies the steps, responsibilities, and resources required. Once approved, the dimensioned FAST model can be employed to produce a cost-effective outcome-focused project plan. Examples of such FAST model applications are described and displayed in subsequent chapters. Another interesting observation relates to the visual effects of the FAST model. A common colloquial expression used by a person to verify that he or she was understood is to say, “Do you see what I’m saying?” Those unfamiliar with the expression may think, “How can one see speech?” FAST makes that colloquial expression literal and understandable. FAST is a far better process than trying to draw word images in the air, relying on the imagination of listeners to configure the same image picture as that of the speaker.
APPLYING FAST TO HARDWARE PRODUCTS
There is much, much more to learn about function analysis, FAST modeling, innovation, and how they fit together to form a powerful analysis process. However, before you start that journey through this book, let’s use the knowledge gained in modeling a cup of tea and apply it to a tangible example. Figure 1.2 is a FAST model of a commonly used product, a mousetrap. At first glance, the FAST model should look familiar to you. The process of FAST model building applies equally well to all situations, in every market segment, regardless of the size and theme of the project.
Reading a FAST Model
Let’s start with the basic function Kill Mouse and read the FAST model in the how direction.
How do we Kill Mouse? By Striking Mouse.
How do we Strike Mouse? By Releasing Striker. Testing the logic to this point, we read back in the why direction.
Why do we Release Striker? To Strike Mouse.
Why do we Strike Mouse? To Kill Mouse.
By this time you should be fairly proficient in reading FAST model examples. You will find some complex FAST model examples in the book, but don’t be intimidated by the size or area covered by a FAST model. All FAST models are read in the same way regardless of their complexity.
Analyzing a FAST Model
After constructing a FAST model, which you have yet to learn, step back and try to determine what the model is telling you. We have many years of experience in building FAST models with project teams and have produced over 850 to 950 FAST models. One thing we’ve noticed is that we have always learned something new about the project which stimulated innovation. This is directly attributable to the greater understanding that a team gains by making their thoughts explicit and structured. Let’s give you a glimpse into how this augmented understanding is achieved and prepare you for what is to follow in the rest of the book. Looking at the way the basic function is configured is a “messy” way to kill mice. We can’t change the basic function if the primary objective is to kill mice, but we can look at the supporting functions to “build a better mousetrap.” A predator such as a cat can do the job, as can mouse and rat poisons. There are many other creative ways to perform the basic function, but do we really want to Kill Mice? One would think that as long as they are out of your home, you wouldn’t care if they lived or died. What if we were to make the function Eliminate Mice basic? Doing so would move the FAST model to a higher level of abstraction and open many more avenues to explore for ridding ourselves of the mice problem. By making Eliminate Mice basic, the function Kill Mouse becomes a secondary function and can be altered or eliminated. After all, killing mice is but one of many ways of eliminating mice. Let’s consider a way to sterilize the mice so that they can’t reproduce, or create a hostile environment by producing an annoying high-pitched ultrasonic sound that disturbs the creatures but is undetectable by humans. One participant at a FAST learning workshop suggested catapulting the mice into an unfriendly neighbor’s yard. Another participant suggested a totally new approach. His idea was to capture and train the mice to eat roaches, thereby turning the liability of having mice into an asset. Another participant asked, “What is the value of the mousetrap?” The response came in the form of a question: “Who determines the trap’s value, the mouse?” This may be a humorous response, but it begs a bigger question: “Who is the customer who determines the value of products and services, and what functions does the customer consider valuable?” These issues, among others, are addressed in the book.
SOME UNIQUE WAYS THAT A FAST MODEL HAS BEEN USED
There are many diverse uses for mapping and modeling functions. FAST models have been used to describe the secular and nonsecular functions of a church, a surgical procedure for replacing a knee, oil and gas exploration, reorganizing a company, functionally justifying department budgets, refining vaccine production, plotting a career path, planning a wedding, developing new products, and many other interesting and innovative project support applications—all this in addition to effective unit product cost reduction of consumer products, reducing the capital and operating expenses of multimillion-dollar international oil and gas projects while improving net present value and internal rate of return, and saving time (time to market, time to reach “first oil”), which in many cases is more important then cost reduction. A few years ago, a survey of FAST model users was conducted to determine in what unique ways the FAST model was being employed. Following is a summary of responses collected in the survey.
1. Communicate across technologies. The FAST language uses active verbs and generic measurable nouns to build a FAST model. This allows communication across disciplines. FAST model building is especially effective when an interdisciplinary team is needed to solve multilevel problems.
2. Identify problem causes. Emerging symptoms are often an indication of a deeperrooted problem. All too often, problem solvers treat symptoms as the cause rather than investigating what caused the symptom to emerge. Replacing a blown fuse with one having a higher capacity is an example of symptom solving. Although the power is restored, the problem remains to emerge later, possibly with more serious consequences. The how–why logic clearly displays the dependent relationship that links functions. If the visible symptom can be identified as a function, the dependent function logic path will help trace and find the root cause of the problem.
3. Raise the level of abstraction. FAST models can be constructed on any level of abstraction. When a project calls for macroanalysis of issues and decisions, a FAST model can be built to match that abstraction level. If selected issues need more detailed microanalysis, the FAST model can isolate and address those issues of concern selectively and drill down to the information needed without disturbing the complete model.
4. Keep project issues in focus. The theme and construction of FAST models are based on the results of a pre-event or “framing” meeting with customer representatives. Once a FAST model is constructed and agreed to by the customer, the project boundaries are determined. Within those boundaries, functions that can be changed as well as those that cannot be changed are identified. Due to the dependent relationship of functions in a FAST model, proposed improvement changes to functions can be traced to determine the change effects on other functions.
5. Separate symptoms of problems. See response 2.
6. Force team consensus. The validity of a FAST model depends on achieving team consensus of all its members who built the model. This is important when an interdisciplinary team is needed and formed to address a project’s problems or opportunities. Requiring team consensus assures that each team member’s contributions are equal to the inputs of the other team members. It also ensures that the diverse concerns of individual team members are reflected in the completed FAST model.
7. Temper emotions with objectivity. Problems involving people rather than things (e.g., department reorganization) are particularly sensitive to emotional involvement and behavior of the team members involved. Managers often commission outside consultants to conduct such studies for the very reason of avoiding emotional reactions of those staff members affected. Although the consultant’s recommendations may be more objective than the recommendations of those involved directly, using outside sources sets up an adversarial relationship with the affected staff. The best approach is to involve those affected by the study outcome as project team members and get the members to buy in to their recommendations. Using FAST modeling and neutral function language to reorganize departments requires team members to address the graphical representation with their territorial and authority concerns rather than confronting other team members directly. If they wish to argue an issue, the argument will be with the logic of the FAST model, not with other team members. Examples of organization case studies and their related FAST models are described in this book.
8. Help prioritize activities. Activities are the way that functions are implemented. However, most company budgets are estimated on how busy (activities) an organizational unit is, projected over the budget period. Understanding which functions are being addressed by the budget submitted allows management to explore different, more cost-effective activities to perform the required functions. It also allows management to prioritize those functions in terms of their contributions to the business plan, which guided management in deciding which activities to fund and which to suspend or delay.
9. Enhance customer communications. FAST models have been created to aid sales. These models display those functions that drive customers’ perceived value. The model is then used as a visual aid in describing the product functionally to a customer and to the performance metrics of the valued functions. The FAST model is then used to compare the function performance of competitive products, which highlights the strengths (ours) and weaknesses (theirs) of the products being compared.
10. Functionally define processes. As described previously, the best way to determine how to do it (a process model) is first to determine what has to be done (a FAST model). There are other examples in the book proving the value of FAST in process design.
11. Determine where to set objectives. Constructing a high-abstraction-level FAST with senior management will clearly describe the direction of the company. Dimensioning the major functions by assigning them goals will help track performance against expectations. A more effective use of organizational FAST models is to move down to department-level FAST models. Understanding the higher-level goals will help department managers select complementary goals using the department’s functions to support higher-level goals. The FAST models can then be “drilled down” to lower levels—to those organizational units supporting the goals of their reporting level. The result is the harmonious performance of individual organization units, focused on the performance of meaningful, high-level business goals.
Some characteristics of organizational FAST models are as follows:
1. Resolve areas of responsibility. Drawing organization charts should be the last things to do in restructuring an organization. The start of the process to improve the effectiveness of an organization is to understand its mission, charter, objectives, and functions needed to address those issues. Once the FAST model is complete, the functions can be clustered to show subunits by drawing unit boundaries around selected functions. Identifying which disciplines should “own” the functions could then be matched to the functions.
2. Enhance organization effectiveness. The boundaries around organizational units and their position on the FAST model will show which units depend on the performance of other units to meet their performance objectives. As an example, manufacturing depends on procurement to receive the correct material needed to meet the production schedule. With the dependencies displayed, joint performance goals can be crafted to encourage a cooperative operating culture.
3. Identify input/output dependencies. Developing dependent performance goals also addresses the issue of the format and quality of input and output performance information usable to departments that depend on such information to meet their performance commitments.
4. Probe process vulnerabilities. A FAST model is useful in assessing predicted process failures. By simulating the failure of a process function, the dependent relationship of functions in a FAST model will trace which functions are affected by such failures. The information can then be translated to the equipment fulfilling the malfunction, and corrective actions can be planned.
5. Identify milestone events. A process model is more effective in determining where to locate milestone events on a FAST model because the dependent relationship of functions displayed will show which functions need to be completed before meeting the milestone requirements. If the activities are inconsistent or in conflict with the event, the activities can be modified. An example in the manufacturing process is the location of inspection points. FAST models have helped reduce the number of inspections, and by identifying which functions will be inspected, and for what, the effectiveness of inspections has be improved and throughput time reduced.
6. Define gate requirements. Process gates such as an incremental funding justification are best located on the FAST model describing that process. FAST will help define who the gatekeepers are, what is required to pass through a gate, and what is needed before entering a gate. The result is a shorter process time by eliminating many loop-backs resulting from rejected funding requests.
7. Select functions for brainstorming. Product and process FAST models can be dimensioned to show issues of concern and which functions affect those issues directly. Instead of improving activities, brainstorming ways to determine the best way to implement those functions keeps the search for better ideas channeled to the functions concerned. This results in more innovative, responsive proposals.
8. Outline policies and procedures. As described previously, the consensus of what has to be done in function form provides an excellent foundation for outlining and developing policies and procedures.
9. Help resolve technical direction. Evaluating emerging technology by understanding and searching for new or improved ways to perform functions is a better way to match those functions to advanced products or processes. As an example, looking for new and unique ways to produce torque will result in more responses for ways to design an advanced screwdriver or drill motor than will examining a variety of competitive products. The only thing now standing between you and learning how to achieve the results described above, and much more, is the unread chapters in this book. Your next step toward learning and applying the principles of function analysis and innovation, and benefitting greatly from this newfound knowledge, is to continue reading.
Click Here to Purchase this Book