Terrapene: Process Management Suite

Home > Software > Why Not Other Software?

Terrapene: Process Management Suite®

ATTENTION: Organizations contemplating a software solution to support your process-based management system

A growing number of software programs are claiming to be able to support process-based management. Most of the programs feature flow charting, and many are modified versions of flow charting programs designed for other purposes. Buyer Beware!

Conducting research over the past five years, Plexus Corporation has found that for most organizations, flow charting does not represent a good solution for mapping, structuring and managing a process-based management system. While most organizations cited the utility of flow charting for individual processes, they cited several reasons why they did not recommend flow charting software to support a process-based management system.

The category most often cited was its Lack of Ease in Use and Understanding. It was almost universal that organizations felt that while flow charts are understood fairly well by selected individuals, as a whole flow charting, especially to the detail level needed to be useful for the organization, was not widely understood. Adding to a lack of understanding is the significant learning curve required to properly create and later to use and understand the flowcharts produced by different process owners within the organization. It appears that most flow charting programs assume that one person, or a small group of people will flow chart all of an organization’s processes. This, of course, stifles the sense of process ownership that is important to process-based systems, and it reduces the accuracy of the process’s reflection of what truly occurs.

Another category often cited was its Inability to ‘Layer’ and to Indicate Non-linear Relationships. Most organizations who tried (and failed) to organize their process-based management systems via flow charting quickly found that it was difficult to show smaller processes insider bigger processes. In effect, flow charting was not designed to show ‘layers’ of integrated processes forming larger and larger processes, but instead was designed to show one, linear process. When layering and multiple relationships are needed to give an accurate and useful picture of a process, flow charting often confused its users more than it clarified.

A third category cited over and over again was its Inconsistency and Discontinuity. Depending upon the source that is used, there are multiple meanings for symbols in flow charting. Some are adamant that diamonds are the symbol for decisions; others are just as adamant that isosceles triangles are the symbol for decisions. It became evident to many that flow charts often evolved into a language of their own making, which was fine for individuals involved in the creation process, but made it difficult to quickly acclimate to the system. Auditors, new employees, etc., had a difficult time deciphering the flow charts, particularly if different parts of the organization used symbols in different ways.

Plexus listened to the voices of the customers. When Plexus recognized the need to develop a software program to assist organizations implement, communicate, manage and audit their process-based management systems, Plexus realized that flow charting was probably not the best solution. They turned instead to modeling. Specifically, Plexus adopted a model that was specifically designed for a process-based system – the ‘Turtle’ diagram.

It is the modeling capability provided by the Turtle diagram that forms the foundation of Terrapene Process Management Suite™. It is the Turtle and its unique features that Plexus has incorporated in the Terrapene software making Terrapene superior to flow charting software for usage in a process-based management system.

Users of Terrapene comment upon its Ease of Use and Understanding, stating that is provides them the means to indicate Layering and Non-linear Relationships in their management systems and Consistency and Continuity because their structure does not change; the Turtle remains the same; it is the information and the various relationships that change.

The following page provides a more detailed comparison including some of Terrapene’s main features and functions.

We invite you to compare the capability of the process management methodology you may be considering, or you are currently using, to support your management system with Terrapene Process Management Suite™.

Does your current approach provide the capability you need to maximize the benefits you expect from a process-based management system?

We invite you to take the challenge below to see how your current management system methodology compares to Terrapene Process Management Suite™.

For additional information, review what Cadillac Products Automotive Company has to say about their experience with Terrapene™ (see the article from Cadillac Products following this page).

CAPABILITY	Terrapene Process Management Suite™	Electronic Flow Charting Systems	Hard Copy Documents ‘Paper Turtles’	Your System for Process- based Management
Analyze the What, Who, How and Performance of each process	YES	YES	YES
Display the important elements of each process	YES	NO	Limited
Identify the process owners of each process	YES	YES	YES
Identify the key measures of each process	YES	Limited	YES
Monitor the key measures of each process	YES	NO	NO
Display the sequence and interactions of core, support and management processes in plain view	YES	NO	Limited
Supports multi-level layers of processes	YES	NO	NO
Access documentation through the screen view of a process	YES	Limited	NO
Display and attach messages and notes to individual and multiple processes	YES	NO	NO
Create and display alerts for immediate or scheduled activities	YES	NO	NO
Complete and display findings where they occur within the management system	YES	NO	NO
Provide immediate access to ISO, TS and AS management system standards / requirements	YES	NO	NO
View and compare process staffing, performance, and actions with comparable processes in the system	YES	NO	NO
Monitor processes within several management systems	YES	NO	NO
Create and communicate ‘packages’ of a process and/or the entire system (Supports Stage 1 management system audits so that analysis can be accomplished online)	YES	Limited	Limited

