PDOS

They say a picture is worth a thousand words, so here’s a hypothetical situation to paint the story ‘how real-time information and predictive analytics unlock value.’

To start, imagine a fully functioning assembly line with a robot, a pneumatic system, a series of conveyors, and a vision system.

Let’s pretend the supply station in the back is bringing in our raw materials. The robot is assembling those materials with precision. The resulting assemblies are then passed on to the quality station, and the vision system inspects each of those assemblies to ensure proper alignment of the parts.

This is a pretty generic operation, but it can show how unified real-time information and predictive analytics unlock value.

Now imagine yourself as a maintenance engineer, who wants to check the status of your asset pool.

Using software, such as ThingWorx Navigate by PTC for example, you launch a role-based maintenance application. All of a sudden you see a complete list of your assets with real-time performance stats and relevant alerts or notifications. You also have a complete list of all your outstanding maintenance work orders.

From here, you have the ability to drill into any of your assets, but you start with the quality station. You immediately see the key characteristics of the station. You see that speed vibration and temperature are all operating within their specified range. You could also see notifications of any warnings, malfunctions, or potential future problems.

Next, you use your device to take a look at the pneumatic system. The pneumatic system also looks fine. Both pressure and flow are operating within the specified range, and there are no outstanding maintenance tickets or work order notifications on your screen.

Now, let’s consider a situation where there was a leak in the pneumatic system. Let’s say a loose fitting was releasing pressure, a fairly common problem in pneumatic systems. Now, rather than looking fine, your device displays flow readings outside of the designated operating range. Furthermore, an alert has automatically been sent to notify you that a system has an error. The overall status indicator on your screen has now switched from green to orange – operational, but not optimal.

Your software solution’s machine learning is now predicting that this air leak, if not repaired, will result in a pneumatic gate failure in approximately 10 day’s time. The good news for you is the system has already issued you a maintenance work order to address the problem before asset failure and unplanned downtime.

This scenario is made possible by a system equipped with primary and secondary sensors, and a complete Industrial Internet of Things (IIoT) solution that can turn raw machine data into valuable information.

For example, your pneumatic system has an airflow sensor, as well as a pressure sensor. The conveyor systems are equipped with motor temperature sensors and vibration sensors.

In addition to the sensors, the rest of the assets on your line are controlled by typical PLCs, which are connected to software such as ThingWorx and Kepware.

You have also used your software to integrate manufacturing floor systems with real-time IT applications, asset maintenance tools, and ERP systems. This provides you with a real-time alignment of your IT and OT systems.

Now, all of your systems are throwing data out at a staggering 800 data points per second.

Your software’s machine learning then uses that real-time streaming data to establish a baseline of normal operating conditions. This way it can immediately connect and broadcast any anomalies that occur. It uses these anomalies, in conjunction with its prediction capabilities to notify you of future problems, just as in the case of the pneumatic failure.

Now that you have an understanding of what is happening under the hood, let’s take a look at how all this comes together to enable real-time operational intelligence.

Pretend you are a production manager. Using software like ThingWorx Navigate and Kepware you have complete visibility into all of your factory operations. You can see all of your work orders, lines, and all of their critical KPI’s.

On your device, you notice an orange status indicator on line one (that was created from the air leak earlier). Once that air leak has been repaired, everything returns back to normal, just as you would expect.

Let’s explore one more hypothetical situation. Consider yourself to be an operator. In this case, you have just been assigned a new order for a thousand units that need to be delivered and expedited for an end-of-day delivery.

You’re notified of the order and in this smart connected scenario you, as an operator have a single portal from which you can see and execute all of your work. Through a single pane of glass, you now have access to your business systems information and your operational data including the KPIs from your line.

On your device, you also have up-to-the-minute visibility of the OEE (Overall Equipment Effectiveness). You see real-time data measurements of your manufacturing operation’s availability, quality, and performance.

Let’s see how some of these metrics might change if we go ahead and speed up the line to accelerate the current order, in order to make room for that expedited order.

To do that you switch the line speed from level one to level two. What you see in seconds on your device is that line speed has increased, and your assemblies are still passing the quality check.

