Archive for August, 2007

Master Data Management - Ruling An Uncharted Territory

Thursday, August 9th, 2007

When we encounter multiple “versions of truth” - we have a natural inclination to try to quickly sort out whom to believe and whom to double guess. Our preferred information sources also aspire to become exquisite “go to” places for all our information needs. However, not all sources are equally good in managing all types of information, some are closer to the action where the information is generated, others are more like second hand reporters. Then we usually end up with multiple sources, having more faith in some over others for specific information, trying to use aggregation and abstraction techniques to further streamline our information feeds and eliminate noise and distraction perpetuated by out of context data. Over time, we all develop our own techniques for information management and have our own master sources and broadcast channels.

Social approach to information sharing is dominant when it comes to business related information, too. We trust more people whom we believe and know well than any formal source of information. There is something what I call a “3Meta” effect here. First “meta” comes from our selection of trusted sources. These can be people, selected official channels and systems. Second (middle) meta comes from our belief that these people or systems indeed have access to the best possible information. Third meta is our final recognition that the information is in fact exactly what we are looking for. Database designers and application architects deal with the third meta only. They design and maintain meta-schema that define the values, meaning and association of different data elements stored in information repositories, and they consider use cases of immediate users of the database and application. System integration architects control the second (middle) meta, providing rules for data distribution between systems and for security of access to the information. First meta is not formally managed. It is a fluid set of preferences that we all establish for ourselves based on our own experience and under some influence by others.

Here is the most dominant information management cultural phenomenon: the more widely used the information the more important the first meta (who are you getting it from), the more specific the information the more important the third meta (how is it stored in the information repository). In other words, we tend to entrust systems (generally better equipped then people to manage large amounts of complex information) with more mundane type of data, leaving key bodies of critical and widely shared information and corporate knowledge to the social network and much less formal information management practice. This cultural phenomenon becomes very significant when we take into consideration growth and constant morphing of business processes and supporting information systems.

As a natural bridging point, we then try to address the “middle meta”. This is commonly called master data management, e.g. establishment of rules and guidelines for the life cycle of critical shared information. These rules can be who can create data, who can access, who can change and modify, how to name it, how and where to store it, how to retrieve it, and so on. On average, I found several dozens of attributes defining various aspects of managing master data. And they often cover only transactional information (orders, customer billing and shipping info, resources, logistics, inventory, product configurations, materials, production and supply chain meta-data). There are two problems with this approach to master data management:

1. It is conceptually just an extension of the application/database approach (third meta). Externalizing master data from multiple applications can cause significant release synchronization and maintenance overhead, knowing that all applications now have to adjust to the common definition and implement interfaces to the external master data registry. This approach can also reduce speed of implementation and cause degradation of performance and functionality of certain applications required to conform to the master data approach. Inevitably, this approach can work well only when fully complemented by enterprise wide process management and business architecture strategy.

2. It works only for structured and well defined data. However, most shared information that is of high value to strategic users is not conforming to any sort of structured meta-schema. Consequently, they will resort to the first meta (captured only in their brains) to organize and manage their access to the information. This way, most critical strategic processes will stay firmly detached from the middle meta layer.

With these two problems in mind, it becomes very important to establish real value of master data management using a middle-meta approach (commonly followed today by Oracle, SAP, IBM and others), considering its limited impact to corporate agility and speed, given cultural challenges and total costs associated with implementing and operating it. Current master data management approaches often only deliver (relatively minor) cost savings associated with pure administrative aspect of collecting and distributing operational meta-data. It is much more pragmatic approach to consider master data management as a part of the overall strategy for enterprise agility and adaptability, particularly in the context of overall business process architecture, service oriented architecture and more fuzzy, but often more differentiating assets (such as knowledge, brand, intellectual property).

Having considered pros and cons and ability to manage all three metas, in any global manufacturing company that develops its own products, enterprise master data focus should shift away from normalizing operational data by middle-meta, and into top down approach addressing product portfolio management, knowledge reuse and intelligent information search ontologies. Addressing first meta first, by modeling and understanding corporate social circles, patterns of decision making, abstraction levels of decision criteria and alternatives, information retrieval routines by administrative and decision support staff, security and access control, shared ontologies that executives use to communicate and make decisions, may reveal more about the true state of maturity and true needs for master data management then simply bottoms up integrating systems that can be manually reconciled with an affordable approach if the shared data is strategically assessed first.

