2000-ben a Nemzetközi Szabványügyi Szervezet (ISO) elfogadta a 9000-es szabványsorozat új változatát, amely tartalmazza a szervezet minőségbiztosítási rendszerére (QS) vonatkozó követelmények listáját.
A szabványok új változatának egyik alapvető különbsége a folyamatszemléletű menedzsment, valamint az SC létrehozása és működése.
A folyamatszemlélet fő gondolata a szabványok új verziójában a következőképpen foglalható össze:
A szervezet tevékenységét kölcsönható folyamatok hálózataként kell reprezentálni;
A szervezet tevékenységének irányítását a folyamatok hálózatának irányításán kell alapulnia.
Ez a cikk az IDEF0 funkcionális modellezési módszertanon alapuló megközelítést tárgyalja a szervezet folyamatainak leírására és osztályozására.
Az ISO 9000:2000 a folyamat következő definícióját használja:
„Összekapcsolt és kölcsönhatásban álló műveletek (műveletek) halmaza, amelyek a bemeneteket kimenetekké alakítják.
Megjegyzés 1. A folyamatok bemenetei általában más folyamatok kimenetei.
2. megjegyzés: A szervezetben a folyamatokat ellenőrzött körülmények között tervezik és hajtják végre, hogy hozzáadott értéket adjanak."
A legtöbb CS-szakértő egyetért abban, hogy a folyamatok leírásának legmegfelelőbb módja a grafikus ábrázolás. A szabvány új verziójában felvázolt folyamatszemlélet értelmezésére vonatkozó különféle dokumentumok különféle lehetőségeket kínálnak a folyamatok grafikus ábrázolására.
A folyamatleírásoknak nemcsak az egyes folyamatokat kell tükrözniük, hanem a folyamatok közötti kapcsolatokat és kölcsönhatásokat is.
A folyamatok a kapcsolatokkal és interakciókkal együtt a szervezet folyamathálózatát képviselik.
A szervezet tevékenységét alkotó folyamathálózat leírása összetett szervezési és technikai feladat, melynek megoldása speciális leírási és elemzési eszközöket igényel.
Ez a körülmény először a 70-es évek közepén valósult meg az amerikai légierő által megrendelt komplex projektek végrehajtása során. Ezzel egyidejűleg javasolták és megvalósultak az Integrált Számítógéppel Támogatott Gyártás (ICAM) program, melynek keretében különösen a rendszerek szerkezeti elemzésének módszertanát alkalmazták. Később ennek a megközelítésnek az alapján dolgozták ki az IDEF0 funkcionális modellezési módszertant, amelyet 1993-ban az Egyesült Államokban, 2000-ben pedig az Orosz Föderációban szövetségi szabványként fogadtak el.
Az IDEF0 funkcionális modellezési módszertanban a folyamat grafikus ábrázolására a következő jelölést alkalmazzuk (2. ábra).
Az IDEF0 módszertannak megfelelően a folyamatot funkcionális blokkként mutatjuk be, amely a bemeneteket kimenetekké alakítja, feltéve, hogy a szükséges erőforrások (mechanizmusok) ellenőrzött körülmények között rendelkezésre állnak.
A folyamatok kapcsolatait és kölcsönhatásait az IDEF0-ban olyan ívek ábrázolják, amelyek egyes funkcionális blokkok kimeneteit összekötik mások bemeneteivel.
A minőségbiztosítási rendszeren belüli folyamathálózati modellnek a következő kérdésekre kell választ adnia:
A szervezet tevékenységében milyen folyamatok kapcsolódnak a minőségügyi rendszerhez?
Mi ezeknek a folyamatoknak a szerkezete, beleértve a folyamatkimeneteket és a fogyasztókat, az inputokat és a beszállítókat stb.?
Hogyan hatnak egymásra a folyamatok?
Hogyan teljesülnek a folyamatokon belül az ISO 9000 sorozat 2000-es verziójában meghatározott követelmények?
Ahhoz, hogy a folyamathálózat funkcionális modellje ezekre és más kérdésekre is választ adjon az SC-n belül, további (az IDEF0 módszertanban megfogalmazottakon túl) követelményeknek megfelelően kell felépíteni.
Az alábbiakban felsoroljuk azokat a követelményeket, amelyeknek egy funkcionális folyamatmodellnek meg kell felelnie, még korántsem teljes:
A funkcionális modell a szervezet minőségügyi rendszerének irányítása szempontjából épül fel. Ezzel a megközelítéssel a modell minden olyan folyamatot és elemet tartalmaz, amely befolyásolja a végtermék és a folyamatok minőségét.
A funkcionális modellnek tartalmaznia kell az ISO 9000 sorozatú IS, 2000-es verzió követelményein belül kötelezőként meghatározott folyamatokat. Ezeknek a folyamatoknak a listája az MS ISO 9001:2000 szabványban található.
A funkcionális modellnek tartalmaznia kell az MS ISO 9000 sorozat 2000-es verziójában szabályozott elemeket (objektumokat). Az ilyen elemek listája itt található.
A funkcionális modellnek le kell fednie a termék életciklusának minden, a szervezet hatóköréhez kapcsolódó szakaszát.
Üzleti folyamat
Ahhoz, hogy a funkcionális modell megfeleljen a felsorolt követelményeknek, üzleti folyamatmodellként kell felépíteni.
Az üzleti folyamat folyamatok (műveletek, cselekvések) és a köztük lévő kölcsönhatások összessége, amelynek eredménye (outputja) a fogyasztóknak szállított termékek és/vagy szolgáltatások, inputjai pedig külső beszállítók által biztosított anyag-, információ- és munkaerőforrások.
Így a funkcionális üzleti folyamatmodell lefedi majd az életciklus-folyamatokat, valamint a kapcsolódó támogatási és irányítási folyamatokat, amelyek a szervezet tevékenységeinek részét képezik. Ez teljes mértékben megfelel az MS ISO 9000 2000-es verziójának követelményeinek.
Például egy varroda női kabátokat gyárt (varr), szerződéseket köt a fogyasztókkal. A termékek fogyasztói a női ruházati üzletek, valamint a kereskedelmi és közvetítő cégek. Az atelier alapanyagokat a fésült malmok, valamint kereskedelmi és közvetítő cégektől szerzi be. A szabóműhely üzleti folyamata a „Női kabátok gyártása” folyamat.
Szükséges folyamatok és elemek
Az MS ISO 9001:2000 szabványban a kötelező folyamatok a következők:
A felső vezetés felelősségének megvalósítása a minőségbiztosítási rendszeren belül;
Erőforrás-gazdálkodás (kiegészítő termelési folyamatok);
A fő termelési folyamatok (termék életciklus-folyamatok) menedzselése;
Az SC mérési, ellenőrzési és fejlesztési folyamatai.
A kötelező elemek a következők:
A szervezet politikáját, céljait tartalmazó dokumentumok a minőségirányítás területén;
A szervezet alkalmazottainak felelősségét tartalmazó dokumentumok (munkaköri leírások);
Minőségi jegyzőkönyvek stb.
Ennek megfelelően a funkcionális modellnek tartalmaznia kell minden kötelező folyamatot és elemet az ISO 9000 sorozatú IS, 2000-es verzió követelményeinek megfelelően.
Példánkban a varróstúdió üzleti folyamatának felépítése a következő (4. ábra).
Az ábrán (4. ábra) a folyamatot 4 egymásra ható folyamatként mutatjuk be. A 4 folyamat mindegyike kötelező az MS ISO 9001:2000 követelményeinek való megfelelés szempontjából.
A funkcionális blokkokat összekötő nyilak olyan elemeket (objektumokat) jelölnek, amelyek az egyik folyamat kimeneteiből a többiek bemenetére kerülnek. Különösen olyan folyamatelemeket képviselnek, amelyek az MS ISO 9000:2000 szempontjából kötelezőek, mint például a „Minőségi nyilvántartások” vagy a „Szervezeti politika a minőségirányítás területén”.
A folyamatok osztályozása fontos lépés a szervezet tevékenységének elemzésében. Az osztályozás egyik célja a szervezet minőségügyi rendszeréhez kapcsolódó folyamatok azonosítása.
A funkcionális modell kétféle elemből áll - funkcionális blokkokból és ívekből. Ennek megfelelően a funkcionális modellen bemutatott folyamatok osztályozása a tényleges funkcionális blokkok és ívek osztályozására redukálódik.
Az IDEF0 modell keretein belül az ívek a diagramon elfoglalt helyzetüktől függően már 4 kategóriába sorolhatók: bemenet, kimenet, vezérlés és mechanizmus.
Ezenkívül az ívek osztályozhatók a diagramon ábrázolt objektumok kategóriájától függően. Ezek a kategóriák a következőket tartalmazhatják:
Anyagok, nyersanyagok, termékek, erőforrások;
Információk, adatok; minőségi nyilvántartások; dokumentáció;
Vezetési megrendelések, tervek, ütemezések; adminisztratív dokumentumok;
Szabványok, normatív dokumentáció;
Felelős végrehajtók, a szervezet alkalmazottai stb.
Az IDEF0 modellben egy bizonyos típusú elem kiemelése érdekében a modellezés előre meghatározott konvenciókat alkalmaz a különböző kategóriájú objektumok ábrázolásának grafikai stílusában. Mivel az íveket az IDEF0 modellben egyenes és szaggatott vonalak ábrázolják, az ívek grafikai stílusa a vonal színére, a vonalvastagságra, a vonal típusára (folytonos, szaggatott, szaggatott pont stb.) és a végén lévő nyíl típusára vonatkozó konvenciókat tartalmaz. ívek.
Például a „Minőségi rekordok” funkcionális modell keretein belül tükröződő íveket egy zöld folytonos vonal jelzi (4. ábra).
Meg kell jegyezni, hogy az objektum kategóriája (például minőségi rekordok) és az objektum grafikus ábrázolási stílusa (zöld folytonos vonal) közötti megfelelés megállapítása a funkcionális modellben nem csak prezentációs szerepet játszik. Egy számítógépes program segítségével az ilyen kapcsolatok feldolgozhatók, speciális jelentések készíthetők, amelyek tartalmazzák például az összes olyan folyamatot, amely a kimeneten minőségi rekordokat generál.
Jegyzet. A grafikai stílusok nem részei az IDEF0 módszertannak. A folyamatok osztályozására szolgáló grafikus stílusok használatát először az IDEF0/EMTool rendszerben javasolták és implementálták.
Az IDEF0 modell funkcionális blokkjai az általuk képviselt folyamatkategóriák szerint osztályozhatók. Az SC funkcionális modelljein belül az MS ISO 9001:2000 szabványban szabályozott folyamatkategóriákat kell használni.
Annak érdekében, hogy az IDEF0 modellben egy bizonyos kategóriájú folyamatokat különítsen el, a modellezés előre meghatározott konvenciókat alkalmaz a megfelelő funkcionális blokkok modellben való ábrázolásának grafikus stílusára vonatkozóan, az ívekre vonatkozó konvenciókhoz hasonlóan.
Az MS ISO 9000:2000 új verziójának alapját képező folyamatszemlélet speciális eszközök alkalmazását igényli a szervezet tevékenységeit alkotó folyamatok leírására és osztályozására.
A cikkből kiderül, hogy az egyik ilyen eszköz lehet az IDEF0 funkcionális modellezési módszertan.
Az IDEF0 módszertan alkalmazása mellett a folyamatok leírására és osztályozására nemcsak az a képessége, hogy a módszertan képes megoldani ezt a problémát a szervezet minőségi rendszerén belül, hanem az is, hogy ez a módszertan a funkcionális modellezés szabványa is számos országban. beleértve az USA-t és Oroszországot is. Ez utóbbi körülmény lehetővé teszi, hogy az IDEF0 módszertant a szervezetek, auditorok és szakértők közötti információcsere közös nyelveként használják.
Az IDEF0 módszertant számítógépes programok támogatják. A számítógépes programok használata a folyamatok leírásának szakaszában nemcsak a probléma megoldásának hatékonyságának növelését teszi lehetővé, hanem e modellek használatát a folyamatmenedzsment szakaszában is, integrálva őket a szervezet vállalati információs rendszerébe.
A. G. Kurjan, P. S. Serenkov
Bevezetés
Az oroszországi biztosítási üzletág sikere teljes mértékben az automatizálás szintjétől függ.
Ma már nem kell meggyőzni a gépjármű-biztosítás előnyeiről és szükségességéről. A lakosság intenzív motorizálása mellett a legmeggyőzőbb érvek a biztosítás mellett a közlekedésrendészet napi jelentései a közlekedési balesetek és autólopások számáról. Egyre több sofőr a legjobbat remélve érzi magát magabiztosabban az úton, csak az autóbiztosításnak köszönhetően. De a biztosításnak, nem csak az autóbiztosításnak, információs támogatásra van szüksége. Nyilvánvaló, hogy a biztosítási tevékenység egységes információs térének sikeres kialakításához különféle szupersztrádák kompatibilitása szükséges. Ennek egyik lehetséges megközelítése az elektronikus interakció szabványosítása. · A biztosítás a gazdaságra gyakorolt pozitív hatás, valamint a jogi személyek és magánszemélyek véletlen veszélyekkel szembeni biztosítási védelmének erőteljes tényezője, merev, többszintű biztosítási folyamatirányítási rendszeren alapul, információs szolgáltatást és támogatást igényel. A biztosítási tevékenység folyamata különféle funkcionális feladatok megoldását biztosítja, kezdve a megkötött biztosítási szerződések lebonyolításától, azok jogi és tartalmi vonatkozásairól az IS-ben történő információmegjelenítésen át egészen a számviteli és statisztikai adatszolgáltatás kialakításáig, a biztosítási szerződések előkészítéséig. vezetői döntések meghozatala, ami a munkaigényes információs folyamatok automatizálását igényli. · A biztosítási területen működő funkcionális problémák megoldására szolgáló információs támogatás jellemzői, a társaságok, fióktelepek, biztosítási tevékenységgel foglalkozó szakemberek munkaállomásainak területi koncentrációja, meghatározta a számítógépek és az ebben az iparágban alkalmazott szakemberek információs interakciójának kommunikációs eszközeinek használatának szükségességét. · Az AIT létrehozásának és használatának gyakorlata a biztosítási tevékenységekben megerősíti egy elosztott információs és számítástechnikai hálózat vagy többszintű hálózat működtetésének megvalósíthatóságát, amely egyetlen technológiai platformot biztosít közös információs bázissal a fájlszerverrel és más hálózatokkal való interakcióhoz. erőforrások.
A kurzusprojekt célja a kiválasztott tantárgyi terület információs rendszerének kezdeti tervezésének elvégzése. A kifejlesztett IS-nek támogatnia kell a szervezet egy meghatározott tevékenységének végrehajtását, és biztosítania kell az ehhez a tevékenységhez kapcsolódó, funkcionálisan összefüggő műveletek sorának végrehajtását. Ebben az esetben figyelembe kell venni az ügyfelek biztosításának folyamatát, a biztosítási kártérítés kifizetését és a megfelelő IS kialakítását.
A cél elérése érdekében a következő feladatokat tűztük ki a tanfolyami projekt megvalósítása előtt:
Vegye figyelembe a vállalkozás tárgykörét;
Tanulmányozni az IS tervezési módozatait és különféle típusú adatmodelleket kidolgozni;
Végezze el az IS logikai és fizikai tervezését;
Válassza ki a megfelelő architektúrát a kérdéses rendszerhez.
A vizsgálat tárgya a "Rosgosstrakh" biztosítótársaság.
Elméleti rész
1.3 ügy-eszközökAllFusionFolyamatmodellező
Az AllFusionProcessModeler (a továbbiakban: BPwin) egy üzleti folyamatok modellezésére szolgáló CASE eszköz, amely lehetővé teszi diagramok készítését IDEF0, IDEF3, DFD jelölésekkel. A modellezés során a BPwin lehetővé teszi, hogy a modell bármely ágán IDEF0 jelölésről IDEF3 vagy DFD jelölésre váltson, és vegyes modellt hozzon létre. A BPwin támogatja a funkcionális értékelemzést (ABC).
A programmal való munka egy új modell létrehozásával kezdődik, amelyhez meg kell adni a nevet és a típust (1. ábra).
1. ábra - Új modell létrehozása
A modelltípus megválasztása határozza meg azt a jelölést, amelyben a munkafelbontás elvégezhető. Tehát, ha az Üzleti folyamat (IDEF0) típust választja, akkor a létrehozott modellben IDEF0, IDEF3 és DFD jelölésekben végezhet munkabontást; ha a DataFlow (DFD) típus van kiválasztva - DFD és IDEF3 jelölésekben; ha a Process Flow (IDEF3) típust választjuk, akkor csak az IDEF3 jelölésben.
A modell nevének megadása és típusának kiválasztása után a BPWin azonnal felszólítja a modell paramétereinek beállítására (2. ábra):
2. ábra - A modell tulajdonságainak beállítására szolgáló ablak
Számozás - a művek és diagramok számozási formátuma és diagramokon való megjelenítésének sorrendje;
Kijelző – a diagramon megjelenített elemek listája;
Layout - elrendezési paraméterek;
ABC Units - a funkcionális költségelemzés egységei;
PageSetup - oldalbeállítások;
Fejléc/lábléc – fejléc és lábléc opciók.
A modell tulajdonságainak beállítása után megjelenik a fő program ablak (3. ábra), amely három fő részből áll:
3. ábra - A program fő ablaka
1 Model Explorer (ModelExplorer) - megjeleníti a modell szerkezetét (rendelkezésre álló diagramok és hierarchiájuk);
2 Fő rész - megjeleníti azokat a diagramokat, amelyekkel dolgozik;
3 eszköztár, amelyek közül a legérdekesebb a ModelToolbox eszköztár.
Jegyzet. Az alapértelmezett beállításokkal létrehozott modellben az orosz karakterek hibásan jelennek meg. Ennek a hiányosságnak a kiküszöbölése érdekében szükséges a modellben használt betűtípusok javítása. Ehhez a Modell ->DefaultFonts menüben egymás után végig kell menni az összes elemen (4. ábra), a Script legördülő listában kiválasztani a cirill értéket és be kell jelölni az Összes módosítása jelölőnégyzetet.
előfordulások (5. ábra).
4. ábra - A betűtípus-beállításokért felelős menüelemek
5. ábra - Betűtípus-beállítások
ModelToolbox eszköztár.
Ez az eszköztár felelős a modell különböző grafikai elemeinek létrehozásáért. Az aktuális diagram típusától függően változik a rajta lévő gombkészlet.
1. táblázat – A ModelToolbox gombok nézete és célja
|
Gomb nézet |
Gomb neve |
Gomb hozzárendelés |
|
|
A kurzort mutató nyíllá változtatja úgy, hogy hogy ki tudjunk választani tárgyakat |
|||
|
IDEF0 - DFD - IDEF3 |
Új munka hozzáadása a diagramhoz |
||
|
PrecedenceArrowTool |
Új nyíl hozzáadása a diagramhoz |
||
|
Egy nyíl nevének társítása magával a nyíllal |
|||
|
Szöveg hozzáadása diagramhoz |
|||
|
DiagramDictionaryEditor |
A Diagramkezelő ablak meghívása megtekintéshez elérhető diagramok típusonként, és lépjen a következőre kiválasztott |
||
|
GotoSiblingDiagram |
Átmenet a szabványos diagramok között, csomópont fa és FEO diagram |
||
|
GotoParentDiagram |
Navigáljon a Szülő diagramhoz |
||
|
GotoChildDiagram |
Navigáljon a gyermekdiagramhoz |
||
|
ExternalReferenceTool |
Külső entitás hozzáadása egy diagramhoz |
||
|
Adattár hozzáadása diagramhoz |
|||
|
Egy kereszteződés hozzáadása a diagramhoz |
|||
A létrehozott modell már tartalmaz egy kontextusdiagramot egyetlen feladattal („fekete doboz”) a modellkészítési szakaszban kiválasztott jelölésben. Most nevet kell adnia ennek a munkának, és ha szükséges, be kell állítania a tulajdonságait. Ehhez meg kell hívni a job tulajdonságai ablakot, rá kell kattintani duplán az egérrel (6. ábra).
6. ábra - Munka tulajdonságai ablak
Ezután nyilakat kell elhelyeznie a diagramon. Ehhez nyomja meg a PrecedenceArrowTool gombot a ModelToolboxon (a kurzor egy nyíllal ellátott kereszt alakban jelenik meg), kattintson arra a helyre, ahová a nyílnak mennie kell, majd kattintson arra a helyre, ahová a nyílnak kell mennie (a BPwin kiemeli ezeket a helyeket, ha föléjük viszi az egérmutatót). A nyíl elnevezéséhez kattintson a PointerTool gombra a ModelToolboxban, majd kattintson duplán a nyílra. A megjelenő ArrowProperties ablakban a feladat nevét be kell írni a Nyílnév mezőbe, vagy kiválasztani a rendelkezésre álló nyílnevek listájából.
Miután elhelyezte a nyilakat az ábrán, bonthatja a munkáját. Ehhez kattintson a GotoChildDiagram gombra a ModelToolboxon, majd kattintson a felbontani kívánt munkára. Megjelenik egy ablak, amelyben ki kell választania, hogy melyik jelölést használja a bontáshoz és a gyermekfeladatok számát (7. ábra).
7. ábra - Gyermek diagram létrehozása
Az utóddiagram létrehozása után a BPwin automatikusan létrehozza a megadott számú feladatot, és szegélynyilakat helyez el a diagram szélein. Ezután kapcsolja össze a határnyilakat a munkabemenetekkel (ha szükséges, új határnyilakat is hozzáadhat), és kapcsolja össze a feladatokat. A művek további bontása hasonló módon történik.
Gyakorlati rész
2.2 Phasználatának előnyeiAllFusionfolyamatModellező
A folyamatmodellezők keretet biztosítanak az üzleti folyamatok megértéséhez és bizonyos események hatásának értékeléséhez, valamint a folyamatok és az információáramlások kölcsönhatásának leírásához a szervezetben.
2.3 Üzleti modellek építése- folyamatokat
Az All Fusion Process Modeler CASE eszközzel üzleti folyamatok modellezésére a következők készültek:
9. ábra - Fogalmi modell
11. ábra - Az adatmodell 3. szintje
12. ábra - A funkcionális adatmodell fája
Kifejezések és rövidítések listája
Az üzleti folyamat egymással összefüggő tevékenységek vagy feladatok összessége, amelyek célja egy adott termék vagy szolgáltatás létrehozása a fogyasztók számára. Az egyértelműség kedvéért az üzleti folyamatokat egy üzleti folyamat folyamatábra segítségével jelenítjük meg.
Az információs rendszer olyan információfeldolgozó rendszer, amely az információkat biztosító és elosztó szervezeti erőforrásokkal, például emberekkel, létesítményekkel és pénzügyi erőforrásokkal együtt működik.
Következtetés
Tehát a kötelező biztosításról szóló szövetségi törvény fő célja az áldozatok jogainak védelme az életükben, egészségükben vagy vagyonukban okozott károkért. A Törvényben foglalt valamennyi jogi norma a kitűzött cél elérésére irányul. Ennek érdekében a törvény meghatározza a szükséges jogi, gazdasági és szervezeti intézkedések összességét, amelyek célja a gépjármű-tulajdonosok kötelező felelősségbiztosításával kapcsolatos viszonyok átfogó szabályozása.
A gépjármű-tulajdonosok felelősségbiztosítási szerződései szerinti kárrendezés világgyakorlata azt mutatja, hogy a biztosítók által teljesített összes kifizetés több mint 2/3-a anyagi (vagyoni) kárt jelent. Ezért az OSAGO rendszer oroszországi fejlesztése és az ilyen típusú biztosításba vetett közbizalom növelése érdekében az áldozatok tulajdonában okozott károk összegének meghatározása és a biztosítási kifizetések kifizetése során felmerülő problémák időben történő megoldása érdekében. egy baleset különösen fontos. A gépjármű-tulajdonosok kötelező felelősségbiztosítására vonatkozó hatályos jogszabályok szükséges módosításai hozzájárulnak a törvény értelmének helyes megértéséhez, a biztosítási jogviszonyokban résztvevők általi következetes végrehajtásához és a joghatósági gyakorlatban történő alkalmazásához.
A BPI ciklus a „The Right Way” vállalat funkcionális modelljének kidolgozásán és megvalósításán alapul. A SADT (Structured Analysis and Design Technique – a szerkezeti elemzés és tervezés módszertana) szempontjából a modell akár egy vállalkozás üzleti folyamataira, akár annak objektumaira fókuszálhat. Az üzleti folyamatokra összpontosító SADT-modelleket funkcionális modelleknek (IDEF0 szabvány), az objektumorientált (IDEF1 szabvány) adatmodelleknek nevezzük. A funkcionális modell az üzleti folyamatok rendszerét reprezentálja a szükséges részletességgel.
Az „As It Should” modell (IDEF0 szabvány) lebontásának első és második szintje az ISO 9000:2000 sorozat elemei és alelemei alapján alakul ki. Lásd a 7.1. ábrát. Az "As It Should" modell következő bontási szintjei az adatáramlási modell alapján alakulnak ki (amelyet az ERP szabvány és az "As is" modell elemzése alapján terveztek).
Az „As It Should” modell IDEF0 diagramok felhasználásával készült, és a következők jellemzik:
Olyan blokkok átalakítása, amelyek a bemeneti adatfolyamot kimeneti adatfolyammá alakítják a mechanizmusok segítségével végzett vezérlési műveletek hatására.
Az áramlási modellben leírt anyag-, információ- és pénzügyi áramlások
Rizs. 7.1: A vállalkozás fő elemei
adat. Az információáramlás három csoportra osztható:
1. A korlátozó tájékoztatást törvények, szabályzatok tartalmazzák; nemzetközi, állami és ipari szabványok; a cég részlegeinek munkáját szabályozó minőségügyi rendszer dokumentálása; Ezt az információáramlást a transzformációs blokkon vezérlő műveleteknek tekintjük.
2. A leíró információkat rajzok, műszaki és egyéb leírások, részletek stb. tartalmazzák. dokumentumok, amelyek szerves részét képezik a termék teljes életciklusa során.
3. Előíró információ - információ arról, hogy a bemeneten lévő objektumot hogyan, milyen feltételek mellett és milyen szabályok szerint kell átalakítani az átalakító blokk kimenetén lévő objektummá.
A szabályozási modellben leírt, szervezetire osztott mechanizmusok,
És műszaki, a vállalkozás információs rendszerét meghatározó (ERP osztályú IS).
Ellenőrzési műveletek, amelyek például lehetnek minőségbiztosítási rendszer dokumentumai.
A funkcionális modellezés („Ahogy kell” modell) a korábban kidolgozott (ISO 9000 szabványon alapuló) adatfolyam-modellből a műveletek és folyamatok általánosítására, valamint a minőségbiztosítási rendszer dokumentációjának grafikus vázának megtervezésére redukálódik, mint az egyik ellenőrzési művelet.
1. A funkcionális modell a következő:
2. Az adatmodell a következő:
3. Az IDEF0 szabvány által leírt SADT modell a következő:
objektum orientált modell. üzleti folyamat-orientált modell;
4. Az IDEF1 szabvány által leírt SADT modell a következő:
üzleti folyamat-orientált modell; objektum orientált modell.
5. A "The Right Way" modellt a következők jellemzik:
szinkronizálási blokkok; funkciók; mechanizmusok;
irányító hatások.
anyag-, információ- és pénzügyi áramlások;
átalakító blokkok;
6. Az információáramlások a következő csoportokba sorolhatók:
leíró információk; korlátozó információk; előíró információk. részletes információk; engedély információ;
Szerzett pontok
8 Bomlási illeszkedés IDEF0-blokkok minőségbiztosítási rendszer dokumentációjának fejlesztésével
Az „As It should” modellben az átalakító blokkok hierarchikus alárendeltségi viszonyban állnak: tevékenység - folyamat - részfolyamat - művelet - cselekvés. Lásd a 8.1. ábrát.
Minden egyes transzformációs blokkot egy mechanizmus és vezérlési műveletek hajtanak végre. A mechanizmusok a vállalkozás tevékenységét támogató szervezeti és technikai struktúrák, információs rendszerek (a szervezeti és technikai struktúra a normatív modell megtervezésekor kerül meghatározásra, amelyet később az adatáramlási modellben is felhasználnak).
Az IDEF0 módszertan szerint minden egyes transzformációs blokkot vezérléssel hajtanak végre (korlátozó és előíró információk).
Az előíró információkat az „As is” modell és az ERP-szabványok határozzák meg, és nem képezik az „As It should” modell megtervezésének tárgyát, míg a korlátozó információk (minőségi rendszer dokumentációja) igen. Így az „As It Should” modell megtervezésének eredménye a minőségügyi rendszer dokumentációjának grafikus váza lesz, amely bizonyos kritériumokkal rendelkezik a dokumentáció minőségének értékeléséhez.
Az „As It should” modellben az átalakítási blokkok a minőségbiztosítási rendszer dokumentációjához kapcsolódnak:
Rizs. 8.1: Transzformációs blokkok a "The Right Way" modellben
1. Tevékenység - üzleti folyamatok halmaza, amely az „As It Should” modell nulla szintjét jellemzi. A tevékenység a külső környezet (állam, társadalom) által ellenőrzött mechanizmusok, például az ISO 9001:2000 szabvány segítségével a bemeneti folyamokat kimeneti folyamokká alakítja át.
2. Folyamat. Az „As It Should” modell első szintű bontásának transzformációs blokkjai megfelelnek az ISO 9001:2000 sorozat elemeinek.Minden folyamatnak megvan a célja. Valamennyi folyamat céljának elérése biztosítja az „As It Should” modell megvalósítását, és ezáltal a vállalkozás magasabb BPI-szintre való átállását. A folyamatokat a minőségügyi kézikönyvben leírt meghatározott céloknak megfelelően hajtják végre.
3. Alfolyamatok. A „The Right Way” modell második szintjének transzformációs blokkjai az ISO 9001:2000 sorozat részelemeinek felelnek meg, a folyamat célja alapján minden benne szereplő részfolyamathoz cél kerül meghatározásra. A részfolyamatok a minőségügyi kézikönyvben leírt meghatározott céloknak megfelelően zajlanak.
4. Művelet - egymás után vagy párhuzamosan végrehajtott műveletek halmaza. A művelet végrehajtása:
a MIK-ek (módszeres minőségi utasítások) szerint, amelyek a vállalkozás minőségügyi rendszerének harmadik szintű dokumentálása;
az erőforrások fogyasztásával;
az egyéb műveletek és a külső környezet korlátozásaira (az ellenőrzési intézkedésekre is figyelemmel).
Az „Erőforrás-menedzsment” és „Termékértékesítés” üzleti folyamatokhoz kapcsolódó műveletek az adatfolyam-modellben vannak meghatározva (az „As is” modell és az ERP elemzése alapján
darts). Így a működés szintjén az ISO 9001:2000 szabvány ipari ERP szabványokkal van dokkolva.
5. Akció. A cselekvések a műveletek dekompozíciójának eredményei. Az intézkedést a minőségbiztosítási rendszer utasításai szerint hajtják végre.
Az „Ahogy kell” modell megvalósítását a folyamatok céljainak integrált megvalósítása biztosítja. Az egyes folyamatok céljának elérése a folyamatot alkotó részfolyamatok céljainak átfogó megvalósítása révén lehetséges. Az egyes részfolyamatok céljának elérése a működési célok átfogó megvalósításán keresztül, stb.
Így az „Ahogy kell” modell megvalósítása minden munkahelyen meg van határozva, és a minőségbiztosítási rendszer dokumentációjának felhasználásával, valamint a mechanizmusok (IS, személyzet), folyamatok és adatfolyamok interakciójával történik. információs, anyagi, pénzbeli). Az „As It Should” modell bevezetését egy modern információs technológiákon alapuló integrált vállalatirányítási rendszer segíti elő, például az ERP osztályba tartozó IS.
9 Modellezési problémáküzleti folyamatok menedzselése
Az üzleti folyamatok modellezése során, mint az IDEF (Integration definition for function modeling) módszertanon alapuló vállalatvezetői tevékenység támogatásának egyik eszköze, két probléma merül fel.
Az első a szabványok és az ebből eredő modellek használata a szervezet irányítására. Az üzleti folyamatok modellezése vagy az ERP osztályba tartozó információs rendszer megléte nem elegendő az irányítási folyamat hatékony támogatásához, ha a vezető nem tűzi ki feladatul az „üzleti folyamatba való beépítést”.
A második probléma az első következménye, és a kidolgozott modellek vállalatvezetőknek történő bemutatásához kapcsolódik. A probléma nem az IDEF módszertani összetettségében van, hanem a sémák kifejezőképességében, amikor nagyszámú résztvevő rövid időn belül megvitatja és meghozza a döntéseit (az előadás kötetében).
Egy kép többet ér ezer szónálnépi bölcsesség
Munkám során gyakran nem csak egy bizonyos probléma tanulmányozására és megoldására van szükség, hanem annak a helyének meghatározására is a vállalat általános modelljében. Nem elég megérteni, hogy egy bizonyos egység nem működik megfelelően, fontos megérteni, hogyan működik együtt másokkal. Ellenkező esetben lehetetlen azonosítani az összes meglévő problémát, és kiválasztani a legjobb módszert a probléma megoldására. Ehhez tanulmányoznia kell a vállalat munkáját és fel kell dolgoznia annak funkcionális modelljét.
Természetesen elméletben a vezetőnek rendelkeznie kell egy funkcionális modellel a cég munkájáról, és nem mindegy, hogy a raktár vagy az informatikai rendszer felépítéséről beszélünk vezetéstől kérésig. De a valóságban ez szinte soha nem derül ki, ezért az ügyfél által kitűzött feladatra való tanulmányozás és megoldás keresése során elkészítem a vállalat vagy egy bizonyos folyamat (funkció) funkcionális modelljét is. saját.
És kezdésként tegyünk egy rövid kitérőt a történelembe. Térjünk vissza a távoli 1877-be, az orosz-török háború idején. A Sytin nyomtató ekkor használt először grafikát a katonai műveletek leírására. Most mindez ismerős számunkra, bármilyen csata leírásakor nyilakkal ellátott kártyák jelennek meg a szemünk előtt, amelyek egyértelműen mutatják a csata menetét. És akkoriban a katonai műveleteket szavakkal írták le. Minden harchoz - sok-sok szó. És nagyon nehéz volt a végén megérteni, mi történik.
Ezért volt Sytin ötlete valóban forradalmi – elkezdte nyomtatni a térképek litográfiai másolatait az erődítmények és a katonai egységek helyszíneinek megjelölésével. Ezeket a kártyákat „Újságolvasóknak. Haszon". Az ötlet annyira aktuálisnak bizonyult, hogy a „Súgó” legelső példányszáma azonnal elfogyott. És akkor az ilyen alkalmazásokra nagy volt a kereslet. Az ok nyilvánvaló. A grafika segített megérteni azt, amit szinte lehetetlen kitalálni pusztán szavak segítségével.
A verbális leírások tehetetlenségére a saját gyakorlatomból is tudok hasonló példát felhozni. Egyik ügyfelem megkért, hogy vállaljam el cége ERP rendszerének bevezetését. Arra a kérdésre, hogy van-e valamilyen technikai feladatuk, azt a választ kaptam: „Igen, van. De 400 oldala van." Ugyanakkor az ügyfél nagyon panaszkodott, hogy kollégáim, akikkel korábban megkeresett, vagy teljesen visszautasították a projektet, vagy egyértelműen felfújt árakat neveztek. Miután láttam, hogy a feladatkör valóban 400 oldalas, és kizárólag szöveges leírásból áll, megértettem a fejlesztők viselkedésének okait. Egy ilyen kötetnyi szöveg elolvasása, elmélyülése, minden árnyalat megértése csak a feladat megértéséhez és az ár megnevezéséhez valóban nagyon nehéz.
Felajánlottam ennek az ügyfélnek egy alternatív lehetőséget - mindent, ami lehetséges, grafikusan leírni jelölések formájában. Példákat mutatott neki a modellkedésre. Ennek eredményeként most újragondolják kívánságaikat és a feladatmeghatározás kialakítását.
Sok más példát is ismerek arra, amikor az üzleti folyamatok grafikus modellezése segítette mind a kollégáim, mind az üzleti tanácsadók és fejlesztők, mind az üzletemberek munkáját.
A jelenlegi helyzet tanulmányozása után, mint bármely más külső szakértő, kereskedelmi ajánlatot készítek, amelyben a lehető legrészletesebben feltárom a jelenlegi helyzetről alkotott elképzelésemet, valamint a szükséges lépéseket. megoldja a feladatot, és természetesen a várt eredményt.
Az ilyen munkafelmérési jelentések terjedelmesek, több oldalt is elfoglalnak, ami egyrészt szükséges, másrészt megnehezíti az észlelést. Eleinte, mint sokan mások, arra gondoltam, hogy jó a terjedelmes beszámoló, mert az ember fizet a munkáért, és minél részletesebb tájékoztatást kell adni neki.
Amikor papíron vagy különböző programokban modelleznek, a felhasználók gyakran különböző színek használatával próbálják növelni a láthatóságot. Ez az egyik leggyakoribb hiba. Valójában a többszínű nyilak és blokkok használata csak további zavart okoz, és torzítja a séma észlelését.
A modellnek fekete-fehérben olvashatónak kell lennie, további színséma nélkül. Ez a megközelítés egyszerre segít elkerülni a félreértéseket és fegyelmezi a modell készítőjét, ennek eredményeként növekszik a modell olvashatósága és műveltsége.
A legjobb megoldás a probléma megértéséhez elegendő részletezés, és semmi több. Egy-egy folyamat részletes nézetének kiválasztásakor az egyes részlegek vagy akár egy alkalmazott munkájának részletes részletei derülhetnek ki. Ilyen struktúra pedig csak akkor jön létre, ha valóban szükséges a munkához vagy a döntéshozatalhoz.
Hasonlóképpen, ha úgy döntök, hogy hozzáadok egy blokkot, fontos megbizonyosodnom arról, hogy az is rendelkezik az összes szükséges attribútummal. Itt nagyon fontos a körültekintés, mert az összetett üzleti folyamatok modellezésekor a modell egyik részének változása egy másikban is változást eredményezhet. Be kell őket adni.
Leggyakrabban a blokkok elnevezésekor követnek el hibákat. Például a "Cikket hozzon létre" helyett azt írják, hogy "Cikket hozzon létre". Ebben a megközelítésben a blokkok cselekvések, ezért mindig igéknek kell lenniük.
Ugyanakkor úgy gondolom, hogy az üzleti elemző nem egészen szakma, minden üzletvezető vagy valamilyen rendszer fejlesztője üzletelemzéssel foglalkozik, aki elemzi az üzletet és a leghatékonyabb rendszer felépítésére törekszik. Ezeknek az embereknek és ezeknek a céloknak a célja az IDEF0 eszköz.
Ezért nagyon fontos, hogy a funkcionális üzleti modell összeállításakor folyamatosan konzultáljon a vállalat vezetőjével, hogy ne kövessen el olyan hibákat, amelyek automatikusan hibákhoz vezetnek a bomlás szakaszaiban. Ezenkívül a későbbi szakaszokban további jóváhagyásokra lehet szükség a strukturális részlegek vezetőitől és az alkalmazottaktól. Csak akkor hajthat végre néhány változtatást és javaslatot, ha „ahogy van” funkcionális modellje valóban tükrözi a dolgok valós állapotát. És ahhoz, hogy az ilyen munkában magas színvonalú eredményeket érjen el, mindenekelőtt gyakorlati tapasztalatra és egy adott típusú vállalkozás jellemzőinek ismeretére van szükség.
További cikkek ebben a témában.
A biztosítótársaságok pénzügyi közvetítők, amelyek biztosítási szolgáltatások nyújtására szakosodtak. Tevékenységük abban áll, hogy jogi személyekkel és magánszemélyekkel kötött megállapodások alapján (biztosítási kötvények értékesítése révén) speciális készpénzalapokat hoznak létre, amelyekből a kötvénytulajdonosok részére a meghatározott összegű készpénzkifizetéseket teljesítik, amennyiben a kötvények előfordulnak. bizonyos események (biztosítási események).
Ha ez a munka nem felel meg Önnek, az oldal alján található a hasonló művek listája. Használhatja a kereső gombot is
Bevezetés…………………………………………………………………..…………3
1. .….5
1.1. Egy biztosító társaság tevékenységének gazdasági elemzése
Sogaz-Med JSC…………………………………………………………………..5
1.2. Az OJSC "Sogaz-Med" biztosító társaság dokumentumforgalmának értékelése ... ..7
1.3. Funkcionális modell kidolgozása „ahogy van”……………………..10
2. Adatbázis tervezése a Sogaz-Med OJSC biztosítótársaság számára…………………………………….16
2.1. Funkcionális modell kidolgozása „ahogy lennie kell”…………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………….
2.2. Logikai-fizikai modell kidolgozása……………………………………16
3. Adatbázis fejlesztése a JSC "Sogaz-Med" cég számára………………………19
3.1. Szoftverkörnyezet kiválasztása adatbázis-fejlesztéshez……………………
3.2. Az adatbázis fejlesztése során használt főbb funkciók, eljárások... (lekérdezés rendezésre, szűrésre stb.)
3.3. Alkalmazás tesztelése……
Következtetés…………………………………………………………………………..25
Hivatkozások……………………………………………………………………..26
Pályázatok……………………………………………………………………………..28
Bevezetés
A modern körülmények között megnő az információs rendszerek jelentősége, amelyek lehetővé teszik a döntéshozatali folyamatok információs támogatását. Az adatbázisok a legtöbb információs rendszer egyik fő elemei.
Egy olyan témakört tekintve, mint egy biztosító tevékenysége, természetesen nem nélkülözhető az információk adatbázisba rendezése.
Biztosító társaságok - Ezek olyan pénzügyi közvetítők, amelyek biztosítási szolgáltatások nyújtására szakosodtak. Tevékenységük abban áll, hogy jogi személyekkel és magánszemélyekkel kötött megállapodások alapján (biztosítási kötvények értékesítése révén) speciális készpénzalapokat hoznak létre, amelyekből a kötvénytulajdonosok részére a meghatározott összegű készpénzkifizetéseket teljesítik, amennyiben a kötvények előfordulnak. bizonyos események (biztosítási események).
A biztosító nagyon sok információval dolgozik, mind az alkalmazottakról, mind az ügyfelekről. Ehhez egy közös adatbázisra van szükség, amely minden szükséges információt tartalmaz. Ez nagyon felhasználóbarát, és szükséges a folyamat automatizálásához.Ezért az oroszországi biztosítási üzletág automatizálása nagyon ígéretes, sok hazai biztosítótársaság csak a közelmúltban kezdett el komolyan gondolkodni a komplex vállalati rendszerek telepítésének szükségességéről.
A relevancia abban rejlik, hogy a számítástechnika alkalmazásának fő oka az osztályon áthaladó nagy mennyiségű információ. A biztosítók tevékenységének automatizálása megkönnyíti a szerződések adatbázisának karbantartását és gyorsítja az ahhoz való hozzáférést, leegyszerűsíti a jelentési dokumentáció elkészítését, ezáltal növeli a munka termelékenységét. A hátrányok is kiküszöbölhetők, mint például az információk megbízhatóságának ellenőrzésének nehézsége (kézi kitöltéskor nagy a hibák, kihagyások valószínűsége), egyes mutatók számológéppel történő kiszámításának szükségessége és nem megfelelő pontossága.
A kurzusprojekt célja a "Sogaz-Med" OJSC "Biztosítási populáció" adatbázisának fejlesztése Delphi 7.0 környezetben.
Tárgy: JSC "Sogaz-Med" biztosítótársaság
Feladatok:
1. A JSC "Sogaz-Med" biztosító társaság tevékenységének elemzése
OJSC "Sogaz-Med"
Az OJSC Sogaz-Med egészségbiztosító 1998-ban a Gazprom leányvállalataként alakult Gazprommedstrakh néven, 2003 nyarán a biztosítási üzletág konszolidációja keretében a Sogaz csoportba került.
A JSC "Sogaz-Med" fő céljai és célkitűzései: az egészségügyi támogatási rendszer fejlesztése, az egészségügyi ellátás megszervezése és minőségének ellenőrzése, az orvosi támogatásra elkülönített pénzeszközök ésszerű felhasználása, valamint a biztosítottak jogainak védelme.
Az OJSC "Sogaz-Med" a kötelező egészségbiztosítás (CHI) végrehajtására szakosodott. 2013 végén a társaság a 2. helyet szerezte meg az orosz egészségügyi biztosítótársaságok minősítésében a kötelező egészségbiztosításból származó biztosítási bevételek tekintetében. A Sogaz-Med OJSC a mai napig az egyik legnagyobb egészségügyi biztosító társaság az Orosz Föderációban, több mint 15,7 millió emberrel (az orosz lakosság több mint 11%-a) biztosítottak. A regionális hálózat több mint 550 részleget foglal magában az Orosz Föderáció 38 alkotóegységének területén. A Társaság befizetett jegyzett tőkéje 2014. szeptember 30-án 102,5 millió rubel, amely teljes mértékben megfelel az Orosz Föderáció hatályos jogszabályainak az alaptőke nagyságára vonatkozó követelményeinek, és lehetővé teszi a Sogaz-Med számára, hogy CHI-tevékenységét a következő napon tervezze meg. hosszú távú alapon.
Az OJSC SOGAZ-Med folytatja a CHI rendszer fejlesztéséhez szükséges modern technológiai eszközök bevezetésének programját. A vállalat számos fióktelepe részt vett az "Univerzális elektronikus kártya" (UEC) szövetségi projekt megvalósításában. Az elmúlt időszakban az OJSC "SOGAZ-Med" fiókjainak kötvénykibocsátási pontjai alapján az UEC kiadására vonatkozó elfogadott kérelmek száma körülbelül 2,3 ezer darab volt. A vállalat számos irodájában egyetlen minta CHI kötvényeket bocsátanak ki elektronikus hordozóval ellátott műanyag kártya formájában ("elektronikus szabályzat").
A "SOGAZ-Med" JSC jól megérdemelt tekintélyt élvez a szakmai közösségben. 2013 márciusában az Expert RA Rating Agency megerősítette a JSC SOGAZ-Med biztosító társaság megbízhatóságának és minőségének A++ minősítését („Kivételesen magas szintű megbízhatóság és szolgáltatások minősége”).
Ez a cég a következő szakosodott egyesületek tagja:
Az OAO Biztosító SOGAZ-Med D.V. vezérigazgatója. Tolstov az Egészségbiztosítók Interregionális Szövetsége elnökségi tagja.
A gazdasági elemzés kimutatta, hogy a 2014. évi eredményeket követően a Társaság kötelező egészségbiztosítási díjainak összege 44,45 millió rubelt tett ki, ami 1,3-szorosa az előző évinek. Emellett a kötelező egészségbiztosítás keretében fizetett biztosítási összegek 34,434 milliárd rubelt tettek ki, ami a biztosítási díjak teljes összegének 95,34%-a.
Ami a vagyoni helyzetet illeti, a vállalkozás működése során az eszközök értéke és szerkezete folyamatosan változik. Az alapok szerkezetében bekövetkezett minőségi változásokról és azok forrásairól a legáltalánosabb elképzelések a jelentéskészítés vertikális és horizontális elemzésével nyerhetők.
A vertikális elemzés a vállalati alapok szerkezetét és azok forrásait mutatja be. A vertikális elemzés előnye a horizontálishoz képest a relatív mutatók alkalmazása, amelyek bizonyos mértékig kisimítják az inflációs folyamatok negatív hatását, ami jelentősen torzíthatja a pénzügyi kimutatások abszolút mutatóit, és ezáltal megnehezítheti az inflációs folyamatok negatív hatását. hasonlítsa össze őket dinamikában. (Lásd 1. táblázat)
1. táblázat – A "Sogaz-Med" JSC eszközeinek szerkezete
A fenti adatokból arra következtethetünk, hogy 2012-ben a vállalkozás befektetett eszközeinek összege 1.724 ezer rubel növekedést mutatott, de a tárgyi eszközök aránya az eszközszerkezetben 0,55%-kal csökkent. 2013-ban 406 ezer rubel csökkenés következett be.
A társaság immateriális javakkal nem rendelkezik. A hosszú lejáratú pénzügyi eszközök aránya az eszközstruktúrában szintén elenyésző, és ingadozó tendenciát mutat: 2012 - 5,11%, 2013 - 7,19%, 2014 - 3,13%.
Összességében a befektetett eszközök aránya 2013-ban 1,55%-kal nőtt, 2014-ben 4,36%-kal csökkent.
A második eszközcsoport – forgóeszközök – mutatója ellentétes tendenciát mutat. 2012-ben részesedésük 93,30%, 2013-ban - 91,75%, 2014-ben 96,11%-ra nőtt.
A vizsgált időszakban a forgóeszközök döntő hányada a vevőállomány, 2012-ben 66,38%, 2013-ban 62,24%, 2014-ben pedig 46,63%-ra csökken.
A készpénz mennyisége minden évben csaknem kétszeresére nőtt: 401 732 ezer rubelről. 2012-ben 740367 ezer rubelre. 2013-ban és 1705579-ig 2014-ben.
A fentiek mindegyike arra utal, hogy a Sogaz-Med OJSC pénzügyi helyzete évről évre javul, ami azt jelenti, hogy ez a szervezet fejlődik, növeli ügyfélkörét, ami viszont a szervezet dokumentumában szereplő munka mennyiségének növekedéséhez vezet. folyam.
1. 2. A JSC "Sogaz-Med" biztosító társaság dokumentumforgalmának értékelése
A szervezet dokumentumáramlásának időben történő elemzése és értékelése a hatékony működés és a stabil fejlődés feltétele. A szervezet hatékonyságának tényleges növelése lehetetlen az összes kulcsfontosságú és támogató üzleti folyamat dokumentációjának folyamatos fejlesztése, valamint az irodai munkaszervezés javítása nélkül.
Tehát a JSC "Sogaz-Med" cégnél a dokumentumkezelés a szervezet egyik legfontosabb üzleti folyamata. Például vegye figyelembe a kötelező egészségbiztosítás megkötéséhez szükséges dokumentumok listáját.
A biztosítási egészségügyi szervezet választása (csere) iránti kérelemhez csatolni kell a biztosítottként való nyilvántartásba vételhez szükséges alábbi dokumentumokat vagy azok hiteles másolatait:
1) az Orosz Föderáció állampolgáraival rendelkező, állami születési bejegyzést követő, tizennégy évesnél fiatalabb gyermekek esetében:
2) az Orosz Föderáció tizennégy éves vagy annál idősebb állampolgárai számára:
3) a „Menekültekről” szóló szövetségi törvény értelmében orvosi ellátásra jogosult személyek esetében:
4) az Orosz Föderációban állandó lakóhellyel rendelkező külföldi állampolgárok esetében:
5) az Orosz Föderációban állandó lakóhellyel rendelkező hontalan személyek esetében:
6) az Orosz Föderációban ideiglenesen tartózkodó külföldi állampolgárok esetében:
7) az Orosz Föderációban ideiglenesen tartózkodó hontalan személyek esetében:
8) a biztosított képviselője számára:
9) a biztosított törvényes képviselője esetében:
A fentiekből kitűnik, hogy a JSC "Sogaz-Med" biztosítótársaság alkalmazottainak sok időt kell tölteniük a dokumentumokkal való munkával, és gyakran olyan munkával, amely nem kapcsolódik közvetlenül a szakmai tevékenységhez. Gyakori helyzet, amikor nem fordítanak kellő figyelmet az ügyfelekkel való kommunikációra, mivel a biztosítók idejük nagy részét dokumentumok szkennelésével és dokumentumkezelő rendszerek elsajátításával töltik.
Ennek következtében a biztosító irracionális erőforrás-felhasználása és eltolódott prioritásai súlyosan csökkentik a társaság versenyképességét a biztosítási piacon, és hátráltatják az üzletág bővülését.
Ezért a vállalatnak úgy kell optimalizálnia a munkafolyamatot, hogy az ne igényeljen nagyszámú humán erőforrás bevonását, és lehetővé tegye az aktuálisan szükséges információk egyszerű és gyors lekérését az adattárból. A cég számára ez két nyerő pontot jelent: a nyújtott szolgáltatás minőségének feltétlen javulását és egy ügyfél kiszolgálási idejének csökkenését, ami csökkentheti a létszámot.
Az is fontos, hogy az optimalizálás nemcsak a dokumentumfolyamatokat egyszerűsíti, hanem segít csökkenteni azok létrehozásának és feldolgozásának költségeit is.
A JSC "Sogaz-Med" biztosítótársaság munkafolyamatának automatizálásának előnyei:
A modell „ahogy van” fejlesztéséhez az AllFusion Process Modeler (BPwin) legfelső szintű CASE eszközt szánják, amely a következő módszereket támogatja:
Modell készítése szabványban IDEF0 .
A funkcionális modell célja a vállalat meglévő üzleti folyamatainak leírása (ún. AS-modell).én S "ahogy van") és az ideális állapot, amire törekedni kell (TO-BE modell "ahogy lennie kell"). Az IDEF0 módszertan a rendszertöredékek egyedi leírásaiból álló diagramok hierarchikus rendszerének felépítését írja elő.
Az IP-modell felépítése egy vállalkozás (rendszer) vagy különálló része (esetünkben ez az állami biztosítás) egészének kontextusdiagram formájában történő leírásával kezdődik. A 2. ábra az IS "Népességbiztosítás" kontextusdiagramját mutatja:
2. ábra. Népességbiztosítási összefüggés diagram
A kontextusdiagram azt mutatja, hogy a biztosítótársaság megkapja az ügyféltől a csere vagy kötvény kiállítása iránti kérelmet, valamint útlevelet, SNILS-t, érvényes kötvényt (csere esetén). Az irányítási mechanizmusok szabályozó jogszabályok, munkaköri leírások, a vállalkozás alapszabálya, valamint további megállapodások. Alkalmazottak A közbiztosítási szakterület zavartalan működéséhez szükséges erőforrások. A biztosítás eredménye egy új biztosítási kötvény, a kiadott kötvényekről szóló jelentések és a vállalkozás pénzügyi helyzetéről szóló jelentések, amelyeket elküldenek a központi irodának a dinamika nyomon követésére.
Továbbá a teljes biztosítási folyamat részfolyamatokra oszlik, amelyek viszont még kisebb részfolyamatokra bonthatók. Egy ilyen felosztás eredményeként a rendszer minden egyes töredéke külön bontási diagramon jelenik meg. (lásd 3. ábra):
3. ábra. Bomlási diagram IDEF 0. Lakossági biztosítás
. A "Munka a populációval" funkció további felosztása eredményeként a következő bontási diagramot kapjuk (lásd 4. ábra):
4. ábra. Bomlási diagram IDEF 0. Munka a lakossággal.
Felbontjuk az „Irányítások elfogadása és regisztráció” függvényt, és megkapjuk a végső diagramot (lásd: 5. ábra):
5. ábra. Bomlási diagram IDEF
A diagramokon jól láthatóak a kötvény kézhezvételekor lezajló folyamatok, kezdve a dokumentumok ügyféltől történő átvételével és a kötvény részére történő kiállításával. Valamint a beérkezett dokumentumokat ellenőrzik, és minden olyan ügyfelet figyelembe vesznek, aki megkapta a szabályzatot, ennek eredményeként összeállítják a magasabb vezetés számára szükséges jelentéseket.
1.4. „Hogy legyen” modell kidolgozása
Most hozzáadásra került egy ilyen erőforrás, mint egy adatbázis, amelynek segítségével leegyszerűsítheti a Sogaz-Med OJSC munkafolyamatát (lásd: 6. ábra):
6. ábra Az „ahogy lennie kell” modell kontextusdiagramja.
A „Lakosság biztosítása”, „Munka a lakossággal” és az „Irányok átvétele és nyilvántartása” diagramokhoz is adatbázis-forrás került. Változások történtek a korábban figyelembe vett „Irányok átvétele és nyilvántartása” bontási diagramon. Most a dokumentumok elfogadása és ellenőrzése egyetlen folyamat, amelynek eredményeként kiderül, hogy az ügyfélben van-e szabályzat. Nyomon követheti a kötvény lejáratának dátumát is, és erről előre értesítheti az ügyfelet. (Lásd: 7. ábra):
7. ábra. Bomlási diagram IDEF 0. Iratok átvétele, nyilvántartása.
Az „ahogy kell” modellből az következik, hogy a lakosságbiztosítás területén az adatbázis használata jelentősen csökkenti az ügyfelektől kapott dokumentumok feldolgozási idejét, ugyanakkor lehetővé teszi a kötvények érvényességének alaposabb nyomon követését is, viszont kedvező sikerhez vezet az ügyfélbázissal való együttműködésben és a vállalat imázsának javításában.
2. fejezet Program rész
2.1 A logikai modell leírása
A 8. ábra a rendszer logikai modelljét mutatja, a ComputerAssociates ERWin programjával megvalósítva:
8. ábra. Logikai adatmodell.
A logikai modell 3 entitást tartalmaz.
A Dokumentumtípus entitás információkat tartalmaz a dokumentum nevéről. Kulcsmező „Dokumentumazonosító” „integer” adattípussal. Nem kulcsmező „Dokumentumtípus” „char(100)” adattípussal.
A „Biztosítási kötvény” entitás az ügyfélről, a kötvényről és a munkavállalóról tartalmaz adatokat. A „Biztosítási kötvényszám” kulcsmező „integer” adattípussal. Nem kulcsmezők "Név" adattípussal "char(100)", "Születési dátum" adattípussal "", "Dokumentumazonosító" int , "Dokumentumszám-sorozat" int , "SNILS" int , "A biztosított telefonszáma" int , "A kötvény regisztrációjának dátuma" dátum idő , „A szabályzat lejárati dátuma” dátum idő , Munkavállalói azonosító int
Az „Alkalmazott” entitás a munkavállalóra vonatkozó adatokat tartalmazza. „Alkalmazotti azonosító” kulcsmező „integer” adattípussal. Nem kulcsfontosságú „Név” és „Pozíció” mezők „char(100)” adattípussal.
2.2. Fizikai adatmodell
9. ábra Fizikai adatmodell.
A fizikai modell generálása a CA Erwin Data Modeler program képességeinek felhasználásával történt. Válassza a Tools->Forward Engineer->Schema Generation menüt, majd a megjelenő ablakban nyomja meg a Generálás gombot. A megjelenő ablakban adja meg a Microsofr Server 2008-ban létrehozott adatbázis és a kiszolgáló nevét. Az adatbázis sikeresen létrejött.
leírni kapcsolatok és normalizálás)
3. fejezet Program rész
A rádiógombra kattintva 1 (100 nap) elteltével a funkció aktiválódik.
eljárás TForm1.RadioButton1Click(Sender: TObject);
vars:string;
kezdődik
Form1.Query2.Close;
Form1.Query2.SQL.Clear;
<:newdate1) ");
Form1.Query2.ExecSQL;
vége;
A rádiógombra kattintva 2 (50 nap) elteltével a funkció aktiválódik.
kezdődik
Form1.Query2.Close;
Form1.Query2.SQL.Clear;
Form1.Query2.SQL.Add("Select Number,FIO,SNILS,Telephone from dbo.OMS");
Form1.Query2.SQL.Add("ahol (Dátum_reg_doc+50>:újdátum1) ");
Form1.Query2.ParamByName("newDate1").AsdateTime:=Form1.DateTimePicker1.DateTime;
Form1.Query2.ExecSQL;
vége;
A rádiógombra kattintva 3 (10 nap) funkció aktiválódik
kezdődik
Form1.Query2.Close;
Form1.Query2.SQL.Clear;
Form1.Query2.SQL.Add("Select Number,FIO,SNILS,Telephone from dbo.OMS");
Form1.Query2.SQL.Add("ahol (Dátum_reg_doc+50>:újdátum1)");
Form1.Query2.ParamByName("newDate1").AsdateTime:=Form1.DateTimePicker1.DateTime;
Form1.Query2.ExecSQL;
vége;
Ha a „Beállítások” -> Munkavállalói regisztráció menüben a gombra kattint, megjelenik a „Munkavállalói regisztráció” párbeszédpanel két mezővel és a „Regisztráció” gombbal.
Gomb 1
kezdődik
Form3.Query1.Close;
Form3.Query1.SQL.Clear;
Form3.Query1.ExecSQL;
vége;
Ha megnyomja a regisztráció gombot, az eljárás elindul 2. űrlap. 1. gomb Kattintson
kezdődik
Form2.Query3.Close;
Form2.Query3.SQL.Clear;
Form2.Query3.ExecSQL;
Form2.Query4.Active:=FALSE;
Form2.Query4.Active:=TRUE;
vége;
Következtetés
Jelenleg a cégeknek magasabb szinten kell megoldaniuk a dokumentumkezeléssel kapcsolatos problémákat. A folyamatosan változó, hatalmas információáramlások megkövetelik a vállalat személyzetétől, hogy gyors és pontos döntéseket hozzanak, amelyek célja a maximális profit elérése minimális költséggel. Ezért a vállalkozások egyre gyakrabban szembesülnek a bejövő információk feldolgozásával kapcsolatos problémákkal. Megoldhatók a vállalatoknál zajló folyamatok automatizálásával.
Az automatizálás segít csökkenteni az üzleti tevékenység költségeit azáltal, hogy szabályozza és egyszerűsíti a vállalati alkalmazottak hozzáférését a szükséges információkhoz. Megváltoztatja a dolgozók munkavégzésének jellegét, mentesíti őket a rutinmunka végzése alól, és lehetőséget ad számukra, hogy szakmailag fontos feladatokra koncentráljanak.
Ebben a kurzusprojektben a Sogaz-Med OJSC társaság lakosságának biztosításának folyamatát vették figyelembe. A szabályzat kézhezvételekor lezajló üzleti folyamatokat ismertettük és ábrázoltuk. Valamint megoldást javasolnak a vállalkozás problémájára, amely a beérkező áruk raktári feldolgozásával és a kapcsolódó dokumentumokkal kapcsolatos.
Ezt követően kidolgozásra került az „ahogy van” és „ahogy lennie kell” funkcionális modellek, majd a program logikai és fizikai modelljét ismertetjük. A beérkezett információk alapján a programozási környezetben létrejött a „Lakosságbiztosítás” adatbázis Delphi 7.0 , amely eszközöket biztosít az információs rendszerben lévő adatok kezeléséhez a kötvényszerzési munka támogatása érdekében. A kapott programot teszteltük.
Bibliográfia
Alkalmazás
Felsorolás
1. egység
egység Egység1;
felület
használ
Párbeszédpanelek, menük, StdCtrls, ComCtrls, Grids, DBGrids, DB, DBTables;
típus
TForm1 = osztály(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;
Eljárás N4Click(Küldő: TObject);
Eljárás N5Click(Küldő: TObject);
Eljárás N3Click(Küldő: TObject);
Radio ProcedureButton1Click(Sender: TObject);
Radio ProcedureButton2Click(Sender: TObject);
Radio ProcedureButton3Click(Sender: TObject);
Magán
(Privát nyilatkozatok)
Nyilvános
(Nyilvános nyilatkozatok)
vége;
Form1: TForm1;
végrehajtás
Unit2, Unit3;
($R *.dfm)
eljárás TForm1.N4Click(Sender: TObject);
kezdődik
forma2.show;
vége;
eljárás TForm1.N5Click(Sender: TObject);
kezdődik
forma3.show;
vége;
eljárás TForm1.N3Click(Sender: TObject);
kezdődik
Form1.Close;
vége;
eljárás TForm1.RadioButton1Click(Sender: TObject);// dinamikus lekérdezések
vars:string;
kezdődik
Form1.Query2.Close;
Form1.Query2.SQL.Clear;
Form1.Query2.SQL.Add("Select Number,FIO,SNILS,Telephone from dbo.OMS");
Form1.Query2.SQL.Add("ahol (Dátum_reg_doc+100<:newdate1) ");
Form1.Query2.ParamByName("newDate1").AsdateTime:=Form1.DateTimePicker1.DateTime;
Form1.Query2.ExecSQL;
vége;
eljárás TForm1.RadioButton2Click(Sender: TObject);
kezdődik
Form1.Query2.Close;
Form1.Query2.SQL.Clear;
Form1.Query2.SQL.Add("Select Number,FIO,SNILS,Telephone from dbo.OMS");
Form1.Query2.SQL.Add("ahol (Dátum_reg_doc+50>:újdátum1) ");
Form1.Query2.ParamByName("newDate1").AsdateTime:=Form1.DateTimePicker1.DateTime;
Form1.Query2.ExecSQL;
vége;
eljárás TForm1.RadioButton3Click(Sender: TObject);
kezdődik
Form1.Query2.Close;
Form1.Query2.SQL.Clear;
Form1.Query2.SQL.Add("Select Number,FIO,SNILS,Telephone from dbo.OMS");
Form1.Query2.SQL.Add("ahol (Dátum_reg_doc+50>:újdátum1)");
Form1.Query2.ParamByName("newDate1").AsdateTime:=Form1.DateTimePicker1.DateTime;
Form1.Query2.ExecSQL;
vége;
vége.
2. egység
egység Unit2;
felület
használ
Windows, Üzenetek, SysUtils, Változatok, Osztályok, Grafika, Vezérlők, Űrlapok,
Dialógusok, Rácsok, DBGridek, StdCtrls, ComCtrls, DB, DBCtrls, DBTables;
típus
TForm2 = osztály(TForm)
Label9: T Label;
GroupBox1: TGroupBox;
Címke1: T Label;
Label2: T Label;
Label3: T Label;
Label4: T Label;
Label5: T Label;
Label6: T Label;
Edit1: TEdit;
DateTimePicker1: TDateTimePicker;
Edit2: TEdit;
Edit3: TEdit;
Edit4: TEdit;
GroupBox2: TGroupBox;
Label7: T Label;
DateTimePicker2: TDateTimePicker;
Label8: T Label;
Button1: TButton;
DBGrid1: TDBGrid;
Query1: TQuery;
1. táblázat: TTábra;
DataSource1:TDataSource;
2. táblázat: TTábra;
DataSource2: TDataSource;
ComboBox1: TComboBox;
Query2: TQuery;
ComboBox3: TComboBox;
Query3: TQuery;
DateTimePicker3: TDateTimePicker;
Query4: TQuery;
DataSource3:TDataSource;
Procedure FormCreate(Sender: TObject);
Magán
(Privát nyilatkozatok)
Nyilvános
(Nyilvános nyilatkozatok)
vége;
Form2: TForm2;
végrehajtás
($R *.dfm)
eljárás TForm2.FormCreate(Sender: TObject);
kezdődik
Bár nem a query1.eof kezdődik
Combobox1.items.add(query1.fieldbyname("Név_dokumentum").asstring);
Query1.next
vége;
Bár nem a query2.eof kezdődik
Combobox3.items.add(query2.fieldbyname("FIO").asstring);
Query2.next
vége;
Form2.Query4.Active:=FALSE;
Form2.Query4.Active:=TRUE;
vége;
eljárás TForm2.Button1Click(Sender: TObject);
kezdődik
Form2.Query3.Close;
Form2.Query3.SQL.Clear;
Form2.Query3.SQL.Add("Beszúrás a dbo.OMS-ba (FIO,DB,ID_doc,szám_doc,SNILS,Telefon,Dátum_reg_doc,Srok,ID_alkalmazott)");
forma dbo.employee ahol 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;
vége;
vége.
3. egység
egység Egység3;
felület
használ
Windows, Üzenetek, SysUtils, Változatok, Osztályok, Grafika, Vezérlők, Űrlapok,
Dialógusok, StdCtrls, DB, DBTables;
típus
TForm3 = osztály(TForm)
Címke1: T Label;
Edit1: TEdit;
Label2: T Label;
Edit2: TEdit;
Button1: TButton;
Query1: TQuery;
ProcedureButton1Click(Sender: TObject);
Magán
(Privát nyilatkozatok)
Nyilvános
(Nyilvános nyilatkozatok)
vége;
Form3: TForm3;
végrehajtás
($R *.dfm)
eljárás TForm3.Button1Click(Sender: TObject);
kezdődik
Form3.Query1.Close;
Form3.Query1.SQL.Clear;
Form3.Query1.SQL.Add("Beszúrás a dbo.Employee-ba (FIO,Position)");
Form3.Query1.SQL.Add("Értékek(:newFIO,:newPosition)");
Form3.Query1.ParamByName("newFIO").AsString:=Edit1.Text;
Form3.Query1.ParamByName("newPosition").AsString:=Edit2.Text;
Form3.Query1.ExecSQL;
vége;
vége.
projekt
program Projekt1;
használ
formák,
Unit1 a "Unit1.pas"-ban (Form1),
Unit2 a "Unit2.pas"-ban (Form2),
Unit3 a "Unit3.pas"-ban (Form3);
($R*.res)
kezdődik
Alkalmazás.Inicializálás;
Application.CreateForm(TForm1, Form1);
Application.CreateForm(TForm2, Form2);
Application.CreateForm(TForm3, Form3);
Alkalmazás.Futtatás;
vége.
Egyéb kapcsolódó munkák, amelyek érdekelhetik.vshm> |
|||
| 20665. | Gyógyszertári adatbázis tervezése és megvalósítása | 2,55 MB | |
| Novokuznyeck-feladat kurzushoz Olyan adatbázist kell megtervezni, amely attribútumcsoportok formájában tartalmazza az információkat: Gyógyszertár Gyógyszernév; annotáció; tárolás; átvétel dátuma; eljövetel; egyenleg a hónap végén; cég gyártója; szállító stb. A feladat a következő: Hozzon létre egy adatbázist. Rendszerezzen állandó hivatkozásokat a táblák között az adatbázis integritásának biztosítása érdekében. | |||
| 20182. | College Daytime Database Design | 2,59 MB | |
| Adatbázis tervezése nappali tagozatos főiskola számára Elkészítette: hallgató gr. A kurzusmunka feladatul tűzi ki egy adatbázis projekt kidolgozását a szervezetben szükséges információk felhalmozására, egy kitöltendő adatbázis létrehozására. Az adatbázist úgy kell kialakítani, hogy figyelembe vegye a különféle típusú információszerzési kérések végrehajtását. Az adatbázis kialakításánál figyelembe kell venni a papíralapú jelentés kiadásának lehetőségét. | |||
| 10007. | Az "Autóalkatrész-katalógus" adatbázis tervezése | 182,36 KB | |
| Kezdetben helyi tömböket (vagy fájlokat) használtak az információk számítógépen való felhalmozására és tárolására, míg minden egyes megoldandó funkcionális feladathoz saját fájlokat hoztak létre a kezdeti és az eredményinformációkból. Ez az adatok jelentős megkettőzéséhez vezetett, bonyolította azok frissítését, és megnehezítette az egymással összefüggő problémás feladatok megoldását. | |||
| 14064. | Az "Archív MBUK Izhbolda SDK" adatbázis tervezése és létrehozása | 24,67 KB | |
| A táblázat oszlopa minden rekordra vonatkozóan azonos típusú információkat tartalmaz, és mezőnek nevezik. DBText Az aktuális adatkészlet szövegmezőinek megjelenítésére, de nem módosítására szolgál. DBEdit Adatkészlet szövegmezőinek megjelenítésére és módosítására szolgál. Hasonló az Stndrd oldal ComboBox összetevőjéhez, de adatbázis szövegmezőként szolgál. | |||
| 20557. | Adatbázis tervezés járműszerviz | 8,01 MB | |
| Az adatbázis mindenekelőtt adatobjektumok tárháza, azaz. az adatbázis által leírt lehetséges fogalmak vagy események halmaza, amely képes ezekre az objektumokra jellemzők alapján keresni. Adatbázisnak nem csak azokat a táblákat lehet tekinteni, amelyek különböző formátumú fájlokat indexelnek, hanem magukat ezeket a fájlokat is, mivel egy ilyen adatbázisban típusolatlan tudástárak. Az adatbázisok segédeszközként használhatók, amely lehetővé teszi néhány hasznos funkció megvalósítását. | |||
| 13839. | Közjegyzői adatbázis tervezése Access DBMS technológiák segítségével | 13,53 MB | |
| A közjegyző a jogrendszer egyik legfontosabb intézménye, amelynek célja egy demokratikus jogállam kialakulásának elősegítése, amelyben a közjegyzői cselekmények végrehajtásával megbízhatóan védik az állampolgárok és a jogi személyek jogait és jogos érdekeit. | |||
| 15115. | A biztosító díjszabása | 28,09 KB | |
| Hibák a tarifák kiszámításában és a biztosítási díj megállapításában, az ezt követő forráshiány a biztosítási kifizetések biztosítására, hibák a viszontbiztosítási védelmi rendszer kialakításában vagy annak résztvevőinek meghatározásában, valamint a viszontbiztosítási díj túlfizetése vagy a viszontbiztosító csődje; a biztosító társaság saját tőkéje. A választott téma aktualitását az adja, hogy a biztosítók tarifapolitikája az alapja egy stabil... | |||
| 13963. | A GÉPJÁRMŰBIZTOSÍTÁS SZERVEZÉSE A "ROSGOSSTRAKH" BIZTOSÍTÓTÁRSASÁGBAN | 3,04 MB | |
| A biztosítás lényege egy bizonyos pénzbeli biztosítási alap létrehozása, valamint annak időben és térben történő elosztása balesetek, természeti katasztrófák és egyéb, a biztosítási szerződésben meghatározott körülmények esetén a benne résztvevőket érő esetleges károk megtérítésére karakter minden járműtulajdonos számára A. védelemhez kapcsolódó nem állami gépjárműbiztosítás típusa ... | |||
| 21849. | PR-kampány szervezése és lebonyolítása az ALLIANZ biztosító márkaváltására | 1021,66 KB | |
| Íme Sam Black definíciói, amelyek elsőként jutottak el az oroszul beszélő olvasóhoz: „A PR az egyik olyan irányítási funkció, amely hozzájárul a kommunikáció, a kölcsönös megértés, a helyszín és az együttműködés kialakításához és fenntartásához a szervezet és a szervezet között. nyilvános. | |||
| 20319. | ADATBÁZISOK ÉS VÉDELMÜK | 102,86 KB | |
| Az online online adatbázisok az 1960-as évek közepén jelentek meg. Az operatív adatbázisokon végzett műveletek feldolgozása interaktívan, terminálok segítségével történt. Az egyszerű index-szekvenciális rekordszervezés gyorsan egy erősebb halmazorientált rekordmodellré fejlődött. Charles Bachmann Turing-díjat kapott a Data Base Task Group (DBTG) munkájának vezetéséért, amely szabványos nyelvet fejlesztett ki az adatok leírására és az adatok manipulálására. | |||
