Chrysler, PLM Platforms and Business Realities

August 2, 2010

I read news from the last week – Chrysler Group LLC contracts with Siemens PLM software for product design and development platform. It wasn’t a big surprise, since initial information about it leaked into the news back into May 2010. The news about large companies switching over big software vendors are always provoking. Each time it presented as a big deal for winning company and complete disaster for another side. However, I don’t have an intent to discuss particular details related to Siemens-Chrysler deal. Navigate your browser on Chrysler CATIA Siemens PLM and you will get a full list of news articles and relevant blog posts. I’d like to use this news as a context to talk about how I see present and future of PLM platforms in a modern business environment.

Business Realities
Modern enterprise landscape is very dynamic. It can be characterized by high dynamic of environmental changes, unstable business conditions, multiple M&A activities. In such realities, PLM-related decisions becomes even more complicated than usual. This situation brings a complex of questions: How to maintain multiple systems? How to work with multiple projects/programs? How to define a roadmap for the future PLM platform development in a company?

PLM Platforms and IT Landscape
I can see a significant trend towards the development of integrated PLM platforms. The initial signs of this trend became visible 3-5 years ago. In my view, today, the strategy of major PLM providers is to develop solid PLM platforms with a significant vertical integration. The objective of such platforms are to provide a stable and well adjusted set of integrated design, engineering and manufacturing planning functions. We’ve seen the formation of such a platform based on Siemens TeamCenter unification, DS V6 platform as well as PTC products. The maturity of these platforms is a good sign for users. At the same time, coupled with the business reality, they can introduce the new problems – PLM platforms transformations and impact of dependent organizations (i.e. Suppliers). These new problems are introducing a potential significant impact on engineering and corporate IT.

Flexibility and Openness
Thinking about business realities and PLM platforms, my ultimate conclusion is that in the next ten years we’ll need to be extremely focused on two aspects of PLM platforms – flexibility and openness. Ability of PLM platform to make flexible adaptation to changes can become a key factor in the future platform implementation. PLM will need to support acquisitions and transformation related not only to the business, but also to engineering and manufacturing activities.

Can We Achieve A Single Point Of Truth?
Part of PLM vision is well known as an ability to provide “a single point of truth” for a company. One of the fundamental questions I’d like to ask if this vision will keep up in the future. With an increased level of complexity, growing number or business systems, bigger scale and fast changes, the “single point of truth” vision can remain as a vision only. I had a chance to discuss it in one of my previous posts – PLM and A Single Point of Disagreement.

So, what is my conclusion today? Changes in large enterprise systems are very expensive and painful for the organization and eco-systems (contractors, suppliers, customers, etc.). The result of having multiple systems can create significant difficulties in operation and management. On the other side, changes may take long period of time and become an on-going effort. The future of large enterprise systems is interesting. My take – watch this space.

Best, Oleg

Leave a Comment » | Daily PLM Think Tank | Tagged: , , | Permalink
Posted by olegshilovitsky

5 Things To Know Before PLM-ERP Integration Project

May 4, 2010

Yesterday, I had chance to read the new paper by Jim Brown: Issue in Focus: The Integrated ERP-PLM Strategy. There are lots of things I agree with Jim. They are mostly in the area of strategic need for PLM-ERP as well as growing level of awareness about such need on the side of companies. However, the issue of integration cost is somewhat, I think, is a very critical. Unfortunately, because of complexity, manufacturers are facing the issue of PLM-ERP cost very late in the implementation process.

In my view PLM-ERP integration never comes as out-of-the-box product. The diversity of product development and manufacturing practices, product versions and many other factors are making PLM-ERP integration very complex and expensive project. I want to breakdown possible decision points related to PLM-ERP integration.

What data do you want to integrate?
It sounds obvious, but before you want to integrate systems, you need to understand what data you are going to integrate. It seems to me as an important topic is to break down data in both systems into very granular pieces and see how this data will be combined, transferred and integrated. Don’t move forward until you don’t understand what data assets do you have.

Where is data located and how it controlled?
The enterprise data management is a complex task. PLM and ERP systems are two the most complicated in the modern manufacturing. Data can be distributed in different locations, organization can use multiple ERP and, sometime, PLM systems. The ownership of enterprise systems and, in the end, control over the data assets can be very complicated. You need to see a full picture of data control by different people in the organization.

What processes influenced by integration?
There are lots of advantages in implementing PLM-ERP integration. However, such integration will introduce a change in the organization development and manufacturing process. As every change, it may bring some problems or simple additional cost in adjustment of work in the organization. You have to understand the influence from the different standpoint – people, software and processes. The cost of adjustment needs to be include into overall estimation related to your PLM-ERP integration project.

