Lean extended enterprise and build-to-order induce better integration of PLM
activities that go through computer aided systems and knowledge-based information
environments [
Computer integration in the expertise chain aims to optimize this kind of relations and
thus the use of enterprise knowledge. The number of different enterprise concepts and
complexities caused by different interpretations of these concepts encourages
enterprises to standardize concepts and formalize behaviors. These efforts build re-usable
and adaptable platforms and imply deep business architecture redeployments [
The main difficulty encountered is to control the complexity of information
quantity and informality. A reduction of the work-structure diversity helps in this regard to
optimize the information efficiency. Seen from the process of collaborative document
writing, it is hard to guarantee the consistency of the document’s subject. The contents
of shared documents may deal with many subjects and fields, and every collaborator
would compose the text by its own understanding, different from other’s because of
different knowledge backgrounds. As a result the subject of the shared documents will
be inconsistent among many copies. Furthermore, the communications between
collaborative systems, the systems and environments will also influence the consistency
of the subject. An approach focusing on the semantic and syntax distinction can help
to resolve the consistency problems involved in collaborative writing [
elements are then identified, and the elements are deployed in a coherent manner to optimize their efficiency. It is the Architecture Phase. 3. The third phase is document generation by a validated knowledge-based application
First, the Enterprise Infrastructure is made off elementary concepts that can be
classed among process, products, resources and external effects [
The aim of this first phase is to differentiate concepts. The analysis of their
relationship is part of a second phase focusing on Architecture. Concepts “behave”
differently according to their context. The modeling of this structure and the analysis of its
possible evolution constitute the Architecture phase. The maturity of the infrastructure
knowledge leads to a restricted number of concepts. They are more relevant and
meaningful for defining the specifics of the studied domain. They are usually formed
by a general name (corresponding for example to UML Class) and a limited numbered
of typological instances (corresponding to UML Object) [
The sum of their behaviour constitutes an as-is platform from which all the business outputs are derived. Usually the platform is build informally according to the enterprise evolution. It raises incoherencies in concept levels or typology definitions. Concretely it can be illustrated by a misuse of a machine (unclear relationship between a process and a resource), an inefficient procedure (confusion in processes), or an unsatisfactory product (unconsidered external effects, badly defined core product conTO-BE cepts). In order to optimise platform efficiency, the roles of the Architecture phase can be defined as follow: x Ensure the coherency between concepts x Optimise relationships and build working environments x Evaluate model maturity and complexity reduction x Define a coherent integration method of knowledge in final products
The two following examples highlight how a domain Infrastructure and Architecture form an enterprise management Infrastructure. This global as-is state can be then redeployed through an enterprise management Architecture to ensure a better use of enterprise knowledge. ,,, ([DPSOH DQDO\VLV LQ LQVXUDQFH LQGXVWU\ GRPDLQ This example focuses on complex contract documentation found in insurance companies. It illustrates how the methodology introduced in this paper helped to analyse and improve the current Master Contract between the insurance company and its policyholders by first getting a good understanding of the current contract and its impact on the enterprise infrastructure. From this, improvements to the existing enterprise infrastructure could be made, and a new improved contract could be generated. A Master Contract governs all benefits and requirements between the insurance company and its policyholders. The complexity manifesting in the contract, also leads to complexity in the IT systems.
It illustrates how the methodology introduced in this paper helped to analyze and improve the current Master Contract between the insurance company and its policyholders by first getting a good understanding of the current contract and its impact on the enterprise infrastructure. In the event of a claim, the contract may in some cases be interpreted differently by the client and the insurer, leading to disputes between the two parties. The complexity manifesting in the contract, also leads to complexity in the IT systems. In order to configure the IT systems, the contract must be interpreted.
Ambiguous interpretations may lead to inconsistencies between the contractual terms and the IT systems, creating a legal risk to the company. Modeling of As-Is enterprise infrastructure, and developing of To-Be improvements.
The analysis of the paragraphs and the extraction of the paragraph concepts therefore correspond to understanding of the Domain Infrastructure. The next step is to extract specific concepts. Figure 2 : Master Contract Improvement Process.
From these contract paragraphs and to establish relationships to other enterprise concepts contained in overall enterprise ontology. In order to decrease the complexity and ambiguity of the Master Contract, it was necessary to firstly understand the contract, and secondly its impact on the enterprise is a whole. To summarize, ontology first help creating the as-is picture of the enterprise, giving an understanding of the enterprise, highlighting its incoherencies and guiding the to-be improvements formulation.
In a second phase, the to-be changes to the enterprise have been implemented (cf.
Figure 2). Consequently, the first ontology had to be updated in order to incorporate
the new evolutions.
,9 ([DPSOH DQDO\VLV LQ DLUFUDIW PDQXIDFWXULQJ GRPDLQ
In the world today, companies’ computerization forces to assume that computer aided
systems support design and manufacturing preparation phases [
The first task of the Infrastructure Phase is to systematically identify them through
documents, presentations and meetings. The justification of this work lies in the need
of visibility and understanding. The number of concepts and processes rapidly
increases [
The spine of the data model is progressively defined. Models are simplified by the identification of main concepts that are kept for rapid communication in the project team. The last category is induced by the introduction of a temporal link between process model and data model. The choices in scenarios become determining on the final platform efficiency.
The first uses entity classes to map the studied mechanical part according to the formalized knowledge.
The second uses tool classes to sort out relevant items and to open the structure to equipment evolutions. At the end of the pre-competitive phase of the development project, the expected gain is a ten factor. The resulting tool must still be completely deployed and validated by the industrialization phase. 9 &RQFOXVLRQV
The conceptual similarities between these two very different application examples reminded on Table 1 encourage both teams to structure their work in a similar methodological approach. Naturally similar kinds of problematic are encountered, implying
Informatics automatically works on algorithms to FEAG;< + " %’&( MONQPSR TVUOW X’YZ\["W XS]_^ L9 "/.101/2& 3 "41&/ " ]Ma‘1T\PSR W X’YZa[W Xa]_^ ! "## $ #*) 6578 9:8 <; => ? ? D JKA9@I 8H 7: :A"C@78 IA B9-=@>C7 C= >9@7 FEAG;< %5&( , # &9A:= cal problems. The main experience outputs are summarized in Table 2. refine unorganised information complexity to semantically enriched relevant concepts.
This reduction of the work structure complexity and heterogeneity helps to optimise the complex document generation by creating more coherent applications or work environments and helps interoperability between experts and applications. The maturity of knowledge contained in these structures contributes to a better agility towards output expectations. The introduced distinctions between Infrastructure and Architecture in one hand and Domain and Project in the other induce de facto an awareness of stakeholders on their position on a knowledge refinement scale. It avoids confusions in concepts considerations and allows the identification of global project risk.
Architecture phase goals are thus valuable hints for such indicators.
Next works should focus on how to monitor the global data evolution. Moreover the
main advantage felt by the teams is the distinction between project and domain elements that is revealed in the need of clearly specifying
the project syntaxes for a better construction of the domain semantics. In a nutshell, this paper proposes a methodology to