Best practices oriented business process operation and

design

Julija Stecjuka, Janis Makna, Marite Kirikova

Institute of Applied Computer Systems, Riga Technical University, 1 Kalku, Riga, LV-1658
Latvia
[email protected], [email protected], [email protected]

Abstract. Business process flexibility has become one of the most important
factors in organizational operation and development. One of the approaches to
achieve the flexibility of the business process is bottom up business process best
practices propagation and leveraging of those practices at higher organizational
levels by appropriate information systems design. The approach is applicable for
fractal enterprises where branches of fractals are free to develop their own
processes and supporting systems. The paper discussed two stages in the
multilayer business process development life cycle in fractal enterprise: namely,
operation and evaluation, and business process design.
Keywords: business process, best practices, fractal enterprise

1 Introduction

Business process flexibility has become one of the most important factors in
organizational operation and development. Opportunities to achieve the flexibility of
business processes depend on various organizational issues, including organizational
culture, organizational structure, its technical infrastructure, etc. For instance,
flexibility in a small enterprise is achieved mainly by effective utilization of tacit
knowledge of employees, while flexibility in large centralized organizations is
addressed by introduction of sophisticated manufacturing and information
technologies, including intelligent agents, semantic networks and specifically
organized ERP systems [1].
In his book “The Fractal Company: A Revolution in Corporate Culture” H.J.
Warneke [2] envisioned a new organizational structure for manufacturing - a fractal
enterprise where each fractal is an independently acting corporate entity, whose goals
and performance can be precisely described. While a precise description of
performance is not the ultimate necessity in non-manufacturing business processes, it is
quite common to have explicit descriptions for well understood and elaborated
processes, which are supported by appropriate information technologies. The most
important issue here is that understanding and explicitness of the process are achieved
not necessarily by following a process design. Most commonly well elaborated
processes emerge gradually by seeking the best possible performance of the
performers.
 In this paper we discuss emergence of the best practices processes in fractal
enterprise, which tolerates different sub-processes used by different structural units to
achieve one and the same organizational goal. Those sub-processes may compete until
superiority of one of the approaches becomes visible. At that time-point a process
common for all structural units may be designed and introduced for leveraging the best
practices in the enterprise. Thus the stage of operation of the process on a small scale is
followed by the stage of design on a larger scale of the process.
The paper is structured as follows. In Section 1 we introduce the notion of fractal
enterprise and illustrate how different sub-processes may be used for the achievement
of one and the same goal. In section 2 we describe a procedure of change analysis for
the propagation of best practices. In Section 3 the process design for leveraging the best
practices is discussed. Section 4 consists of brief conclusions.

2 “Competing processes” in fractal enterprise

The notion of fractal enterprise [3, 4, 5, 6, 7, 8] stems from Warneke’s “fractal

company” [2], where basic patterns of fractal geometry are applied to the design of
industrial corporation. Architecture of a fractal enterprise consists of self-similar, self
optimizing, goal-oriented fractals (independently acting corporate entities), which
perform services, are the object of constant change (dynamic restructuring), and are
integrated into the goal-formation process. One of the essential features of fractal
enterprises is the possibility to execute in parallel different processes for achievement
of one and same goal. On first sight this feature contradicts with the notion of process
optimization, however this parallelism allows for higher flexibility in situations of
differences in local external environments and internal performers, as well as supports
the emergence of best process execution practices. An example of an enterprise, which
to a considerable extent exhibits fractal features, is a university (Fig. 1 a and b).

Fig. 1. Fractals (University, Faculty, Institute, Department) in the university

 The situation of the use of different parallel processes for achieving the same goals
is illustrated in Fig. 2 and Fig. 3. University annually has to prepare a report about its
scientific activities. It is achieved by the delegation of goal “Prepare the report” from
University fractal down to the Department level fractals. Departments are free to
achieve this goal in the most suitable way for them. For instance, Department 1 uses
sub-processes 5 and 6 and their scientific activities information system for achieving
the goal, while Department 2 of the same institute uses sub-processes 7, 8, 9 and
Department 3 uses sub-processes 10 and 11. All departments send information to the
higher level fractal for preparation of the institute level annual report about scientific
activities.

Fig. 2. “Competing” business processes: Dep. 1 (5, 6); Dep. 2 (7, 8, 9); Dep. 3
(10, 11) – Part 1

Suppose Department 1 has a larger staff than other departments and a capability to
develop a business process support system for the acquisition and maintenance of
information about scientific activities. The use of the system allows the department to
accomplish the process more efficiently in comparison with two other departments.
This attracts the interest of both departments and they consider the possibility to
acquire the practices of the Department 1. To achieve this, each department has to
manage the change from the AS IS process to TO BE process which is equal to the
process performed by Department 1. This involves the change of information and
knowledge processing systems of Department 1 and Department 2. The change
procedure [9] for switching to a new process is proposed in Section 3.