What API and development skills do you need?
It sounds like a completely technical. Nevertheless, it is very important. Your organizational systems can provide a different set of techniques and tools to develop integration. In most of the cases, enterprise systems are heavily customized. You need to understand and validate what tools and API you can use and how you PLM-ERP integration will be adjusted to all existing custom developments you have in place.

How to maintain your integration?
This one is last, but extremely important. Your PLM-ERP integration is not a single shot project you are doing once. Your organization becomes heavily dependent on this integration. PLM-ERP integrations are very often belonging to the class of “mission critical systems” in the organization. Therefore, you need to validate how you will be able to maintain this integration from all possible standpoints – people, technologies, system upgrades. The last one is also important. You obviously will manage upgrades of your ERP and PLM systems. You need to take into account that since you have PLM-ERP integration in place, this upgrade process will always be dependable on how you maintain your integration.

What is my conclusion today? PLM-ERP integration is a very expensive project. It can bring lots of benefits, but also drain a significant amount of resources. You need to understand how to make a right estimation of work and validate this project before it starts. I’m interested to discuss your experience and listen to your feedback.

Best, Oleg

Share

15 Comments | Daily PLM Think Tank, PLM+ERP | Tagged: , | Permalink
Posted by olegshilovitsky

Manufacturer Priorities and PLM Integration Lock

March 21, 2010

I have chance to listed AMR’s Mike Burket interview during Siemens PLM Innovation Summit. It seems to me as a very interesting talk and slides about current PLM priorities. You can see it on this link. Thanks Dora Smith for this nice blog post, video and slides. One of the key requirements coming from manufacturers today are around cost reduction, better integration operation and product development as well as improvements in a supply value chain.

I counted two issues that, in my view, can be considered as very old requirements and demanded by many customers long time:
1. Design to Manufacturing Processes
2. Supporting of segmentation in Supply Chain.

On the one side, you can think about them as two separate issues. However, these two issues share one common fundamental problem of PLM systems. The problem is how to organize  integrated cross organizational processes. If you will take a look on the following slide presented by Mike, the need for integration is something that I see as a must requirement to link demand insight, product development and supply networks.

Listening Mike it becomes almost clear that process integration will become the next PLM challenge. However, here is my point. Unfortunately, integration is a very expensive job. All integrated projects I know, took a lot of time, resources and, in my view, doesn’t fit IT budgets. The issue of reduced IT budgets makes this problem even more important and critical. Many of today’s PLM integrated projects were possible only due to result of long and dedicated work done by vendors, services providers and organizations.

What is my conclusion? There is no magic outside of powerpoint slides. Integration is hard. Nobody can do it easy today. Big PLM systems provide a comprehensive product development environment, but they are not adaptable for lean cross-organizational process integration. How to find a way to reduce PLM integrated project cost and improve the agility of product development environment? This is sounds as a deadlock and the biggest challenge for manufacturers and PLM vendors in coming future.

Just my opinion.
Best, Oleg

Share

4 Comments | Daily PLM Think Tank, Interoperability, PLM Implementation | Tagged: , , | Permalink
Posted by olegshilovitsky

Consolidation in EDA and PLM Pitfalls

March 19, 2010

I was watching Mentor Graphics presentation yesterday about their Valor acquisition. If you haven’t had a chance to watch it, take a look on the following link – Consolidation in EDA and PLM State of Mind. The presentation impressed me by slides and explanations. The acquisition’s target is clear and presenting an interest to create integration between design and manufacturing in the Electronic Design industry domain.

The presentation made me think about some fundamental trend in engineering and product development. This trend is about integrated systems. It seems to me EDA industry is following PLM state of mind in the creation of integrated design to manufacturing systems. PLM leaders – Dassault and UGS (now Siemens), passed exactly the same trends by acquisition of manufacturing software companies (Delmia and Tecnomatix).

Quote from Aberdeen’s Michele Boucher, finally confirmed my thoughts:

“In the mechanical world there have been significant moves by PLM vendors to expand their solutions footprint into manufacturing. The acquisition of Valor by Mentor Graphics is the first such move by a major ECAD vendor and constitutes a substantial step forward in providing end-to-end development solutions for the electronics industry.”

However, there is one thing I wanted to raise and discuss. The following side presented the biggest industry problem and reason for acquisition-  fragmentation. The similar problem was presented by PLM industries during the analyzes of design, engineering, manufacturing and other systems. As a result, the complex integrated PLM systems were created.

