Business Process Management Methodology

1 IntroductionFrom Wikipedia, we copy:

«A business process is a set of linked activities that create value by transforming an input into a more valuable output. Both input and output can be artifacts and/or information and the transformation can be performed by human actors, machines, or both.

There are three types of business processes:

1. Management processes - the processes that govern the operation. Typical management processes include "Corporate Governance" and "Strategic Management".

2. Operational processes - these processes create the primary value stream, they are part of the core business. Typical operational processes are Purchasing, Manufacturing, Marketing, and Sales.

3. Supporting processes - these support the core processes. Examples include Accounting, Recruitment, IT-support.

A business process can be decomposed into several sub-processes, which have their own attributes, but also contribute to achieving the goal of the super-process. The analysis of business processes typically includes the mapping of processes and sub-processes down to activity level.

Activities are parts of the business process that do not include any decision making and thus are not worth decomposing (although decomposition would be possible), such as "Answer the phone", "produce an invoice".»

A business process is a systematic approach of the enterprise, where its activities are examined as revenue generating and value adding transformations of material (all forms of money included), services and information.

Again from Wikipedia:

«Business Process Management (BPM) is a field of knowledge at the intersection between Management and Information technology, encompassing methods, techniques and tools to design, enact, control, and analyze operational business processes involving humans, organizations, applications, documents and other sources of information. The term “operational business processes” refers to repetitive business processes performed by organizations in the context of their day-to-day operations, as opposed to strategic decision-making processes which are performed by the top-level management of an organization. BPM differs from business process reengineering, a management approach popular in the 1990s, in that it does not aim at one-off revolutionary changes to business processes, but at their continuous evolution. In addition, BPM usually combines management methods with information technology.

BPM covers activities performed by organizations to manage and, if necessary, to improve their business processes. While such goal is hardly new, software tools called business process management systems (BPM systems) have made such activities faster and cheaper. BPM systems monitor the execution of the business processes so that managers can analyze and change processes in response to data, rather than just a gut feeling.»

Every Business Process is seen from a distance and is represented by a “box”, where the only concern is the resources it is using, the value it is producing and where this value goes or why it is useful (produces revenue).

Every box is “gouged” by the “gain” it produces. It is an analogous of a vocal wave amplifier.

Putting aside electronics, we have a visual idea of the “gain” effect, after observing that the left side wave amplitude (input) is much less than the right hand.

Another depiction might be:

Triggering

input

Transformation /

Process

Product /

Service

Physical

Resources

consumption

AdministrativeResources (Functions)

input

Diagram 1 An abbreviated gain representation in business

In this simple representation, it is evident that inputs are amplified, but not without the contribution of other inputs as well.

Additional components to the previous flow chart result to more complicated scheme:

Diagram 2 Schematic representation of transmission disturbance

Between the inputs to a process, be them the triggering input, the resources contributed or the administrative functions, there is a lot of interference. For example, if the triggering input for the process of “production of a number of items”, is the stock reported by the warehouse accounting, this may be inaccurate, either because some of the reported remainder (as in the books) is spoiled or stolen. Physical resources, as raw material, consumables or energy, as well as direct work, are almost never as thought to be, both in quantity and quality. The same happens with Administrative resources, which depend on decision making, that are not only a consideration of information, but also “rumors”.

All these obstacles represent some kind of noise, which prevents full communication. In other words, things almost never come out as planned.

In order to take correcting actions, a system needs information from the output side to come back to the input side. This feed back makes a system “viable”, since it permits it to work automatically, without external intervention.

Transformation / Process

Diagram 3 Feedback schematic representation (servo mechanisms)

Feedback is information. The more accurate the information is the better a process performs.

Accurate information is not enough. The process management needs three more conditions to fulfill, in order to satisfy the purpose of the existence of the process.

• Effective elaboration of the information, not necessarily sophisticated, but producing the exact and useful information.

• Speed of data elaboration, so that feedback does not become obsolete.

• Data collected and data produced storage, for improvement of both the accuracy of information and usefulness of the information produced.

It is always to remember that the whole enterprise is a process itself! The purpose of the enterprise is usually to steady increase profitability and property value. In the cases of social proprietorship of the enterprise (or when it is a public enterprise), the profits and the property value is usually measured in terms of votes and devoted voters!

Business processes emerged as a sophisticated application of information technology in organizing and running the enterprises in more effective (not just efficient) manner.

It was, as it still is, thought that it is possible to substitute most of the everyday operations without the direct involvement of people, who are considered to be less reliable than machines (computers in this case).

Transformation / Process

The evolution of mathematics1 and statistics, together with the development of algorithms2 permitting high speed calculation of apparently “theoretical” and without any practical usefulness functions, have driven to the feasibility of this dream of all scientists and entrepreneurs.

Mathematics, from their side, creates quantitative models3 for processes (input – output systems, of universal application4). Statistics see the constants and variables of the mathematical5 “functions” as most “usually happening6”, or in statistical terminology as “stochastic” components.

