Actions

Enterprise Engineering

Revision as of 19:18, 24 December 2018 by User (talk | contribs) (Enterprise Engineering is the application of engineering principles to the management of enterprises. It encompasses the application of knowledge, principles, and disciplines related to the analysis, design, implementation and operation of all elements)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Enterprise Engineering is the application of engineering principles to the management of enterprises. It encompasses the application of knowledge, principles, and disciplines related to the analysis, design, implementation and operation of all elements associated with an enterprise.[1]


Enterprise engineering is based on the premise that an enterprise is a collection of entities that want to succeed and will adapt to do so. The implication of this statement is that enterprise engineering processes are more about shaping the space in which organizations develop systems so that an organization innovating and operating to succeed in its local mission will automatically and at the same time innovate and operate in the interest of the enterprise. Enterprise engineering processes are focused more on shaping the environment, incentives, and rules of success in which classical engineering takes place. Enterprise engineering coordinates, harmonizes, and integrates the efforts of organizations and individuals through processes informed or inspired by natural evolution and economic markets. Enterprise engineering manages largely through interventions instead of controls.[2]


Roots of Enterprise Engineering (See Figure 1.)[3]
Enterprise Engineering is a new field, emerging from Information Systems Engineering and the Organizational sciences. This development is shown in the Figure 1.


The roots of Enterprise Engineering [Dietz, 2007]
Roots of Enterprise Engineering
Figure 1. source: The Enterprise Architect


From top to bottom the evolution of thinking within the field of Computer Science is shown. It consists of two parts. The first revolution, around the 1970’s, was the recognition of the difference between form and content. Date Systems Engineering became Information Systems engineering. At the moment the second evolution / revolution is going on. It consist of recognizing two different parts in communication: proposition and intention. Proposition can be seen as content while intention express the relation between the communicator (by example, the speaker) and the proposition. Examples of intention are requesting, promising, stating and accepting. Like the content of communication was put on top of its form in the 1970’s, the intention of communication is now put on top of its content. It explains and clarifies the organizational notions of collaboration and cooperation, as well as notions like authority and responsibility. For a more comprehensive explanation of the concept of intention I’d like to recommend the book ‘Enterprise Ontology’ [Dietz, 2006]. This current revolution in the information systems sciences marks the transition from the era of information systems engineering to the era of enterprise engineering. However, Enterprise Engineering is closely related to organizations, so it focuses on a socio-technical system. Therefore it adopts also knowledge of the organizational sciences. Enterprise Engineering is about engineering enterprises in the sense of focusing on the construction, the white-box view, of enterprises. It doesn’t forget that an enterprise is a system also consisting of people.


Enterprise Engineering Methods[4]
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:

  • Computer Integrated Manufacturing Open Systems Architecture (CIMOSA) methodology: 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.
  • Integrated DEFinition (IDEF) methodology: IDEF, first developed as a modeling language to model manufacturing systems, 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: Petri Nets are established tools used to model manufacturing systems. 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. 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.
  • Unified Modeling Language (UML) or Unified Enterprise Modeling Language (UEML): Unified Modeling Language (UML) is a broadly accepted modeling language for the development of software systems and applications. Many within the Object-oriented analysis and design community also 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. 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 response, 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.
  • Enterprise Function Diagrams (EFD): 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. Research on the complementary use of IDEF and UML has contributed to the acceptance of IDEF as business-front end and therefore a similar study should be carried out with EFD and UML.


Components of Enterprise Engineering (See Figure 2.)[5]

  • Strategic Visioning
  • Human and Culture Development
  • Information Technology Development
  • TQM, Kaizen
    • Continuous change applied across an enterprise
    • Kaizen - Japanese term for continuous improvement
    • Everybody improves everything all the time
  • Procedure Redesign
    • Discontinuous reinvention of existing processes
  • Value Stream Reinvention
    • Discontinuous reinvention of “end to end” streams
    • Breakthrough improvement for the Customer
  • Enterprise Redesign
    • Discontinuous redesign
    • Holistic change to a new world architecture, sometimes accomplished by building new business units of subsidiaries.


Seven Components of Enterprise Engineering
Components of Enterprise Engineering
Figure 2. source: The Wichita State University


Phases of the Enterprise Engineering Process[6]
The main principle behind enterprise engineering is its belief that an enterprise has an underlying structure that can be studied, taken apart, and worked on in order to improve its design and function. In this way, enterprises are treated very much like a building or a machine, with all their components interrelating with each other. Business enterprises and companies are not the only ones that can benefit from this kind of systems engineering, but also all kinds of establishments such as government departments and non-profit organizations. In general, the enterprise engineering uses a cyclical process to evaluate and make improvements on the structure of an enterprise. This cycle may involve many steps, but can be summarized in three simple phases.

  • The first one is “strategic planning,” in which all existing information and data about the enterprise are analyzed. From all the information, several implications about the enterprise will be formed, including its place in the market, its status quo regarding profits, and the efficiency of the human resources. In this stage of strategic planning — called strength, weakness, opportunities, threats (SWOT) —, analysis of the enterprise is also included.
  • The second state in the cycle of enterprise engineering is “process improvement,” where all the gathered information is utilized to further advance the efficiency of the enterprise’s system. This stage involves a team effort wherein everyone in the enterprise works together to get to the goal. In many cases, the enterprise engineer can provide a diagram or systems model that the company can try to follow. Sometimes, this involves a trial-and-error process, trying out different methods until the company finds the one that suits it best. Process improvement not only gives importance in short-term goals, but also in long-term achievements as well.
  • The last stage is the “performance measurement,” in which the enterprise evaluates its progress since the first stage of strategic planning. This phase of the enterprise engineering makes sure that the list of goals is being realized and that the enterprise experiences improvements steadily. Evaluation reports and surveys are usually undertaken to quantify and measure these improvements, which may bring back the enterprise engineering to its first stage.


See Also

Business Process Engineering (BPE)
Design & Engineering Methodology for Organizations (DEMO)
Enterprise Architecture
Enterprise Architecture Framework
Information Engineering (IE)
Information Resource Management (IRM)
Strategic Vision
Information Technology (IT) Transformation
PRIDE Methodologies


References

  1. Definition of Enterprise Engineering Royal Holloway
  2. What is Enterprise Engineering? Mitre
  3. Roots of Enterprise Engineering Johan den Haan
  4. What are the methodologies, methods and techniques involved in Enterprise Engineering? Wikipedia
  5. Components of Enterprise Engineering Larry Whitman
  6. Phases of the Enterprise Engineering Process WiseGeek


Further Reading