THE INDUSTRIAL ENGINEER AS ENTERPRISE DESIGNER

'n Metode word voorgestel om ontwikkelingsvermoe-ns se geskiktheid vir die ontwerp van ondememings te evalueer. Die metode is enersyds gebaseer op 'n model vir ontwikkelingen andersyds op modelle wat die ontwikkelingsvereistes tov Ondememingstoelig. Die evaluasie geskied deur die metodologie, kennisbasisen ontwikkelingshulpmiddelsvan die vermoe te vergelyk met die vereistes wat die ontwikkeling van 'n Ondememing stel.


INTRODUCTION
In the run of his normal business life the Industrial Engineer (IE) often experiences lack of understanding or confusion about his role.This paper attempts to contribute towards resolving the problem by providing a first step towards clarifyingthe IE's role.

What is an Industrial Engineer?
This question from a learned engineering colleague prompted the writing ofthis paper.The author's intuitive answer in engineering terminology was "The SystemsEngineers of Organisations" where the level of organisation engineered depends on the skill and experience of the Industrial Engineer.
We believe that the uncertainty expressed above and the confusion reigning elsewhere can be attributed to the differencebetween the other engineering disciplines and Industrial Engineering on the one hand and on the other hand to the way in which IEs have traditionallybeen applied in industry.
The difference between the disciplinesis illustrated by comparing the general definitionof Engineering according to the American Accreditation Board for Engineering and Technology [2] http://sajie.journals.ac.za "Engineering is the profession by which a knowledge of the mathematical and natural sciences is applied with judgement to develop ways in which to utilise, economically, materials and forces of nature for the benefit of mankind.II To that ofthe Department of Industrial Engineering [4] at the University ofPretoria which defines an Industrial Engineer as: Responsible for development, realisation, utilisation and maintenance of integrated Systems consisting ofHumans, Capital, Material, Equipment, Information and Energy which optimally contribute to the quality of life or .creation of wealth From these definitions it becomes clear that the utilisation of human resources, capital and information as well as artifacts to design and operate wealth creating systems differentiate IEs from other Engineering disciplines who are mainly concerned with the realisation ofthe artifacts The historic application of IEs to solve problems and improve parts of organisations or enterprises rather than to design new ones has led to the misconception that they are only fixers or improvers rather than designers ..

Approach
In order to substantiate the hypothesis that IEs are qualified as Enterprise Engineers and motivate that they should be recognised and applied as such, it has to be shown that they have the capabilities to design and develop Enterprises.
The author proposes to demonstrate the suitability of IEs as Enterprise Engineers by first developing a model to evaluate development capabilities required for the engineering of Enterprises (the subject of this paper) and in a following paper evaluate IEs against this model.The capability evaluation model, CEM, is based on the principle that an Enterprise engineering capability must have a methodology capable of handling the complexities implied in the design of a complex organisational system and provide adequate design aids.

Roadmap
To arrive at the CEM we have to start offwith the high level requirements for the system that has to be designed .This is achieved by reviewing the objectives of Enterprises i.e. their prime mission which represents the "what" that the capability must be able to design.Next we empirically examine what designing an Enterprise entails and then move on to define a generic model for development to show the elements required.A more detailed analysis of Enterprises from a systems architecture, system environment and system life-cycle perspective then follows to provide the detail requirements for the elements of the development model.http://sajie.journals.ac.zaA baseline for evaluation is developed per element of the development model and finally a method for evaluating a capability with respect to each element is proposed.

ENGINEERING OF ENTERPRISES
With the premise that ills should design Enterprises it is important to re-affirm the mission of Enterprises, motivate why they should be designed explicitly and review what such design entails.

Enterprise objectives
Enterprises are created to contribute to the objectives oftheir owners over the long term (generate wealth) through satisfying needs for products or services.An Enterprise can contribute to satisfying the need for products/services by adding form, place, time, ownership or perceived value to the elements ofthe product/service or the complete product/service.

The need for Engineering of Enterprises
Competitive pressures on companies are continuously increasing with the growing trend towards globalization.This necessitates companies to become competitive on a global scale i.e. world class companies.Wireman [5] states that "World class requires the elimination of complexity.It requires simplicity in design and ... processes." Elegantly simple designs very seldom result from a satisfying approach which adopts the first feasible design that presents itself It generally requires the generation of a set of alternatives and sound evaluation and decision making practices to arrive at a good solution i.e. systematic structured design is required.

The .challenge in engineering Enterprises
According to HalP [6] the challenge in designing Enterprises is to "design an organisation which is at the same time flexible to long term changes in the economical and cultural environment and resilient to immediate threats" This view stresses the importance of considering both the Enterprise's environment and it's lifecycle in any design.

