CASE + CAST = APS

November 1991

Temeljite spremembe pri poslovanju so v preteklih letih doletele prenekatero firmo, predvsem z uporabo računalniško podprtih aplikativnih sistemov. Spoznanje, da računalnik ne omogoča v najboljšem primeru le podporo operativnemu delu, kot moderen knjigovodski stroj, je danes prisotno v mnogih podjetjih, ki se borijo za svoj tržni delež. Poudarek je na sprotnih (online) aplikativnih programskih sistemov (APS).

APS in ustrezna računalniška podpora postajata vse bolj zahtevni in kompleksni nalogi ter občasno presegata trenutne zmogljivosti, tako človeške kakor tudi strojne. Dodatna komplikacija in nevarnost je tudi hitrost, ki jo morajo dosegati ljudje, APS in strojna oprema s ciljem spremljanja tekočega dogajanja in konkurenčnosti.

To je čas, ko se je pojavil CASE (Computer Aided Software Engineering) kot ključ, nekateri so ga imenovali kar čudežni, ki bo rešil vse ali skoraj vse probleme in težave pri razvoju in vzdrževanju APS. Lahko se je našlo celo ekonomsko opravičilo, saj so reklame in oglasi za CASE orodja obljubljali mnogo, predvsem za majhen denar.

Jasno je, da od celotne in vsestranske rešitve CASE v praksi pokriva le zgodnje načrtovanje in razvoj APS v njenem celotnem življenjskem ciklusu. Za postopke testiranja, ki so izjemno pomembni za izdelavo čiste in zaupanja vredne programske kode pred samo uporabo v rednem delu, je CASE naredil bolj malo. CASE sam po sebi in kot tak ne more izdelati kvalitetnega in zanesljivega APS.

Ali je morda CAST (Computer Aided Software Testing) manjkajoči člen za normalno pot pri razvoju, testiranju in uvajanju orodij za celovite (integralne) pakete? Vsekakor sta CASE in CAST izdelana približno hkrati. Toda poznavanje in razumevanje obeh je bistveno različno.

CASE je način - metodologija za avtomatično in kompleksno testiranje vseh funkcij pri razvoju novega ali spreminjanju obstoječega APS. S pojavom CASE tehnologije se bistveno povečala hitrost izdelave novih in predvsem zahtevnost APS. To pa je tudi povečalo problemi testiranja, ki je bil potisnjen na rob razvoja in uporabe APS.

Nujno zlo med izdelavo APS je testiranje, čeprav proizvajalci CASE opreme o nepogrešljivosti ravno njihovega produkta vedo povedati vse najboljše. Tragično je, ko se slabo testirani programi prenesejo v produkcijo. Lep primer je firma American Airlines, ki je zaradi programske napake v sistemu rezervacij (booking) v pičlih 3 (treh) mesecih imela ca. 50 mio USS izgube! Prav zato, da se prepreči podobne napake, so mnogi pripravljeni investirati v programsko opremo za testiranje.

In kje je rešitev? Odgovor je treba iskati tudi v boljšem vzdrževanju APS. Znani so podatki, da se tudi do 50% vseh stroškov neke APS porabi za njeno vzdrževanje. To ni le nesmiselno in absurdno temveč tudi neuspeh za organizacijo in izdelavo samega APS. Redki so uporabniki, ki realno ocenijo, da je testiranje APS zelo pomemben korak pri razvoju APS. Vsak napor in strošek se kasneje obrestujeta.

Trditev, da je testiranje med razvojem nepotrebno (podaljšuje čas izdelave, viša stroške), ni resna. Če se testira sproti in med razvijanjem, se vse odkrite napake popravi takoj in ne šele pri prekinitvah med rednim delom.

CAST naredi testiranje bolj vodljivo, uspešno in omogoča uporabniku izdelavo načrta testiranja v vsakem trenutku razvoja ali uporabe APS. CAST vsebuje štiri tehnike testiranja: (1) diagnostiko napak, (2) interaktivno popravljanje, (3) avtomatizirano testiranje in (4) uporaba podatkov - datotek. V CAST okolici so na razpolago orodja, ki skupaj s CASE omogočajo dobro in kvalitetno izdelavo APS.

Razvoj aplikacijskih programskih sistemov z uporabo CASE in podobni orodij se ocenjuje in meri z meseci in leti oziroma  kako hitro se izdela APS v primerjavi z običajnimi metodami. Nasprotno, pri CAST uporabljamo minute in kvečjemu še ure kot mero uspešnosti pri odkrivanju napak. Nekatere APS lahko obsegajo nekaj deset ali celo sto sprotnih, on-line, interaktivnih programov, ki jih je treba testirati. Kar nekaj pripomočkov je na razpolago, ki olajšajo to mukotrpno delo.

Običajno lahko celotno testiranje opredelimo z naslednjimi štirimi metodami:

1. diagnostika napak,
2. interaktivno popravljanje,
3. avtomatizirano testiranje,
4. uporaba podatkov - datotek.

Bistveni postopki obsegajo naslednjih pet korakov:

1. testiranje posameznega programa,
2. združevanje več že preizkušenih programov v zaokroženo celoto,
3. spreminjanje programov, da se prepričamo v predvidene (napačne ali pravilne) rezultate,
4. vzporedno delovanje dveh ali več programov in dveh ali več uporabnikov istega programa ter opazovanje vseh negativnih efektov, pa čeprav takšen način dela morda nikakor ni možen pri rednem delu,
5. obremenitev SW in HW kot v normalnem delovanju.

Eden med pomembnimi in bistvenimi faktorji aplikativnega testiranja je tudi delovanje v ekstremnih pogojih. Tako kot avtomobilska industrija testira in preobremenjuje nove izdelke pred redno proizvodnjo in prodajo, tako je treba tudi APS »obremeniti« - intenzivna uporaba, maksimalno število uporabnikov, velike količine podatkov in podobno.

Celovito testiranje pa ni prisotno le med razvojem programov in APS. Upoštevati je treba tudi hiter razvoj strojne opreme. Res je, da je kompatibilnost od starega na novo zagotovljena že s strani proizvajalca strojne opreme. Vprašanje pa je, če neki stari APS res dobro izkorišča novo strojno opremo. Ko pride do odločitve, da se mora APS prilagoditi novim značilnostim strojne opreme, potem to ne sme na noben način vplivati na delo uporabnikov - spremembe ne smejo niti zaznati, kaj šele, da so pri tem moteni.

Tako zanesljiv in gladek prehod na spremenjeni APS lahko olajša tudi uporaba CAST pripomočkov. Tehnično gledano, uporaba CAST ni težka ali problematična. Največji problem je v tem, da se vsi, ponudniki in uporabniki CASE, ne zavedajo dovolj kaj je učinkovito testiranje. Načrt testiranja in testni podatki morajo biti določeni v vsaki fazi razvoja APS. Kot rečeno, hierarhija testiranja se prične pri posameznem programu in se zaključi kot vsestranski test celotnega APS v resnični okolici delovanja.

Prednosti pripomočkov CAST so nesporne: bistveno skrajšajo čas izdelave APS, odkrijejo napake, vse skupaj pa poceni celoten »proračun« določenega APS. Vsekakor ni razlogov za tekmovanje med CASE in CAST. CAST je dopolnilo CASE, oba skupaj nudita čist dizajn in razvojne prednosti ter zmanjšujeta morebitne možnosti napak - rezultat je boljši APS. Poudarek mora biti na celotnem področju uspešnosti: hiter razvoj, dobro testiranje, zadovoljstvo končnega uporabnika ter natančnost, točnost in ažurnost podatkov.

Stroški ali investicija ?

Koliko stane razvoj in izdelava nekega APS? Kakšna je končna cena APS? In kolikšni so stroški vzdrževanja posameznega APS? Ali je takšen način razmišljanja že prešel meje naše države? In če je že v naši okolici, ali je prodrl tudi v SDK?

To je le nekaj vprašanj, na katera skuša ta zapis odgovoriti in nakazati možno smer izboljšanja. Kot osnova so služili tuji članki na to temo v revijah DATAMATION, COMPUTERWORLD in IBM COMPUTER TODAY. Težišče se suče okoli vzdrževanja, predvsem pa kako zmanjšati te stroške.

Spreminjanje APS (Aplikacijskega Programskega Sistema) ali programa s ciljem, da odpravimo ugotovljene napake ali spremenimo njegove funkcije, imenujemo vzdrževanje (angleško: maintenance). Ne ravno najbolje izbrana beseda, saj pri vzdrževanju APS ne odpravljamo okvar ali obrab zato, ker smo pač APS ali program uporabljali, temveč gre za izboljševanje kvalitete in njegov razvoj. V članku je obravnavano le področje vzdrževanja APS in programov, kar pa ne pomeni, da tudi ostala področja delovanja vsakega računskega centra in le računskega centra, ni možno racionalizirati.