Within a couple of minutes and a few additional cycles, on your device, you see both your performance and OEE trending upwards.

As an operator, you now are assured that you are going to meet your end-of-the-day deadline.

Using these hypothetical situations, together we have painted a picture demonstrating how you can connect disparate assets from different vendors, to provide real-time information.

You’ve also seen how you can leverage role-based applications that combine business systems information and operational data to empower your workforce with real-time actionable intelligence.

By integrating machine-learning capabilities you brought a whole new level of predictive intelligence to your factory floor, identified problems, and resolved issues with minimal impact on operational performance.

This is exactly how real-time information and predictive analytics can unlock value for your organization.

The EAC Product Development Operating System is a framework that is based on three attributes of the product development system: that it is a competitive system; that its operation requires team-based participation from a broad range of contributors across the organization; and that it changes, evolves or decays, over time.

Many product developers have limited direct contact with their customers or their marketplace and lose sight of the competitive nature of their work. The rows of the PDOS matrix represent the three elements of a competitive system in the context of Product Development. Companies that look to capture the benefit of a competitive advantage from their product development competency cannot do so, without also addressing the needs and requirements of competitive systems.

The concept of teamwork in Product Development is well recognized and valued as a key to effective and efficient operation. Many will immediately think of the cross functional team that executes a project in adherence to an organization’s product development process. But as our model takes a systems view of which the process is a constituent element, our conception of the system team is higher level with the project team just one element of it. Product development system excellence is dependent upon individuals and teams in each hierarchical tier of the organization. These are responsible for supplying input to other subsystem elements of the model essential to these other subsystems’ effective operation. Our model represents this system team element as the columns of the PDOS matrix. These pillars of the system are labeled both with their functional role within the PDOS and with the tier of the organization responsible for that role.

The third attribute of our operating system is that it is dynamic. Without the investment of maintenance or improvement energy, entropy will degrade its structure and operation. On the other hand, a commitment to ongoing improvement will facilitate maturing of the system and carry it through the four levels of our maturity model. Our maturity model includes a system improvement tool that not only accelerates the rate of maturing but also damps the organizational turbulence often characteristic of transitions to a new level of maturity.

The subsystem elements of our model exist in the cells of our matrix. The relative strengths of these elements vary during progress to full maturity; at full maturity the seven elements interact in harmonic balance.

Three elements of a competitive system:

Our most visible competitive systems are sports franchises, and the keys to their success are instructive for business operation:

Successful teams start with getting on the same page, literally. The team’s knowledge is captured in carefully guarded Playbooks and Game Plans. Everyone understanding the common goal and their role in it is a key to success. Successful, systematic businesses operate with shared goals that are captured in long term strategies, shorter term initiatives, and near term tactical plans.
Teams invest time and energy in becoming more capable of competing well. The clearest example of this is practice, time spent working on improving the individual and collective skills that are brought to the competition. But the improvement to competence also includes improved infrastructure, equipment, anything that better positions the team to compete. Do businesses generally make this investment in planful improvement to their product development competency with the mind’s eye on the competitive nature of product development?
And finally there is the competition itself. For teams the competition is head to head, and the metric is clear and clearly displayed on a scoreboard. In product development, the competing occurs in the execution of a program or project. The ultimate metric for product development is its productivity, total value created against the total investment made in creating this value. Execution of a project is the game, execution of the portfolio’s roadmap is the season. The ultimate competitive nature of product development is frequently lost in the common check-box nature of administrative project management.

The rows of the PDOS matrix:

In the EAC Product Development Operating System model, the rows represent the three elements of a competitive system. The Information row establishes the knowledge that must be shared – strategy, initiatives, tactics, process workflows – among all product development team members to create common goals and unify efforts. The Preparation row focuses on the improvement efforts that raise the level of corporate competence. And the Project row is where it all comes together, where we execute the game plan and compete.

Pillars of the System:

The columns of our system represent the pillars of the PDOS. Each pillar has two identifiers; the Product Development sub-team associated with that pillar and the focus of the contributing work done by that sub-team within that pillar.

Knowledge Base:

