Ügyviteli rendszerek

Figyelem! Kérjük az értelmezésénél a megjelenés időpontját (2003. november 1.) vegye figyelembe!

Megjelent a Cégvezetés (archív) 67. számában (2003. november 1.)
Szöveg nagyítása Szöveg kicsinyítése Nyomtatás
A vállalatirányítás és ügyvitel területén nagyon sok olyan szoftver létezik, amellyel adott kis területen önállóan megoldható valamilyen feladat, például számlázás, raktárkezelés, könyvelés, pénztár stb. Az egységesítésre megoldás lehet az integrált vállalatirányítási rendszer. A szoftverek többsége még ma is a régi PC DOS-os környezetre és módszerekre épül (akkor is, ha már Windows alatt fut), melyek természetesen már nem alkalmasak arra, hogy bonyolult összetételű követelményeket kielégítsenek. Ilyen alapkövetelmény, hogy a nagyobb ügyviteli, gyártási, szolgáltatási területek egymással összefüggő egységet alkossanak. Sok olyan példát látni, amikor egy-egy pénzügyi osztályon 5-6 különböző alkalmazást használnak, ahol egy adatot többszörösen rögzítenek, ami persze exponenciálisan növeli a hibák arányát.

Sajnos, a mai ügyviteliszoftver-piacon csak kevés összetett rendszer felel meg az integráltság követelményeinek úgy, hogy annak minden előnyét ki is lehessen használni.

Felhasználói igények

Vegyünk egy példát. Bemegy a vevő az üzletbe, hogy vásároljon egy terméket. Ekkor az eladó a raktárkészlet alapján megnézi, van-e rá élő foglalás. Ha rendelkezésre áll a termék, akkor szériaszám alapján ki kell tárolni, majd ez alapján a számlát el kell készíteni. Mivel készpénzes a számla, a pénztárban is bevételezni kell az összeget, és a könyvelésnek át kell küldeni gazdasági eseményként, ahol rögzítik azt. Eközben a vezető információs rendszerben is módosulhatnak a kimutatások. Ezt a folyamatot is végignézve legalább hat olyan érintett terület van, amire sok esetben önálló termékeket ajánlanak a készítők.

Ha integrált rendszerben gondolkodunk, nem szabad elfelejteni, hogy minden vállalkozásnak megvan a saját profilja, módszere arra, hogy az egyes folyamatokat milyen módon kezeli (pl. számviteli politika, SZMSZ stb.). Ha azt nézzük, hogy egy szoftverterméknek önállóan és egységesen kell kezelnie minden folyamatot, akkor csak olyan rendszer használható, amely minden területen beállítható a vállalkozás a saját arculatának megfelelően. Ez viszont már nagyon bonyolult feladat.

Először is a rendszernek megfelelő technológiai háttérrel kell rendelkeznie. Ebbe beletartozik egy komoly adatbázis-kezelő (pl. MS SQL, Oracle, DB2 stb.), illetve olyan kliens-szerver architektúra, amely a teljes aszinkronműködést (egy kliensen belül is) biztosítani tudja. Az általános keresési feltételeknél beállíthatjuk, mely bizonylatok töltődjenek le a kliensfelületre. (Megjegyezzük, hogy a kliens-szerver architektúra esetén minden esetben meg kell adni a keresési feltételt, ami alapján a szerver kikeresi a kért bizonylatokat, és csak azokat adja át a kliensszámítógépnek.) A letöltés közben viszont tetszőleges más feladattal is foglalkozhatunk, hiszen a letöltés hosszú ideig is eltarthat. Sokszor lehet hallani ilyenkor, hogy a rendszer "nem jó és lassú". Ha a keresési feltétel beállításával akár több ezer bizonylat is a gépünkre kerülhet (pl. 2002-es pénztárbizonylatok), akkor még a kevés és tömörített adatokat tartalmazó rekordok esetén is hatalmas mennyiségű információt kell letölteni, hogy utána listaszerűen böngészhetőek legyenek a bizonylatok. A rendszer technológiai háttere a "felelős" azért, hogy tetszőleges számú felhasználó hasonló módon dolgozhasson ugyanazon az adatbázison.

A másik probléma az lehet, hogy az egyes bizonylatokat össze kell kapcsolni egymással a gazdasági események vagy más folyamatok alapján. A megfelelő rugalmasság megköveteli, hogy ehhez olyan leírást használjunk, mely a részletekben is képes minden apró lépést pontosan definiálni. Például egy vállalkozás saját azonosítókat is bevezethet, melyek speciális formátumot használnak, illetve az egyes lépésekben ezek automatikusan is változhatnak adott szervezeti szabályok alapján. Ha ilyen egyedi folyamatokat akarunk létrehozni, melyek a rendszerben akár teljesen automatikusan is képesek lesznek működni, akkor ezt csak speciális leíró nyelvezettel lehet jól definiálni, amire egy integrált rendszer esetében úgynevezett script nyelv szolgál. (Tehát például egy kitárolásnál megmondjuk, hogy ki a vevő és készpénzben fizet, akkor egy gombnyomásra a megfelelő egyedi számla, pénztárbizonylat is létrejön. E bizonylatok véglegesítése után viszont más folyamatok, például könyvelési lépések is kezdődhetnek.)

