Pragmatic Architectures for PLM Future

September 30, 2009

Picture 9I think, we’ve faced many changes during past few years related to how enterprise software is going to be implemented. Shifts in business models, new social and cloud technologies, demand for free software and many others. Thinking about all these challenges and changes, I want to discuss what is potential outcome and impact on Product Lifecycle Management architecture and implementations.

In my view, we came to the point when PLM is adopted as a business methodology and business strategy. However, I think we still have a huge gap between understanding of business practice and technologies and implementations we have in the field. So, proposed principles are my ideas about to define a pragmatic PLM architecture for the next 5-7 years. I’m taking this time span, as something that allows us to change fundamental architectures of the systems and not only make cosmetics tweaks.

1. Individuals Interaction and Process Tools. What should be an approach to design process tools? It looks to me, the key capabilities should be in the way a specific user (individual if you will) can impact overall process design and process management in the organization. Process tools need to move from space where people are divided into “process planners” and “process execution”. No more “build vs. run”. The individuals in an organization will need to define right processes and be able to improve as business change in the organization.

2. Customers Collaboration. I think, we move to the space where a customer will decide how to assemble PLM system from a flexible set of PLM services. Those services will be developed and providers by PLM suppliers. However final system configuration will be defined by customer and answer to the specific needs of business and organization.

3. Permanent Change as a key factor to improve software.
Changes become a key factor in PLM architecture adoption. Today’s systems are very expensive in case you want to make a change in their configuration, data model, implementation practices. This is something we need to work on the future. Cost of change will be key driver to successful PLM implementation. Change is on going procedure. Together with future SaaS models it will finally remove the need in planning precise PLM implementation phases from year to year.

4. Working Software over Methodologies and Documentation. This is last, but very important. No more documentation. Architectures need to allow people to learn how PLM system works, systems will become self explained and self documented. In the same way, you can discover software code, you will be able to discover PLM implementations. This will be a future role of PLM architects in the organization.

This is, of course, not a recipe how to build new PLM system. However, I do so sense in these principles to think how to change enterprise PLM software in the future.

Just my thoughts. As usual, your comments are welcome!

Best, Oleg

PLM Prompt: A Roadmap to PLM Success?

September 30, 2009

I wanted to share with you funny picture from flowingdata. This picture reminds me a lot about PLM implementations and various PLM methodologies. Nevertheless, now, let me ask you few serious questions.

What is a roadmap to PLM success in the organization?

What is a roadmap to successful PLM implementation?

I’m going to think and blog about this next week, but would be interested to hear your voices…

Best, Oleg

Accidental Collaboration using PLM

September 29, 2009

Picture 6I’d like to think about how to improve collaboration… So, why I’d like to talk about “collaboration” again? We got enough collaboration for the past years in PLM. Our primary focus was on how to enable collaboration by seamless access to design, models, visuals, processes in the end. Even so, this is exactly my point – we enable collaboration when people actually ready to collaborate on something. If you are sending request to you colleagues with a specific 3D fragment, problem, issue etc. All these situations can be grouped as “intentional type of collaboration”. Your intent is to collaborate, so it makes things easy.

Now, let me come with a different type of collaboration – accidental. For me, the main distinguished situation in this case, that this type collaboration happens not according to the initial intent. So, you are not allowing people to collaboration with you, but use information created by somebody else to collaborate on the specific topic. I will give you few examples of accidental collaboration: 1/ your discover a specific design problem happened to machine you design in the past; 2/ you are analyzing support case and discover how to improve machine or process; 3/ you are looking on revenues from your products and discover something specific comes out of machines or products you are working on.

Now, what is similar in all these situations (and maybe you can come with something in addition). You have no specific intent to collaborate. A collaboration happens by accident when you work in the context of a specific set of data. This specific set of data is not created for this collaborative purpose, but was created by somebody else, or even a result of combination and/or manipulation on data. Sounds like simple, right? However, in my view, this is terrible missed point in today’s collaborative systems. Most of the tools to support accidental collaboration, today developed by implementation services and target a specific customer need. There is very little generic support for such tools.

So, what should be done, in my view to improve PLM ability for accidental collaboration? Below are few proposals how we can better facilitate accidental collaboration:

1.     Usability of product data representation. As much more we will be human oriented, more information will be available for users

2.     Use “contextual patterns” of user experience. Facilitate presentation of information in the context of particular topic – user, product, operation, requirements, customers.

3.     Improve annotation capabilities. Improve an ability of the system to annotate information. It will allow to create additional data, contextually connected.

4.     Improve data portability. We need to have an ability to transfer data between systems in enterprise. It will allow transparency and connection of information.

5.     Improve Business Intelligence. To have additional BI capabilities will allow to mine and extract data, previously hidden from users.

I’m sure this is a not exhaustive list of needs. However, following these needs will allow to streamline collaboration significantly. How do you see it? Do you have similar cases in your organization? Does it make sense to you?

Best, Oleg

PLM Prompt: Google Site API enables PLM collaboration?

September 29, 2009

Interesting blog post from Google Enterprise. Import, Export and more with Google Sites API. What turns Google Sites to much more configurable and available for customization and tweaks for different cloud based scenarios. Google Blogs comes with two scenarios:

1/Open/Import projects;

2/ SharePoint Move for Google Sites.

Picture 4

I’d not be surprised if small manufacturers will be able to check these capabilities for external collaborative needs. Just my thoughts. What is your opinion?

Best, Oleg