Knowledge is the Value currency of Product Development, and the PD Knowledge Base supports and glues together the other PD operational subsystems. The PD Information System, beyond housing data and information that serve as the building blocks of PD knowledge, also holds standards, transactional processes’ workflow, and functional tacit knowledge shared between project teammates. PLM has emerged as the critical PDIS tool.

Strategic Planning:

The work that culminates with a successful new product being delivered to market initiates with the development of a Strategic Plan. The compass heading provided by the plan informs decision making throughout the organization, including within the other PDOS subsystems. Critical decisions regarding the investments in the development of core and other competencies, as well as of new products align to the strategy.

Innovation (New Knowledge):

The Innovation subsystem elevates the competitive capability of the organization, its competences. It creates new knowledge in the form of disruptive technologies and novel methods of applying current technologies. It focuses on challenging all existing organizational standards, looking to continuously improve how it operates, and to compete in the marketplace from a position of greater strength and competitive advantage.

Expert Workforce Development:

In any competitive venue, it is understood that success ultimately relies on having great players. The competitive performance of your players is developed outside of the bounds of the competition itself. The intention of, commitment to and execution of investing in all of your product-development-critical subject matter experts – your assets –not only directly results in a more competitive team, but facilitates the recruitment of additional skilled players.

Investment Strategy:

The actual marketplace competition fulfilled by product development begins with strategic decisions about how to execute the product roadmap and elaborate the product portfolio. The informed decisions that lead to the significant investments incurred by product development create both the range and limits on profitability and corporate growth over the mid-range future. This late maturing subsystem determines the level at which you’ll compete.

Knowledge Based Decision Making:

The Knowledge Based Decision Making subsystem is the Product Development sibling to the executive function’s Fact Based Decision Making. While KBDM permeates successful Product Development organizations, in the actual competitive venue of development projects, the critical decisions that are captured as the product Concept are informed by pre-existing and newly generated knowledge of the marketplace and of corporate capabilities.

Project Execution:

The Project Execution subsystem is the part of the Product Development System that in the most narrow of views is seen as Product Development. The realization of the expanded view of the Product Development System does not diminish the critical importance of execution. Supported by new execution paradigms and product development specific information technology tools, longed for improvements in project predictability and reliability are now being achieved.

Tiers of the Organization:

Each of the three tiers in the organizational hierarchy – the executive, the managerial, and the individual functional specialist tiers – makes critical contributions to the effective functioning of a fully developed product development system.

Functional Roles within the PDOS:

The Product Development System Team comprises members in the executive, managerial, and individual subject matter layers of the organization. Each tier of the organization contributes to the effectivity of the system:

Executives set strategic direction, including the investment strategy for product development.

Directors and managers are guardians of critical product development knowledge and responsible for seeing that the right knowledge is available to the right individuals at the right time.

The functional specialists, subject matter experts generate new knowledge and use this and pre-existing knowledge in the execution of product development projects.

Maturity Model:

The EAC Maturity Model is a four level model that distinguishes the degree of structure and organization in the product development system at different periods in the evolution of the competency. The four maturity levels are:

Tribal & Heroic
Silo’ed
Systematic
Intelligent (self-managing)

System Improvement Tool:

EAC recognizes the value to both the rate of maturing and the ultimate level of maturity that is provided by a well ingrained root-cause problem solving system. The best of these are based on the PDCA cycle, also known as the Deming Cycle. Developed at Bell Labs in the early 20^thcentury, and introduced to Japan in the wake of World War II, PDCA played a significant role in the rapid recovery and rise of Japanese industry. A particular version of PDCA was developed by Allen Ward, modeled on the way PDCA is executed at Toyota, and tailored by Ward to suit the way Americans prefer to work.

Today we continue our discussion about System Archetypes with an archetype known as “Accidental Adversaries.” This system starts with two partners working to cooperate, but it leads to a negative outcome. The cooperation comes from each partner filling a need of the other. But, once the cooperation or system is put in place, each of them looks to individually optimize their part of the operation — a local optimization. This local optimization has unintended negative consequences for the partner. As each partner feels the negative consequence of what the other is doing, feelings erode, the partnership dissolves, and both sides feel the other side is inconsiderate and taking advantage of them.