Computer specialists are overexcited with the capabilities of hardware and proud of their ability to program it. They take a model and transform it into computer instructions and until they discover a bag, they think it is perfect. Computer scientists know computers and they expect others to tell them what they need from computers to do. Those “others” have limited knowledge of what computers are capable of doing. In many cases, managers (or consultants) miss the rarely occurring circumstances, which are impossible to imagine, without much of experience. Such cases are not only given to the unpredictable of human behavior, be it of employees, clients, bankers or consultants, but equipment as well. Invisible changes of the environment in which machines are operating, may change their behavior without any visible sign of malfunction. For example, the specifications of wood boards in an early September afternoon, may appear different, because they have absorbed humidity, or the analog timers may change their pace, because the electric power source has change (the net has been connected to a different country where the frequency is different [50Hz to 60 Hz]).

1 Jacques Guenot (Mathematician, Professor at the University of Calabria) says that mathematics is “categorization of syllogisms”, while Anastasios Baluktsis (Engineer and Mathematician, Professor at the TEI of Serres) rebates that it is a quantifiable model making. Neither of them published his statement. 2 Giuseppe Giannini (Engineer and researcher at the “Laboratorio di Applicazioni della Matematica all’ Ingegneria” at the University of Calabria), is doing much of research on the hypothesis that an algorithm is “a sequential approximation of calculations, aiming to give a quantitative answer to quantifiable questions, combining the computers’ speedy and accurate calculations with the clarity of the declaration of the question”. (This work is under publishing procedures)3 Stergios Athianos (Full member of the teaching staff of the Accounting Department of the TEI of Serres), in most of his published work is giving precedence to the intrinsic and inherited errors of model crating and the confidence to their implementation, especially from the stock exchange market, information.4 Vasili Karanasios (Professor at the university of Waterloo, Canada), says that “there are persons, assisted by technology, who can give you the answers, if you only put the question”. (This statement is the motto of most of his published work).5 Anastasios Katos (Professor at the University of Macedonia, Thessaloniki), has concentrated his work in the bridge between mathematical functions and the strength of the interference of concurrently operating evolutions of the same nature, in similar circumstances.6 Konstantinos Katrakylidis (Teaching staff member at the Aristotle University of Thessaloniki), supports the idea that “Econometric models have to dislocate from capital investment to consumer market model design” (as in still not published papers).

Computers, from their side, cannot be wrong, because they represent the ultimate “servo-mechanisms”. They either work correctly, or they do not work at all, something not rare. Hackers may trick them, but only if they are exposed at the internet, but hackers would never do it without a motive, be it transfer of money to their benefit, revenge, or pure fun (if someone considers it as fun).

2 The central issuesAn enterprise is a “process” of itself. This means that there must be a clear numerical identification of the inputs and outputs, so that performance may be measured.

People in an organization, enterprises as included, tend to repeat a successful past and this is not driven by intrinsic conservatism, but mere instinct of self-preservation of the persons working in the organization. An exponent of an organization once said: “we are all assessed by our faults; if we take no initiative, or try to change anything, we stand most chances to go to the top”.

Putting order in such a complicated and apparently chaotic context, seems to be impossible. Well; it is impossible!

Process management is oriented versus continuous change of the total enterprise picture, while through it, every process is assessed and evaluated, every interoperation of a process with the rest of the enterprise structure is reviewed and redesigned or a subject to “reengineering”.

2.1 How is a process identifiedIn order to identify a process, we have to keep in mind that it evolved from the “systemic” approach of the enterprise activities. At a first glance, a process is a “sub-system” of the enterprise and so it is essential that there is an input and an output of such a sub-system, a transformation activity of material or information and a clear role as a sub-system.

On a second examination of a subsystem, we see that its output is the input of one or more other subsystems.

With some more attentive examination, we see that the output of every subsystem depends on the provided inputs, not just the transformation capacity of the subsystem. When evaluating the performance of a subsystem and the persons working within it, it is important to see how satisfactory the inputs to the subsystem were.

As a consequence, every subsystem is an internal client, no much different than a client of the products or services of the enterprise as a whole. When we see a subsystem as an internal client, we realize that it is a mini enterprise which is aiming to satisfy the needs and the desires of its clients and be profitable. It is obvious that the client may be internal, when the clients are other subsystems, or external, when the subsystem resides on the extremity of the whole system and its output is addressed to the market.

This is not enough to let us identify a process as something different than a mere function or activity. It has to be repetitive, with clarity of rules and in a specific order.

The same way architects put bricks, concrete, doors, tiles etc, in order to create a building, management is seen as a functional and finite mathematical set, where all elements “belong” to the same set.

The same way architects search for a “better” design, or put in other words a new overall view of a construction (which may be a bridge, an airport or a stadium, other than a house), then after go into details of the elements, management is trying to produce an overall “blueprint” of the enterprise and then after go into details of the whole enterprise. This is feasible only when management knows the details. For example, and architect cannot design a house if his or her knowledge about piping, heating, electric supply and other dynamic subsystems is poor. The same way, business architecture requires in-depth knowledge of all transformations and all the composing elements.

In a schematic representation, a management comprehensive design, has to be equipped with a “Legend”, for every process, explaining at least:

1. The goal it has.

2. The specific Inputs.

3. The specific Outputs.

