Panosten ja tuotosten tunnistaminen on elintärkeä näkökohta liiketoimintaprosessien mallintamisessa, ja se liittyy myös kiinteästi prosessien toteuttamista tukevan tietojärjestelmän määrittelyyn.
Menetelmää ehdotetaan liiketoimintaprosessien panosten ja tuotosten tunnistamiseen ja mallintamiseen yhteistyöympäristössä.
Liiketoimintaprosessien syötteitä ja tuotoksia käsiteltiin eri työaloista: liiketoimintaprosessien hallinnasta, liiketoimintamallinnusarkkitehtuurista tai ohjelmistovaatimussuunnittelusta. Yhteistyöympäristössä liiketoimintaprosesseilla on useita eroja perinteisiin liiketoimintaprosesseihin verrattuna. Toisaalta
prosessitoimintojen toteuttaminen on kahden tai useamman kokonaisuuden (yrityksen, toimitusketjun tai verkoston) vastuulla ja sen mukana prosesseja tukevan järjestelmän ja siihen liittyvän tietojärjestelmän ongelmat, toisaalta yhteistyösuhteet muuttavat miten tietoa jaetaan yksiköiden kesken.
Liiketoimintaprosessien hallinta -alueella tarjotaan tekniikoita ja työkaluja, jotka huomioivat prosessin syötteet ja tuotokset. Jotkut näistä tekniikoista ovat (Aguilar-Saven, 2004): Vuokaavio, Data Flow Diagrams-DFD, Role Activity Diagrams-RAD, Role Interactions Diagrams -RID, Gantt Diagrams, IDEF (Integrated Definition for Role Modeling), värilliset Petri-verkot ( Värilliset Petri-net-CPN-, olio-menetelmät (Object Orientation-OO) tai työnkulkutekniikat Liiketoimintamallinnusarkkitehtuurit Ne lähestyvät liiketoimintaprosessien mallintamista käyttämällä erilaisia mallinnusnäkymiä, joista jokainen keskittyy ja toimii yhdessä integroidun liiketoimintamallin tietyssä osassa ( Toh, 1999).
Jokainen mallinnusarkkitehtuuri ehdottaa omia mallinnusnäkymiään, esimerkiksi: AIMOSA (Organization, Resources, Information and Function Views), GRAI-GIM (Tuotenäkymät),
Fyysinen, päätöksenteko-, tieto- ja toiminnallinen järjestelmä), PERA (Organisaatio- ja HR-arkkitehtuuri, tietojärjestelmä ja tuotantotiimi), GERAM (Visions of Organisation, Resources, Information and Function), ARIS (Visions of Function, Data) ,
Organisaatio ja valvonta). Prosessin syöttöjä ja tuotoksia on käsitelty pääasiassa toiminnallisesta ja informaation näkökulmasta (Melao ja Pidd, 2000). Lopuksi Software Requirements Engineering mahdollistaa elementtien tunnistamisen, jotka on esitettävä malleissa, joiden tavoitteena on tietojärjestelmän suunnittelu ja jotka siksi ottavat tarkasti huomioon liiketoimintaprosessien ja laskennallisten järjestelmien välisen suhteen.
Requirements Engineering pyrkii ymmärtämään ohjelmistojärjestelmän käyttäjien tarkat tarpeet, jotta nämä tarpeet muunnetaan täsmällisiksi ja yksiselitteisiksi ohjeiksi, joita voidaan myöhemmin käyttää järjestelmän kehittämisessä.
Eri työlajit tarjoavat erilaisia mallinnustyökaluja, ja monissa tapauksissa ne sisältävät omat metodologiansa (Cuenca ja muut, 2006). Prosessin mallinnusmenetelmät riippuvat kehitettävistä malleista. Globaalista näkökulmasta katsottuna prosessin dokumentoinnin kannalta merkityksellinen tieto sisältää prosessin määritelmän kohde, soveltamisalaan, ehdot y Määritelmät, vastuuta y viranomainen, Aktiviteetit jotka suoritetaan, Alkupala y poistuu, indikaattoreita, Resurssit, infrastruktuuria se on keskinäisiä suhteita muiden prosessien kanssa (Arrascaeta, 2005 ja Athena, 2004). Lin ja Polenske (1998) esittävät mallin tuotantoprosessin panoksista ja tuotoista. Tämä malli tarjoaa matemaattisen kuvauksen tuotantoprosessin olemassa olevista panoksista ja tuotoista tiedon saamiseksi päätöksentekoon, jossa yrityksen tuotantotoimintaa tarkastellaan sarjana tuotantoprosesseja, jotka yhdistävät useita tekijöitä tulosten tuottamiseksi. Tämä lähestymistapa ei kuitenkaan ota huomioon prosessin ja sen asiakkaiden ja toimittajien välisiä suhteita.
cheng leong ja muut (1999) erottaa kahden tyyppiset panokset ja tuotokset: tiedot ja materiaalit. Toimitusketjun yhteydessä SCOR-malli (Supply Chain Operational
Viitemallia) käytetään parantamaan toimitusketjuyritysten ja niiden tietojärjestelmien välistä viestintää (Athena, 2004). ja muut (2002) ehdottavat tuotantoprosessien panoksiin ja tuotoksiin perustuvaa lähestymistapaa, jota käytetään kehittämään erityisiä malleja, jotka tutkivat tuotantoprosessien välisiä virtoja joko globaalissa toimitusketjussa tai ketjun osassa. hernandez ja muut (2008) erottavat tuotevirrat (muunnosprosessien panokset ja tuotokset), tietovirrat (informaation muunnosprosessien syötteet ja tuotokset) ja päätösvirrat (päätösprosessit ja niiden suhteet).
Prosessin panosten ja tuotosten tunnistaminen on vaatimus liiketoimintaprosessien mallintamisessa, mutta analysoidut ehdotukset eivät täsmennä, miten tämä tulisi tehdä. Tämä oikeuttaa sellaisen metodologian tarpeen, joka auttaa tunnistamaan ja analysoimaan liiketoimintaprosessien syötteitä ja tuotoksia.
Ehdotettu menetelmä liiketoimintaprosessien panosten ja tuotosten tunnistamiseen ja mallintamiseen yhteistyöympäristössä
Metodologian avulla tunnistetaan prosessin panokset ja tuotokset suoritettavan toiminnan sujuvuuden näkökulmasta. Tässä mielessä panokset muunnetaan tai niitä käytetään toiminnan aikana tuotoksen tuottamiseksi. Ehdotettu menetelmä noudattaa ylhäältä alas -prosessia (Top-Dow), jotta prosessien, osaprosessien ja toimintojen panokset ja tuotokset tunnistetaan tässä järjestyksessä.
Kunkin prosessin, osaprosessin tai toiminnon kohdalla on noudatettava seuraavat vaiheet:
1. Tunnista prosessi, osaprosessi tai toiminto: on välttämätöntä tunnistaa yksiselitteisesti prosessi, osaprosessi tai toiminta, jolla menetelmän seuraavat vaiheet suoritetaan.
2. Tuotosten (tulosten) tunnistaminen: Asiakkaalle lisäarvoa tuottavat prosessin tuotokset on erotettava muista prosessituloksista, jotka syntyvät panosten muuntamisesta arvotuoksiksi:
a) Millaisia arvotuoksia (tuloksia) asiakkaalle prosessi tarjoaa?
b) Mitä muita tuotoksia prosessi tuottaa tulojen muuntamisen seurauksena?
Jokaiselle ulostulolle:
2.1. Onko se tiedon tai materiaalin tuotos?: Prosessit voivat tuottaa tietoa tai materiaalia. Metodologiassa ymmärretään, että seuraavaa voi esiintyä:
— Tiedot tai tiedot: toiminnon tai prosessin tuottamat tiedot.
— Esineiden (tai materiaalien) tuotos: toiminnon tai prosessin tuottamat esineet.
2.2. Kuka on asiakas tai vastaanottaja?: Prosessin tuotto on perusteltu tuottamalla arvoa tietylle asiakkaalle (2a).
Muiden muunnosprosessin (2b) tulosten tapauksessa voidaan puhua lähdön vastaanottajasta.
23. Tuotoksen määrittely: Tuotos on täsmennettävä, jotta se voidaan tunnistaa selkeästi sen oman luonteen ja vastaanottajan näkökulmasta. Jälkimmäinen määrittää, onko tuotoksella asiakkaan odottama arvo vai ei:
2.3.1. Mikä on tuotoksen spesifikaatio asiakkaan tai vastaanottajan näkökulmasta?
2.3.2. Mikä on omaa luonnettaan vastaava spesifikaatio sen mukaan, onko se tietoa vai objektia?
3. Tulojen tunnistaminen: Prosessitulot voivat olla erityyppisiä. IDEF0 sisältää prosessimallissaan seuraavat peruselementit, jotka voidaan ymmärtää prosessin syötteinä: auktoriteetti (prosessin kuvaus, määrittely tai perustelu), ohjaus (prosessin aktivoivat ehdot), syötteet (prosessiin saapuva objekti), ja mekanismit (prosessin käyttämät resurssit).
Ehdotetussa menetelmässä tunnistetaan vain ne syötteet, jotka tulevat prosessiin muunnettavaksi tai joita käytetään tuotoksen tuottamiseen.
Jokaiselle merkinnälle:
3.1. Onko se tieto vai materiaalimerkintä?: Metodologiassa ymmärretään, että 2 tyyppisiä merkintöjä voi esiintyä:
— Tietojen tai tietojen syöttö: tiedot tai tiedot, jotka toiminto tai prosessi muuntaa tai käyttää tuotoksen tuottamiseksi.
— Objekti- (tai materiaali-) panos: Objektit, jotka toiminto tai prosessi muuntavat tai käyttävät tuotoksen tuottamiseksi.
3.2. Kuka on toimittaja tai alkuperä?: Tarvittava tieto tuotantopanosten tunnistamiseksi on panoksen toimittava toimittaja tai alkuperä, jos ne on jo perustettu tai jos halutaan luoda jonkinlainen suhde.
3.3. Syötteen määrittely: syöte on tarpeen määritellä selkeästi sen tunnistamiseksi oman luonteensa ja sitä muuntavan tai käyttävän toiminnan näkökulmasta, koska jälkimmäinen edellyttää, että syöte täyttää toiminnalle vaadittavat vaatimukset. suoritettava. tehdä tulos:
3.3.1. Mikä on syöttömäärittely toiminnan näkökulmasta?
3.3.2. Mikä on omaa luonnettaan vastaava spesifikaatio sen mukaan, onko se tietoa vai objektia?