Useful or full featured?

I found a recent post from Oleg with a funny picture. This picture is better than a long discussion about what it is better to get:

  • a full featured PLM application
  • a useful application

Examples are:


I don’t know for a camper, but as a PLM user I am sure which one I may choose.

Unfortunately, most of the PLM applications we meet are of the first kind. Why? Some quick thoughts:

Complex business processes

BP are so complex that implementers simply choose to display everything to all users, having not the information about restricted usage per user or per group of user.

IT design

PLM is supported mainly by IT department which don’t know the BPs, or choose to mix many different business processes in the same application.

New capabilities

Introducing new functions without killing the previous ones which might be obsolete are increasing the volume. Always try to kill existing functions!

Lack of user feedback

I believe user feedback is not at the level today for enterprise applications, compared with what can be found on the web. Today, the smallest shoe vendor in the US provides a way to post comments about its products on his website. PLM vendors are far away from that practice. Even if some surveys are sent once a year into a company, the level of feedback provided is not at the level where it could be used.

What do you think?

SOA for PLM applications (and others?) – Is it really a good idea? Part 2

I would like to come back on that subject initiated in the first part some weeks ago. I exposed my vision of what is SOA, and how this could change the way we design an application.

I would like now to make a step back and look at the entire network of applications used by a given community. CIOs have to manage that network, and to work with business departments to manage the data flow between these applications. It is a tough subject, especially in big organizations, and CIOs have to focus on the right way:

  • to support business processes
  • to master the cost of the whole network

Numerous methods have emerged in the past years to target those objectives, and it can be resumed by BPM (Business Process Management or Modeling). For my point of view, there are three topics to address:

  • which data to export (business data and business decisions)
  • how to transport that data
  • where to transport that data

The benefit of SOA is for me to try to forget the last topic. Why? Mastering the whole network means trying to reduce the number of connections between systems. Several ideas come up to reach that objective: define the right data flow, eliminating the small paths or the bad path, which leads to business process reengineering initiatives.

In today’s world, this kind of schema definition has a short life time, and the business decisions can have changed when the whole schema is ready to be implemented or enhanced.

So for me, CIOs should focus on the two first points:

  • to establish a communication standard over the network, to support data and decision exchanges
  • to ask to application owners to publish which information should bring value to other communities.

This leads to published data. If one or several application owner needs this data, or only a part of it, up to them to take it, or to filter it. It will not change the connection point.

System architects will then have only to define which system masters which data. That’s were the mindset has to change, because it is unusual to publish data without knowing who will use it. It may be a first pragmatic step trying to kill silos, ie pushing people to think about which part of their data could interest other communities.

What do you think?

Product driven, Program driven, Concept driven, and more.


Today’s post is about trying to find communality selecting/defining a PLM application. Or in other words, trying to define classes of enterprises which may benefit using the same software to build their PLM application. Vendors usually market their offers, defining them towards the industry domain, like automotive A&D, receipe, etc. This segregation is usually not good enough, while in the same industry, several type of businesses may exist, and conversaly same business can exist in different industry domains. On the other hand, a lot of litterature exists about company profile, mainly to determine if a company is engineering driven or manufacturing driven, meaning often to check if it needs an ERP or a PLM strategy. I never liked this second segregation, simply obviously a company usually need both. Nevertheless a company cannot do everything at the same time, so somewhere the question has to be answered.

This topic seems today trendy, as John Stark today try to address the lack of standard in the PLM industry.

So I would like today to look at that question, but into a different angle which is the product focus. Because a company may have a special concern about building a new product:

  • Product Driven. I call Product Driven a company which is building new product by assembly existing ones, ie having a large amount of reuse across programs.
  • Concept driven. I call Concept Driven a company which has no reuse of products, but reuse of concepts already developped. Concept can group assembly methods, architecture, or manufacturing process.
  • Program Driven. I call Program Driven a company which is building a new product for a given program, not necessarily reusing part of existing product, nor reusing specific concept existing on the shelf.

For sure, this classification is quite theorical, as a company may have several businesses, oriented differently, or businesses which are a mix of above categories. Those companies may need/wish at the end to select between one or several approaches, starting to homogeneize practices and applications, but this is another story.

That being said, today’s game is to try out to associate a PLM dedicated technology to each given above category.

Are those product categories forming a closed set? Are there existing PLM technologies for each product category?

What do you think?