Še en način obračunavanja nadomestila za delo Službe

V času, ko inflacijska stopnja še ni bila troštevilčna, je bilo očitno, da nadomestilo za delo službe, ki ga poznamo kot tarifa, daje vedno manj sredstev. Dotlej pretežno stabilni prihodki so se pričeli relativno manjšati in pričelo se je dogajati, da služba ni več vračala prihodkov gospodarstvu, kar je bilo pred tem tako rekoč v navadi. Svet službe, ki je tudi zaznal, da se prihodki službe manjšajo, je že pred dobrimi tremi leti prvič zadolžil službo, naj poišče kak način obračunavanja nadomestila, ki bi ne bil odvisen le od debetnega prometa uporabnikov družbenih sredstev, s katerim bi se delo bolj točno zaračunalo uporabniku, za katerega je bilo opravljeno, in bi po možnosti zagotavljal bolj stabilne prihodke.

Sedanji način obračunavanja

Če hočemo najti način, ki bi bil v skladu s temi zahtevami, je treba najprej ugotoviti, zakaj je obstoječa tarifa postala vse bolj skopa.

Splošno je znano, da je obstoječa tarifa degresivna. To pomeni, da vsi uporabniki družbenih sredstev ne plačujejo enako visokega deleža nadomestila od debetnega prometa na svojih računih, temveč plačujejo tisti z manjšim prometom večji delež, tisti z velikim prometom pa manjšega. Nadomestilo (T1), ki ga plača neki uporabnik, znaša

 

kjer pomeni t stopnjo nadomestila (ki je degresivna), p pa debetni promet v določenem obdobju. Tarifa službe (T) pa je vsota nadomestil, ki jih plačajo vsi uporabniki:

 

Če vzamemo primer štirih uporabnikov družbenih sredstev, ki imajo različno velik debetni promet (p1, p2, p3, in p4), plačuje nadomestilo vsak po svoji tarifni stopnji (t1, t2, t3 in t4). V diagrama to prikažemo takole:

 
  
Iz diagrama vidimo, da je delež nadomestila tem večji, čim manjši je debatni promet, in obratno. Posledica je ta, da zaradi večjega deleža nadomestila majhni uporabniki v bistvu subvencionirajo velike. Dejstvo, da so uporabniki razvrščeni v razrede glede na višino debetnega prometa, te lastnosti tarife ne spremeni, kvečjemu jo napravi nekoliko manj očitno.

Degresivna tarifa ima še drugo neugodno lastnost in sicer to, da se s povečevanjem debetnega prometa prihodki, ki jih daje, relativno manjšajo. Ob tem seveda takoj pomislimo na inflacijo, ki res povzroči tak učinek. Ne pomislimo pa na dejstvo, da bi se prihodki, ki jih daje taka tarifa, relativno zmanjševali tudi brez inflacije, če bi se le debetni promet povečeval. V obeh primerih bi se uporabniki selili v razrede z nižjo stopnjo nadomestila in bi plačevali relativno vse manj.

Lastnost tarife, da se s povečevanjem debetnega prometa prihodki relativno zmanjšujejo, je mogoče kompenzirati. To se lahko stori tako , da se povečujejo bodisi razredi, tarifna stopnja ali pa se zmanjšuje obdobje obračunavanja tarife. Navedeni ukrepi so učinkoviti le ob nizki inflacijski stopnji. Doslej se je služba poslužila že vseh treh, vendar brez trajnega učinka. Samo za primer naj navedem, da se ob hitro, da se v petih letih povečajo dvaintridesetkratno. Taka inflacijska stopnja pa je že večkratno prekoračena. To pomeni, da je meja možnosti sedanjega načina obračuna tarife presežena.

Razširjena osnova za obračun

Če vzamemo kot osnovo za obračun poleg debetnega prometa še število nalogov kar je bilo že večkrat predlagano (npr. v Obvestilih 2/88,  Novosti v tarifi), je treba izdelati tudi novo tehniko obračunavanja nadomestila, ki bo upoštevala obe osnovi. Glede na velikost debetnega prometa in število nalogov lahko razvrstimo uporabnike v štiri skupine in sicer

