Structuring Business Engineering Knowledge - Reference Solution and Application

Structuring Business Engineering Knowledge - Reference Solution and Application D. Blessing G. Riempp Institute of Information Management Institute of Information Management University of St. Gallen University of St. Gallen St. Gallen, Switzerland St. Gallen, Switzerland Abstract Knowledge portals aim to provide users with all necessary knowledge via uniform, Web-based interfaces. Heterogeneous sources must be selected and integrated in accordance with user interests in order to ensure optimal support for the individual user s processes. An important prerequisite for achieving this is the development of a fundamental knowledge structure. This paper deals with knowledge structuring in the field of Business Engineering. Business Engineering manages the execution of transformation projects by the use of procedure models, methods and tools. We present a notification which allows the description of knowledge objects as well as relationships between them and with structural data. For the field of knowledge on solutions and projects we provide a reference data structure which categorizes knowledge objects. This reference solution is used within a application. It involves a realization at the software company SAP, which has used the reference model for structuring project knowledge. Keywords Knowledge structure, business engineering, project knowledge, solution knowledge. 1 Introduction 1.1 Motivation In the information age many authors accord a central role to the topic of knowledge management (e.g. [1], [2]). In this context the greatest potential for knowledge management is seen to exist in the context of processes of high complexity and high knowledge intensity (see [3]). One process displaying these qualities is the transformation of enterprises. Transformation is one of the main challenges faced by a large number of enterprises in the current changeover into the information age. The discipline of studying the transformation of enterprises is known as Business Engineering (see [4]). Typically these days large amounts of internal content are available through document management systems, Intranets and other information systems. In addition, more and more external content services are being utilized, such as Gartner Interactive, CIO.com or @brint.com. This means that business engineers employ a variety of sources. Interviews conducted with the consultancy agency Accenture, for instance, have revealed that it now uses in excess of 14,000 databases, some 300 homepages and 20 knowledge management organizational units (see [5]). In fact, while a great number of documents is available thanks to Internet technology, the rapid increase in content makes finding the right information increasingly difficult. Appropriate solutions are thus often developed redundantly. Many companies attempt to avoid this phenomenon by using search engines, but realize that the results are not satisfactory. The current situation is characterized by the availability of more and better knowledge but which is not being used efficiently enough. One possible solution is portals, which are frequently referred to as corporate portals, enterprise information portals, business portals,

etc. The corresponding concepts and products promise integrated, personalized access to all internal and external information sources needed (e.g. [6], [7]). In reality, however, integration is frequently restricted to links to knowledge sources. One reason is that the available knowledge lacks pre-structuring. 1.2 Research Objectives and Questions The research project focuses on support for realizing content management at Business Engineering organizations. The main question investigated is: What does an appropriate structure for Business Engineering knowledge look like and how can it be realized with knowledge management systems? The research objective is to develop a reference model and use it in prototypes for Business Engineering knowledge. The present paper focuses on the field of reference solutions for knowledge structuring. It is part of the umbrella project Content Management for Business Engineering by the Institute of Information Management at the University of St. Gallen (see [8], [5]). The structural recommendations are based on a bestpractice analysis of seven renowned consulting firms. 2 Foundations for the Structuring of Knowledge 2.1 Terminological Basis Business Engineering aims to transform enterprises from operating in the industrial age to operating in the information age. Not only the necessity of transformation but also the opportunities this presents are created predominantly through innovations in the IT sector, which create new business solutions. Transformation in this sense means the restructuring of existing enterprises as well as the creations of new ones. Business Engineering employs process models, methods and tools for the structuring of transformation. Accordingly, the procedure is characterized by being based on the division of labor, transparency and precision (see [9], [4]). The analysis of this study focuses on the field of content management as an instrument of knowledge management. For our purposes a process-orientated understanding of the term knowledge management is therefore being assumed. Knowledge management supports business processes of clients and members of staff, as well as business processes between them by making available transaction data, compound documents and references to persons with specific competence. It is characterized by systematic procedures. The particular understanding of content management used for these purposes, is based on the view that knowledge management aims at the usage of knowledge. As such, the distribution of knowledge is central to content management. Content management therefore aims at the support of the distribution of documented knowledge to members of staff, clients and interested parties in instances where this distribution is supported by certain systems. Content Management also encompasses the preceding processes of capturing and processing of knowledge. There is far-reaching agreement on the meaning of the term portal. Portals are commonly understood to offer integrated access to internal and external information sources such as transactional systems and knowledge management systems. The presentation of knowledge is personalized and preferably process-specific (see [6]). Specific forms are defined by user groups, e.g. in the case of Business Engineering portals, or functionality, e.g. knowledge portals for knowledge management. 2.2 Elements of Knowledge Structuring Nearly all frameworks for knowledge management outline the necessity for knowledge structuring (e.g. [1]). Often the topic is subsumed under the terms information architecture, content management, etc. Meanwhile special architectures for the design of portals have become available, which also contain special components for knowledge structuring (see [6], [10]). Knowledge structure represents the common language between different sources of knowledge (see [11]). It consists of knowledge objects and the relationships or links existing between them. Both explicit knowledge (which is capable of being documented) and implicit knowledge (which is not capable of being documented) represent knowledge objects. As such the knowledge structure represents the link