My take on this:

1. Integration of the systems is a very complex task
2. PLM systems focused on MCAD mostly, already did it in the past
3. Integrated systems in PLM domain created a huge level of complexity
4. Cost of the system’s lifecycle and changes are growing exponentially with the increased level of integration.

I’m sure Mentor Graphics engineering wizards will create an integrated models and maybe even standards to combine data and process flow between various components of EDA systems. Will they be able to resolve the similar problem created by PLM systems? It seems to me, people less think about a cost of change when creating an integrated system. World “integration” is so positive, then people tend to forget about a possible impact in the future.

Just my thoughts… What is your opinion?
Best, Oleg

Share

Leave a Comment » | EDA, Future Trends, Interoperability | Tagged: , , , | Permalink
Posted by olegshilovitsky

PLM vs. ERP: Weird or Different?

February 1, 2010

Discussion started last week with Jim Brown got me think more about ERP and PLM. I have to say, this is not a new topic, but thinking about it, I’m always finding new angles to see differences between ERP and PLM viewpoints. I want to make some breakdown on how things different in both systems, but before, I’d like to suggest you to watch the following video from TED.

Identification: Documents, Parts, Item Masters

When you think about identification systems, you can clearly see that PLM and ERP starts from different foundations. PLM (especially systems that got founded around CAD) think first about Documents and related Parts. Even for systems that taking Item centric approach, definition of Item is pretty much similar to Document. On the opposite side, ERP is all about Item Master, Bill of Materials and Dates (!). Everything starts and ends with “The Date”. Without the assumption about what date you are talking about, you won’t be able to get anything done in ERP.

Versions vs. Effectivitiy

The main identification mechanism in PLM systems is a version. Documents, Parts have versions on it. This is how work-in-progress environment works. Whatever you change, you put version on it. On the opposite side, everything is effectivity oriented. You have a date on everything you are going to change. This date will show when it is effective. It is pretty complicated to combine these two opposite sides to work together.

Changes

This is last in top three core different fundamentals of PLM and ERP, but for sure not least. When you think about changes in CAD and PLM, you can be pretty flexible. You can always get new version of almost everything you are doing. World of PLM structured information comply with your will to change, and you are getting to the next level. The previous one easy becomes obsolete. The life is absolutely different on ERP side of the world – everything you want to change – think dates. Your manufacturing system is up-to-date to manufacturing life. All your change may and will impact manufacturing production systems. All processes are formal, requires ECN/ECOs, signatures, confirmation, etc.

So, Where we can go from here?

These bits and bytes are, in my view, fundamentals of differences between two worlds of PLM and ERP. On the upper levels, buzzwords of execution and innovation are flying, but here inside Bill of Materials, Parts and Items are struggling to live together and magically represents the same product company is doing business on. I think it is very logical that everything PLM people like to see as normal, seems different (or weird) on ERP side. Opposite is also true. Now, my question is how to balance this system? There are few possible ways, and I will try to analyze them.

Data Exchange

This is the old and straightforward way to do PLM/ERP business. If you’re familiar with “drop over the wall” approach – here you go. Just drop Bill of Material from PLM to ERP and forget. But, I’m not sure this is the most efficient one.

Process Orchestration

The most complicated. You don’t care about data first – you think the process wise. This is the right way to do business in the organization. However, compare to the construction industry, if you build you house on the badly prepared foundation (enterprise data) you are in the high accident zone.

Mashups

This is the potential alternative. This option is not developed much these days. Instead of fighting about how to own data, let’s try to focus on how to consume data in the way that users will be less worry where information resides and more focused on decision making. However, this option is still requiring a lot of investigation and research.

What is my conclusion today? It is hard to say “where PLM stops and ERP begin”. Things are getting connected, weird and unbreakable if you want to insure your organizational processes are running smooth. And this is probably less about PLM, ERP and even other systems. This is about how your organization work. And connecting it to the video you had chance to see before, think about your product and not about how it represented in different siloed systems.

So, how do you see? Does it make sense? What are your experience and view on how things need to be connected?

Best, Oleg

Share

24 Comments | Daily PLM Think Tank, PLM+ERP | Tagged: , , , | Permalink
Posted by olegshilovitsky

Back to basics: PLM and ERP Integration

December 16, 2009

I want to finish my ‘back to basics’ set of posts with the topic of PLM and ERP integration. Staying in CAD/PDM/PLM related market for while, I have to say that this topic always was one heavily discussed during PLM implementation. First, I want to distance from discussion about benefits of PLM vs. ERP and how can ERP do PLM or opposite. Let assume we do have both PLM and ERP systems in place. What are options to integrate these systems we have and what is the efficiency of the proposed option.