1. take z majhnim prometom in majhnim številom nalogov,
2. take z velikim prometom in majhnim številom nalogov,
3. take z majhnim prometom in velikim številom nalogov ter
4. take z velikim prometom in velikim številom nalogov.

Tako razvrščene uporabnike je mogoče prikazati v spodnji shemi:

 


Če naj bo tarifa odvisna od dela, ki ga ima služba z opravljanjem plačilnega prometa, je prav, da uporabniki družbenih sredstev iz prve skupine plačajo manj in tisti iz četrte več in sicer sorazmerno glede na obseg dela, ki je opravljeno. Prav tako naj plačata uporabnika iz skupin 2 in 3 približno enako. Pri drugem služba opravi več dela, pri prvem pa je večje tveganje zaradi morebitnih napak pri usmerjanj sredstev. Razen tega so uporabniki, ki poslujejo z velikimi zneski, praviloma veliki in se zanje opravlja temu ustrezno več dela tudi v drugih funkcijah službe.

Te štiri skupine uporabnikov je mogoče prikazati tudi v diagramu s koordinatama debetni promet (p) in število nalogov (v):

 

Predlog za izračun

Osnova za izračun nadomestila naj bo nova veličina, ki jo izračunamo kot produkt števila nalogov in debetnega prometa v določenem obdobju. Ker mora biti nadomestilo vendarle odvisno od opravljenega dela, je treba ta produkt korigirati in sicer s skupnim številom nalogov vseh uporabnikov v istem obdobju. Neki uporabnik družbenih sredstev bi torej plačal nadomestilo

Tukaj pride formula. Čakam na avtorja, da jo »dešifrira«.

Kjer pomenijo T2, tarifo, ki jo plača uporabnik, v1 število nalogov in p2 debetni promet tega uporabnika v določenem obdobju, t2 pa stopnjo nadomestila, ki je enaka za vse uporabnike. Nadomestilo. ki ga plača uporabnik, bo torej vedno sorazmerno z njegovo udeležbo v plačilnem prometu. Skupni znesek nadomestil T je enak vsoti vseh nadomestil vseh uporabnikov:

Tukaj pride formula. Čakam na avtorja, da jo »dešifrira«.

Kako bi predlagana tarifa delovala, lahko vidimo iz primera štirih uporabnikov, ki je prikazan v spodnji tabeli. Vidi se, da bi uporabnika, ki imata v istem obdobju enak produkt iz števila nalogov in debetnega prometa ("volumen plačilnega prometa"), plačala enak znesek nadomestila. Iz tega je mogoče tudi že oceniti, kaj bi pomenila za posamezne uporabnike.

Ostane še vprašanje, kako določiti stopnjo nadomestila tz. To je mogoče izračunati iz sedanjega zneska nadomestila v nekem primerjalnem obdobju in sicer takole:

Tukaj pride formula. Čakam na avtorja, da jo »dešifrira«. 

S tako izračunane tarifne stopnjo sta v primerjalnem obdobju zneska sedanjega in predlaganega nadomestila T enaka. To je obenem tudi že kontrola pravilnosti izračuna tarifne stopnje tz.

Glede na sedanjo tarife ima predlagana številne prednosti. Predvsem bi uporabniki družbenih sredstev plačali sorazmerno enak delež od prometa in nalogov in ne tistim z velikim prometom manjšega, tistim z majhnim prometom večjega. Storitve bi bile zaračunane uporabnikom, za katere se opravljajo, in se plačila za storitve velikih uporabnikov ne bi prenašala na majhne. Ker ne bi bilo velikostnih razredov, inflacija ne bi delovala tako, da bi se prihodki službe sorazmerno manjšali. Razen tega so na voljo že vsi podatki ki omogočajo obračun na predlagani način, tako da ne bi bilo treba uvajati novih evidenc.

Da ne bi ostalo zgolj pri teoriji, naj povemo še to, da se predlagani način preizkuša vzporedno s tistim, katerega preizkus je v teku od začetka tega leta, in da so rezultati ohrabrujoči ter v skladu s pričakovanji.

