Part management is stuck between PLM and ERP

September 11, 2014

plm-erp-part-management

Few days ago, the discussion about PLM revenue model took me into part management route. This is not entirely related to revenue and business models, but my readers mentioned part cost reduction as one of the most visible ways to present PLM ROI. I have to agree, to manage parts is a critical element of overall product development and manufacturing process. Part management is an essential function of every manufacturing company. And… probably one of the most confusing ones. Design parts, manufacturing parts, suppliers, spare parts, manufacturing, supply chain, SKUs… The list of topics that come to mind when you think about Part Management is enormous.

Today, I want to speak about one aspect of part management – interplay between PLM and ERP systems. Usually, PLM and ERP systems are presented by vendors and advisers as a complementary systems. PLM focus is product definition. ERP focus is manufacturing. Despite that role-play, for the last decade, PLM and ERP systems developed significant amount of out-of-the-box functional overlap.

Part management is one of the areas where interplay between PLM and ERP is very demanded. The traditional focus of ERP on part ordering brings ERP part management in a focus of manufacturing planning process. From the other side, product definition is largely done by PLM system and therefore, on a conceptual level, PLM is responsible for initial BOM setup, drawings and other part related documentation.

There are lot of grey zones between PLM and ERP functionality. These areas are very visible in the manufacturing process setup and initial production stage. Also, it depends on manufacturing type (CTO, ETO, MTO), complexity of supply chain and other factors usually related to a specific company – geographical location, speed of lifecycle, etc.

Another grey zone between PLM and ERP is related to early lifecycle stages (definition) and late lifecycle stages (maintenance, support and post-production). These functionality is suffering from lack of information availability between systems. The philosophy of ERP is to focus on ordering transactions. Serial numbers and post production evolution cannot be managed in ERP. On the opposite side, date effiectivity and other manufacturing aspects of BOM can be hardly managed in a typical PLM implementation.

As I mention in the beginning, effective part management across the product lifecycle can result in significant cost reduction. I can see two main sources of cost optimization – 1/ redundant part cost and 2/ part rationalization. Here are some examples of product functionality that can help

- Part classification available across product lifecycle, including early design stages.

- Mechanisms to support part re-use such as search, where-use and other advanced BOM tools

- Approved manufacturers and suppliers list availability in PLM system

- Advanced BOM tools enabling part rationalization

- Other part, suppliers and manufacturers optimization methods

However, here a problem. The functionality I described above requires very tight interoperability level between enterprise systems responsible for product definition, engineering, manufacturing and supply chain. More specifically, it requires tight integration of part and BOM management functions in both PLM and ERP. The commitment for such integration is a hard decision for many companies. Complexity, cost, legacy tools, product updates, corporate politics – this is only a very short list of factors preventing companies from implementing efficient part management.

What is my conclusion? Part management functionality is crossing enterprise systems and departments in every manufacturing company. As a result of that, part management literally stuck between product design, engineering and manufacturing. The potential to streamline part management process is huge and can be a source of significant cost reduction. Just my thoughts…

Best, Oleg


PLM, ERP and the death of over the wall engineering

July 31, 2014

plm-erp-death-of-thraw-over-the-wall-engineering

Do you remember "throw over the wall of manufacturing" statement? This is a traditional engineering world. Pretty much sequential. Engineers are doing their job and throw it over the wall to the next stage. Traditional manufacturing was driven by sales forecast. This is was the world that formed a traditional domains of PDM/PLM and ERP. The engineering job was a black box – product design delivered to manufacturing. Manufacturing people supposed to take design and make it work to production. The processes required lots of back and forth communication. The result you know – skyrocketing cost of change requests, suboptimal design and after all production delays.

There are lot of changes in manufacturing environment these days. One of the most interesting example is growing number of smaller manufacturing companies / startups. I wrote about that few months ago in my post – Why Kickstarter projects need PLM? Today, I want to speak more about that. LineShapeSpace article – Manufacturing Inventory Management: How Much Inventory Do You Need? caught my attention. The question sounds obvious. However, article speaks about looking on inventory from completely different perspective – engineering and growth.

Growth is an essential part of every startup. This is probably one and the most important goal to stay focused on. However, the specific part of manufacturing company is the cost of parts and size of the inventory. To hack the growth path is not simple. To go on the wrong path means to literally to die. Here is my favorite passage from the article

