PLM, demolishing silos and closed BOM loop

June 24, 2014

bom-closed-loop

Product development and manufacturing is getting more complex every day. The complexity comes from both direction – product definition complexity and globalization in manufacturing, supply and customer experience. As we move towards future cloud software, the importance of data platforms is growing even more. For the last 15-20 years, we are living in a realm of siloed and fragmented parts of business applications. Integration and connectivity heavily relies on integration services and expensive integration toolkits.

PLM vendors understand the importance of broader integration beyond engineering department. We can see it in the strategies and acquisition patterns. The following two examples can show you what I mean. Navigate to the following article by Engineering.com – "Demolish the silos in PLM": Why Dassault’s Bernard Charles believes in the 3D Experience is explaining the vision and strategy of Dassault. The following passage is my favorite:

The zero error BOM (Bill of Materials) demands a zero file solution. 3DEXPERIENCE brings the zero file world into the engineering environment; what we do is to connect directly to product data, not to files”. Every company has a promise to their customers and that promise is eventually realized through a value creation process that touches many different points within an organization. Now, to ensure that a brand promise is consistently and sustainably delivered it has to be managed across the entire enterprise, and we have assembled the necessary IT tools.” He adds that so far PLM has just been about helping companies to develop their products, ”But the world has moved beyond the product; the end-customers are demanding experiences around the product” and the secret of market success is to be able to innovate not only on the product, but also on the experience.

Another example came recently from PTC Live 2014 forum in Boston. The following blog post by Monica Schnitger gives you a very good outline and links to keynotes video recording. However, my attention was caught by another blog by Joe Barkai – Closed Loop PLM. Joe outlines PTC vision to connect important lifecycle tools in a single product lifecycle workflow. Here is the passage explaining that:

While the vision – and company executives acknowledged it’s still a vision rather than a product roadmap – is correct, the tools and “solutions” in PTC’s portfolio are separated by a noncontiguous business strategy (SLM and ThingWorx operate as separate business units), and by the lack of a digital backbone, shared data models, common taxonomies and unified workflows. It will be interesting to see how PTC is going to move from a strategically rich but fragmented portfolio to realizing a connected PLM architecture.

Sooner than later, PLM vendors will come with platform strategies and implementation that connecting complicated product lifecycle. Meantime, engineering, manufacturing, supply and consumer spaces are disconnected and can create some real problems. Few days ago, I stumbled on a very interesting article – Keep a sharp eye on SSD bill of materials by DIGISTOR. The article takes you to the reality of disconnected Bill of Materials between OEM manufacturers, suppliers and consumers. Read the article and draw your opinion. Here is my favorite passage

It appears that manufacturer PNY Technologies has committed the same sin, releasing SSDs with varying BoMs. A TweakTown reader contacted Ramseyer and described how the SSD that the individual purchased did not feature a BoM that matched up with one previously reviewed on the website. According to Ramseyer, that reader bought the PNY product because of his glowing assessment of its performance. Because of the shifting BoM, however, that individual’s SSD did not hit the same benchmarks. A representative from PNY admitted that the company had shipped out SSDs with disparate BoMs, qualifying the move by noting that all of its products fall within "minimum advertised performance levels." When manufacturers neglect to lock down the components within their BoMs, consumers and business users may wind up with a product that doesn’t meet their expectations.

What is my conclusion? To close product lifecycle loop from product requirements to actually physical devices with specific supplied components is a big challenge. It requires significant coordination and integration between applications and data sources. I can see the intent of PLM vendors to come with platforms and solutions. Cloud technologies will play a significant role in the way companies will try to demolish silos and synchronize data across multiple application boundaries. Just my thoughts…

Best, Oleg


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


Manufacturing BOM is the next cool thing in PLM

May 9, 2014

plm-manufacturing-bom-boom

I’ve been doing data management system for the last 20 years. The one thing you learn very fast – 3D and visualization are cool. Data is boring. So, if you want to impress somebody (journalist, analyst, your boss… whoever else) you need to create realistic representation of your future product. And show how to can turn it on the screen of your computer or better on mobile device (the reality of last 3 years). I agree, to see what you mean is cool, especially if you can make it before it will be manufactured. Awesome stuff. It can sell your product before it even exists. CAD/ PLM companies made lots of money selling visualization and rendering products. These days you almost cannot differentiate the video or photo of real car from realistic visualization.

Forget about it, for the moment… Design can be cool. However, important question these days is that – can you really make this product? If yes, than how? How fast? Or even more – can you make a profit after you design, visualize, manufacture and sell your product?

Engineering.com articleThe Next Big Boom in PLM and ERP and the Battle Over mBOM Ownership announced “war alarm” between PLM and ERP companies around manufacturing BOM (MBOM). Article speaks about how important MBOM and Master data management in solving problems such as cost, quality, tooling and many others.

I made me think again about how future of manufacturing will be dependent on solving of old PLM/ERP integration problem. In my view, complicated data synchronization is really bad thing. It leads to complex behavior, user experience and, after all, to product data errors. The question of product data errors is one the disturbs manufacturing companies. Emailing spreadsheet with bill of material won’t make your product development and manufacturing process more efficient. The following passage from engineering.com article is my favorite:

Ashley Morris, a researcher at Cardiff University in the UK, has identified seven root causes of product data errors. The three most important ones are 1/ Inaccurate data entry; 2/ Incorrect data flow between applications; 3/ Duplicate data between systems. Product development teams are all-too-familiar with how these errors occur given the various systems that manage the data. Generally cBOMs (configuration BOMs) and eBOMs (engineering BOMs) are created in the PLM systems, whereas mBOMs (manufacturing BOMs) and sBOMs (service BOMs) emanate from ERP or/and MES systems. But there’s no rule here. Several variants and combinations are “on the map”.

MBOM is tough problem. I identified 4 main reasons why MBOM is hard for PLM. Read my previous article here. In a nutshell, here are four main reasons why MBOM solution is not simple for PLM vendors and service providers:

1- Most PLM systems starts from CAD and Engineering BOM.

2- Engineering and manufacturing people live in different worlds.

3- Synchronization of BOMs is messy by default.

4- For PLM to get data about manufacturing parts is painful.

Despite all these complexities and difficulties, PLM vendors is pushing towards better integration with manufacturing. I really liked the following quote explaining the objective of Bill of Material module by Siemens PLM:

“The objective of this BOM module (TC PMM) is to provide an integrated BOM foundation spanning Engineering, Manufacturing, Prototype and Service domains.” The tight integration to design and manufacturing processes can drive virtual validation of both these process types from a BOM point of view. “With our approach the BOM is documented once and various other BOM’s like mBOM, sBOM, pBOM etc are derived from this core eBOM, without re-documentation.”

So, what it all means for PLM? Bill of Materials (BOM) was always the apple of discord between PLM and ERP. Large companies these days cannot live with PLM and ERP systems. While engineering part of product information resides in PLM system, manufacturing part is managed by ERP. Product cost and quality can often fail between chairs and this situation disturbs manufacturing companies. This is the simplest possible configuration. Sometimes, design and engineering product even more distributed (look on Airbus’ case) – design (CATIA), product configuration (Windchill), manufacturing BOM (SAP). Which brings me back to my thoughts about why companies are not ready for single BOM? Main reasons – specialized tools used by different departments, no agreement between organizations how to manage data in a consistent way, absence of ‘universal’ tools.

What is my conclusion? MBOM is going to be in focus for many manufacturing these days. Efficiency and ability of manufacturing company to execute flawlessly becomes more and more important. Manufacturing environment is highly distributed these days with lots of constraints and dependencies. To design and bring product to market in a short time is a complex task you cannot solve without tools that will help you to synchronize and connect bill of materials. Just my thoughts…

Best, Oleg


Why Excel and Multi-BOM are killing collaboration?

April 22, 2014

excel-multiple-bom

Excel and Bill of Materials. What can be better to start a discussion? One of my favorites blogging buddies and author of eng-eng blog Ed Lopategui hit the button of BOM & Excel discussion in his GrabCAD blog – It’s time to drop Excel BOM. I liked the following passage. It speaks about huge cost involved in management of changes using Excel:

There’s one fundamental constant in all of engineering: change. Aligning with the capability to change quickly and often is crucial in fighting back ever-increasing schedule pressures. Excel BOMs provide no help here. A separate Excel BOM has to be manually synchronized with each design change. It’s usually in this confusion where some of the bigger and most expensive errors tend to happen. Conflicts are common and notoriously difficult to set straight. Recognize that the information in a BOM is every bit as vital as your CAD design, and should be managed accordingly. For the very same reasons you benefit from managing CAD, so should you do the same with a BOM.

Ed’s post took me back five years to my Why do I like my PLM Excel spreadsheets? Excel is super flexible and powerful. However, it comes with cost. I summarized them here – PLM Excel spreadsheets: from odes to woes. Very recently I put a possible recipe how PLM can compete and take over Excel spreadsheets. These are important 3 ingredients – (1) flexible data model, (2) easy customization and (3) flawless user experience.

One of the topics in Ed’s blog, took me far beyond just usage of Excel to edit BOM. It was about how to manage bill of materials between engineering and manufacturing space. Here is the passage:

So far we’ve been talking about BOMs strictly from a design perspective. But the expectation that there can be only one BOM to rule them all is unrealistic. There are different ways to slice BOMs, different disciplines may have a need for their own specific view or information. How manufacturing looks at a BOM in ERP will be fundamentally quite different from how engineering looks at a BOM.

The topic of multiple BOM management isn’t so new. The truth is every enterprise system wants to manage their portion of BOM. In PLM space BOM management is often comes with the strategy of multiple BOMs or BOM views. Most of PLM systems can support multiple BOMs. The idea of separating BOMs into different slices or views is current answer to how to let every department in the organization to own their portion of BOM. Most of organizations are doing that because they didn’t find an alternative way to agree how to manage BOM. So, data is split between CAD, PDM, PLM, ERP, MRP, CRM and other domains. Read more about it in my article Why companies are not ready for single BOM? One of the biggest problems in using multiple bill of materials is related to collaboration between people in organization. Multi-BOM leads to huge data synchronization problem. The question “where is my BOM?” is usually the one that kills collaboration.

What is my conclusion? To manage BOM in Excel is a nightmare. So, to bring BOM management tools to replace Excel is a very good idea. However, most of companies are having though time to decide how to manage bill of materials among different systems and environments. In a real world companies are relying on combination of Excel, PDM/PLM and ERP to manage multiple BOMs. Unfortunately, it kills collaboration, productivity and innovation. Just my thoughts…

Best, Oleg


Bill of Materials (BOM): process or technology challenge?

March 3, 2014

bom-process-vs-technology

The importance of Bill of Material in product development and manufacturing hardly can be undervalued. BOM is a cornerstone of almost all processes and activities – from early requirement and design and to manufacturing, services and support. Therefore, efficient BOM management is an absolutely important element of product development processes. PLM vendors are coming with different solutions to manage BOMs. Together with vendors’ solutions, manufacturing companies are developing practices (and sometimes a complete solutions) how to manage Bill of Materials.

I’ve been discussing the idea of "single BOM" for the last few years as a possible way to simplify BOM management. My earlier post – Severn Rules towards Single BOM is almost five years back (2009) raised very interesting debates. All of them are still relevant in my view. I wanted to highlight one very insightful post by Jim Brown here. Jim speaks about different aspects and advantages of single BOM management. As part of this conversation Jim introduced a concept he called – associated BOMs. Here is the passage I specially liked:

Companies have spent a lot of time and effort making logical connections between different BOMs, and developing tools to help develop and synchronize different BOMs. For example, PLM, MPM, and Digital Manufacturing software helps companies translate an engineering BOM into a manufacturing BOM and then further into a BOP. In fact, they have gone further upstream to match conceptual BOMs and requirement structures downstream to BOMs. Maybe you would call these “workarounds” to the real answer of a single BOM. But I would propose a different view based on history and my observations. Perhaps engineers have done what we do best – addressed the problem in the most practical way as opposed to the most elegant way to solve a problem.

I think, Jim’s post is absolutely relevant today. After few years of discussions on this topic, one of my hypothesizes is that companies are not ready for single BOM solution… yet. At the same time, I do believe companies can take realistic steps into single BOM management already today. The variety of ways companies are managing bill of materials can surprise even people with lot of experience in manufacturing and PLM. After many years, I’m always surprised to find "yet another way" to manage bills, configurations and associated manufacturing and production information.

My attention was caught by Teamcenter PLM blog few weeks ago – Bill of Materials concept. Author, posted a very good summary about different types of BOMs. Together with eBOM, mBOM, sBOM and few others, it outlines the idea of Master BOM as a centerpiece of BOM Management capable to provide "single source of truth" about BOM. The following passage explains the idea:

To overcome this challenge, the concept of Master BOM has come. Master Bill of Material can be defined as single source of BOM having all aspect of information for various configuration and discipline. Hence Master BOM by definition is single source of truth for all BOM. Industry is still struggling to find the exact solution in term of defining and managing Master BOM. Also it become more complex due to the facts that different BOM types are managed in different systems. PLM vendors including Siemens PLM has come various solution and tools, but still required to show the success and maturity of managing Master BOM as a single source of truth across various BOM lifecycle and discipline.

This post and exchange of comments made me think about potential two challenges in BOM management – technology and process. The way and technology to support and implement the idea of "master BOM" is quite complicated as well as PLM implementation attempts to integrated product data under the umbrella of "single point of truth". At the same time, the idea of "master" or "single" BOM management faces multiple political challenges including discussions about internal and external company processes. In my view, modern data management technologies (especially coming from web and open source) can introduce some advantages in BOM management. It can be related to scalability of data management solutions as well as improved collaboration features. Would it be enough to overcome process challenges? This is a good question to ask these days.

What is my conclusion? After decades of development in PDM, PLM and ERP, companies are still struggling with BOM management. The topic is quite complicated and introduce many technological and process challenges for companies. Future pressure around competition, customization and cost can bring BOM management challenges back. It will be interesting to see what (technology or processes) improvement will allow to unblock future of BOM management? No specific conclusion. Just thoughts today…

Best, Oleg


The Ugly Truth of Multi-BOM Management

December 18, 2013

multiple-bom-ugly-truth

Bill of Material (BOM) management is always fascinating topic. It sparks so many debates and introduce a large set of diverse opinions. I can even say that I have a special passion to speak about BOM on my blog. If you want to catch up on my recent posts about BOM, you can try these few links – Will PLM manage enterprise BOM? and Will SaaS and Open API solve BOM management problems? My special passion is "single BOM". I started this conversation few years ago. Here is my last writeup about single BOM- Single BOM in 6 steps.

Few days ago, my attention was caught by PLM dojo article about pros and cons is Multiple BOM management – Why You Should (or Shouldn’t) use Multiple BOMs. I highly recommend you to have a read the article including comments (the number is growing). It brings an interesting set of strategies relasted to BOM management. From my side, I can clearly see advantages of both approaches. And I can generally say it depends on many factors – industry, product, organization, processes and… (what is not less important) people. Here is my favorite passage:

Sometimes it makes sense for the CAD user to organize the design differently than how ERP organizes the data. For example, it might make sense to group a large assembly model into sub-assemblies that don’t represent any actual part, but make it easier to divide up work on the overall structure. A related reason is that having the part BOM separate from the CAD BOM isolates the part BOM from the inevitable messiness of the CAD files.

While there is nothing wrong in division and separation of CAD design and Part structures, I still believe there is a trick here. Thinking about that, took me back to the post I wrote few years ago – The Ugly Truth About PLM-ERP Monkey Volleyball The controlling of data is one of the fundamental enterprise software behavior and strategy. One of the "negative" aspects of single BOM strategies is the need (and complexity) to share responsibilities and control over the shared "single BOM". It can create lots of organizational constraints, especially if departments and/or divisions are using multiple systems.

At the same time, Single BOM containing multiple dimensions of product information can become a place to share data among organization and optimize processes. However, in order to make it happen organization will have to agree how to manage "shared space", and shared responsibilities. People management becomes a critical function to make it successful.

What is my conclusion? Technology is easy part, but people are really hard. This is one of my favorite quotes. The ugly truth of BOM management is the fact it requires people management and agreement across organization. Multiple BOM can be done using separation and data island controlling. Very often you can hear about technological challenges of single BOM organization. Much rare situation is when organization is moving to people and organizational constraints. People’s ego and organizational issues are often playing a key role in decision to go with one of BOM management strategies. Just my thoughts…

Best, Oleg


Will SaaS and Open API solve BOM Management problem?

September 27, 2013

where-is-my-bom

I like the way BOM discussion usually sparks. From my experience, "BOM management" topic has the ability to ignite conversation almost immediately. Therefore, I wasn’t too much surprised when I got blog attention from Hardi Meybaum, CEO of GrabCADmost buzzed about company in Boston if you trust Venturefizz. Here is the article – Why single BOM is not the answer for you. Read it and draw your own conclusion. My favorite passage is the one that explains "BOM problem":

Recent posts on bill of materials (BOM) like Oleg’s ‘Will PLM Manage Enterprise BOM,’ make me [Hardi] remember my first conversation about BOM management. It was when I was in charge of IT in a mid-size manufacturing company. Then, and now, Procurement Specialists said that BOM should live in ERP, Engineering Managers said it should live in PLM, Engineers said that it should live in spreadsheets, and PLM vendors said it should live in PLM. This is where today’s BOM problems start.

According to Hardi, BOM management problem will disappear because of SaaS and API availability. He promotes open exchange of data between GrabCAD and other SaaS applications and out-of-the-box integration. It will finally make right information available to everyone in an organization. From what I can see, GrabCAD’s believe that companies will move from integrated large product suites into lean and granular applications. Actually, I like the idea very much. Granularity is a very good thing. Two years ago, Chad Jackson addressed granularity on his Lifecycle Insight blog -Point Solutions, Integrated Solutions and the Granularity Value Proposition. This is how Chad explains the granularity:

The fundamental idea is that you layer on different solutions that each do something very specific and well. Basically it is the point solution approach but from an ecosystem perspective. It would include something like leaving your workgroup PDM software in place. Layer on top of that a workflow. Then add some social computing solution for collaboration. Then you can add in a project management solution. You get the idea. Leave what you have in place. Add in other point solutions where needed. And integrate them as lightly as you can.

Granularity and best-of-breed application set usually comes with two additional price tickets – IT/setup and integration.I can see an interesting and new perspective in the way Hardi presents the advantage of granular solution. It comes together with SaaS, which makes a lot of sense to me. Installation, setup, updates – all these things will go away with SaaS approach. However, I have a doubt about integration. Out of the box integration is a tricky part. I never seen it works well. If you want to create a custom integration, you eventually coming down to nuts and bolts. API plays an important role in the ability of systems to be integrated. I mentioned the importance of Web APIs in PLM last year – Why PLM Need To Lean Web APIs? Even if APIs are available, integration is an expensive thing. From that standpoint, it doesn’t really matter if your PLM and ERP systems are running as SaaS applications or installed in you datacenter. My hunch, traditional RDBMS technologies allows more options to build hardwired integration compared to multi-tenant cloud applications. BOM implementations are complex and required lots of business rules to be implemented to synchronize multiple bill of materials. This is pure integration question and hardly can be handled as custom-made work.

What is my conclusion? SaaS is a game changer in terms of how systems can be deployed and maintained. It creates a completely different view on IT spending and TCO. It is also creates a different perspective of openness and importance of APIs. It was easy to hack ERP or PLM RDBMS with direct SQL call to solve your integration needs. It is completely different for SaaS apps. You cannot do integrations without custom code or flexible integration frameworks and middleware. In my view, the real BOM management problem is not related to the fact your system runs on the cloud or on premise. It is about how to connect multiple BOMs into a single meaningful solution. This task is complex and cost money. Cloud is an excellent foundation to simplify solution available and making information easy accessible. Will it solve BOM management problems across organizational silos. I’m not sure about that. Just my thoughts. What is your take?

Best, Oleg


Will PLM manage enterprise BOM?

August 26, 2013

Bill of Materials is a huge topic. It is hard to underestimate the importance of BOM management in general as well as specifically for PLM systems. I’ve been blogging about BOM many times. Use this custom Google search to browse my previous beyond PLM articles about BOM.

One of the topics I’m debating already long time is so called "single BOM". I explained my early view on a problem of a single BOM back in 2009 in my post – Seven Rules Towards Single Bill of Materials. Despite most of people you talk to would agree with the idea, the implementation of single BOM in modern enterprise is complicated and challenging. Take a look on another post to get a glimpse of what I’m talking about – Why companies are not ready for single BOM? One of the biggest problem towards achieving of single BOM idea is integration challenges. Today, BOM data resides in many systems in enterprise. Each of these systems provides a specific functional view on BOM management – design, engineering, supply chain, manufacturing, finance, etc. However, the integration of these systems is a very complicated task. In addition to that, the attitude of vendors to lock data to improve the competitiveness of their systems applies additional integration and communication difficulties.

Manufacturing companies have many challenges these days. BOM management is one of them. Despite the fact of complexity of single BOM management strategies, businesses need to have a holistic view of bill of materials. I touched it in my 3 modern BOM management challenges blog post – lean manufacturing, heavy customization, supply and contract manufacturing.

In my view, the problem of BOM management is well understood by industry. I stumble upon one of the old Siemens PLM blog posts written by Nick Pakvasa – BOM Challenges in Automotive Industry. In addition to (obvious) recommendation to use TeamCenter as for enterprise BOM management, article nails down the problem of single BOM. Here is my favorite passage:

The requirement to get the BOM under control at the enterprise level is reaching a critical stage. Exponential increase in software content is driving the requirement to eliminate legacy BOM applications that were structured purely to support older product architectures which were predominantly based on mechanical parts, to an environment that has to deliver integrated BOM management capability for all content in the product. And, to deliver this capability with lifecycle BOM management needs incorporated into the application, and to manage this BOM data starting in the Product Planning phase, through designing, building, selling, servicing and retiring the product. Without integrated enterprise level BOM management supporting all functional areas, geographical locations and external suppliers, partners and joint ventures, actions such as traceability of quality and other imperatives, reuse, BOM access for Service, and lifecycle enterprise change management are either cumbersome, with redundant or non-value added effort, and potential for errors, or in some cases, cannot be executed.

What is my conclusion? The recommendation of all PLM vendors is to use PLM as a central system to manage all BOMs. The recommendation is obvious. However, my hunch is that problem is bigger than it presented by PLM companies and other vendors developing systems producing and requesting data about of BOMs. The complexity of integration, implementation legacy and variety of requirements are creating a very complex application space to manage. In addition to that, high level of competition together with political influence inside of every manufacturing company, make the decision about BOM management one of the most complicated in modern enterprise systems. Just my thoughts…

Best, Oleg


PLM, Bill of Materials and Silo Syndrome

April 26, 2013

PLM-info-silos.png

Are you familiar with term “silo”. When it comes to enterprises and large organizations, we often can hear about different silos of information. Here is the definition of information silo as it appears in Wikipedia.

An information silo is a management system incapable of reciprocal operation with other, related information systems. For example, a bank’s management system is considered a silo if it cannot exchange information with other related systems within its own organization, or with the management systems of its customers, vendors, or business partners. “Information silo” is a pejorativeexpression that is useful for describing the absence of operational reciprocity. In Information Technology, the absence of operational reciprocity is between disparate systems also commonly referred to as disparate data systems. Derived variants are “silo thinking”, “silo vision”, and “silo mentality”.

Very often, you can hear about “information silos” in a very negative context. Here are typical reasons why silos are bad – productivity killer, bad information transparency, etc. Recently published by PR Newswire article defines a new term called silo syndrome. Navigate to the following link to read Thousands of Companies Diagnosed with Dreaded ‘Silo Syndrome’. Article defines list of so called “silo syndrome symptoms”:

- An inability to immediately access business information
– Searching for answers but never really finding them
– Problems processing terms like “unstructured content”
– A penchant to unnecessarily flatten relational data
– Inability to join concepts together in real-time
– Needlessly accessing multiple systems for “what” and “why” answers

PLM propaganda very often use the value of PLM in overcoming the problem of organizational silos. Here is one of many marketing examples of PLM value connected to org silos coming from Oracle Agile PLM article on IT Toolbox article.

PLM by definition is concerned with tracking and controlling product-related business processes that span multiple departments across an extended period of time. Each of these departments may utilize differing systems. Tracking a products lifecycle will often present the need to gather and share information with ERP, CRM, inventory, manufacturing, supply chain, logistics and other systems. While some off the shelf integration may be available, current PLM users often find themselves faced with a frustrating level of manual re-entry or poor visibility of information and processes trapped in so-called silos. Overcoming these integration challenges can mean that an organization is liberated to find the true value of PLM: more innovative, market-responsive products, faster-time-to-market, faster time-to-volume, more efficient change management, better customer care, and superior obsolescence strategies. These benefits can be achieved by both process and discrete manufacturers.

The reality of PLM and silos are difficult. The main place where PLM is facing organizational silos is Bill of Materials (BOM) management. For manufacturing organizations, to create and manintain multiple Bill of Materials is a straightforward way to split responsibilities and control. Requirements, Engineering, Manufacturing, Sales, Support, Supply… you name it. Every department and organization is requesting to have “my BOM”, which will allow them to control and manage the information in the way they want. The real challenge come after when people demand PLM system to take care of multiple BOMs and information transformation between these BOM-silos.

What is my conclusion? Today, PLM has a limited success in eliminating organizational silos by introducing support for multiple Bill of Materials. In many situations PLM is not eliminating the needs to re-creating information. The demand of customers is to have sophisticated BOM management tools that allows to maintain multiple BOM silos in organization. In practice, manufacturing organizations are not interested to eliminate BOM silos. People want to keep information silos, but have PLM system that can help them to manage silos. Result is skyrockeing complexity of the PLM systems and implementation. So, do we need to preserve silos? It is a good question you can ask before approaching you next PLM BOM implementation. What is your take? Speak up.

Best, Oleg


BOM 101: 5 “Don’ts” for Bill of Materials Management

January 21, 2013

BOM is fascinating. After posting 3 Modern BOM Management Challenges a week ago, I keep getting back to Bill of Materials management topic. If you missed my previous BOM 101 posts, here are links to get up to speed: BOM 101- The four pillars of every BOM management solution, BOM 101- How to optimize Bil of Materials. You can also take a look on this post as well – Single BOM in 6 steps. Today, I’d like to take a bit different angle by stating my 5 top most important "don’ts" you need to follow when designing and implementing bill of materials solution in your company. These topics are not necessarily reflecting PLM system. You can face the same problems when implementing BOM solutions using Excel spreadsheets, homegrown DIY data management and large ERP solution.

1. Don’t use significant numbers for Part Numbers – Use Classification

The discussion about "significant" vs. "non-significant" part numbers is probably endless. If you are new in this discussion (or just came out of computer science college), a significant Part Number looks like this 60-44-FN400587-60-NM-40-DWG-CHI. The information in this number is coded and different groups of this number are representing different meaning. Is there something wrong here? No, it is absolutely fine to have significant part number. Even more, if you are still using Excel spreadsheets or legacy data management system, this is probably the only way you can do it. However, it is complicated and eventually will lead you to mistakes. These days, most of PLM systems will provide you with the easy way to use insignificant part numbers. One of the features of good data management system is advanced classification mechanism. Such type of mechanism will help you to define all meaningful terms and characteristics of your Parts, Assemblies and Materials.

2. Don’t use supplier’s part number – use your own Item Master number

When working with suppliers, you may decide to use supplier’s part numbering schema. Especially if you are small company, it sounds very reasonable and it can simplify the communication with suppliers. However, this is a wrong thing to do, in my view. Again, PDM / PLM system maintaining item master record with cross-reference mechanism between parts and supplier part numbers can easy solve this problem and simplify your life in the future. What will happen with your system and processes if supplier will decide to change their number schema one day? it will be probably a very complicated day for you. So, use your own item master numbering schema and don’t rely on suppliers.

3. Don’t use the same ID for Part Numbers and Drawing Numbers

This is another question often asked during implementations. To use the same number for items and for drawings as well as process sheets, specification documents, etc. Initially sounds like something that could be simple enough to support and manage, can potentially lead to significant complexity and limitation in managing of change processes. The same drawing can be used for different part numbers. At the same time, changes of part numbers related to materials, stock, etc. won’t require drawing changes. Keep separate numbers and manage relationships between them is a good data management practice to follow.

4. Don’t be afraid to use extra part numbers

Identification is a very important mechanism. Sometimes, the assembly process is quite complicated and requires some temporarily pre assembled elements of the equipment to be maintained separately. In addition, you might have materials such as service parts, replacements, process result chemicals, etc. Bottom line – you don’t want materials in your bill to fly without identification. Everything needs to be included into the bill. Today’s data management systems are powerful enough to manage "extra Part Numbers" to identify everything you need in your bill.

5. Don’t put Bill of Materials on the drawings

Another topic coming from historical usage of paper drawing. In the past, it was the only way to share information. Obvious decision back that days was to put Bill of Materials on the drawing list. In modern digital life, such practice can create a lot of complications and additional procedures (such as updates of drawing when only part list will be changed). The good practice today is to keep cross reference links between drawings and bill of materials. It will allow you to manage your changes process efficiently and optimize your and your company time.

What is my conclusion? Control and efficiency. These are two important words to remember when you deal with Parts, BOMs and Documents. Many processes in this space were developed in the past and can trail lots of complexity if you not update them to "digital era". To streamline processes and make change management simple are important goals to following when creating the foundation of your BOM management solutions. Just my thoughts. I’m sure missed some issues and useful tips. Speak your mind and share your experience….

Best, Oleg


Follow

Get every new post delivered to your Inbox.

Join 244 other followers