Geschäftsprozessorientiertes Wissensmanagement

Transkript

1 Deutsches Forschungszentrum für Künstliche Intelligenz GmbH Document D Geschäftsprozessorientiertes Wissensmanagement Workshop im Rahmen der 1. Konferenz Professionelles Wissensmanagement - Erfahrungen und Visionen Kongresshaus Baden-Baden März 2001 Heinz-Jürgen Müller, Andreas Abecker, Knut Hinkelmann, Heiko Maus März 2001 Deutsches Forschungszentrum für Künstliche Intelligenz GmbH Postfach Kaiserslautern, FRG Tel.: + 49 (631) Fax: + 49 (631) info@dfki.uni-kl.de WWW: Stuhlsatzenhausweg Saarbrücken, FRG Tel.: + 49 (681) Fax: + 49 (681) info@dfki.de

2 Deutsches Forschungszentrum für Künstliche Intelligenz DFKI GmbH German Research Center for Artificial Intelligence Founded in 1988, DFKI today is one of the largest nonprofit contract research institutes in the field of innovative software technology based on Artificial Intelligence (AI) methods. DFKI is focusing on the complete cycle of innovation from world-class basic research and technology development through leading-edge demonstrators and prototypes to product functions and commercialization. Based in Kaiserslautern and Saarbrücken, the German Research Center for Artificial Intelligence ranks among the important Centers of Excellence worldwide. An important element of DFKI s mission is to move innovations as quickly as possible from the lab into the marketplace. Only by maintaining research projects at the forefront of science can DFKI have the strength to meet its technology transfer goals. DFKI has about 115 full-time employees, including 95 research scientists with advanced degrees. There are also around 120 part-time research assistants. Revenues for DFKI were about 24 million DM in 1997, half from government contract work and half from commercial clients. The annual increase in contracts from commercial clients was greater than 37% during the last three years. At DFKI, all work is organized in the form of clearly focused research or development projects with planned deliverables, various milestones, and a duration from several months up to three years. DFKI benefits from interaction with the faculty of the Universities of Saarbrücken and Kaiserslautern and in turn provides opportunities for research and Ph.D. thesis supervision to students from these universities, which have an outstanding reputation in Computer Science. The key directors of DFKI are Prof. Wolfgang Wahlster (CEO) and Dr. Walter Olthoff (CFO). DFKI s six research departments are directed by internationally recognized research scientists: Information Management and Document Analysis (Director: Prof. A. Dengel) Intelligent Visualization and Simulation Systems (Director: Prof. H. Hagen) Deduction and Multiagent Systems (Director: Prof. J. Siekmann) Programming Systems (Director: Prof. G. Smolka) Language Technology (Director: Prof. H. Uszkoreit) Intelligent User Interfaces (Director: Prof. W. Wahlster) In this series, DFKI publishes research reports, technical memos, documents (eg. workshop proceedings), and final project reports. The aim is to make new results, ideas, and software available as quickly as possible. Prof. Wolfgang Wahlster Director

3 Geschäftsprozessorientiertes Wissensmanagement!#"$ % & & % ' () *+ -,'.0/$ ) + % 2 ' %: Heinz-Jürgen Müller, Andreas Abecker, Knut Hinkelmann, Heiko Maus DFKI-D-01-02

4 This work has been supported by a grant from The Federal Ministry of Education, Science, Research, and Technology (FKZ ITW-01 IW 901). Deutsches Forschungszentrum für Künstliche Intelligenz 2001 This work may not be copied or reproduced in whole or part for any commercial purpose. Permission to copy in whole or part without payment of fee is granted for nonprofit educational and research purposes provided that all such whole or partial copies include the following: a notice that such copying is by permission of the Deutsche Forschungszentrum für Künstliche Intelligenz, Kaiserslautern, Federal Republic of Germany; an acknowledgement of the authors and individual contributors to the work; all applicable portions of this copyright notice. Copying, reproducing, or republishing for any other purpose shall require a licence with payment of fee to Deutsches Forschungszentrum für Künstliche Intelligenz. ISSN