Fig. 3. “Competing” business processes: Dep. 1 (5, 6); Dep. 2 (7, 8, 9); Dep. 3 (10, 11) –
Part 2 (continuation)
3 Business process change procedure

The business process change procedure discussed in this section is developed on the
basis of the studies of 14 information systems change cases [9]. It is applicable and has
been used for new business process and information systems design. In this paper it is
applied for best practices transfer in a fractal enterprise. The procedure consists of the
following four steps:
1: Best practices identification
2: Best practices acquisition planning
3: Best practices acquisition cost estimation
4: Best practices acquisition
In this paper we consider informal identification of best practices, i.e., the situation
when one way of performing of a particular task is acknowledged as worth to be
imitated by several structural units. When best practices are identified it is necessary to
plan for their acquisition. This involves analysis of AS IS and TO BE business
processes (Step 2). The best practices acquisition planning involves the following sub-
steps:
2.1: Changing granularity of process description
2.2: Identification of activities to be changed
2.3: Change process risk analysis.
Business process description granularity is one of the most sensitive issues in
business process modeling. It is obvious that the level of granularity represented in Fig.
2 is not suitable for best practices transfer; therefore it is necessary to decompose the
sub-processes in smaller granularity units to identify actual changes in business
processes. Smaller granularity tasks are analyzed in order to identify how they will or
will not be affected by the transfer to target practices. Specific tables used for transition
task analysis consist of columns of performer activities, which are marked for both AS
IS and TO BE cases. Change analysis table for Department 2 referred to in Fig. 2 and
Fig. 3 is represented in Table1 and Table2. The sign “+” denotes completely performed
task, the sign “–” denotes partly performed task because another part of it is performed
by computer system or other business processes and empty TO BE cell means that the
task is fully performed by another business process or computer system.

Table 1. Business process change analysis table: Department 2 secretary’s tasks

AS Department 2 secretary: TO
IS tasks description BE
+ Receive the template (7)
+ Create the list of employees to whom to send the template (7) +
+ Send the template (7)
+ Determine who has not sent back the filled template (9)
+ Send filled template to Institute 1 responsible executive (12)
+ Make sure the template is sent (12)
+ Find out who is not available (business trip, conference, vacations) (7) +
Table 2. Business process change analysis tables Department 2 employee’s tasks

AS Department 2 employee: TO
IS tasks descriptions BE
+ Receive the template (5) -
+ Fill out the template (6) +
+ Send the filled template (12)
+ Send again the filled template, if secretary has not received it (12)
+ Get modification request (6) +
+ Inquire about modification details (6) +
+ Send the modification (6)
+ Receive the reminder to fill the template (5) +
+ Prepare questions to administration about report details (6) +

Business process change analysis table may be applied several times until all
processes are analyzed up to the level of granularity that allows to make an informed
decision about the reasonability of process change i.e. acquisition of the best practice.
This decision is based on risk analysis which is performed on the basis of the Business
process change analysis table. Business process change may considerably influence
responsibilities, knowledge/information patterns and tasks of business process
performers [10, 11, 12, 13]. Therefore multiple aspects are to be analyzed to assess
risks of best practice acquisition. For instance, in the case reflected in Table 1 and
Table 2, the control of the process moves from the secretary to the employee. It means
that the responsibility of receiving and filling of the template is delegated to the
employee. Taking into consideration the fact that the employee has already performed
similar functions and has had similar responsibilities the risk may be considered as not
very high. It would be different in Department 3 where the templates were filled by the
secretary not by the employee. In this case more attention is to be paid to the
knowledge patterns that are to be changed together with the process change.
After risk assessment, business process change cost estimation is to be performed,
taking into consideration tasks with “+” in Business process change analysis table and
all issues discovered in risk analysis. After this sub-step the final decision about best
practice acquisition may be made.

4 Leveraging best practices by business process design on a higher

fractal level

In Sections 2 and 3 the best business processes practices acquisition at one fractal level
was discussed. However, in a situation when one and the same practice is acquired by
all fractals at a particular level of fractal system, it is possible to leverage the practice
and apply it on a higher fractal level. This operation is illustrated in Fig. 4. Leveraging
of the best practice requires business process design on a higher level of hierarchy. It
concerns mainly those business sub-processes that are to be performed by the
information system, because the difference between three similar information systems
services on the lower level of hierarchy and one service on a higher level of hierarchy,
which is used by three structural units, does not considerably change the manual
processes at the lower level of hierarchy. Therefore, in business case exemplified in
this paper, the decision whether to leverage or not the process depends mainly on the
suitability of needed technical and administrative changes with respect to maintenance
of scientific activities information system in centralized manner inside the Institute 1
fractal (Fig. 4).