V diagramu so primerjane sedaj veljavna tarifa, ki v vsakem obdobju predstavlja 100%, preizkušena in predlagana tarifa. Preizkus je opravljen na dovolj velikem številu podatkov, da je mogoče sklepati na to, kako bi tarifa ž v resnici delovala. V teku preizkusa predlagane tarife ni bilo treba prilagajati. Preizkus traja šele štiri obdobja obračuna, če primerjalnega obdobja, v katerem je bila določena tarifna stopnja tz, ne upoštevamo, vendar iz trenda predlagane tarife lahko vidimo, da bo sledila inflaciji.

Kritično o neki obdelavi

Ko sem prelistal številko ugledne slovenske gospodarske revije, se mi je vzbudila asociacija na šolske naloge iz slovenskega in tujih jezikov v gimnaziji pred mnogimi šolskimi reformami. Tedaj smo pisali dve vrsti poprav šolske naloge: tisti z nalogami, kjer je bilo manj rdečih popravkov, so jo napisali kar na rob, ostali, pri katerih je bil profesor z rdečo barvo bolj radodaren, pa so nalogo napisali ponovno, tokrat pravilno. Od tistih časov mi je ostala navada, da si med branjem zapišem kako krajšo opazko kar na rob berila.

V omenjeni številki je kot že več let doslej izšel seznam 200 največjih delovnih organizacij, povečan še za nadaljnjih sto, v naši republiki v letu 1984. Revija se je potrudila in k seznamu objavila komentar, resda nekoliko skromen glede na priliko, ob kateri je objavljen, ampak dober namen je treba ceniti. Komentarju je dodan tudi diagram, najbrž v skladu z rekom, da slika pove več kot tisoč besed. Zdi se, da ta slika ne pove toliko, ker je »za lažje razumevanje« dodanih še »nekaj pojasnil«, kar kaže na to, da nemara diagram ni pravi, ali pa na to, da tudi slika ne pomaga, kjer ni kaj povedati. Z drugimi besedami rečeno, kjer ni, še vojska ne vzame.

Sam seznam je mogočen in prav lepo ga je prelistati. Človeku vzbudi dober občutek, da Slovenija v nekaterih pogledih le ni tako majhna in da ima kaj pokazati. Vendar pa je dovolj majhna, da vsakdo od nas bliže pozna katerega od teh 300 največjih ali pa vsaj koga, ki združuje delo v kateri od teh delovnih organizacij. To seveda da voljo in moč, da nekdo prelista dolgi seznam bolj počasi in pazljivo. Ob takem listanju pa si pazljivi bralec hočeš nočeš napravi na rob kako oznako, kak klicaj, pa tudi kak vprašaj.

Prvo presenečenje so delovne organizacije, ki ne spadajo med gospodarske organizacije. Med 300 največjimi se tako prikažejo ugledna zdravstvena ustanova, znan univerzitetni inštitut in nemara še kaj podobnega. Na prvi pogled ti namreč ne bi sodili v to druščine, vendar se po premisleku človek potolaži, če so veliki, so veliki, pa tudi če niso iz gospodarstva. Vpraša pa se, koliko je še velikih, ki tudi niso s tega področja, pa jih ni na seznamu.

Drugo bolj neprijetno presenečenje so delovne organizacije, ki so notorični viri problemov zaradi negativnih rezultatov poslovanja, pa se vseeno znajdejo v družbi uglednih. Na seznamu je dolenjski velikan avtomobilske industrije, gorenjska tovarna elektronskih izdelkov in bogve koliko takih še, ki nam prav tako niso v čast in ponos. Potem človek neha listati po seznamu in pogleda, od kod taki podatki. In zagleda na vrhu tabele dokaj skrit napis, s katerim se je ugledna revija, ki je podatke objavila, zavarovala: podatke za seznam 300 največjih so pripravili in obdelali pri SDK - centrala za Slovenijo. Na tem mestu interes za tabelo neha biti neoseben in zaskrbi me za ugled organizacije in delovne skupnosti, kjer združujem delo, saj mi ne more biti vseeno, kakšne podatke posredujemo za objavo. Potem se pozanimam, kako je mogoče, da izdelamo tak seznam in izvem (kakor že večkrat doslej), da je seznam izdelan popolnoma tako, kakor je bilo zahtevano.