The scope of Enterprise Engineering
In this paragraph the analogy is made between the design of hardware systems and enterprises to deduct from their similarities whether the same development process can be used and from their http://sajie.journals.ac.za differences how the emphasis should be changed in the development process.
Similar to hardware systems the alternative low level implementations ofEnterprise Systems are often relatively easy to identify from engineering judgement, experience and knowledge.Hardware systems are normally realised by implementation of existing proven components in a new architecture and with new interactions.
Analogous to handling of the complexities of hardware systems the Enterprise systems which are normally much more complex need a greater emphasis on the analysis of requirements and synthesis of element performances to system level.
Integration ofEnterprises (which to a great extent consist of human activity systems) depends on decisions concerning the logic, sequence, routing and timing ofwork flows as well as decisions regarding adjustments to the settings of the system (e.g.resource levels and structure) performing the work. .
On the one hand Enterprise designs depend on how it's vision, mission and objectives are broken down to the functions that the organisation has to perform to convert it's inputs to outputs i.e. how it handles throughput and on the other hand the functions it has to perform to sustain, renew and grow itself In the final analysis the Enterprise's function of adding value and sustaining itself reduce to : The Enterprise functions can be hierarchically cascaded into a number oflevels at which design has to be performed.Each of these levels represents a level of integration.This essentially means that most ofthe design ofEnterprises is in fact Systems design.

MODEL FOR DEVELOPMENT
Now that it is clear what designing an Enterprise entails the need arises for a model of how this development may be achieved.

FIGURE 1
Model for development 37 The author proposes the model shown in Figure I as a basis for evaluating the suitability of any capability for enterprise design.
For the purpose of this evaluation the problem or opportunity can be formulated as creating an entire enterprise or functional segment of an enterprise and the solution as a specific implementation comprising an architecture of resources and procedures for operating and managing the resources and the flow ofthe products or services ofthe enterprise through the resources.
Based on the conclusions reached in paragraph 2.4 we propose measuring against the systems engineering methodology which provides a generic approach and which has been proven to be universally applicable to providing break through solutions for complex systems .
The knowledge base represents the functional knowledge of standard elements (and their characteristics) which may be used to satisfy the low level functional requirements ofthe system (enterprise) Under tools and models the various methods, recipes or techniques for representing, designing, calculating, conflating or evaluating aspects of the problem or potential solutions are grouped.

THE SYSTEMS ENGINEERING METHODOLOGY
Traditionally designs ofEnterprises have evolved empirically from needs.The knowledge and experience ofEnterprise design has largely come from the study of alternative implementations rather than from systematic analysis and synthesis .This approach has led to the vast opportunities to re-engineer businesses by comparing existing implementations ofbusiness processes against a functional concept and eliminating or improving inefficiencies.This is probably also the reason why many view IE's as improvers of businesses rather than the designers ofbusinesses.

FIGURE 1 Model for deve lopment
Since the methodology forms the backbone of the development model and that the author proposes that the Systems Engineering (SE) methodology can be directly applied in the engineering of enterprises it is briefly reviewed here.
The SE methodology essentially comprises the systematic identification of system requirements, establishing their validity for development, specifying a system functionally and "proving" through conceptualising a baseline solution i.e. system concept implementation and accompanying development strategy that the functionality is feasible to develop from a technical, capability and business point ofview .
Once the requirements are clear and verified the methodology provides an approach for handling the inherent complexities of systems problems by cascading and partitioning the requirements, functionally, to a level where implementation can be achieved both in terms of: -Elements by which the required functionality can be achieved, and -ability for the design tasks to be allocated to development resources or capabilities The Systems Engineering methodology further provides a means for identifying alternatives at a detail system level, the sifting and trading off ofthese alternatives against requirements and each other and systematically ensuring that all requirements are allocated to low level elements.The low level elements are allocated to sub-systems by design disciplines/groups and logical integration in terms of units/modules.
Alternative sub-systems are again sifted against requirements at their level and traded off against each other.Preferred sub-systems alternatives are subsequently synthesised/integrated into Systems.In this process the integration activities required between these elements are also defined so that they can be designed and managed by systems engineers.
Extensive use is made of modelling and value systems both in the analysis and partitioning of functions and the allocation of requirements to the low level functions as well as in the synthesis of performance and other figures of merit to system level.
Valuation techniques are employed to assess the various worths of systems (with due consideration for scenario influences) and through value "systems conflate the various worths to an overall system worth.
Decision support theory is applied in the selection of alternatives at element, sub-system and system level to determine preferred alternatives for synthesis and ultimate implementation.

ANALYSIS OF THE REQUIREMENTS OF ENTERPRISES
In order to detail the baselines for the methodology, tools and techniques and knowledge-base, it is necessary to make a more detailed survey ofEnterprises and examine their : -Hierarchy of objectives, -macro and micro architecture, -environments, -life-cycle, http://sajie.journals.ac.za

Hierarchy of objectives in an Enterprise
Table 1 provides an overview ofthe objectives of an Enterprise structured as a hierarchy of functions and shows the associated development work that has to be performed so that an Enterprise may achieve its outputs.In order for an Enterprise to be able to realise these functions they have to be allocated to elements which are integrated to form the Enterprise system .It should be noted that requirements m terms of the different types of resources required for the implementation of enterprise functions only become clear at level 1 in the above hierarchy and that allocation must be done at this level.

