You are currently browsing the tag archive for the ‘Top Down’ tag.

Last time in the series Learning from the past to understand the future, we zoomed in on how the 3D CAD-structure in the mid-market had to evolve. In a typical Engineering To Order (ETO) scenario, it makes sense to extract from the 3D CAD-structure a BOM-structure to collect all the individual parts that are needed for manufacturing. Combined with the drawings generated based on the 3D CAD assemblies/parts, the complete manufacturing information could be provided. Let’s have a look.

The BOM in ERP (part 1)

To understand what most mid-market companies have been doing, I created the image below. When you click on it, you will have an enlarged version.

Note: for educational purposes an extremely simplified example

There is a lot to explain here.

First, on the right we see the 3D CAD assembly, two phantom assemblies, grouping the wheels and the axle. And at the end, the individual parts, i.e. chassis, axle, and wheel. The 3D CAD-structure is an instance-based structure; therefore, there are no quantities in the structure (all quantity 1)

For the individual parts, there are drawings. Also, for the product, we have an assembly drawing. The drawings are essential as we want to have them in the ERP-system for manufacturing.

Finally, the physical parts, now with a different ID than the drawing as we learned this one-to-one relation created a lot of extra work. The physical parts are often called Items or Materials (SAP naming). Unfortunately, for engineering, there is a different meaning behind Materials. Still, SAP’s data model was not built with an engineering mindset.

The physical part structure, which we call the BOM contains quantities. Most PDM-CAD-integrations can filter out phantom assemblies and summarize the parts on the same level

I am still reluctant to call the Part-structure an EBOM as the design of the product has been mainly focusing on extracting manufacturing information, parts, and drawings.

The BOM in ERP (part 2)

In customized PDM-implementations, some implementers created an interface from the BOM-structure to ERP, so the ERP-system would have the basic definition of the parts and a copy of the relevant drawings.

Now manufacturing could create the manufacturing definition without the need to go into the PDM-system.

Some “clever” – Dick Bourke would say “smart – therefore lazy” – proposed to “draw” also manufacturing entities in the 3D CAD-structure, so the PDM-CAD-interface would automatically deliver manufacturing parts too inside the ERP. In the example below, we added paint for the body and grease needed for the axels.

Although “smart, a new problem was introduced here – the 3D CAD-structure, instance-based, always has quantities 1. The extracted BOM would have rounded numbers when considering design parts. Now the grease comes with an estimate of  0.025 kg, assuming quantities are based on SI-units. We could also add other manufacturing information to this BOM, like 0.3-liter paint. Anyway, the result would look like below:

Important to notice from the diagram here: There are placeholders for grease and paint “drawn” in the 3D CAD-structure – parts without a geometrical definition and, therefore, not having an associated drawing. However, these parts have a material specification, and therefore in the BOM-structure, they appear as Materials.

Next in the BOM-structure, the engineers would enter the expected/required quantity – which is no longer a rounded number.

At this stage, you cannot call the BOM on the left an EBOM. It is a kind of hybrid structure, combining engineering and manufacturing data. A type of BOM we discover a lot in companies that started with a type of ETO-product.

The ETO-product

Many companies that developed specialized machinery have started with a base product, from where they developed the custom solution – their IP. Next, with more and more customers, the original solution was extended by creating either new or changed capabilities.

I worked a lot with companies that moved to the full definition of their products in 3D CAD, creating a correct 3D CAD-structure per customer order. Instead of creating new BOM variants, companies were often tempted/forced to make the configuration inside the 3D CAD-model.

The 3D CAD vendor often provided functionality to have multiple configurations of the same part/product inside a single file. A nice feature for designers as there are fewer files to maintain, however, a crime for data management.

Every time one of the configurations of the part would change, or a new configuration was added, the file has to be revised.

And if the change was at level five of a 3D CAD-structure, many assembly files needed to be updated. The versioning problem illustrates the challenge of managing configurations inside a 3D CAD-file, meanwhile creating complexity for the PDM/PLM-system.

Last week Tech-Clarity published the highlights of their survey: Bringing Custom-Engineered Products to Market with a link to the full report, sponsored by Propel.

As you can imagine, this survey is more about PLM collaboration, breaking down the silos and acting agile. Unfortunately, the report does not expose required methodologies, like modularity and “common sense” engineering practices that we discuss here. Still worthwhile to read as the report addresses precisely the type of companies I am referring too here.