Tedaj sem se (kakor že večkrat doslej), spomnil na članek, ki je pred več kot desetimi leti izšel v neki ameriški znanstveni reviji, govori pa o kandidatu, ki bi bil za svoje sicer izkazano odlično znanje fizike kmalu padel na izpitu samo zato, ker profesor ni dovolj točno izrazil vprašanja. Ker je zgodba poučna tudi za naše prilike, zasluži, da jo preberemo tudi mi.

Takole je:

Pred nekaj časa me je poklical kolega in me vprašal, ali bi hotel biti razsodnik za oceno izpitnega vprašanja. Nekega študenta se je bil pravkar namenil oceniti negativno za njegov odgovor na vprašanje iz fizike, študent pa je vztrajal, da bi moral dobiti najboljšo oceno in da bi jo bil tudi dobil, če bi se ne zarotil proti njemu cel sistem. Profesor in študent sta se strinjala, naj zadevo presodi nepristranska oseba, in sta izbrala mene.

Šel sem v kabinet svojega kolega in prebral izpitno vprašanje: »Pokaži kako je mogoče določiti višino stolpnice s pomočjo barometra.«

Študent je odgovoril: »Nesi barometer na vrh zgradbe, priveži nanj dolgo vrv, spusti barometer do ulice, potem ga dvigni k sebi in meri dolžino vrvi. Dolžina vrvi je enaka višini stolpnice.«

Poudaril sem, da ima študent trden argument v svoje dobro, ker je odgovoril na vprašanje popolno in pravilno. Po drugi strani pa, če bi se mu to priznalo, bi lahko dobil visoko oceno iz fizike. Visoka ocena naj bi potrjevala obvladanje fizike, na kar pa odgovor ni kazal. Predlagal sem, naj študent še enkrat poskusi odgovoriti na to vprašanje. Ni me presenetilo, da se je moj kolega strinjal, pač me je presenetilo, da se je strinjal tudi kandidat. Dal sem mu šest minut časa, da odgovori na vprašanje, obenem z opozorilom, da mora biti iz odgovora razvidno določeno znanje fizike. Po petih minutah ni napisal še ničesar. Vprašal sem ga, ali želi odstopiti, vendar je odvrnil, da ne. Imel je mnogo rešitev tega problema; pravkar je razmišljal o najboljši. Opravičil sem se mu, ker ga motim, in dejal, naj prosim kar nadaljuje. V naslednji minuti je izročil odgovor, ki je bil tak:

Nesi barometer na vrh zgradbe in se nagni čez rob strehe. Spusti barometer in meri čas padanje s štoparico. Potem izračunaj višino stolpnice po formuli

Tedaj sem vprašal kolega, ali želi on odstopiti. Pristal je in dal sem študentu zelo visoko oceno. Ko sem zapuščal kabinet svojega kolega, sem se spomnil študenta reči, da ima še druge odgovore na to vprašanje, zato sem ga vprašal, kateri so ti odgovori. »Hm, ja,« je dejal študent. »Mnogo načinov je za določitev višine visoke zgradbe s pomočjo barometra. Na primer, lahko bi vzeli barometer, ko sije sonce in izmerili njegovo višino, dolžino njegove sence in dolžino sence stolpnice in s pomočjo enostavnega razmerja določili višino zgradbe.« »Lepo,« sem rekel, »kaj pa drugi?«

»Da« je rekel študent. »Je še zelo osnovna metoda, ki vam bo ugajala. Pri tem načinu vzamete barometer in začnete hoditi po stopnicah. Ko se vzpenjate, označujete dolžino barometra vzdolž stene. Potem preštejete število oznak, kar vam da višino stolpnice v barometrskih enotah. Zelo direktna metoda.

