Why so hard to break PLM into components?

April 9, 2014


Product Lifecycle Management is not a software. It is business strategy and approach. One of my blog readers mentioned that in the discussion few days ago. Nevertheless, manufacturing companies are usually talking about PLM systems and platforms as something solid and unbreakable. The same picture you can see when looking on PLM online marketing materials and brochures. Despite recent changes in broad PLM acceptance and value proposition, companies still see PLM as a software mostly for engineering domain or driven by engineering IT. One of the dreams many PLM vendors developed for the last decade is how to reach the C-level management such as CIO and engineering executives. In other words, how to reach ERP level of acceptance and awareness.

Earlier today, my attention was caught by Toolbox.com article about modern ERP trends. Navigate to read ERP Trends: Shifting from Big ERP Systems to Componentized ERP Environments. Cloud is changing the face of ERP. The technology is breaking ERP into pieces. One of the results – two tiers ERP configuration. Here is the explanation I captured from the article.

Because of the coinciding innovations in cloud technology, instead of deploying and implementing traditional ERP infrastructure, organizations started adopting a two-tier, or hybrid, ERP model. Two-tier ERP is a method of integrating multiple ERP systems simultaneously. For instance, an organization may run a legacy ERP system at the corporate level while running a separate ERP system or systems, such as cloud ERP, at a subsidiary or division level for back-office processes that have different requirements. To facilitate the adoption of the two-tier methodology, vendors increasingly opened core databases and application programming interfaces and provided customization tools, thus spurring the advent of self-contained, functional ERP components or modules.

So, what does it mean for existing and future PLM strategies and products. More specifically, it made me think about the possibility to break large and heavy PLM platforms into sets of re-usable components. ERP componentizing example speaks about splitting ERP system into modules such as – supply chain, financial, management, human resources. So what potential PLM split can look like? I can see two possible ways here – business process and lifecycle. The first one is something probably we can see a lot in existing PLM platforms. Requirement management, Design Collaboration, Change Management, NPI, etc. I’ve been thinking about Lifecycle as an alternative approach to the traditional business process oriented approach. Lifeycle approach means to develop applications to serve people with their everyday tasks based on maturity of product in the development or services. Think about manufacturing assembly line. Different tools and operations are applied to manufacturing product to bring it to life. Now think about PLM and software tools. PLM components will be used to create product (actually product data and related information).

Toolbox article also speaks about difficulties of componentized approach. The main one is a potential growth of TCO because of the need to integrated data coming from different modules. Here is the passage I specially liked:

The data from the second-tier cloud ERP or modules typically require normalization to integrate with the legacy ERP system at the corporate level. Although direct cost is associated with master data management to ensure consistency and no redundancy, by extending the life of the legacy system, the intention is to reduce the total cost of ownership (TCO) while meeting additional needs for flexibility and functionality. However, the shorter duration of implementing and deploying a two-tier ERP model can actually lead to increased TCO if the indirect costs, such as training, hiring staff, and vendor support, are not taken into to account, as well.

The same problem will arise if we try to break PLM into components. With no solid data foundation, ability to bring and integrate various PLM components will be questionable. The integration cost will skyrocket. Compatibility between PLM components versions will make it even harder. Nevertheless, I can see growing business requirements, customers’ demand and shorter lifecycle for software products as something that will drive future PLM technological changes. Componentizing will be one of them.

What is my conclusion? To break large and heavy PLM suites into configurable and flexible components is an interesting opportunity to satisfy today’s dynamic business reality. However, two fundamental technologies are required to make it happen – scalable open data platform and reliable integration technologies. Just my thoughts…

Best, Oleg

Bill of Materials (BOM) Management: Data, Lifecycle, Process

April 2, 2014


In my recent post about bill of materials – Bill of Materials (BOM): process or technology challenge? I touched the variety of topics related to BOM organization – multiple BOMs and need to manage BOM located in different systems. My main question at the post was around how to make the work with multiple BOMs easier? The problem is tough and the answer is not easy and straightforward. While I was googling the internet to find what others think about this problem, my attention caught TeamCenter PLM blog post – Bill of Material Lifecycle. This posts presents multiple BOMs as a result of changes in the product lifecycle – design, manufacturing, service. Here is a passage I captured:

It is interesting to discuss on BOM lifecycle and its evolution from conceptual stage to full fledge manufactured product to maintenance. In this blog I will explain through life cycle of BOM across the product life cycle done as in house development. The BOM lifecycle can varies based on overall process of company for example some company might only manufacture as order hence they As Build design BOM and they directly CREATE Manufacturing BOM from it.

All together, it made me think that concepts of data, lifecycle and process is often can create a confusion and overlap. I want to clarify these concepts and present how they can be combined together to manage single BOM in the organization.

1- Data

Data is the most fundamental part of Bill of Materials. It combined from data about product, assemblies, parts and relationships between them. Fundamentally, assemblies and components are connected together to form the result data set representing a product. This data set can be presented in many ways – tabular, hierarchical and many other forms (eg. graph). Data about parts leads us to the place where information about product, assemblies, components, supplies and manufacturers is managed. This information can reside into one of the following systems – CAD, PDM, PLM, ERP, SCM and others.

2- Lifecycle

Lifecycle defines the difference between bill of materials of the same product, but associated with different product development periods (stages). Here is the example of some typical stages – concept, design, manufacturing, service. However, these stages are not the same for many companies and can reflect industry, specific business practices, regulation and many other aspects. It is very important to capture relationships between Bill of Materials of the same product (assembly) in different lifecycle stages. Missing lifecycle stage connection can cause a lost of very important product lifecycle information and product development traceability. In some regulated industries such

3- Process

Process is a set of activities that defines Bill of Materials data as well as changes in a lifecycle. Sometimes process can be very informal- save of assembly and parts using design system. It will product design BOM data. However, with the complexity of product development and specific organization, some processes are including changes of data, lifecycle stages as well as people involvement. If you think about ECO process, it might change few bill of materials, lifecycle stages as well as product/part information.

What is my conclusion? The problem of bill of materials management must be separated into three distinct problems: 1/ how to create data with BOM? 2/ how to control product dev stages and differentiate the same BOM across the lifecyle; 3/ how to provide tools to manage process and people to work with data and stages. All together, the problem is complicated. However, separated into these pieces it can help you to build a strategy for your BOM management regardless on tools you are going to use. Just my thoughts…

Best, Oleg

Manufacturing future will depend on solving old PLM/ERP integration problems

March 18, 2014


How to integrated PLM and ERP? This is such an old topic. I’ve been discussing it on the blog so many times. Here are just few of them – The ugly truth about PLM/ERP integration volleyball, BOM and CAD-PDM-PLM-ERP Integration Challenges, 3 steps how to put PLM / ERP each in their place. The good news – the importance of PLM/ERP integration is well known and recognized by everybody. The bad news – it sounds like not solved problem after all years and attempts.

My attention caught last year Wired article – The ‘Smarter’ Manufacturing Enterprise. Article speaks about communicating between devices and people in manufacturing organization and extended enterprise. The common goal – fast production. Speed and efficiency are two factors that rule modern manufacturing and looks like will be even more dominant factors in the future.

However, every manufacturing today is managed by multiple enterprise systems. Communication and integration between these systems will be a show stopper to make the future smart manufacturing dream into reality. Here is my favorite passage from the article.

Why are serious people talking about this now? Because for the first time, the essential technologies that make it possible finally exist at all levels, across not only the factory, but up and down the entire enterprise. Intelligence permeates every corner of today’s manufacturing enterprise, from the RFID tag on the part, to the machine that moves it on the production line, to the truck that hauls it away. Now the trick is to make all these systems work in harmony as one.

In other words, the fundamental systems of manufacturing — enterprise resource planning (ERP), product lifecycle management (PLM), manufacturing execution systems (MES) and industrial automation—have to operate together, seamlessly, like a single well-oiled machine.

It made me think again that current PLM/ERP integration model with complicated data synchronization is bad and won’t work for future of manufacturing. It is heavily relies on the idea of data synchronization and replication between systems. It is too costly to implement and maintain. It is sometimes too slow and requires lots of data manipulation and transformation.

