Happy Holidays!

December 25, 2009

Dear Friends!

Seasons Greetings from Daily PLM Think Tank!

I wish you great Holidays and Happy New Year!

Best, Oleg

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

Will Mashups Grow Up In PLM?

December 23, 2009

Short prompt to think about before Holiday break. Mashups. First coming to us with the world of Web 2.0 and dynamic web site content, mashup becomes an interesting function in many web applications. I think mashups are still very tiny business industry, but this technology was very successful in my view for some of applications like Google Map and not only.

Here is Wikipedia definition of Mashup:
In web development, a mashup is a web page or application that combines data or functionality from two or more external sources to create a new service. The term mashup implies easy, fast integration, frequently using open APIs and data sources to produce results that were not the original reason for producing the raw source data. An example of a mashup is the use of cartographic data to add location information to real estate data, thereby creating a new and distinct web API that was not originally provided by either source.

You can find some interesting ideas related to Enterprise Mashups and development around that in the recently created Open Mashup Alliance. Take a look on the following white paper:

So, my question today is as following. How do you see Mashup advantages in building of product data services and improvement of PLM applications? In my view, the technological foundation of mashups can be an interesting choice when moving PLM application to become more open and available in the way of online services.

Just my thoughts.
Oleg

6 Comments | Daily PLM Think Tank, Enterprise 2.0, Market and Technology, Productivity | Tagged: , , | Permalink
Posted by olegshilovitsky

Why Do We Need PLM to Control Product Cost?

December 22, 2009

I’d like to continue discussing topics that create maximum confusion between PLM marketing and reality. Today, I want to talk about one, that probably in the top list of all manufacturers – product cost. Yes, you want it down, no doubt. If you will talk to PLM marketers, they will all tell – PLM is the way to go. However, how magically it will happen? Why PLM can help you manage cost? How practically it will happen? I decided to discover the potential answers on these questions today…

Let me think about a traditional manufacturing environment that is not going to implement “PLM strategies”, but indeed is looking how to decrease cost of their products. The most reasonable approach is to ask different business units to develop their cost saving programs- R&D, Manufacturing, Supply Chain, Support. I believe, these organizations will be able to deliver decent results. Now, depends on manufacturing type, they have various chances to be successful. For the long run, the company manufacturing the same (or similar) products will be able to optimize cost of products. Their best chance to do so, will be for mass-manufacturing products. Within the time, all functional areas will be optimized and learn from the experience how to manage product costs for what they are doing. There are two potential problems in this approach. First is the time scale and the second production volume. What does it mean?

Time Scale in Manufacturing
With a significant time period, your manufacturing organization has a good chance to develop reasonable good product cost practices. Designers will find optimal solutions, right suppliers will be designated and subcontracted, manufacturing facilities will be optimized, etc.

Production Volume
The previous assumption of time scale will be working if you will continue to manufacture big series of products. With growing number of manufactured items, your product cost will go down.

What is the problem with such assumptions? The only one, in my view. This is less and less happening in modern manufacturing. Market demanding customization in production and due to that time and product volume is going down. So, manufacturers need to manage very flexible practices in their environment to maintain balance between production volume, time and cost.

Now, I want to get to my original question. How PLM can help? PLM is managing product data and processes. How product cost will be resulted from that? My answer – PLM need to facilitate cross-functional IT functions in the organization. Your functional domains are separate. Most of the systems in today’s IT are department oriented and rarely have global organizational exposure.  PLM need to make a success in cross-functional data and processes management. This will be a key for PLM success in the organization. And this is still not happenings…

What do you think about that?
Best, Oleg

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

Can I Report to My PLM from Audi A8 via Google?

December 21, 2009

A very short prompt this early European morning. Google is coming to the next Audi A8. Take a look on the nice photos on Google’s blog.

This is what written in the blog:

To help you figure out where you want to go and how to get there, we’ve also brought Google Maps and Local Search into the A8, and linking it to your desk. You can send business listings directly from Google Maps to your car: search for an address at your desk, send it to the car, and by the time you go to the parking lot your car will know where to go. While in the car, you can use Google Local Search in the same rich quality as at your desk. Imagine you get hungry on the way or want to find a cinema – simply perform a live Google search on your car navigation system and immediately get up-to-date, rich and relevant results.

Now my question is quite simple. Google might collect information about users of A8. So, if you will be driving your next A8, in potential, all systems can report about their performance via the Google’s board navigation system. As you can see on the picture, systems are online… Ha! Don’t you think it will be just cool?

Holiday Greetings!
Best, Oleg

3 Comments | Future Trends, PLM Prompt | Tagged: , , | Permalink
Posted by olegshilovitsky

Large Monolithic PLM Implementations Are a Thing of the Past

December 20, 2009

Continue my last week post about how to make next PLM implementation simpler, I decided to put some ideas towards how the next PLM implementations will look like.

PLM vendors are making huge efforts to simplify PLM deployment and make implementation simpler. Despite that, in my view, typical PLM implementation is still combined from three typical steps: a significant planning effort, deployment of software and additional customization and adaptation services. These steps make implementation expensive. Talking with PLM specialists and consultants you will learn the most important PLM activities are related to good planning upfront, methodologies and clarification of what organization need and how to math organizational needs to capabilities of the system. Gaps are covered by services.  It looks like a deadly connected circle. How we can break it?

