Enterprise engineering is a subdiscipline of systems engineering, which applies the knowledge and methods of systems engineering to the design of businesses. The discipline examines each aspect of the enterprise, including business processes, information flows, and organizational structure.[1] Enterprise engineering may focus on the design of the enterprise as a whole, or on the design and integration of certain business components.
Contents |
In the field of engineering, a more general form of enterprise engineering has emerged.[2] Encompassing "the application of knowledge, principles, and disciplines related to the analysis, design, implementation and operation of all elements associated with an enterprise. In essence this is an interdisciplinary field which combines systems engineering and strategic management as it seeks to engineer the entire enterprise in terms of the products, processes and business operations,".[2] this field is related to engineering management, operations management, service management and systems engineering.
In the context of software development, a specific field of enterprise engineering has also appeared that "deals with the modelling and integration of various organizational and technical parts of business processes".[3] In the context of information systems development, this has become an area of activity for the organization of systems analysis, and an extension to the existing scope of Information Modelling.[4] It can also be viewed as an extension and generalization of the systems analysis and systems design phases of the software development process.[5] Here, enterprise modelling can form part of the early, middle and late information system development life cycle. Explicit representation of the organizational and technical system infrastructure is being developed in order to understand the orderly transformations of existing work practices.[5] This discipline is also known as Enterprise architecture, or along with Enterprise Ontology, defined as being one of the two major sub-fields of Enterprise architecture.[1]
Enterprise engineering involves formal methodologies, methods and techniques which are designed, tested and used extensively in order to offer organizations reusable business process solutions:
These methodologies, techniques and methods are all more or less suited to modeling an enterprise and its underlying processes.
CIMOSA provides templates and interconnected modeling constructs to encode business, people and information technology (IT) aspects of enterprise requirements. This is done from multiple perspectives: Information view, Function view, Resource view and Organization view. These constructs can further be used to structure and facilitate the design and implementation of detailed IT systems.
The division into different views makes it a clarifying reference for enterprise and software engineers. It shows information needs for different enterprise functions such as activities, processes and operations alongside their corresponding resources. In this way it can easily be determined which IT system will fulfill the information needs of a particular activity and its associated processes.
First developed as a modeling language to model manufacturing systems, IDEF has been used by the U.S. Airforce since 1981 and originally offered four different notations to model an enterprise from a certain viewpoint. These were IDEF0, IDEF1, IDEF2 and IDEF3 for functional, data, dynamic and process analysis respectively. Over the past decades a number of tools and techniques for the integration of these different notations have been developed incrementally.
IDEF shows how a business process flows through a variety of decomposed business functions with corresponding information inputs, outputs and actors. Like CIMOSA, it also uses different enterprise views. Moreover, IDEF can be easily transformed into UML-diagrams for the further development of IT systems. These positive characteristics make it a powerful method for the development of Functional Software Architectures.
Petri Nets are established tools used to model manufacturing systems.[11] They are highly expressive and provide good formalisms for the modeling of concurrent systems. The most advantageous properties are the ability to create simple representation of states, concurrent system transitions and capabilities thereby allowing modelling of the duration of transitions. As a result Petri Nets can be used to model certain business processes with corresponding state and transitions or activities therein as well as outputs. Moreover, Petri Nets can be used to model different software systems and transitions between these systems. In this way programmers can use it as a schematic coding reference.
In recent years research has shown that Petri Nets can contribute to the development of business process integration. One of these is the "Model Blue" methodology developed by IBM's Chinese Research Laboratory. Model Blue outlines the importance of model driven business integration as an emerging approach to building integrated software platforms.[12] The correspondence between their Model Blue business view and an equivalent Petri Net is also shown, which indicates that their research has closed the gap between business and IT. However, instead of Petri Nets the researchers instead use their own Model Blue IT view, which can be derived from their business view through a transformation engine.
UML is a broadly accepted modeling language for the development of software systems and applications. The so called, “object oriented community” also attempts to use UML for enterprise modeling purposes. Here, emphasis is placed on the usage of enterprise objects or business objects from which complex enterprise systems are made. A collection of these objects and corresponding interactions between them can represent a complex business system or process. While Petri Nets focus on the interaction and states of objects, UML focuses more on the business objects themselves. Sometimes these are called “enterprise building blocks” and includes resources, processes, goals, rules and metamodels.[13] Despite the fact that UML can be used to model an integrated software system, it has been argued that the reality of business can be modeled with a software modeling language. In respose, the object oriented community makes business extensions for UML and adapts the language accordingly. Extended Enterprise Modeling Language (EEML) is derived from UML and is proposed as a business modeling language. The question remains as to whether this business transformation is the correct method to use, as it was earlier said that UML in combination with other “pure’ business methods may be a better alternative.
EFD is a used as a modeling technique for the representation of enterprise functions and corresponding interactions. Different business processes can be modeled in these representations through the use of “function modules” and triggers. A starting business process delivers different inputs to different functions. A process flowing through all the functions and sub-functions creates multiple outputs. Enterprise Function Diagrams thereby provide an easy-to-use and detailed representation about a business process and its corresponding functions, inputs, outputs and triggers. In this way EFD has many similarities with IDEF0 diagrams, which also represent business processes in a hierarchical fashion as a combination of functions and triggers. The two differ in that an EFD places the business functions in an organization hierarchical perspective, which outlines the downstream of certain processes in the organization. On the other hand, IDEF0 diagrams show the responsibilities of certain business functions through the use of arrows. Furthermore, IDEF0 provides a clear representation of inputs and outputs for every (sub)function.
EFD may be used as a business front-end to a software modeling language like UML and its major similarities to IDEF as a modeling tool indicate that this is indeed possible. However, further research is needed to improve EFD techniques in such a way that formal mappings to UML can be made.[14] Research on the complementary use of IDEF and UML has contributed to the acceptance of IDEF as business-front end and therfore a similar study should be carried out with EFD and UML.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||