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.
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.
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 20thcentury, 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.
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.
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’re habitual beings. We tend to do things the way we’ve always done them. I want to write about specifications in that context today. A lot of the organizations we work with utilize a specification sheet or template in to which a fill-in-the-blanks exercise is executed to create a spec sheet and communicate design intent to engineering. The problem with boilerplate templated spec sheets is they don’t distinguish the value that differentiate one spec from another —e.g. which spec is important, less important, arbitrary, etc.
A way of dealing with that issue is to divide your specifications into three categories: Musts, Coulds, and Shoulds. The Musts are those requirements that without which you don’t have a product. Without them you don’t have a competitive position in the marketplace. The Shoulds are the things on which your competitive advantage is built; things you’re trying to accomplish in your value proposition. The Coulds are things that would enhance the value of your product, but may not be worth focusing on and investing efforts to achieve.
These three categories still could be communicated as point specifications, but we can increase the value and information being communicated by expressing them differently. One way would be expressing them as ranges. Instead of having a point spec you then have a range of values. Hitting any of the points within that range would provide value as perceived by the market place. Those ranges can be communicated to the engineer and used to guide whether they reached sufficiency in their design effort.
You can take these ranges and enhance them further and make them communicate better information by placing them beside a graph to show how the market value will change over the range. That way an engineer can see that they’ve achieved the target, but with a little more effort they can achieve more value. It’s meaningful information to them for their design.
The third way of communicating the Should to engineering would be as goals, as word/statement based ideas of what you’re trying to accomplish with a particular design. The communication of goals takes this point focus defined by specifications and opens it up broadly — bounded only by conceptual boundaries defined by the goals.
The communication of Shoulds as goals allows the focus to shift from achievement of various points to the generation of new knowledge and looking for alternative ways of solving a technical problem. It allows us to rethink the very nature of how we manage engineering and product development. It also frees us from the pain and misery of testing to spec – pass/fail testing – to testing for knowledge and learning. And this knowledge that we gain from testing a full range of technology allows us to capture and apply knowledge as innovation within product design.
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
If you’re familiar with the world of Lean, then you’ve probably heard the expression “it’s a journey.” This expression has become a little trivial or trite. It’s become a little hollowed out, sort of like the term empowerment or win-win. I have a colleague who hates the expression win-win. He hates it because it is always used as a mask when he finds himself in a win-lose situation. But Lean really is a journey and I want to articulate the elements of that journey for you today.
First, you need to define your starting point, like a journey. Then you define a destination or where you want to go. Finally you have a rate of progress towards your destination. So, if you’re traveling from New York to California, you have your starting point in NY and your destination in CA. You have your rate of progress that includes intermediate states. You might stop in PA and visit some friends. You might only have enough money to get to IN. If that’s the case then you’ll need to stop and make some money for a little while before you pack up and continue west as far as you can go. California represents the ideal state and you have some intermediary states along the way.
In the world of Lean you define the current state, you consider your ideal state, you understand your limits, you identify targeted improvement states — way stations along the way, you go there and reach a steady state, then you prepare the next move on your continuous journey when the time is right. And that’s how Lean is represented as a journey.
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 perform Product Development System Assessments (PDSA) for our customers. I’m frequently surprised by how many product development organizations still use email as their primary medium for the communication of information. Attached to these emails are test reports, marketing information, requirements, etc. Documentation that is critical to the performance of their product development!
I recently read a British study stating 38% of a knowledge worker’s time is spent looking for information. I can’t really believe that. We’ve run into organizations where it is that high, but not as a standard or average. But event if you discount that and cut it in half, that is about 20% of the time that knowledge workers spend just hunting for information. And this time spent hunting, this loss of efficiency, is invisible because it just gets buried with everything else inside the charges to project time within specific projects.
The other issue we have with email is that it’s open loop. It has no feedback. If the timing of the sending of some information is wrong, then the recipient will have to search through their inbox for the information after the fact and often times will ask for it to be resent rather than hunt for it. Also, you have various revisions distributed across the organization sitting on various hard drives – some of them current and some of them out of date.
When Bowen & Spears, famous researchers, talked about the need for a direct link between internal suppliers and internal customers, I think they talked about that connection as more personal, more collaborative, and closed loop. For your information flow, if you’re still using an open loop system, find a collaborative tool — PLM for instance. Help your researchers and knowledge workers take the pain out of their information flow.
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
