You are currently browsing the tag archive for the ‘digital revolution’ tag.
If you have followed my blog the recent years, you might have discovered my passion for a modern, data-driven approach for PLM. (Read about it here: The difference between files and data-driven – a tutorial (3 posts)).
The data-driven approach will be the foundation for product development and innovation in a digital enterprise. Digital enterprises can outperform traditional businesses is such a way that within five to ten years, non-digital businesses will be considered as dinosaurs (if they still exist).
In particular, a digital enterprise is operating in an agile, iterative way with the customer continuously in focus, where traditional enterprises often work more in a linear way, pushing their products to the market (if the market still is waiting for these commodities).
Read more about this topic here: From a linear world to fast and circular?
When and how to become a digital enterprise?
It is (almost) inevitable your company will transform at a particular time into a digital enterprise too. Either driven by a vision to remain ahead of the competition or as a final effort to stay in business as competing against agile digital competitors is killing your market share.
One characteristic of a digital enterprise is that all benefits rely on accurate data flowing through the organization and its eco-system. And it does not matter if the data resides in a single system/platform like the major vendors are promoting or the fact that data is federated and consumed by the right person with the right role. I am a believer in the latter concept, still seeing current startups trying to create the momentum to achieve such an infrastructure. Have a look at my blog buddy’s company OpenBOM and Oleg’s recent article: The challenges of distributed BOM handover in data-driven manufacturing
No matter what you believe at this stage, the future is about accurate data. I bumped recently into some issues related actual data again. Some examples:
A change in objectives is needed!
One of the companies I am working with were only focusing on individual outputs, either in their drawings (yes, the 3D Model was not leading yet) or/and in their Excels (sounds familiar ? ). When we started implementing a PLM backbone, it became apparent during the discovery phase we could not use any advanced search tools to have quick wins by aggregating data for better understanding of the information we discovered. Drawings and Models did not contain any (file) properties. Therefore, the only way to understand information was by knowing its (file) name and potential its directory. Of course, the same file could be in multiple directories and as there were almost no properties, how to know what belongs to what item ?
When discussing the future of PLM with such companies, you always hear people (mainly engineers) say:
“we are not administrators, we need to get our job done.”
This shortsighted statement is often supported by management, and then you get stuck in the past.
It is time for the management and engineers to realize their future is also based on a data-driven approach. Therefore adding data to a drawing or CAD model, or in the case of PLM, part / process characteristics become the job of an engineer. We have to redefine roles as in a digital enterprise there is nobody to fix data downstream. People fixing data issues are too expensive.
I do not want to go digital
Most companies at this time are not ready for a digital enterprise yet. The changing paradigm is relatively new. Switching now to a modern approach cannot be done either because their culture is still based on the previous century or they are just in the middle of a standard PLM process, just learning to share files within their (global) origination. These companies might create an attitude:
“I do now want to go digital”
I believe this is ostrich behavior, like saying:
“I want all information printed on paper on my desk so I can work in comfort (and keep my job).”
History shows hanging to the past is killing for companies. Those companies that did not invest in the first electronic wave are probably out of business (unless they never had competition). The same for digital. In potentially ten years from now, it is not affordable to work in a traditional way anymore as labor cost and speed of information flowing through an organization are going to be crucial KPIs to stay in business.
The compromise
As Dutch, we are always seeking compromises. It helped our country to become a leading trading nation and due to the compromises, we struggle less with strikes compared to our neighboring companies. Therefore my proposal for those who do not like digital at this stage: Add just a little digital workload to your day-to-day business, preferably stimulated and motivated by your management and promoted as a company initiative. By adding as much as possible relevant properties and context to your work, you will be working on the digital future of your company. When the times is there to become digital, it will be much easier to connect your old legacy information to the new digital platform, speeding up the business transformation.
And of course there will be tools
If you are observing what is happening in the PLM domain , you will see more and more tools for data discovery and data cleansing will appear on the market. Dick Bourke wrote end of last year an introduction article about this topic at Engineering.com: Is-Suspect-Product-Data-the-Elephant-in-the-Search-and-Discover-Room? Have a read to get interested.
And there are rewards
Once you have more accurate data, you can:
- Find it (saving search time)
- Create reports through automation (saving processing time)
- Apply rules (saving validation work & time or processing time)
- Create analytics (predict the future – priceless J)
Conclusion
We are in a transition phase the way PLM will is implemented. What is clear, no matter in which stage you are, accurate data is going to be crucial for the future? Use this awareness for your company to stay in business.
Two weeks ago I got this message from WordPress, reminding me that I started blogging about PLM on May 22nd in 2008. During some of my spare time during weekends, I began to read my old posts again and started to fix links that have been disappearing.
Initially when I started blogging, I wanted to educate mid-market companies about PLM. A sentence with a lot of ambiguities. How do you define the mid-market and how do you define PLM are already a good start for a boring discussion. And as I do not want to go into a discussion, here are my “definitions”
Warning: This is a long post, full of generalizations and a conclusion.
PLM and Mid-market
The mid-market companies can be characterized as having a low-level of staff for IT and strategic thinking. Mid-market companies are do-ers and most of the time they are good in their domain based on their IP and flexibility to deliver this to their customer base. I did not meet mid-market companies with a 5-year and beyond business vision. Mid-market companies buy systems. They bought an ERP system 25-30 years ago (the biggest trauma at that time). They renewed their ERP system for the Y2K problem/fear and they switched from drawing board towards a 2D CAD system. Later they bought a 3D CAD system, introducing the need for a PDM system to manage all data.
PLM is for me a vision, a business approach supported by an IT-infrastructure that allows companies to share and discover and connect product related information through the whole lifecycle. PLM enables companies to react earlier and better in the go-to-market process. Better by involving customer inputs and experience from the start in the concept and design phases. Earlier thanks to sharing and involving other disciplines/suppliers before crucial decisions are made, reducing the amount of iterations and the higher costs of late changes.
Seven years ago I believed that a packaged solution, combined with a pre-configured environment and standard processes would be the answer for mid-market companies. The same thought currently PLM vendors have with a cloud-based solution. Take it, us it as it is and enjoy.
Here I have changed my opinion in the past seven years. Mid-market companies consider PLM as a more complex extension of PDM and still consider ERP (and what comes with that system) as the primary system in the enterprise. PLM in mid-market companies is often seen as an engineering tool.
LESSON 1 for me:
The benefits of PLM are not well-understood by the mid-market
To read more:
PLM for the mid-market – mission impossible?
PLM for the SMB – a process or culture change ?
Culture change in a mid-sized company – a management responsibility
Mid-market PLM – what did I learn in 2009 ?
Implementing PLM is a change not a tool
Who decides for PLM in a mid-market company ?
More on: Who decides for PLM in a mid-market company ?
Globalization and Education
In the past seven years, globalization became an important factor for all type of companies. Companies started offshoring labor intensive work to low-labor-cost countries introducing the need for sharing product data outside their local and controlled premises. Also, acquisitions by larger enterprises and by some of the dominant mid-market companies, these acquisitions introduced a new area of rethinking. Acquisitions introduced discussions about: what are real best practices for our organization? How can we remain flexible, meanwhile adapt and converge our business processes to be future ready?
Here I saw two major trends in the mid-market:
Lack of (PLM) Education
To understand and implement the value of PLM, you need to have skills and understanding of more than just a vendor-specific PLM system. You need to understand the basics of change processes (Engineering Change Request, Engineering Change Order, Manufacturing Change Order and more). And you need to understand the characteristics of a CAD document structure, a (multidisciplinary) EBOM, the MBOM (generic and/or plant specific) and the related Bill of Processes. This education does not exist in many countries and people are (mis-)guided by their PLM/ERP vendor, explaining why their system is the only system that can do the job.
Interesting enough the most read posts on my blog are about the MBOM, the ETO, BTO and CTO processes. This illustrates there is a need for a proper, vendor-independent and global accepted terminology for PLM
Some educational posts:
Bill of Materials for Dummies – ETO ranked #1
ECR/ECO for Dummies ranked #2
BOM for Dummies – CTO ranked #4
BOM for Dummies: BOM and CAD ranked #7
BOM for Dummies – BTO
Where does PLM start beyond document management ?
The dominance of ERP
As ERP systems were introduced long before PLM (and PDM), these systems are often considered by the management of a mid-market company as the core. All the other tools should be (preferably) seen as an extension of ERP and if possible, let´s implement ERP vendor´s functionality to support PLM – the Swiss knife approach – one tool for everything. This approach is understandable as at the board level there are no PLM discussions. Companies want to keep their “Let´s do it”-spirit and not reshuffle or reorganize their company, according to modern insights of sharing. Strangely enough, you see in many businesses the initiative to standardize on a single ERP system first, instead of standardizing on a single PLM approach first. PLM can bring the global benefits of product portfolio management and IP-sharing, where ERP is much more about local execution.
LESSON 2:
PLM is not understood at the board level, still considered as a tool
Some post related to PLM and ERP
Where is the MBOM ? ranked #3
Connecting PLM and ERP (post 1) – (post 2) – (post 3) ranked #8
PLM and ERP – the culture change
5 reasons not to implement PLM – Reason #3 We already have an ERP system
The human factor
A lot of the reasons why PLM has the challenge to become successful have to do with its broad scope. PLM has an unclear definition and most important, PLM forces people to share data and work outside their comfort zones. Nobody likes to share by default. Sharing makes day-to-day life more complicated, sharing might create visibility on what you actually contribute or fix. In many of my posts, I described these issues from various viewpoints: the human brain, the innovators dilemma, the way the older generation (my generation) is raised and used to work. Combined with the fact that many initial PLM/PDM implementations have created so many legacies, the need to change has become a risk. In the discussion and selection of PLM I have seen many times that in the end a company decides to keep the old status quo (with new tools) instead of really having the guts to move toward the future. Often this was a result of investors not understanding (and willing to see) the long term benefits of PLM.
LESSON 3:
PLM requires a long-term vision and understanding, which most of the time does not fit current executive understanding (lack of education/time to educate) and priority (shareholders)
Many recent posts are about the human factor:
The Innovator´s dilemma and PLM
Our brain blocks PLM acceptance
How to get users excited or more committed to a new PLM system?
The digital transformation
The final and most significant upcoming change is the fact that we are entering a complete new era: From linear and predictable towards fast and iterative, meaning that classical ways we push products to the market will become obsolete. The traditional approach was based on lessons learned from mechanical products after the second world-war. Now through globalization and the importance of embedded software in our products, companies need to deliver and adapt products faster than the classical delivery process as their customers have higher expectations and a much larger range to choose from. The result from this global competitiveness is that companies will change from delivering products towards a more-and-more customer related business model (continuous upgrades/services). This requires companies to revisit their business and organization, which will be extremely difficult. Business wise and human change require new IT concepts – platform? / cloud services? / Big data?
Older enterprises, mid-market and large enterprises will be extremely challenged to make this change in the upcoming 10 years. It will be a matter of survival and I believe the Innovator´s Dilemma applies here the most.
LESSON 4:
The digital transformation is apparent as a trend for young companies and strategic consultants. This message is not yet understood at the board level of many businesses.
Some recent post related to this fast upcoming trend:
From a linear world to fast and circular ?
Did you notice PLM is changing?
Documents or Intelligent Data ?
The difference between files and data-oriented – a tutorial (part 1) – (part 2) – (part 3)
PLM and/or SLM? – (part 1) – (part 2)
Breaking down the silos with data
ROI (Return On Investment)
I also wrote about ROI – a difficult topic to address as in most discussions related to ROI, companies are talking about the costs of the implementation, not about the tremendous larger impact a new business approach or model can have, once enabled through PLM. Most PLM ROI discussions are related to efficiency and quality gains, which are significant and relevant. However these benefits are relative small and not comparable with the ability to change your business (model) to become more customer centric and stay in business.
Some of the ROI posts:
To PLM or Not to PLM – measuring the planning phase ranked #5
Free PLM Software does not help companies ranked #6
PLM selection–additional thoughts
PLM Selection: Proof Of Concept observations
Where is my PLM Return On Investment (ROI) ?
Conclusion
A (too) long post this time however perhaps a good post to mark 7 years of blogging and use it as a reference for the topics I briefly touched here. PLM has many aspects. You can do the further reading through the links.
From the statistics it is clear that the education part scores the best – see rankings. For future post, let me know by creating a comment what you are looking for in this blog: PLM Mid-Market, Education, PLM and ERP, Business Change, ROI, Digitalization, or …??
Also I have to remain customer centric – thanks for reading and providing your feedback
Above Image courtesy of the marketoonist.com – Tom Fishburne
Image related to digital transformation: The Economist – the onrushing wave
In my previous post, I talked about the unstoppable trend towards digital information and knowledge based on data becoming the new business paradigm.
Building knowledge based on information extracted from data, instead of working with documents and people, who need to manipulate these documents.
Moreover, the reasons to move towards a digital data-oriented approach are the immense business benefits it can bring to an organization. Having online visibility on information in context of other information from different stakeholders allows companies to be more proactive.
A proactive company will react faster to the market or customer. This will reduce waste and resources (materials / people) and therefore in the end be more competitive. This is all described in my first post, with relevant links to various global references.
In this post, I want to describe in an example what the differences are between a document-oriented and a data-oriented approach and how it affects people and business. This might give you an impression of the expected business benefits.
The ultimate goal behind a data-oriented approach is to have a single version of the truth for a product, project or plant. This can be realized by treating information as data elements in various connected database, where on demand reports or dashboards can be created based on actual information, instead of documents generated by duplicating data in new systems and locations. Digital data will provide paperless processes accessible almost anywhere around the world.
As an example, I will explain the difference between document-centric and data-centric when dealing with specifications.
The specification
Everyone knows the challenge with specifications. Most of the time in printed documents describing how a product or service should work from the client point of view. There are two principles behind specifications:
- Complexity. The more complex product or service is, the bigger chance that specifications are not complete or hundred percent understood, leading to an iterative change process. The challenge here is to manage the change and the consistency of the full specifications.
- Industry and margins. In a repetitive business, for example, the automotive or other mass consumer products, products can be quiet complex and once sold hard to maintain and repair. In a competitive business, an error in the field can consume a lot of the expected profit. In the construction industry, where most of the time single projects are executed by a chain of disciplines, the industry (still) accepts the costs overrun and the high costs of fixing issues in the field, instead of being clearer upfront during the design and planning.
Let’s stay with the example in the middle of complexity and industry volume. In color the various stages of the process.
The document based specification – 1
When the document based specification arrives, the company has to get an understanding of the content. The project manager has a first read through the document (100+ pages) and decides to send the document (it is a pdf) to sales, engineering, legal and planning. Engineering decides to distribute the document internally to mechanical, electrical and quality (for compliance).
The project manager stresses everyone on a weekly base to deliver the responses and tries to understand if the answers will come in time. There are some meetings needed with the stakeholders as the whole understanding needs to be consistent. Based on several iterations a response is compiled.
The data-oriented approach – 1
When the document based specification arrives, the project leader first stores the document as a reference in the PLM system and extracts all the customer requirements as data elements in the system. While extracting the requirements, the projects manager groups them into digital folders (functional / non-functional, contractual, regulations, etc.) and assigns them to the relevant stakeholders, who get notified by the system. Each of the persons assigned, again the engineering manager has distributed the discipline specific requirements internally.
The project manager watches the progress of the requirements analyses which are around a virtual model. There is still a need for meetings with the stakeholders to agree on the solution approach. Everything is stored and visible online in the system. This visibility has helped some of the stakeholders to be better-aligned upfront. In the end, the response is generated and converted to the customer’s format.
Not much benefit for step 1
If you compare the two approaches, there is mainly one person happy: the project manager. Instead of spending time to collect the status of all information, direct visibility on the response helps him/her to prioritize of focus where attention is needed, instead of discovering it on a weekly base.
There is some small benefit from the virtual model as other stakeholders can have a better understanding of the actual progress.
However, for the rest, all stakeholders are complaining. It is difficult to work. (Fl)Excel was much easier. Moreover, thinking about a virtual model takes time as we are not used working in this way. Typically something for aerospace you might think.
And now the benefits come – step 2
The customer has placed the order, and the project has started. The design has started, and people start to discover discrepancies or ambiguous demands that need to be negotiated with the customer. Is it part of the project and if not, should it become part of the project and at which costs (for whom)
The document oriented approach – 2
Several engineers are now discussing with the counterparts at the customer the detailed interpretation of the requirements, either through face-to-face meetings or emails. Changes are collected and sent to the project manager, who tries to understand what has changed and how to merge it in an on-going specification document. To avoid many revisions, he/she tries to update the document on a bi-weekly base, send it to the internal stakeholders for review and with their feedback generates a specification document for the customer that supposed to cover the latest agreements.
Unfortunate not all changes have reached the document as some of the stakeholders were busy and forgot to include some of the changes agreed with the customer as they were in a lost email. Also, a previous change of a requirement was overwritten as an update from quality used the old data. Finally, some design solutions were changed, which raised the costs. And not sure if the product with all its changes will be compliant after delivery. However, luckily nobody noticed so far, not even the customer
The data-oriented approach – 2
Thanks to the virtual model and the relations between all the requirements, any change in a requirement gets notified in the system. When a requirement is further clarified, it is updated in the system. When a requirement needs to be changed, it is clear what the impact of this change is. A change workflow assures that decisions are made visible and approved. Potentially changes that lead to more work were quoted to the customer for acceptance. Luckily the compliancy engineer noted that the change of materials used would lead to a compliancy issue. On a bi-weekly base, the project manager generates an agreed specification for the customer based on the data in the system.
Benefits are growing.
The project manager remains the happiest person and is even happier as less discussion is needed about who changed what and why. Alternatively, discussions about changes that should exist and cannot be found. The time saved by the project manager could be used to collaborate even better with the teams (without annoying them) or perhaps a second project to manage in parallel.
Other stakeholders start to enjoy the data-oriented approach too. Less ambiguity on their side too, fewer iterations because changes were not apparent. As all information is related to the virtual model online, the actual status is clear when making a decision. Less fixing afterwards and luckily still project meeting between the stakeholders to synchronize. The PLM system does not eliminate communication; it provides a reliable baseline of the truth. No need (and option) to look in your archives.
At this stage, benefits start to become clear. Fewer iterations and better decisions will have an impact on the costs and project stress. Still a complaint from the engineers might be that they need to do too much upfront thinking although some years later they might discover that this will be their main job. Fixing issues from the past have diminished.
And then the ultimate benefits
Now the project has reached the physical state. It is manufactured or under commissioning.
The document oriented approach – 3
In the document oriented approach, many issues might pop-up because they have not been considered in the early phase, or they got lost during document exchanges. Does the product work as specified? Is the building certified as specified?
The customer is king and for manufacturing companies this might lead to product recalls or launch delays. In the construction world, people in the field, will fix the issues by using skilled resources and creating a waste of materials and/or resources.
Data handover to the owner is a nightmare for a the project-centric delivery. Several people have been searching for documents, specifications and emails to build and compile the required documents for handover.
The data-oriented approach – 3
In the data-centric approach, the behavior of the physical product works as expected as most of the issues have been solved in the virtual model. When testing the product it works as specified as the specifying requirements have always been linked to the product. Moreover, they have been agreed and approved by the relevant stakeholders. Where relevant, the customer has paid for the extra work specified.
The handover process was not so stressful as before with the document-oriented approach. As the required information was known and specified upfront related to the requirements, the maturity process of the virtual model assured this data exists in the system. Now the as-built information matches the as-specified information. What a relief.
Conclusion
It is clear that the significant benefits can be found in step 3. I wrote the comparison in an extreme manner, knowing that reality lies in the middle. Excellent people can comprehend and fix more upfront because of their experience. Building the ultimate virtual model is not yet an easy achievement either.
The savings in materials and required resources are significant in a data-oriented approach. The time savings and the quality enhancements might change your company into a market-leader. The cost savings achieved through a pro-active approach will make your margin growing (unless competition does the same) and enable you to innovate.
One final remark on business change
If business change could be achieved by selecting the right tool or system without a business change, you will never get a competitive advantage. As your competitor can buy these too.
However, if you change to a data-centric approach, it will be a though change process and therefore once implemented you will leave competitors behind that keep on hanging on the past.
Jos Voskuil's Weblog 
Jos, great thoughts about BOM management. Here are some of my thoughts. I can see how BOM management will evolve…
As a complement, even if more and more of the diversity of a product is managed at the software level…
1) A wiring diagram stores information (wires between ports of the electrical components) that does not exist in most of…
BOM has NEVER been the sole "master" of the Product. The DEFINITION FILE is ! For example the wiring of…
Interesting discussion about part numbers and where they originate. Though there seems to be consensus about the EBOM and MBOM,…