Danes se porabi preveč časa za vzdrževanje obstoječih APS, namesto da bi razmišljali o načinu, kako zmanjšati stroške takega vzdrževanja. Nekatere ocene se sučejo do 50% vseh izdatkov v AOP - vključno s strojno in programsko opremo ter plače zaposlenih, torej vse, kar je posredno ali neposredno povezano z vzdrževanjem.

S pojmom strošek razumejo v deželah z razvitimi informacijskimi in računalniško podprtimi sistemi vse tisto kar da končnemu izdelku - APS določeno vrednost.

Vzdrževanje obsega do 75% vseh izdatkov uporabe nekega APS. To pa so sredstva, ki bi se lahko koristneje uporabila pri razvoju novih APS.

Ti visoki razvojni in vzdrževalni izdatki pomenijo, da z zmanjšanjem vzdrževalnega časa veliko prihranimo. Če se za vzdrževanje v resnici porabi do 75% sredstev, časa in napora, bo zmanjšanje vzdrževanja le za 30% podvojilo obseg časa, ki je na razpolago za razvoj. Vzdrževanje se lahko zmanjša tudi z uvajanjem takih postopkov razvoja, ki pozneje zmanjšujejo stroške vzdrževanja.

Proces vzdrževanja spremeni obstoječi APS toda ohranja njegove prvotne in osnovne funkcije nespremenjene. Takšno vzdrževanje lahko

• odstrani skrite in novo odkrite napake,
• poveča učinkovitost,
• prilagodi APS spremembam v okolici,
• spremeni APS z dodajanjem ali brisanjem njegovih delov.

Vsako vzdrževanju APS opravimo v treh stopnjah:

1. Oseba ali osebe morajo razumeti zahtevano spremembo v APS,
2. Zahtevana sprememba mora biti narejena in
3. APS mora biti ponovno pregledan (verificiran), če je sprememba zadovoljila zahtevek za spremembo.

Te tri stopnje težko izvedemo na starem, zastarelem APS, kar seveda pomeni, da je vzdrževanje izjemno zahtevno in težko izvedljivo delo. Če program ni pisan v strukturirani in "top-down" obliki, je precej problematično uspešno in zadovoljivo izvršiti tudi najmanjšo spremembo. Praktično nemogoče pa je pravilno spremeniti eno samo inštrukcijo, če se ne da ugotoviti, kaj sploh program dela in čemu služi.

Področja in načini, kjer in na kakšen način lahko vplivamo na vzdrževanje in stroške, so naslednji:

• Izboljšati dokumentacijo obstoječih APS.
• Ena kvalitetna sprememba namesto večkratnega popravljanja.
• Načrtovanje, kontrola in le neobhodne spremembe.
• Strukturirana oblika in programske tehnike.
• Orodja četrte generacije.
• Luč na koncu tunela.
• APS je premoženje.

Jasno je, da so obstoječi APS osnova za začetek zmanjševanja stroškov vzdrževanja. Seveda pa ti APS niso tudi kandidati za skorajšnjo zamenjavo ali odpis. To pa pomeni, da bodo služili še nekaj časa svojemu namenu in zato bodo tudi deležni določenega vzdrževanja. Ključ je v obstoječih APS in v izvajanju kvalitetnih sprememb, ki bodo vodile k lažjemu (cenejšemu ?) vzdrževanju tudi v prihodnje.

Izboljšati dokumentacijo obstoječih APS

Po nekaterih ocenah porabijo tehnologi med 40 - 65% svojega delovnega časa za študiranje in proučevanje dokumentacije in logike programov.

Tehnolog je delavec RC. Odlikuje ga odlično poznavanje strojne in programske opreme v RC. Suvereno obvlada "orodja" za obdelavo podatkov, ima informacijsko znanje in če pozna podatke, potem sta z uporabnikov idealna sodelavca.

Dokumentacija je najpomembnejše orodje in sredstvo, da tehnolog razume zgradbo in delovanje APS. Toda ta ista dokumentacija ima le neznatno vlogo pri projektiranju in razvoju. Četudi je dokumentacija bila napisana, običajno izkazuje KAJ je bilo narejeno, ne pa KAKO in ZAKAJ je bilo narejeno.

Tehnolog izvrši nedokumentirano spremembo, nato pride drugi tehnolog, ki mora ugotoviti posledice te spremembe. Ker običajno ne zaupa dokumentaciji, skuša razumeti in tolmačiti izvirno kodo in tako tudi delovanje celotnega APS.

Prednost lahko dosežemo že z izboljšanjem dokumentacije. Dokumentiranje APS nam lahko nudi informacijo, ki bo kdaj drugič koristna pri odločitvi, ali je APS že v taki fazi razpadanja, da ga lahko upravičeno pričnemo projektirati in izdelovati na novo.

Zelo pomembno pa je dokumentiranje sprememb na takšen način, da bo v bodoče bistveno olajšalo, izboljšalo in predvsem pocenilo vzdrževanje. Ti vzdrževalci bodo hitro razumeli vsebino in delovanje APS, predvideli morebitne nezaželene in predvsem nepredvidene stranske učinke že pred samo dejansko izvršeno spremembo.

Ena kvalitetna sprememba namesto večkratnega popravljanja

Hitro krpanje je današnja pogubna praksa. Najuspešnejši pri takem krpanju so tisti tehnologi, ki želijo hitro rešiti težave, ne glede na izgube in se čimprej vrniti k svojemu trenutnemu delu - projektiranju ali programiranju novih APS. Tako delo lahko primerjamo z beračevo suknjo, s krpo na krpi, ki takoj razpade, ko popusti šiv prve krpe.

Takšen način vzdrževanja in dela ustvari situacijo, da krpanje napak povzroči nove napake: vedno ko se izvršijo programske spremembe je tudi velika verjetnost, da se pri tem naredijo nove napake.

Razlog je v tem, da se popravljanje izvede hitro, v časovni stiski in brez določenega reda. Z vlaganjem določenega napora lahko dosežemo kvalitetne spremembe, saj le premišljeno izvedeno popravljanje ni povezano z novimi napakami. Na splošno drži, da se z reševanjem najbolj težavnih problemov izognemo dodatnim težavam v bodoče. Nekateri podatki kažejo, da z odpravo 20% najtežjih problemov rešimo morda do 80% bodočih problemov.

Kvalitetni popravki lahko izboljšajo poročila - rezultate za uporabnike. Uporabniki vedno kaj pričakujejo: dobro in slabo. Napačna ali nepopolna sprememba lahko povzroči nemir in nezaupanje uporabnika. Vzdrževanje, tj. sprememba APS, naj bi se izvajala "skupinsko", tj. več sprememb skupaj. Povezovanje posameznih sprememb omogoča njihovo natančno proučitev, podrobno analizo problema, samo spremembo in testiranje.

Uporabnik je oseba, ki uporablja storitve RC. Je odličen poznavalec podatkov, suvereno obvlada ustrezna "orodja" za obdelavo teh podatkov, je strokovnjak na svojem področju in če ima poleg tega še informacijsko znanje, potem je idealen sogovornik tehnologu.

Takšno grupiranje sprememb opozarja uporabnika in tehnologa na možne posledice in vplive na delovanje celotnega APS. Ob tem se skrajša tudi čas testiranja, saj se vse spremembe istočasno preverijo. Več takih posegov lahko postopoma pripelje tudi do večje zanesljivosti APS.

Načrtovanje, kontrola in le neobhodne spremembe

Največji delež stroškov vzdrževanja gre na račun sprememb, ki menjajo osnovno funkcijo APS. Sprememba funkcije je lahko rezultat uporabnikove pretirane domišljije ali pa slabo definiranih zahtev pri projektiranju. Uporabnik si običajno sploh ne predstavlja ekonomskega učinka svoje zahteve za spremembo APS. Najboljši način za kontrolo sprememb in njihovo zmanjševanje je obračunavanje in zaračunavanje stroškov naročniku sprememb.

Zviševanje stroškov pri vzdrževanju je najbolje nadzorovati tako, da ima uporabnik proste roke pri vsaki spremembi in seveda točne podatke, koliko ga bo sprememba stala. Te stroške mu posredujejo tehnologi. Odločitev, ali se ta sprememba izplača glede na predvidene stroške izvedbe spremembe in pričakovane rezultate po taki spremembi, sprejme uporabnik, ki je naročnik in plačnik. Takšen način dela mora zavreči vse tiste želje po spremembah, ki ne predstavljajo popravljane napak, so le "kozmetične" narave, predstavljajo pa kar opazne finančne izdatke.

Tudi vodstvo mora planirati in kontrolirati vzdrževanje. Treba se je odločiti za spremembe, ki so profitne: nek star APS, ki se bo kmalu zamenjal, drug obstoječ APS, za katerega se že izdeluje nov, ali pa tretji APS, ki se bo moral zamenjati, pa za to še ni nič narejenega. Za vse pa uporabniki zahtevajo vzdrževanje in spremembe.