1. No integration. Manual. People do it. This is a very simple option. Full stop. You think PLM+ERP is too complex or too expensive. You think people are cheap, and they can move data between two systems by hands. Not a bad one, until your designers are waiting for new Part Number from ERP for a couple of days or your manufacturing planning people getting EBOM once in a while.

2. Batch integration. This is in my view the most widely used type of integration. You understand that type information twice (or even more) in all systems is beyond of what you are ready to do in 21st century. So, your decision is to push information between both systems. It may happen in both directions, but for the most cases, I’ve seen a push BOM from PDM/PLM to ERP is the option company implement the most.

3. Direct integration. Next stop after “Batch integration”. Sometimes it comes after your experience with batch processes. You discovered that some business logic around batch processes is a good idea. Sometimes you need to make some validation or prompt user for a question. This is a time when you hire programmers or service company to develop this integration between “your PLM” and “your ERP”. Some PLM vendors offer “pre-packaged” integration. Despite claims of pre-packaged and out-of-the-box, these integrations never work without tuning, configuration and some additional customization. For many of the customers, this option is a compromise between “no integration” or “batch integration” and something they perceive as a more expensive option. For short term, this type of solution can be pretty good, and if you successfully manage complexity of integration, this will be, probably, your “final stop”. However, I see this type of solution as a problem with timer. In the end of the day, cost of this solution adjustment to your “next problem” will be too high.

4. Middleware based integration. Very popular option for end of 90s and beginning of 2000s. Why do you need to implement n-complete number of integration for your enterprise? You can just implement integration of your PLM (and other systems) to something called “middleware” (various TLA used and continue used for this – EAI, ESB…) and you are done. Integration middleware (such as BizTalk, WebSphere or others) can help you to map data and provide tools for business logic development. In addition to generic middleware/EAI/ESB, there are some vendors in the market that tuned their integration solution for PLM and ERP. In my view, these companies are getting premium price for their experience with PLM and ERP packages. You can consider it as a valid option too. My conclusion is that you need to go to various types of middleware and more complicated integration solution only if you understand what value your organization will get due to this significant investment. This option is robust, however, be prepared to pay the cost of middleware as well as keep experienced people or consulting company to deal with this complicated animal.  Don’t believe in magic and out-of-the-box solutions and your integration will be just fine.

5. Mashups and other Web-like technologies. This is not widely used option. Speaking precisely, this is even not “integration” in our traditional understanding. Mashup automatically will not provide you support for transferring of data between both systems. However, with growing amount of Web -related development, mashups become an interesting example of lean approach in data integration. Most of the mashups are web-client application that extracts data from a different web-sites (in our case it can be the web interface of your PLM and ERP systems) and present combined view on data. Originally developed for internet space, this option is getting some initial traction in enterprise too, but this is a topic for separate post. If you feel very innovative and your staff is experienced in Web technologies, you can try to experiment with mashups in your organization. Be prepared to be misunderstood by customers and management…

Note. I have to say that efficient PLM integration with ERP can affect your company decision with regards to deployment of PLM-related functions and in the end of the day, PLM system at all. So, choosing the right option to integrate you PLM with ERP can improve your decision with regards to PLM and sometime even with ERP implementation roadmap.

Best, Oleg

14 Comments | Daily PLM Think Tank, PLM+ERP | Tagged: , , | Permalink
Posted by olegshilovitsky

PLM and ERP: Why it doesn’t fit?

November 24, 2009

Reading Jim Brown’s blog post “Choosing an ERP to Fit PLM?”, I started to ask myself why these systems fit or don’t fit. For many organizations, I had chance to see in my professional life, PLM and ERP integration was always on the level of “love and hate” relationships. People wanted this integration to happen and on the other side discovered a lot of conflicting topics that prevented them from the ability to organize smooth fit and integration between PLM and ERP.

I’d like to figure out the list of issues that in my view prevent these systems from good fit and, actually these issues make systems from being competitive rather than work together.

1. Control of product master record. The constant question of “who owns what” is the first and most important. Both systems compete in the organization on the ability to manage product master record. This competition pattern is different in the different organization, but you can discover a presence of this “control war”.

2. Cross organizational process handling. Organizations are driven by processes. It can be the engineering change, configuration or any other processes. However, in most of the cases, these processes are rarely belonged to a single system in the enterprise. Processes are spanning across various organizational boundaries. PLM and ERP are competing on the ability to plan, build and manage these processes.

