Large projects are complex, involving multiple products, disciplines, methodologies, techniques, systems and stakeholders. They often fail to meet expectations, schedules and budgets, and results are often poorly validated and managed. Current IT support to project definition, planning, execution and management is fragmented and rigid. Lifecycle data exchange is transformative rather than evolutionary. Innovation is not driven by evolution, embedding experiences and lessons-learned. There are many uncertainties and unknown dependencies in the early phases, many nonproductive meetings, stove-piped and sequential information flows, poor data management, and limited knowledge sharing. Collaborative design, cross-functional team working, and service composition are inhibited. Work environments and user interfaces are rigid and discipline-specific.

This post raises the questions: Are we wrongly trying to generalize and program creative work, collaborative and adaptive environments, and human behavior? Are we doing right to standardize properties, embedding their parameters and values in code? Can this approach serve complex customers with dynamic demands for controlling dependencies, supporting innovation, and automating adaptation? Read the rest of this entry »

Advertisement

Business processes are commonly defined as a set of related activities directed at producing an outcome. In bureaucratic case processing, the outcome is typically a decision, which is documented in a case file and communicated using e.g. formal letters. For the management, improvement and automation of some of these processes, BPM and workflow systems are adequate. Knowledge intensive processes like engineering, design, and construction, however, produce outcomes that are far more complex. To manage, improve, and automate such processes, we must design product models and process models in parallel, with evolving product structures as the core and foundation. This post presents a case from oil&gas field development, outlines why a product-driven business process management approach is needed, and how it is applied. Read the rest of this entry »

Computer support to Product Design and Life-Cycle Management is currently dominated by PLM systems, and industry is not very happy with the support provided. Industrial design methodologies and PLM systems create many disjoint, pre-typed product structures. This approach belongs to the era of communicating product knowledge as engineering drawings. In this post, we discuss the need for replacing these static structures by a single federated product model, from which any structure or aspect can be derived.  The federated product model is managed as a family of configurable system and component models, as part of an active knowledge architecture (AKA). With the advent of AKA we see completely new approaches, concepts, operational methodologies, visual modeling methods, enterprise architectures and design solutions emerging. Read the rest of this entry »

Product Life-cycle Management (PLM) systems have been developed and implemented since the early 1990s. Early solutions were based on a chain of application systems with proprietary user interfaces, information logistics and databases. At the turn of the century product data management standards, protocols and meta-data for application integration matured. Knowledge Based Engineering (KBE), process and collaboration capabilities were introduced. Ten years later customers are still not satisfied with the capabilities offered and value delivered by current solutions. Read the rest of this entry »