This mismatch is expensive. It usually means high inventory carrying costs while you chase down a lot of little customers and invest resources into getting—and keeping—their relatively small orders. The inverse relationship impacts cash flow and energy level significantly, as well as your ability to feed yourself. Long term, this kind of business will most likely be a hobby, not something that sustains you, absent significant investment or luck.

In order to develop a successful product and find a right inventor path, you need to re-think a traditional engineering-manufacturing process. No more over the wall process. You need to design for optimal manufacturing, sourcing, inventory and many other factors. Which means engineering and manufacturing team to work together. My hunch, there is no traditional PLM/ERP boundary any more. Here is another quote to emphasize that:

“We used every fancy prototyping technology, investigated multiple production scenarios, and ultimately landed our production with great manufacturing partners near Hong Kong…utilizing ‘traditional manufacturing’ for production [was] an ordeal to set up, but yields quality, repeatable parts thereafter. The decision to move at this scale of production required that we grow a global sales and fulfillment network.

That wasn’t exactly an ambition for a first our product…but it’s certainly an interesting, if occasionally harrowing, game.” The takeaway from all of this? Do your best to match the inventory risk to your channel risk. It’s a lot easier, faster, and cheaper to go back to the design drawing board than it is to return a container ship to China.

What is my conclusion? We are going to see the world of manufacturing changing in front of us these days. It may change (and probably already changing) the traditional engineering, production planning and manufacturing boundaries. What was true in an old PLM/ERP world will change. The new forms of manufacturing will require re-thinking of current software. Interesting time for PLM and ERP analysts, product managers and vendors. Just my thoughts…

Best, Oleg


PLM users won’t move to the cloud because of cost

May 13, 2014

cloud-adoption-erp-plm

ERP is a long time PLM rival for dominance in manufacturing enterprise organizations. I’m sure you are familiar with the the following discussion topics – what are roles of ERP and PLM in product development process, BOM ownership, enterprise data management, visibility to CIO, etc.

However, here is a new one – cloud. It looks like PLM and ERP will be competing on the speed of cloud adoption. Surprised? Navigate to the following link to read Cloud ERP replacement doubled last year to 24% – Forrester article by Diginomica. Article references Forester research Application Adoption Trends: The Rise Of SaaS speaking about sudden raise of cloud (SaaS) adoption.

Here is my favorite passage from the Diginomica post:

In The Rise Of SaaS, author Paul Hamerman, vice president and principal analyst for application development and delivery, states that cost has become secondary to agility and speed as a motive for SaaS adoption. The top drivers cited by respondents included business agility, speed of implementation and faster delivery of new functionality. He recommends his readers prepare for a number of changes in the way they support business applications, including a shift in perceptions of what counts as legacy:

The new legacy systems are licensed, premises-based applications that are typically customized and difficult to upgrade. As better and better SaaS options become available, look to replace these systems with more flexible and sustainable SaaS solutions.

The key message – it is not about cost, but about agility and speed of cloud solution adoption by enterprise organizations. It reminded me my 2 years old article – Will ERP be on the cloud ahead of PLM? PLM vendors are coming to the cloud and it looks like almost every PLM vendor today has their "own version of cloud PLM". However, can PLM vendors expect a hockey stick in the level of cloud PLM adoption? This is a good question to ask these days.

It seems like PLM vendors got the first part of SaaS – how to cut IT, installation and update cost. This is where newcomers and existing PDM/PLM vendors are clearly shining these days. However, there is a second part – how to make organization to adopt PLM development processes supported by cloud PLM faster? This is a place where cloud PLM is not very much different from "before cloud" PLM, in my view. This process is still long, requires lots of communication with customer including services and deployment. It is business transformation that usually takes so long and requires too many resources and time.

What is my conclusion? Money is not an issue for business. Time is the issue. What I can hear all the time – manufacturing companies have no problem to pay for PLM solutions. The problem is in the way PLM solutions are implemented, speed of business transformation and solution adoption. This is a place where PLM vendors should look for future cloud PLM hockey-stick moment. Just my thoughts…

Best, Oleg

pic credit to Diginomica


Why BOM Management Is Complex?

May 12, 2014

bom-complexity-manufacturing

My last post about Manufacturing BOM raised few interesting comments online and offline. One of them by Jos Voskuil was pretty straightforward – "What is a big deal about MBM"? Jos pointed me on his earlier post – Where is MBOM? This post as well as few other articles I posted earlier – Why companies are not ready for single BOM? and BOM 101: 5 Don’ts for BOM management made me think why BOM is so complex. I wanted to share these reasons and ask your opinion. Here are my top 3 list of issues that are leading to significant BOM management complexity: 1- Items/Parts identification; 2- Views; 3- Synchronizations. Let me go and explain more specifically what I mean.