Ključ za zmanjševanje bodočega vzdrževanja je v izdelavi novih APS na način, ki za vsak morebitni poznejši poseg ne zahteva visokih stroškov. To so predvsem sodobni načini in orodja za razvoj in izdelavo APS.

Strukturirana oblika in programske tehnike

Nesporno drži, da se APS, ki je bil razvit in izdelan strukturirano, dvakrat lažje vzdržuje. Pomembno pri tem je, da se že pri projektiranju upošteva morebitno poznejše vzdrževanje. To pa se doseže s ti. strukturiranim načinom razvoja (designa) in same izdelave (programiranje).

Tako izdelan APS omogoča tehnologu kvalitetno izvršeno spremembo v relativno kratkem času in ne nazadnje tudi stroškovno ceneje. APS mora imeti od strojne opreme (hardware) odvisne dele izločene od čiste aplikacijske kode. Podobno velja za odvisnost od operacijske opreme (sistemski software): osamitev takih rutin v ločene interne ali eksterne module v primeru modifikacije bistveno olajša celoten postopek vzdrževanja. Podobno velja tudi za neodvisnost od delovnega okolja uporabnika: razni šifranti podatkov, konstante vezane na določeno lokacija itd.

Tudi dosledna uporaba nekega splošno priznanega in uporabnega standarda za aplikacijski razvoj in programiranje lajša poznejše vzdrževanje. Vsak tehnolog, ki pozna in obvlada takšen standard, lahko z minimalnimi napori spozna in razume delovanje APS. To pa je tudi nujno potrebni osnovni pogoj za kakršnokoli uspešno intervencijo - spremembo. Ne gre prezreti, da z strukturiranim dizajnom in programiranjem izdelamo APS z minimalno zapletenostjo, kar vodi k minimalnim napakam.

Orodja četrte generacije

Sama uporaba aplikacijskih generatorjev - jezikov 4 generacije (Fourth Generation Languages - 4GL) sicer ne odpravlja problemov vzdrževanja, jih pa reducira na najmanjšo možno mero.

Aplikacijski generatorji jezikov četrte generacije lajšajo vzdrževanje zlasti zaradi

• programska koda je brez napake,
• absolutno čista APS koda,
• prisiljena standardizacija in
• avtomatična izdelava standardne dokumentacije.

Poleg navedenega pa 4GL olajšajo sporazumevanje med uporabniki in tehnologi. 4GL omogoča tehnologu hitro izdelavo prototipne rešitve, ki jo je ob skupni analizi z uporabnikom enostavno popraviti in izpiliti. Na tak način iz uporabnika lahko "izvleče" njegove resnične potrebe in želje, ki se jih v projektnem zahtevku le sluti. To pa tudi pomeni manjše možnosti za spremembe ali vzdrževanje v prihodnje. Velja pa opozorilo: uporabnik mora stalno bedeti nad razvojem APS, saj so 4GL še kako pripravni za izdelavo napačnih aplikacijskih in programskih rešitev.

Luč na koncu tunela

Velika večina tehnologov - vzdrževalcev glede na probleme pri vzdrževanju nekako takole:

• intelektualno in tehnično težko in naporno delo,
• nehvaležno, ker ni potrebnih podatkov za uspešno delo,
• brezuspešno, saj se bodo uporabniki vračali z vedno novimi problemi,
• delo brez konca in
• prikrajšani za tehnološki napredek.

Ti razlogi, včasih upravičeni in razumljivi, lahko negativno vplivajo na delo tehnologov. Da bi jih motivirali in tudi zadržali, mora vodstvo poskrbeti za "luč na koncu tunela". To so predvsem dobri in ustrezni pogoji za delo: lasten ekranski terminal ali ustrezen in zmogljiv osebni računalnik, prost dostop do potrebnih računalniških resursov itd. Drug način kako narediti vzdrževanje privlačnejše je sprememba v funkciji vzdrževanja. Avtor določenega APS je vsekakor najprimernejši vzdrževalec le-tega. Toda, ali to želi in hoče? Odvisno od človeške narave, potreb, želja in ambicij. Večini je vzdrževanje odveč. Rešitev je, da se "avtorju" dodeli kot pomoč sodelavca z osnovno nalogo vzdrževanja, "avtor" je tako delno razbremenjen toda vseeno prisoten, mu pa ostane dovolj časa za delo na novem APS, šolanju itd.

APS je premoženje

Tipičen tehnolog porabi zelo malo (recimo 1%) svojega časa za vzdrževanje, nekaj več (recimo 30%) za nove APS, bolj ga zanima, da čimprej spravi svoj APS v obdelavo in tako "požanje" slavo, ker je uspešno ujel rok izdelave, kakor pa da bi "videl" vsaj malo čez svoj nos v prihodnost in pričakovane probleme vzdrževanja. Pri tem mu lahko pomaga tudi vodstvo z ne dovolj stalno in strogo kontrolo nad njegovim delom.

V svetu je izvorna (source) programska vrstica ocenjena med 5 in 50 US$. To spoznanje le počasi zmanjšuje miselnost, da je APS le strošek, prikazan, če seveda je, kot negativna postavka v bilanci podjetja. Toda APS nikakor ni pasivna postavka kakor tudi stroški vzdrževanja niso vedno negativna. Vzdrževanje kot tako nikoli ne izkazuje direktnega profita, je pa bistveno za uspešno delovanje APS, kar pa je profitno.

Dobro premišljeno vzdrževanje veča vrednost APS. To spoznanje pa upošteva APS kot pravo osnovno sredstvo. Zavedati se je treba pomembnosti in vrednosti APS, kaj je to, kako deluje, da ima svojo ceno in vrednost, ki pa se lahko tudi "pokvari". Takrat pa nastopi vzdrževanje s ciljem za kvalitetnim, hitrim in poceni opravljenim delom.

September 1992

Prihodnost v informatiki

Vsaka obletnica, bodisi osebna ali obletnica delovanja organizacije, nas nekako sili k temu, da vsaj pri sebi napravimo neke vrste obračun uspešnosti za to obdobje. To še toliko bolj, če je obletnica okrogla in visoka. O svojem delu in delovanju organizacije sicer letno poročamo, vendar so ta poročila pripravljena za drugačen namen in tudi za drugo publiko kakor razmišljanja o dosežkih in uspehih v času, ki ga označuje jubilej. Zato so primerno suhoparna in ni slučajno, da izhajajo kot uradna priloga Obvestil. Prav jubilej pa je priložnost, da predstavimo svoje delo in rezultate javnosti, obenem pa tudi razmislimo, kakšne cilje naj določimo kot usmeritev za delovanje v prihodnje. Iz dneva v dan se sproti niti ne zavemo, da se imamo s čim pohvaliti, ker smo zaradi nalog, ki jih vidimo pred seboj, veseli, da je vsaj ena opravljena, zato je jubilej dobrodošla prilika tudi za to, da prikažemo dosežke na bolj prijazen način.

Ko pregledujemo in seštevamo dosežke minulih tridesetih let, se nehote spomnimo, da smo - vsaj zazdi se nam tako - še ne tako dolgo tega, ob petindvajsetletnici službe družbenega knjigovodstva, napravili prav nekaj podobnega. Odveč bi bilo zato ponavljati vse, kar je bilo rečenega in napisanega za tisto priložnost. Raje se bomo ozrli na pet let, ki so minila od tedaj, in pogledali, ali so dosežki v tem času vredni omembe ob jubileju. Navzven morda najbolj vidna sprememba, ki zadeva organiziranost informatike v službi, je v tem, da sta se združila centrala in skupni elektronski računski center centrale in podružnice Ljubljana, ki je tako postal sektor za računalniško obdelavo podatkov.

Informacija je postala že samostojna stroka, ki je vse kaj več kot zgolj uporabljanje računalnikov. Ker se je razvila iz uporabe računalnikov, torej pač zaradi tradicije in pa zato, ker je to tako rekoč najbolj otipljivi del informatike. Poglejmo najprej, kaj smo dosegli pri opremljanju službe z računalniškimi napravami. V preteklih petih letih je bilo zamenjanih deset računalniških sistemov v podružnicah druge in tretje velikosti z novimi, tehnološko sodobnimi in bistveno bolj zmogljivimi. O tem priča tudi dejstvo, da so imele podružnice Koper, Novo mesto, Nova Gorica in Murska Sobota po dva računalnika, večje število obdelav pa se sedaj izvaja na enem računalniškem sistemu. Z zmogljivejšimi so bili zamenjani računalniki velikih podružnic in centrale, poleg tega pa so bile vsako leto nabavljene različne periferne enote računalniških sistemov, ki so zamenjala izrabljene ali je bila z njimi povečana zmogljivost celotnega sistema.