Fig. 4. Leveraging the best practices

In this case best business practices leveraging involves the change of ownership of
the scientific activities information system. Instead of having three separate systems it
is possible to operate with only one Institute 1 level information system. This involves
slight changes in all business processes; yet those changes influence a small number of
employees (Fig. 5).
For the leveraged process the information system has to be changed to accommodate
three departments instead of one. This allows to assume that in fractal enterprises a
fractal approach to business process and information systems development is
applicable [14] and allows incremental bottom-up changes in enterprise processes and
supporting information systems. This approach reflects the systems development
process that is in line with living systems theory, where common processes are
gradually delegated to higher fractal levels of the system for the sake of higher
functional efficiency of the system [15].
Fig. 5. Leveraged business process.

Conclusions

The paper discussed two stages in the multilayer business process development life
cycle: operation and evaluation followed by business process design. This approach
permits bottom up business process best practices propagation and leveraging of those
practices at higher organizational levels by appropriate information systems design.
The approach is applicable for fractal enterprises where branches of fractals are free to
develop their own processes and supporting systems.
References

1. Koc, M., Ni, J., Lee, J., Bandypadhyay, P.: (2007). Introduction to e-manufacturing.
Integration Technologies for Industrial Automated Systems, R. Zurawski (Ed.), pp. 2-1--2-
9. CRC, Taylor and Francis Group (2007)
2. Warneke, H.J.: The Fractal Company: A Revolution in Corporate Culture. Springer, Verlag
(1993)
3. Canavesio, M.M, Martinez, E.: Enterprise modeling of a project-oriented fractal company
for SMEs networking, Computers in Industry, doi: 10.1016/j.compind.2007.02.-05. (2007),
http:// www.sciencedirect.com
4. Fryer, P., Ruis, J.: What are fractal systems: A brief description of complex adaptive and
emerging systems (2006), http://www.fractal.org
5. Hongzhao, D., Dongxu, L., Yanwei, Z., Chen, Y.: A novel approach of networked
manufacturing collaboration: fractal web based enterprise. Int. J. on Advanced
Manufacturing Technology. 26, 1436--1442 (2005)
6. Ramanathan, Y.: Fractal architecture for the adaptive complex enterprise. Communications
of ACM. 48, 5, 51--67 (2005)
7. Ryu, K., Jung, M.: Fractal approach to managing intelligent enterprises. Creating
Knowledge Based Organisations, J.N.D. Gupta and S.K. Sharma (Eds.), pp. 312--348. Idea
Group Publishers (2003)
8. Sihn, W.: Re-engineeringthrough fractal structures. In: IFIPWG5.7 working conference
Reengineering the Enterprise, pp. 21--30. (1995)
9. Makna, J.: Structure of Information System change. In: Scientific Proc. of Riga Technical
University 5th series, Computer science, Applied Computer Systems. 30, pp. 57--65. RTU
Publishing, Riga ( 2007)
10. Schaad, A., Moffett, J.: Separation, Review and Supervision Controls in the Context of a
Credit Application Process: case study of organisational control principles. In: 2004 ACM
symposium on Applied computing, pp. 1380 --1384. ACM, New York (2004).
11. Tripathi, U. K., Hinkelmann, K.: Change Management in Semantic Business Processes
Modeling. In: 8th International Symposium on Autonomous Decentralized Systems, pp.
155-162. IEEE Computer Society, Washington (2007)
12. Rinderle, S., Kreher, U., Lauer, M., Dadam, P., Reichert, M.: On Representing Instance
Changes in Adaptive Process Management Systems. In: 15th IEEE International
Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises, pp. 297-
-304. IEEE Computer Society, Washington (2006)
13. Kim, D., Kim, M., Kim, H.: Dynamic Business Process Management based on Process
Change Patterns. In: 2007 International Conference on Convergence Information
Technology, pp. 1154 –1161 (2007)
14. Kirikova, M.: Toward multy-fractal approach in IS development. In: 16th International
Conference on Information Systems Development “Challenges in Practice, Theory and
Education”, (in print) (2007)
15. Cottam, R., Ranson, W., Vounckx, R.: Life and simple systems. In: Systems Research and
Behavioral Science, Volume 22, Issue 5 , John Wiley & Sons, Ltd, pp. 413 – 430 (2005)