What is my conclusion? Previous siloed enterprise models used data ownership as one of the fundamental models. To own data and allow access in a silo (such as PLM, ERP or MES) was one of the first priorities. Today and tomorrow the speed of communication will be more important. To make collaboration and communication fast will be a criteria for future models to survive. For manufacturing companies and PLM vendors today it means one simple thing – to fix old PLM/ERP integration problems. Just my thoughts…

Best, Oleg

Part and Document Management: Why is it Complex?

March 8, 2014


Parts and Documents are two different objects in engineering, product development and manufacturing. While “part” usually represents physical object, “document” usually represents specification, drawing or 3D model of part. Even it it sounds obvious, Document and Part management is not an easy and simple task.

In my post – How to manage Document versions, revisions and Part numbers, I’ve been mostly speaking about the need to have separate numbers for documents and parts. I also mentioned that bad practice to use the same numbers for both document and part, can lead to significant complexity and mistakes. At the same to implement a system or multiple system to manage Documents and Parts is complicated. Below I described potential three typical configurations you may find in companies related to document and parts management.


Even PDM is not very new technology, you can still see many companies that not using PDM. If this is a case, you have a good chance to see documents (CAD and non-CAD) spread out in the network and shared drives. Without centralized document management system, a company is creating numbering convention how to provide document numbers. A good chance that you will see lots of Excel spreadsheets to be used for Parts and BOM management. Very often, a company will be using similar number convention for parts and mix it together with usage of OEM and supplier part numbers. You can also see homegrown system to manage Part Numbers in a separate database.


This is very typical situation where engineering and manufacturing are splitting responsibilities into silos. Engineering department is using PDM system (very often from the same vendor as CAD system) and manufacturing (as well as rest of the company) is using ERP system. Within this schema, PDM system is taking control of documents. Document numbers usually generated by PDM system according to predefined naming convention. Item masters and parts are managed by ERP. The complexity of this model is to link between documents in PDM system and parts/BOMs in ERP system. In most of the cases, the integration between them is manual or using batch import/ export procedures. Optionally, PDM system can manage parts (typically engineering parts).


It is not unusual to see both PDM and PLM systems co-exit in the same company. Similar configuration can be achieved by combination of PLM and ERP system. In the last case, PDM module is part of broader PLM offering. The specific characteristic of this type of environment is management of parts and engineering BOMs in PLM system. Sometimes, you can see PLM systems is responsible also for manufacturing BOM management. This configuration provides the most consistent way to interlink between Documents and Parts. Both numbers are available in PLM system which can use them. The weak part of this configuration is complexity of integration between PDM/PLM and ERP. Synchronization of Part Numbers and Document Numbers among all systems is a challenge that may potentially lead to data inconsistency.

What is my conclusion? The information about documents and parts is located across organizational departments and systems. At the same time, to manage them in a consistent way is very important. Regardless on the number of systems and the way to manage Document Numbers and Part Numbers to keep them separate and maintain linkage between them is the first priority. Just my thoughts…

Best, Oleg

Does PLM have a chance to win over ERP dominant position?

March 5, 2014


PLM and ERP have long "love and hate" relationships in manufacturing world. You can find lots of materials speaking about complementary roles of PLM and ERP. This is of course true. However, integration between PLM and ERP never been easy. Despite many technologies, systems and solutions available on the market, customers are often skeptical about ease of integration between these systems. My hunch, ERP and PLM are clashing over the data that both system supposed to manage such as Bill of Materials. One of my older articles speaks about The ugly truth about PLM-ERP monkey volleyball. I think beyond specific data and process management aspects both ERP and PLM vendors are competing for "CIO priority" in the company.

In my view, the net-net after almost two decades of competition: ERP more often is taking dominant position in the company. At the same time, PDM and PLM have more challenging position to expand system usage beyond engineering and R&D organizations downstream. The situation is obviously different between larger and smaller companies. The problem of integration between ERP and PLM is dominant for large OEMs and suppliers. The problem of PLM cost and decision to use both PLM and ERP among departments is more critical for smaller manufacturers.