Surviving and Winning in the Automotive Supply Chain:

The Need to Leverage Quality Management Requirements for Your Organization’s Maximum Benefit

Written by: Dennis Gentry, ASQ-CQA
Corporate Quality Director and Vice President
Cadillac Products Automotive Company in Troy, MI

Introduction

Quality Management guru, Phillip Crosby’s famous utterance, “Quality is Free” may have gotten a lot of recognition when it first invaded quality management’s consciousness, and it may have sold a lot of books; but it didn’t, and still doesn’t, reflect the reality of the quality in the automotive industry. Quality for most supplier organizations is a cost.

For automotive suppliers that cost is substantial. There are the costs of having the supplier organization regularly reviewed and certified; and the costs of supporting that effort. There are the hidden costs of fixing problems both real and imagined, and to that end, fixing problems that the supplier organization had no hand in making. There are the costs associated with hiring consultants to develop solutions to problems that are perceived to exist. There are the costs associated with adding and/or redirecting personnel to handle the work related to ‘solutions.’ The investment can be quite daunting.

But most automotive suppliers with varying degrees of civility grin and bear it. After all, or so they rationalize, the quality management certification is a ticket they must have punched or they don’t ride on the automotive industry bus. Suppliers shoulder the cost because the real ROI is continued and expanded business with the automotive OEMs and other automotive suppliers. A ROI that looks good on paper but does not come to fruition for a number of suppliers; and even for the ones it does, the return is often lower than expected.

What can be done? What can the typical automotive supplier do to change the dynamics of a system that seems to be steering supplier toward smaller profit margins and greater expectations?

Experience

I think it is important for you to know that what I am about to say comes from many years of experience in the automotive supply chain. I have been with a medium-sized automotive supplier for over 34 years. During those years I have held many positions for the organization. I am currently Vice-President of Corporate Quality. During my tenure I have seen many management systems come and go. I have seen many quality initiatives come and go. Some were better than others, but in all cases my company and I were able to capture the good from the change and manage the impact of the not so good.

I think also it is important for you to realize that generally I am not an excitable person. I am pretty sure most of my friends and fellow workers would tell you that I am for the most part a calm and even-tempered fellow. They would also probably tell you, if you asked, that though calm, I am passionate about what I believe in. I love what I do.

Why do I tell you this? I tell you because I want you to understand significance of my excitement. What excitement? I am excited about the potential for positive results from the management system now being required by the automotive OEMs; a management system that is to be based on the requirements of Technical Specification 16949:2002.

I am convinced that TS 16949:2002 properly implemented, supported with the right tools, and properly executed can improve the efficiency and effectiveness of the organization, can improve the work life of the individuals who comprise the organization, and can improve the organization’s profitability. Based on the experience my organization and I have gained over the past several years focused on QS-9000, and over the past eighteen months focused on TS 16949:2002, I feel confident to share with you the following conclusions and advice.

Prior to Implementation

There are a couple of primary points you need to understand prior to starting your TS Implementation: 1) If you are QS-9000 certified, you already have 99.9% of the required documentation for TS 16949, and 2) You need to seriously reflect upon the implications and impacts of a process-based management system.

You don’t need to rewrite all your documentation, and in most cases, you will not have to add documentation to implement TS 16949. If you are QS certified company, chances are you have all the required documentation. That’s good news to most organizations; and there is even better news. Chances are that over time you will actually significantly reduce your need for documentation. We have seen that come about in two ways. One, as you seriously embrace the focus on processes rather than jobs, projects and departments, you will begin to see that your system has a great deal of redundant, duplicative documentation. You will gradually bring your documentation into line. Two, as you make your management system more visible, you will find a reduced need for narrative descriptions, which make up a whole lot of documentation. It is true – a picture is worth a thousand words.

