Leta 2000 je Mednarodna organizacija za standardizacijo (ISO) sprejela novo različico serije standardov 9000, ki vsebuje seznam zahtev za sistem kakovosti organizacije (QS).
Ena od temeljnih razlik nove različice standardov je uporaba procesnega pristopa k upravljanju, pa tudi k oblikovanju in delovanju SC.
Glavno idejo procesnega pristopa v novi različici standardov je mogoče povzeti na naslednji način:
Dejavnost organizacije mora biti predstavljena kot mreža medsebojno delujočih procesov;
Upravljanje dejavnosti organizacije mora temeljiti na upravljanju mreže procesov.
Ta članek obravnava pristop k opisovanju in razvrščanju procesov v organizaciji, ki temelji na uporabi metodologije funkcionalnega modeliranja IDEF0.
ISO 9000:2000 uporablja naslednjo definicijo procesa:
»Nabor medsebojno povezanih in medsebojno delujočih operacij (akcij), ki pretvarjajo vhode v izhode.
Opomba 1. Vhodi procesov so običajno izhodi drugih procesov.
Opomba 2: Procesi v organizaciji se načrtujejo in izvajajo pod nadzorovanimi pogoji za dodano vrednost.
Večina strokovnjakov za CS se strinja, da je najprimernejši način za opis procesov grafično predstavitev. Različni dokumenti o interpretaciji procesnega pristopa, začrtani v novi različici standarda, ponujajo različne možnosti za grafični prikaz procesov.
Opisi procesov naj ne odražajo le posameznih procesov, temveč tudi odnose in interakcije med procesi.
Procesi skupaj z odnosi in interakcijami predstavljajo mrežo procesov organizacije.
Opis mreže procesov, ki sestavljajo dejavnosti organizacije, je zapletena organizacijska in tehnična naloga, katere rešitev zahteva posebna sredstva opisa in analize.
Ta okoliščina se je prvič uresničila sredi 70-ih let med izvajanjem kompleksnih projektov, ki so jih naročile letalske sile ZDA. Hkrati je bil predlagan in implementiran program Integrirana računalniško podprta proizvodnja (ICAM), v okviru katerega je bila uporabljena predvsem metodologija strukturne analize sistemov. Kasneje je bila na podlagi tega pristopa razvita metodologija funkcionalnega modeliranja IDEF0, ki je bila leta 1993 sprejeta kot zvezni standard v ZDA, leta 2000 pa kot standard v Ruski federaciji.
V metodologiji funkcionalnega modeliranja IDEF0 se za grafični prikaz procesa uporablja naslednji zapis (slika 2).
V skladu z metodologijo IDEF0 je proces predstavljen kot funkcionalni blok, ki pretvarja vhode v izhode, pod pogojem, da so potrebni viri (mehanizmi) na voljo pod nadzorovanimi pogoji.
Odnosi in interakcije procesov v IDEF0 so predstavljeni z loki, ki povezujejo izhode nekaterih funkcionalnih blokov z vhodi drugih.
Model procesnega omrežja v sistemu kakovosti mora odgovoriti na naslednja vprašanja:
Kateri procesi v dejavnosti organizacije so povezani s sistemom kakovosti?
Kakšna je struktura teh procesov, vključno z izhodi in porabniki procesa, vložki in dobavitelji itd.?
Kako procesi medsebojno delujejo?
Kako so v procesih izpolnjene zahteve, opredeljene v seriji ISO 9000, različica 2000?
Da bi funkcionalni model procesnega omrežja odgovoril na ta in druga vprašanja v okviru SC, ga je treba zgraditi v skladu z dodatnimi zahtevami (poleg tistih, ki so oblikovane v metodologiji IDEF0).
Naslednji je daleč od popolnega seznama zahtev, ki jih mora izpolnjevati model funkcionalnega procesa:
Funkcionalni model je zgrajen z vidika vodenja sistema kakovosti organizacije. S tem pristopom model vključuje vse procese in elemente, ki vplivajo na kakovost končnega izdelka in procesov.
Funkcionalni model mora vsebovati procese, ki so opredeljeni kot obvezni v okviru zahtev IS serije ISO 9000, različica 2000. Seznam teh procesov je podan v MS ISO 9001:2000.
Funkcionalni model mora vsebovati elemente (objekte), ki so urejeni v seriji MS ISO 9000, različica 2000. Seznam takšnih elementov je podan.
Funkcionalni model naj zajema vse faze življenjskega cikla izdelka, povezane z obsegom organizacije.
Poslovni proces
Da bi funkcionalni model zadostil naštetim zahtevam, mora biti zgrajen kot model poslovnega procesa.
Poslovni proces je skupek procesov (operacij, dejanj) in interakcij med njimi, katerih rezultat (izhod) so izdelki in/ali storitve, dobavljeni potrošnikom, vložki pa materialni, informacijski in delovni viri, ki jih dobavljajo zunanji dobavitelji.
Tako bo model funkcionalnega poslovnega procesa zajemal procese življenjskega cikla ter s tem povezane procese podpore in upravljanja, ki so del dejavnosti organizacije. To je v celoti skladno z zahtevami MS ISO 9000, različica 2000.
Na primer, šivalni studio izdeluje (šiva) ženske plašče in sklepa pogodbe s potrošniki. Potrošniki izdelkov so trgovine z ženskimi oblačili ter trgovska in posredniška podjetja. Atelje odkupuje surovine pri tovarnah za cesarstvo, pa tudi pri trgovskih in posredniških družbah. Poslovni proces v krojačnici je postopek "Izdelava ženskih plaščev".
Zahtevani procesi in elementi
V MS ISO 9001:2000 obvezni procesi vključujejo:
Izvajanje odgovornosti najvišjega vodstva v sistemu kakovosti;
Upravljanje virov (pomožni proizvodni procesi);
Upravljanje glavnih proizvodnih procesov (procesi življenjskega cikla izdelka);
Procesi merjenja, nadzora in izboljšanja SC.
Obvezni elementi vključujejo:
Dokumenti, ki vsebujejo politiko, cilje organizacije na področju vodenja kakovosti;
Dokumenti, ki vsebujejo odgovornost zaposlenih v organizaciji (opisi delovnih mest);
Kakovostne evidence itd.
V skladu s tem bi moral funkcionalni model vsebovati vse obvezne procese in elemente v skladu z zahtevami IS serije 9000, različica 2000.
V našem primeru bo imel poslovni proces v šivalnem studiu naslednjo strukturo (slika 4).
Na diagramu (slika 4) je proces predstavljen kot 4 medsebojno delujoči procesi. Vsak od 4 procesov je obvezen v smislu izpolnjevanja zahtev MS ISO 9001:2000.
Puščice, ki povezujejo funkcionalne bloke, predstavljajo elemente (objekte), ki se prenašajo iz izhodov nekaterih procesov na vhode drugih. Predvsem predstavljajo elemente procesov, ki so obvezni z vidika MS ISO 9000:2000, kot so na primer »Evidenca kakovosti« ali »Organizacijska politika na področju vodenja kakovosti«.
Razvrstitev procesov je pomemben korak pri analizi dejavnosti organizacije. Eden od namenov klasifikacije je prepoznavanje procesov, povezanih s sistemom kakovosti organizacije.
Funkcionalni model je sestavljen iz dveh vrst elementov - funkcionalnih blokov in lokov. V skladu s tem je klasifikacija procesov, predstavljenih na funkcionalnem modelu, reducirana na klasifikacijo dejanskih funkcionalnih blokov in lokov.
V okviru modela IDEF0 so loki glede na njihov položaj v diagramu že razdeljeni v 4 kategorije: vhod, izhod, krmiljenje in mehanizem.
Poleg tega je mogoče loke razvrstiti glede na kategorijo predmetov, ki jih predstavljajo na diagramu. Te kategorije lahko vključujejo:
Materiali, surovine, izdelki, viri;
Informacije, podatki; zapisi o kakovosti; dokumentacija;
Naročila za upravljanje, načrti, urniki; upravni dokumenti;
Standardi, normativna dokumentacija;
Odgovorni izvajalci, zaposleni v organizaciji itd.
Za osvetlitev elementov določene vrste v modelu IDEF0 modeliranje uporablja vnaprej določene konvencije o grafičnem slogu predstavljanja objektov različnih kategorij. Ker so loki v modelu IDEF0 predstavljeni z ravnimi in lomljenimi črtami, grafični slog za loke vključuje konvencije za barvo črte, debelino črte, vrsto črte (polna, črtkana, črtkana pika itd.) in tip puščice na koncu. loki.
Na primer, loki, ki se odražajo v okviru funkcionalnega modela "Quality Records", so prikazani z zeleno polno črto (slika 4).
Opozoriti je treba, da vzpostavitev ujemanja med kategorijo predmeta (na primer kakovostni zapisi) in grafičnim slogom predstavitve tega predmeta (polna zelena črta) v funkcionalnem modelu nima le predstavitvene vloge. S pomočjo računalniškega programa je mogoče takšne odnose obdelati in ustvariti posebna poročila, ki vsebujejo na primer informacije o vseh procesih, ki na izhodu ustvarjajo kakovostne zapise.
Opomba. Grafični slogi niso del metodologije IDEF0. Uporaba grafičnih slogov za razvrščanje procesov je bila najprej predlagana in implementirana v sistemu IDEF0/EMTool.
Funkcionalne bloke v modelu IDEF0 lahko razvrstimo glede na kategorije procesov, ki jih predstavljajo. V okviru funkcionalnih modelov SC je treba uporabiti kategorije procesov, ki so urejeni v MS ISO 9001:2000.
Za izločevanje procesov določene kategorije v modelu IDEF0 modeliranje uporablja vnaprej določene konvencije o grafičnem slogu predstavljanja ustreznih funkcionalnih blokov v modelu, po analogiji s konvencijami za loke.
Procesni pristop, ki je osnova nove različice MS ISO 9000:2000, zahteva uporabo posebnih orodij za opis in klasifikacijo procesov, ki sestavljajo dejavnosti organizacije.
Članek kaže, da je eno od teh orodij lahko metodologija funkcionalnega modeliranja IDEF0.
V prid uporabi metodologije IDEF0 za opis in razvrščanje procesov ni le sposobnost metodologije, da reši ta problem v okviru sistema kakovosti organizacije, temveč tudi dejstvo, da je ta metodologija tudi standard za funkcionalno modeliranje v številnih državah, vključno z ZDA in Rusijo. Slednja okoliščina omogoča uporabo metodologije IDEF0 kot skupnega jezika za izmenjavo informacij med organizacijami, revizorji in strokovnjaki.
Metodologijo IDEF0 podpirajo računalniški programi. Uporaba računalniških programov na stopnji opisovanja procesov omogoča ne le povečanje učinkovitosti reševanja tega problema, temveč tudi uporabo teh modelov na stopnji vodenja procesov, ki jih integrirajo v korporativni informacijski sistem organizacije.
A. G. Kuryan, P. S. Serenkov
Uvod
Uspeh zavarovalništva v Rusiji je v celoti odvisen od stopnje njegove avtomatizacije.
Danes ni več treba prepričevati o prednostih in nujnosti avtomobilskega zavarovanja. V razmerah intenzivne motorizacije prebivalstva so najbolj prepričljivi argumenti v prid zavarovanju dnevna poročila prometne policije o številu prometnih nesreč in tatvin avtomobilov. Vse več voznikov, ki upajo na najboljše, se na cesti počutijo bolj samozavestne le zaradi avtomobilskega zavarovanja. Toda zavarovanje, ne samo avtomobilsko zavarovanje, potrebuje informacijsko podporo. Očitno je za uspešno oblikovanje enotnega informacijskega prostora za zavarovalniško dejavnost nujna združljivost različnih super avtocest. Eden od možnih pristopov k temu je standardizacija elektronske interakcije. · Zavarovanje, ki je močan dejavnik pozitivnega vpliva na gospodarstvo in zavarovalno zaščito pravnih in fizičnih oseb pred naključnimi nevarnostmi, temelji na rigidnem večnivojskem sistemu vodenja zavarovalnih procesov in potrebuje informacijske storitve in podporo. Proces zavarovalniške dejavnosti predvideva reševanje različnih funkcionalnih nalog, od izvrševanja sklenjenih zavarovalnih pogodb, prikazovanja informacij v IS njihovih pravnih in vsebinskih vidikov do oblikovanja računovodskega in statističnega poročanja, priprave vodstva. odločitve, kar zahteva avtomatizacijo delovno intenzivnih informacijskih procesov. · Značilnosti informacijske podpore za reševanje funkcionalnih problemov na področju zavarovalništva, teritorialne koncentracije podjetij, podružnic, delovnih postaj strokovnjakov, ki se ukvarjajo z zavarovalniškimi dejavnostmi, so določile potrebo po uporabi osebnega računalnika in komunikacijskih sredstev za informacijsko interakcijo strokovnjakov, zaposlenih v tej panogi. · Praksa ustvarjanja in uporabe AIT v zavarovalniških dejavnostih potrjuje izvedljivost delovanja porazdeljenega informacijsko-računalniškega omrežja ali večnivojskega omrežja, ki zagotavlja enotno tehnološko platformo s skupno informacijsko bazo za interakcijo z datotečnim strežnikom in drugim omrežjem. virov.
Namen predmetne naloge je izvesti začetno zasnovo informacijskega sistema izbranega predmetnega področja. Razvit IS naj podpira izvajanje določene dejavnosti organizacije in zagotavlja izvajanje niza funkcionalno povezanih operacij, značilnih za to dejavnost. V tem primeru je treba upoštevati postopek zavarovanja strank, plačila zavarovalne odškodnine in oblikovanja ustreznega IS.
Za dosego tega cilja so bile pred izvedbo tečajnega projekta zastavljene naslednje naloge:
Upoštevajte predmetno področje podjetja;
Preučiti načine oblikovanja IS in razviti podatkovne modele različnih vrst;
Izvajati logično in fizično zasnovo IS;
Izberite ustrezno arhitekturo za zadevni sistem.
Predmet študije je zavarovalnica "Rosgosstrakh".
Teoretični del
1.3 Ovitek-pomeniAllFusionModelar procesov
AllFusionProcessModeler (v nadaljevanju BPwin) je CASE orodje za modeliranje poslovnih procesov, ki vam omogoča ustvarjanje diagramov v zapisu IDEF0, IDEF3, DFD. Med modeliranjem vam BPwin omogoča preklop z zapisa IDEF0 na kateri koli veji modela na zapis IDEF3 ali DFD in ustvarjanje mešanega modela. BPwin podpira analizo funkcionalnih vrednosti (ABC).
Delo s programom se začne z izdelavo novega modela, za katerega morate določiti ime in vrsto (slika 1).
Slika 1 – Ustvarjanje novega modela
Izbira tipa modela določa zapis, v katerem se lahko izvede razgradnja dela. Torej, če izberete tip Poslovni proces (IDEF0), potem lahko v ustvarjenem modelu izvedete razgradnjo dela v notacijah IDEF0, IDEF3 in DFD; če je izbran tip DataFlow (DFD) - v zapisih DFD in IDEF3; če je izbran tip Process Flow (IDEF3), potem samo v zapisu IDEF3.
Ko vnesete ime modela in izberete njegovo vrsto, vas bo BPWin takoj pozval, da nastavite parametre modela (slika 2):
Slika 2 - Okno za nastavitev lastnosti modela
Številčenje - format številčenja del in diagramov ter vrstni red njihovega prikaza na diagramih;
Prikaz – seznam prikaznih elementov na grafikonih;
Layout - parametri postavitve;
ABC enote - enote funkcionalne stroškovne analize;
PageSetup - nastavitve strani;
Glava/noga - možnosti glave in noge.
Po nastavitvi lastnosti modela se prikaže glavno okno programa (slika 3), ki je sestavljeno iz treh glavnih delov:
Slika 3 - Glavno okno programa
1 Raziskovalec modelov (ModelExplorer) - prikaže strukturo modela (razpoložljivi diagrami in njihova hierarhija);
2 Glavni del - prikazuje diagrame, s katerimi delate;
3 orodne vrstice, med katerimi je najbolj zanimiva orodna vrstica ModelToolbox.
Opomba. V ustvarjenem modelu s privzetimi nastavitvami so ruski znaki prikazani napačno. Da bi odpravili to pomanjkljivost, je treba popraviti pisave, uporabljene v modelu. Če želite to narediti, morate v meniju Model ->DefaultFonts zaporedoma iti skozi vse elemente (slika 4), v spustnem seznamu Skripta izbrati vrednost cirilice in potrditi potrditveno polje Spremeni vse
pojavnosti (slika 5).
Slika 4 – Elementi menija, ki so odgovorni za nastavitve pisave
Slika 5 - Možnosti pisave
Orodna vrstica ModelToolbox.
Ta orodna vrstica je odgovorna za ustvarjanje različnih grafičnih elementov modela. Glede na vrsto trenutnega diagrama se spremeni nabor gumbov na njem.
Tabela 1 – Pogled in namen gumbov ModelToolbox
|
Pogled gumbov |
Ime gumba |
Dodelitev gumbov |
|
|
Kazalec spremeni v puščico kazalca, tako da da bi lahko izbirali predmete |
|||
|
IDEF0 - DFD - IDEF3 |
Dodajanje novega opravila v diagram |
||
|
Orodje za prednostno puščico |
Dodajanje nove puščice na grafikon |
||
|
Povezovanje imena puščice s samo puščico |
|||
|
Dodajanje besedila na grafikon |
|||
|
DiagramDictionaryEditor |
Klicanje okna upravitelja diagramov za ogled razpoložljive diagrame po vrsti in pojdite na izbrani |
||
|
GotoSiblingDiagram |
Prehod med standardnim grafikonom, drevo vozlišč in FEO diagram |
||
|
Pojdi naParentDiagram |
Pomaknite se do zemljevida staršev |
||
|
GotoChildDiagram |
Pomaknite se do otroškega grafikona |
||
|
ExternalReferenceTool |
Dodajanje zunanje entitete v diagram |
||
|
Dodajanje podatkovne shrambe diagramu |
|||
|
Dodajanje križišča na diagram |
|||
Ustvarjeni model že vsebuje kontekstni diagram z enim samim opravilom (»črno skrinjico«) v zapisu, ki je bil izbran v fazi izdelave modela. Zdaj morate temu delu dati ime in po potrebi nastaviti njegove lastnosti. Če želite to narediti, morate poklicati okno lastnosti opravila, dvokliknite ga z miško (slika 6).
Slika 6 - Okno z lastnostmi opravila
Nato morate na diagram postaviti puščice. Če želite to narediti, pritisnite gumb PrecedenceArrowTool na ModelToolbox (kurzor bo v obliki križa s puščico), kliknite na mesto, od koder naj gre puščica, in nato kliknite na mesto, kamor naj gre puščica (BPwin bo označite ta mesta, ko premaknete miškin kazalec nanje). Če želite poimenovati puščico, kliknite gumb PointerTool na ModelToolbox in nato dvokliknite puščico. V oknu ArrowProperties, ki se prikaže, se ime opravila vnese v polje ArrowName ali izbere s seznama razpoložljivih imen puščic.
Ko postavite puščice na diagram, lahko razgradite njegovo delo. To storite tako, da kliknete gumb GotoChildDiagram na ModelToolbox in nato kliknete delo, ki ga želite razstaviti. Prikaže se okno, v katerem morate izbrati zapis, ki ga želite uporabiti za dekompozicijo, in število podrejenih opravil (slika 7).
Slika 7 – Ustvarjanje podrejenega grafikona
Po ustvarjanju podrejenega grafikona bo BPwin samodejno ustvaril določeno število delovnih mest in postavil obrobne puščice na robove grafikona. Nato povežite mejne puščice z vhodi opravil (če je potrebno, lahko dodate nove mejne puščice) in povežite opravila med seboj. Nadaljnja razgradnja del se izvaja na podoben način.
Praktični del
2.2 Pprednosti uporabeAllFusionprocesModelar
Modelarji procesov zagotavljajo okvir za razumevanje poslovnih procesov in vrednotenje vpliva določenih dogodkov ter opis interakcije procesov in informacijskih tokov v organizaciji.
2.3 Izgradnja poslovnih modelov- procesov
Z uporabo orodja All Fusion Process Modeler CASE za modeliranje poslovnih procesov so bili ustvarjeni:
Slika 9 - Konceptualni model
Slika 11 - 3. raven podatkovnega modela
Slika 12 - Drevo funkcionalnega podatkovnega modela
Seznam izrazov in okrajšav
Poslovni proces je niz medsebojno povezanih dejavnosti ali nalog, katerih cilj je ustvariti določen izdelek ali storitev za potrošnike. Zaradi jasnosti so poslovni procesi vizualizirani z diagramom poteka poslovnega procesa.
Informacijski sistem je sistem za obdelavo informacij, ki deluje v povezavi z organizacijskimi viri, kot so ljudje, objekti in finančni viri, ki zagotavljajo in distribuirajo informacije.
Zaključek
Torej je glavni cilj zveznega zakona o obveznem zavarovanju zaščititi pravice žrtev do odškodnine za škodo, povzročeno njihovemu življenju, zdravju ali premoženju. Vse pravne norme, ki jih vsebuje zakon, so usmerjene k doseganju zastavljenega cilja. V ta namen zakon opredeljuje nabor potrebnih pravnih, gospodarskih in organizacijskih ukrepov za celovito ureditev razmerij na obveznem zavarovanju civilne odgovornosti lastnikov vozil.
Svetovna praksa poravnave škode po pogodbah o zavarovanju civilne odgovornosti lastnikov vozil kaže, da več kot 2/3 vseh plačil zavarovalnic predstavlja materialno (premoženjsko) škodo. Zato je za razvoj sistema OSAGO v Rusiji in povečanje stopnje zaupanja javnosti v to vrsto zavarovanja potrebno pravočasno reševanje težav, ki nastanejo pri določanju zneska in izplačilu zavarovanj za škodo, povzročeno na premoženju žrtev kot posledica nesreča je še posebej pomembna. Potrebne spremembe veljavne zakonodaje o obveznem zavarovanju civilne odgovornosti lastnikov vozil bodo prispevale k pravilnemu razumevanju pomena zakona, njegovemu doslednemu izvajanju s strani udeležencev v zavarovalnih pravnih razmerjih in uporabi v praksi pristojnih organov.
Cikel BPI temelji na razvoju in implementaciji funkcionalnega modela podjetja "The Right Way". Z vidika SADT (Structured Analysis and Design Technique – metodologija strukturne analize in projektiranja) je model lahko osredotočen bodisi na poslovne procese podjetja bodisi na njegove objekte. SADT-modeli, osredotočeni na poslovne procese, se imenujejo funkcionalni modeli (standard IDEF0), objektno usmerjeni (standard IDEF1) pa se imenujejo podatkovni modeli. Funkcionalni model predstavlja sistem poslovnih procesov z zahtevano stopnjo podrobnosti.
Prva in druga stopnja dekompozicije modela "Kakor mora" (standard IDEF0) sta oblikovani na podlagi elementov in podelementov serije ISO 9000:2000. Glej sliko 7.1. Naslednje stopnje dekompozicije modela "Kakor je treba" se oblikujejo na podlagi modela pretoka podatkov (zasnovanega na podlagi analize standarda ERP in modela "Kar je").
Model "kot bi moral" je zasnovan z uporabo diagramov IDEF0 in je značilen po:
Preoblikovanje blokov, ki pretvarjajo vhodni tok v izhodni tok pod vplivom nadzornih dejanj z uporabo mehanizmov.
Materialni, informacijski in finančni tokovi, opisani v modelu toka
riž. 7.1: Glavni elementi podjetja
podatkov. Informacijski tokovi so razdeljeni v tri skupine:
1. Omejevalne informacije vsebujejo zakoni, podzakonski akti; mednarodni, državni in industrijski standardi; dokumentacija sistema kakovosti, ki ureja delo oddelkov podjetja; Ta informacijski tok se obravnava kot kontrolna dejanja na transformatorskih blokih.
2. Opisne informacije vsebujejo risbe, tehnični in drugi opisi, detajli itd. dokumenti, ki so sestavni del celotnega življenjskega cikla izdelka.
3. Predpisne informacije - informacije o tem, kako, pod kakšnimi pogoji in po kakšnih pravilih je treba objekt na vhodu pretvoriti v objekt na izhodu transformatorskega bloka.
Mehanizmi, ki so razdeljeni na organizacijske, opisani v regulativnem modelu,
in tehnični, ki določa informacijski sistem podjetja (IS razreda ERP).
Kontrolna dejanja, ki so na primer lahko dokumenti sistema kakovosti.
Funkcionalno modeliranje (model »Kakor mora«) je reducirano na posploševanje operacij in tokov iz predhodno razvitega modela pretoka podatkov (na podlagi standarda ISO 9000) in oblikovanje grafičnega skeleta dokumentacije sistema kakovosti kot enega od kontrolnih akcij.
1. Funkcionalni model je:
2. Podatkovni model je:
3. Model SADT, ki ga opisuje standard IDEF0, je:
objektno usmerjen model. model, usmerjen v poslovne procese;
4. Model SADT, ki ga opisuje standard IDEF1, je:
model, usmerjen v poslovne procese; objektno usmerjen model.
5. Za model "The Right Way" je značilno:
sinhronizacijski bloki; funkcije; mehanizmi;
nadzorni vplivi.
materialni, informacijski in finančni tokovi;
transformacijski bloki;
6. Informacijski tokovi so razdeljeni v naslednje skupine:
opisne informacije; omejevalne informacije; predpisujoče informacije. podrobne informacije; informacije o dovoljenju;
Dosežene točke
8 Prileganje razkroja IDEF0-bloki z razvojem dokumentacije sistema kakovosti
Bloki preoblikovanja v modelu "Kakor bi morali" so v hierarhičnem podrejenem razmerju: dejavnost - proces - podproces - operacija - dejanje. Glej sliko 8.1.
Vsak transformacijski blok se izvaja s pomočjo mehanizma in nadzornih dejanj. Mehanizmi so organizacijske in tehnične strukture ter informacijski sistemi, ki podpirajo dejavnosti podjetja (organizacijsko-tehnična struktura se določi pri oblikovanju normativnega modela, ki se kasneje uporablja v modelu pretoka podatkov).
Po metodologiji IDEF0 se vsak transformacijski blok izvede s pomočjo kontrole (omejevalne in predpisujoče informacije).
Predpisne informacije so opredeljene z modelom "Kakršne so" in standardi ERP in niso predmet oblikovanja modela "Kako bi morale", omejevalne informacije (dokumentacija sistema kakovosti) pa so. Tako bo rezultat oblikovanja modela »Kakor mora« grafični skelet dokumentacije sistema kakovosti z določenimi merili za ocenjevanje kakovosti te dokumentacije.
V modelu "The Right Way" so transformacijski bloki povezani z dokumentacijo sistema kakovosti:
riž. 8.1: Transformacijski bloki v modelu "The Right Way".
1. Dejavnost - niz poslovnih procesov, ki označujejo ničelno raven modela "Kakor mora". Dejavnost pretvarja vhodne tokove v izhodne s pomočjo mehanizmov, ki so pod nadzorom zunanjega okolja (država, družba), na primer standard ISO 9001:2000.
2. Proces. Transformacijski bloki prve stopnje dekompozicije modela "Kakor mora" ustrezajo elementom serije ISO 9001: 2000. Za vsak proces je določen cilj. Doseganje ciljev vseh procesov zagotavlja implementacijo modela »Kakor mora« in s tem prehod podjetja na višjo raven BPI. Postopki se izvajajo v skladu z opredeljenimi cilji, opisanimi v priročniku kakovosti.
3. Podprocesi. Transformacijski bloki druge stopnje modela »Kakor bi morali« ustrezajo podelementom serije ISO 9001: 2000. Na podlagi cilja procesa se za vsak podproces, ki je vanj vključen, določi cilj. Podprocesi tečejo v skladu z opredeljenimi cilji, opisanimi v priročniku kakovosti.
4. Operacija - niz dejanj, ki se izvajajo zaporedno ali vzporedno. Operacija se izvaja:
v skladu z MIK-ji (metodična navodila za kakovost), ki so tretja raven dokumentacije sistema kakovosti podjetja;
s porabo virov;
predmet omejitev iz drugih operacij in zunanjega okolja (predmet nadzornih dejanj).
Operacije povezane s poslovnima procesoma "Upravljanje virov" in "Prodaja izdelkov" so opredeljene v modelu pretoka podatkov (na podlagi analize modela "Kak je" in ERP).
pikado). Tako je na ravni poslovanja standard ISO 9001:2000 spojen z industrijskimi standardi ERP.
5. Ukrep. Dejanja so rezultat razgradnje operacij. Akcija se izvaja v skladu z navodili sistema kakovosti.
Izvajanje modela "Kakor mora" je zagotovljeno z celostnim doseganjem ciljev procesov. Doseganje cilja posameznega procesa je možno zaradi celovitega doseganja ciljev podprocesov, ki tvorijo proces. Doseganje cilja posameznega podprocesa se bo izvajalo s celovitim doseganjem ciljev poslovanja ipd.
Tako je implementacija modela »Kakor mora« določena na vsakem delovnem mestu in se izvaja z uporabo niza dokumentacije sistema kakovosti in interakcije mehanizmov (IS, osebje), procesov in tokov podatkov ( informacijski, materialni, denarni). Uvedbo modela "Kakor mora" spodbuja integriran sistem upravljanja podjetja, ki temelji na sodobnih informacijskih tehnologijah, na primer IS razreda ERP.
9 Težave pri modeliranju vodenje poslovnih procesov
Pri modeliranju poslovnih procesov, kot enem od orodij za podporo dejavnosti vodje podjetja na podlagi metodologije IDEF (Integration definition for function modeling), se pojavljata dva problema.
Prvi je uporaba standardov in iz njih izhajajočih modelov za upravljanje organizacije. Modeliranje poslovnih procesov oziroma prisotnost informacijskega sistema razreda ERP ne zadostujeta za učinkovito podporo procesa vodenja, če si vodja ne zada naloge, da ga »vključi v poslovni proces«.
Drugi problem je posledica prvega in je povezan s predstavitvijo razvitih modelov vodjem podjetij. Problem ni v metodološki kompleksnosti IDEF, temveč v ekspresivnosti shem pri razpravi in odločanju velikega števila udeležencev v kratkem času (v obsegu predstavitve).
Ena slika je vredna tisoč besedljudska modrost
Pri mojem delu se pogosto pojavlja potreba ne le po preučevanju in reševanju določenega problema, temveč tudi po prepoznavanju njegove lokacije v celotnem modelu podjetja. Ni dovolj razumeti, da določena enota ne deluje pravilno, pomembno je razumeti, kako deluje z drugimi. V nasprotnem primeru je nemogoče prepoznati vse obstoječe težave in izbrati najboljšo metodo za rešitev problema. In za to morate preučiti delo podjetja in sestaviti njegov funkcionalni model.
Seveda bi moral vodja v teoriji imeti funkcionalen model dela podjetja in ni pomembno, ali govorimo o organizaciji skladišča ali IT sistema od vodila do aplikacije. Toda v resnici se skoraj nikoli ne izkaže za tako, zato v procesu preučevanja in iskanja rešitve naloge, ki jo je postavil naročnik, ustvarim tudi funkcionalni model podjetja ali določenega procesa (funkcije) na moj.
In za začetek naredimo kratek izlet v zgodovino. Vrnimo se v daljno leto 1877, med rusko-turško vojno. Takrat je tiskar Sytin prvič uporabil grafiko pri opisovanju vojaških operacij. Zdaj nam je vse to znano, ko opisujemo katero koli bitko, se nam pred očmi pojavijo karte s puščicami, ki jasno prikazujejo potek bitke. In v tistih dneh so bile vojaške operacije opisane z besedami. Za vsak boj - veliko, veliko besed. In na koncu je bilo zelo težko razumeti, kaj se dogaja.
Zato je bila Sytinova ideja resnično revolucionarna - začel je tiskati litografske kopije zemljevidov z označbo utrdb in lokacij vojaških enot. Te kartice so se imenovale »Za bralce časopisov. Koristi". Ideja se je izkazala za tako relevantno, da je bila prva naklada "Help" razprodana takoj. In potem so bile takšne aplikacije zelo povpraševane. Razlog je očiten. Grafika je pomagala razumeti tisto, kar je bilo skoraj nemogoče razbrati samo z besedami.
Podoben primer nemoči besednih opisov lahko navedem tudi iz lastne prakse. Ena od mojih strank me je prosila, da prevzamem implementacijo sistema ERP za njegovo podjetje. Ko sem vprašal, ali imajo kakšno tehnično nalogo, sem prejel odgovor: »Da, imajo. Ima pa 400 strani." Obenem se je naročnik zelo pritoževal, da so moji kolegi, s katerimi se je prej obrnil, projekt v celoti zavrnili ali pa so imenovali očitno napihnjene cene. Ko sem videl, da je referenčni opis res dolg 400 strani in je sestavljen izključno iz besedilnega opisa, sem razumel razloge za vedenje razvijalcev. Branje takšnega obsega besedila, poglabljanje vanj, razumevanje vseh odtenkov samo zato, da bi razumeli nalogo in poimenovali ceno, je res zelo težko.
Tej stranki sem ponudil alternativno možnost - da v obliki zapisov grafično opiše vse, kar je mogoče. Pokazal mu je primere modeliranja. Posledično zdaj ponovno razmišljajo o svojih željah in oblikovanju projektnega pooblastila.
Poznam tudi številne druge primere, ko je grafično modeliranje poslovnih procesov pomagalo tako mojim sodelavcem, poslovnim svetovalcem in razvijalcem, kot tudi samim poslovnežem pri njihovem delu.
Po preučitvi trenutnega stanja, tako kot kateri koli drug strokovnjak tretjih oseb, ustvarim komercialni predlog, v katerem čim bolj podrobno razkrijem svojo vizijo trenutnega stanja, pa tudi ukrepe, ki jih je treba sprejeti za rešiti nalogo in seveda pričakovani rezultat.
Takšna poročila o delovnih anketah so obsežna, zavzemajo več kot eno stran, kar je po eni strani nujno, po drugi strani pa otežuje zaznavanje. Sprva sem, tako kot mnogi drugi, mislil, da so obsežna poročila dobra, saj človek plača delo in mu moraš posredovati čim bolj podrobne informacije.
Pogosto pri modeliranju na papirju ali v različnih programih uporabniki poskušajo povečati vidljivost z uporabo različnih barv. To je ena najpogostejših napak. Pravzaprav uporaba večbarvnih puščic in blokov vnaša samo dodatno zmedo in tudi izkrivlja dojemanje sheme.
Vaš model mora biti berljiv v črno-beli barvi, brez dodatnih barvnih shem. Ta pristop hkrati pomaga preprečiti nesporazume in disciplinira ustvarjalca modela, posledično se povečata berljivost in pismenost modela.
Najboljša možnost je dovolj podrobnosti za razumevanje težave in nič več. Podrobne podrobnosti o delu posameznega oddelka ali celo zaposlenega se lahko razkrijejo ob izbiri podrobnega pogleda posameznega procesa. In takšna struktura se ustvari le, če je res potrebna za delo ali odločanje.
Podobno, če se odločim dodati blok, je pomembno zagotoviti, da ima tudi vse potrebne atribute. Pri tem je zelo pomembna previdnost, saj lahko pri modeliranju zapletenih poslovnih procesov spremembe v enem delu modela privedejo do sprememb v drugem. Vnesti jih je treba.
Najpogosteje pride do napak pri poimenovanju blokov. Na primer, namesto »Ustvari članek« napišejo »Ustvari članek«. Bloki v tem pristopu so dejanja, zato morajo biti vedno glagoli.
Hkrati menim, da poslovni analitik ni čisto poklic, s poslovno analitiko se ukvarja vsak poslovni vodja ali razvijalec nekaterih sistemov, ki analizira poslovanje in si prizadeva zgraditi čim bolj učinkovit sistem. Prav tem ljudem in v te namene je namenjeno orodje IDEF0.
Zato je zelo pomembno, da se pri sestavljanju funkcionalnega poslovnega modela nenehno posvetujete z vodjo podjetja "kot je", da ne bi naredili napak, ki bodo samodejno povzročile napake v fazah razgradnje. Tudi v naslednjih fazah bodo morda potrebna dodatna soglasja vodij strukturnih oddelkov in zaposlenih. Le če bo vaš funkcionalni model "kot je" resnično odražal dejansko stanje, lahko naredite nekaj sprememb in predlogov. In za doseganje visokokakovostnih rezultatov pri takem delu so najprej potrebne praktične izkušnje in poznavanje značilnosti določene vrste poslovanja.
Več člankov na to temo.
Zavarovalnice so finančni posredniki, ki so specializirani za opravljanje zavarovalnih storitev. Njihova dejavnost je oblikovanje na podlagi pogodb s pravnimi in fizičnimi osebami (s prodajo zavarovalnih polic) posebnih denarnih skladov, iz katerih se zavarovancem izplačujejo denarna plačila v določenih zneskih v primeru nastanka določenih dogodkov (zavarovalnih dogodkov).
Če vam to delo ne ustreza, je na dnu strani seznam podobnih del. Uporabite lahko tudi gumb za iskanje
Uvod……………………………………………………………………………………..………3
1. .….5
1.1. Ekonomska analiza dejavnosti zavarovalnice
Sogaz-Med JSC………………………………………………………………………………………..5
1.2. Ocena toka dokumentov zavarovalnice OJSC "Sogaz-Med" ... ..7
1.3. Razvoj funkcionalnega modela "kot je"…………………..10
2. Oblikovanje baze podatkov za zavarovalnico Sogaz-Med OJSC………………………………….16
2.1. Razvoj funkcionalnega modela "kakršen mora biti"…………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………….
2.2. Razvoj logično-fizičnega modela…………………………………16
3. Razvoj baze podatkov za podjetje JSC "Sogaz-Med"………………………19
3.1. Izbira programskega okolja za razvoj baze podatkov……………………
3.2. Glavne funkcije in postopki, uporabljeni pri razvoju baze podatkov .... (poizvedba za razvrščanje, filtriranje itd.)
3.3. Testiranje aplikacije……
Zaključek…………………………………………………………………………………..…….25
Literatura…………………………………………………………………..…...26
Prijave…………………………………………………………………………………..28
Uvod
V sodobnih razmerah se povečuje pomen informacijskih sistemov, ki omogočajo informacijsko podporo procesom odločanja. Baze podatkov so eden glavnih elementov večine informacijskih sistemov.
Če upoštevamo tako predmetno področje, kot je dejavnost zavarovalnice, je seveda nemogoče brez strukturiranja informacij v bazo podatkov.
Zavarovalnice - To so finančni posredniki, ki so specializirani za zagotavljanje zavarovalnih storitev. Njihova dejavnost je oblikovanje na podlagi pogodb s pravnimi in fizičnimi osebami (s prodajo zavarovalnih polic) posebnih denarnih skladov, iz katerih se zavarovancem izplačujejo denarna plačila v določenih zneskih v primeru nastanka določenih dogodkov (zavarovalnih dogodkov).
Zavarovalnica dela z zelo veliko količino informacij, tako o zaposlenih kot o strankah. To zahteva skupno bazo podatkov, ki vključuje vse potrebne informacije. To je zelo uporabniku prijazno in potrebno za avtomatizacijo postopka.Zato je avtomatizacija zavarovalniškega poslovanja v Rusiji zelo obetavna - številne domače zavarovalnice so šele pred kratkim začele resno razmišljati o potrebi po uvajanju zapletenih korporativnih sistemov.
Pomen je v tem, da je velika količina informacij, ki prehajajo skozi oddelek, glavni razlog za uporabo računalniške tehnologije. Avtomatizacija dejavnosti zavarovalnic olajša vzdrževanje baze pogodb in pospešuje dostop do nje, poenostavlja pripravo poročevalske dokumentacije in s tem povečuje produktivnost dela. Odpravljene so tudi pomanjkljivosti, kot so težave pri nadzoru zanesljivosti informacij (velika verjetnost napak, opustitev pri ročnem izpolnjevanju), potreba po izračunu nekaterih kazalnikov s pomočjo kalkulatorja in njihova nezadostna natančnost.
Namen tečajnega projekta je razviti bazo podatkov "Zavarovalna populacija" za OJSC "Sogaz-Med" v okolju Delphi 7.0.
Objekt: zavarovalnica JSC "Sogaz-Med"
Naloge:
1. Analiza dejavnosti zavarovalnice JSC "Sogaz-Med"
OJSC "Sogaz-Med"
Zdravstvena zavarovalnica OJSC Sogaz-Med je bila ustanovljena leta 1998 kot hčerinska družba Gazproma pod imenom Gazprommedstrakh, poleti 2003 pa je bila v okviru konsolidacije zavarovalniške dejavnosti vključena v skupino Sogaz.
Glavni cilji in cilji JSC "Sogaz-Med": izboljšanje sistema zdravstvene oskrbe, organizacija zdravstvene oskrbe in nadzor njene kakovosti, racionalna poraba sredstev, namenjenih za zdravstveno podporo, in varstvo pravic zavarovancev.
OJSC "Sogaz-Med" je specializirano za izvajanje obveznega zdravstvenega zavarovanja (CMI). Po rezultatih leta 2013 je družba zasedla 2. mesto na lestvici ruskih zdravstvenih zavarovalnic po zavarovalnih prihodkih iz obveznega zdravstvenega zavarovanja. Do danes je Sogaz-Med OJSC ena največjih zdravstvenih zavarovalnic v Ruski federaciji z več kot 15,7 milijona zavarovanih ljudi (več kot 11% ruskega prebivalstva). Regionalna mreža vključuje več kot 550 oddelkov na ozemlju 38 sestavnih enot Ruske federacije. Vplačani odobreni kapital družbe je na dan 30. septembra 2014 102,5 milijona rubljev, kar je v celoti skladno z zahtevami veljavne zakonodaje Ruske federacije glede višine odobrenega kapitala in omogoča Sogaz-Med načrtovanje svojih dejavnosti CHI. dolgoročno.
OJSC SOGAZ-Med nadaljuje z izvajanjem programa za uvedbo sodobnih tehnoloških sredstev za razvoj sistema CHI. Številne podružnice podjetja so sodelovale pri izvajanju zveznega projekta "Univerzalna elektronska kartica" (UEC). V preteklem obdobju je število sprejetih vlog za izdajo UEC na podlagi točk izdaje politik podružnic OJSC "SOGAZ-Med" znašalo približno 2,3 tisoč kosov. V mnogih pisarnah podjetja izdajajo CHI politike enega vzorca v obliki plastične kartice z elektronskim nosilcem ("elektronska politika").
JSC "SOGAZ-Med" uživa zaslužen ugled v strokovni skupnosti. Agencija za ocenjevanje Expert RA je marca 2013 potrdila oceno A++ zanesljivosti in kakovosti storitev za zavarovalnico JSC SOGAZ-Med ("Izjemno visoka stopnja zanesljivosti in kakovosti storitev").
To podjetje je član naslednjih specializiranih združenj:
Generalni direktor Zavarovalnice OAO SOGAZ-Med D.V. Tolstov je član predsedstva Medregionalne zveze zdravstvenih zavarovalnic.
Ekonomska analiza je pokazala, da je v letu 2014 znesek zavarovalnine družbe za obvezno zdravstveno zavarovanje znašal 44,45 milijona rubljev, kar je 1,3-krat več kot v preteklem letu. Poleg tega so zavarovalnine v okviru obveznega zdravstvenega zavarovanja znašale 34,434 milijarde rubljev ali 95,34 % celotnega zneska zavarovalnine.
Kar zadeva premoženjsko stanje, se med delovanjem podjetja vrednost sredstev in njihova struktura nenehno spreminjata. Najbolj splošne predstave o kvalitativnih spremembah, ki so se zgodile v strukturi sredstev in njihovih virih, je mogoče pridobiti z vertikalno in horizontalno analizo poročanja.
Vertikalna analiza prikazuje strukturo sredstev podjetja in njihove vire. Prednost vertikalne analize v primerjavi s horizontalno je uporaba relativnih kazalnikov v njej, ki v določeni meri izravnajo negativni vpliv inflacijskih procesov, ki lahko bistveno izkrivijo absolutne kazalnike računovodskih izkazov in s tem otežijo primerjaj jih v dinamiki (glej tabelo 1).
Tabela 1 - Struktura sredstev JSC "Sogaz-Med"
Iz zgornjih podatkov lahko sklepamo, da se je v letu 2012 znesek osnovnih sredstev podjetja povečal za 1.724 tisoč rubljev, vendar se je delež osnovnih sredstev v strukturi sredstev zmanjšal za 0,55 %. Leta 2013 je prišlo do zmanjšanja za 406 tisoč rubljev.
Družba nima neopredmetenih sredstev. Tudi delež dolgoročnih finančnih sredstev v strukturi sredstev je nepomemben in ima nihajoč trend: 2012 - 5,11 %, 2013 - 7,19 %, 2014 - 3,13 %.
Na splošno se je delež nekratkoročnih sredstev v letu 2013 povečal za 1,55 %, v letu 2014 pa se je zmanjšal za 4,36 %.
Kazalnik druge skupine sredstev – obratna sredstva, ima nasproten trend. V letu 2012 je njihov delež znašal 93,30 %, v letu 2013 - 91,75 %, v letu 2014 se je povečal na 96,11 %.
V analiziranem obdobju pretežni del kratkoročnih sredstev predstavljajo terjatve, ki v letu 2012 predstavljajo 66,38 %, v letu 2013 62,24 %, v letu 2014 pa se delež zmanjša na 46,63 %.
Znesek gotovine se je vsako leto povečal za skoraj 2-krat: s 401.732 tisoč rubljev. v letu 2012 na 740367 tisoč rubljev. leta 2013 in do 1705579 v letu 2014.
Vse našteto nakazuje, da se finančno stanje družbe Sogaz-Med OJSC vsako leto le izboljšuje, kar pomeni, da se ta organizacija razvija, povečuje bazo strank, kar posledično vodi v povečanje količine dela v dokumentu organizacije. tok.
1. 2. Ocena toka dokumentov zavarovalnice JSC "Sogaz-Med"
Pravočasna analiza in vrednotenje dokumentnega toka organizacije sta pogoja za njeno učinkovito delovanje in stabilen razvoj. Brez nenehnega izboljševanja dokumentacije vseh ključnih in podpornih poslovnih procesov ter brez izboljšanja organizacije pisarniškega dela je nemogoče resnično povečati učinkovitost organizacije.
Tako je v podjetju JSC "Sogaz-Med" upravljanje dokumentov eden najpomembnejših poslovnih procesov organizacije. Upoštevajte na primer seznam dokumentov, ki so potrebni za pridobitev police obveznega zdravstvenega zavarovanja.
Vlogi za izbiro (zamenjava) zavarovalne zdravstvene organizacije so priloženi naslednji dokumenti ali njihove overjene kopije, potrebne za registracijo zavarovanca:
1) za otroke po državni registraciji rojstva in do štirinajstih let, ki so državljani Ruske federacije:
2) za državljane Ruske federacije, stare štirinajst let in več:
3) za osebe, ki so upravičene do zdravstvene oskrbe v skladu z zveznim zakonom "o beguncih":
4) za tuje državljane, ki stalno prebivajo v Ruski federaciji:
5) za osebe brez državljanstva, ki stalno prebivajo v Ruski federaciji:
6) za tuje državljane, ki začasno prebivajo v Ruski federaciji:
7) za osebe brez državljanstva, ki začasno prebivajo v Ruski federaciji:
8) za zastopnika zavarovane osebe:
9) za zakonitega zastopnika zavarovane osebe:
Iz navedenega je jasno, da morajo zaposleni v zavarovalnici JSC "Sogaz-Med" porabiti veliko časa za delo z dokumenti, pogosto pa za delo, ki ni neposredno povezano s poklicnim poslom. Pogosta situacija je, ko komunikaciji s strankami namenjamo premalo pozornosti, saj zavarovalnice večino časa porabijo za skeniranje dokumentov in obvladovanje sistemov poteka dela.
Posledično neracionalna poraba virov in prestavljene prioritete zavarovalnice resno zmanjšujejo konkurenčnost družbe na zavarovalnem trgu in ovirajo širitev poslovanja.
Zato mora podjetje optimizirati potek dela, tako da ne zahteva vključevanja velikega števila človeških virov in vam omogoča enostavno in hitro pridobivanje informacij, ki jih trenutno potrebujete iz skladišča. Za podjetje bo to pomenilo dve zmagovalni točki: brezpogojno izboljšanje kakovosti opravljene storitve in skrajšanje časa, potrebnega za oskrbo ene stranke, kar lahko zmanjša število zaposlenih.
Pomembno je tudi, da optimizacija ne bo le poenostavila pretoka dokumentov, temveč bo pripomogla tudi k zmanjšanju stroškov njihove izdelave in obdelave.
Prednosti avtomatizacije poteka dela zavarovalnice JSC "Sogaz-Med":
Za razvoj modela "kot je" je namenjeno vrhunsko orodje CASE AllFusion Process Modeler (BPwin), ki podpira naslednje metodologije:
Izdelava modela v standardu IDEF0 .
Funkcionalni model je zasnovan tako, da opisuje obstoječe poslovne procese v podjetju (ti AS-model). jaz S "tako kot je") in idealno stanje - za kar si morate prizadevati (model TO-BE "kot bi moral biti"). Metodologija IDEF0 predpisuje gradnjo hierarhičnega sistema diagramov – posameznih opisov sistemskih fragmentov.
Konstrukcija modela IP se začne z opisom delovanja podjetja (sistema) ali njegovega ločenega dela (v našem primeru je to javno zavarovanje) kot celote v obliki kontekstnega diagrama. Slika 2 prikazuje kontekstni diagram IS "Zavarovanje prebivalstva":
sl.2. Kontekstni diagram zavarovanja prebivalstva
Kontekstni diagram prikazuje, da zavarovalnica od stranke prejme vlogo za zamenjavo ali izdajo police, pa tudi potni list, SNILS, veljavno polico (v primeru zamenjave). Mehanizmi upravljanja so regulativni pravni akti, opisi delovnih mest, statut podjetja, pa tudi dodatni sporazumi. Zaposleni so vir, potreben za nemoteno delo na področju javnega zavarovanja. Rezultati zavarovanja bodo nova zavarovalna polica, poročila o izdanih policah in poročila o finančnem stanju podjetja, ki se pošiljajo v glavno pisarno, da spremljajo dinamiko.
Nadalje je celoten zavarovalniški proces razdeljen na podprocese, ki jih je mogoče razstaviti na še manjše podprocese. Kot rezultat takšne particije je vsak fragment sistema prikazan na ločenem diagramu razgradnje. (glej sliko 3):
sl.3. Diagram razgradnje IDEF 0. Zavarovanje prebivalstva
. Kot rezultat nadaljnje particije funkcije "Delo s populacijo" dobimo naslednji diagram razgradnje (glej sliko 4):
sl.4. Diagram razgradnje IDEF 0. Delo s prebivalstvom.
Razstavimo funkcijo "Sprejem dokumentov in registracija" in dobimo končni diagram (glej sliko 5):
sl.5. Diagram razgradnje IDEF
Diagrami jasno prikazujejo procese, ki potekajo ob pridobitvi police, začenši s postopkom prejema dokumentov od stranke in konča z izdajo police. Prav tako se preverijo prejeti dokumenti in upošteva se vsaka stranka, ki je prejela polico, na podlagi česar se sestavijo poročila, potrebna za višje vodstvo.
1.4. Razvijanje modela "kako bi moralo biti".
Zdaj je dodan tak vir, kot je zbirka podatkov, s pomočjo katerega lahko poenostavite proces dela v OJSC Sogaz-Med (glej sliko 6):
Slika 6. Kontekstni diagram modela »kot mora biti«.
V diagrame "Zavarovanje prebivalstva", "Delo s prebivalstvom" in "Sprejem in registracija dokumentov" je dodan tudi vir baze podatkov. Spremembe so bile narejene v prej obravnavanem diagramu razčlenitve "Sprejem in registracija dokumentov". Zdaj je sprejem dokumentov in njihovo preverjanje en sam proces, zaradi katerega se razkrije prisotnost politike pri stranki. Prav tako lahko spremljate datum, ko se pravilnik konča in o tem vnaprej obvestite stranko (glej sliko 7):
sl.7. Diagram razgradnje IDEF 0. Sprejem in registracija dokumentov.
Iz modela »kot mora biti« izhaja, da uporaba baze podatkov na področju zavarovanja prebivalstva bistveno skrajša čas obdelave dokumentov, prejetih od strank, omogoča pa tudi natančnejše spremljanje veljavnosti polic. , kar posledično vodi do ugodnega uspeha pri delu z bazo strank in izboljšanja podobe podjetja.
2. poglavje Programski odsek
2.1 Opis logičnega modela
Slika 8 prikazuje logični model sistema, implementiran s programom ERWin podjetja ComputerAssociates:
sl.8. Logični podatkovni model.
Logični model vsebuje 3 entitete.
Entiteta Vrsta dokumenta vsebuje informacije o imenu dokumenta. Ključno polje "ID dokumenta" s podatkovnim tipom "celo število". Neključno polje "Vrsta dokumenta" s podatkovnim tipom "char(100)".
Subjekt "Zavarovalna polica" vsebuje podatke o stranki, polici in zaposlenem. Ključno polje "Številka zavarovalne police" s podatkovnim tipom "celo število". Neključna polja "Ime" s podatkovnim tipom "char(100)", "Datum rojstva" s podatkovno vrsto "", "ID dokumenta" int , "Serija številk dokumenta" int , "SNILS" int , "telefonska številka zavarovane osebe" int , "Datum registracije police" Datum čas , "Datum poteka politike" Datum čas , ID zaposlenega int
Entiteta »Zaposleni« vsebuje podatke o zaposlenem. Ključno polje "ID zaposlenega" s podatkovnim tipom "celo število". Neključni polji "Ime" in "Pozicija" s podatkovnimi vrstami "char(100)".
2.2. Fizični podatkovni model
Slika 9. Fizični podatkovni model.
Generacija fizičnega modela je bila izvedena s pomočjo zmožnosti programa CA Erwin Data Modeler. Izberite meni Tools->Forward Engineer->Schema Generation in pritisnite gumb Generate v oknu, ki se prikaže. V oknu, ki se prikaže, podajte ime baze podatkov, ustvarjene v Microsofr Server 2008, in strežnika. Baza podatkov je bila uspešno ustvarjena.
opisati povezave in normalizacija)
Poglavje 3. Programski odsek
S klikom na izbirni gumb 1 (100 dni) se funkcija sproži.
procedura TForm1.RadioButton1Click(Pošiljatelj: TObject);
vars:string;
začeti
Form1.Query2.Close;
Form1.Query2.SQL.Clear;
<:newdate1) ");
Form1.Query2.ExecSQL;
konec;
S klikom na izbirni gumb 2 (50 dni) se funkcija sproži.
začeti
Form1.Query2.Close;
Form1.Query2.SQL.Clear;
Form1.Query2.SQL.Add("Izberite številko,FIO,SNILS,Telefon iz dbo.OMS");
Form1.Query2.SQL.Add("kjer (Date_reg_doc+50>:newdate1) ");
Form1.Query2.ParamByName("newDate1").AsdateTime:=Form1.DateTimePicker1.DateTime;
Form1.Query2.ExecSQL;
konec;
S klikom na izbirni gumb 3 (10 dni) funkcija se sproži
začeti
Form1.Query2.Close;
Form1.Query2.SQL.Clear;
Form1.Query2.SQL.Add("Izberite številko,FIO,SNILS,Telefon iz dbo.OMS");
Form1.Query2.SQL.Add("kjer (Date_reg_doc+50>:newdate1)");
Form1.Query2.ParamByName("newDate1").AsdateTime:=Form1.DateTimePicker1.DateTime;
Form1.Query2.ExecSQL;
konec;
Ko kliknete na gumb v meniju »Nastavitve« -> Registracija zaposlenih, se prikaže pogovorno okno »Registracija zaposlenih« z dvema poljema in gumbom »Registracija«
Gumb1
začeti
Form3.Query1.Close;
Form3.Query1.SQL.Clear;
Form3.Query1.ExecSQL;
konec;
Ko pritisnete gumb za registracijo, se postopek sproži TForm 2. Gumb 1 Kliknite
začeti
Form2.Query3.Close;
Form2.Query3.SQL.Clear;
Form2.Query3.ExecSQL;
Form2.Query4.Active:=FALSE;
Form2.Query4.Active:=TRUE;
konec;
Zaključek
Trenutno morajo podjetja probleme v zvezi z upravljanjem dokumentov reševati na višji ravni. Nenehno spreminjajoči se ogromni tokovi informacij zahtevajo od osebja podjetja hitre in natančne odločitve, katerih cilj je doseči največji dobiček z minimalnimi stroški. Zato se podjetja vse pogosteje soočajo s težavami, povezanimi z obdelavo vhodnih informacij. Rešiti jih je mogoče z avtomatizacijo procesov, ki potekajo v podjetjih.
Avtomatizacija pomaga znižati stroške poslovanja z regulacijo in poenostavitvijo dostopa zaposlenih v podjetju do potrebnih informacij. Spremeni naravo dela zaposlenih, jih razbremeni opravljanja rutinskega dela in jim da možnost, da se osredotočijo na poklicno pomembne naloge.
V tem predmetnem projektu je bil obravnavan proces zavarovanja prebivalstva v družbi Sogaz-Med OJSC. Opisani in prikazani so bili poslovni procesi, ki potekajo ob prejemu politike. Predlagana je tudi rešitev problema tega podjetja, ki se nanaša na obdelavo vhodnega blaga v skladišču in povezanih dokumentov.
Nato sta bila razvita funkcionalna modela "kot je" in "kot mora biti", nato pa je opisan logični in fizični model programa. Na podlagi prejetih informacij je bila v programskem okolju izdelana baza podatkov »Zavarovanje prebivalstva«. Delphi 7.0 , ki zagotavlja sredstva za upravljanje podatkov v informacijskem sistemu za podporo delu pridobivanja police. Nastali program je bil preizkušen.
Bibliografija
Dodatek
Seznam
Enota 1
enota Enota1;
vmesnik
uporablja
Pogovorna okna, meniji, StdCtrls, ComCtrls, Grids, DBGrids, DB, DBTables;
tip
TForm1 = razred (TForm)
Glavni meni1: TMainMenu;
N1: element menija;
N2: element menija;
N3: element menija;
N4: element menija;
N5: element menija;
DBGrid1: TDBGrid;
GroupBox1: TGroupBox;
RadioButton1: TRAdioButton;
RadioButton2: TRAdioButton;
RadioButton3: TRAdioButton;
Poizvedba2: TQuery;
DataSource1:TDataSource;
Postopek N4Click(Pošiljatelj: TObject);
Postopek N5Klikni (Pošiljatelj: TObject);
Postopek N3Click(Pošiljatelj: TObject);
Radio ProcedureButton1Click(Pošiljatelj: TObject);
Radio ProcedureButton2Click(Pošiljatelj: TObject);
Radio ProcedureButton3Click(Pošiljatelj: TObject);
Zasebno
(zasebne izjave)
Javno
(javne izjave)
konec;
Obrazec1: TForm1;
izvajanje
uporablja Unit2, Unit3;
($R *.dfm)
procedura TForm1.N4Click(Pošiljatelj: TObject);
začeti
form2.show;
konec;
procedure TForm1.N5Click(Pošiljatelj: TObject);
začeti
form3.show;
konec;
procedura TForm1.N3Click(Pošiljatelj: TObject);
začeti
Obrazec1.Zapri;
konec;
procedure TForm1.RadioButton1Click(Sender: TObject);// dinamične poizvedbe
vars:string;
začeti
Form1.Query2.Close;
Form1.Query2.SQL.Clear;
Form1.Query2.SQL.Add("Izberite številko,FIO,SNILS,Telefon iz dbo.OMS");
Form1.Query2.SQL.Add("kje (datum_reg_doc+100<:newdate1) ");
Form1.Query2.ParamByName("newDate1").AsdateTime:=Form1.DateTimePicker1.DateTime;
Form1.Query2.ExecSQL;
konec;
procedura TForm1.RadioButton2Click(Pošiljatelj: TObject);
začeti
Form1.Query2.Close;
Form1.Query2.SQL.Clear;
Form1.Query2.SQL.Add("Izberite številko,FIO,SNILS,Telefon iz dbo.OMS");
Form1.Query2.SQL.Add("kjer (Date_reg_doc+50>:newdate1) ");
Form1.Query2.ParamByName("newDate1").AsdateTime:=Form1.DateTimePicker1.DateTime;
Form1.Query2.ExecSQL;
konec;
procedura TForm1.RadioButton3Click(Pošiljatelj: TObject);
začeti
Form1.Query2.Close;
Form1.Query2.SQL.Clear;
Form1.Query2.SQL.Add("Izberite številko,FIO,SNILS,Telefon iz dbo.OMS");
Form1.Query2.SQL.Add("kjer (Date_reg_doc+50>:newdate1)");
Form1.Query2.ParamByName("newDate1").AsdateTime:=Form1.DateTimePicker1.DateTime;
Form1.Query2.ExecSQL;
konec;
konec.
Enota 2
enota Enota 2;
vmesnik
uporablja
Windows, Messages, SysUtils, Variante, Classes, Graphics, Controls, Forms,
Pogovorna okna, mreže, DBGrids, StdCtrls, ComCtrls, DB, DBCtrls, DBTables;
tip
TForm2 = razred (TForm)
Oznaka9: Oznaka T;
GroupBox1: TGroupBox;
Oznaka1: Oznaka T;
Oznaka2: Oznaka T;
Oznaka3: Oznaka T;
Label4: T Label;
Oznaka5: Oznaka T;
Oznaka6: Oznaka T;
Uredi 1: TEdit;
DateTimePicker1: TDateTimePicker;
Edit2: TEdit;
Edit3: TEdit;
Edit4: TEdit;
GroupBox2: TGroupBox;
Oznaka7: Oznaka T;
DateTimePicker2: TDateTimePicker;
Oznaka8: Oznaka T;
Button1: TButton;
DBGrid1: TDBGrid;
Poizvedba1: TQuery;
Tabela1: TTtabela;
DataSource1:TDataSource;
Tabela2: TTtabela;
DataSource2: TDataSource;
ComboBox1: TComboBox;
Poizvedba2: TQuery;
ComboBox3: TComboBox;
Poizvedba3: TQuery;
DateTimePicker3: TDateTimePicker;
Poizvedba4: TQuery;
DataSource3:TDataSource;
Postopek FormCreate(Pošiljatelj: TObject);
Zasebno
(zasebne izjave)
Javno
(javne izjave)
konec;
Obrazec2: TForm2;
izvajanje
($R *.dfm)
procedura TForm2.FormCreate(Pošiljatelj: TObject);
začeti
Čeprav se query1.eof ne začne
Combobox1.items.add(query1.fieldbyname("Ime_doc").asstring);
Poizvedba1.naprej
konec;
Čeprav se query2.eof ne začne
Combobox3.items.add(query2.fieldbyname("FIO").asstring);
Poizvedba2.naprej
konec;
Form2.Query4.Active:=FALSE;
Form2.Query4.Active:=TRUE;
konec;
procedure TForm2.Button1Click(Pošiljatelj: TObject);
začeti
Form2.Query3.Close;
Form2.Query3.SQL.Clear;
Form2.Query3.SQL.Add("Vstavi v dbo.OMS (FIO,DB,ID_doc,number_doc,SNILS,Telephone,Date_reg_doc,Srok,ID_employee)");
Form2.Query3.SQL.Add("Vrednosti(:newFIO,:newDB,(Izberite ID_doc iz dbo.DOc, kjer je Ime_doc = :newDoc1),:newNumber_doc,:newSNILS,:newTelephone,:newDate_reg_doc,:newDate_reg_doc,:SeleceetS ID dbo.employee, kjer je FIO = :newDoc))");
Form2.Query3.ParamByName("newFIO").AsString:=Edit1.Text;
Form2.Query3.ParamByName("newDB").AsdateTime:=Form2.DateTimePicker1.DateTime;
Form2.Query3.ParamByName("newDoc1").AsString:=Combobox1.Items.Text;
Form2.Query3.ParamByName("newNumber_doc").AsString:=Edit2.Text;
Form2.Query3.ParamByName("newSNILS").AsString:=Edit3.Text;
Form2.Query3.ParamByName("newTelephone").AsString:=Edit4.Text;
Form2.Query3.ParamByName("newDate_reg_doc").AsdateTime:=Form2.DateTimePicker2.DateTime;
Form2.Query3.ParamByName("newSrok").AsdateTime:=Form2.DateTimePicker3.DateTime;
Form2.Query3.ParamByName("newDoc").AsString:=Combobox1.Items.Text;
Form2.Query3.ExecSQL;
Form2.Query4.Active:=FALSE;
Form2.Query4.Active:=TRUE;
konec;
konec.
Enota3
enota Enota3;
vmesnik
uporablja
Windows, Messages, SysUtils, Variante, Classes, Graphics, Controls, Forms,
Dialogs, StdCtrls, DB, DBTables;
tip
TForm3 = razred (TForm)
Oznaka1: Oznaka T;
Uredi 1: TEdit;
Oznaka2: Oznaka T;
Edit2: TEdit;
Button1: TButton;
Poizvedba1: TQuery;
ProcedureButton1Click(Pošiljatelj: TObject);
Zasebno
(zasebne izjave)
Javno
(javne izjave)
konec;
Obrazec3: TForm3;
izvajanje
($R *.dfm)
procedure TForm3.Button1Click(Pošiljatelj: TObject);
začeti
Form3.Query1.Close;
Form3.Query1.SQL.Clear;
Form3.Query1.SQL.Add("Vstavi v dbo.Employee (FIO, Položaj)");
Form3.Query1.SQL.Add("Vrednosti(:newFIO,:newPosition)");
Form3.Query1.ParamByName("newFIO").AsString:=Edit1.Text;
Form3.Query1.ParamByName("newPosition").AsString:=Edit2.Text;
Form3.Query1.ExecSQL;
konec;
konec.
projekt
program Projekt1;
uporablja
obrazci,
Enota 1 v "Enota1.pas" (Obrazec1),
Enota 2 v "Unit2.pas" (Obrazec2),
Enota3 v "Unit3.pas" (Obrazec3);
($R*.res)
začeti
Application.Initialize;
Application.CreateForm(TForm1, Form1);
Application.CreateForm(TForm2, Form2);
Application.CreateForm(TForm3, Form3);
Application.Run;
konec.
Druga sorodna dela, ki bi vas lahko zanimala.vshm> |
|||
| 20665. | Oblikovanje in izvedba lekarniške baze | 2,55 MB | |
| Novokuznetsk naloga za seminarsko nalogo Treba je oblikovati bazo podatkov, ki vključuje informacije, predstavljene kot skupino atributov: Farmacija Ime zdravila; opomba; skladiščenje; datum prejema; prihajajo; stanje ob koncu meseca; proizvajalec podjetja; prodajalec itd. Naloga je: Ustvariti bazo podatkov. Organizirajte stalne povezave med tabelami, da zagotovite celovitost vaše baze podatkov. | |||
| 20182. | Načrtovanje dnevne baze podatkov na fakulteti | 2,59 MB | |
| Oblikovanje baze podatkov za redno visoko šolo Izvajal: študent gr. Pri predmetnem delu je naloga razviti projekt baze podatkov za zbiranje potrebnih informacij v organizaciji za ustvarjanje baze podatkov za polnjenje. Bazo podatkov je treba oblikovati ob upoštevanju izvajanja zahtev različnih vrst za pridobitev informacij. Pri oblikovanju baze podatkov je treba upoštevati možnost izdaje poročila v papirni obliki. | |||
| 10007. | Oblikovanje baze podatkov "Katalog avtomobilskih delov" | 182,36 KB | |
| Sprva so bili lokalni nizi (ali datoteke) uporabljeni za zbiranje in shranjevanje informacij na računalniku, medtem ko so za vsako od funkcionalnih nalog, ki se rešujejo, nastale lastne datoteke začetnih in rezultatskih informacij. To je povzročilo znatno podvajanje podatkov, zapletlo njihovo posodabljanje in oteževalo reševanje med seboj povezanih problematičnih nalog. | |||
| 14064. | Oblikovanje in izdelava baze podatkov "Arhiv MBUK Izhbolda SDK" | 24,67 KB | |
| Stolpec tabele vsebuje informacije iste vrste za vse zapise in se imenuje polje. DBText – Uporablja se za prikaz, vendar ne spreminjanje besedilnih polj trenutnega nabora podatkov. DBEdit - zasnovan za prikaz in spreminjanje besedilnih polj podatkovnega niza. Podobno kot komponenta ComboBox na strani Stndrd, vendar služi kot besedilno polje baze podatkov. | |||
| 20557. | Avtomobilski servis za načrtovanje baze podatkov | 8,01 MB | |
| Baza podatkov je najprej skladišče podatkovnih objektov, tj. niz možnih konceptov ali dogodkov, ki jih opisuje baza podatkov, z možnostjo iskanja teh objektov po značilnostih. Za bazo podatkov lahko štejemo ne samo tabele, ki indeksirajo datoteke z znanjem različnih formatov, ampak tudi te datoteke same, ker so v takšni bazi znanja netipizirana repozitorija znanja. Podatkovne baze se lahko uporabljajo kot pomožno orodje, ki vam omogoča izvajanje nekaterih uporabnih funkcij. | |||
| 13839. | Oblikovanje notarske baze podatkov s tehnologijami Access DBMS | 13,53 MB | |
| Notar je ena najpomembnejših institucij pravnega sistema, namenjena spodbujanju oblikovanja demokratične pravne države, v kateri so z izvajanjem notarskih dejanj zanesljivo varovane pravice in zakoniti interesi državljanov in pravnih oseb. | |||
| 15115. | Tarifna politika zavarovalnice | 28,09 KB | |
| Napake pri izračunu tarif in pri določanju zavarovalne premije, posledično pomanjkanje sredstev za zagotavljanje izplačil zavarovanj, napake pri razvoju sheme pozavarovalne zaščite ali pri določanju njenih udeležencev in preplačila pozavarovalne premije ali stečaj pozavarovateljev; so lastna sredstva zavarovalnice. Ustreznost izbrane teme je posledica dejstva, da je tarifna politika zavarovalnic osnova stabilnega ... | |||
| 13963. | ORGANIZACIJA ZAVAROVANJA VOZIL V ZAVAROVALNICI LLC "ROSGOSSTRAKH" | 3,04 MB | |
| Bistvo zavarovanja je oblikovanje določenega denarnega zavarovalnega sklada in njegova razporeditev v času in prostoru za nadomestilo morebitne škode njegovim udeležencem v primeru nesreč, naravnih nesreč in drugih okoliščin, določenih z zavarovalno pogodbo. Znak za vse lastnike vozil A vrsta nedržavnega avtomobilskega zavarovanja v zvezi z zaščito ... | |||
| 21849. | Organizacija in izvedba PR kampanje za rebranding zavarovalnice ALLIANZ | 1021,66 KB | |
| Tu so definicije Sama Blacka, ki so prve prišle do rusko govorečega bralca: »PR je ena izmed vodstvenih funkcij, ki prispeva k vzpostavitvi in vzdrževanju komunikacije, medsebojnega razumevanja, lokacije in sodelovanja med organizacijo in njenim javnosti. | |||
| 20319. | BAZE PODATKOV IN NJIHOVA ZAŠČITA | 102,86 KB | |
| Spletne spletne baze podatkov so se pojavile sredi šestdesetih let prejšnjega stoletja. Operacije z operativnimi bazami podatkov so bile obdelane interaktivno s pomočjo terminalov. Enostavna indeksno zaporedna organizacija zapisov se je hitro razvila v zmogljivejši model zapisov, usmerjen v niz. Charles Bachmann je prejel Turingovo nagrado za vodenje dela skupine Data Base Task Group (DBTG), ki je razvila standardni jezik za opisovanje podatkov in manipulacijo s podatki. | |||
