Identifikasjon av input og output er et aspekt av vital betydning i modelleringen av forretningsprosesser, og er også nært knyttet til definisjonen av informasjonssystemet som støtter gjennomføringen av prosesser.
En metodikk er foreslått for identifisering og modellering av input og output fra forretningsprosesser i et samarbeidsmiljø.
Inndata og utdata fra forretningsprosesser ble adressert fra forskjellige arbeidsdisipliner: Business Process Management, Business Modeling Architectures eller Software Requirements Engineering. I et samarbeidsmiljø har forretningsprosesser flere forskjeller fra tradisjonelle forretningsprosesser. På den ene siden
utførelsen av prosessaktiviteter er ansvaret til to eller flere enheter (selskaper, forsyningskjeder eller nettverk), og med det problemene til systemet som støtter prosessene og det tilhørende informasjonssystemet, på den annen side transformerer samarbeidsrelasjoner hvordan informasjon deles mellom enheter.
I området Business Process Management tilbys teknikker og verktøy som vurderer prosessinnganger og -utganger. Noen av disse teknikkene er (Aguilar-Saven, 2004): flytskjema, dataflytdiagrammer-DFD, rolleaktivitetsdiagrammer-RAD, rolleinteraksjonsdiagrammer -RID), Gantt-diagrammer, IDEF (integrert definisjon for rollemodellering), fargede petrinett ( Farget Petri-net-CPN), Objektorienterte metoder (Objektorientering-OO) eller arbeidsflytteknikker Forretningsmodelleringsarkitekturer De nærmer seg forretningsprosessmodellering ved å bruke forskjellige visninger av modellering, som hver fokuserer og arbeider på en spesifikk del av den integrerte forretningsmodellen ( Toh, 1999).
Hver modelleringsarkitektur foreslår sine egne modelleringsvisninger, for eksempel: AIMOSA (Organization, Resources, Information and Function Views), GRAI-GIM (Product Views),
Fysisk, beslutningstaking, informasjons- og funksjonssystem), PERA (Arkitektur av organisasjonen og HR, informasjonssystemet og produksjonsteamet), GERAM (Visions of Organization, Resources, Information and Function), ARIS (Visions of Function, Data ,
Organisasjon og kontroll). Prosess input og output har blitt adressert hovedsakelig fra funksjonelle og informasjonsmessige perspektiver (Melao og Pidd, 2000). Til slutt tillater Software Requirements Engineering å identifisere elementene som må representeres i modeller hvis mål er utformingen av et informasjonssystem og som derfor eksplisitt vurderer forholdet mellom forretningsprosesser og beregningssystemer.
Requirements Engineering prøver å forstå de nøyaktige behovene til brukerne av programvaresystemet, for å oversette disse behovene til presise og entydige instruksjoner som senere kan brukes i utviklingen av systemet.
De forskjellige arbeidsdisiplinene gir forskjellige modelleringsverktøy og inkluderer i mange tilfeller sine egne metoder (Cuenca og andre, 2006). Prosessmodelleringsmetodikk avhenger av modellen som skal utvikles. Fra et globalt perspektiv inneholder informasjonen som er relevant for å dokumentere en prosess definisjonen av mål, omfang, vilkår Y Definisjoner, ansvar Y autoritet, Aktiviteter som utføres, Forrett Y utganger, indikatorer, Ressurser, infrastrukturen Det er innbyrdes forhold med andre prosesser (Arrascaeta, 2005, og Athena, 2004). Lin og Polenske (1998) presenterer en modell av input og output fra produksjonsprosessen. Denne modellen gir en matematisk beskrivelse av eksisterende input og output i produksjonsprosessen for å gi informasjon for beslutningstaking, der den produktive aktiviteten til en bedrift betraktes som et sett med produktive prosesser som kombinerer flere faktorer for å produsere resultater. Denne tilnærmingen tar imidlertid ikke hensyn til relasjonene mellom prosessen og dens kunder og leverandører.
cheng leong og andre (1999) skiller mellom to typer input og output: informasjon og materiale. I sammenheng med forsyningskjeden, SCOR-modellen (Supply Chain Operational
Reference Model) brukes til å forbedre kommunikasjonen mellom leverandørkjedebedrifter og deres informasjonssystemer (Athena, 2004). og andre (2002) foreslår en tilnærming basert på input og output fra produktive prosesser, brukt til å utvikle spesifikke modeller som undersøker flytene mellom produktive prosesser, enten fra en global forsyningskjede eller en del av kjeden. hernandez og andre (2008) skiller mellom produktflyter (innganger og utganger for transformasjonsprosesser), informasjonsflyter (innganger og utganger for informasjonstransformasjonsprosesser) og beslutningsflyter (beslutningsprosesser og deres relasjoner).
Identifisering av input og output fra en prosess er et krav som skal oppfylles i forretningsprosessmodellering, men de analyserte forslagene beskriver ikke hvordan dette skal gjøres. Dette rettferdiggjør behovet for en metodikk som hjelper til med å identifisere og analysere input og output fra forretningsprosesser.
Foreslått metodikk for å identifisere og modellere input og output fra forretningsprosesser i et samarbeidsmiljø
Gjennom metodikken vil input og output av prosessen identifiseres ut fra synspunktet om flyten av aktiviteten som utføres. I denne forstand blir input transformert eller brukt under aktiviteten for å produsere en output. Den foreslåtte metodikken følger en top-down prosesstilnærming (Top-Dow) slik at input og output fra prosesser, delprosesser og aktiviteter blir identifisert, i den rekkefølgen.
Trinnene som skal følges for hver prosess, delprosess eller aktivitet er:
1. Identifiser prosessen, delprosessen eller aktiviteten: det er nødvendig å utvetydig identifisere prosessen, delprosessen eller aktiviteten som de følgende trinnene i metodikken skal utføres på.
2. Identifikasjon av utganger (resultater): prosessutgangene som tilfører kunden verdi, må skilles fra de andre prosessutgangene som er et resultat av aktiviteten med å transformere input til verdiutganger:
a) Hvilke verdiutganger (resultater) for kunden gir prosessen?
b) Hvilke andre utganger genererer prosessen som et resultat av å transformere inngangene?
For hver utgang:
2.1. Er det et utdata av informasjon eller materiale?: Prosesser kan gi utdata av informasjon eller materielle objekter. I metodikken er det forstått at følgende kan vises:
— Data eller informasjonsutgang: data eller informasjon produsert av aktiviteten eller prosessen.
— Utgang av gjenstander (eller materialer): gjenstander som produseres av aktiviteten eller prosessen.
2.2. Hvem er kunden eller mottakeren?: Prosessresultatet begrunnes ved å gi verdi til en spesifikk kunde (2a).
Ved andre utganger som en konsekvens av transformasjonsprosessen (2b) kan man snakke om mottakeren av utgangen.
23. Spesifikasjon av utdata: det er nødvendig å spesifisere utdata for å tydelig identifisere det i henhold til sin egen natur og fra mottakerens perspektiv. Sistnevnte avgjør om produksjonen har verdien som forventes av kunden:
2.3.1. Hva er spesifikasjonen av output fra kundens eller mottakerens synspunkt?
2.3.2. Hva er spesifikasjonen som svarer til sin egen natur avhengig av om det er informasjon eller objekt?
3. Identifikasjon av innganger: Prosessinngangene kan være av ulike typer. IDEF0 inkluderer i sin prosessmodell følgende grunnleggende elementer som kan forstås som input til prosessen: autoritet (beskrivelse, spesifikasjon eller begrunnelse av en prosess), kontroll (forhold som aktiverer prosessen), input (objekt som går inn i prosessen ), og mekanismer (ressurser som brukes av prosessen).
I den foreslåtte metodikken identifiseres bare inngangene som går inn i prosessen som skal transformeres eller brukes til å produsere en utgang.
For hver oppføring:
3.1. Er det en informasjons- eller materialoppføring?: I metodikken er det forstått at 2 typer oppføringer kan forekomme:
– Data eller informasjon input: Data eller informasjon som transformeres eller brukes av aktiviteten eller prosessen for å produsere et output.
— Objekt (eller materiell) input: Objekter som transformeres eller brukes av aktiviteten eller prosessen for å produsere et utdata.
3.2. Hvem er leverandøren eller opprinnelsen?: en nødvendig informasjon for å identifisere input er leverandøren eller opprinnelsen som leverer input, hvis de allerede er etablert eller hvis du ønsker å etablere en eller annen type relasjon.
3.3. Spesifikasjon av input: det er nødvendig å spesifisere input for å tydelig identifisere det i henhold til sin egen natur og fra perspektivet til aktiviteten som transformerer eller bruker det, siden sistnevnte betinger det faktum at inputen oppfyller de nødvendige kravene til aktiviteten skal utføres. Lag en utgang:
3.3.1. Hva er inputspesifikasjonen fra et aktivitetssynspunkt?
3.3.2. Hva er spesifikasjonen som svarer til sin egen natur avhengig av om det er informasjon eller objekt?