Eno od smeri razvoja računalniških naprav, osebne računalnike, uspešno uvajamo tudi pri nas. Od prvih nekaj modelov, ki so bili nabavljeni v glavnem za potrebe razvijanja programov, smo prišli že do široke uporabe v vseh delih in funkcijah službe. Za sedaj se osebni računalniki uporabljajo kot samostojne naprave. Pričakujemo lahko, da se bo tudi v prihodnje uporaba širila tako po številu uporabnikov in naprav kakor po področjih in namenih uporabe in da bo vse več možnosti za prenos podatkov med njimi in velikimi sistemi. Uspešni poizkusi nas v tem potrjujejo.

Na področju komunikacij je služba ena od prvih organizacij, ki je poleg tega, da je bila soinvestitor javne mreže za prenos podatkov, začela to mrežo tudi redno uporabljati za prenos podatkov in interaktivno delo z oddaljenih lokacij v dveh podružnicah. Vozlišče v Ljubljani je bilo ena od prvih treh aktivnih vozlišč računalniške mreže Službe družbenega knjigovodstva. Nedavno tega je bil opravljen uspešen preizkus prenosa podatkov med računalnikoma Unisys in IBM, kar bo omogočilo nadaljnje povečanje števila slovenskih podružnic, ki se bodo lahko povezale v računalniško mrežo. Računalniška mreža bo tudi omogočila neposreden vpogled v zbirke podatkov, ki jih služba zbira in jih bo lahko ponudila, ko bo to omogočeno tudi z navodili.

Projektiranje aplikacijskih programskih sistemov in programiranje sta vedno aktualni področji informatike. Smer razvoja v razvitih državah na tem področju je delo z bazami za upravljanje s podatki in uporaba programskih jezikov četrte generacije.

V zgornjem pregledu dosežkov smo podali le tiste, ki se nanašajo na zadnjih pet let ali manj in ki so pomembni za razvoj in delo vnaprej. Videti je, kakor da se hvalimo, in dejansko se. Rečemo lahko, da je informatika v naši službi na strokovnem nivoju, kakršnega dosegata morebiti le še dva druga računska centra v službi, pa tudi v bližnji okolici jih ni prav dosti, ki bi nas v tem pogledu presegali. Uspehi seveda obvezujejo, do njih pa ne prihaja slučajno. Na to kaj smo dosegli, vplivajo različni faktorji na različne načine. Faktor, ki vpliva pozitivno, je izobraževanje in neprestano strokovno usposabljanje. To področje je zadovoljivo urejeno in prizadevati si moramo, da v prihodnosti ne bi prišlo do poslabšanja. Manj smo zadovoljni s tehničnimi in prostorskimi pogoji.

Ker so strokovni uspehi zelo močna motivacija, lahko rečemo, da bomo uspešni tudi v prihodnje, kolikor bo to odvisno od nas samih. Ob tem pa morajo biti izpolnjeni še objektivni pogoji, ki morajo ta osnovni pogoj dopolniti. Pri tem mislim na dolgoročne razvojne usmeritve za področje informatike, ki jih je služba sprejela, a jim zaradi različnih vzrokov, med katerimi finančni niso na zadnjem mestu, v celoti ne sledimo. Če naj bomo kot sektor in služba na področju informatike uspešni tudi v prihodnje, mora biti to omogočeno tudi tehnično, prostorsko in kadrovsko.



Oktober 1989

Mašinerija brez ljudi je staro železo

Za kratek razgovor smo prosili pomočnika generalnega direktorja za področje računalniške obdelave podatkov.

Podružnica Ljubljana je z novo organizacijsko shemo AOP formalno izgubila projektantsko in programsko ekipo, ki je opravljala svoje delo za vse podružnice v Sloveniji z IBM opremo. Boste po tej shemi na centrali organizirali tudi programiranje za podružnice z Borroughs računalniškimi sistemi?

Težko bi rekli, da je podružnica Ljubljana izgubila programsko in projektantsko ekipo, ki je pokrivala njene potrebe in potrebe drugih podružnic SDK v Sloveniji, kjer so instalirali računalniški sistemi IBM, z novo organizacijsko shemo sektorja za obdelavo podatkov centrale. Če uporabim vaš izraz, se je to formalno zgodilo že z ustanovitvijo skupnega elektronskega računskega centra centrale in podružnice Ljubljana, kar pa ni pomenilo, da podružnica Ljubljana ni imela na voljo strokovnjakov za računalništvo in seveda tudi ne pomeni, da jih ne bo imela v prihodnje. Vse storitve, ki jih je za podružnice Ljubljana opravljal SERC, bo v prihodnje opravljal sektor za obdelavo podatkov centrale. Z novimi računalniškimi napravami, ki so bile instalirane prav te dni, bo mogoče opravljati te storitve vsaj tako kvalitetno kot prej.«

Računalniške sisteme ima v tem trenutku vsaka podružnica v Sloveniji ne glede na morebitno nerentabilnost take organizacije. Predvidevate na tem področju kakšne spremembe?

Računalniški sistem v vsaki podružnici v Sloveniji je bil v času, ko je bil inštaliran, gotovo upravičen, saj moramo upoštevati tudi druge razloge, ne le ekonomskih. Najprej je treba verjetno izpolniti zahtevo, da morajo biti podatki plačilnega prometa obdelani dnevno ažurno. Vemo, da je računalnik sredstvo, ki to omogoča. Dejstvo pa je, da so danes na voljo tehnike in naprave, ki jih v času, ko se je obdelava podatkov v službi načrtovala, še ni bilo ali pa jih še nismo obvladovali. V tem smislu je treba ugotoviti, da je mini računalnik v SDK svoje poslanstvo opravil in da bo treba izdelati načrt za čas, ko bodo računalniki v podružnicah odslužili. Ob tem moram povedati še to, da nadomestitev računalnikov v podružnicah ne pomeni obenem kar avtomatične odprave delavcev, ki delajo na tem področju, predvsem organizatorjev in programerjev.«

Za organizacijski del analiz v SDK ste postali nepogrešljiv partner pri opravljanju njihove osnovne dejavnosti. Kontrola je ostala do sedaj še brez kakšne večje računalniške podpore. Mislite, da bi bilo tudi za kontrolo mogoče kaj več narediti in kaj?

Najbrž bi se dalo kaj več narediti, vendar se na to področje še najmanj spoznamo, ker smo s kontrolo bolj malo delali. Lani so izrazili željo, da instaliramo programe, ki bi jih uporabljali inšpektorji. Šlo je namreč za to, da bi dobili magnetni trak od uporabnikov družbenih sredstev, nato pa bi jih inšpektorji preko svojega programa analizirali. Nekaj poskusov je bilo, dlje od tod pa nismo prišli. Menim pa, da bi to lahko naprej razvijali in bi bilo še posebej koristno pri ocenjevanju periodičnih obračunov in ocenjevanju zaključnih računov. Najbrž bi se dalo narediti programski paket in izdvojiti preciznejše detajle, da ne bi bilo treba človeku premlevati vseh podatkov, od tu naprej pa bi jih analiziral inšpektor. Mi bi takšen program znali narediti, samo uporabniki družbenih sredstev bi morali specializirati svoje zahteve in tudi pobuda mora priti od njih.«

Obrazci plačilnega prometa so že nekaj časa v prometu v taki obliki, kot ga zahteva prihodnji TK prenos v SDK. Kako sodelujete pri realizaciji TK prenosa v SDK in kako bomo to izpeljali v Sloveniji?

Pri sami izvedbi TK prenosa ne sodelujemo, sodelovali pa smo v delovni skupini pri SDK Jugoslavije. Nadaljnje sodelovanje je namreč presegle naše kadrovske zmogljivosti. Precej smo se namreč angažirali pri razvoju programskih aplikacij sistema za spremljanje investicij. Če bi poslali eno ekipo še za realizacijo TK prenosa, bi se dnevno delo začelo zatikati, ne sicer pri plačilnem prometu, pri statističnih poročilih pa zagotovo. Sodelovali smo tudi pri prenosu na TK pri seriji 1. V eksperimentalni prenos nismo vključeni, mislim, da ob tem ne bo posebne škode, ker ne gre za obdelavo, ampak vnos in prenos podatkov, kar že dobro obvladamo. TK prenos naj bi 1. oktobra stekel, s 1. februarjem leta 1986 pa naj bi to uspelo tudi vsem podružnicam v državi.«

V SDK ste znani kot uspešen direktor skupnega računalniškega centra centrale in podružnice Ljubljana. Kako vam je uspelo vzdrževati stalno motiviranost zaposlenih, disciplino in obenem podporo sodelavcev?

Trudim se. Karkoli delam, nimam nikoli osebnih interesov. Vedno sem poskušal poiskati tiste rešitve, ki so za službo najboljše. Pozna pa se, da že dolgo delamo skupaj, da me delavci poznajo in da vedo, da nimam osebnih interesov. Ljudje sledijo tistemu, ki ve, kaj hoče. Pri motiviranosti pa smo vedno gledali na to, da smo delavce za dobro delo dobro nagradili. Predvsem se mi zdi pomembno, da nikoli nikogar ne podcenjuješ. Vedno smo bili širokogrudni za razne vrste nagrajevanja, nadurno delo smo vedno priznali in kompenzacija je bila vedno možna. Treba je imeti pošten odnos do delavcev in jim omogočiti tudi strokovno izpopolnjevanje, udeležbo na strokovnem seminarju ali razstavi in upam, da bodo te možnosti ostale tudi v prihodnje.«