Seveda, če želite bolj zapleten način, lahko privežete barometer na konec vrvice, ga zanihate kot nihalo in določite "g" na ulici in na vrhu stavbe. Iz razlike med obema vrednostma za "g" lahko načelno izračunate višino stavbe.

Končno je zaključil, »je še mnogo drugih načinov za rešitev tega problema. Verjetno najboljši,« je dejal, »je ta, da vzamemo barometer v klet in potrkamo pri hišniku. Ko se oglasi, mu rečemo takole: »Gospod hišnik, tule imam dober barometer. Če mi poveste višino te stolpnice, vam dam ta barometer!«

Tedaj sem vprašal študenta, ali res ne pozna konvencionalnega odgovora na to vprašanje.

Zgodba se tu zaključi z razmišljanjem študenta o razmerah in poučevanju na njegovi univerzi. Mi pa se lahko iz te zgodbe naučimo nečesa drugega: ne smemo pričakovati, da bomo na osnovi površno definirane naloge dobili izdelek, ki bo ustrezal vsem našim skritim željam. Če smo nad izdelkom razočarani ali če ni to, kar smo pričakovali, najprej premislimo, kaj smo storili, da bi dobili to, kar smo želeli.

Čim bolj grobo je izražena naloga, temveč je rešitev, ki ji ustrezajo. Da bi se v prihodnje izognili robnim ali celo popolnim popravam, bi bilo prav, da zahtevo specificiramo, kolikor najbolj točno moremo.


September 1985

Problem predstave o računalniških strokovnjakih

Januar 1985

Pri opravljanju svojega dela smo z njim običajno tako okupirani, da ne pomislimo, kaj o našem delu in nas samih mislijo drugi. Da bi se vživeli v svoje sodelavce in vsaj poskusili nase pregledati z njihovimi očmi, je še redkeje. Praktično izključeno pa je, da bi se vživeli v kožo uporabnikov in ugotovili, kakšna je njihova predstava o računalniških strokovnjakih. Največ, kar v tem pogledu navadno naredimo, je to, da jih razumemo, če nas ne razumejo. Živi in pusti živeti. V zadnji številki revije Datamation je izšel članek, ki je v tem pogledu prav razveseljujoč, ker daje priliko, da pogledamo, kako nas vidijo drugi, daje tudi možnost, da se spremenimo, če menimo, da nismo taki, kakršni se jim zdimo. Zato je zanimiv tudi za nas.

Eksperti ocenjujejo, da je programiranje računalnikov eden od najperspektivnejših segmentov za poslovanje. Do konca desetletja bo v ZDA programerjem na voljo več kot 25.000 delovnih mest. Kaj točno programer dela? Kaže, da ima o tem vsak drugačno predstavo. Tukaj je nekaj raznih vtisov, odvisno od tega, kje kdo sedi.

Programer - kakor se vidi sam

Je križanec med dr. Spockom in Clintom Eastwoodom - inteligenten, logičen, vendar hladen in preračunljiv, ne eden od tistih, ki izgubljajo čas z ničevimi čustvi. Še kot študenta so te iskali po študentskem domu, da si pomagal razvozlati pomen gumbov na mikrovalovni pečici, prenosnem telefonu, video kasetnem rekorderju, digitalnih budilkah in bančnih avtomatih. Pri slednjih si skušal razvozlati fine programske napake s tem, da si odštel 1.024 USD od bančnega računa, ki je imel saldo manj kot 256 USD.

V službi popravljaš programe, ki dopuščajo odštevanje 1.024 USD od bančnih računov, ki imajo saldo manj kot z 256 USD. Tvojim naporom gre neposredna zasluge za rešitev podjetja, ki je na robu finančne katastrofe.

Ker si učinkovit, vendar tankovesten, te po krivem obsojajo. Uporabniki mislijo, da je tvoja edina skrb, kako bi jim zagrenil življenje. Vodstvo te venomer kara, da zapravljaš dragocen računalniški čas, ko si izmišljaš ekrana, ki jih uporabnik razume. Sanjaš o tem, da boš zapustil to podjetje, ki je ladja norcev, brž ko boš dokončal svoj razvpiti program in prodal milijon izvodov.

