Pentru a dezvolta modelul „ca atare”, este destinat instrumentul CASE de nivel superior AllFusion Process Modeler (BPwin), care acceptă următoarele metodologii:
Crearea unui model în standardul IDEF0.
Modelul funcțional are scopul de a descrie procesele de afaceri existente la întreprindere (așa-numitul model AS-IS „așa cum este”) și starea ideală de lucruri - la ce ar trebui să se străduiască (modelul TO-BE „cum ar trebui să fie "). Metodologia IDEF0 prescrie construirea unui sistem ierarhic de diagrame - descrieri unice ale fragmentelor de sistem.
Construcția unui model IS începe cu o descriere a funcționării unei întreprinderi (sistem) sau a unei părți separate a acesteia (în cazul nostru, asigurarea populației) ca întreg sub forma unei diagrame de context. Fig. 2 prezintă diagrama de context a IS „Asigurările populației”:
Fig. 2.
Diagrama de context arată că societatea de asigurări primește de la client o cerere de înlocuire sau emitere a unei polițe, precum și un pașaport, SNILS, o poliță valabilă (în cazul înlocuirii). Mecanismele de management sunt actele juridice de reglementare, fișele postului, statutul întreprinderii, precum și acordurile suplimentare. Angajații sunt resursele necesare pentru buna funcționare a industriei asigurărilor. Rezultatele asigurării vor fi o nouă poliță de asigurare, rapoarte privind stâlpii eliberați și rapoarte privind situația financiară a companiei, care sunt trimise la sediul central pentru a urmări dinamica.
În plus, întregul proces de asigurare este împărțit în sub-procese, care la rândul lor pot fi descompuse în sub-procese și mai mici. Ca rezultat al acestei împărțiri, fiecare fragment al sistemului este reprezentat pe o diagramă de descompunere separată. (vezi fig. 3):
Fig. 3.
Ca rezultat al divizării în continuare a funcției „Lucrează cu populația”, obținem următoarea diagramă de descompunere (vezi Fig. 4):
Fig. 4.
Efectuăm descompunerea funcției „Recepția documentelor și înregistrarea” și obținem diagrama finală (vezi Fig. 5):
Fig. 5.
Diagramele arată clar procesele care au loc la primirea unei polițe, începând cu procesul de primire a documentelor de la un client și terminând cu emiterea unei polițe către acesta. De asemenea, se verifica documentele primite, si se tine cont de fiecare client care a primit polita, in urma carora se intocmesc rapoartele necesare conducerii superioare.
Acum este adăugată o resursă precum o bază de date, cu ajutorul căreia este posibilă simplificarea procesului de flux de lucru la Sogaz-Med OJSC (vezi Figura 6):
Fig. 6. Diagrama contextuală a modelului „cum ar trebui să fie”.
În diagramele „Asigurarea populației”, „Lucrul cu populația” și „Recepția și înregistrarea documentelor”, a fost adăugată și o resursă de bază de date. Au existat modificări în diagrama considerată anterior a descompunerii „Acceptarea și înregistrarea documentelor”. Acum acceptarea documentelor și verificarea acestora este un singur proces, în urma căruia se dezvăluie că clientul are o politică. De asemenea, puteți urmări data la care se încheie polița și puteți notifica clientul în avans (vezi Figura 7):
Fig. 7.
Din modelul „cum ar trebui să fie” rezultă că utilizarea unei baze de date în domeniul asigurării populației reduce semnificativ timpul de procesare nu numai a documentelor primite de la clienți, dar face și o monitorizare mai atentă a valabilității politici, care la rândul lor duce la succes favorabil în colaborarea cu baza de clienți și îmbunătățirea imaginii companiei.
Cand. fiz.-mat. stiinte,
Profesor asociat al Departamentului de Software și Sisteme Inteligente,
Institutul de Stat de Inteligență Artificială Donețk
Ruchkina V.N.
.,
student postuniversitar al Universității Naționale Donețk
IT acoperă noi domenii de știință, tehnologie, afaceri. Un exemplu izbitor este afacerea cu asigurări. Introducerea și utilizarea tehnologiilor informaționale moderne devine un tipar obișnuit. Acest lucru se datorează în primul rând fluxului tot mai mare de informații care trebuie acumulate, stocate și procesate. Creșterea volumului de circulație a documentelor a companiei de asigurări duce la:
- cresterea numarului de angajati ai societatii de asigurari;
- la o creștere a costurilor de derulare a unei afaceri de asigurări;
- lipsa de flexibilitate în managementul companiei de asigurări;
- la o creștere a prețurilor la serviciile de asigurare ale companiei și, ca urmare, la o scădere a competitivității acesteia.
Capacitatea unei companii de asigurări de a procesa și a prelua cantități mari de informații în timp util depinde direct de nivelul de automatizare a activităților sale.
Rezultatul optim al muncii de dezvoltare a automatizării companiei de asigurări este dezvoltarea și implementarea unui sistem informatic informatic (CIS) pentru prelucrarea datelor, menit să acopere toate elementele principale ale procesului tehnologic și să garanteze securitatea completă a datelor în toate etapele. de prelucrare a informaţiei.
Procesul de trecere a unei companii de asigurări la sisteme informatice informatice cuprinde trei etape: dezvoltarea și proiectarea sistemului, programarea și implementarea acestuia.
Primul pas în etapa de dezvoltare și proiectare a unui sistem informațional corporativ este procesul de construire a modelelor de afaceri ideale și reale ale IC („programare de afaceri”). Proiectarea proceselor de afaceri se realizează atât folosind tehnologii clasice (SADT), cât și tehnologii moderne (UML). Abordările au avantaje și dezavantaje, dar vă permit să formalizați și să simplificați înțelegerea activităților companiei și a zonelor sale individuale.
Metodologia clasică de analiză structurală și proiectare SADT („Tehnica de analiză și proiectare structurată”) vă permite să descrieți activitățile companiei din punct de vedere funcțional și structural. Diagramele construite folosind această abordare reflectă sistemul de procese de afaceri al companiei ca un set de funcții, proceduri și sarcini efectuate în companie și descriu principiile utilizării fluxurilor de date. Aceste diagrame sunt ușor de înțeles pentru specialiștii de la diferite niveluri ale managementului companiei.
Metodologia analizei și proiectării orientate pe obiecte folosind limbajul de modelare unificat UML ("Unified Modeling Language") vă permite să reflectați dinamica proceselor companiei.
Următorul pas în această etapă este alegerea instrumentelor și sistemelor pentru modelarea afacerii. sisteme CASE ( „Inginerie software asistată de calculator”) sunt cele mai potrivite pentru aceasta. Alegerea CASE depinde de metodologia de modelare aleasă. Tehnologia modelării structurale clasice este implementată complet folosind sistemul BPWin, care face parte din pachetul software Computer Associates AllFusion Modeling 4.1. Modelele de proces ale următoarelor standarde (notații) sunt create în sistemul BPWin: IDEF0, DFD și IDEF3.
Modelele bazate pe standardul IDEF0 sunt necesare pentru a identifica munca de bază, neduplicată, neredundante și eficientă și resursele alocate corect. Diagramele de flux de date (DFD) descriu funcțiile de procesare a informațiilor, documentele, obiectele și oamenii și departamentele. Aceasta utilizează un set de elemente pentru surse, chiuvete și depozite de date. Pentru logica interacțiunii fluxurilor de informații se folosește IDEF3. Cu ajutorul acestuia, ele caracterizează atât o formulare separată a implementării unui proces de afaceri, cât și o secvență completă de acțiuni.
Diagramele create folosind BPWin vă permit să formulați mai precis enunțul problemei și să schițați etapele soluționării acesteia.
Luați în considerare procesele de organizare a contabilității și menținerea contractelor de asigurare, precum și decontarea pierderilor asupra acestora. Subiecții din aceste procese sunt: clientul (persoană fizică sau juridică) și personalul companiei de asigurări. Are ca obiect activitatea de contabilitate si intretinere a contractelor de asigurare, precum si decontarea pierderilor asupra acestora.
Contabilitatea contractelor de asigurare include următoarele procese:
- inregistrarea asiguratului, conditiile esentiale ale contractului de asigurare;
- procesarea contractelor de asigurare;
- calculul datoriei asiguratului (la plata platilor de asigurare conform graficului);
- inregistrarea platilor;
- calculul soldului sumei asigurate;
Menținerea contractelor de asigurare include următoarele procese:
- acceptarea documentelor primite;
- prelucrarea datelor în temeiul contractelor de reziliere;
- prelucrarea datelor în baza contractelor de reînnoire;
- formarea documentelor de ieșire (scrisori de prelungire a contractului sau plata următoarei rate);
- calculul reducerilor ca urmare a reînnoirii contractului și luarea în considerare a istoricului pozitiv de asigurare al clientului;
- eliberarea documentelor de ieșire.
Soluționarea daunelor în cadrul contractelor de asigurare include următoarele procese:
- acceptarea documentelor primite;
- inregistrarea asiguratului (persoana asigurata);
- înregistrarea unui eveniment asigurat;
- evaluarea evenimentului asigurat;
- mentinerea istoricului evenimentelor asigurate conform contractului de asigurare;
- mentinerea istoricului evenimentelor asigurate pentru asiguratul (persoana asigurata);
- calculul despăgubirilor de asigurare (plăți de asigurare);
- intocmirea actului de asigurare si inregistrarea acestuia;
- inregistrarea platilor de asigurare;
- întocmirea unei situații de plăți (despăgubiri) de asigurări în ansamblu pentru societate, ținând cont de diverse caracteristici de clasificare;
- formarea documentelor de ieșire;
- eliberarea documentelor de ieșire.
După definirea principalelor procese organizatorice de activitate, este necesară standardizarea fluxului de documente al companiei de asigurări. Un sistem informatic informatic este eficient atunci cand sunt determinate procesele organizationale ale activitatilor companiei, iar fluxul de lucru este standardizat.
La etapa finală a dezvoltării și proiectării SIC se întocmește o misiune tehnică. Termenii de referință ar trebui să conțină cerințe generale pentru sistem, cerințe detaliate pentru sarcinile și funcțiile sistemului și alte documentații tehnice. Cu cât sunt formulate mai precis cerințele pentru sistemul în curs de dezvoltare, cu atât vor fi implementate mai precis.
Sistemul informatic modern al unei companii de asigurări este un sistem de introducere, procesare și stocare a informațiilor, care acoperă toate principalele divizii, servicii, domenii de lucru ale companiei și îndeplinește cerințele de eficiență, fiabilitate, completitudine funcțională, claritate, accesibilitate și fiabilitate.
Eficiență - ar trebui să se aloce cât mai puțin timp posibil pentru introducerea și procesarea documentelor primare, deoarece valoarea informațiilor scade în fiecare zi.
Fiabilitatea se realizează datorită unui sistem informatic computerizat, pe care sunt deplasate funcțiile de verificare a corectitudinii introducerii datelor.
Completitudine funcțională - luând în considerare cantitatea maximă de informații, precum și conformitatea datelor conținute în documentația primară cu cerințele reglementărilor și instrucțiunilor, standardelor și acordurilor interne.
Claritate - datele introduse din documentația primară utilizată de departamentele companiei trebuie să fie consistente și consecvente, iar în caz de inconsecvență trebuie prevăzute mecanisme de control și proceduri de corectare a datelor.
Disponibilitatea datelor trebuie respectată pentru a efectua volumul de muncă necesar pentru verificarea informațiilor contabile, precum și pentru a obține informații despre documente care nu sunt necesare pentru activitatea curentă a departamentelor companiei.
Fiabilitate - asigurarea pierderii minime de date cu recuperare ulterioara in cazul defectarii sistemului cauzata de factori obiectivi si subiectivi.
Mai exact, sarcina tehnică poate fi întocmită ținând cont de diagramele și diagramele proiectate în stadiul de dezvoltare și proiectare a sistemului folosind instrumente moderne de business intelligence.
Primul pas în faza de programare presupune alegerea și proiectarea unui model de stocare. ERWin inclus în set Computer Associates AllFusion Modeling 4.1, vă permite să proiectați modelul de date selectat folosind diagrame DFD.
Următorul pas în faza de programare este definirea unui sistem sau limbaj de programare. Apoi sunt create părțile server și client ale sistemului sau limbajul de programare al interfeței. Urmează compilarea cererilor și formarea de șabloane pentru rapoarte.
Ultimul pas în etapa de programare este testarea și depanarea atât a părților individuale ale programului, cât și a întregului sistem.
Principalele etape de implementare includ instalarea și reglarea unui sistem informatic informatic. În plus, există o clarificare a documentelor primare și a formelor de rapoarte. Adaptarea sistemului presupune aducerea lui de la nivelul As Is la nivelul To Be, până la ajustarea proceselor de business în sine.
Un sistem informatic informatic trebuie sa contina module (subsisteme) corespunzatoare principalelor domenii de activitate din cadrul companiei: contract, intretinere contract, plati, analize, business core, expert. Toate aceste blocuri sunt axate pe furnizarea de informații prompte și de încredere conducerii companiei pentru a lua decizii informate de management.
Să aruncăm o privire mai atentă asupra activității blocului de experți. Acest bloc este un sistem expert (ES) capabil să rezolve principalele sarcini ale companiei, cum ar fi:
- eficienta in luarea unei decizii privind alegerea unui produs de asigurare pentru un client in functie de conditiile de asigurare specificate;
- capacitatea de a conduce o politică de subscriere on-line pentru diviziile structurale ale companiei, care sunt îndepărtate de sediul central al companiei;
- analiza si prognoza politicii tarifare pe tipuri de asigurare, produse de asigurare ale companiei;
- analiza activitatilor companiei la data de raportare in functie de parametrii de clasificare specificati (de exemplu, incasari de plati de catre diviziile de vanzare ale companiei, pe tipuri de asigurari, pe produse de asigurare; informatii operationale privind pierderile declarate de catre companie, pe tipuri de asigurări, pe produse de asigurare; informații operaționale privind plățile efective; informații despre rezultatul tehnic al activităților companiei la orice dată).
Sistemul expert funcționează atât cu cunoștințele dezvoltate în domeniul asigurărilor, cât și cu datele acumulate de compania de asigurări. Programul rezolvă sarcinile atribuite prin intermediul inferenței logice, având acces la sistemul de fapte și deduce concluzii din informațiile disponibile în baza de cunoștințe. Baza de cunoștințe (KB) constă din trei părți:
1. Reguli care descriu relații și metode de rezolvare a problemelor unui domeniu de aplicare. KB este compus din cunoștințe faptice stocate într-o bază de date despre un purtător și cunoștințe utilizate pentru a obține alte cunoștințe.
2. Mecanismul de retragere. Conține principiile și regulile de lucru, selectează modalitatea de aplicare a regulilor de rezolvare a problemelor. Stabilește ce reguli trebuie apelate, organizând accesul la acestea în baza de cunoștințe. Motorul de inferență detectează când este găsită o soluție acceptabilă și o trimite.
3. Sistem de interfață cu utilizatorul. Poate ajuta utilizatorii atunci când lucrează cu ES, chiar dacă nu știu cum este organizat; explică utilizatorului cum să obțină rezultatul.
Un sistem informatic informatic structurat profesional va crește avantajul competitiv al unei companii de asigurări, ale cărei fluxuri de informații cresc în fiecare zi. Procesul de tranziție a unei companii de asigurări la sisteme informatice informatice include etapele de dezvoltare, programare și implementare. Acest sistem va automatiza introducerea de informații pentru primirea de rapoarte privind activitățile companiei, ține centralizat evidențe și procesa date, va efectua prelucrarea electronică a datelor și va face schimb de informații, va analiza rapid activitățile cu determinarea ulterioară a tacticii companiei, va anticipa și planifica activitățile companiei. . Dificultăți în trecerea la sisteme informatice informatice - în primul rând, timpul alocat dezvoltării și implementării sistemului, costuri mari de numerar (un proces costisitor de standardizare și descriere a proceselor de afaceri ale unei companii de asigurări), schimbarea tradițiilor stabilite de Compania. Cu toate acestea, în mod ideal sunt viabile din punct de vedere economic și vă permit să lucrați competitiv pe piața serviciilor financiare.
Vezi și pe acest subiect.
Companiile de asigurări sunt intermediari financiari specializați în furnizarea de servicii de asigurare. Activitatea acestora consta in formarea pe baza de contracte cu persoane juridice si persoane fizice (prin vanzarea politelor de asigurare) a unor fonduri speciale, din care se fac plati catre asigurati de fonduri in sume determinate in cazul unor evenimente (evenimente asigurate). ).
Dacă această lucrare nu ți s-a potrivit în partea de jos a paginii, există o listă de lucrări similare. De asemenea, puteți utiliza butonul de căutare
Introducere ………………………………………………………… .. ……… 3
1. .….5
1.1. Analiza economică a activităților companiei de asigurări
OJSC Sogaz-Med ………………………………………………………… ..5
1.2. Evaluarea fluxului documentar al companiei de asigurări OJSC „Sogaz-Med” ... ..7
1.3. Dezvoltarea unui model funcțional „ca atare” ………………… ..10
2. Proiectarea bazei de date a companiei de asigurări Sogaz-Med OJSC ……………………………… .16
2.1. Dezvoltarea unui model funcțional „cum ar trebui să fie” ………………… ... …………… 13
2.2. Dezvoltarea unui model logico-fizic ……………………………… 16
3. Dezvoltarea unei baze de date pentru societatea OJSC „Sogaz-Med” ……… ... …………… 19
3.1. Alegerea unui mediu software pentru dezvoltarea bazei de date ……………………
3.2. Principalele funcții și proceduri utilizate în dezvoltarea bazei de date .... (Solicitare de sortare, filtrare etc.)
3.3. Testarea aplicației……
Concluzie ……………………………………………………… .. …… .25
Referințe …………………………………………………… ..… ... 26
Anexe ………………………………………………………………… ..28
Introducere
În condiţiile moderne, importanţa sistemelor informaţionale este din ce în ce mai mare, permiţând furnizarea de suport informaţional pentru procesele decizionale. Bazele de date sunt unul dintre elementele de bază ale majorității sistemelor informaționale.
Luând în considerare un astfel de domeniu ca activitatea unei companii de asigurări, este fără îndoială imposibil să faci fără structurarea informațiilor într-o bază de date.
Firme de asigurari - este vorba de intermediari financiari specializați în furnizarea de servicii de asigurare. Activitatea acestora consta in formarea pe baza de contracte cu persoane juridice si persoane fizice (prin vanzarea politelor de asigurare) a unor fonduri speciale, din care se fac plati catre asigurati de fonduri in sume determinate in cazul unor evenimente (evenimente asigurate). ).
O companie de asigurări lucrează cu o cantitate foarte mare de informații, atât despre angajați, cât și despre clienți. Acest lucru necesită o bază de date comună care să conțină toate informațiile necesare. Acest lucru este foarte ușor de utilizat și necesar pentru a automatiza procesul.Prin urmare, automatizarea afacerii de asigurări în Rusia este foarte promițătoare - în multe companii de asigurări autohtone abia recent au început să se gândească serios la necesitatea implementării sistemelor corporative complexe.
Relevanța constă în faptul că o cantitate mare de informații care trec prin departament este principalul motiv pentru utilizarea tehnologiei informatice. Automatizarea activităților asigurătorilor facilitează întreținerea bazei de date de contracte și accelerează accesul la aceasta, simplifică întocmirea documentelor de raportare, crescând astfel productivitatea muncii. De asemenea, elimină neajunsuri precum complexitatea controlului fiabilității informațiilor (există o mare probabilitate de erori, omisiuni la completarea manuală), necesitatea calculării unor indicatori cu ajutorul unui calculator și lipsa lor de acuratețe.
Scopul proiectului de curs este dezvoltarea unei baze de date „Asigurările populației” pentru SA „Sogaz-Med” în mediul Delphi 7.0.
Obiect: societatea de asigurări OJSC „Sogaz-Med”
Sarcini:
1. Analiza activităților companiei de asigurări OJSC „Sogaz-Med”
OJSC „Sogaz-Med”
Compania de asigurări medicale OJSC Sogaz-Med a fost înființată în 1998 ca o filială a Gazprom sub numele Gazprommedstrakh; în vara anului 2003, în timpul consolidării activității de asigurări, a fost încorporată în grupul Sogaz.
Principalele scopuri și obiective ale OJSC Sogaz-Med sunt: îmbunătățirea sistemului de suport medical, organizarea asistenței medicale și controlul calității acesteia, utilizarea rațională a fondurilor alocate pentru sprijinul medical și protecția drepturilor asiguraților.
Sogaz-Med OJSC este specializată în asigurări obligatorii de sănătate (ASM). La sfârșitul anului 2013, compania a ocupat locul 2 în ratingul companiilor de asigurări medicale din Rusia în ceea ce privește încasările de asigurare din asigurarea medicală obligatorie. Astăzi, OJSC „Sogaz-Med” este una dintre cele mai mari companii de asigurări medicale din Federația Rusă, cu un număr de asigurați de peste 15,7 milioane de persoane (mai mult de 11% din populația Rusiei). Rețeaua regională include peste 550 de subdiviziuni pe teritoriul a 38 de entități constitutive ale Federației Ruse. Capitalul autorizat plătit al Societății este de 102,5 milioane de ruble, la 30 septembrie 2014, ceea ce respectă pe deplin cerințele legislației actuale a Federației Ruse la dimensiunea capitalului autorizat și permite OJSC Sogaz-Med să își planifice activitățile. privind asigurarea medicală obligatorie pe termen lung.
OJSC SOGAZ-Med continuă implementarea programului de introducere a mijloacelor tehnologice moderne pentru dezvoltarea sistemului de asigurări medicale obligatorii. O serie de sucursale ale companiei au participat la implementarea proiectului federal „Cartel electronic universal” (UEC). În perioada trecută, numărul cererilor acceptate pentru eliberarea UEC pe baza punctelor de emitere a politicilor filialelor OJSC SOGAZ-Med a fost de aproximativ 2,3 mii bucăți. Multe birouri ale companiei emit polițe de asigurare medicală obligatorie pentru un singur eșantion sub forma unui card de plastic cu un purtător electronic („polița electronică”).
OJSC SOGAZ-Med se bucură de un prestigiu binemeritat în comunitatea profesională. În martie 2013, Agenția de Rating Expert RA a confirmat ratingul de fiabilitate și calitate a serviciilor la nivelul A++ al companiei de asigurări SOGAZ-Med OJSC („Nivel excepțional de ridicat de fiabilitate și calitate a serviciilor”)
Această companie este membră a următoarelor asociații de specialitate:
Director general al companiei de asigurări SOGAZ-Med D.V. Tolstov este membru al Prezidiului Uniunii Interregionale a Asigurătorilor Medicali.
Analiza economică a arătat că, la sfârșitul anului 2014, volumul primelor de asigurare ale Companiei pentru asigurarea medicală obligatorie se ridica la 44,45 milioane de ruble, ceea ce este de 1,3 ori mai mare decât indicatorii anului precedent. În plus, plățile de asigurare în cadrul asigurării medicale obligatorii s-au ridicat la 34,434 miliarde de ruble, sau 95,34% din valoarea totală a primelor de asigurare.
În ceea ce privește statutul proprietății, în cursul funcționării întreprinderii, valoarea activelor și structura acestora suferă modificări constante. Ideea cea mai generală a schimbărilor calitative care au avut loc în structura fondurilor și sursele acestora poate fi obținută folosind analiza verticală și orizontală a raportării.
Analiza verticală arată structura fondurilor întreprinderilor și sursele acestora. Avantajul analizei verticale față de analiza orizontală este utilizarea de indicatori relativi în ea, care, într-o anumită măsură, netezesc impactul negativ al proceselor inflaționiste, care pot distorsiona semnificativ indicatorii absoluti ai situațiilor financiare și, prin urmare, pot complica compararea lor în dinamică. Vezi tabelul 1)
Tabelul 1- Structura activelor OJSC „Sogaz-Med”
Din datele furnizate, se poate concluziona că în 2012 a avut loc o creștere a valorii activelor fixe ale întreprinderii cu 1.724 mii de ruble, cu toate acestea, în structura activelor, ponderea activelor imobilizate a scăzut cu 0,55%. În 2013, a existat o scădere cu 406 mii de ruble.
Societatea nu are imobilizări necorporale. Ponderea activelor financiare pe termen lung în structura activelor este, de asemenea, nesemnificativă și are o dinamică variabilă: 2012 - 5,11%, 2013 - 7,19%, 2014 - 3,13%.
În general, ponderea activelor imobilizate în 2013 a crescut cu 1,55%, în 2014 a scăzut cu 4,36%.
Indicatorul celei de-a doua grupe de active - activele circulante, are tendința opusă. În 2012, ponderea acestora a fost de 93,30%, în 2013 - 91,75%, în 2014 a crescut la 96,11%.
Pentru perioada analizată, cea mai mare parte a activelor circulante o constituie conturile de încasat, ele reprezintă 66,38% în 2012, 62,24% în 2013, în 2014 ponderea se reduce la 46,63%.
Suma fondurilor a crescut de aproape 2 ori în fiecare an: de la 401.732 mii de ruble. în 2012 până la 740367 mii de ruble. în 2013 și până la 1.705.579 în 2014.
Toate cele de mai sus sugerează că starea financiară a OJSC Sogaz-Med se îmbunătățește de la an la an, ceea ce înseamnă că această organizație se dezvoltă, crește baza de clienți, ceea ce duce la rândul său la o creștere a volumului de muncă în procesul de circulația documentelor organizației.
1. 2. Evaluarea fluxului de documente al companiei de asigurări OJSC „Sogaz-Med”
Analiza și evaluarea în timp util a fluxului de lucru al organizației sunt condițiile pentru funcționarea eficientă și dezvoltarea stabilă a acesteia. Este imposibil să creșteți cu adevărat eficiența muncii unei organizații fără îmbunătățirea constantă a documentației tuturor proceselor cheie și de sprijin, precum și fără îmbunătățirea organizării muncii de birou.
În același mod, în compania OJSC „Sogaz-Med” fluxul de documente este unul dintre cele mai importante procese de afaceri ale organizației. De exemplu, luați în considerare o listă de documente care sunt necesare pentru a obține o politică OMI.
Cererea de alegere (înlocuire) a unei organizații medicale de asigurare va fi însoțită de următoarele documente sau de copiile certificate ale acestora necesare pentru înregistrarea ca persoană asigurată:
1) pentru copiii după înregistrarea de stat a nașterii și cu vârsta sub paisprezece ani, care sunt cetățeni ai Federației Ruse:
2) pentru cetățenii Federației Ruse cu vârsta de paisprezece ani și mai mult:
3) pentru persoanele care au dreptul la asistență medicală în conformitate cu Legea federală „Cu privire la refugiați”:
4) pentru cetățenii străini cu reședința permanentă în Federația Rusă:
5) pentru apatrizii cu reședința permanentă în Federația Rusă:
6) pentru cetățenii străini rezidenți temporar în Federația Rusă:
7) pentru apatrizii care locuiesc temporar în Federația Rusă:
8) pentru un reprezentant al persoanei asigurate:
9) pentru reprezentantul legal al persoanei asigurate:
Din cele de mai sus, reiese clar că angajații companiei de asigurări Sogaz-Med OJSC trebuie să petreacă mult timp lucrând cu documente și, adesea, la muncă care nu are legătură directă cu afacerile profesionale. O situație obișnuită este atunci când nu se acordă suficientă atenție comunicării cu clienții, deoarece de cele mai multe ori asigurătorii sunt angajați în scanarea documentelor și stăpânirea sistemelor de management al documentelor.
Drept urmare, utilizarea irațională a resurselor și schimbarea priorităților companiei de asigurări reduc serios competitivitatea companiei pe piața asigurărilor și împiedică expansiunea afacerii.
Prin urmare, compania trebuie să optimizeze fluxul de lucru astfel încât să nu necesite implicarea unei cantități mari de resurse umane și să facă posibilă recuperarea cu ușurință și rapiditate a informațiilor necesare în momentul de față din stocare. Pentru companie, acest lucru va însemna două momente câștigătoare: o îmbunătățire necondiționată a calității serviciului oferit și o reducere a timpului necesar pentru deservirea unui client, ceea ce poate reduce numărul de personal.
De asemenea, este important ca optimizarea nu numai că vă va permite să eficientizați fluxurile de documente, ci va contribui și la reducerea costurilor de creare și procesare a acestora.
Avantajele automatizării fluxului de documente ale companiei de asigurări Sogaz-Med OJSC:
Pentru a dezvolta modelul „ca atare”, este destinat instrumentul CASE de nivel superior AllFusion Process Modeler (BPwin), care acceptă următoarele metodologii:
Crearea unui model în standard IDEF0.
Modelul funcțional este destinat să descrie procesele de afaceri existente în întreprindere (așa-numitul model AS eu S „așa cum este”) și starea ideală de lucruri - la ce ar trebui să se străduiască (modelul TO-BE „cum ar trebui să fie”). Metodologia IDEF0 prescrie construirea unui sistem ierarhic de diagrame - descrieri unice ale fragmentelor de sistem.
Construcția unui model IS începe cu o descriere a funcționării unei întreprinderi (sistem) sau a unei părți separate a acesteia (în cazul nostru, asigurarea populației) ca întreg sub forma unei diagrame de context. Fig. 2 prezintă diagrama de context a IS „Asigurările populației”:
Fig. 2. Diagrama contextului asigurării populației
Diagrama de context arată că societatea de asigurări primește de la client o cerere de înlocuire sau emitere a unei polițe, precum și un pașaport, SNILS, o poliță valabilă (în cazul înlocuirii). Mecanismele de management sunt actele juridice de reglementare, fișele postului, statutul întreprinderii, precum și acordurile suplimentare. Angajații - resursele necesare pentru a funcționa fără probleme în industria asigurărilor. Rezultatele asigurării vor fi o nouă poliță de asigurare, rapoarte privind stâlpii eliberați și rapoarte privind situația financiară a companiei, care sunt trimise la sediul central pentru a urmări dinamica.
În plus, întregul proces de asigurare este împărțit în sub-procese, care la rândul lor pot fi descompuse în sub-procese și mai mici. Ca rezultat al acestei împărțiri, fiecare fragment al sistemului este reprezentat pe o diagramă de descompunere separată. (vezi fig. 3):
Fig. 3. Diagrama de descompunere IDEF 0 asigurare a populatiei
. Ca rezultat al divizării în continuare a funcției „Lucrează cu populația”, obținem următoarea diagramă de descompunere (vezi Fig. 4):
Fig. 4. Diagrama de descompunere IDEF 0. Lucrul cu populația.
Efectuăm descompunerea funcției „Recepția documentelor și înregistrarea” și obținem diagrama finală (vezi Fig. 5):
Fig. 5. Diagrama de descompunere IDEF
Diagramele arată clar procesele care au loc la primirea unei polițe, începând cu procesul de primire a documentelor de la un client și terminând cu emiterea unei polițe către acesta. De asemenea, se verifica documentele primite, si se tine cont de fiecare client care a primit polita, in urma carora se intocmesc rapoartele necesare conducerii superioare.
1.4. Dezvoltarea modelului „cum ar trebui să fie”.
Acum este adăugată o resursă precum o bază de date, cu ajutorul căreia este posibilă simplificarea procesului de flux de lucru la Sogaz-Med OJSC (vezi Figura 6):
Fig. 6. Diagrama de context a modelului „cum ar trebui să fie”.
În diagramele „Asigurarea populației”, „Lucrul cu populația” și „Recepția și înregistrarea documentelor”, a fost adăugată și o resursă de bază de date. Au existat modificări în diagrama considerată anterior a descompunerii „Acceptarea și înregistrarea documentelor”. Acum acceptarea documentelor și verificarea acestora este un singur proces, în urma căruia se dezvăluie că clientul are o politică. De asemenea, puteți urmări data la care se încheie polița și puteți notifica clientul în avans (vezi Figura 7):
Fig. 7. Diagrama de descompunere IDEF 0.Recepția și înregistrarea documentelor.
Din modelul „cum ar trebui să fie” rezultă că utilizarea unei baze de date în domeniul asigurării populației reduce semnificativ timpul de procesare nu numai a documentelor primite de la clienți, dar face și o monitorizare mai atentă a valabilității politici, care la rândul lor duce la succes favorabil în colaborarea cu baza de clienți și îmbunătățirea imaginii companiei.
Capitolul 2 Secțiunea Program
2.1 Descrierea modelului logic
Figura 8 prezintă modelul logic al sistemului, implementat folosind programul ERWin de la Computer Associates:
Fig. 8. Model logic de date.
Modelul logic conține 3 entități.
Entitatea „Tipul documentului” conține informații despre numele documentului. Un câmp cheie ID document cu un tip de date întreg. Câmp non-cheie „Tip document” cu tipul de date „char (100)”.
Entitatea "Polita de asigurare" contine date despre client, polita si angajat. Câmp cheie „Numărul poliței de asigurare” cu tipul de date „întreg”. Câmpuri non-cheie „Nume complet” cu tipul de date „char (100)”, „Data nașterii” cu tipul de date „”, „ID document” int , „Numărul seriei de documente” int, "SNILS" int , „Numărul de telefon al persoanei asigurate” int , „Data înregistrării politicii” DateTime , „Perioada de valabilitate a politicii” DateTime , "Card de identitate al angajatului" int
Entitatea „Angajat” conține date despre angajat. Un câmp cheie ID de angajat cu un tip de date întreg. Câmpuri non-cheie „Nume complet” și „Poziție” cu tipuri de date „char (100)”.
2.2. Model de date fizice
Figura 9 Model de date fizice.
Generarea modelului fizic se face folosind capacitățile programului CA Erwin Data Modeler. Selectați meniul Tools-> Forward Engineer-> Schema Generation și apăsați butonul Generate în fereastra care apare. În fereastra care apare, specificați numele bazei de date create în Microsofr Server 2008 și serverul. Baza de date a fost generată cu succes.
Descrie conexiuni și normalizare)
Capitolul 3. Sectiunea Program
Făcând clic pe butonul Radio 1 (100 de zile) funcția este declanșată.
procedura TForm1.RadioButton1Click (Expeditor: TObject);
var s: șir;
începe
Form1.Query2.Close;
Form1.Query2.SQL.Clear;
<:newdate1) ");
Form1.Query2.ExecSQL;
Sfârșit;
Făcând clic pe butonul Radio 2 (50 de zile) funcția este declanșată.
începe
Form1.Query2.Close;
Form1.Query2.SQL.Clear;
Form1.Query2.SQL.Add ("Selectați numărul, FIO, SNILS, Telefon de la dbo.OMS");
Form1.Query2.SQL.Add ("unde (Date_reg_doc + 50>: data noua1)");
Form1.Query2.ParamByName ("newDate1"). AsdateTime: = Form1.DateTimePicker1.DateTime;
Form1.Query2.ExecSQL;
Sfârșit;
Făcând clic pe butonul Radio 3 (10 zile) funcția este declanșată
începe
Form1.Query2.Close;
Form1.Query2.SQL.Clear;
Form1.Query2.SQL.Add ("Selectați numărul, FIO, SNILS, Telefon de la dbo.OMS");
Form1.Query2.SQL.Add ("unde (Date_reg_doc + 50>: data noua1)");
Form1.Query2.ParamByName ("newDate1"). AsdateTime: = Form1.DateTimePicker1.DateTime;
Form1.Query2.ExecSQL;
Sfârșit;
Când faceți clic pe butonul din meniul „Setări” -> Înregistrare angajat, apare caseta de dialog „Înregistrare angajat” cu două câmpuri și butonul „Înregistrare”
Butonul 1
începe
Form3.Query1.Close;
Form3.Query1.SQL.Clear;
Form3.Query1.ExecSQL;
Sfârșit;
Când apăsați tasta de înregistrare, procedura este declanșată TForm 2. Buton 1 Faceți clic
începe
Form2.Query3.Close;
Form2.Query3.SQL.Clear;
Form2.Query3.ExecSQL;
Form2.Query4.Active: = FALSE;
Form2.Query4.Active: = TRUE;
Sfârșit;
Concluzie
În prezent, companiile trebuie să rezolve problemele legate de fluxul de documente la un nivel superior. În continuă schimbare, fluxurile uriașe de informații necesită de la personalul întreprinderii, rapiditatea și acuratețea deciziilor luate, vizând obținerea unui profit maxim la costuri minime. Prin urmare, întreprinderile se confruntă din ce în ce mai mult cu probleme asociate cu procesarea informațiilor primite. Acestea pot fi rezolvate prin automatizarea proceselor din companii.
Automatizarea ajută la reducerea costurilor de a face afaceri prin reglementarea și simplificarea accesului angajaților companiei la informațiile de care au nevoie. Schimbă natura muncii angajaților, eliberându-i de munca de rutină și oferindu-le oportunitatea de a se concentra pe responsabilități importante din punct de vedere profesional.
În cadrul acestui proiect de curs a fost luat în considerare procesul de asigurare a populației în societatea OJSC „Sogaz-Med”. Au fost descrise și descrise procesele de afaceri care au loc la primirea politicii. Și, de asemenea, a propus o soluție la problema acestei întreprinderi asociată cu procesarea mărfurilor care intra în depozit și a documentelor aferente.
Apoi au fost dezvoltate modele funcționale „așa cum este” și „cum ar trebui să fie”, în continuare, este descris modelul logic și fizic al programului. Pe baza informațiilor primite a fost creată baza de date „Asigurări populației” în mediul de programare Delphi 7.0 , care oferă instrumente de gestionare a datelor în sistemul informațional pentru a sprijini munca de obținere a unei politici. Programul rezultat a fost testat.
Bibliografie
Aplicație
Listare
Unitatea 1
unitate Unit1;
interfata
utilizări
Dialoguri, Meniuri, StdCtrls, ComCtrls, Grile, DBGrids, DB, DBTables;
tip
TForm1 = clasa (TForm)
MainMenu1: TMainMenu;
N1: TMenuItem;
N2: TMenuItem;
N3: TMenuItem;
N4: TMenuItem;
N5: TMenuItem;
DBGrid1: TDBGrid;
GroupBox1: TGroupBox;
RadioButton1: TRadioButton;
RadioButton2: TRadioButton;
RadioButton3: TRadioButton;
Query2: TQuery;
DataSource1: TDataSource;
Procedura N4Click (Expeditor: TObject);
Procedura N5Click (Expeditor: TObject);
Procedura N3Click (Expeditor: TObject);
Procedură RadioButton1Click (Expeditor: TObject);
Procedura RadioButton2Click (Expeditor: TObject);
Procedura RadioButton3Click (Expeditor: TObject);
Privat
(Declarații private)
Public
(Declarații publice)
Sfârșit;
Form1: TForm1;
implementare
folosește Unit2, Unit3;
($ R * .dfm)
procedura TForm1.N4Click (Expeditor: TObject);
începe
Form2.show;
Sfârșit;
procedura TForm1.N5Click (Expeditor: TObject);
începe
Form3.show;
Sfârșit;
procedura TForm1.N3Click (Expeditor: TObject);
începe
Formular1.Închidere;
Sfârșit;
procedura TForm1.RadioButton1Click (Expeditor: TObject); // interogări dinamice
var s: șir;
începe
Form1.Query2.Close;
Form1.Query2.SQL.Clear;
Form1.Query2.SQL.Add ("Selectați numărul, FIO, SNILS, Telefon de la dbo.OMS");
Form1.Query2.SQL.Add ("unde (Date_reg_doc + 100<:newdate1) ");
Form1.Query2.ParamByName ("newDate1"). AsdateTime: = Form1.DateTimePicker1.DateTime;
Form1.Query2.ExecSQL;
Sfârșit;
procedura TForm1.RadioButton2Click (Expeditor: TObject);
începe
Form1.Query2.Close;
Form1.Query2.SQL.Clear;
Form1.Query2.SQL.Add ("Selectați numărul, FIO, SNILS, Telefon de la dbo.OMS");
Form1.Query2.SQL.Add ("unde (Date_reg_doc + 50>: data noua1)");
Form1.Query2.ParamByName ("newDate1"). AsdateTime: = Form1.DateTimePicker1.DateTime;
Form1.Query2.ExecSQL;
Sfârșit;
procedura TForm1.RadioButton3Click (Expeditor: TObject);
începe
Form1.Query2.Close;
Form1.Query2.SQL.Clear;
Form1.Query2.SQL.Add ("Selectați numărul, FIO, SNILS, Telefon de la dbo.OMS");
Form1.Query2.SQL.Add ("unde (Date_reg_doc + 50>: data noua1)");
Form1.Query2.ParamByName ("newDate1"). AsdateTime: = Form1.DateTimePicker1.DateTime;
Form1.Query2.ExecSQL;
Sfârșit;
Sfârșit.
Unitatea 2
unitate Unit2;
interfata
utilizări
Windows, Mesaje, SysUtils, Variante, Clase, Grafică, Controale, Formulare,
Dialoguri, Grile, DBGrids, StdCtrls, ComCtrls, DB, DBCtrls, DBTables;
tip
TForm2 = clasa (TForm)
Label9: TLabel;
GroupBox1: TGroupBox;
Label1: TLabel;
Label2: TLabel;
Label3: TLabel;
Label4: TLabel;
Label5: TLabel;
Label6: TLabel;
Edit1: TEdit;
DateTimePicker1: TDateTimePicker;
Edit2: TEdit;
Edit3: TEdit;
Edit4: TEdit;
GroupBox2: TGroupBox;
Label7: TLabel;
DateTimePicker2: TDateTimePicker;
Label8: TLabel;
Buton1: TBbutton;
DBGrid1: TDBGrid;
Query1: TQuery;
Tabelul 1: TTtable;
DataSource1: TDataSource;
Tabelul 2: TTtable;
DataSource2: TDataSource;
ComboBox1: TComboBox;
Query2: TQuery;
ComboBox3: TComboBox;
Query3: TQuery;
DateTimePicker3: TDateTimePicker;
Query4: TQuery;
DataSource3: TDataSource;
Procedura FormCreate (Expeditor: TObject);
Privat
(Declarații private)
Public
(Declarații publice)
Sfârșit;
Form2: TForm2;
implementare
($ R * .dfm)
procedura TForm2.FormCreate (Expeditor: TObject);
începe
Deși nu query1.eof începe
Combobox1.items.add (query1.fieldbyname ("Nume_doc"). Asstring);
Interogare1.următorul
Sfârșit;
Deși nu query2.eof începe
Combobox3.items.add (interogare2.fieldbyname ("FIO"). Asstring);
Interogare2.next
Sfârșit;
Form2.Query4.Active: = FALSE;
Form2.Query4.Active: = TRUE;
Sfârșit;
procedura TForm2.Button1Click (Expeditor: TObject);
începe
Form2.Query3.Close;
Form2.Query3.SQL.Clear;
Form2.Query3.SQL.Add ("Inserați în dbo.OMS (FIO, DB, ID_doc, number_doc, SNILS, Telephone, Date_reg_doc, Srok, ID_employee)");
Form2.Query3.SQL.Add ("Valori (: newFIO,: newDB, (Selectați ID_doc din dbo.DOc unde Name_doc =: newDoc1) ,: newNumber_doc,: newSNILS,: newTelephone,: newDate_reg_doc,: newSrok, (Selectați ID_angajat dbo.angajat unde FIO =: newDoc)) ");
Form2.Query3.ParamByName ("nouFIO"). 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;
Sfârșit;
Sfârșit.
Unitatea 3
unitate Unit3;
interfata
utilizări
Windows, Mesaje, SysUtils, Variante, Clase, Grafică, Controale, Formulare,
Dialoguri, StdCtrls, DB, DBTtables;
tip
TForm3 = clasa (TForm)
Label1: TLabel;
Edit1: TEdit;
Label2: TLabel;
Edit2: TEdit;
Buton1: TBbutton;
Query1: TQuery;
Procedură Buton1Click (Expeditor: TObject);
Privat
(Declarații private)
Public
(Declarații publice)
Sfârșit;
Form3: TForm3;
implementare
($ R * .dfm)
procedura TForm3.Button1Click (Expeditor: TObject);
începe
Form3.Query1.Close;
Form3.Query1.SQL.Clear;
Form3.Query1.SQL.Add ("Inserare în dbo.Employee (FIO, Poziție)");
Form3.Query1.SQL.Add ("Valori (: newFIO,: newPosition)");
Form3.Query1.ParamByName ("nouFIO"). AsString: = Edit1.Text;
Form3.Query1.ParamByName ("newPosition"). AsString: = Edit2.Text;
Form3.Query1.ExecSQL;
Sfârșit;
Sfârșit.
Proiect
program Project1;
utilizări
Formulare,
Unit1 în „Unit1.pas” (Formular1),
Unit2 în „Unit2.pas” (Form2),
Unit3 în „Unit3.pas” (Form3);
($ R * .res)
începe
Application.Initialize;
Application.CreateForm (TForm1, Form1);
Application.CreateForm (TForm2, Form2);
Application.CreateForm (TForm3, Form3);
Application.Run;
Sfârșit.
Alte lucrări similare care vă pot interesa.Wshm> |
|||
| 20665. | Proiectarea si implementarea bazei de date a farmaciilor | 2,55 MB | |
| Misiunea Novokuznetsk pentru lucrarea de termen Este necesar să se proiecteze o bază de date care să includă informații prezentate sub forma unui grup de atribute: Farmacie Numele medicamentului; adnotare; depozitare; Data primirii; venire; sold la sfârșitul lunii; producătorul companiei; furnizor, etc. Sarcina este următoarea: Creați o bază de date. Organizați relații persistente între tabele pentru a asigura integritatea bazei de date. | |||
| 20182. | Facultatea de proiectare a bazelor de date în timpul zilei | 2,59 MB | |
| Proiectare baze de date pentru catedra de zi a colegiului Completată de: student gr. În cadrul cursului, sarcina este stabilită - să dezvolte un proiect de bază de date pentru acumularea informațiilor necesare în organizație pentru a crea o completare a bazei de date. Baza de date trebuie concepută ținând cont de implementarea solicitărilor de diferite tipuri pentru obținerea de informații. La proiectarea bazei de date, ar trebui luată în considerare posibilitatea emiterii unui raport pe hârtie. | |||
| 10007. | Proiectarea bazei de date „Catalog de piese de schimb auto” | 182,36 KB | |
| Inițial, pentru acumularea și stocarea informațiilor pe un computer s-au folosit matrice (sau fișiere) locale, în timp ce pentru fiecare dintre sarcinile funcționale de rezolvat s-au creat propriile fișiere de informații inițiale și rezultate. Acest lucru a dus la o duplicare semnificativă a datelor, a complicat actualizarea acestora și a îngreunat rezolvarea sarcinilor problematice interconectate. | |||
| 14064. | Proiectarea și crearea bazei de date „Arhive MBUK Izhboldinsky SDK” | 24,67 KB | |
| O coloană de tabel conține informații de același tip pentru toate înregistrările și se numește câmp. DBText - Folosit pentru a afișa, dar nu pentru a modifica câmpurile de text curente ale setului de date. DBEdit - Proiectat pentru a afișa și modifica câmpurile de text ale setului de date. Similar cu componenta ComboBox a paginii Stndrd, dar servește câmpul de text DB. | |||
| 20557. | Baza de date Design Auto Service Station | 8,01 MB | |
| O bază de date este, în primul rând, o stocare a obiectelor de date, adică. un set de concepte sau evenimente posibile descrise de baza de date, cu capacitatea de a căuta aceste obiecte după atribute. O bază de date poate fi considerată nu numai tabele care indexează fișiere cu cunoștințe de diferite formate, ci și aceste fișiere în sine, deoarece nu sunt depozite de cunoștințe tastate într-o astfel de bază de date. Bazele de date pot fi folosite ca ajutor pentru implementarea unor funcții utile. | |||
| 13839. | Proiectarea unei baze de date pentru biroul notarial folosind tehnologiile de bază de date Access | 13,53 MB | |
| Notarul este una dintre cele mai importante instituții ale sistemului juridic, menită să contribuie la formarea unui stat democratic de drept, în care drepturile și interesele legitime ale cetățenilor și persoanelor juridice sunt protejate în mod fiabil prin implementarea actiuni notariale. | |||
| 15115. | Politica tarifară a companiei de asigurări | 28,09 KB | |
| Erori în calculul tarifelor și în stabilirea primei de asigurare, lipsa ulterioară a fondurilor pentru asigurarea plăților de asigurare, erori în dezvoltarea unei scheme de protecție în reasigurare sau în stabilirea participanților acesteia și plata în exces a primei de reasigurare sau falimentul reasigurătorilor , un nivel supraestimat al costurilor pentru a face afaceri - toate acestea conduc la pierderi prin sursa de acoperire a cărora servesc fondurile proprii ale organizației de asigurări. Relevanța temei alese se datorează faptului că politica tarifară a asigurătorilor stă la baza unui... | |||
| 13963. | ORGANIZAREA ASIGURĂRII DE VEHICULE ÎN COMPANIA DE ASIGURĂRI SRL „ROSGOSSTRAKH” | 3,04 MB | |
| Esența asigurării este formarea unui anumit fond de asigurare monetară și distribuirea acestuia în timp și spațiu pentru a compensa eventualele daune aduse participanților săi în caz de accidente, dezastre naturale și alte circumstanțe prevăzute de contractul de asigurare.caracter pentru toți proprietarii de vehicule Tip de asigurare auto non-statală asociată cu protecția... | |||
| 21849. | Organizarea si implementarea unei campanii de PR pentru rebranding-ul companiei de asigurari ALLIANZ | 1021,66 KB | |
| Iată definițiile lui Sam Black, care a venit primul la cititorul vorbitor de limbă rusă: „PR este una dintre funcțiile de management care contribuie la stabilirea și menținerea comunicării, înțelegerii reciproce, locației și cooperării între organizație și ea. public. | |||
| 20319. | BAZELE DE DATE ȘI PROTECȚIA LOR | 102,86 KB | |
| Bazele de date online online au apărut la mijlocul anilor 1960. Operațiunile pe baze de date operaționale au fost procesate interactiv folosind terminale. Organizațiile simple de înregistrări indexate secvențiale au evoluat rapid către un model de înregistrare mai puternic, orientat spre set. Charles Bachmann a primit Premiul Turing pentru conducerea Grupului de activitate pentru baze de date (DBTG), care a dezvoltat un limbaj standard pentru descrierea datelor și manipularea datelor. | |||
În anul 2000, Organizația Internațională pentru Standardizare (ISO) a adoptat o nouă versiune a seriei 9000 de standarde, care conține o listă de cerințe pentru sistemul calității (QS) al organizației.
Una dintre diferențele fundamentale în noua versiune a standardelor este utilizarea unei abordări procesuale a managementului, precum și a creării și funcționării CI.
Ideea principală a abordării procesului în noua versiune a standardelor poate fi rezumată după cum urmează:
Activitățile organizației trebuie prezentate sub forma unei rețele de procese care interacționează;
Managementul activităților organizației ar trebui să se bazeze pe managementul unei rețele de procese.
Acest articol discută o abordare a descrierii și clasificării proceselor într-o organizație bazată pe aplicarea metodologiei de modelare funcțională IDEF0.
ISO 9000: 2000 utilizează următoarea definiție a procesului:
„Un set de operațiuni (acțiuni) interconectate și care interacționează care transformă intrările în ieșiri.
Nota 1: Intrările în procese sunt, în general, ieșirile altor procese.
Nota 2. Procesele dintr-o organizație sunt planificate și executate în condiții controlate pentru a adăuga valoare.”
Majoritatea experților SC sunt de acord că cel mai acceptabil mod de a descrie procesele este reprezentarea grafică a acestora. Diverse documente privind interpretarea abordării proceselor prezentate în noua versiune a standardului oferă diferite opțiuni pentru prezentarea grafică a proceselor.
Descrierea proceselor ar trebui să reflecte nu numai procesele individuale, ci și relațiile și interacțiunile dintre procese.
Procesele, împreună cu relațiile și interacțiunile, reprezintă rețeaua de procese dintr-o organizație.
Descrierea rețelei de procese care alcătuiesc activitățile unei organizații este o problemă organizațională și tehnică complexă, pentru soluționarea căreia sunt necesare mijloace speciale de descriere și analiză.
Pentru prima dată această împrejurare a fost realizată la mijlocul anilor '70 în timpul implementării unor proiecte complexe comandate de Forțele Aeriene ale SUA. Totodată, a fost propus și implementat un program de fabricație integrată asistată de computer (ICAM), în cadrul căruia, în special, a fost aplicată metodologia de analiză structurală a sistemelor. Ulterior, pe baza acestei abordări, a fost dezvoltată metodologia de modelare funcțională IDEF0, care în 1993 a fost adoptată ca standard federal în Statele Unite, iar în 2000 ca standard în Federația Rusă.
Metodologia de modelare funcțională IDEF0 folosește următoarea notație pentru a reprezenta grafic procesul (Fig. 2).
În conformitate cu metodologia IDEF0, procesul este reprezentat ca un bloc funcțional care transformă intrările în ieșiri în prezența resurselor (mecanismelor) necesare în condiții controlate.
Interconexiunile și interacțiunile proceselor din IDEF0 sunt reprezentate de arce care conectează ieșirile unor blocuri funcționale cu intrările altora.
Modelul rețelei de proces din cadrul sistemului calității ar trebui să răspundă la următoarele întrebări:
Care sunt procesele din activitățile organizației legate de sistemul calității?
Care este structura acestor procese, inclusiv ieșirile și consumatorii proceselor, intrările și furnizorii etc.?
Cum interacționează procesele între ele?
Cum îndeplinesc procesele cerințele definite în seria ISO 9000, versiunea 2000?
Pentru ca modelul funcțional al rețelei de proces să răspundă la aceste și la alte întrebări din cadrul CI, acesta trebuie construit în conformitate cu cerințe suplimentare (în plus față de cele formulate în metodologia IDEF0).
Mai jos este o listă departe de a fi completă de cerințe pe care trebuie să le îndeplinească un model de proces funcțional:
Modelul functional este construit din punctul de vedere al managementului sistemului calitatii organizatiei. Prin această abordare, modelul include toate procesele și elementele care afectează calitatea produsului și proceselor finale.
Modelul funcțional trebuie să conțină procesele identificate ca obligatorii în cadrul cerințelor din seria ISO 9000, versiunea 2000. O listă a acestor procese este dată în MS ISO 9001: 2000.
Modelul funcțional ar trebui să conțină elementele (obiectele) reglementate în seria ISO 9000, versiunea 2000. O listă cu astfel de elemente este dată în.
Modelul funcțional ar trebui să acopere toate etapele ciclului de viață al produsului care intră în domeniul de aplicare al organizației.
Procesul de afaceri
Pentru ca modelul funcțional să îndeplinească cerințele enumerate, acesta trebuie să fie construit ca model de proces de afaceri.
Un proces de afaceri este un ansamblu de procese (operațiuni, acțiuni) și interacțiuni între acestea, al căror rezultat (ieșire) sunt produse și/sau servicii furnizate consumatorilor, iar inputurile sunt resurse materiale, informaționale și de muncă furnizate de furnizori externi.
Astfel, modelul funcțional al procesului de afaceri va acoperi procesele ciclului de viață, precum și procesele de suport și management asociate care fac parte din activitățile organizației. Acest lucru este pe deplin în concordanță cu cerințele familiei IS ISO 9000 versiunea 2000.
De exemplu, un atelier de cusut produce (coase) paltoane de dama, incheind contracte cu consumatorii. Consumatorii produselor sunt magazinele de îmbrăcăminte și firmele comerciale și intermediare. Atelierul cumpără materii prime de la fabrici prăbușite, precum și de la companii comerciale și intermediare. Procesul de afaceri într-un atelier de cusut este procesul de „Confecționare a paltoanelor de damă”.
Procese și elemente obligatorii
În IS ISO 9001: 2000, procesele obligatorii includ:
Implementarea responsabilitatii managementului de top in cadrul sistemului calitatii;
Managementul resurselor (procese auxiliare de producție);
Managementul principalelor procese de producție (procesele ciclului de viață al produsului);
Procese de măsurare, monitorizare și îmbunătățire a SC.
Elementele obligatorii includ, dar nu se limitează la:
Documente care contin politica, obiectivele organizatiei in domeniul managementului calitatii;
Documente care conțin responsabilitatea angajaților organizației (fișe de post);
Înregistrări de calitate etc.
În consecință, modelul funcțional trebuie să conțină toate procesele și elementele obligatorii în conformitate cu cerințele din seria IS ISO 9000 versiunea 2000.
În exemplul nostru, procesul de afaceri dintr-un atelier de cusut va avea următoarea structură (Fig. 4).
În diagramă (Fig. 4), procesul este prezentat sub forma a 4 procese care interacționează. Fiecare dintre cele 4 procese este obligatoriu în ceea ce privește îndeplinirea cerințelor MS ISO 9001: 2000.
Săgețile care conectează blocurile funcționale reprezintă elemente (obiecte) care sunt transferate de la ieșirile unor procese la intrările altora. În special, ele reprezintă elementele proceselor care sunt obligatorii din punctul de vedere al IS ISO 9000: 2000, precum, de exemplu, „Înregistrările calității” sau „Politica organizației în domeniul managementului calității”.
Clasificarea proceselor este o etapă importantă în analiza activităților organizației. Unul dintre scopurile clasificării este definirea proceselor legate de sistemul calității organizației.
Modelul funcțional este format din două tipuri de elemente - blocuri funcționale și arce. În consecință, clasificarea proceselor reprezentate pe modelul funcțional se reduce la clasificarea blocurilor funcționale și a arcelor propriu-zise.
În cadrul modelului IDEF0, arcurile, în funcție de poziția lor pe diagramă, sunt deja subîmpărțite în 4 categorii: intrare, ieșire, control și mecanism.
În plus, arcurile pot fi clasificate în funcție de categoria de obiecte pe care le reprezintă în diagramă. Aceste categorii pot include:
Materiale, materii prime, produse, resurse;
Informații, date; înregistrări de calitate; documentele;
Ordine de management, planuri, grafice; acte administrative;
Standarde, documente de reglementare;
Executori responsabili, angajati ai organizatiei etc.
Pentru a selecta elemente de un anumit tip în modelul IDEF0, în timpul modelării sunt utilizate convenții pre-acordate privind stilul grafic de reprezentare a obiectelor din diferite categorii. Deoarece arcele din modelul IDEF0 sunt reprezentate de linii drepte și întrerupte, stilul grafic pentru arce include convenții pentru culoarea liniei, grosimea liniei, tipul de linie (solid, punctat, liniuță punctată etc.) și tipul vârfului de săgeată la sfârșit. arcuri.
De exemplu, arcele care se reflectă în cadrul modelului funcțional „Înregistrări de calitate” sunt afișate cu o linie continuă verde (Fig4).
De remarcat că stabilirea unei corespondențe între categoria unui obiect (de exemplu, înregistrări de calitate) și stilul grafic de reprezentare a acestui obiect (linia continuă verde) în modelul funcțional joacă nu doar un rol de prezentare. Cu ajutorul unui program de calculator, acest tip de relație poate fi procesat prin crearea de rapoarte speciale care să conțină, de exemplu, informații despre toate procesele care produc înregistrări de calitate la ieșire.
Notă. Stilurile grafice nu fac parte din metodologia IDEF0. Utilizarea stilurilor grafice pentru clasificarea proceselor a fost pentru prima dată propusă și implementată în sistemul IDEF0 / EMTool.
Blocurile funcționale din modelul IDEF0 pot fi clasificate în funcție de categoriile de procese pe care le reprezintă. În cadrul modelelor funcționale ale Regatului Unit, ar trebui utilizate categoriile de procese care sunt reglementate în IS ISO 9001: 2000.
Pentru a distinge procese dintr-o anumită categorie în modelul IDEF0, în timpul modelării, se folosesc convenții pre-acordate privind stilul grafic de reprezentare a blocurilor funcționale corespunzătoare în model, prin analogie cu convențiile pentru arce.
Abordarea procesuala, care sta la baza noii versiuni a IS ISO 9000: 2000, necesita utilizarea unor instrumente speciale pentru descrierea si clasificarea proceselor care alcatuiesc activitatile organizatiei.
Articolul arată că unul dintre astfel de instrumente poate fi metodologia de modelare funcțională IDEF0.
Utilizarea metodologiei IDEF0 pentru descrierea și clasificarea proceselor este susținută nu numai de capacitatea metodologiei de a rezolva această problemă în cadrul sistemului calității organizației, ci și de faptul că această metodologie este și un standard pentru modelarea funcțională în un număr de țări, inclusiv SUA și Rusia. Această din urmă împrejurare face posibilă utilizarea metodologiei IDEF0 ca limbă unică pentru schimbul de informații între organizații, auditori, experți.
Metodologia IDEF0 este susținută de programe de calculator. Utilizarea programelor de calculator în etapa de descriere a proceselor permite nu numai creșterea eficienței rezolvării acestei probleme, ci și utilizarea acestor modele în etapa managementului proceselor, integrându-le în sistemul informațional corporativ al organizației.
A. G. Kuryan, P. S. Serenkov
Procesul de modelare a afacerii poate fi implementat în cadrul diferitelor metodologii, care diferă în primul rând prin abordarea lor asupra a ceea ce este organizația modelată. În conformitate cu diverse idei despre organizație, se obișnuiește să se împartă metodologia în obiect și funcțional (structural).
Tehnici obiect consideră organizaţia modelată ca un ansamblu de obiecte care interacţionează – unităţi de producţie. Un obiect este definit ca o realitate tangibilă - un obiect sau un fenomen care are un comportament clar definit. Scopul acestei tehnici este identificarea obiectelor care compun organizatia, si repartizarea responsabilitatilor intre acestea pentru actiunile efectuate.
Tehnici funcționale Cea mai faimoasă dintre care este metodologia IDEF, o organizație este privită ca un set de funcții care transformă un flux de informații primite într-un flux de ieșire. Procesul de conversie a informațiilor consumă anumite resurse. Principala diferență față de metodologia obiectului constă într-o separare clară a funcțiilor (metode de prelucrare a datelor) de datele în sine.
Din punct de vedere al modelării afacerii, fiecare dintre abordările prezentate are propriile sale avantaje. Abordarea obiect vă permite să construiți un sistem care este mai rezistent la schimbări, se potrivește mai bine cu cele existente structuri organizatorice. Modelare funcțională se arată bine în cazurile în care structura organizatorică este în proces de schimbare sau este în general slab formată. Abordarea bazată pe funcții este intuitiv mai bine înțeleasă de artiști atunci când primesc informații de la aceștia despre munca lor curentă.
Metodologia IDEF0 poate fi considerată următoarea etapă în dezvoltarea cunoscutului limbaj grafic pentru descrierea sistemelor funcționale SADT (Structured Analysis and Design Technique). Din punct de vedere istoric, IDEF0 a fost dezvoltat ca standard în 1981, ca parte a unui program extins de automatizare industrială numit ICAM (Integrated Computer Aided Manufacturing). Familia de standarde IDEF își moștenește denumirea de la numele acestui program (IDEF = Icam DEFinition), iar ultima sa revizuire a fost lansată în decembrie 1993 de către Institutul Național de Standarde și Tehnologie din SUA (NIST).
Scopul tehnicii este de a construi diagrama functionala sistemul studiat, care descrie toate procesele necesare cu o acuratețe suficientă pentru modelarea fără ambiguitate a activității sistemului.
Metodologia se bazează pe patru concepte principale: bloc funcțional, arc de interfață, descompunere, glosar.
(Activity Box) reprezintă o funcție specifică în cadrul sistemului considerat. Conform cerințelor standardului, numele fiecărui bloc funcțional trebuie formulat în modul verbal (de exemplu, „a produce servicii”). În diagramă, blocul funcțional este reprezentat printr-un dreptunghi (Fig. 6.1). Fiecare dintre cele patru laturi ale unui bloc funcțional are propriul său sens specific (rol), în timp ce:
Orez. 6.1.
Arc de interfață(Săgeată) afișează un element de sistem care este procesat de un bloc funcțional sau afectează în alt mod funcția reprezentată de acest bloc funcțional. Arcurile de interfață sunt adesea denumite fluxuri sau săgeți.
Cu ajutorul arcurilor de interfață sunt afișate diverse obiecte care, într-o măsură sau alta, determină procesele care au loc în sistem. Astfel de obiecte pot fi elemente ale lumii reale (piese, mașini, angajați etc.) sau fluxuri de date și informații (documente, date, instrucțiuni etc.).
În funcție de ce parte a blocului funcțional se potrivește acest arc de interfață, se numește „inbound”, „outbound” sau „control”.
De menționat că orice bloc funcțional, conform cerințelor standardului, trebuie să aibă cel puțin un arc de interfață de control și unul de ieșire. Acest lucru este de înțeles - fiecare proces trebuie să urmeze niște reguli (afișate de arcul de control) și trebuie să producă un rezultat (arc de ieșire), altfel nu are sens să îl luăm în considerare.
Prezența obligatorie a arcurilor de interfață de control este una dintre principalele diferențe ale standardului IDEF0 față de alte metodologii ale claselor DFD (Data Flow Diagram) și WFD (Work Flow Diagram).
Descompunere(Descompunerea) este conceptul de bază al standardului IDEF0. Principiul de descompunere este utilizat atunci când descompune un proces complex în funcțiile sale constitutive. în care nivel de detaliu procesul este definit direct de modelator.
Descompunerea vă permite să reprezentați treptat și structurat modelul de sistem sub forma unei structuri ierarhice de diagrame individuale, ceea ce îl face mai puțin supraîncărcat și ușor de digerat.
Ultimul dintre conceptele IDEF0 este Glosar... Pentru fiecare dintre elementele IDEF0 - diagrame, blocuri funcționale, arcuri de interfață - standardul existent presupune crearea și menținerea unui set de definiții adecvate, cuvinte cheie, narațiuni etc. care caracterizează obiectul afișat de acest element. Acest set se numește glosar și este o descriere a esenței acestui element. Glosarul completează armonios limbajul grafic, oferind diagramelor informațiile suplimentare necesare.
Modelul IDEF0 începe întotdeauna cu prezentarea sistemului ca întreg - un singur bloc funcțional cu arcuri de interfață care se extind dincolo de zona considerată. Se numește o astfel de diagramă cu un bloc funcțional diagrama de context.
În textul explicativ la diagrama de context ar trebui specificat poartă(Scopul) construiți diagrama ca o scurtă descriere și comite Punct de vedere(Punct de vedere).
Determinarea și formalizarea obiectivului dezvoltării unui model IDEF0 este un punct extrem de important. De fapt, scopul identifică zonele relevante din sistemul studiat pe care ar trebui să se concentreze mai întâi.
Punctul de vedere definește direcția principală de dezvoltare a modelului și nivelul de detaliu necesar... O fixare clară a punctului de vedere vă permite să descărcați modelul, refuzând să detaliați și să studiați elementele individuale care nu sunt necesare, pe baza punctului de vedere ales asupra sistemului. Alegerea corectă a punctului de vedere reduce semnificativ timpul petrecut pentru construirea modelului final.
Alocarea subproceselor. În procesul de descompunere, un bloc funcțional, care în diagrama de context afișează sistemul ca întreg, este detaliat într-o altă diagramă. Diagrama de al doilea nivel rezultată conține blocuri funcționale reprezentând principalele sub-funcții ale blocului funcțional diagrama de context, și se numește copil (Child Diagram) în raport cu acesta (fiecare dintre blocurile funcționale aparținând unei diagrame copil, respectiv, se numește bloc copil - Child Box). La rândul său, blocul funcțional părinte se numește bloc părinte în raport cu diagrama copil (Parent Box), iar diagrama căreia îi aparține se numește diagramă părinte (Parent Diagram). Fiecare dintre sub-funcțiile diagramei copil poate fi detaliată în continuare printr-o descompunere similară a blocului funcțional corespunzător. În fiecare caz de descompunere a unui bloc funcțional, toate arcele de interfață care intră sau ies din acest bloc sunt fixate în diagrama copil. Acest lucru realizează integritatea structurală a modelului IDEF0.
Uneori, nu are sens să se ia în considerare în continuare arcurile individuale ale interfeței de nivel superior pe diagramele de la nivelul inferior sau invers - să reflecte arce individuale ale nivelului inferior pe diagramele de la niveluri superioare - acest lucru va supraîncărca diagramele și va face le este greu de înțeles. Pentru a rezolva astfel de probleme, standardul IDEF0 prevede conceptul de tunel. Notația „Arrow Tunnel” sub formă de două paranteze în jurul începutului arcului de interfață denotă că acest arc nu a fost moștenit din blocul părinte funcțional și a apărut (din „tunel”) doar în această diagramă. La rândul său, aceeași desemnare în jurul capătului (săgeata) arcului de interfață în imediata vecinătate a blocului de destinație înseamnă că acest arc este afișat și nu va fi luat în considerare în diagrama copil a acestui bloc. Cel mai adesea se întâmplă ca obiectele individuale și arcurile lor de interfață corespunzătoare să nu fie luate în considerare la unele niveluri intermediare ale ierarhiei - în acest caz, ele "se plonjează mai întâi în tunel" și apoi, dacă este necesar, "se întorc din tunel".
De obicei, modelele IDEF0 transportă informații complexe și concentrate, iar pentru a limita aglomerația lor și a le face lizibile, standardul adoptă constrângeri de complexitate adecvate.
Se recomandă reprezentarea pe diagramă de la trei până la șase blocuri funcționale, în timp ce numărul de arcuri de interfață potrivite pentru un bloc funcțional (lăsând un bloc funcțional) se presupune a nu depăși patru.
Standardul IDEF0 conține un set de proceduri care permit unui grup mare de oameni din diferite zone ale sistemului modelat să dezvolte și să convină asupra unui model. De obicei, procesul de dezvoltare este iterativ și constă din următoarele etape condiționate:
Ce merge la unitatea „la intrare”?
Pe baza prevederilor existente, a documentelor și a rezultatelor sondajului, este creată o schiță de model a modelului.
Vizibilitatea limbajului grafic IDEF0 face ca modelul să fie destul de lizibil pentru persoanele care nu au luat parte la proiectul de creare a acestuia, precum și eficient pentru organizarea de spectacole și prezentări. Pe viitor, pe baza modelului construit, se pot organiza noi proiecte menite să facă modificări în model.
