Sisendite ja väljundite tuvastamine on äriprotsesside modelleerimisel elulise tähtsusega aspekt, mis on tihedalt seotud ka protsesside läbiviimist toetava infosüsteemi määratlemisega.
Pakutakse välja metoodika äriprotsesside sisendite ja väljundite tuvastamiseks ja modelleerimiseks koostöökeskkonnas.
Äriprotsesside sisendeid ja väljundeid käsitleti erinevatest töödistsipliinidest: äriprotsesside juhtimine, ärimudelite arhitektuurid või tarkvaranõuete inseneriteadus. Koostöökeskkonnas on äriprotsessidel mitmeid erinevusi traditsioonilistest äriprotsessidest. Ühest küljest
protsessitoimingute teostamise eest vastutavad kaks või enam üksust (ettevõtted, tarneahelad või võrgustikud) ning sellega kaasnevad protsesse toetava süsteemi ja sellega seotud infosüsteemi probleemid, teisalt muudavad koostöösuhted seda, kuidas teavet jagatakse üksuste vahel.
Äriprotsesside haldamise valdkonnas pakutakse tehnikaid ja tööriistu, mis arvestavad protsessi sisendite ja väljunditega. Mõned neist tehnikatest on (Aguilar-Saven, 2004): vooskeem, andmevoo diagrammid-DFD, rollitegevuse diagrammid-RAD, rollide vastasmõju diagrammid -RID), Gantti diagrammid, IDEF (rollimudeli integreeritud definitsioon), värvilised Petri võrgud ( Couloured Petri-net-CPN), objektorienteeritud meetodid (Object Orientation-OO) või töövootehnikad Ärimudelite arhitektuurid Nad lähenevad äriprotsesside modelleerimisele, kasutades erinevaid modelleerimise vaateid, millest igaüks keskendub ja töötab integreeritud ärimudeli ühele konkreetsele osale ( Toh, 1999).
Iga modelleerimisarhitektuur pakub välja oma modelleerimisvaated, näiteks: AIMOSA (organisatsiooni, ressursside, teabe ja funktsioonide vaated), GRAI-GIM (tootevaated),
Füüsiline, otsuste tegemise, teabe- ja funktsionaalne süsteem), PERA (organisatsiooni ja personali arhitektuur, infosüsteem ja tootmismeeskond), GERAM (visions of Organisation, Resources, Information ja Function), ARIS (Visions of Function, Data) ,
Organisatsioon ja kontroll). Protsessi sisendeid ja väljundeid on käsitletud peamiselt funktsionaalsest ja informatsioonilisest vaatenurgast (Melao ja Pidd, 2000). Lõpuks võimaldab tarkvaranõuete projekteerimine tuvastada elemendid, mida tuleb esindada mudelites, mille eesmärk on infosüsteemi kujundamine ja mis seetõttu võtavad selgesõnaliselt arvesse äriprotsesside ja arvutussüsteemide vahelisi seoseid.
Requirements Engineering püüab mõista tarkvarasüsteemi kasutajate täpseid vajadusi, et need vajadused tõlkida täpseteks ja üheselt mõistetavateks juhisteks, mida saab hiljem süsteemi arendamisel kasutada.
Erinevad töödistsipliinid pakuvad erinevaid modelleerimistööriistu ja paljudel juhtudel hõlmavad oma metoodikat (Cuenca ja teised, 2006). Protsessi modelleerimise metoodikad sõltuvad arendatavast mudelist. Globaalsest vaatenurgast sisaldab protsessi dokumenteerimiseks asjakohane teave protsessi määratlust sihtmärk, ulatus, tingimustele Y Definitsioonid, vastutus Y asutus, Tegevused mida teostatakse, Eelroog Y väljub, näitajad, Vahendid, infrastruktuuri see on omavahelised suhted teiste protsessidega (Arrascaeta, 2005 ja Athena, 2004). Lin ja Polenske (1998) esitavad tootmisprotsessi sisendite ja väljundite mudeli. See mudel kirjeldab tootmisprotsessis olemasolevaid sisendeid ja väljundeid matemaatiliselt, et anda teavet otsuste tegemiseks, kus ettevõtte tootmistegevust käsitletakse kui tootmisprotsesside kogumit, mis ühendab tulemuste saamiseks mitu tegurit. See lähenemisviis ei võta aga arvesse protsessi ning selle klientide ja tarnijate vahelisi suhteid.
cheng leong ja teised (1999) eristab kahte tüüpi sisendeid ja väljundeid: informatsioon ja materjal. Tarneahela kontekstis kasutatakse mudelit SCOR (Supply Chain Operational
Võrdlusmudel) kasutatakse tarneahela ettevõtete ja nende infosüsteemide vahelise suhtluse parandamiseks (Athena, 2004). ja teised (2002) pakuvad välja tootmisprotsesside sisenditel ja väljunditel põhineva lähenemisviisi, mida kasutatakse spetsiifiliste mudelite väljatöötamiseks, mis uurivad tootmisprotsesside vahelisi voogusid kas globaalses tarneahelas või ahela osas. hernandez ja teised (2008) eristavad tootevooge (teisendusprotsesside sisendid ja väljundid), infovooge (teabe teisendusprotsesside sisendid ja väljundid) ja otsustusvooge (otsustusprotsessid ja nende seosed).
Protsessi sisendite ja väljundite tuvastamine on äriprotsesside modelleerimisel nõue, kuid analüüsitud ettepanekutes ei ole üksikasjalikult kirjeldatud, kuidas seda teha. See õigustab vajadust metoodika järele, mis aitab tuvastada ja analüüsida äriprotsesside sisendeid ja väljundeid.
Pakutud metoodika äriprotsesside sisendite ja väljundite tuvastamiseks ja modelleerimiseks koostöökeskkonnas
Metoodika kaudu selgitatakse välja protsessi sisendid ja väljundid läbiviidava tegevuse kulgemise seisukohast. Selles mõttes sisendeid teisendatakse või kasutatakse tegevuse käigus väljundi saamiseks. Kavandatav metoodika järgib ülalt-alla protsessi lähenemisviisi (Top-Dow), nii et protsesside, alamprotsesside ja tegevuste sisendid ja väljundid tuvastatakse selles järjekorras.
Iga protsessi, alamprotsessi või tegevuse puhul tuleb järgida järgmisi samme:
1. Identifitseerige protsess, alamprotsess või tegevus: on vaja ühemõtteliselt identifitseerida protsess, alamprotsess või tegevus, mille puhul viiakse läbi metoodika järgmised etapid.
2. Väljundite (tulemuste) tuvastamine: kliendile väärtust lisavad protsessiväljundid tuleb eristada teistest protsessiväljunditest, mis tulenevad sisendite väärtusväljunditeks muutmise tegevusest:
a) Milliseid väärtusväljundeid (tulemusi) protsess kliendi jaoks pakub?
b) Milliseid muid väljundeid protsess sisendite teisendamise tulemusena genereerib?
Iga väljundi jaoks:
2.1. Kas see on teabe või materjali väljund?: protsessid võivad anda teabe või materiaalsete objektide väljundeid. Metoodikas on arusaadav, et võib ilmneda järgmine:
— Andmete või teabe väljund: tegevuse või protsessi käigus saadud andmed või teave.
— Objektide (või materjalide) väljund: objektid, mis on toodetud tegevuse või protsessi käigus.
2.2. Kes on klient või saaja?: Protsessi väljund on õigustatud konkreetsele kliendile väärtuse pakkumisega (2a).
Teiste väljundite puhul võib teisendusprotsessi (2b) tulemusena rääkida väljundi adressaadist.
23. Väljundi täpsustamine: väljundit on vaja täpsustada, et seda selgelt identifitseerida vastavalt selle olemusele ja saaja vaatenurgast. Viimane määrab, kas väljundil on kliendi oodatud väärtus või mitte:
2.3.1. Milline on väljundi spetsifikatsioon kliendi või saaja vaatevinklist?
2.3.2. Milline spetsifikatsioon vastab oma olemusele olenevalt sellest, kas tegemist on teabe või objektiga?
3. Sisendite identifitseerimine: protsessi sisendid võivad olla erinevat tüüpi. IDEF0 sisaldab oma protsessimudelis järgmisi põhielemente, mida võib mõista protsessi sisenditena: autoriteet (protsessi kirjeldus, spetsifikatsioon või põhjendus), kontroll (protsessi aktiveerivad tingimused), sisendid (protsessi sisenev objekt), ja mehhanismid (protsessis kasutatavad ressursid).
Pakutud metoodikas tuvastatakse ainult need sisendid, mis sisenevad teisendatavasse protsessi või mida kasutatakse väljundi tootmiseks.
Iga sissekande kohta:
3.1. Kas tegemist on teabe- või materjalikirjega?: Metoodikas on arusaadav, et võib esineda kahte tüüpi kirjeid:
— Andmete või teabe sisend: andmed või teave, mida tegevus või protsess väljundi loomiseks teisendab või kasutab.
— Objekti (või materjali) sisend: objektid, mida tegevus või protsess väljundi loomiseks teisendab või kasutab.
3.2. Kes on tarnija või päritolu?: sisendite tuvastamiseks vajalik teave on tarnija või päritolu, kes tarnib sisendit, kui need on juba loodud või kui soovite luua mingit tüüpi suhet.
3.3. Sisendi täpsustamine: sisendit on vaja täpsustada, et see selgelt identifitseerida vastavalt selle olemusele ja seda muundava või kasutava tegevuse vaatenurgast, kuna viimane eeldab asjaolu, et sisend vastab tegevuseks vajalikele nõuetele. teha väljund:
3.3.1. Mis on sisendi spetsifikatsioon tegevuse seisukohast?
3.3.2. Milline spetsifikatsioon vastab oma olemusele olenevalt sellest, kas tegemist on teabe või objektiga?