The PLM-user Pitch

The PLM system pitch and the related discussions is almost always focused on the decision makers - how should you convince the management to buy, and how should you show that you provide value with your implementation?

The topic is most often focused on the disconnect between IT and Business and how to bridge the gap.

It’s of course an important topic but today we will look at it from another angle.

There is another void to fill and that is the one between the benefit of the enterprise and the actual user of the system.

Neither vendors nor the companies looking for PLM systems have (enough of) this in focus. There is a functional focus, I can agree on that, but that is not necessarily the same thing as a user oriented PLM focus. It’s more about having a checklist to see that an application can fulfill the functional requirements, which is not really the same as having the user in the center.

So what would happen if we would focus on the users? Because once bought, a system such as PLM is not only good for the business as a whole, it is also intended to help users in their everyday work.

Tools and processes for the greater good

An enterprise tool is often emphasized as the tool which should support the complete company’s need and not necessarily the individual. We focus on overall process/information improvement and harmonization and not the end-users tasks and daily work.

A company oriented pitch is also often more future oriented, than what you would like to phrase it to an end-user. The employees are more focused on the present and solving the challenges of today. That’s where our pitch should be focused – the present and what it means for the individual.

An individual productivity tool

If you take the scope of PDM, you should be able to pitch the actual idea to make it about enabling the individual; making it easier to find the right information, enabling earlier transparency as well as collaboration. For complex data sets and/or tasks it will help out in keeping data integrity, and dependencies thereby offloading the workers from otherwise tedious and error prone tasks.

But unfortunately there are challenges with this pitch:

• The end user and the way they want a system to behave and support them in their daily work is diversified. What makes a good fit for one will not necessarily fit others. Basically I don’t believe that there is a “Heinz ketchup of PLM”, fitting all tastes. I rather believe that the need is as diverse as the salsas that you can buy in your local supermarket.
• If we talk about PDM systems - functions associated with PDM comes with quite a heavy baggage in terms of old system behavior which has not always been perceived as enabling. A shift in technology and the ability to work more seamlessly will most likely help out in making PDM applications less of a struggle in the future.

A Tool for Knowledge

The productivity pitch will not get that much traction if your PLM system is used to “only” specify your products once you have developed them, instead of being develop within it. Unfortunately this (mis)usage is not as uncommon as you might think. In many cases putting things into the system is an administrative task at the end of what one consider value adding activities, and this really undermines the individual’s perception of having the system support her needs.

But, independent of scenario you would probably gain one thing and that is a knowledge bank. The system will create transparency which would benefit the individual, as searchable and structured information will allow for higher productivity second time around.

This transparency will also benefit the people further down the chain. The earlier you manage to accomplish it the more power you will get of it, and it’s also an opportunity for business intelligence to analyze trends earlier which again could be used as a pitch for certain end users or consumers of information.

Democratization

By sharing knowledge we will enable decentralizing and distribution of tasks. Technology will enable this. Because by systemizing knowledge we can put it in the hands of “anyone”.

Think about simulation which previously was something that only highly specialized people worked with. Today software is taken the first hit through checking the output of the individuals work before integrating it with the rest of whatever solution one is working on. All domains have it; software, hardware, mechanical design, electronics, etc. And some will take the step to create mockups which brings multiple disciplines together.

There will always be a place for specialized skills but the frontier is and will continue to move as we manage to systemize knowledge. And this should appeal to the expert as it will allow her to focus on things which are less bread and butter, at the same time as it gives the non-expert more confidence in the output she produces.

A trendy phenomena is Internet of Things; think what we can do with data collected from products in the field and once we systemize that knowledge. How will that translate into the way we design our products or conduct or service and maintenance business? Once that data is cracked it can be used as BI put into the hands of the individual.

Could this bottom-up approach result in benefits on company level (for “the greater good”)?

Could we flip this around to make it about the company, and what is best for it? Of course we could. Thinking about and addressing the needs of the individual will at the end find its way to the bottom line, resulting in better overall quality, better flows, higher productivity, higher data quality, etc.

Conclusion

IT and PLM should not be seen as a support function next to the core business – your PLM processes is actually part of your business. In many companies today it is therefore within your PLM systems that you conduct your business. If we embrace that fact, the focus can’t always be on the benefits on company level, the day-to-day work has to find its way to the PLM pitch.