If we look at the methodology of custom-engineered products, let us look at how their “best practice” from the past is blocking the future.

When a new customer request is coming in, sales engineering is looking for the best match of delivered products. Hopefully, 80-90 % remains the same, and engineering has to focus only on the differences.

First, the best-match 3D CAD-structure is copied to a new project. As you can see most 3D CAD-systems provide the functionality to create a derived structure from an original 3D CAD-structure. From there, a traditional ETO-process starts as described at the beginning of this post. We complete the 3D CAD-structure with manufacturing in mind, generate the BOM and drawings, and we can deliver. In the case of purchase parts, the generated BOM often contains already the supplier part number in the 3D CAD-structure as we are focusing on this single delivery.

The disadvantage of this approach that in theory, we have to check if the structure that we reused is really the best so far, otherwise we introduce errors again.

The second disadvantage is that if one supplier part in the structure becomes obsolete and needs to be revised, the company has to go through all the 3D CAD-structures to fix it.

Also, having supplier parts in the 3D CAD-structure makes it more difficult to standardize, as the chosen supplier part matched the criteria for that customer at that time. Will it match the criteria also in other situations?

From ETO to BTO to CTO

Many companies that started with custom-engineered products, the ETO-approach, want to move towards a Configure To Order (CTO) approach – or if not possible at least Build To Order (BTO). More reuse, less risk,  instead of creating every time a new solution for the next customer, as discussed before.

This is not a mission impossible; however, often, I have seen that companies do not set the right priorities to move towards a configure to order environment. There are a few changes needed to become a configure to order company (if possible):

  1. Analyze your solution and define modules and options. Instead of defining a full solution, the target now is to discover a commonality between the various solutions. Based on commonality, define modules and options in such a manner that they can be used in different situations. Crucial for these modules is that there is a standard interface to the rest of the product. Every company needs to master this specific methodology for their products
  2. Start defining products from a logical structure, defining how products, modules and options are compatible and which combinations are allowed (or preferred). For companies that are not familiar with logical structure, often a configured EBOM is used to define the solutions. Not the optimal way; however, this was the first approach most companies took ten years ago. I will explain the configured EBOM below.
  3. A product definition and its modules now should start from a real EBOM, not containing manufacturing characteristics. The EBOM should represent the logical manner of how a product is defined. You will notice this type of EBOM might be only 2 – 3 levels deep. At the lowest level, you have the modules that have their own lifecycle and isolated definition.
  4. You should no longer use supplier part numbers in your EBOMs. As the engineering definition of a module or option should not depend over time from a single supplier. We will discuss in the next post the relation between EBOM parts and the Approved Manufacturer List (AML)

To conclude for today

Changing from ETO to CTO requires modularity and a BOM-driven approach. Starting from a 3D CAD-structure can still be done for the lowest levels – the modules, the options. In a configure to order process, it might not be relevant anymore to create a full 3D-representation of the product.

However, when we look forward, it would be greatly beneficial to have the 3D-representation of every specific solution delivered. This is where concepts as augmented/virtual reality and digital twin come in.

Next time more on the BOM-structures – as we have just touched the upcoming of the EBOM – enough to clarify next week(s).

This time a short post (for me) as I am in the middle the series “Learning from the past to understand the future” and currently collecting information for next week’s post. However, recently Rob Ferrone, the original Digital Plumber, pointed me to an interesting post from Scott Taylor, the Data Whisperer.

In code: The Virtual Dutchman discovered the Data Whisperer thanks to the original Digital Plumber.

Scott’s article with the title: “Data Management Hasn’t Failed, but Data Management Storytelling Has” matches precisely the discussion we have in the PLM community.

Please read his article, and just replace the words Data Management by PLM, and it could have been written for our community. In a way, PLM is a specific application of data management, so not a real surprise.

Scott’s conclusions give food for thought in the PLM community:

To win over business stakeholders, Data Management leadership must craft a compelling narrative that builds urgency, reinvigorates enthusiasm, and evangelizes WHY their programs enable the strategic intentions of their enterprise. If the business leaders whose support and engagement you seek do not understand and accept the WHY, they will not care about the HOW. When communicating to executive leadership, skip the technical details, the feature functionality, and the reference architecture and focus on:

  • Establishing an accessible vocabulary
  • Harmonizing to a common voice
  • Illuminating the business vision

