PROBLEM STATEMENT

Several general problems have been identified in the emerging field of enterprise engineering (Kosanke et al., 1998; Zelm & Kosanke, 1999; Vernadat, 2002). Efforts have been made to unify the language of EE for applications integration purposes (Vernadat, 2001) and reduce the confusion among potential users caused by multiple approaches and the proliferation of multiple, heterogeneous modeling tools and languages; however, problems on little common understanding, consistent terminology and divergent focus persist in the field. There is lack of business justification, little management involvement, and little use of existing enterprise engineering architectures. There is a small user community due to little awareness of EE;

and there is a tendency on the part of small and medium enterprises to ignore enterprise modeling and enterprise integration. The above general problems are seen as an effect; this research addresses some of their causes, targeting three areas: (a) an enterprise systems engineering (ESE) definition, (b) a classification scheme for ESE; (c) an ESE process.

In regards to a definition of ESE, it is clear that the existence of several definitions of enterprise engineering with different foci has been at the center of the above mentioned general problems. While some definitions of EE are rather broad (ISO, 1999b; ISEE, 2003), others focus on change methods (Martin, 1995), and yet others focus on business processes (Vernadat, 1996) or communication networks and life cycle (Kosanke et al., 1999). Broad definitions with different foci do not portray the uniqueness of EE as a separate research field

and do not help to orchestrate efforts toward the development of EE. According to Rowe, Truex, & Kvasny (2004), a field of study must have a central character and distinctiveness.

Current definitions of EE may have a central character, namely, the enterprise, but they do not have distinctiveness. Divergent foci do not support the concentration of efforts toward the development of EE; instead they contribute to the existing confusion among potential users (Kosanke et al., 1998; Zelm & Kosanke, 1999). Thus, it is necessary to continue the efforts towards properly defining enterprise systems engineering.

In regards to an ESE classification scheme, the main sources of frameworks and methodologies for enterprise systems engineering are the enterprise architectures (CIMOSA, PERA, GIM, and GERAM). Recognized enterprise architectures do not fit some definitions of enterprise engineering: CIMOSA focuses on building an information system through its own language; GIM focuses on the decision system and does not include implementation;

PERA’s Master Plan (of 300+ pages) presents a process to design an integrated enterprise focusing on life cycle and resources; GERAM originated from the merging of the other three enterprise architectures (CIMOSA, PERA and GIM) and it does not have its own process.

All these enterprise architectures attempt to reduce complexity by modeling and by providing general representations of the relationships among different enterprise views and abstraction levels during the life cycle of an enterprise (Kosanke, 1995; Vernadat, 1996; Chen, Vallespir

& Doumeingts, 1997; Williams & Li, 1998; Kosanke et al., 1999; Kosanke & Zelm, 1999;

Williams, 1999). However, these enterprise architectures are still complex, which makes them less attractive to business users (Noran, 2003).

An enterprise is composed of various systems, which are expected to interact cohesively to achieve the enterprise goals. Thus, an enterprise is a system in its own right and engineering principles should be applicable to its design. Enterprise architectures are only starting to highlight the different areas of study within the enterprise that need to be addressed to produce the desired output, which is an integrated enterprise system. A single graphical representation, used by existing enterprise architectures, is not able to encompass most of the areas that need to be addressed to engineer an enterprise system.

In regards to an ESE process, it is clear that enterprise architectures are intended to support the design of an integrated enterprise system through a process or methodology. Without a process the architecture achieves nothing. Williams et al. (1996) stated that an enterprise methodology is more important than the architecture itself. Similarly, Tolle & Vesterager (2003) stated that in the context of virtual enterprises, a methodology is needed that helps manage the task of creating an enterprise. Although there is agreement regarding the need for designing an integrated enterprise system, the problem is that several choices have been suggested regarding what the output of an EE process should be. Among the suggestions are a business process (Vernadat, 1996), a modified enterprise (ISO, 1999), implementation of an enterprise element (ISEE, 2003), communication networks (Kosanke et al., 1999), and a changed task or a changed enterprise (Martin, 1995). In fact, the existence of several proposals for the output of an EE process impedes EE from becoming a distinct discipline.

Different choices of output lead to different EE processes to produce that output. Moreover, the variety of EE processes and outputs will continue setting the stage for increased modeling approaches and tools.

A common thread in most enterprise architectures is the significance given to integrating strategy in an EE process (Scheer, 1998; Williams, 1998; Kosanke & Zelm, 1999; Scheer, 1999; Veasey, 2001; Zachman, 2003). Similar importance is given in the literature to the subject of alignment among business processes. Business processes must be aligned among themselves and with strategy (Ortiz et al., 1999). At its current development enterprise engineering methodologies signal the need to integrate strategy, but none indicate their relationships with different levels of strategy during the engineering of an enterprise system.

This constrains management involvement and business justification of EE (Kosanke et al., 1998; Zelm & Kosanke, 1999).

There is a need for extensive research in EE if it is to grow as a field and become the source of concepts, methodologies and tools to design, improve, and redesign enterprises of the 21^st century. The proposed framework intertwines a definition, a classification scheme, and a process for engineering integrated enterprise systems. It is an important step toward overcoming significant challenges faced by today’s EE community.

Enterprise Systems Engineering needs a framework that:

• Clearly defines what ESE is.

• Has a process to engineer an integrated enterprise.

• Sets the boundaries of EE with respect to other disciplines.

• Organizes the different areas of study that ESE needs to address.

• Enables the use of engineering principles and methods to produce an enterprise system.

The lack of such a framework, together with the existence of several enterprise architectures, each one with its respective methodology attempting to fill the void, has contributed to curtailing the use and spread of EE methodologies (Kosanke et al., 1998; Zelm & Kosanke, 1999).