4. The Resources it is using.

5. The number of activities that are performed and their order.

6. The other organizational units it is affecting.

7. The horizontal organizational impact.

8. The value it is creating to specific internal clients or expected external clients.

9. The events that trigger the start of a process.

10.The event indicating the end of a process.

Some more explanations are needed:

Goal

Object:

A business process has some well defined goal. This is the reason the organization does this work and should be defined in terms of the benefits this process has for the organization as a whole and in satisfying the business needs.

Connections:

Goal link from activity Business Process. A goal link indicates the attached object to the business process describes the goal of the process. A goal is the business justification for performing the activity.

Information

Object:

Business processes use information to tailor or complete their activities. Information, unlike resources, is not consumed in the process - rather it is used as part of the transformation process.

In formation may come from external sources, from customers, from internal organizational units and may even be the product of other processes.

Connections:

Supply link to activity Business Process. A supply link indicates that the information or object linked to the process is not used up in the processing phase. For example, order templates may be used over and over to provide new orders of a certain style - the templates are not altered or exhausted as part of this activity.

Output

Object:

A business process will typically produce one or more outputs of value to the business, either for internal use of to satisfy external requirements. An output may be a physical object (such as a report or invoice), a transformation of raw resources into a new arrangement (a daily schedule or roster) or an overall business result such as completing a customer order.

An output of one business process may feed into another process, either as a requested item or a trigger to initiate new activities.

Resources

Object:

A resource is an input to a business process, and, unlike information, is typically consumed during the processing. For example, as each daily train service is run and actuals recorded, the service resource is 'used up' as far as the process of recording actual train times is concerned.

Connections:

Supply link to activity Business Process. An input link indicates that the attached object or resource is consumed in the processing procedure. As an example, as customer orders are processed they are completed and signed off, and typically are used only once per unique resource (order).

Triggering Event:

Object:

A triggering Event is the information or material being received by a procedure in order to start the transformation activities. When there is no triggering event the process remains idle, so it does not use resources or information and does not generate value or information.

Connections:

Supply link to activity Business Process. An output link indicates the fulfillment of the processes’ goal, potential discrepancies and may be used as a triggering event of the next depended process. For example, the process of hiring a new person is completed after the selection process is over and the payroll (and not only) process is informed and starts calculating the payments (insurance as well).

2.2 What is process modellingFrom the previous presentation of the business process concept, a series of additional concepts should be added, in order to make a good use of the process oriented management.

Additional aspects of management are needed, in order to create models of process oriented management. These new aspects, although under discussion7, represent an effort to:

Standardize the planning procedure.

Pre-calculate the cost / effect of every detailed “component” of an enterprise.

Give a specific answer to the essential business question “buy or make8”?”

Co-ordinate all of the activities and achieve an optimized timing.

Visually represent a process.

Move decision making, from personal to methodological procedure.

Simplify complexity and chaotic operations.

Make automation possible.

Emancipate the enterprise from the oppression by personal authority of the non strategic management (middle managers) over the top management. By modelling the processes, middle managers can not have a personal policy in their functions any more.

This effort is driving to a simple but exhaustive and rigid procedure description, after an analysis of the current processes, examination of the possible quantifiable improvement and simplification, visual representation and execution monitoring.

7 Many writers support the opinion that “if all enterprises use an identical and standardized “processes” they risk to loose their uniqueness, loosing their real or imaginary competitive advantage.8 This answer is usually referred to as “outsourcing”

The goal is to create a model of the real process, as it is executed or will be after the improvement procedure, on paper (or in a computer software), together with the interconnection with every related process, so that the whole business is examined before the implementation.

3 Process ModellingProcess modelling is very close to process reengineering. The procedure of process analysis is not limited to represent a process “as is”, but also to identify potential improvements, or even suggest:

The abolishment of a process, if it is superfluous, if the same process is already incorporated in another process, or just looping (bureaucracy for the sake of bureaucracy).

The outsourcing of a process, after evaluating that an external supplier of the process will provide a better process output, a better interconnection with the related processes, with a lower consumption of the enterprise resources (not just the cost).

The modification of a process in such an extend as to be completely different from the actual process, in order to adapt to the changes of the environment, both the external and the internal.

It is the top management to decide the adoption of any of the above suggestions. For strategic or political reasons, top management may drop the suggested changes. For example, proprietary software production, currently executed by employees, may be suggested to outsource to a specialized software company, because the analysts prove that the enterprise will increase the value of the process output with the consumption of less resources. The top management has set a strategic goal to motivate the personnel through a policy of “non firing”, even when the staff members are considered to participate in a “non economic” process.

Process modelling is connected also with the workflow analysis and reengineering. Workflow is the operational aspect of a work procedure: how tasks are structured, who performs them, what their relative order is, how they are synchronized, how information flows to support the tasks (wordflow) and how tasks are being tracked. As the dimension of time is considered in workflow, workflow considers "throughput" as a distinct measure.