Enterprise architecture
The realisation of any system depends on how its functions are allocated to its elements, how these elements and their interfaces are structured, how the interactions between the elements are structured, routed and controlled.
A generic structure for an Enterprises can (similarly to other successfully surviving purposeful systems) be depicted in Figure 2   According to M'Pherson self sustaining systems must provide for the following functionality: POLICY COORDINATION PROCESS CONmOL -A Support system to provide the incoming and outgoing logistics (L) for the system and maintain (M), the : -Operational, -information, -management and -Jogistic, processes under the direction of the support control system (SC) with information provided by the information processes (IP) .
-An information system (IC) which monitors the status of the system and provides input to the processes, control and management systems.
-Management in terms of systems to direct (PD) and control (eC) the other functional processes.
This provides a generic view ofthe architecture that has to be designed for an Enterprise system.

The life-cycle of an Enterprise
To ensure the long term continued survival of an Enterprises it has to be designed for the whole system life.This necessitates viewing Enterprises in their life-cycle context.

FIGURE 3 The enterprise life cycle
Manufacture/deliver product/service & support items The author proposes that the life-cycle of integrated Enterprises may be described as shown in Figure 3.This figure emphasises that the Enterprise is primarily designed for its operational phase but the model also provides for its initial establishment and the fact that the system is subject to continuous development and adjustment to cope with new challenges and opportunities arising from the market , environment and technology.
From Figure 3 the generic considerations for the design ofEnterprises can be divided into providing the functions which the system must perform during its operational life and aspects which ensure that the Enterprise can be realised, maintained and upgraded.

The Enterprise in its environment
The Enterprise context is completed by viewing the Enterprise in its macro environment.This whole systems dimension is illustrated in Figure 4 adapted from M'Pherson [1] FIGURE 4 Enterprise in its environment

REAUZATION ENVIRONMENT
This view shows the aspects of the environment that have to be incorporated in the design ofthe Enterprise and for which the development capability will have to be assessed WIDER SYSTEM

BASELINES FOR EVALUATION OF CAPABILITIES
With the elements for the development system known and the more detailed requirements visible from the various Enterprise perspectives, baselines can be set against which development capabilities may be evaluated.

Baselines for evaluation of methodology
In terms of methodology a capability should be compared to the SE methodology.The comparison should be based on the SE process flow and be shown to be able to analyse and cascade requirements according to the hierarchical levels set out in Table 1, be able to generate low level functional requirements that can be allocated to elements as in 2.4 and be able to synthesise these into architectures as in Figure 1.

Baselines for evaluation of tools and techniques
Essentially tools and models are used to interpret or represent aspects of problems and or potential solutions.The interpretation aspects are handled by partitioning and cascading or synthesisingfrom one level of detail or abstraction to another whereas the representation tools serve to illustrate or clarify specific aspects of a problem in a manner suitable for the analyst.
Tools/modelling capabilitiescan be evaluated with respect to their suitabilityfor Enterprise engineeringin terms oftheir suitabilityfor representing the type ofproblems involved and their capabilityfor interpretation of the problems/potential solutions.
The solutions sought will generally provide the types of functions at the levels shown in Figure 1 (Enterprise system) and handle the same flows.At the process level the logistic, operations and maintenance processes are similarin nature and can be handled by the same set oftools which addresses levels 1 through 7 of the functional hierarchy of work set out in Table 1.
Similarly tools can be grouped in 5 categories i.e. those suitable for: -Cascading, partitioning and synthesis ofproblems and solutions -Designing physicalimplementations at process levels 1 through 7 -Designing information activities at processes level -Designing the co-ordination, control and management levels -Engineering business aspects This evaluation should be done by evaluating the tools availablein the capabilitywith respect to their abilityto cascade, partition and synthesise for each of the four classes ofelements in the table above.

Baselines for evaluation of the knowledge base
The knowledge base should be evaluating on it's suitabilityfor identifying and definingthe elements of an Enterprise and designing the interactions i.e. integration between the elements.
In order to do this one has to first conceptualise the baseline systems that may represent implementationsof the enterprise ito.their architecture and dynamics.The architecture of enterprises at the lowest level can be reduced to a mix of resources and integrators as illustrated in Table 2.
The actual evaluation should be industry sector specific where the knowledge is measured on both the nature of resource and the type of resource.It is suggested that knowledge of the type of resource is more cardinal than the specific nature.A competent capabilityshould be able to compensate for lack of specific knowledge of the industry by consultation with people within the industry.

Conclusions
The paper provides a model and approach to evaluat ion which addresses the essential elements of the development model.
A superficial application ofthe model by the author indicates that it is workable.
Preliminary results when applied to IEs indicate that they are well equipped with methodology, tool s and techniques to design enterprises especially at the operational and tactical levels.Their knowledge base could be extended wrt the types of industries covered and in general might benefit from a wider knowledge of human resources and the technical system resources required to implement Enterprise functions .Further investigation is required to confirm these results .

FIGURE 2
FIGURE 2 An enterprise Architecture

TABLE 1
IPerformmotion/stepMost simplelevel of work performed by a single resource e.g, grasp, reach, read, clamp, step in x-axis.