I think many of PLM vendors and implementers made a misinterpretation of out-of-the box terms. What is currently proposed in PLM “out-of-the-box” package is an effort to create “standard PLM”. What you can hear around is additional activities how possible to create typical industry implementations, OEM/supplier oriented typical implementation, etc.

In my view, this is a dead-end in PLM evolution. Such efforts will be endless similar to multiple standard activities in product development. The main reason for that is because manufacturing these days need to be more agile, lean and dynamic to sustain in their business and making profit. When such fundamental for their product development system like PLM becomes “typical”, you cannot expect them to be dynamic, lean and efficient at the same time.

What is a possible solution? I think software vendors need to learn again lessons from 15-20 years back. In beginning of 90th, few companies were doing PDM. Such projects were considered as luxury, needed by big organizations only. PDM budgets started at six digits numbers and requires major involvement of software vendor, custom software builds and long project implementation time line. However, in the middle and end of 90th we had chance to see a strong trend towards flexible data models, inexpensive Windows based systems and as a result lower entry barrier for PDM implementation.

My conclusion today. Vendors need to leave magic-out-of-the-box marketing efforts and depart to the new station where we’ll able to find new engineering solution for old problem. Future systems will be adaptive, will not require a significant effort to deploy and implement.

Just my thoughts. YMMV…
Best, Oleg

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

How to Simplify My Next PLM Implementation?

December 18, 2009

Siemens’s blog post by Nik Pakvasa and following discussion drove me to put my thoughts in the this direction- how to make next move in my PLM implementation easier? The complexity of PLM implementation is one of the fundamental problems that prevents Product Lifecycle Management industry from mainstream expansion and deployment. When a customer likes all ideas related to how keep track of data and processes about products and around, the implementation becomes a nightmare. PLM vendors did a lot on the way to simplify products and their deployment by providing packaged out-of-the-box implementations, best (or useful) practices related to data models and process implementations. However, the better solution is definitely required.

Business is very dynamic these days. Customers challenged by competition, cost, need to adapt their business processes to the new conditions of business, etc. All these put a fundamental requirement for change in business systems, and PLM is standing first, in my view, in the line of these changes. Whatever happens – outsourcing, optimizing manufacturing or design process changes, the ability to adapt PLM system to the “next PLM implementation” becomes fundamental. However, most of them are not as simple as we want.

If you are looking on additional information about this topic, I can also advise you fresh CIMData paper analyzing customer migration challenges based on their experience with three Siemens PLM customers. Note, you need to make a registration on Siemens PLM web site to get access.

My analyzes shows three most important reasons why “my next PLM implementation” is always complex.

1. Insufficient flexibility of PLM systems. For the first time, you may think I’m kidding, right? In most of the cases, the perception of PLM system is that this is a very flexible outfit. However, if you will take a closer look, many of PLM systems have no consistent flexibility that customers can rely on for many years. Next big things, new releases, improved functionality,  new technologies – all these can create a very complex situation for customers.

2. High level of customization activities. This is a very typical for industry. Each PLM implementation contains a significant amount of services that include system configuration, adding of functionality, integration with customer’s systems like ERP and others. The amount of such implementations is so significant that becomes one of the key questions when the customer want to change/move existing implementation. Amount of testing and adaptation that need to be done make this project very complicated.

3. Lack of standardization activities in PLM-related industry space. Standardization is a very expensive activity. My best take on standards is as following: Standards like toothbrushes – everybody needs’em, but nobody wants to use somebody else…  If we can imaging that level of standardization in PLM space can be improved, reliance on these standards can be great help.

I want to say few words also about “out-of-the-box” (OOTB). It presented as the universal hammer to solve the problem of PLM implementation, OOTB is a Trojan Horse in PLM industry town. In my view, OOTB provides a simple answer on how to implement PLM system fast for the first time. At the same time, OOTB is not providing any advantages in simplification of my next PLM implementation step. OOTB should come in balance with flexibility and system openness – this is the only way to get PLM to the next level of maturity in implementation.

So, what are my recommendations today?

1. Invest in PLM system openness and flexibility
2. Simplify your customization functionally and technologically.
3. Plan small steps in your PLM implementation journey.
4. Sponsor standardization activity – this is future health of the industry.

Just my thought.
Best, Oleg

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

Will PLM Get Troubled by Future FOSS databases?

December 17, 2009

The following article in TechWords “The New FOSS Frontier: The Database Market” drove me to think about PLM and RDBS relationships from a different angle. For PLM, as for all enterprise applications these days, RDBMS is almost commodity. PLM supports all of them (actually there are not so many – Oracle, MS SQL Server and DB2, who else?), cost of RDBS solution is insignificant since it either included into premium cost of PLM or RDBMS is already available in the organization.

Nevertheless, I think, things may go wrong. I see two aspects where PLM providers can be impacted. Here is my view on this.