1 – Item / Part Identification

Item Master. Item. Part. Assembly. Product. You name it… But whatever you call it, you come down to the way (and format) to identify Parts. Part number is probably the simplest wayto identify things in product design, manufacturing and support. The next question – what Part Number? Things are simple only on the surface. As soon as you dig inside, you find yourself surrounded by manufacturing part numbers, design parts, suppliers part numbers, support parts and many others. The information about them resides in multiple data databases, spreadsheets and systems.

2- Views (or Product Views or BOM Views)

You may think about bill of material as a list of parts and everything else you need to make a product. However, very fast it gets complicated with product configurations, manufacturing information, suppliers, As-built BOM and maintenance parts. To differentiate and manage all this information is not a simple task.

3- Synchronizations.

As I mentioned before, bill of material information (multiple BOMs) are usually managed by different systems. Often (in case of PLM) multiple BOMs are managed by PLM system itself. Now think about change processes and updates. Each one generates a sequence of updates and dependent operations that needs to be done to synchronize BOMs and keep them in a consistent status. Indeed, one of the most complex tasks in BOM management.

What is my conclusion? BOM is not simple thing as you might think from the beginning. To keep system in sync with diversity of data and processes takes time and effort. Variety of product development and manufacturing approaches, global deployment, etc. How to overcome the complexity of BOM management? Look forward to learn about BOM management complexities you are facing developing and implementing BOM management solutions.

Best, Oleg


PLM Downstream Usage and Future Information Rivers

May 5, 2014

plm-business-data-lake

PLM downstream usage is a popular and well-known topic. Speak to anybody in PLM community about how to implement PLM beyond engineering department. You can easy discover the value of information located in PLM system for many users in enterprise and beyond. The perceived value of data is very high. However, PLM is consistency failing to capture downstream users. Among diverse set of reasons, I’d like to pickup 3 most visible – complexity, cost of licenses and misalignment with enterprise data management systems and strategies. The last one is specially interesting. PLM is traditionally perceived as engineering system, which is not visible on CIO level. Opposite to that, ERP and Data Warehouse (DW) solutions are traditional candidates to keep and share information. However, the life is not as sunny as you might think.

The following slideshare presentation caught my attention over the weekend – Changing the Paradigm Rivers of Information instead of data warehousing by Paul Nannetti of Capgemini. One of the key discussion points- how to change the information flow and availability of data in an enterprise organization. The traditional DW (Data Warehousing) approach means to bring all data in a central location in a normalized way. Opposite to that, author speaks about opportunity to provide information on demand to different groups of people using modern big data technologies. Here are few passages from the slide deck:

Changing the flow. Why IT needs to stop pushing back against local business views and start enabling them. Traditional DW approaches satisfy corporate needs but leave most users without the information they need 9 out of 10 said that they would have made better decisions in the past 3 years if they’d had all the relevant information. Changing the flow Enterprise Data Warehouse Business Data Lake BIM Changing the Paradigm. Retrospective to Predictive: Shifting BI from retrospective analysis to delivering insight at the point of action.

The following slides presents DW problem and future paradigm shift in how information will flow in the enterprise.

enterprise-dw-problem

from-enterprise-dw-to-rivers-of-information

I found the idea of ‘business data lake’ compelling. The three main enterprise system players – ERP, CRM and PLM will be trying to influence they way information will be delivered to this data lake as well as flowing downstream. It is clear that some modern technological approaches in data management will be mobilized to make it work. Big data Hadoop is one of them. Another aspect is changing landscape of data storage, data modeling and data delivery mechanisms. Store all data, because storage is cheap can be a new approach these days.

What is my conclusion? The changes in technologies and paradigms of data organization can be an opportunity for PLM system to get more influence outside of engineering. Existing DW approach is expensive. Existing major enterprise systems such as ERP are not flexible enough to provide a platform for "business data lakes". By having access to existing data assets – design, engineering, supply chain and manufacturing, PLM system can facilitate better downstream information usage and wider adoption. Just my thoughts…

Best, Oleg

Pictures credit to Capgemini slideshare presentation.


Why so hard to break PLM into components?

April 9, 2014

plm-componentizing

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

BOM-data-lifecycle-process

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


Follow

Get every new post delivered to your Inbox.

Join 250 other followers