Robert Wallerblad

www.infuseit.com

A Picture is worth a Thousand Words

My professional path has allowed me to work with many industries and type of customers - looking at just my recent year and it has taken me into classic manufacturing, automotive, defense as well as apparel. Something that has been a signature of my work across all these customers is the fact that I’ve been very visual in the way that I’ve been communicating. I’ve been using mockups to illustrate my ideas from pre-study, architectural reviews, scoping workshops, concept discussions, down to developer input and user stories. What I can say is this – independent of industry or audience, these artifacts are always appreciated and well received.

Engineers, spare part catalogue editors, configuration managers,   pattern makers, buyers, controllers, designers, .... I can continue this list ... managers, project sponsors, project owners, project managers, business developers, SW architects, SW tester, and SW developers, .... what do they have in common? Well, they want (and need) to be able to understand at least to some extent the IT solution that will affect them or that they will be responsible for.

Here is a small prezi on the topic that might give you some more food for thought. Enjoy (and don't miss the movie clip at the end)!

As you might understand by now I’m quite clear on my view on this topic. Don't get me wrong, I'm not saying that you should stop writing all nice diagrams, charts, boxes, and lanes that you do today (as long as they have a good purpose ;). But the audience for those artifacts is limited to experts, and unlike what you might think even techies at the IT-side find visual illustrations of a topic useful.

If you haven't used mockups before there is one trap that you will fall into: your audience will look at the mockup as something finished and fully covering – end users expect the solution to look and behave as the mockup and developers will try to realize every little inch of the picture without questioning. To mitigate this behavior, it is very important to apply some expectation management. The purpose of the mockup, its usage and “how to read it” should be clear to the audience (and preferably repeated as often as the mockups are shown ;).

It feels great to be understood and even better for the audience at the receiving end to actually understand. So try it out!

One last thing regarding mockups - They don't replace human interaction and verbal communication. It's a complement to that and all your current tools to make yourself understood.

Robert Wallerblad

www.infuseit.com

This %&$#?@! PLM Application!

Have you ever encountered bad user experience in a PLM tool? I have a few times. So how do we address user experience in enterprise software such as PLM Systems?

UI is only one part of UX

When thinking about user experience (UX) of an application you might associate it with words like nice and modern looking graphical user interface (GUI). But it is so much more – in its core it’s about understanding the end-users need and to make the work-tasks as simple, effective, and intuitive as possible. Level 1 is to address things such as consequent usage of interaction patterns, wording, icons and other features that you might associate with the GUI. But that doesn’t necessarily mean that you will develop the right features. You might still miss the actual goal of your implementation.

Understanding the user and the context

So, back to what I considered core – it´s all about understanding the context and the usage. Is the target an expert user? Then it might be important to have an effective pixel-usage, and advanced features, which might have some threshold to learn, but which is motivated by the value it provides. Or, is it aimed for the broader audience, where it has to be intuitive, self-explaining and with zero thresholds? To understand this you need to more or less work in the same way as any business analyst, grasping the essence and details of the tasks that you are about to develop a support for. To know the business impact goal of the implementation is an important part of this, as it sets the framework for whatever feature or function you are about to develop.  You can probably implement “a thing” in hundred different ways but only a few of them will match the desired outcome (e.g. better overview, higher efficiency, transparency, or traceability).

Another important thing, which is put to its extreme when working with customers in the fashion industry (as I do now), is the amount of data that the user is exposed to, and the speed in which the user has to perform his/her tasks. This means that every click counts – if you do thousands of product developments per season you will have some demand on the tools which is supporting your processes. Things which normally might be considered annoying become critical issues. And bad performance becomes show stoppers as the users find other ways to conduct their daily work. If you think about it, it’s not any different to any other industry. It’s just that the situation is more extreme which makes UX a good focal point for efforts made to make life easier to the end-user.

Don't lay the load on the user

A typical trap is to make things over-complicated. This is often found in PLM tools. Tools providing out-of-the-box capabilities often take the path to provide a function which is as generic as possible, allowing as flexible usage as possible. This flexibility is also manifested in the fact that every screen comes fully loaded with features. Something that you most probably can either configure, or use preferences to adjust. The issue is that none of that is actually done to enhance the experience. Actually, you will most likely find this in a lot of highly customized or bespoke software as well, and for the same reason – it is hard to take decisions which limits your options even if it for a good cause; to keep it simple. In many cases you need to take a stand and choose a path for the usage of the software to make it work in a streamlined and effective way - by not taking the decision yourself, you force it upon the end user.

To quote Steve Jobs;

“Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.”

There is money to make from good design

The value of good design is not only about pleasing the end-user. Areas which contribute to a faster ROI are:

• Less need for support
• Less error prone
• Less need for user training
• More through-put
• More time spent on value adding tasks

But I have also heard some “softer” reasons for pushing for good design and that is to be able to appeal new, young, co-workers; you need to provide tools which don’t make the hair on their back stand up. That fight is not easy won as applications from the “consumer world” have transformed what we expect from an application in terms of usability. And mobile and cloud has done the same with availability, as we demand access from anywhere at any time.

What can we ask from the future?

I will not take the consumer and mobile path on this one, and I won’t take you to “star trek” millennia either…

Steve Krug’s book “Don’t make me think” is often mentioned when usability is discussed. Isn’t it time for someone to write the book “Don’t make me enter more information, please I beg you!”? I hope and believe that a lot of today’s tedious clicking and entering will be replaced by capabilities which will allow the user to shift focus from administrative to more value adding tasks. Aren’t we soon in the age of more intelligent PLM applications, which could enable more automated metadata creation? I'm not talking about mind-reading applications. It's more about utilizing the context in which the data resides, releasing data by moving out of the boundaries of native file formats, and borrow some from predictive coding. In short - don't make a human do the work that a machine can do.

Robert  Wallerblad
www.infuseit.com

*The title was inspired by the book "Jävla skitsystem" by Jonas Söderström

LCI – Document package or continuous process?

LCI or LifeCycle Information is a hot topic in the Norwegian Oil & Gas industry. For my international readers who do not know this term, it has to do with managing huge amounts of documentation from plant engineering through product engineering and fabrication. Then cross checking it all through multiple iterations. The documentation is then supplied to the Operator at several milestones in the project from early design through commissioning.

A more international term would be preparation of Documentation For Installation (DFI) and Documentation For Operation (DFO).

Rigorous demands on LCI from the operators
Operators put rigorous demands on what information they want in a project, and at which points in time they need it due to their need to monitor progress in the projects, and to be compliant with safety and regulatory standards. The Engineering procurement & construction contractor is responsible for collecting, checking and supplying the documentation from its own disciplines as well as all suppliers in the required way.

LCI Coordinators
Traditionally it has been the domain of a whole host of LCI Coordinators to make sure that all documentation is present and if not, make sure it is created…. However the “best” LCI coordinators manage to produce the information without “bothering” engineering too much. It has largely been a document centric process separated from the plant/product engineering process.

Varying LCI requirements from operators
One of the real headaches for the EPC’s are the varying requirements from different operators in different countries or especially when the end customer is a yard. I’ve witnessed rigorous and detailed LCI deliveries in a project for an operator, and a completely different set of deliveries for a yard. This challenge has led to more EPC’s defining their own LCI strategy and processes as their own best practice, while treating requirements from operators in different parts of the world as “add-ons” to their already existing LCI process.

Going from document-centric to data oriented approach
In recent years, I’ve started to see a shift from the separated document centric approach to a more data oriented approach where data is harvested from different data structures, or linked data in context if you will. This process is no longer separate from the plant design and project execution process, but rather an integrated part of it. This shift is very similar to how the aerospace industry is executing their projects. One such example is Airbus DMU (Digital Mock Up). With this approach it is easier to share and collaborate on data. Dependencies and consequences of changes are more easily understood and experiences can be harvested from one project to the next by copying data structures from one project to the other. Some EPC’s are also creating best practice template structures or libraries. I've seen this approach used successfully to facilitate re-use and to minimize engineering time during FEED phase (Front End Engineering & Design) and also during contract execution.

If you want more information regarding the differences between a document centric and data oriented approach I would recommend Jos Voskuils blog series on the subject.

CONCLUSION
The Oil & Gas industry is under pressure to save money and be more efficient. LCI is one of the domains where there is a lot to be learned from other industries. Building the LCI processes into your engineering and project execution processes will greatly reduce the LCI effort. Of course this demands that you have some way to collect, control and consolidate engineering and design data from various sources.

Bjørn Fidjeland
www.infuseit.com

PLM vs ERP – the everlasting trench war or the best PLM ROI?

PLM vs ERP discussions have a tendency to end in trench war between the ERP people and the PLM people. If not open hostility, there is little understanding of your opponent. It does not have to be like this. PLM and ERP can live together and make the total outcome better if PLM and ERP has found their roles and co-operate.

 In this blog I am talking about PLM and ERP tools. Not the PLM concept covering many applications and the whole lifecycle.

This is one of the everlasting PLM topics. There are a lot of blogs about this topic. And more will come as this topic will exist as long as PLM and ERP tools exist. Here are some of them: Beyond PLM, The Virtual Dutchman, Engineering (Engineering) and Engineering.com.

Why is PLM vs ERP a challenge?

Traditionally PDM and MRP had clear roles. PDM takes care of the parts and BOM from engineering and MRP takes care of purchasing and production planning. This picture is not that clear anymore. PLM and ERP have overlapping functionality and processes. Both try to handle “all product information”. PLM stretches into the ERP domain with for example sourcing functionality and ERP stretches into the PLM domain with for example CAD integrations.

Another reason is that PLM and ERP are typically owned by different organizations. ERP is owned by the finance-people and PLM is owned by the technology-people. There is difference in culture, focus, language and they often have a hard time understanding each other.

One oversimplified difference is that with ERP you optimize what you have (existing and physical products), with PLM you optimize what you do not have (new products, intellectual property).

How to approach this

The challenge is identifying a clear and not overlapping role for the PLM system and ERP system in your company. The first step is getting the PLM and ERP people into the same room and get them to understand each other. And to see this from a bigger picture. What is best for our company? Can we achieve something better by co-operating and perhaps “giving away” something to the other side?

There are clear benefits if you can get PLM and ERP to work together. Less time entering information again, better quality of data, faster change processes etc. Get out of the trenches and look at the information flow, processes and business needs. Do this without prejudice about where and how to solve it. When you understand what your business needs you can look at a logical flow. Which tools have the best functionality and which roles are supposed to do the work? Don´t make people have to work in both systems and switch back and forth.

Use a top- down approach: What is best for the company; not “how can I build as much functionality into my tool as possible”.

Several of the companies where we have run PLM-ERP workshops with this approach have responded: This is the first time both camps say they understand each other and are agreeing that together they can really improve things.

A typical scenario

There is no single correct answer on what the PLM-ERP set-up should be. The most common solution though is this:

• The parts and EBOM are born and approved in PLM
• The EBOM is transferred to ERP when it is approved
• The EBOM is re-transferred when it is changed and approved again
• MBOM is created in ERP based on the EBOM
• The change process includes manufacturing planning (at least manually)

The next level could be feedback from ERP. E.g. Cost, stock, change implemented, preferred suppliers etc.

Some companies create and give names to parts in the ERP system and others create the MBOM in the PLM system. However, most companies with a working PLM-ERP integration follows the set-up above.

The challenge is anyway the business process, information flow and business rules. Not on the technology side.

Typical PLM-ERP integration tasks

When you start looking on a PLM-ERP integration there are some task you have to do. Here is a typical list:

1. Objective & Ambition – What do you want to achieve? What is the business pain?
2. Processes – Which processes will be covered/changed?
3. Information Flow – What information will be handled and how should it flow?
4. Business Rules – What are the rules ensuring data and process consistency?
5. Data Model – How is the data related to each other? Are the data the same in PLM and ERP?
6. Transfer Mechanisms – What is triggering the transfer? What is transferred?
7. Data mapping – How do PLM and ERP data map?
8. Data ownership – Which tool owns which data at which step in the process?
9. Integration Technology – What integration technology should you use?
10. Technical Implementation – Programming/configuring the solution

The first 8 are business topics, only the last 2 are technology topics. The challenge is on the first 8. If you do those correctly you will find the 2 last ones to be manageable.

Conclusion

PLM - ERP integration is one of the really big benefits you can get from a PLM investment. It will ensure good quality of data and you will reduce the manual effort in data entering.

There is no single right answer to how this integration should be. There are overlapping processes and functionality. Get out of the trenches and find out what is best for your company.

Tore Brathaug
www.infuseit.com

How do we get PLM right?

How do we get PLM right and who is the PLM expert? Who knows best how it fits the users and the company? Can we get it right without involving the end users?

I’m not claiming to be a user experience (UX) expert of any kind but I have reflected and learnt some during the years, and one thing is that the best way of really getting it right is by testing it on end-users. And I intentionally expressed this in plural – you need a group of people to validate the chosen solution. It is arrogant to think that you will get it right just because it states expert (or PLM advisor as in my case) on your business card.

But a UX expert wouldn’t ask an end-user; so what is it that you want? To put it into a classic T-Ford example: If you would have asked what the people would have wanted they would have said "faster horses", instead their need was faster transportation. So it's not solutions that one should ask for and seek, it is the underlying problem that you want to solve.

After having talked to the users about their challenges, wishes and dreams, she would bring a suggestion to the table to try it out, preferably before and during implementation. That’s where the UX expert has its domain; understanding the end-user, suggesting solutions and validating them (which is a craft of its own to master). 

So how is it with PLM? Should we consider that the same applies to this domain? That the crowd knows better than the expert? And the expert’s job is to suggest solutions and then validate them?

Who knows the customer best?

Well, I would say it would be strange if it wouldn’t be the customer itself. The customer though, might need some assistance in understanding, expressing, describing and documenting their needs, problems and challenges.

Who knows the domain best?

The customer knows how they are doing things but that is not necessarily the same thing as stating that it is the best way (even for that customer). External “experts” will bring ideas to the table, as they have experience from many different companies, thereby allowing them to have another view on the topic.

Who knows what to aim for, and what the vision should be?

Is it the ones working in the process day-to-day? Well, you need to have some perspective to your own work. And be exposed to input from others to be the one with a goal that has a trajectory which aims high enough.  Don’t get me wrong! You will get good initiatives going by listening to the end-users. But, you might find them to be “micro-ambitious” – targeting to solve the challenges and evolve the work of few, but not taking the enterprise view of the PLM agenda. Also, it is most likely that you will get feedback targeting to solve the problems of today which leads to a more reactive behavior than a proactive approach targeting to get your enterprise to the next "level".

Who knows the tools?

There is actually at least one more “expert” to this equation, at least once you actually talk about IT solutions and not just strategies and processes – The above questions don’t take into account that there are constraint in the IT tools, which are limiting your options. This is where the application expert finds his place. The platform/application will create constraints which the expert, whether it is UX or PLM, has to consider at least to some extent when it comes to deciding on solutions.

The other side of the coin can be processes or solutions in the application that you did not think about, but can give short term improvements with little effort.

Have we found all the “experts” now?

We have a good mix, but there is one more which could spice up things and could be used as a catalyst; the generalist. In some situation you will benefit from not being an expert in the field - an outside perspective will allow you to see new connections and reframing your situation with expertise and experience from other industries and business domains.

An interesting take on this is whether you are looking for someone who should help you solve a problem or find a problem. To truly take your PLM vision and strategy to another level it’s not enough to solve a known problem; you need to find problems that you didn’t know you have. Who is most suited to guide you in that quest?

But what happend to the crowd/the end-user?  

They are there. Because whether you are implementing processes or tools to support them the end-user will still be the judge if it fits with her needs or works in the reality of conducting her work. 

Conclusion

Implementing PLM (and knowing how and what to do) is not a one-man job. You need to ensure that your team is multi disciplinary; with both broad and deep knowledge in the domain, business, and technology. I would also emphasize that you need real end-user involvement to make sure that you, at the end, get their acceptance.

I leave you with a quote that stuck in my mind after a conversation with a colleague:

"A 'newbie' will look for evidence to guide her in the path to the most appropriate actions to a greater extent than an expert would. Therefore she will win in the long run."

What if you would have a team of experienced people which uses the tools and mindset of the newbie?

Robert Wallerblad

www.infuseit.com

Variant management in engineer-to-order?

Many products come in a lot of different variants, for equally many different reasons. Growth in variance can be a big challenge, in the virtual world, as well as the physical world. Taking a structured approach to variant management can help you get back in control – if you do it right.


First of all: variant management is not equal to product configuration (even if it is a closely related topic which may very well be part of a variant management solution). Also, the solution for variant management might look very different depending on type of product and type of industry: Is it a highly industrialized product, like a car, where all variants are made from a finite set of standardized modules? Or, is it a complex, low volume product, where new variants are created “on-the-fly”, based on customer requirements?

Many industrial companies are in the latter category, supplying highly advanced products to demanding customers in industries like oil & gas, aerospace & defense and health care. Common to all of these are that they typically come from a very project oriented mode of working, which is reflected in the way they are organized and how information is managed. They do talk about products, they do have product catalogues, but every delivery of a product is organized as a project, which typically includes a substantial engineering effort. The product information tends to be treated as project specific, even if the major part stays unchanged between each delivery project. Reuse between projects is frequently done by copying rather than referencing, resulting in massive duplication of documentation as well as part numbers.

The economy of scale

Variant management in high volume manufacturing is driven by a desire to cover a wide variety of customer preferences with a limited number of products. This has resulted in products that are configurable by the end customer, as part of the ordering process. The emergence of product platforms has brought this concept further, allowing a large number of models to be derived from a common technical platform. One of the latest developments in automotive is "scalable platforms", from which car models of almost any size can be derived, with VW and Volvo as early movers with their MQB and SPA platforms respectively. It is no secret that these initiatives are huge investments, but both manufacturers expect to gain a significant competitive advantage through the economy of scale for shared components and modules, as well as shortened development cycles for future models.

For low volume products, where the typical mode of operation is engineer-to-order (ETO), variant management is not needed as an enabler to provide a larger number of variants, as each delivered product is anyway tailored to satisfy the requirements of each individual customer. Rather, variant management should be seen an approach to rationalize the way products are delivered, while maintaining the competitive advantage of being flexible towards the customer. The economy of scale is still a valid motivation for improved variant management, as far too many activities end up as a redundant effort, repeated in every single delivery project.

Where to start and what to do?

Although the streamlined configure-to-order (CTO) process of the automotive industry might be out of reach when you are dealing with low volume products, there are still many concepts which can be applied, if you are in the ETO-business.

First of all, you need to step back and take a look at your business model and strategy: are you aiming at speeding up your current delivery process, or are you looking for new ways to design and deliver your products? There might very well be a potential in automating repetitive tasks in the engineering process, employing for instance parameterized CAD-models to speed up drawing generation and CNC-preparation. In many cases, however, there is a much greater potential to be gained from avoiding repetitive tasks, rather than automating them. This is where modularization and product platform thinking can be of help. If most variants of a product can be made from a limited number of standardized modules, there are huge benefits to be harvested all along the product lifecycle, far beyond the engineering department. A few examples:

• It is easier to predict the cost of the complete product, when the cost of each individual module is known from experience.
• Component and material cost will be reduced when enabling the procurement to order larger volumes, gaining lower prices from suppliers. Better predictability for expensive, long lead items is another advantage.
• Quality cost is reduced, as each module has a standardized set of design documents, which can be improved over time.
• Production processes can be industrialized and optimized to a much larger extent, as the number of identical items increase.

Some companies might object that customer requirements will still force them to deliver unique products (and documentation) every time. This may be true today, but will it still be true if the customer was confronted with the choice of a standard product and a custom product at twice the price? Certain types of products are custom by nature, because of the surrounding environment. It would still make sense to standardize what can be standardized to reduce the engineering effort in the delivery process, saving time and money.

Success criteria

To succeed with variant management in a project oriented environment, it is critical that the organization is set up to properly manage the standardized building blocks, and that the information management systems in use support the new way of working. Most PDM and PLM systems have specific functionality for variant management, as well as the required support for engineering change management across projects. The single most important criterion, still, is to establish a dedicated organization for product management with sufficient funding to develop and maintain the standard product definition, to ensure that it is complete and up to date. Otherwise, there is a high probability that the project engineers will continue managing variants as they have always done: using "Save As".

Johannes Storvik
www.infuseit.com