A blog by Oleg Shilovitsky
Information & Comments about Engineering and Manufacturing Software

Do we have problem managing history and time in PLM?

Do we have problem managing history and time in PLM?
olegshilovitsky
olegshilovitsky
10 June, 2009 | 4 min for reading

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:

Google Wave Playback -1

Google Wave Playback -2

What is your view and how do you see time and history managed in our systems in the future?

Recent Posts

Also on BeyondPLM

4 6
17 June, 2009

I was thinking about future options for PLM in today’s computing environment. In this fast moving world, there are two...

9 August, 2019

One of the most commonly used PLM sales scenarios is to sell it as an expansion of existing PDM system....

11 April, 2013

For many years, enterprise software was known as a place where development of new features was one of the main...

6 June, 2021

My recent articles about PLM vs ERP exposed how deep is the division of data and power in organizations. Many...

1 February, 2018

Thinking about SaaS application race? You’re not alone. Some companies cannot agree with new landscape of applications. As such, Oracle...

15 December, 2013

PDM is not a new domain in enterprise, engineering and manufacturing software. It might sounds like PDM functions are clearly...

23 September, 2015

I started a series of blog posts about PLM dedicated to hardware startups. In my previous article, I explained why...

12 August, 2010

Scaling up is a tough problem. I want to talk today and PLM Software scalability in unusual aspects – business...

11 August, 2011

Finally, my vacation over and Beyond PLM is back to normal. While screening materials, the following title caught my attention:...

Blogroll

To the top