Ievades un izejas identifikācija ir ļoti svarīgs biznesa procesu modelēšanas aspekts, kā arī ir cieši saistīts ar informācijas sistēmas definīciju, kas atbalsta procesu izpildi.
Tiek piedāvāta Metodika biznesa procesu ievades un izvades identificēšanai un modelēšanai sadarbības vidē.
Biznesa procesu ievades un izvades tika apskatītas no dažādām darba disciplīnām: biznesa procesu vadība, biznesa modelēšanas arhitektūra vai programmatūras prasību inženierija. Sadarbības vidē biznesa procesiem ir vairākas atšķirības no tradicionālajiem biznesa procesiem. No vienas puses
par procesa aktivitāšu izpildi ir atbildīgas divas vai vairākas vienības (uzņēmumi, piegādes ķēdes vai tīkli), un līdz ar to procesus atbalstošās sistēmas un ar to saistītās informācijas sistēmas problēmas, no otras puses, sadarbības attiecības pārveido to, kā informācija tiek koplietota starp entītijām.
Biznesa procesu pārvaldības jomā tiek nodrošinātas metodes un rīki, kas ņem vērā procesa ievadi un izvadi. Dažas no šīm metodēm ir (Aguilar-Saven, 2004): blokshēma, datu plūsmas diagrammas-DFD, lomu aktivitāšu diagrammas-RAD, lomu mijiedarbības diagrammas -RID), Ganta diagrammas, IDEF (integrēta lomu modelēšanas definīcija), krāsainie Petri tīkli ( Couloured Petri-net-CPN), objektorientētās metodes (Object Orientation-OO) vai darbplūsmas metodes Biznesa modelēšanas arhitektūras Tie pieiet biznesa procesu modelēšanai, izmantojot dažādus modelēšanas skatus, no kuriem katrs koncentrējas un darbojas uz vienu konkrētu integrētā biznesa modeļa daļu ( Toh, 1999).
Katra modelēšanas arhitektūra piedāvā savus modelēšanas skatus, piemēram: AIMOSA (organizācijas, resursu, informācijas un funkciju skati), GRAI-GIM (produktu skati),
Fiziskā, lēmumu pieņemšanas, informācijas un funkcionālā sistēma), PERA (organizācijas un personāla arhitektūra, informācijas sistēma un ražošanas komanda), GERAM (organizācijas, resursu, informācijas un funkciju vīzijas), ARIS (funkciju, datu vīzijas). ,
Organizācija un kontrole). Procesa ievades un izvades galvenokārt ir aplūkotas no funkcionālā un informatīvā viedokļa (Melao un Pidd, 2000). Visbeidzot, programmatūras prasību inženierija ļauj identificēt elementus, kas jāatspoguļo modeļos, kuru mērķis ir informācijas sistēmas projektēšana un kuri tāpēc skaidri ņem vērā attiecības starp biznesa procesiem un skaitļošanas sistēmām.
Prasību inženierija cenšas izprast precīzas programmatūras sistēmas lietotāju vajadzības, lai šīs vajadzības pārvērstu precīzās un nepārprotamās instrukcijās, kuras vēlāk varētu izmantot sistēmas izstrādē.
Dažādās darba disciplīnas nodrošina dažādus modelēšanas rīkus un daudzos gadījumos ietver savas metodoloģijas (Cuenca un citi, 2006). Procesu modelēšanas metodoloģijas ir atkarīgas no izstrādājamā modeļa. No globālā viedokļa informācija, kas attiecas uz procesa dokumentēšanu, ietver definīciju mērķis, darbības jomu, noteikumiem y Definīcijas, atbildību y iestāde, Darbības kas tiek veiktas, Uzkoda y izejas, rādītājiem, Resursi, infrastruktūra Tas ir savstarpējās attiecības ar citiem procesiem (Arrascaeta, 2005 un Athena, 2004). Lin un Polenske (1998) piedāvā ražošanas procesa ievades un izvades modeli. Šis modelis sniedz matemātisku ražošanas procesā esošo ieguldījumu un izlaides aprakstu, lai sniegtu informāciju lēmumu pieņemšanai, kur uzņēmuma produktīvā darbība tiek uzskatīta par produktīvu procesu kopumu, kas apvieno vairākus faktorus, lai radītu rezultātus. Tomēr šī pieeja neņem vērā attiecības starp procesu un tā klientiem un piegādātājiem.
čengs leongs un citi (1999) izšķir divus ievades un izvades veidus: informāciju un materiālu. Piegādes ķēdes kontekstā SCOR modelis (Supply Chain Operational
Atsauces modelis) tiek izmantots, lai uzlabotu komunikāciju starp piegādes ķēdes uzņēmumiem un to informācijas sistēmām (Athena, 2004). un citi (2002) piedāvā pieeju, kuras pamatā ir ražošanas procesu ievade un izlaide, ko izmanto, lai izstrādātu īpašus modeļus, kas pēta plūsmas starp ražošanas procesiem vai nu globālajā piegādes ķēdē, vai ķēdes daļā. hernandezs un citi (2008) izšķir produktu plūsmas (transformācijas procesu ievades un izvades), informācijas plūsmas (informācijas transformācijas procesu ievades un izvades) un lēmumu plūsmas (lēmumu pieņemšanas procesi un to attiecības).
Procesa ievades un izvades noteikšana ir prasība, kas jāievēro biznesa procesu modelēšanā, taču analizētajos priekšlikumos nav norādīts, kā tas būtu jādara. Tas attaisno vajadzību pēc metodoloģijas, kas palīdz identificēt un analizēt biznesa procesu ievadi un iznākumus.
Piedāvātā metodoloģija biznesa procesu ievades un izvades noteikšanai un modelēšanai sadarbības vidē
Izmantojot metodoloģiju, procesa ievades un iznākumi tiks identificēti no veicamās darbības plūsmas viedokļa. Šajā ziņā izejvielas tiek pārveidotas vai izmantotas darbības laikā, lai iegūtu rezultātu. Ierosinātajā metodoloģijā tiek izmantota lejupejoša procesa pieeja (no augšas uz leju), lai procesu, apakšprocesu un darbību ievades un iznākumi tiktu identificēti šādā secībā.
Katram procesam, apakšprocesam vai darbībai jāveic šādas darbības:
1. Identificējiet procesu, apakšprocesu vai darbību: ir nepieciešams nepārprotami identificēt procesu, apakšprocesu vai darbību, kurā tiks veikti šādi metodoloģijas soļi.
2. Iznākumu (rezultātu) identificēšana: procesa iznākumi, kas klientam rada pievienoto vērtību, ir jānošķir no citiem procesa iznākumiem, kas rodas, pārveidojot ieguldījumus vērtību izlaidēs:
a) Kādas vērtības iznākumus (rezultātus) klientam nodrošina process?
b) Kādus citus rezultātus process ģenerē ievades pārveidošanas rezultātā?
Katrai izvadei:
2.1. Vai tā ir informācijas vai materiāla izvade?: procesi var nodrošināt informācijas vai materiālu objektu izvadi. Metodoloģijā tiek saprasts, ka var parādīties:
— Datu vai informācijas izvade: dati vai informācija, ko rada darbība vai process.
— Objektu (vai materiālu) izlaide: objekti, ko rada darbība vai process.
2.2. Kas ir klients vai saņēmējs?: procesa rezultāts ir pamatots, nodrošinot vērtību konkrētam klientam (2a).
Citu izvadu gadījumā transformācijas procesa rezultātā (2b) var runāt par izvades saņēmēju.
23. Rezultāta specifikācija: nepieciešams precizēt iznākumu, lai to skaidri identificētu pēc tā būtības un no saņēmēja viedokļa. Pēdējais nosaka, vai produkcijai ir klienta gaidītā vērtība:
2.3.1. Kāda ir produkcijas specifikācija no klienta vai saņēmēja viedokļa?
2.3.2. Kāda specifikācija atbilst tās būtībai atkarībā no tā, vai tā ir informācija vai objekts?
3. Ievadu identifikācija: procesa ievades var būt dažāda veida. IDEF0 savā procesa modelī ietver šādus pamatelementus, ko var saprast kā ievadi procesā: autoritāte (procesa apraksts, specifikācija vai pamatojums), kontrole (nosacījumi, kas aktivizē procesu), ievades (objekts, kas ienāk procesā), un mehānismi (procesā izmantotie resursi).
Piedāvātajā metodoloģijā tiek identificētas tikai tās ievades, kas nonāk procesā, lai to pārveidotu vai izmantotu produkcijas ražošanai.
Katram ierakstam:
3.1. Vai tas ir informatīvs vai materiāls ieraksts?: Metodikā ir saprasts, ka var parādīties 2 veidu ieraksti:
— Datu vai informācijas ievade: dati vai informācija, ko pārveido vai izmanto darbība vai process, lai iegūtu rezultātu.
— Objekta (vai materiāla) ievade: objekti, kas tiek pārveidoti vai izmantoti darbībā vai procesā, lai iegūtu rezultātu.
3.2. Kas ir piegādātājs vai izcelsmes vieta?: nepieciešama informācija, lai identificētu izejmateriālus, ir piegādātājs vai izcelsmes vieta, kas piegādā izejmateriālu, ja tie jau ir izveidoti vai ja vēlaties izveidot kāda veida attiecības.
3.3. Ievades specifikācija: ir nepieciešams norādīt ievadi, lai to skaidri identificētu pēc tā būtības un no darbības viedokļa, kas to pārveido vai izmanto, jo tas nosaka to, ka ievade atbilst darbības nepieciešamajām prasībām. veiciet izvadi:
3.3.1. Kāda ir ievades specifikācija no darbības viedokļa?
3.3.2. Kāda specifikācija atbilst tās būtībai atkarībā no tā, vai tā ir informācija vai objekts?