Junij 1991
V začetku leta 1991 so bile vse podružnice SDK v R Sloveniji med seboj povezane v republiško TK mrežo z računalniki Unisys in IBM. S tem je bil izpolnjen prvi pogoj za uvedbo popolnega TK prenosa podatkov z nalogov plačilnega prometa v SDK.
Ker pa za uspešno delovanje tako kompleksnega in pomembnega sistema, kot je TK prenos podatkov, niso dovolj le lepe želje, temveč je potrebno še kaj več, sem mnenja, da je Služba v letih, odkar je začela uvajanje TK prenosa podatkov (od leta 1984 dalje), bila premalo aktivna tako na področju razvoja in nadgradnje obstoječih tehnoloških rešitev v Službi in sodelovanju z zunanjimi institucijami, kot tudi pri izobraževanju in sodelovanju z uporabniki naših storitev - podjetji in iskanju novih rešitev za odpravo napak in težav, ki se pojavljajo pri delu v funkciji.
Z razvojem in nadgradnjo TK prenosa podatkov smo bili preveč pod vplivom in odvisnostjo SDKJ (kar je zaradi enotnosti PP lahko zagovarjati), včasih pa je taka odvisnost in povezanost lahko služila tudi za izgovore.
Če bi hoteli doseči maksimalne učinke in prednosti TK prenosa podatkov, pa menim, da bi morala biti formirana mešana delovna skupina, sestavljena iz strokovnjakov službe s področja funkcije plačilnega prometa in AOP-ja ter zunanjih institucij (ki se ukvarjajo z informacijskimi sistemi) in uporabnikov storitev. Skupina bi morala dajati pobude za nove rešitve in nadgradnjo obstoječega koncepta TK in usklajevanja interesov, zahtev in možnosti uporabnikov in izvajalcev storitev.
V sedanji organiziranosti Službe je bil povezovalni člen med uporabniki in plačilnim prometom oddelek preventivne kontrole, vendar zaradi preobremenjenosti s kontrolno funkcijo in medorganizacijsko (funkcijsko) ločenostjo ta komunikacija ni funkcionirala optimalno. Dobro bi bilo, ali bi ta problem funkcijske povezanosti s prihodnjo organiziranostjo Službe rešili.
Že od uvedbe TK načina prenosa podatkov naprej se srečujemo s podobnimi težavami in problemi, tehnološke rešitve samega zajema in prenosa podatkov pa se do danes bistveno niso spremenile. Če bi hoteli obdelati vse naloge plačilnega prometa prejete od imetnikov računov v podružnici Ljubljana po TK načinu (teh pa je bilo v letu 1990 45.890.772, kar je približno 40 % vseh obdelanih nalogov v SDK R Sloveniji, približno enak odstotek obsega dela pa odpade tudi na ostala opravila v plačilnem prometu), bi bila nujna posodobitev obstoječe tehnologije dela in opreme, saj trenutno zajemamo na tri različne načine (preko PC, S1 in S1 z EDX operacijskim sistemom). Vsekakor je to primer, kako se množična obdelava NE sme delati. Če k temu dodamo še dva različna kontrolna programa (TK in TEZAURUS), obilo različnih plačilnih instrumentov in načinov izvršitve, potem lahko v bližnji prihodnosti pričakujemo zrušitev sistema, če ne bomo v doglednem času nekaj ukrenili.
Kot prvo je treba takoj začeti aktivnosti, da prenehamo pošiljati naloge po TK-4 načinu, saj je bil ta način izvršitve ob uvajanju TK prenosa sprejet kot začasna rešitev. Tovrstni način dela nam povzroča največ problemov in težav pri TK obdelavi. V letu 1990 je podružnica Ljubljana obdelala 4.410.467 nalogov po TK, od tega jih je bilo 2.488.525 po TK-4 načinu ali 56 %. Namesto da bi se odstotek TK-4 nalogov manjšal in povečevalo število TK-1 nalogov, smo v Službi ustvarjali trend ravno v obratni smeri. Enako stanje je tudi v letu 1991, čeprav za to ni nobenih razumnih vzrokov, temveč so bile razvite nove rešitve, ki omogočajo hitrejši zajem podatkov po TK-1. Tudi če pregledamo prejete originalne naloge po TK-4, lahko kaj hitro ugotovimo, da ima velik del teh nalogov vse pogoje, da bi bili izvedeni po TK-1 načinu, vendar to iz takšnih ali drugačnih vzrokov ni tako.
Kot drugo pa bi morali intenzivneje pristopiti k informiranju podjetij ter nazornemu prikazu prednosti in koristi, ki jih prinaša tak način prenosa podatkov, ter pravočasno opozoriti uporabnike na pomembnost posameznih podatkov v desnem delu virmanskega naloga (predvsem vezna oznaka in sklicevanje na številko). Za uspešno delo pa bi morali akcijo izvajati koordinirano na celem območju R Slovenije.
Kot tretje pa bi morali delavci interne kontrole posvetiti več pozornosti na pravilno izpolnjevanje podatkov, ki so pomembni za TK prenos. To so predvsem podatki »sklicevanje na številko« in vezna oznaka, ter na vse napačno izpolnjene podatke opozoriti predlagatelje virmanskih nalogov in zahtevati, da so naslednjič ti podatki pravilno formirani in vsebinsko ustrezni.
Če bomo od julija 1991 dalje prenašali naloge (tiste, ki izpolnjujejo te kriterije) le po TK-1 načinu, si vsekakor ne bi smeli dovoliti pošiljanja nalogov po TK-4 načinu, če obstajajo na takem nalogu podatki, ki omogočajo TK-1 prenos. Če bi obdelali vse naloge po TK-1 načinu, to ne bi smel biti vzrok za dodatno - tretjo izmeno, ker bi bilo treba okrepiti popoldansko izmeno, ki bi pretežno skrbela za kontrolo vnesenih podatkov, s tem pa bi lahko zmanjšali tudi odstotek napak in reklamacij, hkrati pa bi odpadlo klasiranje nalogov za pošiljanje po pošti za kompletiranje TK-4.
Vzroki, ki nam ovirajo pravočasno končanje obdelave in s tem nakazujejo potrebo po tretji izmeni, so predvsem pozen sprejem zadnjega preseka prejetih TK nalogov od SDKJ iz Beograda in dodatne zadolžitve Službe v večernih urah (reševanje likvidnosti bank) ter občasno tudi okvare računalniške opreme.
Če pa bi se pokazalo, da celotnega dela ne moremo opraviti v predvidenem času, pa ne bi smelo biti problematično dodatno zaposlovanje delavcev na področju plačilnega prometa, saj vsi vemo, da je to ena od vitalnih funkcij Službe in je bila vedno argument, s katerim smo lahko zagovarjali obstoj Službe družbenega knjigovodstva in opravljanje plačilnega prometa v neodvisni instituciji.
Glede na to, da živimo v dobi informacijske tehnologije, kjer so pravočasne in točne informacije najbolj iskano in pomembno blago, kar pa vsekakor so informacije o prilivu oziroma odlivu denarja na žiro računu, se bomo morali počasi zavedati dejstva, da nam ni dano za vedno in samo nam opravljanje plačilnega prometa. Verjetno se bo tudi na tem področju čez čas pojavila konkurenca, ali pa si bodo uporabniki naših storitev poiskali alternativne rešitve (tako kot RTV Slovenija) in z nekom drugim sklenila posel, ki ga je do nedavna opravljala Služba, pa se zaradi svoje togosti ni mogla prilagoditi zahtevam in potrebam uporabnikov. V podružnici Ljubljana se je že več podjetij oglasilo z željo, da bi jim Služba zajemala podatke (sklicevanje na številko odobritve) ter posredovala tako zajete podatke na magnetnih medijih za njihovo nadaljnjo uporabo. Vendar ker nam obstoječe tehnološke rešitve ne omogočajo takega načina dela (lokalni TK za določenega uporabnika), smo jim ponudili le obstoječe rešitve, ki pa vsekakor niso zadovoljile pričakovanj. Zaradi svojega obstoja in preživetja pa so na ta način prisiljeni iskati druge rešitve zunaj SDK, kar pa vsekakor ni v korist Službi.
Ni komentarjev:
Objavite komentar