Programer - kakor ga vidi uporabnik

Nima razumevanja za človeško krhkost ali spodobno oblačenja. Ko ga opomnijo na športna oblačila, ki jih sestavljajo kavbojke in majica, odgovori, da kravata in obleka ovirata dotok krvi v možgane in s tem onemogočata kreativnost. Komuniciranje s programerjem je naporno, ker govori tuj jezik, ki vsebuje obilje izrazov kot so k, abend in no-op (osebni zaimek, ki označuje vodstvo podjetja). Če nam uspe prebiti ta jezikovni zid in mu dopovedati, daje v programu napaka, izjavi, da je to »napaka operaterja« in predlagaj naj se ponovno generirajo. Zagotavlja vam, da je razumljivost uporabniku na vrhu prioritet pri razvoju programov, vam ponosno pokaže tabelo, ki je izpisana decimalno in ne heksadecimalno. Najpogostejši odgovor na vprašanje: PTPN (preberi tisto prekleto navodilo).

Programer - kakor ga vidi šef

Je marljiv in lojalen vse dokler je lahko član badminton kluba v podjetju in če dobi popust v svoji trgovini z računalniškimi komponentami ter ima rezerviran parkirni prostor za svojega BMW. Prekanjeni šef prepoznava kot normalne naslednje značilnosti obnašanja programerja: a) enkrat tedensko odloži vse, kar dela, da bi popravil zadnjo napako v prejšnjem programu, b) vedno zamudi sestanek kljub svoji fenomenalno točni elegantni kvarčni zapestni uri, c) pušča na mizi prijave za zaposlitve, zlasti ob času ocenjevanja. Ocenjevanje časa, ki je potreben za programiranje, je ena najbolj zahtevnih šefovih nalog, ker programer verjame, da ima projekt devet življenj in daje le deveto tisto, ki ga je treba upoštevati. Najpogostejši odgovor na vprašanje: »Napaka uporabnika«.

Programer - kakor ga vidi tehnik

Sam sebi pravi programski tehnik, toda prav kakor smetar, ki se skriva za nazivom »sanitarni tehnik«, nima pojma, za kaj pri tehniki pravzaprav gre. Če bi resnično imel talent, bi programiral v strojnem jeziku, ampak tega v večerni šoli za programiranje niso naučili. Namesto tega žali grobo lepoto procesorja s tem, da vse računalnike otovori s cobolom ne glede na njihovo interno arhitekturo. Ko se sestane delovna skupina, krivi za to, da ni opravil dela do roka, omejitve zaradi velikosti pomnilnika in hitrosti izvajanja programov. Problem je seveda OPO (oprema pametnejše od operaterja). Najpogostejši odgovor na vprašanje: »Hardverska napaka«.

Programer - kakor ga vidi glavni direktor

Je znatna debetna postavka v plačilnem stolpcu finančnega poročila. Žene ga neustavljiv nagon po dokupovanju »zastarele« opreme (oprema, ki je stara več kot šest mesecev). Hrepeni po najnovejših video igrah, ki se nezmotljivo pojavijo na vsakem ekranu, ki je priključen na naš računalnik. Ima navade testirati nove programe v času, ko je računalnik najbolj obremenjen, tako da mreža razpade. Kritična pot vsakega pomembnega projekta visi na programerjevih prepozno opravljenih nalogah. Glede na to, kako se oblači, kakšno grimaso dela in kakšen delovni čas spoštuje, bi ga lahko zamenjali s hišnikom, le plačo ima petkratno hišnikovo. Njegovi napori so direktno krivi za to, da je podjetje na robu finančne katastrofe. Najpogostejši odgovor na vprašanje: »Sem dobro oblečen?«

Slika govori sama zase. Kar bi se človek nemara lahko vprašal, je: ali so v tej hiši samo programerji tisti, ki so na očeh?

O ekonomiji in organiziranju informacijskih sistemov