Znano je, da redno spremljate razvoj računalništva v svetu. Kakšen trend je trenutno prisoten in kaj od tega bi bilo zanimivega za našo službo?

Zadnje čase spremljam razvoj računalništva na žalost bolj pasivno. Ogledal sem si Hannovrski sejem računalništva, kjer sem sicer veliko videl, saj je sejem prava paša za oči, bolj pa bi mi koristilo, če bi se udeležili kakšnega seminarja, kar pa je strahovito drago. Vendar če smo nekaj deset starih milijard dinarjev investirali v računalniško opremo, bi morali najti še nekaj sredstev za izobraževanje, kajti mašinerija brez ljudi je staro železo. V Beogradu sem se tudi pogovarjal z nekaterimi, ki so bili na SICOB v Parizu, in tudi oni so mi potrdili, da IBM kot vodilni ne razstavlja več računalniških sistemov. V začetku leta je IBM objavil sistem 3090, to je računalnik, katerega centralni polnilnik se začne pri 16 MB. Ta računalnik bi bilo zanimivo videti, pa ravno tega niso razstavili. Prikazali pa so, kako računalnik pri delu lahko pomaga človeku pri konstruiranju, načrtovanju, statistiki, vnosu podatkov pa tudi pri banalnih stvareh. Za SDK je zanimiva predvsem uporaba mikroračunalnikov. Pri nas se na tem področju stvari že premikajo. Za določene enote je bil namreč naknadno objavljen popust, zato smo kupili nekaj več ekranov in mikroračunalnik IBM PC za potrebe centrale. Omenjeni računalnik bo imel poleg standardnega programiranja še možnost priključitve na velik računalnik, obdelave teksta, grafični prikaz podatkov in drugo.

Kako gledate na poskuse uveljavljanja mikroračunalnikov v združenem delu in posebej v SDK?

To je edina možna pot naprej. Mikroračunalnike bi morali čim bolj uveljaviti in tako zmanjšati zaostanek za razvitim svetom. V službi družbenega knjigovodstva smo bili do sedaj že korak zadaj in zato smo veseli, da ima centrala SDKJ mikroračunalnike in da je naš generalni direktor pokazal izredno razumevanje za to področje.


oktober 1985

Ponovna modernizacija dela

September 1984

Sedanje stanje računalniške tehnologije obdelave podatkov in tehnike v SDK še ni zadovoljivo. Oporo bomo našli pri domači industriji.

Izvrševanje nalog v zvezi s plačilnim prometom, knjiženjem sprememb na žiro računih in evidenc plačilnega prometa je že vseh 25 let neločljivo povezano s tehniko. V tem obdobju je služba uporabljala pri svojem delu vse od mehanskih knjižnih strojev do računalniških sistemov in razvijala tehnologijo dela, ki je vedno optimalno vključevala razpoložljivo tehniko.

Delavci, ki letos praznujejo četrt stoletnico dela v službi, posebno tisti, ki so delali v plačilnem prometu ali družbenem računovodstvu, se prav gotovo dobro spominjajo takratne tehnologije dela. V podružnicah je bilo delo s prejemom, sortiranjem in pripravo plačilnih dokumentov oddvojeno od strojnega knjiženja. Osnova za knjiženje so tvorili dokumenti, ločeni na odobritve in obremenitve, sortirani po posameznih osnovnih računih DR (Družbeno Računovodstvo) in individualnih partijah. Plačilni promet je za tako pripravljene dokumente že izdelal konsignacijo, to je kontrolni seštevalni trak, ki je služil kot osnova za knjiženje v družbenem računovodstvu. Sistem kontrole sloni na dvojnem knjigovodstvu, zato se je moral promet v breme na vseh osnovnih računih ujemati s prometom v dobro. Vsak dan znova je ekipa v oddelku DR s strahom čakala na izid končnega seštevanja prometa po osnovnih računih. Najmanjša razlika je pomenila utrudljivo iskanje napake v celotnem gradivu tistega dne.

Plačilni promet je svojo nalogo priprave dokumentov za knjiženje končal običajno do 17. oziroma 20. ure. DR, ki je po tem času prevzel štafetno palico pa se je odvisno od natančnosti dela plačilnega prometa kot tudi delavcev pri strojnem knjiženju v DR, ubadal s knjiženjem, ki se je končalo z vlaganjem izdelanih izpiskov v predalčke uporabnikov, tja do 20. ure ali pa do 6. ure zjutraj.

Knjiženje prometa na individualnih partijah uporabnikov družbenih sredstev je bilo popolnoma ločeno od knjiženja razčlenjenega prometa za potrebe družbene evidence.

Edini medij za knjiženje so bile knjigovodske kartice. V oddelkih družbenega računovodstva je bilo zato vedno na kupe kartic, zloženih v kovinske zaboje ali vozičke.

Pogled v strojnico bivšega DR je bil zaradi množice mehanskih šklepetajočih strojev skoraj impozantnejši od današnjih lekarniško čistih in urejenih elektronskih računskih centrov. Ob vsakem stroju je stal voziček s kovinsko škatlo, v kateri so bile kartice za knjiženje. Knjiženje prometa in izdelava izpiskov je tekla na velikih, samostojnih knjižnih strojih, postavljenih drug za drugim kot tiskarski stroji v tiskarni. Razčlenjeni promet smo knjižili na malih namiznih knjižnih strojih, pravih pritlikavcih v primerjavi s prvimi. Cel sistem priprave in knjiženja je zahteval disciplinirano in natančno delo. Skrita napaka, ki je nastala v plačilnem prometu že dopoldne ali zgodaj popoldne, je bila odkrita šele po izdelavi končne bilance, torej ob primerjavi celotnega prometa v breme in dobro. Zaradi tega je bil delovni čas v plačilnem prometu in družbenem računovodstvu pravzaprav variabilen. Nič kolikokrat so se dekleta in fantje vračali z dela, ki so ga začeli že zjutraj, šele v poznih večernih ali celo jutranjih urah. Možje in fantje, v SDK so delala večinoma dekleta, so večkrat zaman čakali pred vrati podružnice. To slabo lastnost tedanje tehnologije so seveda dobro poznali vsi delavci v teh dveh organizacijskih delih. Medsebojna odvisnost delavcev, ki jo je narekovala taka tehnologija je zahtevala kar najboljše sožitje, stkala nič koliko pristnih prijateljskih zvez in naredila delovno in močno solidarnostno vzdušje v teh kolektivih.

Periodične in zaključne račune je služba obdelovala le na Centrali. Leta 1964 je bil postavljen v stolpnici na Kidričevi ulici, danes Štefanova ulica, prvi Univac, klasičen računalniški sistem. Vhodne podatke so luknjali na kartice. V računalniško konfiguracija je sodila še sortirka kartic, tabelirka in pa seveda sami luknjalniki kartic. Računalniški sistem je bilo mogoče programirati z ožičenjem programskih plošč. Ekipa delavcev iz AOP je-uspešno delala na njem skoraj deset let.

Leta 1970 se je SDK odločila za modernizacijo tehnologije dela, sklenjeno je bilo:

1. da se prenesejo na računalniško obdelavo podatkov vsa najbolj obsežna dela: plačilni promet, evidenca in statistična raziskovanja, pomembna za celo državo. Zagotoviti je bilo treba čim hitrejše kroženje denarnih sredstev in čim popolnejšo informiranje združenega dela in družbenopolitičnih skupnosti
2. da se sistem obdelave podatkov zastavi decentralizirano, torej po podružnicah, ker so pač le-te pri vsakodnevnem opravljanju dela, neposredno povezane z organizacijami združenega dela in DPS. Obdelava plačilnega prometa, to pomeni prejem, priprava in knjiženje naj bo v podružnicah. Podatki službe morajo predstavljati neposredno osnovo za informacijske sisteme družbenopolitičnih skupnosti in združenega dela
3. zagotoviti je treba enotno tehnologijo dela pri obdelavi vseh podatkov, ki so pomembni za vso državo
4. zagotoviti je treba celovito tehnično-tehnološko kompatibilnost računalniških sistemov v organizacijskih enotah službe
5. v drugi fazi avtomatizacije je treba zagotoviti povezavo elektronskih računalniških sistemov v podružnicah v enotno mrežo za TK prenos podatkov v službi.

Leta 1972 so v službo pričeli prihajati prvi računalniški sistemi. Ljubljana je dobila IBM 370/l35. Spominjam se še predloga, naj bi bila zmogljivost internega pomnilnika 64 K bytov, to je malenkost več, kolikor jo ima danes osnovna verzija hišnega računalnika Spectrum. Maribor, Celje in Kranj so dobili Singerjeve računalnike System 10. Za zajemanje podatkov je bila izbrana Datica. To je luknjalnik papirnatega traku. Nova tehnika je nujno zahtevala tudi spremembo tehnologije.