From as early as 1962, scientific research resulted in the creation of descriptive and mathematical models of “distributed systems”. The most used is the Petri model, which is using set theory as a start point to arrive to finite elements, in order to calculate the potential and the throughput of a process, seen as a part of an organization. Newer scientists, created a visional depiction of each process and used colors as a sign of distinction between movement of material and information between places within (within the organization, or from and to externals). The novelty introduced (still remaining a major issue) is the significance of a “node”. A node is mainly an attempt to make decisions automated. It may be a simple comparison leading to a route of different considerations (and calculations that go with them), usually called “algorithms”. Although the mathematical calculations seem to have only theoretical significance for business processes, when they become a part of software, the calculations become an important tool for analysts and programmers, alike.

Figure 1 Workflow representation with pattern comparison

Patterns are used as probes. They let pass only whatever is identically behaving.

Figure 2 A process at design and implementation phases

Before such tools, as Petri workflow model, every process has to be engineered in a manner that resembles a “recipe”, with all ingredients (resources) measured and put in a sequential order, in terms of monetary value, time and quality. Every process starts from a triggering event and then is executed according to the value of the event, either internally (within the same process) or through triggering another process.

This recipe permits the operation of a process in an identical way every time it is repeated. This makes possible the representation of a process by an algorithm, which may be represented verbally, visually or mathematically.

There are several conventions about the representation of a process model, some of them are struggling for international recognition, as to become international standards, other as helpful tools and, yet others as mere depictions of important points of the model. Almost all of them are in use, because they help managers, analysts, consultants and implementers to communicate.

Figure 3 Visual representation of a process

Under this perspective, a visual representation of a process may me depicted as:

Figure 4 Complete process representation

It is evident that the result of such an effort is the representation of a process by an “algorithm”, thus by a “pseudocode” and finally by real computer coding, using any computer programming language.

Figure 5 Business Process Notation as in RFC 2119

A process is performed though the completion of TASKS. A task is assigned to a person, a process, a sub-process or a function.

There are different kinds of assignments, described by the keywords:

MUSTMUST NOTREQUIREDSHALLMUST NOTSHOULDSHOULD NOTRECOMMENDEDMAYOPTIONAL

4 The opportunitiesThe evolution of hardware availability, together with the software cumulative creation, draw a landscape of opportunities for process oriented management, which would become mechanical, from one side of the perspective and, exceptions saved, assigned to computers.

Take as an example your phone calls that are computer answered, unless you cannot get a satisfactory answer. In most of the cases you will not ask for a person to talk to; in some cases there is nobody in the other end of the line!

Behind such communication, there is a detailed analysis and a synthetic work, based on a series of processes. There are cases that even sales process is assigned to a recorded message and a machine to make the phone calls.

5 The restrictionsNot all processes work mechanically. The definition of a process covers a statistically significant population of events that are routines. There is still room for personal handling, through individual decisions, thought as exceptions.

Human intervention is inevitable because human behaviour is not mechanical and humans are the most complicated beings, as affected by the environment they are trying to change!

Competition, as a component of the global change, is also making the process definition a temporary issue in need of a constant review. Every enterprise is trying to differentiate in all its aspects; processes do not make an exception.

Under this view, the closer a process is to the external systems, especially the clients, the more possible it becomes that it will modify, even without an apparent reason, but just because the enterprise decides to present a new aspect, before the competitors do it.

Repetitive reengineering is creating confusion among operators.

Every reengineering is leaving enough room for overseen cases and events thus left outside the process, creating the need for the system to be tuned up again.

ReferencesS. Levitt and S. Dubner, Freakonomics, Harper Colins, 2006

R. Templar, The rules of Management, Prentice Hall, 2005

M. Gordon, Entrepreneurship 101, John Wiley, 2007

V. Grover and W. Kettinger, Business Process Change, Idea Group Publishing, 1998

M. Minsky, The Emotion Machine, Simon & Schuster, 2006

RFC-2119

Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, IETF RFC 2119, March 1997http://www.ietf.org/rfc/rfc2119.txt

BPEL4WS(BPEL4WS) 1.1, IBM/Microsoft/BEA/SAP/Siebel, May, 2003http://www-106.ibm.com/developerworks/webservices/library/ws-bpel/

QUESTIONS & DISCUSSIONIs it possible to maintain a process in an enterprise when it does not make any transformation of the resources it consumes?

A triggering event is defined in a process modelling work. Is it possible to start a process as a result of an undefined event?

A process is producing a calculated value. What kind of value is produced by a process whose output is not certain, like Research and Development?

6 IT Enable Change6.1 IntroductionFrom a distant view, a process is a subsystem which is transforming inputs into outputs, it is being started by an “event” and is finished when the output is delivered and recorded.

Process management is aiming to define every single subsystem in the form of a process, so that:

• A repetitive routine work is not a subject of decision making; thus human judgment dependant, but identically done in every repetition.

• A repetitive work becomes automatically done.

• The potential of the Information and Communication Technologies (ICT) is exploited.

The process definition and designing depends on the Hardware and Software potential and evolution and availability. Under this view, the enterprise architecture changes, as the ICT potential changes. For example, introducing a set of hardware / software enabling automatic control and monitoring of a production machine, creates the necessity of re-engineering the production process, while it also makes it possible to connect the production process with sales, provisions, warehousing etc.