Zveza ekonomistov Jugoslavije je skupaj s Svetom za družbeni sistem informiranja SFRJ priredila jugoslovansko posvetovanje o ekonomiji in organiziranju informacijskih sistemov. Organizator je bila Zveza ekonomistov Slovenije, posvetovanje pa je bilo na Bledu od 9. do 11. oktobra 1985.

V uvodnem delu je bilo podanih nekaj preglednih referatov s področja družbenega sistema informiranja in poslovnega informacijskega sistema. Najprej je bilo posvetovanje razdeljeno v tri tematska področja. Vsakemu od njih je bil namenjen en dan, s tem daje bila drugega dne popoldne organizirana okrogla miza na temo standardizacija v informacijskih sistemih. Tematska področja so bila ekonomija in organiziranje poslovnih informacijskih sistemov, ekonomija in organiziranje v informacijskih službah družbenega informiranja in kot tret'e varstvo informacijskih sistemov in podatkov.

Zgornja faktografija je potrebna zaradi splošnega orisa ozadja. To, da sem se imel priliko udeležiti posvetovanja, mi daje priložnost, da zapišemo nekatera svoja razmišljanja in opažanja, ki se nanašajo nanj.

V prispevku nimam namena biti recenzent referatov ali celo ocenjevalec tega pomembnega dogodka, ne morem pa si kaj, da ne bi vsaj poizkusil pripomoči k razumevanju tega, kar so napisali in povedali nekateri referenti in drugi, ki so se oglasili kot razpravljavci v zvezi s posameznimi temami.

Naj se najprej dotaknem ključnega izraza tega posvetovanja, informacijski sistem. Iz poročil in razprave je bilo videti, kot da je le malo komu jasno, o čem govori, čeprav je eden od uvodnih poročevalcev že dlje časa tega podal jasno in sprejemljivo definicijo informacijskega sistema. Zgornja domneva je videti kar tendenciozna, vendar ni utemeljena. Iz razprav na tem in na prejšnjih posvetovanjih na to temo, ki jih prireja zveza ekonomistov Slovenije vsako leto v Portorožu, se da ugotoviti, da se izraz informacijski sistem uporablja za

1. računalniški sistem
2. računalniško obdelavo (aplikacijski programski sistem)
3. računalniški program
4. računalniški izpis.

Tu in tam se izraz uporablja celo korektno. Najočitneje nerazumevanje. je pred nekaj meseci pokazal nekdo na ljubljanskem radiu, ki je dejal približno takole: »Vedeti moramo, da je osebni računalnik že sam po sebi informacijski sistem.« Splošna uporaba izraza izhaja najbrž od tod, da vsi mislimo, da razumemo, kaj je informacija in kaj je sistem in da zato razumemo tudi kombinacijo obeh besed. Vendar se moramo zavedati, da je informacijski sistem predvsem sistem. To pomeni, da ima določene strukturne elemente, funkcionalne elemente, povezave, hierarhijo, način delovanja in da opravlja določene funkcije. Skratka, o informacijskem sistemu moramo razmišljati z vidika teorije sistemov, tega vtisa pa večina razpravljavcev ni pustila.

Mnogo je bilo tudi govora o razvijanja in formacijskih sistemov v določenih organizacijah. Čeprav članek ni predavanje o informacijskih sistemih, je nekako treba komentirati-tudi ta pogled. Delujočo organizacijo si lahko zamislimo kot povezavo dveh sistemov, produkcijskega in informacijskega (ki ju še naprej lahko delimo na podsisteme). Produkcijski sistem je tisti, ki je materialna osnova za proizvodnjo ali delovanje, informacijski sistem pa omogoči, da organizacija res deluje ali proizvaja. Vsaka delujoče: organizacija torej mora vsebovati tudi delujoč informacijski sistem ali pa je preprosto ne bi bilo. Tam, kjer »vzpostavljajo«, »razvijajo«, »gradijo« in drugače izdelujejo svoj informacijski sistem, nemara preprosto še niso opazili, da njihov informacijski sistem obstaja.