If you have been told that you need only to map your current compliance to QS-9000 and to then cross-reference its application to your TS 16949-based system to achieve compliance to TS 16949:2002, you’ve been told wrong! Not only is that action not compliant because doing so ignores the requirement to map your organization’s processes’ sequences and interactions, it is an utter waste of time. Worse, it will stymie any notion you have for improving your system! The true result of following a so-called matrix path is one of confusion and decline. I know from experience – one of the sites I oversee (I am responsible for 5 manufacturing sites) went down the matrix path. The result – they confused themselves, they weren’t ready for a compliance audit, and they experienced none of the improvements possible as the result of a true process-based management system implementation.

But that begs the question – what is a true process-based management system?

Process-based Management

We found that a process-based management system is in essence an organized series of structures that individually and collectively can lead to predictable outcomes. What that means is this. First, and especially critical, the organization must realize up front that the ‘process approach’ means that the organization will need to change its thinking about how it perceives an organization gets work done and how the results of that work are measured.

At present most organizations have tons of processes, but they don’t really acknowledge them, so they most often don’t control or support them. Organizations manage people and stuff, not processes. The only area where processes are managed at all is on the manufacturing floor. There, most manufacturing organizations do a pretty good job. It’s typically the processes that interface with manufacturing processes (that the organization doesn’t see as processes), which cause the problems.

Process-based management (the ‘process approach’ of TS 16949) requires that an organization accept a model for managing itself that forces the members of the organization to see their organization as a series of processes, which interlink and interact, to form a complete system. A way to think about it is – processes aren’t the result of people doing work, processes are the work that people do. A key effect on the organization once they make this shift in thinking is that processes become the focus of management.

The focus on processes compels the organization take actions that are consistent with managing processes. Like any style of management, process-based management requires the organization to adopt standard practices that are appropriate for process-based management. Though it was difficult at times to make the transition to process-based management, we were pleased with the results. We found that process-based management strengthened many of the practices of management we were already carrying out, and most important, provided positive results that we did not anticipate. Some of the key process-based practices we adopted (in some cases we were already using the practice in our current management system), and the result of each is presented in the diagram that follows.

Process Identification and Visibility

Step one is to pull together the individuals who currently manage and lead the organization. Whether these people are department heads, supervisors or VPs is not altogether relevant; but what is most relevant is that the ‘core’ processes of the organization are identified and that process ownership to the core process can be assigned.

What is predictable about the identification of core processes (those processes which could be called the ‘macro’ processes of the organization) is that generally in the initial identification stage, there will be many more identified than will eventually be adopted. Why? Because each individual’s process is seen as important to him or her, it is predictable that each individual could promote his or her process. That’s not a bad thing because the processes identified will be used in some manner and by struggling to see where a process fits into the overall system, allows the group to grow in its understanding of the organization’s processes.

Eventually, however, it is necessary to synthesize the list of processes to see which among them are the real macro processes and which among them are actually processes that make up the ‘insides’ of the macro processes, or are processes that help manage macro and the micro processes. It is a balancing act. Too many processes and the organization is managing more interfaces than it can handle, thus raising risks to the customer. Too few processes and the robustness resulting from the checks and balances of multiple processes and multiple process owners do not exist.

Once the scope of the macro processes and a skeleton of them is completed, you are ready for an important next step – gather the individuals who work within the process to help identify the next level of processes = those micro (smaller) processes which make up the bigger, macro processes.

To support this effort my organization and I decided to use the ‘turtle’ methodology to facilitate and record the identification work. The turtle is a simple cause and effect diagram which is comprised of boxes for the inputs and outputs and then breaks the process into four parts/boxes – what, who, how, and measure. Additionally, to support our efforts we purchased software called Terrapene Process Management Suite. It looked promising because it used the ‘turtle’ as its basic methodology. Both the turtle and Terrapene program were easy to understand and easy to apply.

But what came, as a surprise to everyone is how the visualization of processes impacted the individuals working on the identification. It was as if they were seeing the processes for the first time, even though they may have worked in that job for 20 years. When completed, turtles were shared via projections on a conference wall or via the Terrapene shared software. From these actions Individuals who worked in the process(es) could quickly determine discrepancies in actual practices. And what became apparent almost immediately is that the visibility allowed process owners and process workers to question and/or point out redundant and non-value added processes.

Process Ownership and Accountability