3. Enterprise Backbone. This is related to my previous post. How many enterprise backbones we need? PLM and ERP are both interested to keep the role of enterprise backbone. So, they can be very competitive in this role. If IT and engineering organization are not making right arrangement, overall organization can overspend on this a lot of internal dollars.

There is set of additional specific characteristics that we need to keep in mind from my standpoint. PLM and ERP fit is very dependent on the organization. Personal topic plays a very significant role. There are too many systems in existing enterprises. This enterprise system’s zoo, brings us to the point where integration is physically impossible or very costly.

So, what is the solution for PLM and ERP fit? Is it the next place for PLM (or may be ERP) innovation? What is the role of professional service and partner’s organization in the processes of making PLM to fit ERP or vice versa?

Best, Oleg

19 Comments | Daily PLM Think Tank, PLM+ERP | Tagged: , , , | Permalink
Posted by olegshilovitsky

New Office 2010 features for PLM integration

July 22, 2009

I’m continuing to provide my observation for upcoming Microsoft Office 2010 version. Today, I’d like to discuss two features related to Office 2010 that probably not on the surface of day-to-day communication, but at the same time will be very important in context of broad PLM implementations.

Office 2010 Properties and Share command

In Office 2010 Command replaces previously – command and, known from Office 2007command. The new concept of Backstage, going to be introduced in Office 2010 will centralize and summarize access to general information about documents and will simplify way to communicate with content in my view.

office-2010-backstage

In addition, <Share> command takes central place in User interface. <Share> command provides central place where exchange between Office and other formats and systems will happen.  This is very interesting move. Microsoft reasonable assumes <Share> command will provide better feeling to users and will eliminate information redundancy. For me, this place will become central place to integrate with PLM system in Office 2010.

office-2010-share

Open Document Format.

Another important topic in my view. Open Document format was introduced in Office 2007. It provides an alternative XML format for saving documents and content. In my view, Open Documents format played important role in the past when Office 2007 was integrated with MOSS 2007. So, together with command, Open Document format provides good foundation to integrate unstructured content with Office in very granular way.

What is my conclusion? Properties, Share, Change File Type commands and combination with Open Document Format in Office 2010, provides advanced foundation for integration with PLM content and systems. They will allow to integrate non-structured content in PLM such as – Requirements, Engineering Change, Published 3D content etc.

8 Comments | Daily PLM Think Tank, Microsoft | Tagged: , , | Permalink
Posted by olegshilovitsky

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?

 

1 Comment | Daily PLM Think Tank, PLM and organization, Technology | Tagged: , , , | Permalink
Posted by olegshilovitsky

What is beyond Collaboration and Process Management in PLM?

January 21, 2009

Collaboration and Process Management is obviously a very important part of Product Lifecycle Management. But does it really target successful Product Lifecycle Management implementation?  Yes, I think that allowing people to collaborate and have this process organized and synchronized with all other processes in your organization is the ultimate goal of any PLM implementation. Assuming you have already done this… does it make you feel good about your implementation? More importantly, does it make you feel good about your company?  If you answered NO, (as I suspect), I’d like to discuss and raise questions to discover what is beyond Collaboration and Process Management.

 I think that decision making needs to be taken care of by Product Lifecycle Management very urgently. I’m not talking about the ability of the system to make decisions, rather the ability of the PLM system to take control over product data that will help people in decision making. In order to make this happen, PLM tools need to provide a decision-oriented environment, that will allow the user (engineer, analyst, manager) to make the appropriate decision about change, design, priority etc.

 In order to make this happen, PLM needs to step up from a process-oriented environment to a multi-domain, content oriented environment. PLM needs to manage multiple domains of data, allowing the users of  (PLM) systems to access Requirements, Engineering, Parts, Customers, Manufacturing, etc. By allowing this, PLM will give users the chance to control the most important decisions in the organization. I see this as the ultimate value of PLM, beyond collaboration between people and the management of processes. 

If you are planning on implementing PLM today, what should you put on your short list to achieve these goals? In my view, you need to invest in two areas – operational business intelligence and the integration of your PLM system with other enterprise systems. The first area will give you tools to present information to make the right decision. The second will integrate product data into connected multi-domain data sets (such as multiple Bill of Materials etc.). Achievements of these two goals will allow PLM systems to move beyond day-to-day collaboration and process activities.

10 Comments | Daily PLM Think Tank, PLM and organization | Tagged: , , , | Permalink
Posted by olegshilovitsky

Next Entries »
Follow

Get every new post delivered to your Inbox.

Join 73 other followers