PLM Prompt: Enterprise Buzzwords or How Many Applications Do We Need?

September 28, 2009

Picture 2Interesting post few days ago. What is very annoying is the number of buzzwords growing in the enterprise system world. Do we really need all of them? Is there overlap? How many times you faced situation when you and your colleagues are using different words for the same thing?

Here is the short list (thanks to Improve Process Blog)

• CAD (Computer aided design) to support modeling of hardware and electrical/electronics
• PDM (Product data management) systems to support data management
• PLM (Product lifecycle management) systems to support workflow, engineering change, bill of material management, release to manufacturing etc.
• MES (Manufacturing execution systems) to manage work in progress on the manufacturing floor
• CRM (Customer relationship management) systems manage, track and organize its data / contacts with its current and prospective customers
• BPM (Business process management) systems provide process management capability with workflows
• SCM (Supply chain management) systems provide the ability to manage the entire supply chain and support planning, sourcing, manufacturing, delivery and return logistics.
• KM (Knowledge management) to support knowledge sharing of best practices and lessons learned.
• SRM (Supplier relationship management) to support managing vendor relations and lifecycle.
• PPM (Project Portfolio Management) systems used for analyzing and collectively managing a group of current or proposed projects.
• BI (Business intelligence) systems help the business acquire a better understanding of its commercial context.
• EMM (Enterprise Marketing Management) systems manage marketing’s end-to-end internal processes including Web Analytics, Campaign Management, Digital Asset Management, Web Content Management, Marketing Resource Management, Marketing Dashboards, Lead Management, Event-driven Marketing, Predictive Modeling etc.
• HRMS (Human resource management system) or HRIS (Human resource information system) manage all processes within human resources.

Best, Oleg

PLM Prompt: Integrated PLM and ERP – Killer Ideas or Controlled Innovation?

September 28, 2009

Picture 1Short prompt in the beginning of the week. I was reading post from BSW “Killer Ideas And Controlled Innovation: Why you need to integrate PLM and ERP?”. First of all, an idea of integrating PLM (back 15 years it was PDM) seems old. I remember myself in the early beginning of my data management activities around AutoCAD back in 1993, an idea of communication between design data management system and manufacturing systems was highly important. But, I think, this problem is still not resolved.

So, is it a killer idea? Or may be the successful approach in integrating PLM and ERP can bring real innovative future?

Just my thoughts.

Best, Oleg

How to Unleash the Potential of PLM 2.0?

September 25, 2009

The term “management” is very misused, in my view. Long time ago, somebody told me if you don’t know how to call it, call it “management”. So, Product Lifecycle Management :)… How we can move it forward? I have heard a lot of discussions about 2.0 trends for the last few years. It started as Web 2.0 and after moved to different areas of our life Government 2.0, Enterprise 2.0, Library 2.0, Everything 2.0 etc… So, finally, thanks to my colleagues from Dassault Systems, we have now PLM 2.0. I had chance to talk about various aspects related to PLM 2.0 and this is my next attempt to discuss and churn again about the PLM 2.0 topic.

Management Minimized, but Not Eliminated.

I think, management is a really outdated term in the context of software. Like a combustion engine, management as a technology is largely stopped being developed. In order to realize the full potential of organization we need to focus on a process or, saying differently, on how to marshal resources and activities to achieve our goals.

Many times in Product Lifecycle Management we are trying to lay down a structure design, engineering, manufacturing, dependencies between them and later enforcing software to manage it to get maximum of business potential. This is an obsolete approach in my view. The right one structure comes from real business context, from specific business needs. In this case PLM will become real enabling technology and not “management” technology.

However, what is going on around? There are few interesting 2.0 trends I can see in PLM going to PLM 2.0:

1. Expand. This interesting trend represented, in my view, in DS V6. I give full respect to my colleagues in Dassault System. This approach allows to resolve many problems in the organization of development, manufacturing and other business processes. Common model used in this approach can solve lots of problems as well as collaborative business applications leveraging common infrastructure. Since now, everybody will be able to collaborate in much more efficient way. I think big ERP vendors are also pretty much following the same ideas laying down fundamentals of ERP platforms to serve needs of product development and manufacturing.

2. Integrate. This is another approach. In order to achieve the next level of productivity, PLM content and process is going to be integrated into the environment that much more social and less formal. Different ideas about how to integrate PLM products or content into business process suites, office applications, web portals, IM-tools. In my view, you can see a very interesting example of such approach in PTC’s Social Product Development strategy. Going hand-by-hand with Microsoft’s SharePoint, processes can be easy integrated and distributed, if you will.

3. Socialize. This approach is shifting 180 degrees to the people. Let say, people first (opposite to “product first”) we need to care how to organize contextual communication by providing flexible space to do it. You just take what you need into this space- Bill of Material, Item, Drawing, Contact, Mail etc. The importance of contextual and not formal collaboration is taking top priority in such approach. I liked to see service offer a way to collaborate without boundaries. The biggest advantage you really don’t need “to manage”, but just to collaborate socially. What need to be prevented is organizing of “yet another informational silo”.

So, to unleash the real potential of PLM 2.0, PLM need to lose the “M” part. This is not about management anymore, but about how to help to people to realize potential of organization to design, manufacture, sell and maintain products and ideas. One of the best non-technological books I had chance to read last time was “The Opposable Mind“. PLM needs to get out of traditional “management” ways to think and transform PLM to PLM 2.0.

Best, Oleg


Get every new post delivered to your Inbox.

Join 288 other followers