Kell egy szakember!

Talán ezek alapján világossá válhat, hogy egy komplex rendszer esetén miért is kell legalább egy olyan informatikus szakember (külső vagy belső), aki a vállalati folyamatokat képes megismerni, és a rendszer leíró nyelvezetén azt a megfelelő módon programozni. Ez a szakember rendszerint programozó és nem rendszergazda! (Az esetleg háznál lévő rendszergazdák, operátorok erre a feladatra nem alkalmasak egyrészt a programozói tudás, másrészt az ügyviteli szakértelem hiánya miatt.) Így egy-egy integrált rendszer bevezetése több hónapot is igénybe vehet, hiszen a programozónak elsősorban a folyamatokat kell átlátnia úgy, hogy azokat képes legyen implementálni (eközben minden illetékes emberrel megbeszéli a hozzá tartozó folyamatokat), az egyes bizonylatok képeit, kialakítja az egyedi listákat, megszerkeszti a kimutatásokat, vagy egy hasonló szerkesztőfelülettel a kliensprogramok beviteli felületén is elvégzi a szükséges módosításokat annak érdekében, hogy megfelelő sorrendben csak a releváns információk legyenek kint a képernyőn.

Most már az is érthető, hogy a bevezetés során miért lehet szükség rendszerintegrátor cég közreműködésére, majd a későbbiekben úgynevezett support (támogatási szerződés) keretében a karbantartásra. (Ugyanis idővel mindig lesznek olyan változtatások a cég ügymenetében, amelyek az így programozott, illetve beállított rendszerben módosítási igényeket indukálnak.)

Egyedi fejlesztések

Ha egy vállalkozás ügymenetét sajátos folyamatok jellemzik, akkor valószínűleg egyedi fejlesztést kell kérni bizonyos feladatok gyakorlati megvalósítására. Ilyenkor viszonylag hosszú és költséges folyamatra kell felkészülni.

Elsőként a feladat pontos definiálására van szükség. Ekkor olyan konzulensek jelennek meg a megrendelőnél, akik képesek a feladatot mélységeiben feltárni, és később specifikálni a programozók számára. Néhány héten keresztül a megrendelő munkatársait kérdezik ki részletesen az egyes folyamatokról. Így a feladat pontos leírását tartalmazó részletezés készül. Ez az alapja a rendszertervnek, amely általánosságok után a legapróbb részletekig definiálja a kifejlesztendő egyedi szoftver komponenseit, majd a gyakorlati szakasz következik, amikor a programozók a rendszerterv alapján elkészítik a program legelső változatát.

Az első tesztelési fázist még a programozók végzik, amikor a gyorsan és egyértelműen kiszűrhető hibákat fedezik fel és javítják ki, majd utána tesztrendszert hoznak létre (úgynevezett pilot rendszert), ami szélesebb körű kísérletezést, próbákat tesz lehetővé. Ez a fázis akár néhány hónapig is eltarthat attól függően, hogy az újonnan kifejlesztett szoftver vagy programkomponens mekkora feladatokat, illetve folyamatokat ölel át.

A tesztrendszerrel párhuzamosan éles rendszert is kialakítanak, amit a tesztelési időszak végén a fejlesztők üzembe állítanak. A folyamatból látható, hogy az egyedi fejlesztés roppant időigényes, és persze költséges is lehet. A fejlesztő cégek általában csak a feladatspecifikáció megléte után tudnak pontos árajánlatot adni a költségekre. Elsőként tehát a specifikáció létrehozására adnak árajánlatot (ez a feladat nagyságától függően átlagosan 200-500 ezer forint lehet, de léteznek extrém esetek is). Ha a megrendelő ezt állja, akkor a pontos feladatspecifikáció alapján a fejlesztő cég megadja az ajánlatot a teljes rendszer kifejlesztésére és bevezetésére.

Az árajánlathoz rendszerint kiszámolják, hány fejlesztői és támogatói munkaórát kell biztosítani minimálisan a feladat végrehajtásához, majd felszorozzák a megfelelő szakértői óradíjjal, ami a programozóknál 8-20 ezer forint, a konzulenseknél 5-15 ezer forint a platformtól és a feladat bonyolultságától függően.

Figyelem! Kérjük az értelmezésénél a megjelenés időpontját (2003. november 1.) vegye figyelembe!

Nyomtatás Főoldalra Nyomtatás Nyomtatás A lap tetejére A lap tetejére