Cloud computing is one of the largest and most disruptive technological trends these days. Cloud certainly disrupted many existing domains. We can see a lot of cloud disruption in enterprise domain these days. CMSWire article Will Disruptive Cloud Computing Kill Enterprise Resource Planning? is specifically focusing on how cloud tech can disrupt ERP domain. Read the article and make your opinion. Article references Gartner study – Predicts 2014: The Rise of the Postmodern ERP and Enterprise Applications World (you need to pay to get access). Here is an interesting passage:

According to the report the problems that are impacting on ERP are historic. In fact, they go back nearly 20 years. From the mid-1990s, enterprises invested in ERP solutions because they addressed problems that had been inherited from the 1980s, when systems were not reliable enough and did not integrate with newer applications. However, many of these service provides went beyond implementations. They provided extensive customizations on top of the work that was outlined on the licenses, with many setting up software factories with thousands of programmers to provide those customizations. The net result of 15 years of continuous customization, the report added, are ERP implementations that are now "arthritic," incredibly slow and expensive to change

Gartner is also making prediction about future development of ERP solutions and transforming of large monolithic suites into set of smaller and flexible application services:

Longer term, over the next 10 years and more, we envision a scenario where more of the market ‘flips’ to the cloud. Instead of having on-premises core solutions that are complemented by innovation or differentiating processes being supported in the cloud, some organizations will move all their ERP functionality to the cloud. These won’t be single vendor mega-suites but instead will be loosely coupled suites of cloud functionality,” Nigel Rayner, co-author of the report said.

This prediction made me think about potential transformation in the balance between PLM and ERP systems (or maybe services in the future). The focus on smaller adaptive services can give an opportunity to PLM vendors to provide solutions in functional areas that raised controversy and competition in the past – change management, item master management, BOM management and few others. By providing new modern cloud manufacturing applications PLM vendors will be able to takeover inflexible legacy ERP suites and integrate with other ERP services.

What is my conclusion? The disruption time is good for changes and revisiting of old status quo and decisions. The historical balance of PLM and ERP is one of them. By providing flexible and agile product lfiecyle services, existing PLM vendors and newcomers can win over the existing status in many manufacturing companies. Just my thoughts…

Best, Oleg

The Role of PLM in Hollow Corporations

February 5, 2014


Do you know what means "hollow corporation"? My readers from UK and Europe should be familiar with the term. This is a model for a company that outsource majority of their production activity. A compatible U.S. buzzword is "virtual business". There are few references defining what is "hollow corporation". Business glossary here defines it as a business in which "important elements are outsourced to subcontractors". Ten years old article brings the main two drivers behind the Hollow Corporations trend – globalization and technology. Here is the passage I liked:

Component tasks can be performed anywhere in the world. People in diverse parts of the globe working on common technology platforms provided by Microsoft and Google can now share work product seamlessly. They can communicate easily and cheaply across long distances due to undersea fiber optic cables. Through technology, distance between workers is no longer the limitation it was once.

However, I can see virtual corporation trend goes much beyond tech companies such as Google and Microsoft. Wikipedia link to "virtual business" brings another set of definitions I found useful. Among few of them "virtual enterprise" is the most interesting:

A virtual enterprise is a network of independent companies—suppliers, customers, competitors, linked by information technology to share skills, costs, and access to one another’s markets. Such organizations are usually formed on the basis of a cooperative agreement with little or no hierarchy or vertical integration. This flexible structure minimizes the impact of the agreement on the participants’ individual organizations and facilitates adding new participants with new skills and resources. Such arrangements are usually temporary and dissolve once a common goal is achieved. A virtual enterprise is rarely associated with an independent legal corporation or brick and mortar identity of its own.

The pioneers of virtual business came from internet space. You may think about Amazon and other virtual booksellers as an example of very successful virtual businesses connecting buyers and sellers only by using technologies and internet. However, I can see manufacturing companies are actively embracing virtual corporation space too. In my view, expression "hollow corporation" is getting new meaning these days in manufacturing world. Company like Nike took a new type of relationships with suppliers and created a new type of business. Many other manufacturers across the globe took the concept of delivering new innovative products combined with high efficiency of supply chain networks.

