I’d like to continue yesterday’s discussion about PLM basics and talk about our ability to manage history and time in Product Lifecycle Management. Since PLM is about *Lifecycles*, time and history are very fundamental pieces, I found that they are not actually managed at the appropriate level.
Let’s look at what we have today in most of the systems. There are two basic definitions related to history and time. The first is *Revision*. Without going into the complexity of defining revisions, versions, and various management patterns of these revisions and versions, I can say that a revision is an explicit characteristic of an object in the system and can be applied (with different behaviors) to documents, parts and some other objects in the system. The second is *Effectivity*. In context of our conversation, this characteristic is related to the specific date from which information in the system is valid when applied to the objects we are managing. For example, we may have a Bill of Materials effective for today and for the next month, etc.
Design Systems: Most of the design systems are implementing and supporting revision concepts. This is natural for a system and designer behavior, but they also burden their work as they are not in particularly interested in knowing the number of revisions they have today. In most cases, the system implements revisions in order to track changes in design in other places in the system (i.e. ECO etc.).
Operational Systems: Most of the operational systems are fundamentally time-oriented. This is mostly related to ERP and their manufacturing and operational modules. Effectivity is a characteristic that applies to almost everything in these systems, such as parts and BOMs. Obviously, Revision and Effectivity based systems are very hard to integrate as a single system, and bridging these different behaviors is not simple.
Where do I see problems with today’s system from the standpoint of management of history and time? The biggest problem, in my view, is that all these characteristics and parameters are secondary next to how the system manages data. We can apply them on an object in the system, but we don’t manage time/history as a core operational behavior to apply to everything – definition of models, objects, processes, changes, etc. There are two main aspects (1) Definition; (2) User Experience. Although they are different, they are certainly dependent since you cannot achieve a specific operational level in the user experience without being able to define time/history level in the information you manage.
Definition: There are many elements of Product Lifecycle Management system today that do not allow you to apply *time* as a characteristic of this element. The most straightforward example is that you cannot manage differences in product data dependent on time. In most of the systems, if I change a definition of a Part or a Document, these definitions need to be applied to everything I manage in the system. I’m sure that some implementations, can resolve such a problem on a particular implementation level, but this is not a core system behavior. Another problem is to manage functional characteristics of the system based on time. In today’s dynamic world, there are situations where a certain functionality of the system (i.e. compliance), need to be applied to products with a specific date/time/history perspective. To make it seamless is very problematic, in my view. In most cases, you can change process definitions and manage the process definitions as snapshots, but this is will be an artificial task, since you will define it explicitly in the system. Another issue, in my view, is the ability to keep track of changes in the system and query it on a timely basis. This functionality is mostly not available.
User Experience: User experience is complex and simple at the same time. We can allow a system to present time in the part of the system where it is available. But there is no system today, in my opinion that allows you to use time as a fundamental operational element from the user experience standpoint. Here is my point. I think that most people work in a timely manner. Our memory is associative with time. We can remember what we did yesterday and we can remember part of what we did 2 months ago. I think that the user experience of a PLM system needs to be aligned with the ability to operate systems in timely manner. It will make a system more natural in its behavior and also easier understand.
To end this post, I’d like to point on Google Wave Playback feature. Even if Google Wave is not pretending to become PLM system, the way changes made in Wave was presented actually was very impressive and has a lot of potential for future collaborative systems. This means, of course, not only for Product Lifecycle Management J.
Google Wave Playback Function Demo:
What is your view and how do you see time and history managed in our systems in the future?
Pingback: Who Owns (or Pwns?) PLM Master Data in Your Company? « Daily PLM Think Tank Blog()