between the sources of knowledge and the business processes, by integrating the sources of knowledge on a logical level. The structuring of knowledge is supported in the first instance by the development of those knowledge models. When using an appropriate modeling language one should ensure that the model is capable of reproducing all of the elements named aboves. The notation put forward here involves an extension of the classic entity-relationship models (see [12]). Fig. 1 explains the elements of a knowledge model. Term Symbol Description Type of entity Documenttype Documenttype group Thesaurus Type of link Reference type Generalization/ Specialization Generalization of real objects of a similar type Generalization of documents of a similar type Grouping of a number of document-types logically connected Classification systems or indexes Generalization of links of a similar nature Referral to a document within another document Type of entity, document-type or document-type group as special variation of another Fig. 1: Elements of knowledge models This modeling concept is suited to a knowledge management project in two phases. Firstly it allows description of the current situation and identification of weak spots in the analysis phase. Secondly it allows to semiformally present the new concept in the design phase. Also, besides allowing for the description of the project-specific situation, the model enables users to present reference models. Standard models can thus be used as point of departure in projects, and then be tailored to accommodate specific companies. While data modeling disposes of appropriate reference models that already exist, knowledge modeling requires appropriate action. The following chapter puts forward a reference model for Business Engineering, using for that purpose the modeling language developed above. 3 Reference Model for Business Engineering A structure of knowledge may be described through knowledge models as well as specific descriptions of the types of knowledge objects and thesauruses. The following graphic provides an initial overview over the structure of knowledge for Business Engineering. This will be elaborated upon below for the types of knowledge object employed in problem solving and projects. 3.1 Overview Fig. 2 represents an overview of the main types of knowledge objects and links. It focuses on problem solving and project knowledge. So for instance, no types of knowledge objects relating to the member of staff, such as his résumé, or links to thesauruses or types of knowledge objects for technology or branches have been indicated. Employee Creates Works on Solution Belongs to Customer Business Engineering process Business process Industry System/ technology Fig. 2: Knowledge structure for Business Engineering (overview)

Well-structured information is stored for the entity types project, customer and employee. External projects are carried out for customers and by employees, which lead to corresponding relationships. Another relationship is caused by the fact that employees develop a lot of solutions and are therefore owners of important know how in the specific area. s use solutions, especially methods. Solutions and projects are categorized according to the same thesauruses: Business Engineering process, business process, industry and system/ technology. This enables retrieval by navigation and search of both standardized solution as well as former and current projects. 3.2 Solutions According to the scope of the solution aimed at the project and the general validity (see [8]) different types of knowledge objects can be differentiated (cf. Fig. 3). Concept: Concepts offer approaches to solve strategic, economic or technological questions. Reference model: Reference models are a starting point for concrete models in projects and can be adjusted to concrete problems in specific application fields. Examples are reference models for organizations in specific industries or for information systems. Method: Methods are instructions for creating certain design results. Examples are methods for software engineering, for introducing ERP software or for process design. Case: A case is a practical example of how a solution has been realized. In contrast to project documentation it covers only parts of the overall material for the purpose of summarizing. A special case is a best practice or reference solution, which shows the successful resolution of a problem. Technology/tool: Articles about technologies and tools cover IT concepts and products, which are important for realizing new business solutions. Examples are product descriptions, market overviews or system architectures. ROI analysis: Documents about ROI aspects contain information for analyzing the profitability of business solutions. Examples are catalogues with criteria for costs and benefits, descriptions of the business logic or concrete calculations within cases. With regard to the components of methods it is possible to rely on the research in the field of method-engineering, which deals with the structuring of design methods (see [13]). A method may therefore be described with the use of the types of knowledge objects result, technique, process model, role model, and meta model. The intended result of the process of problem solving is recorded in a document. A technique is an action manual, instructing the business engineer how to produce a result. The process model defines the orderly sequence of activities in the process of producing results. The role model groups activities and allocates these to persons and organizational units. It describes the tasks, competencies and Solution Concept Reference model Method Case Technology/ tool ROI analysis Result Technique Procedure model Role model Meta-model Fig. 3: Knowledge structure for solutions