On a remote time, at the beginning of the eighties, a British scientist, Sir Ian Sinclair, invented “procedures” in computer programming, later to be adopted by C language (Kerningham & Richie) and the still operating Borland (inventors of Pascal). The whole idea consisted in creating a set of computer instructions that are repetitive in a program and be called by a single name; all you have to do is to provide information and you get the execution of a series of algorithms, all based on the same inputs, until you get a certain output. This output may be a numerical result, a memory allocation, a screenshot or a printout. It corresponds to what was being called a “subprogram”, without the necessity of providing the inputs, while they were being retrieved from either other “procedures”, or “functions”.

The following evolution has been the “Legacy” of the properties of a procedure to another procedure, until procedures became “objects”. Under the programming point of view, an object is an independent program, solving a specific algorithm (name it a problem; it does not make any difference).

Managers, scientists and programmers alike, at that time, thought it might be a worthy attempt to use IT to perform all the calculations inherent in a business environment, if only they could represent business activities with algorithms. Well, they managed to do it! The evolution of the capacity of mass storage (Hard Disks) has given a hand, but communication speed and communication systems, were holding back all the involved parties, while they developed in a slower pace.

It has been the development of communication technologies that boosted the evolution of the business systems, together with data storage capacity.

It was about 1992 when distributed systems became possible, thus coordination of systems became necessary. The invention of the Internet, at this same time, did not provide enough contribution to the evolution, while it was considered (still is) unsafe. Packet Switch Network is still the backbone of business interactions, when it comes to confidential information and especially in money transfer.

At the beginning it was only distributed book keeping (not accounting) and money transfer between banks, as well as confidential information about their clients. From that time to date, there has been an enormous evolution, not just in H/W and S/W, but especially in management.

The history exceeds this handouts’ purpose, but still some notation is important when it come to the implementation of holistic approach of business, out of which Enterprise Resource Planning (ERP) emerged. It was a technical response to the management needs for a coordinated distributed system, based on activities, monitored by computer combination of H/W & S/W. To do this, activities have been considered as interconnected “modules”. It was the evolution of databases, especially the relational databases, that enabled management to store, update and modify data generated by each activity and be represented in understandable and meaningful reports, using statistical correlations between “factors”.

An ERP system can include software for manufacturing, order entry, accounts receivable and payable, general ledger, purchasing, warehousing, transportation and human resources. The major ERP vendors are SAP, PeopleSoft, Oracle, Baan and J.D. Edwards. Lawson Software specializes in back-end processing that integrates with another vendor's manufacturing system9.

The ERP systems are (ERP is still being used in the enterprises with an increasing success) information systems based on the existing managerial practice. This means that ERP is an ICT system that monitors functions and actions and allows managers to make correct decisions (take as an example the statistics over demand of a product that show a necessity of increasing or decreasing the minimal inventory of ready-to-sell products and the parts or raw material inventory).

Implementing ERP, managers are able to plan ahead more accurately and most important, much faster, while all the implications of a manufacturing and sales plan, in terms of investments, hiring personnel, buying material, expected profits, payments and expected cash-in.

The implementation of ICT, on one hand proved that monitoring is not enough, if we wanted to improve the overall performance of an enterprise, and that many activities and functions can be set free from decision making and be almost fully automated.

9 http://www.pcmag.com/encyclopedia_term/0,2542,t=ERP&i=42727,00.asp

At that point, reengineering has been seen as a necessary step for better implementation of ERP and improvement of the enterprise overall performance, under the thought that if we eliminate unnecessary activities and actions and improve the performance of each one of the remaining, the overall performance will also improve. The result of redesigning was a blueprint of the enterprise, where blocks describe the repetitive actions (an equivalent of the rooms of a house), each with a reference to a more detailed blueprint (equivalent to the pluming and electric power of each room), by using comprehensive diagrams.

The business is seen as a single process under the view of:

The Strategy of the Organization.

Customer Satisfaction.

Governance.

Stakeholders Satisfaction.

Profits.

Under this view, Business Architecture is seeing the enterprise as10:

A group of “domains” (aspects, viewpoints) such as: business, data, application and technology.

Scope: the enterprise scope: the part of the organization (department, business unit, firm) or even across traditional boundaries (virtual enterprise).

Granularity: the level of detail or level of granularity.

Time: the time horizon: the factual situation, the desired or target architecture or any intermediate situations.

Business Architecture represent the enterprise as-is, search for optimal changes, implements the changes, by exploiting IT capabilities, evaluates results achieved and suggest new changes, in order to adapt to the changes in the consumer desires and competition.

Business Architecture is based on the process management. Without the process concept, architecture would be a nightmare, if ever possible, because every detail should be designed as a new entity and from scratch.

The depiction of the architectural blueprints has been standardized, so that specialists, consultants and managers can understand the same thing. This is leading to homogeneity among enterprises, thus depriving them from the confidentiality needed to maintain a competitive advantage.

6.2 Process Engineering and Re-engineering

10 The Open Group Architecture Framework, 2003