Zaradi računalniške kontrole usmerjanja sredstev je služba vsem uporabnikom menjala številko žiro in drugih računov. Neizkušenost in obremenjenost z ročno tehnologijo dela je povzročila nedoslednost pri določanju konstrukcije nove številke. Le-ta je sestavljena iz številke sedeža SDK, osnovnega računa in številke partije. Sistem kontrole zajemanja s kontrolno številko zajema le individualno partijo, izven take kontrole pa je ostala številka sedeža SDK in številka osnovnega računa po kontnem planu SDK.

Neizkušeni smo bili tudi pri določanju tehnologije kontrole pravilnosti zajemanja drugih podatkov. Kljub uvedenemu kontrolnemu seštevku, je bil ta seštevek, po zapisu podatka v prometno datoteko, zavestno iz puščen. Podatki so se sortirali kot prej dokumenti, v breme in dobro, narejena je bila končna bilanca in šele takrat je bilo znano, če je bilo zajemanje podatkov na Datikah v redu opravljeno.

Datičarka, kot smo imenovali operaterke na novih zajemalnih strojih, je lahko s pomočjo seštevka na začetku, kontrolirala pravilnost vpisanih zneskov. Ker pa je bil podatek luknjan na papirnati trak, napak ni mogla popraviti. Tudi napak pri prenosu številk partij ni bilo mogoče kontrolirati. Zato je v sistemu zajemanja in kontrole podatkov prišlo do faznega zamika, ki je razmaknil posamezne faze dela tudi za 8 ur ali več. Predpisana tehnologija je zahtevala previjanje papirnatih luknjanih trakov pred konvertiranjem na magnetni računalniški trak.

Opisane pomanjkljivosti so narekovale takojšnjo spremembo začrtane tehnologije in s tem tudi spremembo celotnega paketa programov za kontrolo in obdelavo podatkov plačilnega prometa. Skupaj z zunanjimi sodelavci iz Intertrada in IBM smo v SDK Ljubljana realizirali nov programski paket, ki je slonel na precej spremenjenih osnovnih principih zajemanja in kontrole podatkov.

Nova računalniška tehnologija je zahtevala drugačno organizacijo dela. Vpeljane so bile naslednje faze dela:

• priprava dokumentov
• luknjanje podatkov
• sistemska kontrola
• elektronski računski center
• sortiranje dokumentov in prilaganje izpiskov

Kljub precejšnjem izboljšanju začrtane tehnologije dela, nova tehnika ni prinesla pričakovanega učinka. Iskanje napake, končno bilanciranje, ki ga je opravljala sistemska kontrola, je bilo v veliki odvisnosti od števila in tipa napak. Namesto pričakovanega olajšanja, je tudi nova tehnologija zadržala variabilen delovni čas, ropot strojev, in še povečala odvisnost celega procesa obdelave od delovanja sedaj le enega stroja - računalnika. Prilaganje dokumentov izpiskom in konsignacijam, izdelanih na računalniškem sistemu je predstavljalo in to še danes, zadnjo fazo kontrole pravilnosti zajemanja podatkov.

Po šestih letih delovanja navedenih tehničnih sredstev in tehnologije dela se je služba odločila za precejšnjo spremembo. Zajemanje podatkov s kontrolo, ki je predstavljalo najzahtevnejše in obenem najbolj občutljivo fazo v celotnem sistemu obdelave plačilnega prometa, naj bo interaktivno in dislocirano od glavnega računalniškega sistema v velikih podružnicah. Napake, storjeno ob zajemanju, je treba odkriti takoj in popravi naj jo tisti, ki jo je tudi napravil. Formalna, logična in računska kontrola je bila vgrajena v kontrolni program na mini računalniških sistemih IBM S/1 in Burroughs 1800 s priključenimi ekranskimi terminali.

Šele taka tehnologija dela je izpostavila veliko učinkovitost računalniške tehnike. Skoraj čez noč so bile ukinjene nočne izmene, v katerih so delale večinoma žene in mladina. Znatno se je izboljšala kvaliteta našega dela, saj je padlo število reklamacij na neznatni minimum. Tudi ažurnost in učinkovitost se je precej povečala. Kot primer navedimo le podatek, da smo prej obdelovali zaključne in periodične obračune do nivoja federacije 3-5 mesecev, danes pa potrebujemo za tako delo na navedenem nivoju le še 15 dni.

Služba družbenega knjigovodstva v SR Sloveniji ima danes vgrajeno naslednjo računalniško opremo. V podružnicah Ljubljana, Maribor, Celje in Kranj računalniške sisteme IBM 370/ in 4331 ter za zajemanje podatkov IBM S/l z ekranskimi terminali. V ostalih podružnicah so za zajemanje in obdelavo računalniški sistemi Burroughs, tudi z ekranskimi terminali.

Vzporedno z opremljanjem s tehničnimi sredstvi za AOP je služba intenzivno pripravljala potrebne kadre, da bi vsa vlaganja v opremo dajala čim prej pričakovane rezultate. Služba se je orientirala na strokovno usposabljanje delavcev iz obstoječega sestava. Na tak način smo v Sloveniji pridobili več kot 14 vodij računalniških centrov, 10 projektantov, čez 20 programerjev, okrog 50 operaterjev na sistemu, čez 300 operaterjev na zajemalnih strojih oziroma ekranskih terminalih, pa kontrolorjev in ostalih delavcev, ki sodelujejo v avtomatski obdelavi podatkov.

Naslednji pomemben element avtomatizacije je izdelava aplikativnega programa. Na tem področju je bila služba, zaradi večjega števila enakih računalniških sistemov in enotne tehnologije dela, najbolj učinkovita. Za okrog 100 projektov na zveznem nivoju je bilo izdelanih preko 2.000 programov za zajemanje in obdelavo podatkov.

Sedanje stanje računalniške tehnologije obdelave podatkov in tehnike v službi še ni zadovoljivo. V obdelavi podatkov je še vedno prisotno mnogo preveč ročnega dela. Identifikacija uporabnikov družbenih sredstev je prav tako še vedno neprimerna za popolno avtomatizacijo dela. Računalniški sistemi v SDK so nepovezani. Od uporabnikov družbenih sredstev še vedno prejemamo vhodne podatke le na papirnatih dokumentih. V nekaterih naših podružnici so sicer že poskušali pridobivati podatke na magnetnih medijih, vendar obstoječe organizacijsko tehnološke rešitve, ki izvirajo še iz obdobja ročnega dela, zavirajo razvoj.

Za naslednje srednjeročno obdobje služba načrtuje ponovno modernizacijo svojega dela, z naslednjimi glavnimi značilnostmi:

• še večja distribuiranost obdelave v organizacijskih enotah SDK
• nova konstrukcija številke žiro in drugih računov, ki naj omogoči popolno kontrolo brez konzultacije baze podatkov. Tako bo mogoče zajemati podatke le enkrat in jih takoj vključiti v plačilni promet
• šifriranje namena nakazila bo omogočilo zaustaviti papirne naloge pri pobudnika
• izdelati bazo podatkov za predhodno kontrolo in analize.

Pri tej modernizaciji naj bi sodelovala tudi domača industrija, ki naj bi v bodoče predstavljala čvrsto in zanesljivo oporo službi pri opremljanju in nadaljnjem razvoju sistema avtomatske obdelave podatkov.

September 1984

Novi APS za investicije

Na podlagi projekta za spremljanje in informiranje o investicijah (izdelan julija 1983) je SDK Jugoslavije pripravila zahtevek za izdelavo aplikacijskega programskega sistema (APS). Glede na to, da služba razpolaga s tremi računalniškimi sistemi (IBM, Burroughs in NCR v Bosni), je potrebno izdelati za vsak računalniški sistem poseben APS. Pri tem je SDK v Sloveniji dobila nalogo za izdelavo APS za računalniške sisteme IMB (to nalogo je dobil SERC Ljubljana) in Burroughs, medtem ko bo APS za NCR izdelala SDK v Bosni in Hercegovini. Zaradi enotne izdelave vseh treh APS je SDK Jugoslavije imenovala skupno delovno skupino, ki je po prejemu zahtevka za izdelavo APS, v skladu z internimi standardi službe, izdelala idejni projekt.

Zahtevek je bil izdelan in dopolnjen od konca decembra 1983 do maja 1984, idejni projekt pa je bil izdelan in verificiran 24. maja 1984. Od tega dne dalje delovna skupina nadaljuje delo pri izdelavi APS. Rok za izdelavo pa je 31. december 1984.

Obstoječi sistem in osnovna problematika

Sedanji podatki o investicijskih vlaganjih v Službi temeljijo na naslednjih statističnih raziskovanjih:

Izplačila za investicije, ki se spremljajo mesečno preko obdelave podatkov iz plačilnega prometa (R-1 in IN-1) ter mesečna poročila poslovnih bank o izplačilih iz investicijskih kreditov (IN-K-1).

Največja pomanjkljivost mesečne statistike o investicijskih izplačilih pa je med drugim tudi v nepopolnem zajemanja podatkov, ker v sedanjem sistemu ni mogoče spremljati investicijskih vlaganj iz deviznih sredstev in vlaganj iz domačih in tujih blagovnih kreditov. Naslednja pomanjkljivost pa je v nepopolni obdelavi podatkov po teritoriju in dejavnosti vlaganj, ker sedanji sistem zagotavlja samo podatke o investitorjih ne pa [tudi podatkov o investicijskih objektih.

Evidence in ankete o investicijah v teku in zagotovitvi sredstev.

To so za sedaj edine evidence v Službi, ki se vodijo po investicijskih objektih. Te evidence zagotavljajo zelo pomembne podatke o vsakem objektu v izgradnji (njegovi predračunski vrednosti, zagotovitvi sredstev po virih financiranja in drugo).

Pomanjkljivost teh podatkov je predvsem v definicijah (republiški predpisi) za pojem objekt, za določanje predračunske vrednosti in druge neusklajene kategorije. Naslednja pomanjkljivost je tudi v tem, da se poleg obstoječe zelo obsežne evidence investicij v službi (E-IN) dvakrat letno izvaja snemanje (IN-CB), da bi zbrali potrebne podatke za informiranje o investicijah v teku.

Podatki iz knjigovodstva uporabnikov družbenih sredstev

Ti podatki, ki jih uporabniki trimesečno predlagajo službi v zaključnih računih in periodičnih obračunih, vsebujejo pomembne podatke o investicijah v teku in investicijskih vlaganjih, o aktiviranih investicijah in razpoložljivih sredstvih za investicije.

Največje pomanjkljivosti te kategorije podatkov pa so tele:

1. podatke je mogoče zagotoviti samo po investitorjih,
2. ni podatkov za investitorje, ki ne predlagajo zaključnih računov in periodičnih obračunov,
3. podatki vsebujejo samo izplačila iz dinarskih sredstev, ni pa podatkov o izplačilih iz deviznih računov in drugih vlaganjih, ki v trenutku vlaganja ne predstavljajo izplačil.

V celoti je sedanji sistem spremljanja in informiranja o investicijah dokaj zapleten, kar se med drugim kaže tudi v tem, da je v službi več vzporednih, delnih in nepovezanih evidenc in statističnih raziskovanj.

Razvoj sistema informiranja o investicijah

V letu l983 je ZIS sprejel koncepcijo dolgoročnega razvoja informiranja o investicijah in predloge napredka v l. 1984. Dokument so pripravili Zvezni zavod za statistiko, Služba družbenega knjigovodstva Jugoslavije, Narodna banka Jugoslavije, Zvezni zavod za družbeno planiranje, Zvezni sekretariat za finance in Združenje bank Jugoslavije.

V skladu s predlogi napredka iz navedenega dokumenta in na podlagi drugih dokumentov v Službi in izven nje je lani posebna delovna skupina v Službi v
sodelovanju s predstavniki Zveznega zavoda za družbeno planiranje in Zveznega zavoda za statistiko izdelala projekt za spremljanje in informiranje o investicijah.

Projekt postavlja predvsem naslednje cilje:

1. usklajena delitev del v informiranju o investicijah med Službo in zavodi za statistiko,
2. izgradnja konsistentnega podsistema v sistemu družbenega sistema informiranja, ki bi zadovoljeval različne nivoje informiranja (združeno delo, DPS od občine do federacije, družbenopolitične organizacije itd.),
3. uvajanje novih enotnih evidenc po investicijskem objektu,
4. v okviru službe se vsa evidenca vodi na sredstvih AOP,
5. širše povezovanje s podatki drugih udeležencev v sistemu preko sredstev AOP.

Organizacija evidence

Osnovne poročevalske enote, ki dajejo individualne podatke o investicijah, so investitorji, SDK in banke.

Osnovne enote opazovanja, za katere se formirajo individualni podatki, so investicijski objekti (vsa investicijska vlaganja, za katera so po republiških predpisih predpisane obveznosti zagotovitve sredstev) in druga investicijska vlaganja posameznega investitorja (vlaganja za katera se po republiških predpisih ne zagotavljajo sredstva). Za vsak investicijski objekt se bo vodila evidenca od trenutka prijave izgradnje objekta službi, ko se formira evidenca, pa do trenutka izdaje uporabnega dovoljenja. Evidenca o investicijskih objektih se vodi po investitorjih, zato je identifikacijska številka objekta sestavljena iz žiro računa investitorja in zaporedne številke objekta v okviru enega investitorja.

Vsebina evidence

Evidenca vsebuje poleg splošnih podatkov o investitorjih (podatki iz RUDS) in objektih (naziv, šifra dejavnosti, teritorij, oznaka prioritete, karakter gradnje, pomembnejši datumi itd.) naslednje finančne podatke:

podatki o predračunski vrednosti (45 elementov), ki jih predlagajo investitorji (skupaj s splošnimi podatki o objektu) ob prijavi investicije (obr. IN-1) in prijava sprememb predračunske vrednosti (obr. IN-2),

pogodbene investicije in ugotavljanje plačil (17 elementov), podatke daje Služba iz svojih evidenc, ki jih vodi kontrola (obr. IN-4),

izvršena izplačila in druga izvršena vlaganja (37 elementov), podatke daje Služba na osnovi plačilnega prometa, banke o izvršenih izplačilih iz sredstev odobrenih kreditov (obr. IN-K-l), investitorji o izvršenih plačilih iz deviznih sredstev in drugih vlaganjih za katera niso izvršena plačila v trenutku vlaganja (IN-3).

Zajemanje in obdelava podatkov ter informiranje

Podatke o investicijskem objektu zajema tista podružnica kjer ima investitor svoj žiro račun. Izjemo predstavljajo investitorji (TOZD), ki poslujejo preko skupnega žiro računa na nivoju delovne organizacije. Podatke za te investitorje zajema podružnica, ki vodi skupni žiro račun delovne organizacije. Te podatke pa podružnica mesečno dostavlja tisti podružnici, ki pokriva območje kjer ima investitor (TOZD) svoj sedež. Z navedeno izmenjavo podatkov zagotovimo obdelavo podatkov po teritoriju investitorja.

Obdelavo podatkov izvajajo vse organizacijske enote in to:

• podružnice na nivoju občin
• centrale na nivoju republike
• SDKJ na nivoju SFRJ

Podatki se obdelujejo:

• mesečno o izvršenih izplačilih za investicije v tekočem letu iz računov investitorjev in iz sredstev kreditov,
• trimesečno vse druge obdelave (po predhodno izvršeni izmenjavi podatkov po teritoriju objektov med organizacijskimi enotami Službe) kot npr. po dejavnosti in teritoriju investitorja, po namenu vlaganja in lokaciji investicijskega objekta, po prioritetnih dejavnostih itd.

SDK Jugoslavije je predpisala 112 informativno-analitičnih tabel kot okvirni  obseg enotne obdelave.

Temeljne rešitve aplikacijskega programskega sistema

Delovna skupina je upoštevala predvsem naslednji dve načeli:

temeljne programske rešitve naj bodo čim bolj enotne za vse tri računalniške sisteme,
zagotoviti čim večjo prilagodljivost programov glede dograjevanja sistema - tako pri vhodnih podatkih kakor tudi pri izhodih informacijah.

Obe načeli sta rešeni preko posebnega sistema parametrov, ki omogočajo hitro prilagajanje programov in so enotni za vse tri računalniške sisteme.

Tako npr. parametri, ki povezujejo oznake AOP vhodnih obrazcev z mestom zapisa v stavkih omogoča hitro prilagoditev programov v primeru spremembe finančnih podatkov (oznake AOP) v vhodnih obrazcih. V tem primeru spremenimo samo navedene parametre (le-ti so izven programa), programov pa ne spreminjamo.

Zgoraj prikazan parameter določa tako izgled glave, ki bo izpisana v izhodni tabeli, kakor tudi vsebino podatkov v stolpcih (v vrstici z zvezdica).

Poleg navedenega moramo s parametri določiti še način grupiranja podatkov kot npr.:

S 1 OBCIN OBCINA XXX-XXXXXXXXX
S 2 DEJIN4 Po PODROCJIH IN PANOGAH DEJAVNOSTI INVESTITORJA

Kar pomeni, da bodo podatki grupirani po občinah in za vsako občino po področjih in panogah dejavnosti investitorja.

Še nekaj o organizaciji datotek. Zaradi racionalnega izkoriščanja kapacitet na magnetnih diskih in zaradi racionalnosti glede hitrosti obdelave je celotna evidenca organizirana v dveh datotekah:

datoteka s podatki po investicijskih objektih s splošnimi podatki o investitorju (razen naziva, ki ga po potrebi dobimo iz RUDS) in objektu ter z vsemi finančnimi podatki o objektu. Izvršena vlaganja v objekt so zapisana po stanju od začetka gradnje do konca poročevalskega obdobja (62 finančnih podatkov v stavku. Stavek je objekt kar pomeni za Slovenijo približno 2000 stavkov,
datoteka s podatki o vlaganjih v tekočem letu tako v objekte kot tudi druga vlaganja za vsakega investitorja, ki niso vezana na objekt. To je37 finančnih podatkov v stavku - stavek je objekt ali druga vlaganja investitorja kar pomeni za Slovenijo red velikosti 10.000.

September 1984

Novi APS ELKA-IGRA

Koristni predlog in tehnična izboljšava

Na 27. seji sveta službe so člani sveta sprejeli predlog za nagraditev koristnega predloga in tehnične izboljšave aplikacijskega sistema »IGRA«, ki sta ga izdelala naša delavca sektorja za računalniško. Avtorja smo poprosili, da nam aplikacijski programski sistem Igra predstavita še posebej za Obvestila, objavljamo pa tudi obrazložitev, ki jo je pripravila strokovna komisija za oceno investicijskih predlogov, ki jo vodi namestnica generalnega direktorja Službe družbenega knjigovodstva v SR Sloveniji.

Aplikacijski programski sistem IGRA predstavlja nadgradnjo APS ELKA, ki je izdelan za paketno obdelavo podatkov na velikih računalniških sistemih IBM in je namenjen za izdelavo različnih analitično-informativnih pregledov iz sekvencialnih datotek s podatki o periodičnih obračunih in zaključnih računih uporabnikov družbenih sredstev ter iz datotek drugih statističnih raziskovanj (R-l , B-2, K-l).

S tem APS je mogoče hkrati obdelati eno datoteko iz diska in (ali) več datotek iz magnetnih trakov, če imajo vse datoteke enake stavke.

Glavna karakteristika APS je v njegovi fleksibilnosti, ki omogoča izdelavo velikega števila različnih tabel. V ta namen je sestavljen iz programskega dela in sistema parametrov.

Vsi parametri se vključujejo direktno v izvajalne programe, zato ni potrebno sprotno prevajanje programov.

Ob uporabi aplikacijskega programskega sistema ELKA se je pokazalo, da bi bile možnosti za njegovo uporabo veliko večje z vgraditvijo nekaj dodatnih funkcij.

Glavne dopolnitve APS-a, ki sta jih avtorja vgradila v obstoječi sistem ELKA, omogočajo uporabo aplikacijskega programskega sistema IGRA tudi za pripravo računalniških obdelav podatkov za vrste podatkov in datotek, za katere se je do sedaj rešitve posebej programiralo, ali pa programe, ki so bili pripravljeni v drugih centrih (Beograd), prilagajalo za obdelavo za republiko Slovenijo in njene podružnice.

Zaradi naštetih dopolnitev se je zmanjšal obseg programiranja, omogočena je enostavna priprava tabel za namene publiciranja in prikazovanja podatkov za določene tipe tabel brez predhodnega programiranja ter priprava podatkov za preslikavo na mikrofiše. S tem se je mogoče veliko hitreje prilagajati potrebam uporabnikov podatkov ter veliko hitreje uvajati spremembe in dopolnitve obdelav.

Prednosti novega aplikacijskega programskega sistema IGRA so se potrdile z uporabo v obdelavi podatkov periodičnih obračunov za obdobje I-IX/1987 v SRS in podružnicah z IBM računalniki.


--------------------------------------

Kako uporabljamo APS IGRA

Poleg standardnih ukazov, s katerimi aktiviramo vsako obdelavo na računalniku, so za obdelavo z APS IGRA potrebni še naslednji ukazi ali parametri:

1. Parametri za opis vhodne datoteke

Za vhod lahko praviloma izberemo vsako sekvencionalno datoteko na disku ali traku, ki ima enake stavke. Podatki so lahko nepakirani in pakirani. Pri tem velja omejitev, da so vsi podatki, ki jih seštevamo ali iz njih izračunavamo nove podatke, pakirani v poljih enake dolžine.

Opis datoteke vsebuje predvsem tele informacije:

• dolžina logičnega in fizičnega stavka (zapisa) v datoteki;
• za vsak uporabljen podatek vpišemo ime, lokacijo v stavku, dolžino ter oznako, če je podatek pakiran ali nepakiran;
• lokacija in struktura podatkov za element (npr. AOP iz zaključnih računov) v stavku;
• informacija, če so in koliko so vhodni podatki okrajšani (npr. v tisoč din) in če le-te želimo še dodatno okrajšati.

2. Parametri, s katerimi neposredno oblikujemo zahtevano obdelavo

Le-tiso razdeljeni v naslednje kategorije:

2.1. Določitev obsega populacije (izbor datoteke in izbor stavkov iz datoteke) in to:

• nosilec podatkov trak ali disk;
• vrsta posla (npr. zaključni računi TOZD iz gospodarstva);
• izbor stavkov iz vhodne datoteke glede na vrednost obeležij (npr. področja dejavnosti 01 do 11 brez nekaterih podskupin), glede na vrednost elementov ali kazalcev ali vrednost indeksa elementa ali kazalca (npr. organizacije, ki imajo prikazano izgubo v tekočem letu nad določenim zneskom), glede na vrednost primerjave dveh elementov ali kazalcev oz. indeksov.

2.2. Sortni pojem

po katerem prikazujemo podatke v tabeli le-ta lahko predstavlja en ali več podatkov iz stavka, ali (in) izračunan podatek (npr. sort zaključnih računov za TOZD po višini povečanja OD na delavca). Podatke lahko sortiramo po rastočem ali padajočem zaporedju sortnega pojma.

2.3. Zbiranje podatkov

Podatke lahko prikazujemo individualno po stavkih (npr. posamezno po zaključnih računih) glede na sortni pojem ali pa jih zbiramo glede na vrednost enega ali več obeležij v stavku (npr. po občinah, po področjih in panogah dejavnosti itd.). Podatke lahko zbiramo tudi po razredih numeričnih obeležij (npr. po višini izgub) ali po razredih, ki jih določamo iz več vrednosti atributivnih obeležij (npr. razred, ki predstavlja seštevek stavkov iz področij dejavnosti 01 do 11 brez nekaterih podskupin).

Zbiranje podatkov lahko izvršimo v več nivojih, lahko pa jih vzporedno zbiramo tudi v posamezne razrede izven nivojev.

V isti tabeli lahko istočasno prikazujemo zbirne in individualne podatke.

2.4. Izbor podatkov iz stavkov

Podatke lahko prikazujemo posamezno po elementih ali pa iz več elementov - z uporabo osnovnih štirih računskih operacij izračunavamo nove podatke. Npr. kazalec, ki ga izračunamo po formuli:

(O96+Il3+114+1I6+131-ll9/-183X (l80+l8l))/(l32-lo4)X'100' 

V formuli za izračun, lahko kot množitelj ali delitelj uporabljamo poljubno konstanto, ki je lahko celo ali decimalno število.

V eni tabeli lahko prikažemo do 999 finančnih podatkov, od tega je število kazalcev omejeno na približno 200. Poleg elementov in kazalcev lahko poljubno izbiramo tudi druge podatke ali pa prikazujemo le-te brez elementov (npr. selektivno listanje zaključnih računov s podatki: številka stavka, ime organizacije, žiro račun, šifra dejavnosti itd.).

2.5. Navedba tekstov

S parametri navedemo: naslov tabele, imena finančnih in drugih podatkov, imena razredov. S parametrom pa lahko oblikujemo celotno glavo tabele, če le-ta ni širša od ene printerske strani (132 znakov).

2.6. Posebni parametri za oblikovanje tabele:

• format strani tabele (širina x višina)
• širina stolpcev
• presledki med vrsticami
• medsebojna zamenjava stolpcev in vrstic
• število vrstic za glavo tabele (posebna oblika za mikrofilm)
• število vrstic za imena v čelu tabele
• skok na novo stran
• druge možnosti

APS IGRA kot nadgradnja APS ELKA

APS IGRA ima poleg vseh možnosti APS ELKA predvsem še naslednje možnosti:

• večje možnosti pri izbiranju vhodnih datotek
• večje število podatkov, ki lahko prikazujemo v eni tabeli
• izračun kazalcev po zahtevnejših in daljših formulah za izračun
• možnost daljših imen za elemente in kazalce
• večje možnosti pri formiranju tabel
• večje možnosti pri izbiranju stavkov iz datoteke ter izbiranju podatkov iz stavkov
• večje možnosti pri zbiranju podatkov v agregate
• nekatere možnosti grafičnega prikazovanje podatkov

Glede na to, da je APS IGRA bil razvit iz prvotnega APS ELKA, so nekatere nove funkcije vsebovane tudi v zadnji verziji APS ELKA.

September 1988