The classic example used to highlight Accidental Adversaries is that of Walmart and Proctor & Gamble. Walmart needed product for their shelves and P&G needed distribution for their products. So the two companies cooperated. Once the cooperation was in place P&G tried to improve their position by running a lot of specials and sales. This created extra work and costs for Walmart. Walmart tried to recover those costs by buying extra quantities of the discounted product, stockpiling, and then burning through their inventory after the prices went up — selling them at full price to make extra profit and recover the burden put on them by the sales themselves. Proctor & Gamble then started running more sales to move more product and make up for the loss, and this turned into a cycle. Both sides felt the other side was operating against their interest and this cooperative venture became an adversarial relationship.

We see something similar happening in our organizations. Let’s use the relationship between marketing and engineering as an example. Marketing needs some organization to realize their vision and design. Engineering needs someone to come up with a vision and awareness of what the market needs in order to execute and do their work. As marketing learns, deep into a development project, some new information, they will try feeding it into a project. This is often called scope creep. Engineering will try their best to fulfill the new requirement. However, it may cause a problem for engineering. It may cause a project to be late. So, engineering puts in place some rigid rule like a spec freeze. Marketing, losing the flexibility of the process, will amp up its early requirements and put in stretch goals instead real goals. The idea being that if engineering can meet the stretch goals, then the product will still be strongly competitive in the market place. This cycle repeats itself and marketing and engineering find them selves in an adversarial relationship.

The antidote for this archetype is dialogue — continuing dialogue about the cooperation throughout the entire life of the system. Dialogue can’t end once the initial system in place. There needs to be ongoing dialogue between marketing and engineering. This is part of the design of the interface between the two groups. To come full circle, design of the interface is one of the key elements of systems and systems thinking…the topic that we’re heavily focused on in this series.

Contact us to learn more about how Systems Thinking and the application of our Product Development Operating System can help your organization become more efficient, productive, innovative, and competitive. Follow Bill at http://www.twitter.com/systhinking

We’ve been talking about System Archetypes. These are the types of systems that recur in a number of environments and are easily recognizable. The system archetype we’re going to talk about today is called Eroding Goals. Eroding goals are caused by a delay in the results of the actions we take to improve something. If you recall, systems operate on feedback — positive and negative feedback — and delays in the cause and effect cycles between elements of the system.

So in eroding goals you start with some condition and an ambition to improve it. There is some gap between your condition and the goal. This gap causes a dynamic tension. Senge represents it well in his book, The Fifth Discipline, by showing a hand stretching a rubber band. The tension of that rubber band pulls up on the condition, but with the same force it puts pressure to pull down the goal. You have two possible results. You can either take action that will move the condition towards the goal or you can soften the goal and pull it down closer to your condition.

What happens in eroding goals is you start by taking positive action, doing the right thing, but there is a time delay between the activity you take and seeing the positive results of the action you take. This time delay, this lack of positive reinforcement of your action, causes a loss of commitment to the work you’re doing. To relieve the pressure you lower your goals to reduce the dynamic tension that’s in play.

An example of this might be if your company releases three new products each year and there’s a goal to increase this number to six. This goal drives increased investment as the company moves towards increasing the capacity and capability to release six new products. But there is a delay in the positive results from the actions taken to increase capacity. This lack of results causes those making the investment to lose confidence and commitment to the initiative. So, to avoid making increased investments — in their minds eye perhaps throwing good money after bad — they lower their goals from six to four; an incremental increase instead of a dramatic increase.

The antidote to eroding goals is simply setting good goals. The setting of good goals comes from a process called learning first. Study your situation; study the distance between your condition and your goal. Then make goals that are achievable. This ties directly to learning first, learning cycles, and the EAC promoted LAMDA learning tool. If you’re not familiar with the LAMDA learning tool, I suggest you look into it. One way of doing so is to contact EAC.

We’ve been talking about system archetypes and will focus on that topic again in this post. We’re going to look at the system archetype called “Shifting the Burden.” First, a little review. A system archetype is a system that recurs over and over in many different settings and industries.