The enterprises feel it is necessary to implement IT in their management and in the same time IT professionals are developing and offering different solutions. Management is seeking solutions leading to cost cut, as a means of obtaining more profits or just stay in business. The employees of the enterprise are trying to keep their salaries (or even improve them), keeping their real or imaginary “authority”, in the same time, intact.

Figure 6 Business Engineering

Process Engineering is seen as an automation seeking procedure of the management operations, whenever human intervention can possibly be substituted by IT.

Prior to process engineering, it is necessary to define:

The business models.

The domain objects.

The data to record and access.

The communication between objects.

The interaction of objects and the environment.

The evaluation gauges.

The change from function to process oriented management requires:

Full documentation of every process.

Elimination of duplicated objects.

Modifications that will permit the implementation of IT objects, which programmers will choose from a library.

An implementation strategy.

A transition period.

A full implementation time plan.

Figure 7 Business Engineering Process

Combining the before mentioned factors, becomes evident that Process Engineering is solidly based on the definition of a process. The question is “who defines a process of an enterprise?”

Is it the IT specialist, called in to computerize the processes, or the top or operational management? Or, perhaps, external consultants? The answer retrieved from the literature is that Process Engineering is a group work.

Figure 8 Top management forms the team

Group work is easy to say. People in such groups have conflicting interests and incentives and each part is trying to make the most with less. Top management is concerned about the cost of both the engineering operations and the cost of selling goods or services. IT specialists are concerned about their payment and the work they have to offer, so they are trying to make the vaster use possible of objects from the library that they are familiar with (while it is practically impossible to know well all available libraries in the IT market). Consultants are trying to convince that a vendor’s solution will be safer and faster to implement, under his guidance. Low rank managers are trying to prove that their skills are indispensable and their work cannot be replicated by any routine, computerized or human.

The result is that a solution is very often dictated by top management, as a part of the enterprise strategy. When this strategy becomes explicit, all parties involved are adapting to it, withholding as little information as possible, about their work, to keep it important, but in the same time appear collaborative.

Research and surveys have shown that all the parties involved in process engineering are imitative. They are more easily convinced to adopt a proposal when they see results from an application in another enterprise, no matter what their success has been.

Mixing internal and external expertise requires a common language of communication with identical concepts behind graphics, wards and diagrams. Moreover, IT specialists, consultants and Software vendors, need a common language, as well. This way a Unified Modeling Language (UML) has been agreed upon and standardized in a manner that serves both the purposes of IT programming and implementing and managerial planning and controlling.

Figure 9 Notation types of classes, as in ISO/IEC 19501:2005(E)

Under these needs, objects are categorized in classes, according to their significance to the enterprise, together with the necessary data and attributes (characteristics), as well as relations with other objects, on an information basis. Classes also characterize an object as global, which means it is available in all processes, or local, which means is only used in a specific process. Such a categorization of objects is very helpful to both IT specialists and managers. It simplifies IT design and implementation and duplicate operations elimination in the same time, helping to diminish costs and risk taking.

Division of objects in classes arrives from “Corporate Strategy11” analysis, where the activities of a corporation is seen as a set of units (call them objects), each of them providing a certain “product” to other units, which is “paid” at a price worth paying (lower than its market price, if available) and they are either “unique” (global class processes), deriving, outcomes or spin-offs.

These thoughts have been passed to the computer programming philosophy, in almost all programming languages, under different names, but with the same working aspects. They are different from functions, because functions in computer languages mean a calculation which produces a number (or a series of numbers).

A class is describing the characteristics of an aspect of the enterprise, like Employees, Machinery, Cash, Clients, etc. The characteristics of a class are inherited to sub-classes.

For example, if a class named Employees contains the characteristics of an employee, like his name, address, social security number, age etc, a sub class EmployeesSalesPersons, derives from class Employees, without the need of giving the general information again, adding whatever may be seen as useful to register, as if he/she is using a proprietary car, what kind of education he/she has, the languages he/she speaks and so on.

An instance of a class (or subclass of any level) may contain more specific characteristics, such as his/her sales per year. This particular instance is called an “object”.

A class may also contain a function, or in other words a specific way of calculating a given number, for example, the way a discount is calculated for a client, according to his past payments and purchases. A class may also contain a set of behaviors of the class, reflecting different events.

At this point it is obvious that a class is a description of characteristics of an entity and its behavior, which is inherited to more detailed sets, or subclasses.

What is more to a class, is that it contains data and activities, that may be restricted, either to be seen or changed by everyone, or start an operation. This is called Encapsulation. For example, it is not permitted to access the personal data of the employees, unless by authorized person, due to personal data protection laws.

11 I. Ansoff, Corporate Strategy

A last characteristic of a class is Polymorphism. This means that a class which contains activities (or methods), produces different output, depending on the conditions under which the method is invoked. For example, a method called “CalculateDiscount”, uses a different procedure of calculations when the client is a wholesaler and a different procedure when it concerns a consumer.

The question is still there and it is difficult to see one. Is it the object oriented programming needs that made management to adopt a process oriented view, or object oriented programming is an answer which is meeting the needs of management evolution? To my point of view, management and programming evolved in parallel. Even the processors design resembles an organizational chart of a multinational! Or is it the other way round?