Dragi izraz, ki je bil na tem posvetovanju zelo priljubljen in v splošni uporabi, je bil izraz baza podatkov. Zanj je očitno, da se je iz informatike preselil v druge stroke in se v njih trdno ukoreninil. Težko bi dejal, da sem razumel, na kaj seje v splošnem z bazo podatkov mislilo, vendar tako, kakor jo pojmujemo v informatiki največkrat ne. Pogosto izražena ideja je bila, da bi se, če bi imeli »dobro«, popolno« ipd. bazo podatkov pravilno odločali. To razmišljanje je v osnovi sicer pravilno, ne upošteva pa nivoja (hierarhijo) odločanja. Čim višji je namreč nivo odločanja, tem manj podatkov je potrebnih za (pravilne) odločitve in tem manj podatkov pride iz sistema, v katerem se odloča, tem več pa iz okolice. Nazoren dokaz za to trditev je gradnja rafinerije pri nas po tem, ko je okolica energetsko krizo že prebolevala: na osnovi podatkov znotraj sistema se je dalo najbrž sklepati, da je taka odločitev pravilna, pogled zunaj meja sistema pa bi verjetno pokazal nasprotno.

Posebna pozornost je bila posvečena standardizaciji v informatiki. Že prej je bilo večkrat ugotovljeno (in obžalovano), da na tem področju za razvitimi tako zelo zaostajamo, kar je na prvi pogled nerazumljivo, saj je videti, kot da se ne bi zavedali ekonomskega pomena standardizacijo. Tega se sicer zavedamo, vendar na področjih, kjer ima standardizacija tradicijo in kjer brez standardov preprosto ne gre več. Kaj pa v informatiki? Tu tradicije še ni in ekonomske koristi (merljive v dinarjih) so premajhno, da bi bile v razmerah visoke inflacije opazne ali celo prevladujoče. standardi v informatiki me spominjajo na resničen primer, ko je bil neki delovni organizaciji ponujen program za optimiranje nekega njenega proizvoda. Ocenjeno je bilo, da je s pomočjo optimizacije mogoče prihraniti do 3 % pri stroških proizvodnje. Po desetdnevnem premisleku je delovna organizacija nakup programa zavrnila z zanimivo obrazložitvijo. Povedali so, da so skupaj z drugimi proizvajalci iz svoje panoge dosegli pri zvezni administraciji (ki je tedaj imela to pristojnost) 75 odstotno podražitev izdelka, katerega proizvodnjo naj bi optimizirali. Nakup progama, ki bi jim omogočil za red velikosti manjšo korist, bi bil v takih okoliščinah golo zapravljanje. Standardi torej še naprej ostanejo ekonomska kategorija tudi v informatiki, vendar se spričo razmer ne smemo čuditi, če ne bo pretirane vneme za to, da bi jih razvijali in uveljavljali.

Naj se za konec dotaknem še organizacije posvetovanja. Prirejeno je bilo nekako »forumsko«. Avtorji, ki so svoje prispevke sicer objavili v zborniku referatov, so le-te na kratko predstavili, v nadaljevanju pa so udeleženci posvetovanja kako njihovo misel ali pa vprašanje za razpravo, ki so bila posredovana posebej, uporabili kot iztočnico za svojo diskusijo. Posledica take tehnike je bila, da smo vsi poslušali vse diskutante. Ker interesi niso tako univerzalni, bi se mi zdelo primerneje, da bi referenti svoje prispevke predstavili bolj temeljito in z uporabo vizualnih pripomočkov (npr. grafoskopa). Poleg tega bi organizatorji lahko priredili več okroglih miz, ki bi potekale istočasno. S tem bi dosegli, da bi se udeleženci bolj posvetili temam, ki jih predvsem zanimajo. Okrogla miza bi s tem postala res to, kar naj bi bila, namreč izmenjava mnenj, s čimer bi pridobili tako udeleženci kot tudi prireditelj.

Če bi posvetovanje organizirali na tak način, bi to zahtevalo nekaj več organizacijskega napora, vendar verjamem, da bi bilo vredno poizkusiti, saj bi bilo srečanje bolje izkoriščeno, kar je v vzajemnem interesu vseh sodelujočih.

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