1. Cost of PLM software. Introduction of FOSS into the enterprise domain can drive customers to think about the future cost cutting in software. With today’s huge payments for RDBMS, enterprises don’t see any other alternatives and continue to pay to ERP, PLM and other vendors. Tomorrow their expectation will be different.

2. Reliance on RDBMS vendor status quo. PLM systems are heavily relying on databases in general. Also, some of PLM systems are tuned for a specific RDBMS features. What will happen if PLM will lose RDBM anchor in enterprise?

So, what is my thoughts and conclusion today? Ringing bell of free should awake some of the sleeping PLM behemoths. Tomorrow the situation be a different and customer’s perception on enterprise software can change, just if a small fraction of enterprises, will be switching from licensed RDBMS systems to FOSS rivals. So, PLM better to come prepared.

Just my thoughts.
Best, Oleg

8 Comments | Daily PLM Think Tank, Open Source, PLM and organization | 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

Back to basics: Multi-CAD and PLM

December 15, 2009

How many CAD systems do you have in your development organization? I do believe more than one. And if you will think about your Product Lifecycle Management future, the obvious need is to connect your multiple CAD environment in the way allows you to manage all your design records, reference your design information in processes, allow downstream design usage in ERP and manufacturing systems. Today, most of the systems claims support for multi-CAD environment. So, what is the deal? I’d like to outline the following characteristics and vendor’s trends in this space:

1. My CAD vs. other CADs. For PLM vendors with origins in CAD space, own CAD systems will be always a priority. This is natural for business and much easy for development to support CAD system that making the same product development release cycle as PDM/PLM environment. Vendor’s “my CAD” interfaces may have additional features that will not be available for “other CADs”.

2. CAD/PDM bundles. Due to previous trend, I can see forming of stable CAD/PDM bundles that provide tuned functional characteristics. Autodesk/ProductStream; SolidWorks/PDMWorks; SolidEdge/TeamCenter; NX/TeamCenter; CATIA/ENOVIA etc. Such bundles can be best in class solution for a specific CAD.

3. No CAD files. This is a very new trend. Introduced in CATIA V6, this trend represents technological morphing of CAD and PDM/PLM environment into a single entity. (Note: With future of Cloud/SaaS, this type of software architecture, can be potentially a very interesting approach, but I will discuss it in separate post).

So, what can be the possible strategy for a company to support multiple CAD in PLM environment? I can see two possible and very obvious options.

Option 1: Focus on PLM vendor selection, choose your PLM environment and maximize usage of multi-CAD interfaces provided by this vendor. If you also thinking about possible reducing of CAD system usages and/or you shifting from multi-CAD environment to “primary CAD” option this can be a good option, in my view.

Option 2: Implement best in class CAD/PDM bundles and think about separate provider of PLM products, services, environment. You can find more appropriated to use PLM system provided by your ERP vendor or use some alternative technologies to build your PLM environment. I posted about this option earlier this year (Which Technology Can Convert Multiple PDMs into a Single PLM).

So, what do you think about these options? Can you share your experience? I’m interested to get your comments and thoughts.
Best, Oleg

12 Comments | Daily PLM Think Tank, PLM Basics | Tagged: , , | Permalink
Posted by olegshilovitsky

Back to basics: PLM and Single Point of Truth?

December 14, 2009

I’m continuing with a set of ‘back to basics’ questions and discussion. My topic today is about singularity or what known in PLM as “a single point of truth”. I remember the time before computers were widely spread in engineering and manufacturing organizations and people used “Drawing on the wall”. The famous statement back to that time was – if you see drawing on the wall, think maybe there is “another wall”. Computers supposed to resolve the problem of multiple walls. However, the problem becomes even worst. Now you may have an unlimited number of “electronic walls” in your email system, disk on your laptop, server in your location or different enterprise systems. PLM comes with a very promising and illusive statement about single point of truth. From PLM standpoint, it defined as capability (or ability) to manage single (or unique) version of product data in your organization.

Now, my questions today about how to manage this uniqueness? Is it something you can see as an achievable goal for your next PLM implementation or wishful thinking? Is it something we can realistically implement in the organization with all systems we have in place? Can we achieve it in a single shot, or we need to have multiple steps to get there?

Here is my take on this (and I’m making it the most provoke as I can think about).

1. PLM Singularity (or single point of truth) represents a fundamental interest of people in the organization to organize and manage product data.
2. We can implement it in the organization, but it requires a significant effort that may vary depends on organization complexity and number of other systems involved into product development process and number of geographical locations company plan to cover by this system.
3. Implementing of singularity may take multiple steps until it will be achieved in the organization.

So, what is my conclusion today? I think, singularity cannot be considered as a goal for PLM implementation. The final cost can be too heavy to carry, and it will take long time to get there. Realistic PLM implementation need be done as “go by steps” approach. Each step will achieve goals helping organization to resolve specific issues they have in the organization or optimize existing processes. This is the only way to create something I’d call – lean PLM. If you want to implement single point of truth, think about playing “singularity chess” before :) . (thanks, Paul Burgess blog for picture)


Just my thoughts. I’m looking forward to your comments.
Best, Oleg

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

« Previous Entries