Whatever is the real story, the fact remains that change in management is a continuous procedure, in which an increasingly role the IT plays.

As in every change, there are forces facilitating change and forces opposing. Each none of the stakeholders is trying to benefit by, either the change, or the retention of the “status quo”.

Searching for a predictable behavior, we first have to identify the motivation of each stakeholder. Starting from the facilitating forces, we see the expectancy of future profits, after an IT supported change is implemented. These stakeholders are mainly top management and shareholders. Even when they know little or nothing about the impact on efficiency and profitability, they tend to expect higher profits from an enterprise which is on the hedge of the technological development. We have to remember that top management is being elected by the shareholders, thus expresses their expectations. In many cases, such a change may be very painful for the enterprise and may cause losses, but the market price of the share may rise, despite the “damages”12.

Software vendors are trying to sell their products at the highest possible price, together with the expectation of leverage in profitability of the buyer’s enterprise. What they really sell is a tool and as such it may be used well or be misused and this depends on other factors, than the software integrity or real capabilities to solve problems. Take as an example the implementation of a very sophisticated and efficient computer program, though which one can predict future sales. Every manager, or just person, wants to predict the future, but is there enough and statistically significant data of the past, so that the predictions have a solid base?

People, investors and managers alike, are sometimes attracted from the new and the promising development of technology that they invest in it under a speculative eye13. They think that being early investors they gain a competitive advantage.

Consultants, as intermediates between vendors and the end users (the enterprises) are selling their superiority in knowing better the link between IT and management and vice versa.

12 J. Castaldo, “RIM test of faith”, article in Canadian Business, April 9, 2007, page 29 13 Al Rosen, the green trap, article in Canadian Business, April 9, 2007, page 19

On the other hand, opposing forces to the change, in addition to their wish to retain the privileges (real or imaginary), are found among all stakeholders.

In top management, members of the Board of Directors, which oppose to changes (usually the IT based changes), have an intrinsic supernatural fear of technology, even in cases when they understand and know it. There are cases that IT specialists, who became members of the Board of Directors of an enterprise, are reluctant in changes that are IT intensive! Is there a hint about their incentives? One answer may be that they will be forced to share knowledge (read: authority) with others.

Vendors are always creating a “new version” which is in need of further change of the enterprise in order to be “bug free”. They really don’t want any change in management; all they want is to sell their software. If the enterprise does not change, it is better for them, because they can always sell this new version, together with the promise that the new version does not require any “significant” changes, as did the past one.

Even among the consultants there are persons and consulting firms alike, who oppose change. Once the change is effectuated, their job (and payment) is over!

Pondering all these conflicting interests is much easier than described in the previous paragraphs. An analysis of the incentives of each party involved is sufficient, in order to formulate a strategy of change implementation.

Figure 10 Change strategy overview

Again, from a different point of view, the question is still asked; would that be possible to produce radical changes, without the implementation of the state-of-the-art IT?

Automated processes are not the core of the answer. It is the whole of the mindset that goes with it. It is thinking as a programmer or processors designer that assimilates the IT processes with managerial matters, so that in the end of the line it is confusing about what comes first, if ever either was first.

Definition of processes of an enterprise, as said beforehand, is teamwork involving:

1. Top management

2. External Consultants

3. Function Responsible Staff Members – Managers

4. Software vendors’ representatives

It would prove a useless exercise, if all parties involved are were not driving to the same direction, although it is expected to hide information from each other, due to serve their self-interest. It is the top management that has to inspire the rest of the team to drive to the same direction and this is possible when14:

There is a solid determination to change the organization.

The goals of the change are transparent and common to all.

The selection of the external consultant for the change is NOT the task of the top management, but competence of the functional managers.

The benefits of change are clearly and briefly explained.

There is a concrete and feasible time-plan, set by the top management and controlled for respect of the deadlines.

Creating transformational value rather than just implementing IT projects prevails.

Building capability for ongoing change, gains priority. Being able to predict future business needs and how IT can help shape new business models and deliver the desired benefits.

Creating a climate of open communication becomes a central issue.

Managing confidence and risk - understanding the impact of external changes, all play a major role.

The team, after its formation, has to determine:

The data to be collected, in order to be able to identify and assess the change.

The budget devoted to change, for both hardware and software.

The boundaries of cost / benefit, suggesting to outsource or keep a process.

The difference between installation and implementation. Computers and other IT hardware, as well as software, may be installed, but they may end up as game machines, where employees pretend to work, while they play “solitarily”! Implementation, on the other hand, means that the whole set of H/W and S/W is productively used15.

14 http://www.bcs.org/server.php?show=ConWebDoc.378215 74% of IT projects failed in 2005 – same % as in 1980, [Source: Standish Group and Gartner]

The non IT specialist members of the team are well prepared to understand computer and communication jargon. It is not imperative to know all the technicalities in detail. If so, it may be dangerous, because on technical matters the specialists feel the competition and react. A rough knowledge of the capabilities is enough.

But, is there really a change when the enterprise is seen as a series of sequential and concurrent processes, based on IT16? Functions do not disappear under any circumstances; they are simply redistributed among processes, becoming more efficient. Information technology is a mere tool for data gathering and elaboration speed and complexity, together with transmission, accuracy and security. Workflow remains the center of performance and thus profitability.

