Figure 3.2 System boundary during analysis of the business system

Size: px
Start display at page:

Download "Figure 3.2 System boundary during analysis of the business system"

Transcription

1 BUSINESS SYSTEMS S far, we have explained business prcesses. Business prcesses are dynamic in nature and invlve activities. Hwever, if we want t lk at the entire business system, we als have t cnsider the static aspects. This invlves, fr instance, the rganizatinal structures within which business prcesses are cnducted. This als invlves varius business bjects and infrmatin bjects, such as tickets r rders. Fr the static and dynamic aspects as a whle, we use the term business system. In business terminlgy, a business system refers t the value-added chain, which describes the value-added prcess, meaning the supply f gds and services. A business can span ne r several business systems. Each business system, in itself, generates ecnmic benefit. Thus, the business administrative meaning f business system des nt differ very much frm ur use f the term business system. We als refer t the 'results' f a business system as 'functinality'. Fr the analysis and mdeling f a business system it is imprtant t define system limits. A business system that is t be mdeled can span an entire rganizatin. In this case, we talk abut an rganizatin mdel. It is als pssible t cnsider and mdel nly a selected part f an rganizatin. In ur case study, an IT system is t be integrated int the Passenger Services peratin. Therefre, it is sufficient t bserve this peratin and t narrw the business system t Passenger Services nly. Passenger Services is a divisin within the UML Airprt, with emplyees, rganizatinal structure, an IT system, and defined tasks (Figure 3.2). The

2 surrunding divisins, such as baggage transprtatin r catering, als belng t the UML Airprt, but nt t ur business system. S, we will treat them like ther, external, business systems: Figure 3.2 System bundary during analysis f the business system We are nt interested in any f the external business systems as a whle, but nly in the interfacesbetween them and ur business system. Fr instance, the staff f passenger services need t knw that they have t transfer passengers' luggage t baggage transprtatin, s that it can be laded int the airplane. Of curse, fr this, passenger services have t knw hw baggage transprtatin accepts luggage, s that it can be made available accrdingly. It is pssible that the IT systems f passenger services and baggage transprtatin will have t be cnnected, meaning that interfaces will have t be created. On the ther hand, passenger services are cmpletely uncncerned with hw baggage transprtatin is rganized, and whether each suitcase is individually carried acrss the runway r carts are used t transprt luggage t the airplane.

3 Using UML t Mdel Business Prcesses and Business Systems Befre we mve n t the mdeling f business prcesses and business systems with UML, we shuld ask urselves whether UML is even suitable fr the mdeling f business prcesses and business systems. Fr this purpse we will take a lk at UML's definitin by OMG "The Unified Mdeling Language is a visual language fr specifying, cnstructing, and dcumenting the artifacts f systems" UML Unified Mdeling Language: Infrastructure, Versin 2.0, Final Adpted Specificatins, September This definitin indicates that UML is a language fr the mdeling and representatin f systems in general, and thus, als f business systems. In any case, UML fulfills at least ne f the requirements f business-system mdeling: it reflects varius views f a business system, in rder t capture its different aspects. The varius standardized diagram types f UML meet this requirement, because every diagram gives a different view f the mdeled business system. We reach the limits f UML when mdeling extensive business prcess prjects, fr instance, business prcess reengineering, r when mdeling entire rganizatins. Hwever, fr these kinds f prjects pwerful methds and tls are available, such as Architecture f Integrated IT Systems (ARIS). This desn't mean that we want t keep anyne frm using UML fr prjects like that, althugh we recmmend a thrugh study f the UML specificatins (OMG: Unified Mdeling Language: Superstructure, Versin 2.0, Revised Final Adpted Specificatin, Octber 2004) and the use f CASEtls. This text is tailred tward prjects with the gal f develping IT systems. Mrever, it is tailred tward prjects fr which a cncern f the business system is

4 the assurance f the smth integratin f an IT system. The fllwing characteristics mark such prjects: Thse business prcesses that are affected by the cnstructin and integratin f IT systems are cnsidered. Business-prcess mdeling is nt the fcus f these prjects. Instead, the mdel serves as the fundatin fr the cnstructin and integratin f IT systems. Business prcess integratin can determine the success r failure f such a prject; but the main task still is the cnstructin f IT systems. Because budgets are ften tight, time investment in the methdlgy and language required fr business-prcess mdeling shuld nt amunt t mre than 5-10% f the ttal prject effrt. Practical Tips fr Mdeling Business Prcesses Often ne is warned abut the cmplexity f business prcess analysis and businessprcess mdeling. Hwever, in ur experience mst business prcesses are thrughly understandable and cntrllable. Rather, the lack f clarity and transparency makes them seem mre cmplex than they really are. In many cases, existing business prcesses are dcumented prly r nt at all. This can be traced t the fact that fr many years mst functinalities were treated as 'islands' instead f parts f cmprehensive business prcesses. Because f that, the link between activities the prcess chain is missing. If this verview is missing, business prcesses seem cmplicated. There are mre hurdles t vercme if business prcesses are handled by IT systems. Mst f the time, dcumentatin f the manual wrkflw that is carried ut between individual systems is nt available. In ther cases, the functinality f IT systems is

5 unknwn because prcesses run autmatically, hidden smewhere in a black bx, and nly the input and utput are visible. Existing business prcess architectures r reference mdels that already exist can speed up and ease the mdeling prcess. Cmparing prcesses with similar r identical prcesses in ther rganizatins can be helpful in identifying discrepancies and deriving pssibilities fr imprvement.