Once processes have been identified and made visible the next step is to assign ownership. Who will be accountable for making sure a process produces what it is supposed to produce at the rate that is acceptable to meet the needs of the other processes in the system and the customer of the system?

Obviously, process owners play an integral role in a process-based system. It stands to reason that a process owner paying close attention to the performance of a process will ensure that other processes and process owners in the system will get what they need, when they need it. If that doesn’t happen, and if outputs from one process to the input of another aren’t right, or don’t show up on time, then that fact should be detected by the system very quickly. Quick detection allows the problem to keep from compounding. And the detection itself allows for a permanent fix to be put in place before the problem causes multiple spills or contributes to multiple and larger spills.

It bears repeating – process-based management forces the system to evaluate the process, not the person. The person, the process owner, is held accountable for the performance of the process.

Inputs and Outputs, Measurement, and Performance Metrics

Generally speaking, manufacturing organizations have a pretty good handle on measuring things on the manufacturing floor. Because of that measurement maturity, they can reap some of the benefits of the predictability and diagnosis measurement supports. When you think about it, the loudest voice of a process is it performance metrics. What is coming in and what is going out and at what rate?

But talk processes with the folks in Accounting, Purchasing, R&D, and Design and you get a lot of polite nods or a bunch of blank stares.

Why talk processes with the individuals in these areas? The answer is because a process-based system works best, when all members of an organization consistently and uniformly use it. Besides the obvious benefit of having everyone in the organization speak the same language, there are at least two other significant benefits. One, processes outside the manufacturing area can tap into the same strengths of a process-based approach that have assisted manufacturers worldwide move from making simple items that broke the same day they were purchased to complex items that can operate for 30 years with little or no problems. Two, for a system to work effectively and efficiently all facets of the system must interface with one another, or be capable of doing so, as required by the product or service, which must be produced. Whether the interfaces are between two processes, or several processes all at once, the inputs and outputs must satisfy the requirements of the next input or output in a series of possible inputs and outputs. In the past we most often allowed the ‘voice’ (and the owner) of an individual process to say, “We measured our output by our standards and it met our spec; therefore it’s ready for you.” In a true process-based system that is no longer the case. In a process-based system an output that is some other process’s input must satisfy that processes expectations. Once the organization begins to realize the benefits of this type of alignment, and not only encourages alignment of measures from input to output and output to input, but demands alignment, the processes and the system begin to improve.

In our development of processes and process measurements we discovered that there are at least three types of measures, which must be accounted for on the output side of each process (by default these also apply to the input side). The three are: 1) measures either required or necessitated by the Customer, 2) measures required due to a standard, law or regulation, 3) measures required by the system itself. In aggregate the measures provide a solid indication of the process’s performance.

Linkages and Collaboration, Commonality and Best Practices, Scorecards and Management by Facts

Though it took a little arm twisting, our corporation decided that our best plan of attack in moving forward with TS 16949:2002 certification would be to embrace the new requirements fully in order that we could benefit from the value the requirements may bring. It was the right choice.

Besides reducing unneeded redundancies, increasing accountability, increasing transparency and moving toward a system that measures itself by its performance, our decision added benefits that we could not have predicted.

Because processes show themselves to be interconnected, it is necessary to bring people together. What is different is that they are brought together not for the purpose of getting along, or swapping stories; they are brought together to talk about shared processes. They, individuals, are not the focus; their processes are.

Collaboration wasn’t something that needed to be encouraged, it simply happened because it was necessary; it could not be avoided. Inputs and outputs don’t magically come together; they happen because two or more processes, and the people who work in them, collaborate.

Once you get over the hump of collaboration and cooperation, gradually the system begins to foster a sense of commonality or shared understanding. What we found is that a by-product of that commonality, especially when the commonality extended beyond one plant to another, was the sharing of best practices. We found that reasonable people (our workers are quite reasonable and intelligent) seeing that their process (now visible for all to see on Terrapene) was similar to their compatriots at another plant, began to compare components of the process. When they were alike it provided a kind of reinforcement, which was good in many respects; and when they were different it caused the process players, particularly the owner to ask, “Why are they different?” “Should they be different?” “What is better and why?”

Our collaboration over processes has resulted in identifying several best practices within the corporation. This is good for the corporation, the individual plants and the individuals who contributed.