5 ! " # %$ #& 3!#"$ % & & % ' () *+ -,'.0/$ ) + % 2 ' %: ')(+*-,/ /687 (+,:9;4 5/<-< ( 6+=/>,/? 6 (A@CB >"D (+EGFC( 6+= HI, 5 J ')*-,/FC( = ')(+*-FCL 9M@ 5 B 6.ONCPQP R SUTWV/XTWV Y Z[]\\!^1_\`bac_aAdc^1Ì^1_fehgW[ji3kmlcno_ lq[j^1pj^1_rqs_fe!^gi3_^1tì^1_ acp]\s^1[]_^)u/^1\!no_k^gi3\gw[]v3tfe[jdc^w ac_a+x dc^1ì^1_feacyz-doaau/^oac_dc^1\!^1t^1_ {}Z~^1[jedc^Gi3[]_dc^Gi)[]\!e%!^1knQv3t k[j^i s_ƒ1actp k^gi)qs_fe!^gi3_^1tì^1_ k[j^ no_ i^ge!^s ˆin+!^ e!^dc^1\!eaaie!^ge%nqk^gî dc^g p]ac_fê taau/^1_ {oqs_kikac\ˆncucg%notplcno_iz[]\\!^1_\v3taaz-epj^gi3_ Š%^Gi3aAey_do\y_fe!^Gi3_^1tÌ^1_ y_ko ˆi3a e[ ^Gi3_Œ^1[]_^h ^1[]t^slcno_OŽ ncidc^1t^1_\ìnqk^1p]pj^1_ C no_ƒg^g e!^1_ y_k acyv3t Cncz-e g aai^1\! Q\!e!^1Ì^1_~^1_fe gw[]v ^1pjegWyi3k^1_ { []_~ si3y_k z8 yihk[j^b /yio yv tacpjey_dok^gi qs_fe!^gi3_^1tì^1_uy_kškac\ Qv3t^1[je!^Gi3_šlQ[j^1pj^GiIu/^Gi^1[je\Iu/^Gdcno ^1_^GiŒ ˆin+!^ e!^ p][j^gdceb\[]v3t^giokaai!x []_ u/^gdcio y_k^geg kac\\z[]\\!^1_\`bac_aadc^1ì^1_feacp]\ƒ1y\ aae!ƒ1p][]v3t^nqk^gidoaaisy_aaut ac_do[jdc^ syz-doaau/^ ac_dc^1\!^1t^1_œgw[ji3k y_km_cyiwy_dc^1_ ydc^1_km[]_mk[j^hu/^ge!i3[j^gup][]v3t^1_ Wup acyz-^[]_fe!^gdci3[j^gie[]\!eg{ []_^hu/^1\!no_k^gi^ nci3`žu/^ge!i3[j^gup][]v3t^gi Wup acyz-^h\!e!^1p]pj^1_mk[j^) s^1\v3t aaz-e\! incƒg^1\\!^"kaai1{ÿsacv3t sac`bì^gi y_k tacì C :[]\!eb^1[]_ s^1\v3t aaz-e\! incƒg^1\\o^1[]_ Š" y_k^1plcno_ e[jlq[je aae!^1_ kac\œz8 yi ^1[]_^1_ y_k^1_ ^1[]_ ˆidc^Gu_[]\blcno_Z~^Gie inqkyƒ1[j^gieg{ ha:\[j^ acyz k^1_ ^Gi3_ noì /^Ge!^1_ƒG^1_ ^1[]_^1\qs_fe!^Gi3_^1tÌ^1_\huac\[j^Gi^1_ \[]_k s^1\v3t aaz-e\! incƒg^1\\!^œaau/^gi acyv3t k[j^z[]\\!^1_\! p]aae!e!z-nci3` lcno_mqs_fe!^gi3_^1tì^1_ {CZ[]\\!^1_ []\!e []_\!u/^1\!no_k^gi^wkac Olcno_ Š%^1k^1yey_dz8 yi%^1[]_ qs_fe!^gi3_^1tì^1_ g%^1 m^1\wk[j^š%^1aaiu/^1[jey_dilcno_ s^1\v3t aaz-e\! incƒg^1\\!^1_œlc^giu/^1\\!^gieg{ h[j^m^1[]_ƒg^1p]_^1_ Qv3ti3[je!e!^œk^1\Z[]\\!^1_\`bac_aAdc^1Ì^1_feŒ`~ y\\!^1_:k^1\tacpjušacp]\b[]_fe!^gdci3acpj^mš%^x \!eac_ke!^1[]pj^ lcno_ s^1\v3t aaz-e\! incƒg^1\\!^1_ru/^ge!i3acv3tfe!^gesg%^gi3k^1_ h[j^)ÿsye!ƒ1y_dblcno_œz[]\\!^1_m^giz-nopjdce []` WactÌ^1_rk^Gih ˆincƒG^1\\!u/^1aAiu/^1[jey_d []_k^1` ^1\sk^1` Š%^1aAiu/^1[je!^Gis^Gi3`r ncdop][]v3tfeg u/^1\\!^gi^" ˆi!x dc^gu_[]\\!^ ƒ1y"^giƒ1[j^1pj^1_ cacp]\g%^1 ^Gî kac\z[]\\!^1_i_[]v3tfet aae!e!^c{fqsìdc^ ^1tie ^1_fe\!e!^1tfe ^1[]_"dcino\\!^Gi ^1[]pk^1\)Z[]\\!^1_\hª~[]_\!u/^1\!no_k^Gi^b ˆiz«acti3y_do\!gW[]\\!^1_rª~[]` WactÌ^1_ k^gi ˆincƒG^1\\!u/^1aAiu/^1[ x ey_d{f C^1[]_^%Z~^1[je!^GidoaAu/^y_kŠ%^Gg acti3y_dh\!nop]pje!^y_`b[je!e!^1pjuaai`b[jek^gi _fe\!e!^1tcy_dh^giz-nopjdc^1_ { s^gi Z~nci \tnc 3 s^1\v3t aaz-e\! incƒg^1\\!nci3[j^1_fe[j^gie!^1\ Z[]\\!^1_\`bac_aAdc^1Ì^1_fe u[j^ge!^geœ^1[]_u nax i3y`m k[j^&lc^gi3\v3t[j^1k^1_^1_± s\! /^ e!^²k^gí ³µ_fe!^Gdci3aAe[jno_±lcno_±Z[]\\!^1_\`bac_aAdc^1Ì^1_fe y_k s^1\v3t aaz-e\! incƒg^1\\`bac_aadc^1ì^1_febacyz-ƒ1yƒg^1[jdc^1_my_k~ƒ1ymk[]\ ye[j^gi^1_ {} s^gi syz-i3yz%ƒ1yi" []_i^1[ x v3tcy_dolcno_ Š%^1[je!i+ aadc^1_ g aaisu/^ggwy\\!ena /^1_ z-nci3`"yp][j^gieg y` ^1[]_^1_œui^1[je!^1_œ³µ_z-nci3`baAe[jno_\acy\µx eacy\v3tœƒ1ym^gi3`r ncdop][]v3t^1_ { h[j^)tnot^) /actp k^gi^1[]_dc^gi^1[]v3tfe!^1_œš%^1[je!i+ aadc^)[]\!e^1[]_r ^1[]v3t^1_mkaAz8 yi1 kac\\kac\ t^1`babk^1\z~nci \tnc \`b[je!epj^gig%^1[]pj^hdcino\\!^)š%^1acv3tfey_db _k^geg{ Š%^Gƒ ydop][]v3t~k^gih³µ_fe!^gdci3aae[jno_ lcno_ Z[]\\!^1_\`bac_aAdc^1Ì^1_fe y_k~ s^1\v3t aaz-e\! incƒg^1\\!^1_ p]ac\\!^1_ \[]v3tmz-nopjdc^1_k^ ki^1[ sacy e!i3[]v3tfey_dc^1_œy_fe!^gi3\v3t^1[]k^1_ ¹ ºC»1¼A½¾ ÀÂÁ»1ÃÄ+ÅÆoºC»1»1º Ç»ŒÈ É»1Ê Ë Ê»1ÃÉ Ë Ì/ÁOÀ É ÄŒÍÏÎ-»1»1º ¾ Ë» Ð Ë ÊºQÐ º Ë ÁoÑ []_[jdc^ k^gi Š%^1[je!i+ aadc^ u/^1\v3t aaz-e[jdc^1_ \[]v3t `b[je k^gi ³µ_fe!^Gdci3aAe[jno_Òlcno_ Z[]\\!^1_\`bac_aAdc^1Ì^1_feMy_k s^1\v3t aaz-e\! incƒg^1\\`bac_aadc^1ì^1_fe acyz)z«acv3tp][]v3t^giœ ˆu/^1_^c{ h[j^ ˆi3\!e!^1p]p]y_d ^1[]_^1\m acv3tqx no_ƒg^g e\g kac\ e[jlq[je aae!^1_ ^Gi3\!no_^1_ y_k~ haae!^1_ u/^1\v3ti^1[jueg }[]\!ek^gi ^Gi3\!e!^ Qv3ti3[je!e k^1\± s^1\v3t aaz-e\! incƒg^1\\`bac_aadc^1ì^1_fe\g{ []_Ó[]_fe!^Gdci3[j^Gie!^1\ÔŽ ncidc^1t^1_\ìnqk^1p]p ƒ1y` Õ

6 s^1\v3t aaz-e\! incƒg^1\\µx y_kiz[]\\!^1_\`bac_aadc^1ì^1_fe `"y\\ˆƒ1y\ aae!ƒ1p][]v3tbz-^1\!epj^gdc^1_ CgW[j^Wkac\ˆi^x pj^glaac_fe!^ Z[]\\!^1_"z8 yigw[]\\!^1_\[]_fe!^1_\[jlc^ e[jlq[je aae!^1_i[]k^1_fe[ ƒ1[j^giey_k"\!e!i3y eyi3[j^gie gw[ji3k y_k \v3tp][j^1\\p][]v3thz[]\\!^1_\`bac_aadc^1ì^1_fe! incƒg^1\\!^%ƒ1yiš%^gg acti3y_d 1ƒ1y`; sy\!eacy\v3t"y_k ƒ1yimÿsye!ƒ1y_dmlcno_ Z[]\\!^1_Uz-^1\!epj^Gdc^1_ {s Cn no ^1_Z[]\\!^1_\`bac_aAdc^1Ì^1_fea e[jlq[je aae!^1_ `b[jek^giw ˆincƒG^1\\!u/^1aAiu/^1[jey_d no`)u[]_[j^gie g%^gi3k^1_ { ÍÏÎ-»1»1º Ë» Ð Ë ÊºQÐ º Ë Á É Ë UÍ ÅÄ Ì Å Ë ÊºQÐ º Ë ÁoÑ h[j^ qs`b\!^ge!ƒ1y_d lcno_ s^1\v3t aaz-e\! incƒg^1\\!^1_òp ac\\!e \[]v3t kyi3v3tò sinoy Cg aai^xrnqk^gi Z~nci n gx w ac_aadc^1ì^1_feµx \! Q\!e!^1Ì^"e!^1v3t_[]\v3t y_fe!^gi3\!ec ye!ƒg^1_ { Z~nci n gx w ac_aadc^1ì^1_fe\! Q\!e!^1Ì^ ncnci3k[]_[j^gi^1_œk[j^ Š%^1aAiu/^1[jey_dœ\!e!i3y eyi3[j^gie!^gi" s^1\v3t aaz-e\! incƒg^1\\!^c []_k^1`ï\[j^bk[j^s!^gg%^1[]p]\acp]\)_ acv3t\!e!^1\ ƒ1y u/^1aaiu/^1[je!^1_k^1_ e[jlq[je aae!^1_ []k^1_fe[ ƒ1[j^gi^1_ k[j^1\!^ k^1_òš%^1aaiu/^1[je!^gi3_ ƒ1ynci3k_^1_ s_fg%^1_ky_do\! incdci3ac`bì^s\!eaaie!^1_my_kœk[j^si^1pj^glaac_fe!^1_ haae!^1_mu/^gi^1[je\!e!^1p]pj^1_ {oz[]\\!^1_\µx `bac_aadc^1ì^1_fea e[jlq[je aae!^1_ no ^1_Ok[j^1\!^s ncnci3k[]_aae[jno_\!z«y_ e[jno_i^gid ac_ƒg^1_ []_k^1` \[j^ ƒc{ Šs{k^1_ /ydci3[ acyzkac\z8 yik[j^a ey^1p]pj^ syz-doaau/^i^1pj^glaac_fe!^)z[]\\!^1_my_fe!^gi3\!ec ye!ƒg^1_ { ¹ ºC»1¼A½¾ ÀÂÁ»1ÃÄ+ÅÆoºC»1»1º Ç» ¹ ºCʺ Ë» Á Ë ºC»IÍÏÎ-»1»1º Ë» Ð Ë ÊºQÐ º Ë Á» Ñ h[j^ ³µk^1_fe[ a+x e[jno_ry_km^ /^ e[jlc^iqs`b\!^ge!ƒ1y_dœlcno_~ s^1\v3t aaz-e\! incƒg^1\\!^1_~[]\!e^1[]_^)k^gih ^Gi3_acyz-doaAu/^1_ k^gibqs_fe!^gi3_^1tì^1_\!ncidoac_[]\aae[jno_ { h[j^œwrnqk^1p]p][j^gi3y_d s e[]`b[j^gi3y_d y_kš sye!no`baae[ x \[j^gi3y_drlcno_ s^1\v3t aaz-e\! incƒg^1\\!^1_ no`)u[]_[j^gi^1_ma ey^1p]pj^1\z[]\\!^1_:`b[je"z-io yt^gi^1_: ˆi!x z«acti3y_dc^1_ \!n kac\\}^gi3_ incƒg^1\\!^"\! Q\!e!^1`baAe[]\v3t []_œ^1[]_^ no_fe[]_cy[j^gi3p][]v3t^) ˆincƒG^1\\!lc^Gi!x u/^1\\!^gi3y_d^1[]_dc^gu/^ge!e!^geg%^gi3k^1_œ\!nop]pje!^1_ { []_~gw[]v3tfe[jdc^1\) s_p][j^gdc^1_ k^1\ Z~nci \tnc \ g aai)^1\g ^1[]_ nci3y`&z8 yi)k^1_ sy\!eacy\v3t ƒggw[ x \v3t^1_ Z[]\\!^1_\v3taAz-eŒy_kš ˆi3a[]\ƒ1y u[j^ge!^1_ ˆkac`b[jebk[j^mZ[]\\!^1_\v3taAz-eIlcno_U ˆiz-nopjdc^1_ y_k w []\\!^Giz-nopjdc^1_:acy\Ik^Gib ˆi3a[]\pj^Gi3_^1_ ac g" acti^1_k:k[j^ ˆi3a e[ ^Gib_^1y^OgW[]\\!^1_\v3taAz-ep][ x v3t^ ˆi ^1 fe_[]\\!^s[]_o[]ti^ž ncidc^1t^1_\!g%^1[]\!^1_ y_k% no\y_do\ac_\ aae!ƒg^h[]_fe!^gdci3[j^gi^1_ no ^1_ {C sy\ k[j^1\!^1` si3y_k \[]_k Š%^1[je!i+ aadc^ lcno_ Z[]\\!^1_\v3taAz-epj^Gi3_ Š%^Gi3aAe!^Gi3_ y_k s_fg%^1_k^gi3_u[]_ukac\ ˆincdci3ac`b` acyz-dc^1_no`bì^1_mg%nci3k^1_ { V %Y/TWV!#"%$'&)(+*-,/ "76 (+,98:3 5/;-; (+" < &>= 5@? ACB "76=D,E*GF%= ACB "IH x ŸWn laaœ s^1y\v3t^ ^1pj^ no` ³µ n laaae[jno_\!dc^1\!^1p]p]\v3taaz-ew`)u ^1v3t_nopjncdo[j^GƒG^1_fe!i3y` haai3`b\!eacke Wx2JK LMONO haai3`b\!eacke W^1[]_ƒx2Poy^Gidc^1_ { w y^1p]pj^gi+qse!^1pj^ no`m{ k^ XY" B[Z $'!#"%$'\>, 5]A &^*-,]VO( ; _ =D,E, acv3ttnqv3t\v3tcypj^i CnopjncetCyi3_ WnQv3t\v3tCypj^ z8 yiz[jie\v3taaz-e W[jdcdc^1_fuacv3t\!e!i3ac\\!^ Õ J xckjdmwm9hpje!^1_ _CyeG{ t[]_ ^1p]`bac Qsz«t\!n{ v3t R,SD"(=F R#T (U+VO(+" s^1ye\v3t^1\s nci3\v3tcy_do\!ƒg^1_fe!i3y` z8 yi m y_\!ep][]v3t^h³µ_fe!^1p]p][jdc^1_ƒsx% h ³ h`)u ˆigW[]_Qxµ Qv3ti+ nok[]_dc^gi Ce!i3ac\\!^ Wx2JOLDJWJWNŒ ac[]\!^gi3\p]acye!^gi3_ s_ki^1ac\g{ Wu/^1v ^Gi+Qhkz [ { k^ &)(+*GV B 8`= 5 F s^1ye\v3t^1\s nci3\v3tcy_do\!ƒg^1_fe!i3y` z8 yi m y_\!ep][]v3t^h³µ_fe!^1p]p][jdc^1_ƒsx% h ³ h`)u ˆigW[]_Qxµ Qv3ti+ nok[]_dc^gi Ce!i3ac\\!^ Wx2JOLDJWJWNŒ ac[]\!^gi3\p]acye!^gi3_ W^1[ n{ w acy\ Qhkz [ { k^ a

7 UV TWV žt µy si1{ž nop ^GisŠ acv3t «qs_[jlc^gi3\[je aaes CeG{ hacp]pj^1_ si1{pcno\!^gzwncz-^gi!x spjz-^1[]\  Q[j^1Ì^1_\ W " wu y_v3t^1_ Ce!^Gz«ac_rWnci3_ «i3[j^1ki3[]v3tqx spj^+ac_k^giqs_[jlc^gi3\[je aae ˆi3p]ac_dc^1_Qx ŸŒ yi3_fu/^gid ˆincz { si1{ Ce!^Gz«ac_ PoaAupjno_\ [ «i3[j^1ki3[]v3tqx spj^+ac_k^giqs_[jlc^gi3\[je aae ˆi3p]ac_dc^1_Qx ŸŒ yi3_fu/^gid ˆincz { si1{ h[]`b[je!i3[]\ aai3aado[]ac []\ «qs_[jlc^gi3\[je aaez[j^1_ Z~nopjz-doac_d y^gz  %i^1k[jew Qy[]\\!^c % yi3[]v3t si1{ no_acp]kmw ac[j^gi «qs_[jlc^gi3\[je aae ^Gdc^1_\!uyid ˆincz { si1{ i3ac_ w acyi^gi «qs_[jlc^gi3\[je Oncz acpjdoaai w []v3taa^1p}ƒ1yiwwu ytpj^1_ «qs_[jlc^gi3\[je aaewwu y_\!e!^gi ˆincz { si1{ s_ki^1ac\su/^gig%^1[]\ «qs_[jlc^gi3\[je aae i3ac_ z«yie+w ac[]_ si1{qspji3[]v3tm ^1[]Ì^Gi  CgW[]\\p][jz-^s W " % yi3[]v3t w aaie[]_œ ncetacye «s^1ye\v3t^ ^1pj^ no` W " Š%no si1{/ Ce!^ /^1_ CeacaAu «qs_[jlc^gi3\[je aae aai3p]\!i3yt^ N

8 Inhalt Wissensmanagement und Workflow-Management Anforderungen an die Workflow-Unterstützung für wissensintensive Geschäftsprozesse Sven Schwarz, Andreas Abecker, Heiko Maus, Michael Sintek DFKI GmbH, Kaiserslautern Using Conceptual Graphs for Organization Modeling in Workflow Management Systems Jürgen Klarmann Universität Stuttgart Workflow Management in the Light of Emerging Collaborative Applications Ulrich Hasenkamp, Wolfgang Hilpert Philipps-Universität Marburg Wissensgenerierung aus Geschäftsprozessen und Workflowsystemen mit Hilfe von Systemischer Beratung Tomas Bohinc Deutsche Telekom, Bonn Praxisberichte I Management von Prozesswissen in Fahrzeugentwicklungsprojekten Christian Rupprecht, Thomas Rose, Martin Fünffinger, Holger Schott, Albrecht Sieper, Christopher Schlick, Manfred Mühlfelder FAW Ulm, BMW München, IAW Aachen IT-unterstützter Wissenstransfer in der internationalen Forschung und Entwicklung - Ein Praxisbericht des Marktplatz des Wissens der BMW AG Michael Gehle RWTH Aachen Erfahrungen über die Einführung von Wissensmanagement in einem Großunternehmen Eberhard Bohn, Doreen Kopke Drägerwerke Lübeck, TU Dresden Wissensorientiertes Projektmanagement als Implementierungsansatz für Knowledge Management Angelika Bordt RWTH Aachen

9 Wissensmanagement und Geschäftsprozesse I Business Process Oriented Knowledge Management Peter Heisig Fraunhofer IPK Berlin Software-Unterstützung für das Geschäftsprozessorientierte Wissensmanagement Andreas Abecker, Heiko Maus, Ansgar Bernardi DFKI GmbH, Kaiserslautern Process Oriented Knowledge Management Stefan Jablonski, Stefan Horn, Michael Schlundt Universität Erlangen-Nürnberg Praxisberichte II Wissens-Ko-Produktion und dynamische Netze: Kooperative Wissenserzeugung und nutzung in wissensintensiven Geschäftsprozessen Frank Fuchs-Kittowski Fraunhofer ISS, Berlin Wissensmanagement im Projektgeschäft Marlis Brunk, Heiko Armin Schneider T-Nova Berkom Berlin Integrating Business Process and Lessons Learned with an Experience Factory Björn Decker, Klaus-Dieter Althoff, Markus Nick, Carsten Tautz Fraunhofer IESE Kaiserslautern Geschäftsprozessorientiertes Wissensmanagement in einem globalen Unternehmen: Am Beispiel von SIEMENS ICN ShareNet Joachim Döring, Ulrich Gerndt, Stefan Jenzowsky Siemens ICN München Wissensmanagement und Geschäftsprozesse II Unsichtbar oder Vergessen Wie man verborgenen Wissensprozessen auf die Schliche kommt Marcel Hoffmann, Thomas Goesmann, Andrea Misch Universität Dortmund, Fraunhofer ISST Dortmund Integrierte Prozeß- und Kommunikationsmodellierung als Ausgangs-punkt für die Verbesserung von wissensintensiven Geschäftsprozessen Ulrich Remus Universität Regensburg Applied knowledge management in innovation processes Anja Schulze Universität St. Gallen Eine prozessorientierte Mikro-Logik für praxisnahe Wissensmanagement- Projekte: Grundlagen und Vorgehensmodell Marco Bettoni, Nicole Baschung, Georg Endress, Markus Rütti Fachhochschule beider Basel

10 Tools und Poster Prozessorientiertes Wissensmanagement mit CognoVision Stephan Müller, Rudi Herterich DHC Saarbrücken Prozessmodellierungswerkzeuge und das Semantic Web Christian Fillies, Frauke Weichhardt, Gabriele Koch-Süwer Filles & Friends Consulting, beratung im netz, Gedion Wissenstransparenz als Wettbewerbsvorteil Einstiegsmethode und -werkzeug in das praktische Wissensmanagement von Unternehmen Ingo Dämming, Claudius Borgmann, Uwe Hess IMS GmbH, Borleben Abschätzung des Potentials von Informations- und Kommunikationstechnologien im Kontext von Wissensmanagement Andrea Brönner Universität Erlangen-Nürnberg e-knowledge Bart Depovere Siemens Brüssel Kopplung von Workflow und Organisationsgedächtnis Joachim Zobel Price Waterhouse Coopers

11 Anforderungen an die Workflow-Unterstützung für wissensintensive Geschäftsprozesse Sven Schwarz, Andreas Abecker, Heiko Maus, Michael Sintek Deutsches Forschungszentrum für Künstliche Intelligenz DFKI GmbH Postfach 2080, D Kaiserslautern Phone: , Fax: Zusammenfassung Wissensmanagement zielt darauf ab, die Durchführung wissensintensiver Geschäftsprozesse im Unternehmen effizienter und effektiver zu machen. Während Software-Unterstützung für das WM momentan vorwiegend auf Kommunikations- und Kollaborations-Unterstützung bzw. verbessertes Informationsmanagement baut, war ein gezielter Geschäftsprozess- bzw. Workflow-Support für wissensintensive Tätigkeiten bisher kaum Gegenstand der Betrachtung. Ausgehend von einer Zusammenfassung der Merkmale gegenwärtiger Workflowmanagementsysteme und einer Charakterisierung wissensintensiver Aktivitäten, leiten wir in diesem Papier Anforderungen für eine Prozessmanagement-Unterstützung für den Wissensarbeiter ab, skizzieren einige existierende Arbeiten in diese Richtung und diskutieren unsere momentane Konzeption zur softwaretechnischen Umsetzung der gewünschten Funktionalitäten. 1 Ansatz und Ziele von Workflowmanagement Heutige Unternehmen müssen sich dem globalen Wettbewerb stellen, ständig die Geschäftskosten senken und schnellstmöglich neue Dienstleistungen und Produkte anbieten. Dies erfordert ein konstantes Überdenken, Optimieren und Modifizieren der Geschäftsabläufe und eine effektive Gestaltung des Informationsflusses. Workflow(Wf)-Technologie erleichtert dies mittels Methoden und Software zur Unterstützung von (i) Geschäftsprozess- Modellierung zur Speicherung der Geschäftsabläufe als Wf-Spezifikation, (ii) Geschäftsprozess-Reengineering zur Optimierung der Geschäftsabläufe und (iii) Wf-Automation (Generierung von Wf-Implementationen) zur Durchführung und Kontrolle der Geschäftsabläufe. Die Zielsetzung der Wf-Automation durch ein Workflow Management System (WfMS) wird i.a. als Provide the right information and the right tools to the right receiver at the right time. beschrieben, was direkt zu den folgenden vier Fragen führt (zitiert nach [14]): WAS ist die richtige Information? WIE wird die Information bearbeitet / geliefert? WER bekommt die Information bzw. WER bearbeitet eine Information? MIT WELCHEN TOOLS werden die Informationen bearbeitet?

12 Dabei wird also neben der Datenmodellierung und der Beschreibung der in einen Prozess involvierten Applikationen bei der zweiten (und teilweise der dritten) Frage die interessante Problematik der Beschreibung der Prozesslogik eines Vorganges angesprochen. In konventionellen WfMSen wird die Durchführung eines Wfs mittels eines strengen Ablaufplanes ähnlich einem Flussdiagramm vollzogen. Die Prozesslogik wird somit mehr oder weniger auf das Abarbeiten dieses festen Ablaufplanes beschränkt. Der Ablaufplan wird vor der Durchführung modelliert wie von der Workflow Management Coalition (WfMC) definiert. Das gesamte Wf-Management zerfällt somit in zwei Phasen: eine Definitionsphase, in der Prozess-Definitionen erstellt und bearbeitet werden, und eine Ausführungsphase, in der Prozesse instanziiert, ausgeführt und gegebenenfalls kontrolliert werden. 1 Eine genauere Beschreibung des Zusammenhangs zwischen Prozess-Definitionen wird im Terminology & Glossary Dokument 2 beschrieben. Zunächst wird pro Geschäftsprozesstyp eine Prozess-Definition erstellt. Für einen spezifischen aktuellen Geschäftsprozess wird diese Prozess-Definition dann instanziiert und ausgeführt. Änderungen werden traditionell nicht vorgesehen. Der Ablauf muss a-priori bekannt und in einer Prozess-Definition modelliert sein. Wenn überhaupt Änderungen möglich sind, dann nur bei der Prozess- Definition, was dann allerdings eine Änderung aller Instanzen zur Folge hat. Es zeigte sich schnell, dass der konventionelle Ansatz zu starr war, um den Anforderungen der Realität bezüglich Dynamik und Flexibilität gerecht zu werden. Sich verändernde Rahmenbedingungen im Umfeld von Geschäftsprozessen erfordern die lang- und mittelfristige Evolution von Modellen. Weiterhin verlangen Ausnahmesituationen, Fehler und unvorhersehbare Ereignisse nach flexibler Handhabung auf Ebene der Prozessinstanzen. Es resultierte die Aufspaltung in drei grundsätzliche Herangehensweisen: Ad-hoc Workflow I.a. existiert keine allgemeine Prozess-Definition, sondern bei Prozessbeginn kann der Bearbeiter eine Instanz durch Erzeugen einer elektronischen Umlaufmappe mit einer eingebauten Repräsentation der Routing-Logik erzeugen. Änderungen dieses Routings sind dem Instanzenbesitzer, allen am Umlauf-Beteiligten, oder definierten Beteiligten erlaubt. Flexibler Workflow Erstellen einer Prozess-Definition vor der Ausführung, aber mit der Möglichkeit, die Prozesse und ihre Modelle während der Ausführung zu modifizieren. Folgende Ansätze lassen sich finden (siehe [18]): Die Prozess-Definition enthält offene Punkte (black boxes), deren genaue Ausgestaltung durch Nachmodellieren auf Instanzenebene zur Laufzeit geschieht (open point approach). Die Prozessdefintion enthält Beschreibungen bestimmter möglicher Ausnahmesituationen und Fehlerfälle (Ressourcen liegen nicht vor, ein Mitarbeiter nimmt eine Aktivität nicht an,...) mit definierten Behebungsprozeduren (Verschieben der Aktivität, Delegation an anderen Mitarbeiter, Prozessänderungserlaubnis für bestimmte Personen,...). 1 Wf Reference Model, Seite 7 [ 2 Terminology & Glossary, Seite 7 [

13 Bestimmte oder alle Prozessbeteiligte haben die Möglichkeit, auf Instanzen- bzw. Definitionsebene in Problemsituationen gewisse Änderungen mit einem vordefinierten Operatorvorrat (streiche Aktivität, ändere Reihenfolge, überspringe,...) durchzuführen (meta model approach). Bei Änderungen der Definition muss die Konsistenz eventuell anderer laufender Instanzen sichergestellt werden. Strukturierter Workflow Erstellen von vordefinierten Prozessen in reaktiv unveränderbaren Umgebungen mit relativ strenger Ausdruckskraft. Die Prozess-Modelle können nur als ganzes verändert werden. Einzelne laufende Prozesse sind nicht modifizierbar. Diese Definition entspricht dem klassischen Workflow-Konzept. Nachdem wir soweit Grundansatz und aktuelle Hauptausprägungen der Wf-Idee kennengelernt haben, wollen wir im nächsten Abschnitt 2 eine Typisierung von Geschäftsprozessen und ihrer Teilaufgaben betrachten, sowie im darauffolgenden Abschnitt 3 entsprechende Merkmale und Elemente der Wissensarbeit untersuchen. In Abschnitt 4 wird die Eignung gewisser Geschäftsprozessklassen für die Unterstützung durch WfMSe beschrieben und die Klasse der wissensintensiven Geschäftsprozesse (WiGPe) eingeführt. Es folgt eine Gegenüberstellung der oben eingeführten drei Grundausprägungen des Wf-Supports in Abschnitt 5, denen wir wünschenswerte Eigenschaften einer Prozessunterstützung für Wissensarbeiter gegenüberstellen. Zur Umsetzung dieser Eigenschaften stellen wir in Abschnitt 6 einige Basis-Designentscheidungen für ein WfMS zur Unterstützung WiGPe vor und diskutieren einige Punkte zur weiteren Implementierung. Abschnitt 7 skizziert einige aktuelle verwandte Arbeiten, die Teile unseres Ansatzes bereits in irgendeiner Weise umsetzen, während wir schließlich in Abschnitt 8 kurz zusammenfassen. 2 Geschäftsprozess- und Aufgabentypen Bevor man Anforderungen an die Rechnerunterstützung durch ein WfMS stellt, ist es zweckmäßig, zunächst einmal die Geschäftsprozesse selbst zu charakterisieren. Picot [25] klassifiziert Geschäftsprozesse anhand von 5 Kriterien, die er als Prozessvariablen bezeichnet (Abbildung 1). Mit Hilfe dieser Prozessvariablen lassen sich drei idealtypische Prozesstypen (vgl. auch Abbildung 2-links), die Picot [25] folgendermaßen beschreiben: Routineprozess: Diesen Prozesstyp findet man typischerweise im Rechnungswesen, wo oft mehrere Menschen gemeinsam standardisierte Abläufe abarbeiten. Der Prozess hat eine klare, flache Struktur und behält diese auch weitestgehend auf Dauer. Regelprozess: Im Gegensatz zum Routineprozess bleibt die Struktur zwar noch kontrollierbar, ist aber häufigen Änderungen von Seiten der Mitarbeiter unterworfen. Der Ablauf eines Prozessmodells ist nicht mehr determiniert, wohl aber der individueller Prozesse. Beispiel: Auftragswesen des Anlagenbaus Einmaliger Prozess: Hier handelt es sich um typischen Vertreter von Managementoder Projektaufgaben. Weder Prozessablauf noch Kommunikationspartner sind konkret bestimmbar. Somit wird der Ablauf meist sehr kommunikationsintensiv durch einzelne Mitarbeiter oder Teams individuell durchgeführt. Offensichtlich sind diese Art von Prozessen kaum planbar und somit genauso wenig automatisierbar.

14 Prozessvariable Indikatoren Komplexität Zahl der Teilaufgaben Anordnung der Teilaufgaben (sequentiell, parallel) Abhängigkeiten/Rückkoppelungsbedarf der Teilaufgaben Rollen der in den Prozess involvierten Mitarbeiter Grad der Wiederholungshäufigkeit ohne Strukturveränderungen Veränderlichkeit Planbarkeit der Kommunikation während der Informationsbeschaffung Offenheit des Prozessergebnisses Änderungsanfall bedingt durch organisationsinterne/-externe Anforderungen Detaillierungs- Möglichkeit der Zerlegung des Gesamtprozesses in einfache Teilschritte grad Eindeutigkeit des erforderlichen Inputs, der Transformationsschritte und des Outputs Grad der Anzahl der am Prozess beteiligten Mitarbeiter Arbeitsteilung Koordinationsbedarf des Gesamtprozesses Interprozess- Schnittstellen zu anderen Prozessen verflechtung Gemeinsame Datennutzung mit anderen Prozessen Prozesshierarchie (Beitrag des Prozesses zu über-, unter- oder nebengeordneten Prozessen) Abbildung1. Kriterien und Indikatoren von Geschäftsprozessen, wie von [25] vorgestellt. Ein Prozess setzt sich aus einer Vielzahl von Teilaufgaben zusammen. [25] teilt diese (Teil-) Aufgaben ebenfalls in drei Fälle ein (zur Charakterisierung eines Prozesses nach seinem Aufgabentyp nimmt man den im Prozess überwiegend vorherrschenden Typ): Der Routinefall ist gekennzeichnet durch seine hohe Planbarkeit bei niedriger Komplexität. Der Informationsbedarf ist ebenso gut bestimmt wie der Lösungsweg. Zur Lösung werden viele Hilfsmittel und genau festgelegte Kooperationspartner herangezogen, wobei die Kommunikationsintensität eher niedrig bleibt. Die Arbeit ist sehr stark dokumentorientiert. Beim Sachbezogener Fall erhöht sich bereits die Komplexität, während sich die Planbarkeit verringert und der Lösungsweg nunmehr nicht immer geregelt erscheint. Der Informationsbedarf und die Kooperationspartner sind nun nicht mehr eindeutig bestimmbar, weshalb auch das Arbeiten mit Dokumenten oft nicht mehr ausreicht. Der Einzelfall stellt für eine maschinelle Unterstützung eine Katastrophe dar, da hier hohe Komplexität mit niedriger Planbarkeit gepaart auftritt. Der Informationsbedarf sowie der Lösungsweg sind gänzlich unbestimmt. Die Kooperationspartner sind ebenfalls nicht festgelegt nichtsdestotrotz handelt es hierbei aber um eine sehr kommunikationsintensive Arbeit unter Zuhilfenahme von wenigen Hilfsmitteln. Die Arbeit ist nicht mehr dokumentenorientiert. Bevor wir auf die Eignung gewisser Prozesstyp-Aufgabentyp-Kombinationen für die WfMS-Unterstützung eingehen, wollen wir nun den Begriff des WiGPes etwas beleuchten. 3 Wissensintensive Geschäftsprozesse und -aufgaben Selbstverständlich sind alle betrieblichen Tätigkeiten zu einem gewissen Anteil mit Wissen verbunden und erfordern mehr oder weniger Erfahrung im jeweiligen Tätigkeitsbereich.

15 Nichtsdestoweniger macht es Sinn, sich beim Start einer WM-Initiative im Unternehmen zuerst einmal auf einen (oder wenige) wesentliche Kernprozesse im Zentrum der betrieblichen Leistungserstellung zu konzentrieren, die in hohem Maße Fachwissen, trainiertes Entscheidungsvermögen, Informationsintegration aus vielen Quellen, Erfahrung in ähnlichen Fällen, etc. erfordern, so dass Wissen hier zum kritischen Erfolgsfaktor wird; 3 Prozesse, deren Wissenorientierung oft geprägt ist durch Gebundenheit an wenige erfahrene Personen, Verteiltheit dieser Experten über große Entfernungen, Flüchtigkeit von Expertise und Entscheidungsbegründungen bei Mitarbeiterfluktuation und wegen mangelnder Dokumentation oder Dokumentierbarkeit usw. Die Konzentration auf solche Prozesse bzw. Aufgaben in Prozessen lässt sich beispielsweise dadurch rechtfertigen, dass bei diesen Tätigkeiten oft der Leidensdruck genügend groß ist, um eine grundsätzliche Veränderung der Arbeitsweise angehen zu können; dass oft verhältnismäßig wenige Mitarbeiter involviert sind, mit einem relativ hohen Ausbildungsstand, was die Erfolgsaussichten eines Change Programms erhöht; dass solche Aufgaben häufig Gegenstand von Qualitätssicherungs- oder Zertifizierungsmaßnahmen sind, so dass man sich ohnehin einmal grundsätzlich mit ihnen beschäftigen muss; oder dass durch Qualitätsverbesserungen im Ergebnis, Fehlervermeidung oder Effizienzsteigerungen bei der Durchführung solcher Aufgaben durch ihre Schlüsselstellung im Betrieb große Hebelwirkungen erzielt werden können (beispielsweise kann keine Initiative zur Verringerung von Kodierfehlern bei der Software-Erstellung jemals so große positive Effekte zeitigen, wie die Verbesserung der Kommunikation und Dokumentation von Entwurfsentscheidungen in der Grobdesignphase des Softwareentwicklungsprozesses, wo schon kleine Fehler zu großen Effekten in der kompletten Produktentwicklung führen können). Im Zuge unserer eigenen Industrieerfahrungen [20] zeigte sich die Notwendigkeit für WM-Funktionalitäten bei Anwendungsproblemstellungen wie technischen Entwurfsaufgaben / Produktentwicklung, bzw. Konfiguration von Anlagen, bei anderen Autoren wurden Anwendungsszenarien bei der Entscheidungsunterstützung [33], der strategischen Planung [13] oder im kreativen Design [16,29] untersucht. Ein weites Feld der Anwendung von WM, auch mit einer deutlichen Vorreiterrolle in der kommerziellen Nutzung, ist der Bereich Projektdurchführung / Projektmanagement bei Consulting-Aufgaben [23,8]. All diese Aufgabenbereiche sind keine typischen Anwendungsszenarien für Geschäftsprozess- oder WfMSe, man vermisst die wohlstrukturierten Abläufe, die klar erkennbaren, wiederholbaren Dokument- und Kommunikationsflüsse. Dennoch lässt sich die Notwendigkeit von WM-Maßnahmen unmittelbar einsehen; WM seinerseits kann aber auf vielfältige Weise synergetisch mit GPMSen und WFMSen verbunden werden (siehe [6]). Es stellt sich somit die Frage, ob sich die obengenannten Bereiche grundsätzlich jedem Prozessmanagement oder jeder Prozessunterstützung entziehen. Unseres Erachtens lässt sich dazu zumindest einmal folgendes beobachten: 1. Auch hochgradig unstrukturierte Aufgaben wie das kreative Design sind häufig eingebettet in durchaus konventionelle Prozesse, die zum Beispiel Rahmenvorgaben machen, Deadlines festsetzen, Kommunikationspartner festlegen, Dokumentationsformate und Ausgabedokumente vorschreiben, Input-Dokumente liefern usw. Die wissensintensive 3 Der initiale Fokus auf zentrale Aufgaben wird z.b. in der Know-Net Methode [9] in Stufe 1 Strategische WM-Planung als make the KM business case beschrieben, oder spiegelt sich in der CommonKADS-Methode [7] in der Machbarkeitsanalyse (Worksheet OM-5: feasibility decision document) wider.

16 Aufgabe taucht in diesem Fall als Black Box in einem gewöhnlichen Geschäftsprozess auf. Es stellt sich die Frage, ob die Einbettung in einen umfassenden konventionellen Workflow nicht zu Verbesserungen führen kann. Im KnowMore-Projekt [3] beispielsweise wird zur Unterstützung solcher Aufgaben eine aktive Informationsbereitstellung aus dem Organisationsgedächtnis eingesetzt, welche Kontextparameter des Workflows zur Verbesserung des Information Retrieval benutzt. 2. Auch umgekehrt kann es vorkommen, dass innerhalb eines komplexen Ad-hoc-Prozesses, der sich selber der a-priori-planung und Ablaufprogrammierung entzieht, durchaus stark strukturierte, eher konventionell angehbare Teilaufgaben oder Prozessanteile auftauchen. Man denke beispielsweise an das Einholen amtlicher Genehmigungen innerhalb eines großen Bau- oder Raumplanungsvorhabens, oder auch nur an das Arrangieren eines Meetings (Terminabsprachen, Einladungen, Agenda, Raum- und Hardwarereservierung, Catering, Anreiseplanung, Unterkunft, Protokollführung,...) innerhalb eines komplexen kollaborativen Prozesses. Hier entstehen konventionelle Wf- Bruchstücke innerhalb eines schwächer strukturierten umgebenden Prozesses. In einer solchen Situation kann wiederum der umliegende schwach strukturierte Prozessanteil Input für den stark strukturierten liefern, bzw. seinen Output weiternutzen; ferner kommen natürlich die bekannten Wf-Nutzeffekte für den stark strukturierten Prozessanteil zum Tragen. Man sieht also, dass der Einsatz von Wf-Technologien auch im Umfeld wissensintensiver Aufgaben durchaus Sinn macht. Bevor wir auf mögliche konkrete Ausprägungen der Unterstützung näher eingehen, wollen wir noch etwas auf die Charakteristika wissensintensiver Arbeit eingehen, wie sie in der Literatur diskutiert werden. Rittels Begriff der Wicked Problems Schon in den 70er Jahren charakterisierte Rittel (siehe[27,28] und [13]) Wissensarbeit als primär durch den Umgang mit wicked problems ( harte Problemstellungen, im Gegensatz zu tame problems, einfachen Problemen) geprägt. Einige Merkmale von wicked problems: Problembeschreibung: Schon die klare Problemformulierung ist schwierig und i.a. nicht ohne Dissens aller beteiligter Parteien zu erreichen, z.b. hinsichtlich des adäquaten Abstraktionsniveaus zur Aufgabenbeschreibung. Im Kern läuft die Aufgabenstellung häufig auf ein komplexes System von Anliegen (Themen, Diskussionspunkten, Entscheidungsvariablen) und Randbedingungen (Restriktionen, Optimierungsgrößen, Constraints) hinaus. Dabei sind die Bedingungen bisweilen stark veränderlich über die Zeit hinweg, und auch Anliegen können sich ändern. Problembearbeitung: Normalerweise sind viele Parteien mit ihren Interessen involviert, so dass die Lösungsfindung eher ein Aushandeln zur Erreichung eines akzeptablen Kompromisses ist als ein Problemlösen. Lösungen müssen mithin eher konstruiert oder entdeckt werden, als aus einer gegebenen Lösungsmenge ausgewählt. Häufig gibt es nicht richtige oder falsche Lösungen, sondern mehr oder weniger gute, oft sogar mit moralischen oder politischen Einflussfaktoren bei der Bewertung der Lösungsgüte. Folglich hat man oft keine klaren Erfolgskriterien, sondern beendet die Lösungsfindung, wenn keine Ressourcen mehr für die weitere Diskussion da sind.

17 Schon diese erste Grobcharakterisierung macht deutlich, dass ein Software-Support für solche Tätigkeiten eng mit Kommunikations- und Kollaborationssystemen gekoppelt sein sollte, dass die Dokumentation von Abläufen, Planungen und Entscheidungen mit ihren Ursachen nützlich wäre, dass eine Planungsunterstützung als Nachdenkhilfe bei der Strukturierung des Problem- bzw. Lösungsraumes vonnöten ist, und dass eine optimierte Informationslogistik hilfreich ist, beispielsweise zum kontinuierlichen Monitoring externer Informationsquellen, um z.b. auf veränderte Rahmenbedingungen sofort aufmerksam zu werden. Bearbeitung wissensintensiver Aufgaben Aufbauend auf den Darstellungen von Kidd [19] und Buckingham Shum [29] ähnliche Darstellungen findet man beispielweise auch bei Davenport [17] fassen wir typische Merkmale bei der Bearbeitung wissensintensiver Aufgaben zusammen: Unvorhersehbare Verhaltensmuster: Vielfältige und stark ad-hoc entstehende Verhaltensmuster und Vorgehensweisen sind typisch. Dies schließt den Einsatz konventioneller Wf-Ansätze aus und verlangt nach individuell situativ definierbaren Prozessmustern. Diese würden immerhin Nachvollziehbarkeit unterstützen, könnten in ähnlichen Situationen zur Planung herangezogen werden und könnten auf einem gewissen Abstraktionsniveau zur Definition von sehr groben Standardvorgehensmustern bzw. zumindest Checklisten dienen. Kommunikationsorientiert: Hoch variable Kommunikationsnetzwerke mit vielfältigem Einsatz von Medien sind typisch. Fachliche Inhalte sind wichiger bei der Auswahl von Kooperationspartnern als starre betriebliche Aufbauorganisation. Wissen ist massiv in ausgetauschten Dokumenten, Mails, Entwürfen, etc. enthalten. Dies erfordert die Integration von Prozessmanagement und Kommunikationskanälen sowie die Inhaltsorientierte Erschließung von Dokumenten und auch s für das Informationsmanagement. Mächtige Yellow-Page-Systeme sollten die Basis für die Zusammenstellung virtueller Teams sein. Interdisziplinär: In zunehmendem Maße erfordert die Bearbeitung komplexer wissensintensiver Aufgaben die Expertise vieler Fachrichtungen und Unternehmensbereiche. Dies erfordert die schnelle Erfassbarkeit des aktuellen Prozessstatus für neu hinzukommende Team-Mitglieder sowie den einfachen Zugriff auf Hintergrund-Informationsmaterial zum Briefing in einem Thema noch unerfahrener Mitarbeiter/innen. Informationslastig: Die oftmals auch nur oberflächliche Verarbeitung großer Mengen von Information und Dokumenten ist typisch. Automatische inhaltsorientierte Anbindung an Informations-, insbesondere Push-Dienste wären hier von Vorteil, ebenso die kontextuelle, automatisch indexierte Ablage von Information. Argumentationsbasiert: Das Vorgehen ist ein kontinuierliches Argumentieren und Verhandeln entlang von Schlüsselanliegen, Kernfragen, Handlungsoptionen und Optimierungskriterien. Ein System sollte es zumindest ermöglichen, die eigene Arbeit entlang solcher Grundkategorien zu planen, organisieren und auch zu dokumentieren. Dies würde u.a. die schrittweise Top-Down-Verfeinerung von Aktivitäten, oder auch die Terminierung von Aktionen umfassen. Iterativ: Da der Problembearbeitungsprozess von Haus aus iterativ und inkrementell ist, muss eine Prozessbeschreibungssprache natürlich Zykel und ggf. spätere Verfeinerun-

18 Ausprägung Variablen niedrig mittel hoch Komplexität Grad der Veränderlichkeit Detaillierungsgrad Grad der Arbeitsteilung Interprozess- verflechtung Routineprozess / Routinefall Regelprozess / Sachbez. Fall Einmaliger Prozess / Einzelfall Abbildung2. Links: Picots Charakterisierung verschiedener Geschäftsprozesstypen. Rechts: Eignung von Prozess-/Aufgabentypen für WfMSe [25]. gen früherer Prozessschritte erlauben. Der Zugriff auf Dokumente und Prozessabläufe in früheren Durchläufen wäre hier hilfreich. 4 Eignung von Prozess-/Aufgabentypen für WfMSe Eine Untersuchung aller Kombinationsmöglichkeiten von Prozess- und Aufgabentypen liefert Hinweise auf die Eignung dieser Kombinationen für die Unterstützung durch ein WfMS. Picot [25] schlägt eine Einordnung dieser Kombinationen in drei Eignungsstufen vor (von nicht geeignet bis voll geeignet, siehe Abbildung 2-rechts). Dabei wurde das ursprüngliche Diagramm leicht modifiziert und zeigt unsere Einordnung des WfMSs zur Unterstützung WiGPe. Wie aus dem letzten Kapitel leicht nachvollziehbar, siedeln wir WiGPe primär im Bereich der Einzelfall-Aufgaben an. Fließende Übergänge zu Sach- und Routineaufgaben sowie in Regel- und Routineprozesse sind natürlich zu beobachten, wobei die Variabilität noch eher auf der Achse der Prozesscharakteristika als bei den Aufgabencharakteristika zu sehen ist, weil man wohl nur schwerlich aus reinen Routineaufgaben einen wissensintensiven Prozess wird zusammensetzen können. Dabei kann Bereich 1 eine volle Eignung attestiert werden. Sowohl der Gesamtprozess als auch die Teilaufgaben können nach festen Regeln abgearbeitet werden. Eine Rechnerunterstützung zu diesem Bereich kann hervorragend in Form eines transaktionsorientierten (konventionellen, strukturierten) Workflows erfolgen. Innerhalb des zweiten Bereiches kann den Mitarbeitern immer noch Unterstützung in Form von Dokumenten-Retrieval, , Routineprüfungen etc. bereitgestellt werden, während wichtige Entscheidungen und der genaue Ablauf des Prozesses hauptsächlich in der direkten Verantwortung der Mitarbeiter selbst liegen. Ad-hoc und Flexible Workflows beispielsweise unterstützen diesen Bereich. In Bereich 3 ist ein komplettes WfMS nur schwerlich anzusiedeln, da sowohl die Aufgabe als auch der Ablauf des Prozesses kaum vorherbestimmt werden können und fast gänzlich dem Mitarbeiter überlassen sind. Eine Rechnerunterstützung in diesem Bereich wird sich

19 Abbildung3. Eigenschaften von Workflow-Typen, inkl. der Unterstützung wissensintensiver Geschäftsprozesse. daher hauptsächlich mit Informationsmanagement, Kommunikationsunterstützung und individuellen Planungs- und Projektierungsaufgaben begnügen. Die Funktion dieser Rechnerunterstützung entspricht weitestgehend einem Assistenten, der den Benutzer bei der Arbeit lediglich unterstützt, anstatt durch zwingende Vorschläge das Einhalten eines bestimmten Ablaufplans zu gewährleisten. In diesem Bereich ist die Unterstützung WiGPe vorwiegend anzusiedeln. Im FRODO-Projekt [1] streben wir eine Unterstützung zur Planung und Durchführung sachlich komplexer Geschäftsprozesse mit geringer Häufigkeit in Form eines WfMSs an. Darüber hinaus sollen bereits durchgeführte Prozesse als Informationsquelle nutzbar gemacht werden, um damit zukünftige Geschäftsprozesse leichter planen und durchführen zu können. Die Unterstützung zielt also zunächst auf die Planung, Durchführung und Archivierung einmaliger Prozesse ab, allerdings mit dem Hintergedanken, dass archivierte, abgeschlossende Prozesse zu zukünftigen Prozessen zumindest ähnlich genug sind, dass eine Wiederverwendung nach leichten Modifikationen dennoch möglich ist. 5 Eigenschaften eines Workflow-Supports für WiGPe Abbildung 3 beschreibt die drei in Kapitel 1 dargestellten Wf-Typen in fünf Dimensionen, wie sie von COI 4 vorgeschlagen wurden. Die Abbildung wurde um ein weiteres Diagramm ergänzt, welches wünschenswerte Eigenschaften eines WfMS zur Unterstützung WiGPe skizziert. Der folgende Abschnitt 5 wird auf diesen vierten Wf-Typ und seine Schwerpunkte eingehen. Zunächst stellen wir die fünf Wf-Charakteristika vor: Modifizierbarkeit. Wie oft, wie komfortabel und wie stark sind Änderungen möglich? Hier geht auch ein, ob jeder Benutzer Änderungen vornehmen kann oder bloß bestimmte Administratoren. 4

20 Wiederholfaktor. Wie oft können die Workflows wiederverwendet werden? Müssen die Workflows bei der Wiederverwendung zuerst angepasst werden, verringert sich der Wiederholfaktor. Prozesskomplexität. Können komplexe Arbeitsprozesse adäquat modelliert werden? Ist die Modellierung beliebig verfeinerbar? Sind komplexe Sachverhalte durch ausdrucksstarke Beschreibungen komfortabel modellierbar? Planbarkeit von Varianten. In wieweit ist eine Wf-Variante auf der Basis eines anderen Workflows generierbar? Hier geht es nicht um die Möglichkeit, bereits bestehende Workflows zu verändern. Vielmehr geht es um die Frage, ob zum Zeitpunkt der Erstellung eines neuen Workflows, dieser auf der Basis eines anderen Workflows generiert werden kann und dieser strukturell tatsächlich als Variante geführt wird. Automatische Weiterleitung. Werden den Benutzern automatisch Aufgaben zugeteilt? Sind diese Aufgaben zwingend zu bearbeiten, oder stellen sie für den Benutzer bloß Vorschläge dar? Unterstützung wissensintensiver Geschäftsprozesse Unseres Erachtens sollten die Schwerpunkte zur Unterstützung WiGPe folgendermaßen verteilt sein: Modifizierbarkeit: hoch. Jeder Benutzer kann jederzeit alles modifizieren und verfeinern. Das WfMS ist flexibel und dynamisch an neue entstehende Situationen anpassbar. Außerdem ermöglicht erst eine hohe Modifizierbarkeit, dass Prozesse zunächst grob vormodelliert werden und diese dann während der Durchführung nachmodelliert werden können. Dies entspricht dem open point Ansatz zur Flexibilität und macht nur Sinn, weil wir von hochqualifizierten Power Usern ausgehen können. Wiederholfaktor: gering. Generell ist das WfMS zur Planung und Durchführung von individuellen Geschäftsprozessen gedacht. Daher ist die (exakte) Wiederholung von Prozessen nur von zweitrangiger Bedeutung. Dennoch kann ein gewisser Wiederholungsfaktor durch die Überführung von Prozess(teilen) in Modellen erreicht werden. Diese Modelle können sowohl bei der Generierung als auch während der Durchführung instanziiert in Prozesse eingebaut werden. Somit wird das Wiederverwenden von Prozess(teilen), die sich in der Vergangenheit bewährt haben, ermöglicht. Prozesskomplexität: hoch. Sowohl komplexe Prozesse als auch tiefergehende Modellierung von Einzelfall-Aufgaben sollen unterstützt werden. Das WfMS bietet eine komplexe Modellierung erstens durch beliebige Top-Down-Verfeinerungsmöglichkeit und zweitens durch eine ausdrucksmächtige Sprache zur Beschreibung der Prozesslogik. Planbarkeit von Varianten: gering. Das Erstellen von Wf-Varianten ist aufgrund der Fokusierung auf individuelle Prozesse von geringfügiger Bedeutung. Nichtsdestotrotz stellt das Erstellen von Varianten mithilfe von Prozess-(teil-)Modellen kein Problem dar. Diese (Teil-)Modelle werden zwar instanziiert, die Änderungen werden aber danach direkt auf den Instanzen durchgeführt und nicht etwa auf den Ursprungsmodellen. Allerdings handelt sich anschaulich bei diesen Varianten eher um Workflows, die ähnlich zu dem ursprünglichen Workflow sind. Nach zu erwartenden häufigen Modifikationen wird der neue Workflow unter Umständen nur noch entfernt an den ursprünglichen erinnern.