When you tell your Data Management story with that perspective, it can end happily ever after.

It all resonates well with what I described in the PLM ROI Myth – it is clear that when people hear the word Myth, they have a bad connotation, same btw for PLM.

The fact that we still need to learn storytelling is because most of us are so much focused on technology and sometimes on discovering the new name for PLM in the future.

Last week I pointed to a survey from the PLMIG (PLM Interest Group) and XLifcycle, inviting you to help to define the future definition of PLM.

You are still welcome here: Towards a digital future: the evolving role of PLM in the future digital world.

Also, I saw a great interview with Martin Eigner on Minerva PLM TV interview by Jennifer Moore. Martin is well known in the PLM world and has done foundational work for our community

. According to Jennifer, he is considered as The Godfather of PLM.  This tittle fits nicely in today’s post. Those who have seen his presentations in recent years will remember Martin is talking about SysLM (System Lifecycle Management) as the future for PLM.

It is an interesting recording to watch – click on the image above to see it. Martin explains nicely why we often do not get the positive feedback from PLM implementations – starting at minute 13 for those who cannot wait.

In the interview, you will discover we often talk too much about our discipline capabilities where the real discussion should be talking business. Strategy and objectives are discussed and decided at the management level of a company. By using storytelling, we can connect to these business objectives.

The end result will be more likely that a company understands why to invest significantly in PLM as now PLM is part of its competitiveness and future continuity.

Conclusion

I shared links to two interesting posts from the last weeks. Studying them will help you to create a broader view. We have to learn to tell the right story. People do not want PLM – they have personal objectives. Companies have business objectives, and they might lead to the need for a new and changing PLM. Connecting to the management in an organization, therefore, is crucial.

Next week again more about learning from the past to understand the future

Image:  21stcenturypublicservant.wordpress.com/

I have talked a lot the past years about Digital Transformation and in particular its relation to PLM. This time I want to focus a little more on Digital Transformation and my observations related to big enterprises and small and medium enterprises. I will take you starting from the top, the C-level to the work floor and then try to reconnect through the middle management. As you can imagine from the title of this post, there is a challenge. And I am aware I am generalizing for the sake of simplicity.

Starting from the C-level of a large enterprise

Large and traditional enterprises are having the most significant challenge when aiming at a digital transformation for several reasons:

  • They have shareholders that prefer short-term benefits above long-term promising but unclear higher benefits. Shareholders most of the time have no personal interest in these companies, they just want to earn money above the average growth.
  • The CEO is the person to define the strategy which has to come with a compelling vision to inspire the shareholders, the customers and the employees in the company – most of the time in that order of priority.
  • The role of the CEO is to prioritize investments and stop or sell core components to make the transformation affordable. Every transformation is about deciding what to stop, what to start and what to maintain.
  • After four to seven years (the seven years’ itch) it is time for a new CEO to create a new momentum as you cannot keep the excitement up too long.
  • Meanwhile, the Stop-activities are creating fear within the organization – people start fearing their jobs and the start-activities are most of the time of such a small-scale that their successes are not yet seen. So at the work floor, there will be reservations about what’s next

Companies like ABB, Ericsson, GE, Philips – in alphabetical order – are all in several stages of their digital transformation and in particular I have followed GE as they were extremely visible and ambitious. Meanwhile, it is fair to say that the initial Digital Transformation plan from GE has stalled and a lot of lessons learned from that.

If you have time – read this article: The Only Way Manufacturers Can Survive – by Vijay Govindarajan & Jeff Immelt (you need to register). It gives useful insights about what the strategy and planning were for digital transformation. And note PLM is not even mentioned there J

Starting from the C-level of a small and medium enterprise

In a small or medium enterprise, the distance between the C-level and the work floor is most of the time much shorter and chances are that the CEO is a long-term company member in case of a long-standing family-owned business. In this type of companies, a long-term vision can exist and you could expect that digital transformation is more sustainable there.

Unfortunate most of the time it is not, as the C-level is often more active in current business strategies and capabilities close to their understanding instead of investing energy and time to digest the full impact of a digital transformation. These companies might invest in the buzz-words you hear in the market, IoT, Digital Twins and Augmented Reality/Virtual Reality, all very visionary topics, however of low value when they are implemented in an isolated way.