The last fact made me think about future role of PLM in such type of corporations. Typical vertically integrated manufacturing company is centralized around manufacturing planning control (MPC) system. This is a central place and main system in manufacturing universe. These days MPC functions are typically implemented as part of commercial ERP systems. The main purpose of vertical integration is to put manufactured products out of production lines. With new concept of virtual corporations, the manufacturing center of gravity is moving towards suppliers and outsource manufacturers. It puts product development in focus and makes a lot of sense to bring PLM system to manage design, product portfolios, configurations and coordinate it with customer demand and customer focus.

What is my conclusion? Industry landscape is changing these days and it brings new requirements for computer systems in engineering and manufacturing. Vertically integrated manufacturing model is changing towards more flexible networks that can react fast on customer demands. I can see a clear trend towards optimizing supply chain networks and outsource manufacturing facilities. Customers want more specialized products, lower cost and fast delivery. It brings new challenges for manufacturing and opportunities for PLM systems to establish new type of product development. Just my thoughts…

Best, Oleg

PLM, CMMS and BOM Hot Potato

January 8, 2014


There is no person in manufacturing universe that can underestimate the importance of right Bill of Material information. However, I can see people responsible for material management in a special league for the context of material management and BOM.

Doug Wallace of Life Cycle Engineering (www.lce.com) speaks exactly about that in his article The importance of an equipment BOM. I found this writeup quite interesting. Here is the passage that defines the importance of BOM:

The main purpose of the materials management organization is to provide the "right parts in the right quantities at the right time." But where do those material requirements come from? Whether or not demand is predictable, whether the materials are for production or maintenance, the requirements are usually generated from a bill of material (BOM). Without a complete and accurate BOM, decisions regarding material planning and replenishment are often made in a vacuum, resulting in excess inventory, stockouts, expediting charges and expensive downtime.

At the same time, I can see a question here – where is that material requirements and BOM information is coming from? Where is this accurate Bill of Material is located? PLM system is one potential candidate alongside with more traditional MRP/ERP system. I debated this topic last year in my article – Will PLM management enterprise BOM? Shaun Snapp of smfocus has an interesting perspective of separate system taking care of all Bill of Materials management aspects. He debates it on his BOM blog here.

Doug’s article made me think about confusion in the way different systems represents and required data related to Bill of Material management. For example, article provides a detailed information about what information should be on (E)BOM – Part Number, Description, Quantity, UoM, Manufacturer, MPN, Supplier related information including Supplier’s Part Number.

This information can be managed by PLM/BOM solution as well as PDM solution combined with design system. I’m sure Excel spreadsheet from engineering department can provide it as well. Since the context of discussion is maintenance and CMMS, the information can come from ERP/MRP system. In my view, the confusion comes even in the name – EBOM. Some people can think about (Engineering)BOM, another group can think about (Equipment)BOM as it was presented in the article. I’m sure some computer geeks can think about (Electronic)BOM too :). Article summary provides some hints on the engineering roots for the BOM as well as importance of collaboration beyond silos:

As a rule, the RE is primarily responsible for providing initial EBOM information and all engineering-driven changes. The planner is responsible for ensuring EBOM accuracy. But the key to overall EBOM effectiveness is to recognize that data creation and maintenance is a collaborative process that requires teamwork and communication.

What is my conclusion? In my view, there is a confusion around BOM ownership and responsibilities of providing a correct BOM information. The level of fragmentation of BOM information is too high. Organization is often handle BOM as a "hot potato" changing hands of different organizations and finally thrown over the manufacturing wall. It introduces a problem that future lead to higher product product cost, expensive maintenance and operation. Just my thoughts…

Best, Oleg

SMB business is tough… and not only for PLM vendors

October 22, 2013


PLM for small companies is long time debated topic. The origins of PLM business are going deep into businesses of large companies in defense, aerospace and automotive industries. Nevertheless, PLM companies for the last 10-15 years are trying to crack down "PLM for SMB" story with variable success. Sometimes PLM solutions for small companies are reminding me a fashion show in Paris – one season PLM for SMB is trending, next one is not. One of the most visible PLM SMB shutdowns was PTC retiring their Windchill ProductPoint.