In conclusion, be careful what you wish for when preparing for master data management. Inevitably, your master data management will hinge on your PLM architecture - from the front of portfolio management to the back of BOM release. Address all three meta layers before you determine where is the highest payback. You may be surprised to discover where should you focus first.

Posted in Uncategorized | No Comments »

BPM in PLM - Modeling Language Trade-off , We Have A Winner

Friday, August 3rd, 2007

Process modeling language and tool is an important component of the PLM framework. I have been asked by clients very often - what modeling language and tool is the best choice for PLM? Obviously, the answer depends on the methodology, or methodologies that the framework incorporates. Various tools are often needed for different steps in the methodology. For example, for value stream mapping and fast analysis of cycle time and variability - Value Scape may be an excellent fit, while for planning detailed implementation of SAP by mapping process to digital assets and functional coverage - ARIS is excellent fit. Suffice to say, PLM framework is not going to consist of only one modeling tool. Unfortunately, many IT strategists believe that corporate standards for process transformation using BPM are about tools and not about methodology. Thus, I have seen awkward modeling choices that result in sheer frustration and often abandonment of otherwise sound methodology. One of PLM architects I talked to recently made an interesting comment on corporate IT standard for BPM tool: “I won’t complain when I have to use a wrench to hammer something in place here and there, but too often I feel like they are forcing me to use a hammer when I need to tighten a bolt.”

Let me go back to the original predicament: what modeling language and tool is the best for BPM in PLM? At minimum, two requirements stand right out: fidelity of process representation and execution.

- Process fidelity: PLM processes are dynamic, not following stable and repeatable flows. They involve dynamically changing rules, conditional iterations, human decisions, versioning and configuration management of inputs and outputs, and often require high-performance computing services to sort out meaningful information from a huge amount of complex data. For example, to be able to represent all possible data flows in structural analysis of an airplane wing, one may have to provide very granular (fine grain) definition of all inputs and outputs and conditions of their processing at each step in the flow (e.g. some inputs may be mandatory for some tasks to proceed, some are processed only if other inputs are available, some are single instances per processing step while others are processed in a batch, some are version controlled for each iteration, others are kept frozen during several iterations, some are processed only if certain design rules are in effect, others are processed only upon an event of certain parameter reaching certain threshold, etc.).

- Execution. On the other hand, detailed process flows are of little use in PLM unless they are executable in run time exactly the way that their description says. Detailed PLM process definitions cannot be used as specifications for programming, since their complexity and dynamic character make it completely impractical to code and change the code as often as the process changes.

There are many other requirements, but these fundamental two establish quick filter for candidate modeling languages, because they address both required speed of change and much needed consensus on the process coverage.

There are many process modeling and execution languages available addressing these two requirements, but often emphasize one over the other. Unfortunately, very few address both requirements with satisfactory results. BPEL for example is executable, but can naturally express relatively small spectrum of PLM processes. It is based on pi calculus approach that best addresses messaging flows between systems following agreed upon transactional sequences and processing conditions. However, BPEL is not a natural choice for execution of open-ended collaborative processes that involve context specific reasoning of humans, rule based iterations and dynamic reconciliation of processing conditions. On the other hand, BPMN is rich annotation language, but cannot be executed in its raw form. It can be exported into BPEL format, but then it limits many useful features of its constructs that enable capturing structural richness of the PLM processes.

This area is new to PLM architects and they are often quickly disillusioned when testing approaches touted by vendors who (somehow too often) lead them the wrong path offering either BPMN or BPEL or a combination of the two. Observing deployments in other industries where complex collaborative processes demanding content reconciliation are the norm (homeland security and life sciences for example), I found that currently best choice of modeling and execution language for PLM is CPID that offers both rich expression and executable XML format. CPID is based on SOA IM standard reference model issued by VCG. It combines the best of BPMN and BPEL, offering high fidelity process representation in an XML format directly executable on SOA VM (SOA virtual machine) based on the SOA IM standard reference model. Another important aspect of CPID is that it is based on the ontology that equally applies to content and context reconciliation, thus is best suited for collaborative processes that need to span multiple systems and multiple disciplines sharing federated content.

Posted in Uncategorized | 1 Comment »