Prim Hírek

Antal Katalin: - Korábban a Scala 5.0 Btrieve-változatát három cég használta a cégcsoportból, a program által kínált lehetőségeket azonban nem aknáztuk ki. A csoporthoz tartozó többi vállalat más ügyviteli rendszert alkalmazott, és a speciális igények miatt a hirdetésfelvételt is egyedi fejlesztésű program támogatta. Az upgrade-re éppen az információkinyerési művelet, valamint a kontrolling által végzett adatfeldolgozás nehézkessége és hosszú átfutási ideje miatt került sor. A tulajdonosi és cégstruktúra miatt bonyolult jelentésrendszerhez szükséges információ kinyerésének ideje az 5.0-ról 5.1-re történő átállást követően napokról egy órára csökkent.

M.: - Evidens volt az upgrade, mert elégedettek voltak a korábbival, vagy felmerült a rendszercsere lehetősége is?

A. K.: - Az előző verzió bevezetője, támogatója nem a Scala Hungary volt, mivel akkor vállalatunk, egyéb megfontolások alapján, nem őket választotta. A támogatással és az oktatással egyaránt elégedetlenek voltunk. Így a rendszerváltás gondolata is felmerült, de hogy nem vált tetté, annak két oka van. Egyrészt megkeresésünkre a Scala Hungary vett minket szárnyai alá, s egyúttal az oktatásban és a támogatásban is minőségi szolgáltatást ígért. Másrészt az akkor már küszöbön álló eladásunk miatt az anyagilag kisebb mértékben megterhelő megoldás mellett kellett voksolnunk. A Scala melletti döntésünk a lehető legjobb választásnak bizonyult. Bizalmunk kamatozott, a támogatással teljes mértékben elégedettek vagyunk. A folyamtatos tudástranszfer révén egyre jobban átlátjuk a rendszert, s ha úgy adódik, már magunk is képesek vagyunk a kisebb problémákat megoldani.

M.: - Minden korábbi szigetmegoldás integrálódott a Scalába?

A. K.: - A folyamatok feltérképezésével együtt a követelményspecifikációt is közösen állítottuk össze a Scala Hungary munkatársaival. Megvizsgáltuk, hogy a speciális funkciókat lefedő külső programok közül melyeket éri meg bizonyos munkamennyiség árán funkcionálisan is a Scalába integrálni, illetve mikor ésszerűbb megoldás az interfész kialakítása. Az ezekkel a programokkal kapcsolatos elvárásainkat megismertettük a Scalával, és ők úgy vélték, hogy a hirdetés-nyilvántartó, valamint a lapok készletezését végző rendszer specialitásai túlnőnek a Scalán. Így itt a minél jobb kapcsolat kialakítása lett a cél, ami mindmáig problémamentesen működik. De a papírkészlet- és egy vállalatnál - tesztelés céljából - a nyeremény-nyilvántartást célszerűnek látszott a Scalába integrálni.

M.: - Milyen modulokat vezettek be?

A. K.: - A Főkönyv, a Kimenő és bejövő számlakönyv, a Vevőrendelés, a Beszerzés-, valamint a Készletnyilvántartás támogatását és persze a statisztikakészítést bíztuk a Scalára. A bérszámfejtésen is gondolkodtunk, de a lapokra jellemző kifizetési specifikációk miatt a korábbinál maradtunk, így a bérfeladás interfészen keresztül, de fennakadás nélkül, mindig kellő időben megtörténik.

M.: - Amit elmondott, annak alapján az átállás egyik kritikus pontja az adatbetöltés lehetett...

A. K.: - A megfelelő működés szempontjából az adatbetöltés mindig kritikus, de ezt is a Scalával közösen, ám akkor még nem minden szempontból megfelelően előkészítve végeztük. Az itt szerzett tapasztalatainkat később, a Sanoma létrejöttekor ismét előtérbe kerülő adategyesítések alkalmával kamatoztattunk. A Scala vállalta - kellemes meglepetésünkre az adat-előkészítéssel együtt - az 5.0-ban rögzítettek betöltését az 5.1-be, a többi vállalatnál pedig a mi előkészítésünket követően tette meg ezt. A követelményspecifikáció elkészítését a 2001 júniusában elindított - az oktatás összehangolását nehezítő szabadságolások ellenére nagyon rövid ideig tartó -, augusztus végén befejeződött adatbetöltés követte.

M.: - Mi okozta a legtöbb gondot, és hogyan sikerült azokat megoldani?