Another interesting SMB-related retirement announcement just came few days ago from SAP. German ERP giant is retiring their cloud initiative focused on small businesses – SAP Business By Design. ZDNet announced about it here. Article provides some information about why Business By Design was halted. Here is a passage from the article:

ByDesign is intended to serve "mid-market" companies that are smaller than large enterprises but larger than small- and medium-sized businesses. At launch, executives projected that the $4 billion software suite would generate $1 billion in annual revenue. Yet it is expected to generate no more than $35 million this year, according to Wirtschaftswoche.

Nevertheless, SAP Business By Design rival NetSuite seems to be doing well. Recently NetSuite signed partnership agreement with Autodesk about combined sales of NetSuite and Autodesk PLM360. Other PLM vendors are also getting back to be more focused on SMB market. Few months ago, Siemens PLM announced future expanding of SolidEdge SP product. PTC is coming with new SMB initiative – Windchill PDM Essentials. Arena Solutions is keeping their specialty in cloud BOM and PLM, in my view, also focusing on small companies.

What is my conclusion? 60-80% of CAD seats in industry is not connected to any data management solution. That was true few years ago. My hunch is that CAD/PLM companies is doing everything possible to change that status. It came down as an aggressive SMB-marketing of existing "scaled down" PLM solutions as well as introducing of new opportunities by leveraging cloud and open source. The biggest competition in SMB space is "status quo". At the end of the day, if a company can make things done by using Excel, Office and email, you need to provide a very attractive solution to change that. Small doesn’t mean simple. SMB business is a complicated and tough. Price and implementation efforts are still two key elements that every vendors struggle when trying to provide a viable solution for SMB. Just my thoughts…

Best, Oleg

BOM: Apple of Discord between PLM and ERP?

September 17, 2013

BOM Management. Multiple BOM Views. These topic are always drives lots of discussion in a real life and online. There is no question about importance of BOM in product development, engineering, manufacturing… Literally, you cannot do anything without Bill of Materials.

Few weeks ago, I came with the topic that generated a very good and healthy discussion – Will PLM Manage Enterprise BOM? A bigger part of the discussion happened in PLM LinkedIn group. You need to have LinkedIn user to access that. In a nutshell, the discussion was about an influence PLM and ERP both have on BOM management in the organization. The topic is not restricted to PLM and ERP. However, it is clear that PLM and ERP are playing major roles in how BOM managed in organization and how enterprise BOM management solution can be architected.

BOM Golden Rule

I’m sure you are familiar with Golden Rule. Satirical definition of this rule says “Whoever has the gold, makes the rules“. Here is manufacturing definition of the rule – “Whoever owns the BOM, makes the rules“. This is very true in many aspects and it explains a lot of what happens in every manufacturing organization in terms of how enterprise systems are positioned. They people work in the majority of organizations these days can be summarized as following – don’t touch my BOM. You can think about design / engineering, manufacturing, sales, supply, plant and many others. Every department or organization is creating their own BOM and then trying to synchronize it during product development process with other BOMs.

I’ve seen multiple attempts to create an alignment between various enterprise systems. Here is an example of product vs. transactional alignment between PLM and ERP provided by one of my blogging buddies – Edward Lopategui from E[E] blog. I took the following passage from LinkedIn discussion:

I think part of the problem is the divide between PLM and ERP, where PLM has always been product focused while ERP is transaction focused. While few dispute that PLM has the superior BOM capability, the ERP transactional dependencies perpetuate the legacy need to continually instance MBOM on the ERP side. And since PLM does not have an acceptable equivalent of those transactional capabilities, expect the divide to continue into the foreseeable future.

You can explain what are differences between BOM in PLM and ERP from product, system and technological standpoint. However, the political influence in organization can make this type of effort meaningless. One of my permanent discussion opponents, Dr. Michael Grieves (Consultant at NASA and author of Product Lifecycle Management: Driving the Next Generation of Lean Thinking book) provided the examples of factors here:

Where the MBOM resides is going to be dependent on both technical, political, and legacy factors. Technical factors include the complexity of the product, how often the MBOM changes and who drives those changes, whether an MES system exists,… Political factors include whether the strategic direction is toward ERP or PLM. Legacy factors include what systems are currently in place for MBOM control. Compounding these issues is that ERP companies are moving into PLM solution spaces and vice-versa.


