Business Process Models as Design Artefacts in ERP Development

Transcription

1 Business Process Models as Design Artefacts in ERP Development Signe Ellegaard Borch IT University of Copenhagen, Rued Langgaards Vej 7, 2300 København S, Denmark Abstract. Adequate design of business process models is a matter of designing the model to fit the context in which it is going to be used. This includes knowing about different complex use scenarios, user groups and the specific purpose that the model is going to serve. This paper will consider one example of such a situated design, namely that of a design of a business process model intended to support development of ERP systems that eventually will support business processes. We will describe this kind of model as an example of a design artefact playing the role as a boundary object in software development, and discuss the challenges there might be in making an adequate design of such a model. Introduction In most cases the question of good process design is considered a matter to be investigated in the organizations that are going to use the business process support systems: the question could be answered either from a management point of view (e.g. process design in the context of optimizations as they are done in projects of Business Process Reengineering) or from a users point of view (e.g. concerning flexibility in support of the work practice). This paper will take a slightly different approach to the question of adequate process design, namely that of the design and use of business process models in software development of systems that should support business processes. There is a difference between designing processes to fit end user organizations directly, and designing a business process model that is to be used in the work of developing systems that will eventually support business processes. Empirical research on use of business process models in software development is relevant for the discussion of adequate process design because it makes explicit how the development organization conceptualizes the business domain, and how the models serve as one of the means the development organization has to make the process designs that will be present in the final systems. Moreover, issues such as reuse and best practices are dealt with in the software development companies not only from a business perspective, but also from a software perspective: if parts of the software (or parts of the domain knowledge the development company possesses) can be reused, the company might save working hours and money. Business process models can serve a number of different functions in software development of business process support systems. In the case that we are going to present in this article, the vision is to design a model that will unite different aspects of

2 2 Signe Ellegaard Borch the software development of ERP systems. The same model should be a generic domain model and ontology, functioning as a common frame of reference and a language for communicating about the business domain, and at the same time support technical design of the business processes in the applications that are being developed. Some of the challenges when designing such a model are how the model should be tool supported, how the same model can be a useful tool for different groups in the development organization, and how the model should be designed to bridge the gap between the business domain and the technical domain within the development organization. Moreover, the model is perceived as a way to introduce a process oriented paradigm into ERP systems development that until now has been primarily focused on handling business data, not business processes. As a means of analyzing the case, we will introduce the concepts of design artefacts and design oriented knowledge, as they are described in the theoretical framework of activity theory. Design artefacts and design-oriented knowledge It is a basic assumption in activity theory that every human activity is mediated by socially constituted artefacts. Design is one specific human activity, and the artefacts used here are named design artefacts: design can be characterized as an activity where a designing subject shapes the design object by means of some design artefacts [1]. An activity is changing an object, transforming the object into an outcome, and the design artefact is used as a tool in this process. However, the design artefact used as a tool is not neutral, but determines the perspective the designer has on the design object: The tool is at the same time both enabling and limiting: it empowers the subject in the transformation process with the historically collected experience and skill crystallised to it, but it also restricts the interaction to be from the perspective of that particular tool or instrument; other potential features of an object remain invisible to the subject... [5]. The designing subject is not necessarily an individual person - usually there are a number of people involved in a design process: most prominently the designer who shapes the design object, and the future user of the object. Normally, design processes involve even more people: design activities are carried out within a complex social context, with rules and division of labor. The design artefact has an important role as a facilitator of cooperation between these (often heterogeneous) groups. The design artefact makes it possible to share design-oriented knowledge between different stakeholders, also independently of project phases and physical settings. Software development is one place where design processes occur, and where design artefacts are used. Examples of design artefacts in software development are: programming languages, system development methods, specification standards, CASE-tools. In [1] three dimensions of design are described in relation to software development: Construction, cooperation, and conceptualization. Design artefacts have a mediating role in all three dimensions:

3 Business Process Models as Design Artefacts in ERP Development 3 1. Construction is the productive relation between the designing subject and the object of design. The construction of software is an engineering process, where e.g. programming languages are used as tools. 2. Cooperation is the representational relation between subjects involved in design. Prototypes and conceptual models are examples of design artefacts that mediate cooperation in software development. 3. Conception is the dialectical relation between the designing subjects and the historically developing activity. The dimension of conception in design becomes obvious when e.g. new design artefacts are introduced into a design practice it could be a new programming language paradigm or prototypes that give rise to alternative perspectives on the current design practice. One important question is: How to design the design artefact itself? To shed a light on this we will apply the concepts presented above on a specific case: a project of designing a business process model that is to be used as a design artefact in ERP development. Designing a business process model as a design artefact in ERP development What are the issues to consider when designing a business process model that is to be used as a design artefact in ERP development? The reflections presented below are inspired by empirical studies done in the period in a large software developing company developing ERP software. We observed a project of designing a generic business process model that was going to be used as a common frame of reference about the domain within the development organization, as well as a basis for technical systems development. In the following, these observations will be related to the concepts introduced above, to explain how the generic business process model was designed to support the construction, cooperation and conception in ERP development. Construction The model was seen as a means of improving the flexibility of the final systems, by raising the level of abstraction and expressing the technical functionality of the system in terms of domain-near concepts. The long term vision was that the system would eventually be changed by moving these domain-near abstractions in a visual tool. However, the immediate use of the model was to make the developers understand how the processes of the ERP system adapt, interact, and relate. Also, the developers could get an overview of the work practices of the end users. Having a deeper knowledge of the domain might give the developers new ideas on how to support the processes of the domain technically, e.g. by getting an opportunity to combine their technical knowledge with the domain knowledge.