A. K.: - A legnagyobb feladat a nyolc vállalat Access-nyilvántartásában lévő adatok bevitelével a partneradatokat összesítő masteradatbázis létrehozása volt. A Scala standard funkciója helyett az adatbázisra történő közvetlen rátöltést választottuk, de már folyt a funkció tesztelése, amikor erről tájékoztattuk a Scala Hungaryt. A változtatást az egyeztetések után elfogadták, és annyi segítséget, amennyit ez a fázis még megengedett, megadtak az adat-előkészítéshez. Az áttöltési időszak legnagyobb tanulságaként elmondható, hogy a program ismerőivel folytatott intenzív kommunikációval az áttöltés problémái exponenciálisan csökkenthetők. A nem megfelelően előkészített adatállomány menet közben sokkal nehezebben korrigálható. A fentiekből levont következtetéseket - hogy mire és milyen formában van szükség - az idén betöltésre előkészített adatoknál hasznosítjuk. A jelentős változások ellenére is sokkal zökkenőmentesebb volt az új cég és a szükséges adatok bevitele a Scalába, mint az előbb ismertetett verzióváltáskor.

M.: - Mit nyertek a már elmondottakon túl az 5.1-re való átállással?

A. K.: - Korábban nem használtuk ki a Scalában meglévő tíz dimenzió és az azok szerinti adatcsoportosítás lehetőségét, de ma már kilencet bevontunk a munkánkba. Többek között az eltérő magyar és nemzetközi főkönyvi számrendszer, az újságok és osztályok költséghelyei, valamint a költségek felmerülésével, a megjelenések idejével összekötött hónapkódok alkotják a dimenziókat, s adataink bérmelyik mentén csoportosíthatók. Kontrollerszemmel nézve a könyvelési rendszerből történő, a korábbinál jóval egyszerűbb adatkinyerés az igazi "ajándék".

M.: - Milyen változásokra volt szükség az összevonás előkészítése, illetve megvalósítása során?

A. K.: - Felkészülve a vállalatok összevonására, eladás előtt egységesítettük a masteradatbázis partnerkódját, ami nagy koncentrációt és komoly előkészítési munkát igényelt. Itt kamatoztattuk a korábbi tapasztalatokat. Miközben nyitott tételeket töltöttük át egy-egy vállalatba, a partnerek adatainak egyenkénti "összevezetését" is elvégeztük - külön foglalkozva a problémás tételekkel. Ehhez is maximális támogatást nyújtott a Scala, s útmutatásaik alapján - hogy később a könyvelő és pénzügyes kollégák gond nélkül megtalálják a partnert - bizonyos szisztéma alapján egészítettük ki hatkarakteresre a partnerkódokat. Ennek eredményeként - a technikai problémák és a jelentős szervezeti változások ellenére is - mindössze négy nap kellett az új vállalat adatbetöltéséhez. Ez volt a tulajdonosváltás kapcsán a rendszerrel kapcsolatos legnagyobb, sikeresen végrehajtott feladat, amely a Scala munkatársainak hozzáértését és együttműködési készségét is dicséri. Az új cég - a Sanoma Budapest Rt. - létrejötte jelentősen leegyszerűsítette a munkafolyamatot. A korábban külön cégként működő hirdetésszervező vállalkozásunk beolvadásával a számlázás jelentős mértékben csökkent.

M.: - Hogyan viselte a Scala a váltást, kellett-e újrakonfigurálni?

A. K.: - Beállításai és dimenziói szinte változtatás nélkül átmenthetők voltak, ami a korábbi munka sikerét jelzi. Most a holdinggal együtt öt vállalatot szolgál ki, plusz a konszolidált céget. Ez utóbbit a kontrollingmunka további egyszerűsítése érdekében - utólag, az ötszöri adatgyűjtést és összedolgozást jelentő crystallos próbálkozást követően - hoztuk létre. A konszolidált vállalat lehetővé teszi az év korábbi részében és az új cégkonstrukció létrejötte után termelődő adatok együttes kezelését. Létrehozásához kihasználtuk a dimenziókat, és így cégenként más-más jelzéssel ellátott adatokat tölthettünk a konszolidált vállalatba. A cégekből kiszedett, majd megjelölve ugyanoda visszatöltött tranzakciók naplófeladáskor kerültek a konszolidált vállalatba. Százezer feletti akciószámnál ez is időigényes feladat volt, amihez a tudástranszfer során átkerültek hozzánk a szükséges készségek. A fentiek mellett eltörpültek az olyan munkák, mint például az egységes számlavezetéshez szükséges kisebb fejlesztések vagy a több kódon előforduló partnerek számára történő, VBA-fejlesztéssel megoldott letiltás.

M.: - Mik a legközelebbi, a Scalát is érintő terveik?

A. K.: - Egy hónapos határidő-eltolással, november elején - kiskereskedelmi tevékenységbe kezdve - boltot nyitunk a kiadó közelében. Ott a Scala és a Novodata együttműködésének eredményeként a Scalával integrált, vonalkódot is kezelő Novodata pénztárgéprendszert működtetünk. A csúszásnak prózai, előremutató oka volt. Megvizsgálva a szükséges és az ezzel egy időben más területet is érintő feladatokat, egységes cikktörzslista létrehozása mellett döntve a nyereményjátékunk indulásának idejére halasztottuk a boltnyitást.