This kind of comparative review spilled over into the boardroom. If individual processes could be compared how about macro processes and entire systems? Because we had carefully identified our processes using a common methodology (turtle modeling) utilizing a common platform (Terrapene Process Management Suite) ‘macro’ process owners and executive management could literally compare processes from site to site or within a site. It was a consensus from all who participated that the depth and richness of the discussions that were generated by the availability and ease of the comparative analysis, made the decision-making easier and more precise.

From those first tentative sessions has now evolved into a standard practice by our corporation’s executive management. Our CEO has seen fit to eliminate the monthly PowerPoint presentations of performance for a more concrete, ‘real time’ assessment of the health of the corporation by asking that plant managers present their review of plant performance via the platform upon which they manage – Process-based Management as supported by Terrapene. Because our Terrapene system has all pertinent system hyperlinked to it, any question that is posed by the CEO or any of the executive team, can be immediately be investigated, sorted out and resolved. Or, in the case of a particularly complex or complicated problem, an action plan can be put in motion based on real facts, not speculation.

We are now in the process of merging all our measurement systems so that we can better access real time data. We have used scorecards for a number of years, but now the scorecards are moving closer to providing warning lights. Our hope is that the post mortems we typically do after the fact with a scorecard can be avoided because we headed off the problem before it became a failure.

Cost

For those who are wondering, though it would be impossible to make a direct comparison, our implementation was less costly and took less time than what I had anticipated. Let me explain. When I first approached the implementation of TS 16949 like many of my colleagues in quality management, I started down the path of creating a cross over matrix from QS to TS and mapping and flow-charting our company’s processes. I thought that would be the easiest and fastest way to approach the task.

I found out early on that my first conclusions were probably wrong. The cross over work proved confusing and began to eat up a lot of time. The flow-charting and mapping programs designed for linear, one level processes proved to be unusable. They are great for single, linear processes, but they are inadequate for analyzing, monitoring and managing layers of processes. It was for this reason we used the program Terrapene. Process owners, and others who contributed to the implementation process, were able to quickly place the models of their processes on line. Having done so, it was easy for others in the processes, and across the corporation, to contribute.

My conclusion is – the way we went about implementation was less costly than others I have witnessed and researched (driven by escalating costs, and lots of other important things to do, a TS implementation must be done at as low a cost as possible); AND we got a great system as a result of our efforts.

Conclusion

Besides the obvious improvement outlined thus far, to wrap up let’s address two more issues.

In our recent TS 16949:2002 certification audits we began to see the kind of value we, as an automotive supplier, need and want from an audit. Our Certification Body auditor was able to thoroughly evaluate our system prior to coming on site by using the Package feature of Terrapene. That is, we sent him a copy of our system (the parts required to be evaluated prior to the audit) on a working copy of Terrapene so that he could review our system’s compliance and so that he could become familiar with our process-based management system. Because of the quality of his preparatory work, as supported by the completeness of the ‘Package,’ he was able to come on site with what he needed to audit. He was able to detect due to the thoroughness, completeness and visual acuity of the Terrapene ‘Package’ of our system sent to him where he should concentrate his efforts in the audit. In these areas the auditor and his team did deep dives to see if what they thought was a problem, was indeed a problem. And when a problem was detected, it could be linked to a customer-specific, or TS or our quality system’s noncompliance.

The transparency of our management system allowed our auditor to ask questions that led to better self reflection on our part. He could ask: “Why do this process this way here and another way over there? Did you intend that?” We couldn’t see it! He saw it. Those kinds of observations proved invaluable.

Additionally, the transparency of our system appears to have led to a much richer and more detailed rendering of the strengths and weaknesses in final audit report.

What about the bottom line? It’s too early to tell, but indications are that our approach is positively impacting our bottom line. We have already found and corrected a major gap between corporate headquarters and our plants. We didn’t detect it until it became obvious through our use of Terrapene and process-based management.

With our visible, process-based system, we are able to acclimate and train new people to our system much faster and more effectively. This includes when we transfer individuals from site to site. This is especially true for individuals we bring on board to fill management positions.

I am not ready to agree with Crosby’s pronouncement about quality. It is not free. But with proper attention to detail, a proper understanding of process-based management, with the assistance of a solid tool like Terrapene, and with an executive team that is willing to do the right thing, a company’s return on a TS implementation can be well worth it.