Shifting the Burden centers around shifting the burden from solving a problem to solving a symptom. It starts with the awareness of a problem. The awareness comes from the observation of some symptom of that problem. At the point of observation you have a choice. You can either choose to put out the fire and resolve the symptom, or you can do a more protracted problem solving exercise and get to the root-cause and solve the problem. Under the time constraints of modern business we oftentimes choose the former and put out the fire. We measure success using the fact that the symptom goes away and we can get back to our urgent regular work.

Shifting the burden from solving a problem to solving a symptom results in an addiction cycle. We treat the symptom and, because we haven’t solved the problem, the problem recurs as a fire. As we rely more on solving symptoms instead of problems, more and more fires recur and we find ourselves in perpetual firefighting. As we are perpetually firefighting we have less time to spend on solving problems so we’re more inclined to solve symptoms. As we do this, our ability to actually root-cause problems and solve them at their root atrophies. It is a side affect of the addiction cycle.

For example, say you have a customer service group. Let’s say that over the course of the last three months the number of calls into the call center has increased by 25% and the customer service groups is suffering low morale because of it–long hours and hostile customers. The problem at this point really is unknown. No one has investigated it. It could be as simple as an unclear instruction manual for a new product that’s been released. But, in the interest in getting the call center morale problem resolved the company invests in capacity for the call center. With more people in the call center morale improves and the symptom goes away, but the underlying problem remains…probably to recur at some point in the near future.

The “Shifting the Burden” archetype has an antidote. The antidote is to recognize when you’re applying Band-Aids–to recognize when you’re just solving the symptom–and to follow up that with a deep root-cause problem solving exercise. Of course, to be able to do this, you need a competency and capability of solving root-cause problems. This could be PDCA or, as EAC promotes, the LAMDA learning cycle.

Today we are going to start talking about system archetypes and we’re going to deal with the easiest to understand — Escalation.

In escalation there are two players. Player one does something that is seen as a threat by player two and player two responds in kind by making a power move. Player one then perceives that power move as a threat, so they respond again in kind and do something that is perceived as a threat by player two. So it goes in a continuing pattern of “seen as threat…response > seen as threat…response” and the situation grows out of control. The situation escalates. It’s done through a series of power moves.

In an escalation system, both parties are operating from their mental models: a sense of righteousness. They believe they can’t give in. An example of escalation was seen in the 1980’s during the arms buildup between the United States and the Soviet Union. The Soviet Union would increase their nuclear arsenal and the U.S. would respond in kind and increase theirs. The U.S.’s increase was then seen as a threat to the Soviet Union who would then spend more money and increase theirs. Likewise we would respond in kind. On and on it went consuming critical national resources. Both countries locked into this system, unable to back down. Both were prisoners of the system. Eventually it led to bankruptcy of the Soviet Union and hyperinflation in the United States.

This kind of escalating system exists inside of our organizations. It exists between functional groups when one functional group takes an important position, but that position is seen as a threat to another group in the organization and they start escalating back and forth.

A trigger for an escalation can be simple. An example could be if your marketing group says they’ve learned something new about the market and need to introduce a new spec in the middle of a product development process. The engineering group might say, “We can’t! That change in spec will drive us back to square one. We can’t accommodate it and still be on time to market.” With these two righteous positions the interface between the two groups becomes a battle line. They go back and forth escalating, threatening and counter threatening each other.

If you find yourself in a system of escalation, how do you get out of it? If you’ve recognized the system, that’s terrific, but how do you find your way out of it. In the archetype of escalation the way out is through dialogue. Between countries, on the international scale, the term dialogue is referred to as diplomacy. Inside of your organization dialogue is referred to as inquiry – learning and asking questions to understand the underpinnings of your partner’s position. Peter Senge calls this advocacy (within your position) with inquiry (looking to understand the position of your partner). If you’re wondering how to avoid escalating situations by asking meaningful questions to get to the heart of a matter, I recommend you read a terrific book by Michael J. Marquardt called Leading with Questions. If you learn to lead with questions you will always be able to find yourself out of organizational situations that are escalating out of control.