What makes a great difference is that every activity is examined as a process, where workflow is a part of the necessity to satisfy the internal or external client, together with other resources, such as simple or complicated and automate machinery, other equipment, such as telephones, consumables, such as forms to compile by hand or computer assisted, as well as a place to host the activity.

6.3 Process RepresentationAfter all possible actions and reactions are considered, before suggesting any change, especially when it concerns IT, a common language between all parties involved must be established17.

There are several computer programs helping create the blueprint of the processes18. This does not mean that using this representation software one may become an expert in defining, establishing and using the process approach of business management. These are tools to be used by a team in order to create quick visual representations which are using the Unified Modeling Language Notation, without having to browse the whole of the standards, since the standards are already stored in a database.

Before getting involved in teamwork of process based business reengineering, all members of the team have to understand the goals of the enterprise; it is obvious that the goals are different from enterprise to enterprise.

Understanding the goals will help understanding the value chain of the enterprise. This means that they have to understand what values the enterprise is offering and to whom, either inside the enterprise or the clients, as well as the society.

16 Alphonse Karr’s much quoted maxim: Plus ça change, plus ça reste la même chose.17 Computer aided diagrams training may be found at: http://www.visual-paradigm.com/product/bpva/demos/bpmodeling/bpd.jsp18 They may be found at: http://dmoz.org/Computers/Software/Business_Drawing/

Modeling a business is usually being seen as problem solving, while it is a totally different procedure. Process oriented reengineering does not resolve specific problems. For example, if the enterprise is facing a cash-flow problem, this will not be resolved by reengineering the processes. The problem will persist after reengineering the enterprise if management decision making continues ignoring the cash impact of the transactions.

Some writers suggest that the first meetings of the process engineering (and reengineering) team are held outside the physical environment of the enterprise, for example in a hotel meeting room, so that managers and consultants concentrate on the process definition, leaving behind their current problems.

The first move is to represent the working groups’ structure.

Figure 11 End-to-end process representation

The second move is to represent in a graphical way, the procedure of process engineering (or reengineering).

Figure 12 overall graphical representation (Diagram)

6.4 Process InterconnectionAn enterprise, seen as a system, is a subsystem of the local and global economy, interacting with it, being in the same time a set of subsystems interacting among them, in order to create value and harvest the fruits.

Every process is affecting one or more other processes, in at least three aspects:

Physical; which concerns transfer of goods or services.

Triggering; which means that the end of a process triggers the execution of one or more other processes.

Informational; which means that the execution of a process is being registered.

It has to be mentioned that process modeling has to be integrated with data modeling. Data modeling is the accounting side of the enterprise. It has to be stressed that without an accounting system it is impossible to either evaluate a process or make accountability possible.

Figure 13 Model of activity processes example

This may be simplified using visual tools, so that it may be understood by managers who don’t have the technical skills to understand the use of classes, procedures, or constants and variables.

Using one of the software tools, it is possible to view the processes as blocks interacting among them. These tools may even represent the places or the processes, by icons that resemble the real world of the enterprise. Such a representation is very useful to teamwork involving managers who represent “functions”; when, for example, a financial manager or a production engineer has little or no IT skills.

It is also noticeable that in modern enterprises almost all of the activities or departments are using computers, either to process or store “events” and that all are communicating through a network, either on a client / server, or peer to peer basis. For example, the warehouse accounting is almost impossible to be on paper; there a computer where items in stock, reception and retrieval are stored.

Figure 14 A primitive order process representations, interconnected with other processes. Notice the different colors and the different shapes

Information flow and triggering effects may not require human intervention and be “processed” automatically. For example insufficiency of the ordered goods may be communicated to the ordering client by an automatically created e-mail, trigger the process of production of the item, calculate the raw material sufficiency for the production, compare the reordering level “rule” of each of the raw material items, directly send an e-mail to the supplier and issue the order, calculate the cash availability impact, notify the “treasurer” that the enterprise is running short of cash, so that he will have to either change the credit policy or ask for a bank loan and record the event to the statistically semantic information system.

6.5 Concluding RemarksImplications of the ‘Business Improvement’ Perspective

The project should be owned and led by the business and not the IT function. Within the project team, there should be close collaboration between the business and IT team members.

The project objectives should be clearly expressed in terms of the business goals being sought and the outcomes and benefits that need to be gained to satisfy them.

The design of the new working practices should be completely integrated with the design of the IT application that enables them.

The project should consider explicitly how to implement the whole of the integrated design.

The project scope should incorporate all activities needed to deliver the expected benefits. This will include both change management and IT development.

The business must be motivated to release the necessary staff from the day-to-day business to design and implement the business changes.

The management process of the project should recognise and accommodate the inter-dependency of the project with the organisational context in which it is being executed. This implies the possible need to modify the project’s activity, plan or even objectives to react to unexpected and unplanned events.

As it is not always possible to do a complete design of the new working practices early on in the project, the management process of the project may need to accommodate an element of learning as it progresses.