In this paragraph, I also need to mention the small and medium enterprises that are in the hands of an investment company.  Here I feel sorry as the investment company is most of the time trying to optimize the current ways of working by simplifying or rationalizing the business, not creating a transformative vision (as they do not have the insights. In this type of companies, you will see on a lower scale the same investments done as in the other category of small and medium enterprises, be it on a lesser scale.

Do people need to change?

Often you hear that the problem with any change within the companies is because people do not want to change. I think this is too much a generalization. I have worked in the past five years with several companies where we explored the benefits and capabilities of PLM in a modern way, sometimes focusing on an item-centric approach, sometimes focusing on a model-based approach. In all these engagements there was no reluctance from the users to change.

However, there were two types of users in these discussions. I would characterize as evolutionary thinkers (most of the time ten years or more in the company) and love-to-change thinkers (most of them five years or less in the company). The difference between these groups was that the evolutionary thinkers were responding in the context of the existing business constraints where the love-to-change thinkers were not yet touched by the “knowledge how good everything was”.

For digital transformation, you need to create the love-to-change attitude while using the existing knowledge as a base to improve. And this is not a people change, it is an organizational change where you need to enable people to work in their best mode. It needs to be an end-to-end internal change – not changing the people, but changing the organizational parameters: KPIs, divisions, departments, priorities. Have a look at this short movie, you can replace the word ERP by PLM, and you will understand why I like this movie (and the relaxing sound)

The Middle Management dilemma

And here comes my last observation. At the C-level we can find inspiring visions often outcome-based, talking about a more agile company, closer to the customer, empowered workers, etc.  Then there is the ongoing business that cannot be disrupted and needs to perform – so the business units, the departments all get their performance KPIs, merely keeping the status quo in place.

Also, new digital initiatives need to be introduced. They don’t fit in the existing business and are often started in separation – like GE Digital division, and you can read Jeff Immelt’ s thoughts and strategy how this could work. (The Only Way Manufacturers Can Survive). However as the majority of the business runs in the old mode, the Digital Business became another business silo in the organization, as the middle management could not be motivated to embed digital in their business (no KPIs or very low significance of new KPIs)

I talked about the hybrid/bimodal approach several times in my blog posts, most recently in The Challenges of a Connected Ecosystem.  One of the points that I did not address was the fact that probably nobody wants to work in the old mode anymore once the new approach is successful and scaled up.

When the new mode of business is still small, people will not care so much and continue business as usual. Once the new mode becomes the most successful part of the company, people do want to join this success if they can. And here the change effort is needed. An interesting article in this context is The End of Two-Speed IT from the Boston Consultancy Group (2016). They already point at the critical role of middle management. Middle management can kill digital transformation or being part of it, by getting motivated and adopting too.

Conclusion

Perhaps too much text in this post and even more content when you dive more in-depth in the provided content. Crucial if you want to understand the digital transformation process in an existing company and the critical place of middle management. They are likely the killers of digital transformation if not give the right coaching and incentives.  Just an observation – not a thought 😉

Last week I posted my first review of the PDT Europe conference. You can read the details here: The weekend after PDT Europe (part 1).  There were some questions related to the abbreviation PDT. Understanding the history of PDT, you will discover it stands for Product Data Technology. Yes, there are many TLA’s in this world.

Microsoft’s view on the digital twin

Now back to the conference. Day 2 started with a remote session from Simon Floyd. Simon is Microsoft’s Managing Director for Manufacturing Industry Architecture Enterprise Services and a frequent speaker at PDT. Simon shared with us Microsoft’s viewpoint of a Digital Twin, the strategy to implement a Digit Twin, the maturity status of several of their reference customers and areas these companies are focusing. From these customers it was clear most companies focused on retrieving data in relation to maintenance, providing analytics and historical data. Futuristic scenarios like using the digital twin for augmented reality or design validation. As I discussed in the earlier post, this relates to my observations, where creating a digital thread between products in operations is considered as a quick win. Establishing an end-to-end relationship between products in operation and their design requires many steps to fix. Read my post: Why PLM is the forgotten domain in digital transformation.

When discussing the digital twin architecture, Simon made a particular point for standards required to connect the results of products in the field. Connecting a digital twin in a vendor-specific framework will create a legacy, vendor lock-in, and less open environment to use digital twins. A point that I also raised in my presentation later that day.

Simon concluded with a great example of potential future Artificial Intelligence, where an asset based on its measurements predicts to have a failure before the scheduled maintenance stop and therefore requests to run with a lower performance so it can reach the maintenance stop without disruption.

Closing the lifecycle loop

Sustainability and the circular economy has been a theme at PDT for some years now too. In his keynote speech, Torbjörn Holm from Eurostep took us through the global megatrends (Hay group 2030) and the technology trends (Gartner 2018) and mapped out that technology would be a good enabler to discuss several of the global trends.

Next Torbjörn took us through the reasons and possibilities (methodologies and tools) for product lifecycle circularity developed through the ResCoM project in which Eurostep participated.

The ResCoM project (Resource Conservative Manufacturing) was a project co-funded by the European Commission and recently concluded. More info at www.rescom.eu

Torbjörn concluded discussing the necessary framework for Digital Twin and Digital Thread(s), which should be based on a Model-Based Definition, where ISO 10303 is the best candidate.

Later in the afternoon, there were three sessions in a separate track, related to design optimization for value, circular and re-used followed by a panel discussion. Unfortunate I participated in another track, so I have to digest the provided materials still. Speakers in that track were Ola Isaksson (Chalmers University), Ingrid de Pauw & Bram van der Grinten (IDEAL&CO) and Michael Lieder (KTH Sweden)

Connecting many stakeholders

Rebecca Ihrfors, CIO from the Swedish Defense Material Administration (FMV) shared her plans on transforming the IT landscape to harmonize the current existing environments and to become a broker between industry and the armed forces (FM). As now many of the assets come with their own data sets and PDM/PLM environments, the overhead to keep up all these proprietary environments is too expensive and fragmented. FWM wants to harmonize the data they retrieve from industry and the way they offer it to the armed forces in a secure way. There is a need for standards and interoperability.

The positive point from this presentation was that several companies in the audience and delivering products to Swedish Defense could start to share and adapt their viewpoints how they could contribute.

Later in the afternoon, there were three sessions in a separate track rented to standards for MBE inter-operability and openness that would fit very well in this context. Brian King (Koneksys), Adrian Murton (Airbus UK) and Magnus Färneland (Eurostep) provided various inputs, and as I did not attend these parallel sessions I will dive deeper in their presentations at a later time

PLM something has to change – bimodal and more

In my presentation, which you can download from SlideShare here: PLM – something has to change. My main points were related to the fact that apparently, companies seem to understand that something needs to happen to benefit really from a digital enterprise. The rigidness from large enterprise and their inhibitors to transform are more related to human and incompatibility issues with the future.

How to deal with this incompatibility was also the theme for Martin Eigner’s presentation (System Lifecycle Management as a bimodal IT approach) and Marc Halpern’s closing presentation (Navigating the Journey to Next Generation PLM).

Martin Eigner’s consistent story was about creating an extra layer on top of the existing (Mode 1) systems and infrastructure, which he illustrated by a concept developed based on Aras.

By providing a new digital layer on top of the existing enterprise, companies can start evolving to a modern environment, where, in the long-term, old Mode 1 systems will be replaced by new digital platforms (Mode 2). Oleg Shilovitsky wrote an excellent summary of this approach. Read it here: Aras PLM  platform “overlay” strategy explained.

Marc Halpern closed the conference describing his view on how companies could navigate to the Next Generation PLM by explaining in more detail what the Gartner bimodal approach implies. Marc’s story was woven around four principles.

Principle 1 The bimodal strategy as the image shows.

Principle 2 was about Mode 1 thinking in an evolutionary model. Every company has to go through maturity states in their organization, starting from ad-hoc, departmental, enterprise-based to harmonizing and fully digital integrated. These maturity steps also have to be taken into account when planning future steps.

Principle 3 was about organizational change management, a topic often neglected or underestimated by product vendors or service providers as it relates to a company culture, not easy to change and navigate in a particular direction.

Finally, Principle 4 was about Mode 2 activities. Here an organization should pilot (in a separate environment), certify (make sure it is a realistic future), adopt (integrate it in your business) and scale (enable this new approach to exists and grow for the future).

Conclusions

This post concludes my overview of PDT Europe 2017. Looking back there was a quiet aligned view of where we are all heading with PLM and related topics. There is the hype an there is reality, and I believe this conference was about reality, giving good feedback to all the attendees what is really happening and understood in the field. And of course, there is the human factor, which is hard to influence.

Share your experiences and best practices related to moving to the next generation of PLM (digital PLM ?) !

 

 

 

observation This week I realized that, although I believe the benefits of PLM are more and more accepted in mid-market companies, the decision how to start and where to start with PLM is often not clear. I recognize several approaches which I will describe in this and some upcoming posts.

All persons in this post are fiction and in case you recognize these persons in your company, it is pure coincidence. Instead of talking about approaches,I was tempted to call it strategies, but when you read my observation you will realize the word strategy would not fit.

Approach 1:  The silent PLM

PxM Inside our company, often there is an engineer or an engineering manager, who got caught by the PxM virus. The PxM virus is a modern virus, which makes you a believer that PDM or PLM will bring your company a lot of benefits. Documents and proof points of the severe impact exist all around the world. However nobody has gotten infected so far in this company. Everyone is working the way they worked since many years and life is secure and predictable.

Now this infected engineer is getting exited and dreams about the introduction of PLM in his company and how he will become the hero of the company and gets a big promotion. Unfortunate for him in this kind of business there are no big bonuses to collect, so the honor of promotion is already a big achievement.

So the first thing this engineer does is chatting with his peers and friends to find out where PxM has been implemented successful  and he studies some success stories which he learned from his network.

Now the challenge starts.

He goes to the management and shows a nice PowerPoint, explaining why the company needs PxM and what are the expected benefits, based on reference stories. The management has no real clue what he is talking about, but it looks promising and they allow him to select a PxM system for his department and to start a pilot.

sel_a The engineer already knows which PxM system to choose. The one, recommended by the friendly reseller, who sold them their 3D CAD system (which is a success) and worked hard with him to finalize the slides. As requested by the management he had to invite two other PxM vendors to make an objective selection and at the end an impressive comparison matrix is shown to the management why system A has been chosen.

Now the implementation starts and step 1 is very successful. The document management part around the CAD system goes smoothly and everyone in the engineering department starts to be happy.

Following this successful implementation there are two options:

  • the engineer does not get promoted and the implementation ends. It will remain a silent document management implementation and the dream is put aside.
  • the engineer gets promoted and continues to push his vision as now he has a broader audience to spread the PxM virus. We will follow this story line…….

The engineer gets promoted and continues to push his vision

This is the best that can happen and the engineer, who now became the head of engineering, starts to express his vision to his fellow managers, explaining the advantages of PLM. Notice, he is now talking about PLM as the scope has been extended beyond product data management, involving other disciplines in the organization.

vision

And here the head of engineering discovers that his fellow managers are also infected by a virus. Not the PxM virus, but one of them has already for many years the ERP virus. And as the ERP virus addresses the operational and financial tasks in the organization, the management trusts him.  The sales and marketing department seems to be infected by CRM, but currently they caught a social disease, which made them push for all kind of communities. The management either likes it (as their kids are also on Facebook) or dislikes it, because they believe work is a serious business and being on internet all day is considered gaming.

myplmSo the head of engineering realizes that he has some freedom within his department, but the other departments and the management have their own priorities. And PLM is not on their list. Together with the friendly CAD reseller, who meanwhile was promoted to be Senior PLM Consultant, they work on a perfect PLM environment within the engineering department and they believe their success will show off in the upcoming years.

And then the crisis came and the company had to cut budgets. To be continued in (hopefully) 1 or 2 years

Conclusion: The silent PLM approach has a huge chance to fail as there is no corporate vision and management push to get PLM implemented. PLM should be addressed top-down. As in many mid-market companies there was also no strategically partner, who could assist the management to build a vision and to set priorities.

Next week:

approach 2: Academical  PLM

tornado_butterfly You might have heard about the chaos theory and the butterfly effect ? In general, the theory promoted by Edward Lorentz and others, claims that the flapping of the wings of a butterfly, somewhere in South America may influence ultimately the path of a tornado, either preventing or accelerating that a tornado may hit at a certain place in North America.

WOW, if a butterfly can do this, can you imagine the impact of all of us, flapping our notes and plans around PLM in an organization ?  What a chaos we can create ?

I came to this association, looking back on my activities the past three weeks. Talking with implementers and companies, who all had a tornado of wishes and activities,  trying to create order through a PLM implementation – the anti-chaos theory.

Most of the discussions were based on a typical mid-market approach.

What do I mean by a typical mid-market approach – and I am generalizing here. None of the people I have been talking to in the past weeks match the exact characteristics, however all contributed to the picture in my mind.

shout_left

 

Typical mid-market approach (my generalization):

 

  • (Power) User Driven / Do It yourself approach – inside the organization there are people who have the dream to improve the company with PDM / PLM and the energy to prove it. They build the plan and define the solutions. External resources are only hired to do specialized services, fitting in the thought process of the power users. They believe that everyone will see the benefits of the implementation and join their approach step-by-step enthusiastically.
  • Focus on technical details– often the wishes are based on implementing technical capabilities close to the understanding of users, usually requiring a minimum of change in the daily processes. For example the focus might be on a technical capability how to connect the PLM system to the ERP system (Middleware / XML /Web Services / …..)  instead of discussing how it will work from the process point of view – how is the process impacted ?
  • Task solving – much in combination with the previous point, the focus is on optimizing and/or automating tasks of a certain user. The end-user’s daily tasks/pains are the focus for solving, which means trying to automate as much as possible, providing as much as possible single system / single screen solutions. 
  • Risk Avoidance – often these companies do not have the capabilities (people / time / budget) to experiment with new directions. Approaches from other similar companies are followed (looking for references). For sure not a bad approach, however the result is it will be harder to be differentiate from your competitors. And of course risk avoidance should always be considered in the scope of manageable risks.
  • Lack of top-management investment / push – although the top management in these companies subscribe to the needs for PLM, the focus of the investment is usually mainly on the external costs (software and services), where internal resources are forced to do the PLM activities beside daily tasks. Later the management will wonder why things are going slow, as they did their job (they approved the investment– waiting for the results now)
  • Focus on business skills – the people in the project team are often well educated in their daily business and practices, but lack project management, risk management and change management skills. These ‘soft’ skills are often acquired by buying a book to be placed on the desk.

observation

 

After writing these generalizations, I had the feeling that instead of characteristics, i was writing about risks . As this was not the intention, let see the how to manage these risks:

 

  • The power users should realize that they are sent on a difficult mission which requires a lot of creativity to implement changes in the context of the PLM project. And strange as it seems the PLM software might not be the biggest challenge.
    The biggest challenge will be on choosing the right best practices and to implement them with acceptance of the users. This is change management combined with implementation knowledge / experience. They point for the power users should be to have an implementation partner with experience, who can explain why best practices work and explain how other companies address this issue. Without practical guidance the power users have become pioneers, which is something the management for sure wants to avoid.
    Often to avoid user objections, the project team decides on heavy customizations or ‘weird’ compromises – nice to keep the user community quiet, but bad for the future, as benefits will not be the same.
    This mainly happens as there is too much focus the ‘hard’ side of the project ( hardware /software /IT /Services ) , and no or limited attention to the human / change management side.
    Power Users – be aware !
  • The management should realize that it is a company’s decision and vision. So from their side a steering committee with a clear vision is required. Their job is to keep the vision, prioritize the activities and make sure the power users are not creating an isolated solution based on their dreams.
    The most important role of the management is to take continues responsibility for the project – it does not end by giving the approval for the project and budget. Where users might reluctantly accept changes, it is the job of the management to enforce the changes and support them.
    This can be done in a harsh way by imposing the changes, however this will cause resistance and the end users will demonstrate the management was wrong. This leads at the end to a situation where the company as a whole will be in a worse position as before.
    So managing by motivation should be the approach, as after all the power lies in motivated users, who understand the benefits of the changes and benefits for their future job.
    Management – be aware !
  • Make sure the focus and priority is on business not on IT. Sell and explain the business benefits internally all the time.
    All be aware !

To conclude:

  • The mid-market characteristics look like risks for a successful PLM implementation, if not addressed and taken seriously
  • There is significant management support and control needed to monitor, guide and sell the PLM project.
    To make sure the company benefits are targeted and not the individual users or departments demands only.
  • Implement bottom up but control and direct top-down
  • Your implementation partner should have resources with skills for both levels – so not only programmers who can do miracles, but also consultants that can explain, validate best practices based on other experiences

 

Understanding chaos – enjoy:

observationThe past month I was involved in a two ENOVIA SmarTeam projects, where both had the target to become the company’s PLM system. However the way these projects were executed lead to the conclusion that the first one was probably going to fail as a PLM system, were the second project was going to be successful. 

And only by looking back to the history of the first implementation, it became clear what prevented it from becoming implemented as a PLM system. It had all to do with a bottom-up approach and a top-down approach. I guess ENOVIA SmarTeam is one of the few products that allows a customer to make a choice between bottom-up or top-down.

Somehow also Jim Brown’s post was in line with this observation, but judge yourself.

Most classical PLM systems require a top-down approach as the PLM scope requires departments to work in a different way and to enforce a change on the organization. Organizational change usually only happens top-down based on the vision of the management.

cad ENOVIA SmarTeam however has the option to be implemented as a CAD data management system, managing the Product Data in the form of documents. This brings a lot of value to the engineering department and depending on the PLM awareness of the company they might try to replace the Excel based Bill Of Materials  into a BOM inside the system. As we are working in the scope of engineering this is in most of the cases the Engineering BOM.

There are also other CAD data management systems that claim to be an enterprise PDM system as they manage the product data (usually only the native CAD data) and the engineering BOM. As these systems do not contain capabilities to become an enterprise PLM system, it will be clear for the organization, where to position it – and to keep it in the engineering department.

There are engineering managers in mid-market companies that have the PLM vision and this was the case in the first implementation I mentioned. As his initial mission was to manage the product data based on SolidWorks and AutoCAD, the company decided that ENOVIA SmarTeam was the best multi-CAD data management solution for the company. Meanwhile the engineering manager had the hope (or dream) that once this implementation was completed all other departments would stand in a queue to get connected to ENOVIA SmarTeam too………

…. and this did not happen. Why ?

The main reason for that was that at the time the management had understood the PLM benefits and considered implementing PLM, they looked at SmarTeam and it was implemented too much as an engineering solution, too rich in functionality (and complexity) to be used and integrated by other departments. But when the company was looking to an PLM extension from their ERP system, the engineers refused to work with that system, as according to their opinion the system did not support their needs.

How could this be prevented ?

express This was done exactly in the second project. Also here the implementation started in the engineering department, but from the start it was clear for the management, that they would extend the implementation towards a full cross-departmental PLM implementation. The main difference was that the implementation was not focused on satisfying the designers, but from the start it was clear ENOVIA SmarTeam should be useful for other departments too. This implicated less customization on the existing product, more standard functionality. Yes, the designer had to change their way of working as they worked file-based before. But as the focus of the implementation was always on providing data access across the organization, the system remained attractive for the production planning and manufacturing people. It was not an engineering tool only.

Additionally the standard ENOVIA SmarTeam system required from all departments adaptations to their working methods, but as it was not heavily customized, it was much easier to extend the scope beyond engineering.

So what is the conclusion:

  • Do not try to build the ultimate engineering solution as step 1 in a PLM project. Remain with the core capabilities.
  • Keep the focus on storing information in such a way that it becomes usable for departments outside engineering. This requires less detailed data and more reporting capabilities
  • Do not hide the intentions to the management that ENOVIA SmarTeam can become the company’s PLM system. Make the management aware of that but also explain the benefits of a step-by-step implementation, starting with engineering and expanding when the time is ripe
  • It would not be the first time that ENOVIA SmarTeam was the best kept secret for the management. The engineering department was happy, but no-one made the effort to explain the full capabilities to the top management

And now a small advertisement add the end

sde The ENOVIA SmarTeam Express offering allows a customer to start design centric (SDE = SmarTeam Design Express) and to extend the scope step by step by applying engineering capabilities extending the scope from Concept to Manufacturing (SNE = SmarTeam Engineering Express), guiding a bottom-up implementation step-by-step.

Translate

Categories

  1. If it was easy, anyone could do it. It's hard. It's supposed to be hard. Quote inspired by Tom Hanks…

%d bloggers like this: