How can you prevent PLM 2.0 silos?

April 30, 2009

The latest development in Product Lifecycle Management has raised the level of PLM systems with their ability to support wider areas of product development, manufacturing and maintenance. I think that over the past few years we have seen many new capabilities, systems and technologies developed by leading PLM companies. So, where is my concern?. Massive development of PLM technologies creates a new domain of enterprise software which then creates a new island of data. With new and modern technologies, you can see very reliable and centralized storage of product information that allows you to track every record of product data and related information. However, this development has led to another problem – product information has become siloed inside of the enterprise.

So, how can you develop Product Lifecycle Management strategies that can prevent you from creating additional PLM silos?

1. Develop integration strategies for PLM including the connection of various existing software (design, planning, manufacturing) to PLM. Without these integration strategies, you will find yourself quickly landing on an island that contains a huge amount of information that you need to exchange with external bodies.

2. Plan Business Process Management initiatives that prevent disintegration of information and processes. These BPM initiatives can be processes connected on the organizational level. As part of this connection, these establish (physical and logical) links between PLM and other enterprise systems.

3. Invest into Business Intelligence and establish a way of accessing product information in PLM systems from outside systems. This business intelligence software will create a business background for improving the PLM information available and the general ‘de-siloing’ of data inside the organization.

So, what are my practical recommendations? Start from investing in overall IT infrastructure integration with PLM. You need to figure out where all the pieces of product data are related and what processes they touch. Afterwards, you will need to see how to optimize processes and align them with available platforms and tools for business process management.


PLM Integration Gotchas

April 30, 2009

Today I would like to discuss PLM integrations. I see PLM as a business software that heavily relies on integration. You need to integrate PLM with multiple design, manufacturing and business systems. Manufacturing companies are using a huge set of multiple systems as a result of their operational history, acquisitions and product preferences for specific solutions.

In my opinion, as soon as you decide to get into the PLM story, you will find yourself in the business of Integration Services. Even after many years of implementation, I don’t think we have a consistent agreement about PLM integration eco-systems and tools that you need for integration. So, where do you start? How do you avoid typical mistakes in such complex topics as PLM Integration? Let’s define the following areas of Product Lifecycle Management where integration is required today. In my view, there are three areas where PLM product (or project) can face different integration use cases: (1) User Interactive Integrations; (2) Process Integrations.

User Interactive Integrations

These are integrations that span the scope of CAD (design) and CAE systems. Traditionally, these integrations mostly rely on API systems. Additional usage of standard formats for data exchange can simplify integration efforts (3DXML, JT, STEP etc.). More advanced integration in this space can use Mashup technologies to allow mixing data from multiple systems on client and component based integration with portals and other tools. Capturing of data from multiple desktop systems is a significant part of the integration effort. Usage of XML based data mixing and transformation tools can simplify overall integration costs.

Process Integrations

These are integration tools that focus on the integration of multiple transactional systems. In addition, business process management is also part of this process integration game. In this area, you can find potential for heavy usage of integration middleware and ESB (Enterprise Service Buses). Some of the integration techniques are based on proprietary tools developed inside of PDM products. Additionally, you have the potential to use an integration solution from large IT vendors (Microsoft SharePoint, BizTalk Server, IBM WebSphere etc.). You will need to optimize your organization and system usage in order not to fall into complex integrations and expensive implementation in these areas.

Additional Gotchas:

Peer-to-Peer vs. Middleware/SOA based integrations:

This is a very known trade-off in the integration business. You can connect a system directly by custom developed bridges and you can use mediation software for the integration. You need to use a rule of thumb.  I don’t think there is “one-size decision” in this case. On one hand, middleware solutions are naturally more expensive to introduce and support. On the other hand, a number of local bridges can result in a spaghetti-integration mess .

Promising Integration Technologies:

There are a few interesting integration technologies in the horizon that, in my view, are undervalued by PLM products. Mashup technologies can be used to mix information from different data sources and reuse this information for multiple purposes. There are different flavors of Mashups- (1) client/browser and (2) data (or sometime called enterprise) Mashups. There are a few interesting products that have been introduced in this space (i.e. JackBe, PopFly, Denodo and others)

Out-of-the-Box and Integration Services

You can achieve a pretty good out-of-the-box desktop integration, especially if you can standardize specific data formats and scenarios. Excellent examples are multi-CAD and other engineering systems. At the same time, process and more complex business integration are hard to achieve with out-of-the-box solutions and require implementation in the context of specific customers and scenarios.

Open Source

Since the integration business depends heavily on services and customer-oriented implementation, I see a potential for integration based on open source products. Advantages of open source products for customer are that they can modify it in any time because they fully own them. These integration solutions have a long life span, which can be a significant advantage in the total cost of the solution.

Integration as a Service

This class of new and emerging solutions allows you to use integration products available online from the Web. In my opinion, these solutions are mostly focused on the growing SaaS space. This is a very new zone in which I think needs to be watched more in the future.

The bottom line in this discussion is that PLM integrations have many faces and aspects. The optimization and future development of technologies in this space can bring significant competitive advantages and more integration solutions to customers.

What’s your opinion?

 


When BOM seeks the right enterprise nanny…

April 29, 2009

Yes, I have come to the conclusion that the Bill of Materials (BOM) child is quite alone… probably because the BOM children were very popular and everybody wanted to take care of them . Just take a look at our closest environment . We do have a Bill of Materials in CAD/design, Engineering, Manufacturing, Support and Maintenance…. As I mentioned in my previous post, Search for the right BOM – I’m feeling lucky?, finding the right Bill of Materials in an enterprise environment is not simple.

So, the question I wanted to ask is how can we improve Bill of Materials, which fundamentally represents everything in Product Lifecycle Management – from the early requirements and design until production and disposal. My initial idea was about a synchronized BOM (Is it time for a synchronized Bill of Materials?). The biggest challenge I found is actually Bill of Materials separated by multiple systems in the organization. I’m sure you are very familiar with this problem. Bill of Materials have many flavors where each system tries to manage its own flavor of Bill of Materials. As a result, we have NO Bill of Materials.

I have seen a few trends in Bill of Materials management as of today:

1. Master trend. This is probably the oldest one. The idea is quite straightforward and based on trying to build master-relationships for the Bill of Materials. So far, when you have a master, you supposed don’t have a problem with multiple BOMs. But, to define such “master behavior” is difficult, and the process of master definition spans across time, products and technologies within the organization. It may work, in my view, in quite a synchronized and centralized environment. But if you take a more detailed look, you will find “another small BOM” somewhere around :)….

2. Multi-BOM trend. This one is quite established. As we said, there are many Bill of Materials – here we have an answer. We can manage many BOMs! With all the technologies we have today, we can manage as many as we want. Where is Catch 22? The governance model for Bill of Materials in this case becomes very problematic. Now we have too many BOMs and they are trying to state their single point of truth about what is going on with a product. Multiple tools around this problem can help you to compare, change, and even find inconsistencies, but the overall system becomes quite unstable, in my opinion…

3. Process trend. This is a new one, I discovered. We don’t manage Bill of Materials anymore. We do manage processes for organizations. Design, Engineering, Manufacturing. This sounds very reasonable. Process can formalize our activity around data and provide a reliable way to manage our ancient data life on a different level. So, in other words, – BOM is stupid and the process is smart. So far so good… Process management is a big scope. To implement it for an organization is not a simple task at all…. I’m just afraid, this is too much for “my small BOM child” :)…

So, what is my conclusion? I think we are still an the age where we need to find better technologies for managing Bill of Material(s). Do you know of any alternatives? I’m looking how to resolve the BOM problem within an organization and beyond…


What is the future of search for PLM?

April 28, 2009

There is no doubt a search changed the way we work today on the Internet. Remember how looked for  information in the pre-Internet and pre-Google age? It wasn’t so simple as today. 

So, the change of the user’s behavior regarding ‘search’ has created a lot of opportunities on the Internet surface. I’ve tried to look at how PLM and search intersects and perhaps find new ways to improve PLM system behaviors today. I touched on this before in my posts about Enterprise Search and PLM. So, I’ll do a deeper discovery into this space.

 What is available today? :

 1.    Enterprise Search.

This term is used to describe the application of search technologies inside of organization. This term is opposite two other searches – web search and desktop search – it is probably the most relevant to what PLM does inside an organization. The ability to find the right information about product, documentation, changes etc. is extremely important. I think that this area will grow in the near  future.

 Microsoft Futuristic View on Enterprise Search

2.    3D Space search.

This is a very specific area in search applications that allows you to specify your search criteria based on certain geometric characteristics of a product. Even if such capabilities already exist inside of many PLM applications, this search is interesting since it can connect to an enterprise search. Actually, it’s important to integrate 3D Space search into enterprise search and other applications.

 Dassault Systems 3DLive User Experience (UX)

3.    Visual Search / 3D search

If 3D Space search mostly uses 3D as a criteria for search (WHERE), Visual search (or 3D search, as I call it) is mostly about being able to provide a search with information about WHAT to search for. This can be interesting for the decision making and design process areas – because it allows you to find all information visually. Sometimes, however, it’s misleading as it can be hidden by wrong meta-information and additional data.

 Innovative solution from 3DPartBrowser 

The above are my top three perspectives for Search in the PLM domain. I’m going to discover search topic in context of PLM during these days on Infonortics Search Meeting in Boston. During this meeting, I had some casual talk with Steven Arnold and got some interesting perspectives on his Beyond Search Blog. I’m looking forward to speak more about this topic in the future…



5 reasons why Wiki fails for PLM collaboration

April 27, 2009

In the last few posts, I wrote about how you can use Enterprise 2.0 tools to improve various processes related to product development. I think that Wiki is an easy collaborative platform. I also think that Wikis have a great potential to be transformed into something that bigger from which smaller enterprises can benefit. At the same time, over the past few weeks, I tried to experiment with Wiki platforms.

 My initial proposition was to use Wiki as content space to keep information for collaborative usage. I don’t think this is a very new and fresh idea, but I wanted to see how it would be possible to use existing tools without significant modifications.

 Below is my conclusion regarding the weak sides of the Wiki story for product collaboration:

1.       Information Access. The biggest advantage of Wiki is simplicity. But this means that Wiki is completely flat. You don’t have any way of organizing access to information rather than creating of pages / sub-pages and links between them. When you deal with short flat pages it works well. When you start to add more complex content, it becomes unusable. I found that the simplest way ,to search for information was a browser embedded search (even though theChrome search is quite good, it wasn’t very simple to find what I needed. If you have multiple Wikis, you have the problem of information being separated and not accessible across Wikis.

2.       Content Maintenance. It’s very simple to insert information and update a Wiki. Butm at the same time, you have to take care of all the information there. This means that you can’t maintain your content with rules and logic. This is not a good way to organize it. You need to take care of the content or else it turns into garbage very quickly.

3.       Updates. I didn’t find any way to maintain automatic and dependency in updates of content. This is creates cumbersome situation when I need to update information I already put in wiki, but keep history of my updates. Quite straightforward requirements in our space, but hardly can be achievable out of the box.

4.       Integration. This disappointed me very much. The only way to integrate Wikis is to put hyperlinks on the relevant information. But what if this information is located in other systems / storages and formats?. I didn’t find any way to mashup information inside a Wiki page. Although Web Parts or similar functionality is available, it breaks the  page into segments and is not as good as what I want.

5.       Structural Information. This is a higher degree of content maintenance, but a very important one, in my opinion. Product information is highly structured by nature. Maintaining this information only by URL/links mechanisms is not trivial. So, the structure of information is probably a very desired feature.

Therefore, what is my conclusion? The Wiki collaborative mechanism is very nice and simple. It provides a very affordable way of collaborating and co-editing information. It seems hard to balance between the benefits and burdens of Wiki on the user.. I’d like to hear your opinions and experience of applying Wiki technologies.


How to create self-contained PLM persistent storage?

April 24, 2009

I’m getting back to the topic of persistent storage of PLM data. In my previous posts, I touched on this a few times.

PLM Persistent Content and Dynamic 3D PDF

PLM Dream Technologies for 2009

First of all, I will try to define functional scope for product persistent storage: In my view, there are five groups of product information that need to be included in this storage: (1) product geometry and models; (2) drawings; (3) knowledge representation (how-to; reasoning; math…); (4) Technical data such as suppliers, manufacturing, etc. and finally (5) meta-data describing all the product data together.

While I see a growing interest and demand for a solution that could possibly covering all the five topics I mentioned above, I don’t see technologies mature enough to provide an answer and allow practical implementation of such a solution in the field. I will try to cover briefly what I found available and what I see practically possible today.

I see STEP as a very solid and mature format that probably can consolidate geometry, model, and sometime additional product information. At the same time, raster formats (IGES, TIFF) and some others can be used to represent drawings for the long-term. Broad usage of PDF makes this format a reliable and stable option for long-term persistent storage as well. On top of PDF, I’ve seen some development such as PDF/A (for document archiving). Even if this format cannot be used as is for product-related data, this is the direction that can be taken to develop extensions for PDF that can support needs for representation of additional technical data.

I didn’t find any reliable technologies that can be used to store meta-data and technical data, rather than existing database and XML technologies. Even if these (Database and XML) technologies prove themselves for transactional usages, I haven’t found practical reference on using databases for data storage over a long time..

Apart from the above-mentioned technologies, I didn’t find mature technologies that can be used. There are a few research projects that I found in this space – LOTAR and some developments done by OMG, OASIS, and W3C. All these development are mostly research in character and contain research and development of models for persistent storage. At the same time, I don’t see them ready for production deployment.

So far, storage has become less expensive and we continue to produce a massive amount of new data on a daily basis. I see persistent storage as a very interesting opportunity for development that we’ll be able to see in the near future.


Will Master Data Management (MDM) work for PLM?

April 23, 2009

Lately, I’ve seen a potential for a growth in Master Data Management (MDM) initiatives. For those who don’t know MDM technologies are, I recommend you start with Wikipedia and check out the links of the MDM offering by IBM, Oracle and some other large IT vendors.

http://en.wikipedia.org/wiki/Master_Data_Management

http://www.dmoz.org/Computers/Software/Master_Data_Management/

Looking at the broad range of PLM capabilities and needs, I noticed that some of them deal with non-transactional and released products, and referenced data. This released data is need by various departments in the organization. The ability to find relevant product data related to a specific design as well as to change things from the past is growing. With growth of regulations in today’s word, being able to track and discover designs in the vault is a real need that can provide fast ROI

mdm-for-plm

So, can you figure out the math between having to access non-transactional product data and master data management technologies?. At first glance, this is something that can be validated and tested.

The following are some pros and cons for using MDM in the context of PLM:.

Pros:

· Reliable infrastructure to manage a single source of information

· Ability to redistribute information across the organization

· Global data availability in the organization

Cons:

· Expensive data transformation when you move data from design

· Not flexible for scenarios where back-reference to original data is needed.

· Data redundancy

What will be the future of MDM in the context of Product Development and Product lifecycle Management? Although there is some potential here, Master Data Management needs to adopt a flexible ability to play around various scenarios related to data referencing and data retention; I hardly see it being applied “as is” to product development today.

What is your opinion?


Follow

Get every new post delivered to your Inbox.

Join 262 other followers