4 4 Signe Ellegaard Borch One big design issue was how the model could be designed to facilitate the design of certain qualities desired in the final systems, e.g. flexibility. The model should provide ways to represent and experiment with such elements, conceptually and technically. One suggestion was to relate the concepts of the model directly to the reuse of technical components, and to make a library of reference processes as a technical representation of the processes in the model. Also code generation based on the model was discussed, thereby entering into the field of Model-Driven Development. Cooperation The model was intended to mediate between: - different professions within ERP development - development teams that are physically located in different countries and time zones - different legacy ERP systems that were acquired when the company bought up smaller players in the market, but that are still maintained and developed on - in the future, also groups involved in the complex channels of distribution and use of the ERP systems: the partners who have the direct contact with the end user organizations and make the final adaptations of the systems, and eventually also the end users themselves Different professions within the ERP development company that would potentially use the model are: people directly involved in market oriented work (e.g. marketing or strategic planning of what should go into the final products), user interface designers, people working with requirements analysis and functional specifications, people involved in end user support and training, and technical developers. The fact that the model was going to support cooperation gave rise to following questions: What information needs to be present for different groups? Bridging the gap between the domain-oriented knowledge and the way it has to be structured in order to become part of the technical solution was partly a question of information, notation, level of formalization etc. The work with making prototype tools that were meant to support different groups of model users made this obvious: business processes modeled in an activity diagram style of notation had to be heavily annotated with informal comments explaining the scenarios in order to be used as a means of communication, and a concept of meta-data had to be introduced in order to capture the additional information needed to be able to e.g. use the scenarios as a basis for workflow descriptions. Conception The initial design of the generic business process model was made by taking an already existing conceptualization of the business domain, a supply chain standard, and adapting it to be used in ERP development. The original model provided a basic taxonomy for the business process domain seen from a supply chain perspective, and also a particular way to structure this knowledge. The reuse of this model gave rise to

5 Business Process Models as Design Artefacts in ERP Development 5 questions like: What should be in scope of the model? Should the domain model used in ERP development be at the same level of granularity as the supply chain model that was taken as a starting point? Should the model aim at being primarily a generic representation of the business domain, or should it contain only information specifically needed in ERP systems or ERP systems development? What changes should be made to the notation to turn the original supply chain model into a design artefact in software development? In the prototypes that were made to experiment with tool support for the model, already existing modeling tools were reused. In one case it was a tool for drawing visual representations that was extended to fit the new purpose. The reuse of the drawing tool had an effect on the requirements for the new tool that was designed, by asking for functionality that is usually related to the access of graphical representations, e.g. zooming. Whether this functionality was also appropriate for supporting knowledge sharing about business processes was a point of discussion. Another issue was the role of the generic business process model in the process of moving towards an ERP system that would support business processes. Currently, there is no direct process support in the ERP systems developed the current systems are menu based, data and document centric, not process centric. The model is seen as a vehicle of introducing a new modeling paradigm into the design practice of the software development organization. In order for the model to become a common frame of reference in the development practice, it has to be communicated, even advertised. The distribution of the knowledge represented in the model is made with the aid of tools, sites on the intranet, and posters. The posters are displayed everywhere in the canteen, in meeting rooms and in offices. In this way, the concepts of the model are naturalized and become part of the professional vocabulary of the different teams in the development organisation. Related Work In [3] the notion of situated ontologies is presented. A situated ontology is a taxonomy that is formalized according to its context of use, and not in relation to formal design criteria. In relation to the work presented in this article, situated ontologies can be seen as design artefacts, and the methods to design situated ontologies, using e.g. iterative prototyping, could also be used when designing design artefacts. The concept of design artefacts is related to the concept of boundary objects. There is a substantial body of empirical research done in this field, e.g. on classifications and taxonomies [2]. A boundary object is a design artefact that transcends different communities of practice by adapting to different situations and contexts of use while maintaining identity.

6 6 Signe Ellegaard Borch Conclusion This paper discussed how a business process model was designed to be used as a design artefact in the development of ERP systems. The concepts of activity theory have been used to understand and explain different dimensions of the software development process that the model would be used in. Generic process models are one of the means that can be used when designing software to support business processes. We have, by presenting a specific case, pointed at important issues to consider when designing such a model. References [1] Bertelsen, O. W.: Design Artefacts: Towards a design-oriented epistemology, Scandinavian Journal of Information Systems, Vol. 12, [2] Bowker, C. G.; Star, S. L.: Sorting things out: Classification and its consequences, Cambridge: MIT Press, [3] Floyd, C.; Ukena, S.: On Designing Situated Ontologies for Knowledge Sharing in Communities of Practice, Workshop on Philosophical Foundations of Information Systems Engineering, Proceedings of the CAISE 05 Workshops, Vol. 2, [4] Korpela, M. et al.: Information Systems Development as an Activity, Computer Supported Cooperative Work, Vol. 11, March [5] Kuutti, K.: Activity Theory as a potential framework for human-computer interaction research, In: Nardi, B. (ed.): Context and Consciousness: Activity Theory and Human Computer Interaction, Cambridge: MIT Press, 1995.