From technical standpoint, it is relatively easy to explain the difference between EBOM and MBOM. The first (EBOM) represents they way product is designed (structure, models, functionality, configurations, etc.) The variety of characteristics are depending on the type of manufacturing and processes. Manufacturing BOM defines how product will be produced (including aspects of material ordering, routing, different manufacturing plants, etc.).

EBOM and MBOM are not entirely different but data structures and attributes used in both are often not overlapping. Some engineering attributes and structures are not relevant for MBOM (or cannot be stored using MRP/ERP systems). On the other sides, MBOM information is often irrelevant and not needed for engineers and designers.

The thing that makes everything complicated is a process between these two worlds. The “throw over the wall” manufacturing concept co-exists together with tightly collaborative process of work on EBOM and MBOM. Engineers are requested to provide information about product (EBOM) as early as possible in the development cycle. At the same time, manufacturing planning can get back to engineering in order to finalize and optimize product. Very often, both BOMs (but mainly MBOM) can be used for external planing systems.

What is my conclusion? BOM is one of the most important information pieces in product development. It comes on different stages of development – design, engineering, manufacturing, supply, etc. Because of different reasons – technical, political and organizational, the most widely adopted BOM implementation practice is to split BOM into separate pieces (views) reflecting application domains. At the same time, modern business and manufacturing practices require better integration of processes around BOM. PLM vs. ERP. Engineering BOM vs. Manufacturing BOM. The debates about how to organize them in a better way are heating up in every organization. Just my thoughts…

Best, Oleg

PLM360+NetSuite: Changing the integration game?

May 18, 2013

PLM and ERP integration is not a new topic. Step in the discussion about any PLM implementation and you will come to the topic of PLM+ERP integration in less than 5 minutes. Integration between two enterprise software suites is usually a complicated tasks which involves lots of planning, adjustments and hard-wiring from both sides.

Cloud software brings a new perspective to PLM / ERP integration domain. Of course, it will not dismiss planning stage. Lots of EPR and PLM planning tasks are still needs to be done. However, cloud integration is simpler. Web APIs and architecture as well as cloud deployment can make integration between cloud products easier. Early stage SaaS products exposed some difficulties in integration. Usage of REST APIs and additional cloud-based integration tools is streamlining integration tasks.

Earlier this week Autodesk and NetSuite announced partnership focused on providing seamless integration between two products – Autodesk PLM360 and NetSuite. You can find press release of the announcement by navigating to the following link. Here is an interesting passage:

The bi-directional integration of these revolutionary cloud technologies gives manufacturers a single, closed-loop solution to accelerate product design and development, reduce risk of errors and delays, streamline supply network collaboration, and gain critical real-time visibility into costing, scheduling, capacity and profitability.

Market research shows that manufacturers are increasingly turning to cloud-based Software-as-a-Service (SaaS) applications to run product development, production, supply chain, order management, financials and other core business applications without the time and cost burden of on-premise software and servers. Gartner predicts that nearly half (47 percent) of manufacturers worldwide will be using or piloting SaaS applications by 2015, up from just 2 percent in 2010.[1]

In the following video, Gavin Davidson and Brian Roepke demonstrate the new integration between NetSuite Manufacturing and Autodesk PLM 360 software at SuiteWorld 2013:

Couple of thoughts about the scenario presented. I found natural to see not only traditional BOM transfer function during the PLM/ERP integration, but also modern social collaboration functions presented by NetSuite. Also, additional cloud-based tools such as Fusion 360 (cloud design CAD) and online cloud simulation tools naturally fit into the scenario.

What is my conclusion? Integration is tough topic. Usually it requires implementation effort and additional services. It looks like cloud software (both ERP and PLM) is about to define a new trend in the ability to establish a different level of integration. Time and customers will show how it will work. Nevertheless, it is clear that cloud vendors are trying to resolve old integration problems in a different way. Just my thoughts…

Best, Oleg

Disclosure: I’m responsible for PLM and Data Management product development at Autodesk.


Get every new post delivered to your Inbox.

Join 218 other followers