responsibilities of the various roles. The metamodel is the data model of a method and describes the individual creative objects, such as process, task, client, application, and the relationships between them. 3.3 s Types of project knowledge are project documentation, project experience and project correspondence (cf. Fig. 4). The result of a project solution is recorded in a project documentation. Result documents serve as templates, which is why the relationship from a project document to a result template should be stored. The project documentation consists of project management 3.4 Thesauruses for Business Engineering Thesauruses serve to standardize terminology and the subsequent location of knowledge objects. The amount of thesauruses employed will determine the efficiency of the location as well as the effort put into the classification. It is therefore important to find an appropriate medium, which will depend largely on the size of the organization. At this point four thesauruses will be proposed: Business Engineering Process, Business Process, Industry, System/technology. Solution documentation experience correspondence Method management document result Result Fig. 4: Knowledge structure for projects documents and project results. management documents contain information for controlling the project (e.g. activity plan, master plan, minutes). results document the formal results of a project. The corresponding knowledge objects strongly vary by the subject of projects. Other project documents are project experiences, which contain knowledge for internal usage. experiences are recorded to learn for future projects (see [3]). correspondence includes documents such as protocols, presentations or other confidential papers between the persons involved (customer, partner, etc.). These are put into a separate structure to ensure that only authorized parties have access. 4 Application of the Reference Model The model referred to above was applied and validated in three practical projects. PROMET@Web as well as Business Model@Web constitute Intranet or Extranet applications and demonstrate the application of knowledge structure for purposes of problem solving (see [5]). A solution for client knowledge and project knowledge developed by SAP relates to knowledge structure for projects and will be explained in the following. 4.1 Background and Objective SAP AG is the leading supplier worldwide of standard business management software.

Two of their projects (CPI 1 and 2 - Customer Information) focused on making project information globally accessible, and to obtain an earlier reaction to possible escalations of projects. Furthermore knowledge won from project experience, but not documented to date, was to be captured and made accessible initially to members and later on to clients through dedicated portals (see [14]). The system applies the knowledge structure to projects. 4.2 Knowledge Structuring A substantial portion of the project consisted of the initial structuring of the required knowledge in accordance with the procedures applied by the SAP consultants. The consulting process by SAP is predetermined by the implementation method ASAP (Accelerated SAP), in which the phases project preparation, business blueprint, implementation, production preparation and go live & support are being distinguished. The ASAP process is contained in a comprehensive Field Operations Process, which describes the integral relationship with the client (including aspects of acquisition, account management etc.). Knowledge structuring involves various levels: Initially the project team identified four areas of knowledge required within the processes: General project information (e.g. client data, project status, project duration), documentation according to the implementation method ASAP, Confidential project documents (correspondence) as well as Documentation of project experiences from previous projects. Classes, i.e. document types, were formed for the various areas. For instance, the area project experience shows classifications under the headings business solutions, technical solutions and final reports for projects. Templates specify the content of the categories. The category business solutions, for instance, requires entries for surrounding business environment, organizational environment, business demands, description of solution, references to similar solutions and experts. Attributes describe the stored documents in detail. The quality category, being divided into successfully employed, recommended, not recommended and not tested, is decisive in determining the degree to which clients will gain access. Only successfully employed and recommended documents will be made available externally. Further examples of attributes are period of validity, region of validity, release and language. To assist with searches and navigation, links to SAP-products and solution maps have been introduced. The latter describe the possible solutions (products and services) by SAP and its partners according to the branch and business processes of the client. 5 Conclusion The major findings of the projects on knowledge structuring are: Business process as starting point Pre-structuring of knowledge results from the requirements of the business process. Therefore, the business process has to be analyzed within the scope of knowledge structuring. At SAP, the defined areas were chosen to support the field operation process and the introduction method ASAP. Standardization through knowledge structuring An important success factor for the operation of a knowledge structure is the usage for all knowledge sources. At SAP, for example, the solution maps are used as navigation instrument for all information system of the consulting step by step. This uniformity makes navigation and retrieval of content easier. Multidimensionality Usually, one navigation possibility is not enough. Depending on the user s familiarity with the system, the process characteristic (strong structured versus weak structured) and personal preferences different mechanisms have to be offered. At SAP, navigation is possible by defined classes, solution maps as well as attribute and freetext search. Additionally, in the future access will also be possible by the ASAP process. However, this requires on the one hand the assignment of meta information to

the objects and on the other hand flexible systems. Organizational measures The creation of the knowledge structure alone not yet guarantees a long-term success. The implementation of adequate processes, which cover maintenance of the knowledge structure as well as assignment of meta-information, is essential. At SAP, the regular adjustment of the knowledge structure is done by a new role named knowledge worker. The assignment of meta-information happens by the creator of a knowledge objects and is checked by the knowledge worker afterwards. System support Knowledge management systems have to support knowledge structuring to a great extend. This goes beyond pure navigation. For example, the system implemented at SAP supports the entering of metainformation by displaying and checking possible attributes, name standards, etc. Other possibilities, which contribute to a correct database, are setting of validity dates or triggering of automatic workflows, e.g. in case of unclearness of certain meta information. 6 References [1] Davenport, T.H., Information Ecology. Oxford University Press, New York, USA, Oxford, UK, 1997. [2] Oesterle, H., Enterprise in the Information Age, Business Networking: Shaping Enterprise Relationships on the Internet (Oesterle, H., Fleisch, E., Alt. R., Eds.): 17-54. Springer, Berlin et al., Germany, 2000. [3] Eppler, M., Roepnack, A., Seifried, P., Improving Knowledge Intensive Processes through an Enterprise Knowledge Medium. SIGCPR 1999 Conference, New Orleans, USA, 1999, http://www.knowledgemedia.org/ netacademy/publications.nsf/all_pk/1236. [4] Oesterle, H., Business in the Information Age: Heading for New Processes. Springer, Berlin et al., Germany, 1995. [5] Blessing, D., Content Management für das Business Engineering: Fallbeispiele, Modelle und Anwendungen für das Knowledge Management bei Beratungsunternehmen. Ph.D. Dissertation, University of St. Gallen, Switzerland, 2001. [6] Allweyer, T., Jost, W., An Enterprise Information Portal for Integrating Knowledge Management and Business Process Management, Proceedings of the KnowTechForum 99, Potsdam, Germany, September 1999. [7] Detlor, B., The corporate portal as information infrastructure: towards a framework for portal design. International Journal of Information Management. 20 (2): 91-101, 2000. [8] Jansen, C., Blessing, D., Bach, V., Oesterle, H., Knowledge Portals for Business Engineering: A Reference Architecture, Proceedings of the Third International Conference on the Practical Application of Knowledge Management, Dominque, J. (Ed.): 129-148, Manchester, UK, April 2000. [9] Taylor, D., Business Engineering with Object Technology. John Wiley & Sons, New York, USA et al., 1999. [10] Walker, J., Building An Intranet Portal. Report, Forrester Research, Inc., Cambridge, USA, January 1999. [11] Applehans, W., Globe, A., Laugero, G., Managing Knowledge: A Practical Web- Based Approach. Addison-Wesley, Reading, MA, USA et al., 1999. [12] Chen, P.P.-S., The Entity-Relationship Model Toward a Unified View of Data. ACM Transactions on Database Systems. 1 (1): 9-36, 1976. [13] Robson, W., Strategic Management & Information Systems. Pitman Publishing, London, UK et al., 1997. [14] Blessing, D., Goerk, M., Bach, V., Management of Customer and Knowledge: Solutions and Experience at SAP. Knowledge and Process Management (forthcoming).