EDB - Hvor står Forsvaret?

Der synes at være en voksende erkendelse af, at den nuværende spredte administration af EDB-udviklingen i forsvaret snarest må ændres, hvis ikke overblikket skal tabes. Major H. V. Rose, Forsvarets Datatjeneste, søger her at give en oversigt over den hidtidige udvikling af EDB i forsvaret og af den nuværende status. Forfatteren peger ikke på en enkelt løsning - som eksempelvis kunne være at styrke det nuværende EDB- element i en samordnende opgave ved oprettelsen af et tværgående EDB- fagligt element - men han efterlyser en snarlig beslutning om, hvad det er man vil.
 
 
Indledning
Det er ikke ukendt, at der inden for EDB-området er sket en eksplosiv udvikling de sidste 20-30 år, og at der ikke er tegn, der tyder på, at denne udvikling vil stoppe eller aftage i intensitet i den nærmeste fremtid. På grund af den hastige udvikling kan det være svært at følge med i, hvad der foregår. Der findes meget få bøger, der forsøger at give en samlet fremstilling. Udviklingen dokumenteres for det meste i fagtidsskrifter, som kan være vanskeligt tilgængelige for mange, og som for det meste kun præsenterer brudstykker af helheden. Denne artikel behandler også kun et brudstykke, det brudstykke, der normalt kaldes systemudvikling. Dette område er specielt interessant for brugeren, idet det er inden for den ramme, at han normalt kommer i kontakt med EDB, og det er her man forsøger at få brugerens ønsker og EDB-muligheder til at gå op i en højere enhed. Indholdet af artiklen er baseret på en konference, der blev afholdt i OKT 1983. Deltagerne var systemchefer fra større nordiske virksomheder (EDB, banker, industri og offentlige virksomheder). Hovedtemaet i konferencen var systemafdelingernes placering, omfang og virkemåde i fremtiden. Begreberne systemchef og systemafdeling tillægges forskellig betydning i forskellige virksomheder, men et gennemgående træk er, at systemafdelingen stiller specialister til rådighed for et projekt, hvor man sammen med brugerne udvikler et system. Systemchefer kan opfattes enten som chefer for en systemafdeling, med ansvar for udvikling og drift af systemer, eller som personer med ansvar for udviklingen af et specifikt system. Et system defineres i »American National Dictionary for Information Processing« som en »kombination af personel, maskiner og metoder, organiseret til at udføre et sæt specifikke funktioner«. Systemudvikling kan defineres som den funktion inden for en organisation, der udvikler et brugbart system. Jeg vil i denne artikel omtale endnu tre EDB-begreber: Datamater, programmel og kommunikation. Selv om disse begreber efterhånden er ved at blive en del af vort daglige gloseforråd, så lad mig af hensyn til afgrænsningen af denne artikel forklare, hvad jeg lægger i de tre begreber. Ved datamater forstår jeg det fysiske udstyr, der anvendes til databehandling.
 
Programmel er de programmer, procedurer, regler og tilhørende dokumentation, der får datamaten til at udføre de ting, brugeren ønsker, (en gang imellem som han ikke ønsker). Man kan tale om to t3^)er programmel afhængig af dets funktion. Systemprogrammel følger som regel med datamaten og er til dels bestemmende for dens kapaicitet og virkemåde. Applikationsprogrammel er de redskaber brugeren tager i anvendelse for at løse problemer eller udføre funktioner. Applikationsprogrammel kan deles op i to kategorier. Standardprogrammel købes som regel uden for virksomheden og er designet til at udføre generelle funktioner, der er fælles for mange virksomheder. »Skræddersyede løsninger« fremstilles af brugere og specialister i forening med henblik på at løse specifikke virksomhedsproblemer. Kommunikation, eller datakommunikation, er enhver form for transport af data mellem hinanden fjerntliggende steder. Fjerntliggende kan i denne forbindelse også være to rum ved siden af hinanden. Jeg vil i denne artikel kun beskæftige mig med den tekniske udvikling på de tre områder i det omfang, det er nødvendigt for forståelse af indflydelsen på systemudvikling.
 
Udviklingen
Den tekniske udvikling
Den tekniske udvikling løber parallelt på de tre områder datamater, programmel og kommunikation, og udviklingen på et område har i høj grad været med til at forcere udviklingen på de to andre områder. 
 
Udviklingen af datamater er især gået i retning af mindre fysiske komponenter, større kapacitet til at lagre informationer, større hastighed og ikke mindst væsentlige prisreduktioner. Fra nogle sider hævdes det, at man er ved at kunne se grænsen for den teknologiske udvikling, men andre er begyndt at udforske det, der ligger på den anden side af horisonten. Men man vil formentlig se en opbremsning af udviklingen inden for datamater, som skyldes, at de andre komponenter af EDB-området, programmel, kommunikation og ikke mindst brugerne, på nuværende tidspunkt ikke kan udnytte den udviklede teknologi tilnærmelsesvis fuldt ud. Udviklingen inden for systemprogrammel har i stor grad været medvirkende til at øge datamatens hastighed og evne til at behandle og holde styr på store datamængder. Tendensen går i retning af, at systemprogrammellet automatiserer en større og større del af systemudviklingsarbejdet og gør afstanden mellem brugeren og anvendelsen af et bestemt system væsentlig kortere. Endvidere sætter det den enkelte datamat i stand til at betjene flere brugere og flere systemer på samme tid. Prisudviklingen på dette område viser en stigende eller i hvert tilfælde konstant tendens. Inden for standardprogrammel er der de seneste år markedsført et utal af produkter (værktøjer) designet til at løse alverdens problemer. Arkivsystemer, rapport generatorer, økonomi- og budgetsystemer, grafiksystemer og lagerstyringssystemer blot for at nævne nogle få. Fælles for disse systemer er, at udbuddet bliver større, at der er stor overlapning på de forskellige systemer, og at de bliyer billigere. Det bør tilføjes, at man, for at henvende sig til så stor kundekreds som muligt, standardiserer produkterne i en sådan grad, at man kun sjældent opfylder en bestemt kundes behov fuldt ud. Priserne for »skræddersyede systemer« er stadig ganske betragtelige.
 
Det nye standardprogrammel vil i fremtiden i højere og højere grad sætte brugeren i stand til at anvende sin datamat direkte uden brug af et »EDB-kyndigt« mellemled. Datakommunikation følger i store træk udviklingen inden for generel kommunikation. Både tråd- og trådløse forbindelser har været dyre at etablere og anvende og kræver iværksættelse af særlige sikkerhedsforanstaltninger, hvis man vil reservere sine informationer for sig selv. Udviklingen går i retning af at gøre kommunikationen billigere og sikrere. De nye kommunikationsmidler (lyslederkabler og infrarøde stråler bl.a.) opfylder til en vis grad disse betingelser. Dette betyder, at man i meget stor grad kan distribuere sine systemer og derved sætte en meget større kreds af brugere i kontakt med systemet.
 
Systemudvikling
Systemarbejdet i forbindelse med EDB fremkom i 50’eme, da man begyndte at anvende datamaten til administrative formål. Før denne tid blev datamaten udelukkende anvendt til teknisk/videnskabelige opgaver, der var kendetegnet ved at være klart afgrænsede problemer, som kunne løses direkte af brugeren via en tekniker. Mens de teknisk/videnskabelige opgaver er kendetegnet ved få data og mange beregninger, er det omvendte tilfældet ved administrative opgaver. Her gøres i vid udstrækning brug af registeroplysninger (lagrede data). Skulle brugeren derfor som teknikeren selv udføre sine opgaver via en datamat, måtte han, foruden viden om problemet, der skulle løses, og et programmeringssprog, også besidde teknisk viden om, hvordan oplysninger var lagret, og hvordan han ajourførte sine registre. Desuden måtte han sikre sig et fornuftigt samspil mellem de maskinelle og de manuelle rutiner. Eftersom opgaverne dækkede flere og flere funktioner i virksomheden, og eftersom integrationen af opgaverne steg, blev det for voldsomt et arbejde for brugerne. For at løse dette problem udviklede man en organisation, hvor brugeren var ekspert, når det gjaldt viden om virksomheden, mens man uddannede specialister på de EDB-tekniske områder, de såkaldte systemplanlæggere og programmører. Disse specialister blev som regel samlet i EDB- eller systemafdelinger.
 
Systemafdelingen i 60’erne
Som regel var afdelingen en lille stabsenhed med reference til økonomiafdelingen. Dette var i og for sig naturligt nok, da de opgaver man løste hovedsageligt var af økonomisk og regnskabsmæssig art. Opgaverne blev dog sjældent initieret af brugeren, der havde en meget lille forståelse for de muligheder, der forelå. Oftest var det EDB-specialisteme, der kom med en god ide, der så blev grebet og godkendt af brugeren. Det var således sjældent virksomhedens mål, der var afgørende for et projekts igangsættelse. Afdelingens placering og organisation var ligeledes en følge af det daværende teknologiske niveau, hvor datamaten i hovedsagen var i stand til at operere på informationerne med et numerisk indhold. Afdelingens opgave var at »lave« systemer (analyse, konstruktion, programmering) samt at vedligeholde disse.
 
Af karakteristiske faktorer i afdelingens virke bør følgende fremhæves. Der herskede udbredt entusiasme på både bruger og specialistside, men denne entusiasme hvilede i høj grad på manglende viden om systemer og teknik. Fra ledelsens side var der større skepsis, dels fandt man det svært at indplacere denne nye funktion i organisationen og dels stillede den store krav om tilførsel af ressourcer. Afdelingen var i det store og hele selvforsynende. Man lavede selv sine analyser og programmering og anvendte ikke service udefra. Systemerne, der blev konstrueret, var »batch-systemer«, hvor brugeren præsenterede sine beregnings- eller udskriftsbehov for systemafdelingen, der foretog den fornødne kodning, hvorefter opgaven blev placeret i køen af de opgaver, der skulle løses af en centralt placeret datamat. Resultatet bley derefter afleveret til brugeren, der nu kunne afgøre, om det var det, han havde brug for. Både i systemudvikling og opgaveløsning var der tale om begrænset involvering af brugeren. Systemafdelingerne bidrog kun i ringe grad til opnåelse af den enkelte virksomheds mål, og tildelingen af økonomiske midler var derfor som regel lille og noget tilfældig. Endvidere blev der fra ledelsens side ført ringe kontrol med disse midler på grund af manglende forståelse for funktionen. Projekter, der blev iværksat, overskred som hovedregel både økonomiske og tidsmæssige rammer. Man havde endnu ikke udviklet effektive metoder til projektstyring. Både brugere og systemudviklingspersonel fokuserede på problemløsning. Det var de enkelte problemer, der var den drivende kraft i systemudviklingsarbejdet.
 
Problemer ved slutningen af 60'erne
Efter at have virket i en halv snes år stod systemafdelingerne med en større erfaring, men også med en række nye problemer. Selv om den nye teknologi begyndte at vise en nedadgående tendens på omkostningssiden, blev EDB-afdelingens ressourcebehov større og større, både i penge og personel. Dette skyldtes ikke mindst, at udgifterne til personel voksede støt. Den forventede rationaliseringsgevinst udeblev. Når man udviklede et system til at løse et problem, forventede man, at de personelressourcer, der blev anvendt til at udvikle systemet, blev frigjort, når systemet var operativt. Det viste sig som regel, at når brugeren begyndte at tage systemet i anvendelse, begyndte han også at få gode ideer til forbedring af systemet. Dermed blev det personel, der havde været anvendt ved udviklingen af systemet, bundet til dette for at udvide og vedligeholde det eksisterende system. Gradvist blev flere og flere i systemafdelingen bundet til disse opgaver, og afdelingens muligheder for at udvikle nye systemer blev reduceret i takt hermed. For at løse dette problem blev der tilført mere personel, men der var en tendens til, at også dette personel blev opslugt i eksisterende systemer. Dette problem betegnes »backlog«,d.v.s. systemafdelingens manglende evne til at udvikle systemer i takt med brugerens ønsker.
 
Ud over den registrerede »backlog«, som er de registrerede projekter, der venter på at blive sat i gang, er der en lige så stor »usynlig backlog«, som er udtryk for ønsker/behov en bruger har om at få sat et EDB-projekt i gang, men som han på forhånd opgiver, fordi han ved, at hans chancer for at få dem gennemført er mikroskopiske. På grund af det tilsyneladende umættelige behov for ressourcer, begyndte ledelsen at udvise interesse for systemafdelingen, ligesom resultaterne af de første systemer begyndte at åbne ledelsens øjne for de muligheder, der lå gemt i EDB. Systemafdelingen blev konfronteret med krav om koordinering af afdelingens og virksomhedens mål, og ledelsen begyndte at forlange udbj^te af investeringén. Den ringe forudsigelighed vedrørende projektforløb var ikke tilfredsstillende, og man blev stillet over for krav om forudsigelige tidsmæssige og økonomiske rammer. Den adskillelse af EDB-specialister og brugere, som indledningsvis havde været nødvendig, begyndte nu at virke belastende. Kommunikationskløften mellem de to grupper blev bestandigt bredere, og især var der en tendens til, at EDB-specialisten havde en meget ringe forståelse for virksomhedens problemer, hvorimod brugeren fik mere og mere viden om EDB, eller rettere om, hvad EDB kunne bruges til. De etablerede systemer viste kun ringe effektivitet. Dette slq^ldtes både fejl i programmel og datamater, men det skyldtes ikke mindst, at brugernes behov ikke var tilstrækkeligt medinddraget i udviklingsfasen, og at det endelige produkt derfor ofte kun i ringe grad tilfredsstillede disse behov. Alt i alt stod man ved overgangen til 70’eme med en række bristede illusioner både på bruger- og specialistside.
 
Svar på 60’emes problemer
EDB var kommet for at blive. Selv om mange ledere i EDB kun så muligheder for anvendelse til automatisering af visse administrative funktioner for derigennem at opnå en evt. rationaliseringsgevinst, var der mange, der begyndte at se mulighederne for at udvikle et effektivt ledelsesværktøj til forbedring af produktion og konkurrenceevne. Uanset hvilket synspunkt man delte, var der behov for kraftigere ledelseskontrol, d.v.s. indsigt og kontrol med både systemarbejdet og projektforløbet. Der blev udviklet forskellige modeller for systemarbejdet. Fælles for disse var, at arbejdet blev delt op i et antal definerede faser, og at de enkelte faser blev gennemarbejdet, før man tog fat på den næste. Samtidig udviklede man en række dokumentationsteknikker, der dels sikrede et bedre overblik over udviklingsarbejdet og dels sikrede brugeren indsigt i arbejdsforløbet, i en form han kunne forstå. En sådan vedtagen referenceramme gav endvidere mulighed for, at man kunne begynde at distribuere noget af analysearbejdet, således at brugeren i højere grad blev involveret i arbejdet. Herigennem forsøgte man at skabe forståelse mellem brugere og specialister. De faseopdelte arbejdsmodeller gav ledelsen mulighed for at gennemføre metodisk projektledelse, idet det nu blev muhgt at sammenligne flere EDB-projekter i en organisation. Endvidere var der nu mulighed for at indføre beslutningsprocesser i et projekts livsforløb, således at ledelsen ud fra et rimeligt dokumenteret grundlag kunne træffe beslutning om, at et projekt skulle standses.
 
Systemafdelingen i 70’erne
I kraft af ledelsens interesse fandt systemafdelingen en ny plads i organisationen. Fra at være en afdeling under økonomifunktionen blev den en funktionel afdeling med reference til både økonomi-, administrations-, planlægnings- og ledelsesafdelingeme. Afdelingernes opgave var at lave »skræddersyede« systemer på ordre, herunder egnetheds- og systemanalyser, programmering, uddarmelse, vedligeholdelse og projektledelse. Der blev i 70’eme opnået en høj grad af professionalisme på EDB- området, en så høj grad, at arbejdet måske begyndte at ligne kunst mere end håndværk. Man brugte timer og dage på at finde den optimalt »snedigste« løsning, uden tanke for hvad udviklingsarbejdet kostede. idet lagerplads og bearbejdningstid i datamaten var økonmiske faktorer, der stadig havde væsentlig indflydelse på slutresultatet. På EDB-specialistsiden nåede man et meget højt vidensniveau, erhvervet gennem erfaring og uddannelse. En større og større del af EDB- afdelingens personel havde tilbragt størstedelen af deres karriere i EDB- miljøet. På brugerside begyndte man at få øjnene op for mulighederne i EDB, men på grund af den accelererende udvikling blev det sværere og sværere at følge med i den tekniske udvikling. Man begyndte at fokusere på operationelle virksomhedssystemer, d.v.s. systemer, der bidrog til at løse problemer, der vedrørte virksomhedens samlede bestræbelser, fremfor systemer, der kun erstattede en eller flere administrative rutiner. Brugerne var ikke længere henvist til kun at stille déres problemer og spørgsmål i en kø og så få svar næste morgen (»batch-systemer«). Udviklingen inden for systemprogrammel og datatransmission muliggjorde, at brugeren kunne få svar her og nu (»real-time systemer«), og selv om virksomheden havde filialer spredt over et stort geografisk område, kunne alle anvende en fælles central datamat, og alligevel få svarene/ løsningerne præsenteret direkte på deres arbejdssted. En stor hindring i arbejdet med datamater var, at man, for at kunne gøre sig forståelig over for denne, skulle anvende et kodet sprog, som var meget vanskeligt og tidskrævende at lære. Der blev efterhånden udviklet kommunikationssprog, der var væsentlig lettere at lære, og man lod datamaten om at oversætte dette til en form, der kunne forstås af denne. Der var dog stadig tale om en meget høj grad af kodning og strenge syntaktiske regler.
 
Systemprogrammellet blev i højere grad effektivitetsorienteret, d.v.s. lettere anvendelse af datamaten, flere samtidige brugere om samme datamat, større informationsmængde på mindre lagerplads, hurtigere behandlingstider og mindre fysiske komponenter. Der opstod gradvist en EDB-serviceindustri. I første omgang var produkterne systemprogrammel til effektivisering af eksisterende datamater, men gradvist dukkede også applikationsprogrammel op, til løsning af generelle problemer inden for en virksomhed. Således opstod et alternativ til at have en egen EDB-afdeling i en virksomhed. Efterhånden som flere systemer blev taget i anvendelse opdagede man, at de forskellige systemer arbejdede på samme data. Dette førte til udviklingen af databaser, hvor man kun lagrede data et sted og så tillod de forskellige systemer at få adgang til disse data. Dette forenklede også i væsentlig grad arbejdet med at vedligeholde data. Systemafdelingernes egen interne organisation undergik også en forandring. De nye systemudviklingsmetoder medførte, at man gik over til en funktionsorienteret organisation svarende til de modeller og metoder, der blev anvendt. Alt i alt havde man ved udgangen af 70’erne en bedre produktionsenhed.
 
Nye problemer ved udgangen af 70’erne
På trods af de stadig faldende dataomkostninger voksede omkostningerne for systemerne. Dette skyldtes, at de menneskelige ressourcer blev dyrere og dyrere. Dette havde indflydelse både på den arbejdskraft virksomheden selv anvendte, men også i stigende grad på prisen på det programmel, man købte uden for virksomheden. De nye systemudviklingsmetoder havde lettet arbejdet i nogen grad, men man havde ikke derigennem fået løst problemerne vedrørende »backlog«. En typisk fordeling af personellet i en EDB-afdeling på anvendelsesområder kunne være 40% beskæftiget med udvikling af nye systemer, 40% beskæftiget med vedligeholdelse af eksisterende systemer og 20% beskæftiget med generel udvikling og rådgivning, med en klar tendens til forøgelse af personel til systemvedligeholdelse. Med mindre der tilførtes personelressourcer, var der kun et sted at tage dette personel fra, det var fra udviklingspersonellet, med deraf følgende fare for, at udviklingen blev bremset eller gik i stå.
 
Det var og er ikke ualmindehgt, at en virksomhed kunne have en »backlog« på 3-4 år. D.v.s. at der fra det øjeblik, ledelsen havde truffet beslutning om et projekts gennemførelse, kunne gå 4-7 år før systemet var operativt, når systemudviklingstiden indregnes, med mindre ledelsen ændrede prioriteringen af iværksatte projekter. Denne situation sammenholdt med de store vedligeholdelsesproblemer på eksisterende systemer, skabte ikke uforståeligt meget stor utilfredshed hos brugere og ledelse. Den hurtige udvikling på EDB-området gav uddannelsesproblemer både på bruger- og speciahstside. EDB-området var stadig meget teknisk betonet og vanskeligt at trænge ind i for brugere, og for specialisterne kneb det med at få tid til at følge med i udviklingen. De nye teknologier og koncepter var så forskellige fra det hidtidige anvendte, at man kun i mindre omfang kunne bygge på erfaring, og mængden af disse antog et sådant omfang, at det blev uhyre vanskeligt at danne sig et overblik over, endsige foretage en vurdering af det udbud, der fandtes. Man blev udsat for en aktiv markedsføring fra servicebureauer, men havde svært ved at foretage vurdering og udvælgelse. I takt med at den generelle konkurrence mellem virksomhederne blev skærpet, indførtes ny organisatorisk tænkning. Profitledelse og flexibilitet blev begreber, der også kom til at omfatte systemafdelingerne.
 
Svar på 70’ernes problemer
I dag er man i mange virksomheder i gang med at løse 70’emes problemer. Det er tydeligt, at det er systemudviklingen, der er flaskehalsen i anvendelsen af EDB. Det er derfor naturligt at forsøge at løse problemerne ved at købe de systemer, som i større og større omfang bliver udbudt på markedet. Dette ændrer drastisk ved systemafdelingens opgaver. For mindre virksomheder er det ikke længere rentabelt at opretholde en egen systemafdeling, deres behov kan som regel dækkes af standardsystemer med fornøden tilpasning. Større virksomheder har stadig behov for egne systemafdelinger, men deres opgaver ændrer karakter. Systemafdelingerne bliver nu ansvarlig for udarbejdelse af funktionelle specifikationer. Vurdering og analyse af brugerens behov og omsættelse af disse krav over for systemleverandører. Den store konkurrence på EDB-serviceområdet, med mange konkurser, svingende kapacitet og kvalitet nødvendiggør en nøje vurdering og kontrol af sælgeren. Denne vurdering udføres bedst af systemafdelingen med dens viden om leverandørmarkedet og brugerens behov.
 
Med indførelsen af mikrodatamater og færdige problemløsningspakker til rimelig pris, er der opstået en mulighed for, at de enkelte afdelinger i en virksomhed kan købe sig til en EDB-løsning, de har ventet på i mange år, inden for eget budget. Dette er set fra et virksomhedssynspunkt ikke særligt økonomisk, og systemafdelingen får derfor til opgave at koordinere indkøb og anvendelse af EDB-produkter inden for virksomhedsområdet. Virksomhederne har kun ringe erfaring med indkøb af den type serviceydelser, og der er opstået et behov for at styre kontraktforholdene omkring disse ydelser. Især volder godkendelseskriterieme problemer, og denne funktion er naturligt lagt over til systemafdelingerne. Det er ikke i alle tilfælde, at det kan betale sig at købe en løsning. Større virksomheder er begyndt at opstille kriterier for valg af den ene eller anden mulighed. Generelt vil man købe en løsning, når der er tale om større systemer eller ressourceknaphed, når ny teknologi skal indføres, nar »skræddersyede« systemer er til rådighed eller når der er behov for nye færdigheder i systemafdelingen (ledelse og teknik).
 
Status i Forsvaret
Ledelsesdirektiver
Det i det foregående skitserede udviklingsforløb er især typisk for større industrivirksomheder. Der er ligeledes tale om et generaliseret udviklingsforløb. Mange virksomheder har haft et andet forløb, og man må også have i tankerne, at mange virksomheder endnu ikke har været hele udviklingsforløbet igennem, men er i gang med at løse både 60’emes og 70’emes problemer.
I Forsvaret er den samlede EDB-virksomhed delt i fire hovedomrader (FKODIR 0.380-0 1978) med tre fagstabe ansvarlige for styring af disse områder:
- Operativ EDB-virksomhed styret af FST-0,
- administrativ EDB-vriksomhed styret af FST-0,
- våbenteknisk EDB-virksomhed styret af FST-M og
- teknisk/videnskabelig EDB-virksomhed styret af FST-0.
 
FKO udpeger de myndigheder, der inden for hovedområderne gøres ansvarlige for systemudvikling af et bestemt system, idet koordinering af dette arbejde inden for hovedområderne pålægges henholdsvis FST-OS, FST-ØA, FST-MM og FST-OP. Forsvarets Datatjeneste (FDAT) er direkte underlagt FKO (FKOBST 0. 380-3 1978) og fungerer som EDB-faglig myndighed på det administrative område. Inden for systemudviklingsarbejdet har FDAT rådgivnings- og bistandsopgaver, men intet hovedansvar for udviklingsopgaver. Det bør dog bemærkes, at endnu intet projekt gennemføres uden bistand fra Forsvarets datatjeneste (FDAT). FDAT er som følge af denne ansvars- og opgavedefinition i praksis underlagt FST-0. Til styring af systemudviklingsarbejdet inden for det administrative område, har FST-0 udgivet bestemmelser, der fastsætter EDB-projekt- organisationers sammensætning og ansvar. I det efterfølgende vil jeg ikke behandle de i FKODIR definerede begreber våbenteknisk- og teknisk/videnskabelig EDB-virksomhed Systemerne inden for disse områder er i overvejende grad produktorienterede. De er ofte dele af et samlet kompleks (våbensystemer, overvågningssystemer m.m.) og leveres ofte sammen med disse. Der er i mindre grad tale om systemudvikling i den forstand, der behandles i denne artikel.
 
Organisation
Ansvaret og styringen af systemudviklingen ligger jf. FKODIR ved FKO fagstabe. Dette forekommer at være en rimelig konsekvens af FKODIR opdeling af EDB-virksomheden, men i praksis har de personer, der sidder i fagstabene, ikke tilstrækkelig viden om emnet til at varetage ansvaret og gennemføre styringen. FDAT varetager derfor rådgivning af de pågældende fagstabe med henblik på udarbejdelse af retningslinier, planer, bestemmelser og direktiver. Ved gennemførelse af et projekt varetager FDAT ansvaret for de planlæggende, udførende og kontrollerende funktioner vedrørende EDB- systemet, mens det overordnede systemansvar pålægges en af FKO udpeget myndighed (bruger). I praksis er der også her tendens til, at systemansvarets funktioner varetages af personel fra FDAT på grund af manglende viden hos projektgruppens brugerrepræsentanter. Den nødvendige viden om systemudvikling findes i dag stort set kim hos specialisterne, og selv om intentionerne i FKODIR og FKOBST om at lægge ansvaret og styringen hos brugerne er rimelige, er det i realiteten umuligt at leve op til disse krav, med mindre man begynder at uddanne brugerne i systemudvikling.
 
Den største viden om systemudvikling findes i dag ved FDAT. Denne viden skulle gerne bidrage til løsning af Forsvarets samlede opgaver. FKODIR opdeling af EDB-virksomheden virker i sig selv splittende, og når videnressourceme er samlet i en fælles pulje, kan interessekonflikter meget let hæmme en rationel udnyttelse af denne viden. Situationen er ikke ukendt for mange store virksomheder. Deres svar på problemet er at gøre EDB-funktionen til en stabsfunktion på linie med virksomhedens øvrige afdelinger. Denne placering er ikke afgjort af, hvilke opgaver der løses, men af en vurdering af funktionens mulighed for at bidrage til løsning af virksomhedens samlede mål.
 
Uddannelse
Uddannelsen i Forsvaret foregår på to niveauer. Uddannelse af specialister og uddannelsen af officerer (brugere). Specialistuddannelse er i dag, også set med civile øjne, af meget høj karat. Den gennemføres dels som en grunduddannelse med Forsvarets egne instruktører og dels som en videreuddannelse ved civile myndigheder og firmaer, rettet imod de produkter og opgaver, den enkelte specialist skal beskæftige sig med. En egentlig brugeruddannelse finder sted i meget ringe omfang. På officersskolerne og Forsvarsakademiet forsøger man at lære eleverne, hvordan datamaten virker. En opgave, der selvsagt bliver mere og mere kompliceret i takt med den teknologiske udvikling. Enkelte officerer og befalingsmænd, der indgår i en projektgruppe, får en mindre uddannelse/ instruktion vedrørende de produkter, der indgår i projektarbejdet. Intet sted foregår en uddannelse af brugere i, hvordan EDB generelt kan anvendes.
 
Holdninger
Inden for den samlede personelgruppe i Forsvaret er holdningerne til EDB selvfølgelig meget nuancerede, men man kan alligevel spore visse generelle holdninger på bruger- og ledelsesside. Brugerne er i stort omfang, ikke mindst på grund af påvirkninger fra omverdenen, begyndt at se mulighederne for at anvende EDB til løsning af komplicerede opgaver. Disse muligheder omsættes af brugeren til muligheder inden for hans eget arbejdsområde. Han ser muligheden for at slippe af med noget kedeligt rutinearbejde eller muligheden for at realisere arbejdsopgaver, der i kompleksitet eller omfang Overgår hans nuværende formåen. Et andet yderpunkt er, at han kan finde anvendelse for EDB på alle andre arbejdsområder end hans eget. Hans arbejde er så vigtigt og kompliceret, at det ikke kan overlades til en maskine. Hos næsten alle brugere findes en meget stor skepsis over for EDB. Alle kan fremdrage eksempler på, hvor galt det er gået, og uanset hvilke ideer man fremkommer med, er der alligevel ingen chancer for at få dem gennemført. Endvidere er der generelt meget stor usikkerhed over for, hvilke konsekvenser indførelse af EDB vil få for den enkeltes arbejdssituation.
 
På ledelsessiden har man lidt større visioner vedrørende anvendelse af EDB, men sporene skræmmer. Lange projektudviklingsforløb, dårligt virkende systemer og ringe ressourcekontrol indbyder ikke til at investere mere på dette område. Og da man i forvejen har svært ved at styre Forsvarets funktioner på højeste niveau, er der ikke særlig stor lyst til at indføre endnu en dimension på dette niveau. Man er generelt tilfreds med at overlade styringen af EDB-virksomheden til lavere niveauer i Forsvarets hierarki.
 
Anvendelsen af EDB
Sammenlignet med civile virksomheder følger Forsvaret ganske godt med udviklingen i anvendelsen af datamater og systemprogrammel. Uanset om det drejer sig om køb eller leje, har man adgang til de nyeste teknikker og værktøjer. Hvordan har man anvendt disse værktøjer? Forsvarets datatjeneste har siden 1971 været involveret i udviklingen af 17 store EDB-systemer. Af disse er 9 blevet afleveret til brugerne som færdige systemer, og 8 er under udvikling. Af de 9 færdige sptemer er 2 opslugt af andre systemer, 6 er under omarbejdelse, fordi de ikke opfylder brugerens krav/ønsker, og 3 virker tilsyneladende. Inden for de sidste tre år er der påbegyndt 3 nye EDB-projekter, og uden en drastisk omprioritering eller ressourceforøgelse kan man ikke forvente, at nye projekter vil kunne igangsættes med FDAT’s hjælp inden for en overskuelig fremtid. Forsvarets traditionelle systemudviklingsressourcer er altså stort set bundet flere år ud i fremtiden.
 
Alt i alt en ikke særlig imponerende resultatliste, men ikke så forskellig fra de erfaringer, dér er blevet gjort af store civile virksomheder. Med undtagelse af et enkelt system er alle systemerne opgaveorienterede, d.v.s. gennemført med henblik på at erstatte eksisterende manuelle rutiner. Det sidst påbegyndte projekt er et analysesystem, der skal sætte brugeren i stand til at løse opgaver inden for sagsbehandling af et bestemt emneområde ved bl.a. at kunne foretage simuleringer og konsekvensberegninger, en egenskab, der kun i meget ringe omfang er til stede i de øvrige systemer. Systemerne der bruges i Forsvaret er rettet imod løsning af specifikke opgaver og problemer, ikke på overordnet niveau, men normalt under fagstabsniveau. Man kan på denne baggrund spørge om, i hvilken grad anvendelsen af EDB indtil nu har været medvirkende til løsning af Forsvarets samlede opgave eller har forøget effektiviteten i Forsvaret.
 
Placering i udviklingen
Man kan ikke entydigt placere Forsvaret på et enkelt sted i det udviklingsforløb, der er skitseret tidligere. På nogle områder, især det tekniske, er Forsvaret meget langt fremme. Det, der først og fremmest sætter Forsvaret tilbage i forhold til civile virksomheder, er en manglende strategisk planlægning for EDB-virksom- heden. Man har endnu ikke kortlagt EDB-funktionens betydning for Forsvarets samlede virksomhed og fastsat mål og retningslinier for EDB- udviklingen. Vi står i Forsvaret midt i 70’emes problemer, men har i modsætning til mange større civile virksomheder endnu ikke taget aktivt fat på at løse disse. Inden for systemudvikling står vi endnu på nogle områder med 60’emes problemer. Et systematisk gennemført analyse- og projektforløb er endnu ikke indført som standard. På andre områder har man allerede taget hul på anvendelse af 80’emes værktøj til systemudvikling.
 
Tendenser i begyndelsen af 80’erne
I midten af det 18. århundrede oplevede verden det, der i dag kaldes den industrielle revolution. Fra mange sider hævdes det, at vi i disse år, forårsaget af anvendelsen af EDB, er midt i en revolution af tilsvarende omfang. Der er almindelig enighed om, at der på teknologiområdet vil ske en forbedring af forholdet mellem pris og ydelse på 20-25% om året i SO’eme. På kommunikationsområdet forventes en endnu større forbedring. Antallet af problemer og opgaver, der kan løses på en datamat, vil stige voldsomt, og der vil udvikles standardværktøjer, der vil sætte brugeren i stand til at præsentere og løse problemer i en direkte interaktion med datamaten uden specialistviden. Tilbuddene vil i langt højere grad være rettet imod problemløsning frem for opgaveløsning.
 
En IBM imdersøgelse er kommet til følgende konklusion vedrørende lønarbejderes afhængighed af EDB i deres arbejde: 11979 var 10% direkte afhængige af EDB og 27% delvis afhængige. 11985 forudser man, at 45% vil være afhængige og 10% delvis afhængige. Endvidere forudses det, at 60% af USA’s »skrivebordsarbejdere« vil være direkte anvendere af informationssystemer i 1990. Men langt den vigtigste tendens, og det der gør, at man kan tale om en revolution, viser sig i de koncepter, der er under udvikling i forbindelser med anvendelse af EDB. Koncepter der er blevet mulige på grund af prisfald og øgede anvendelsesmuligheder. 
 
I »elektronisk data behandling« har vægten hidtil været lagt på ordene elektronisk og behandling. I dag er man begyndt at lægge vægten på data. Den koncept, der lægges til grund for fremtidig anvendelse af EDB er, at data (information) er en virksomhedsressource, hvis betydning ligger på linie med personel, maskiner og råstoffer. IBM citerer direktøren for et stort internationalt forsikringsselskab for følgende: »... værdien af data er kun mindre end værdien af personel. De er livsvigtige for ledelsen både for at træffe beslutninger og til at styre denne store virksomhed«. Man kan hertil tilføje, at data er en absolut nødvendighed for at styre samtlige andre ressourcer. Information har ingen betydning med mindre den bliver anvendt, og dens anvendelighed er betinget af pålidelighed, tilgangsmuligheder og konsistens.
 
Næsten alle fastansatte i Forsvaret udfører sagsbehandling under en eller anden form, og til al sagsbehandling anvendes informationer. Hvor tit er man ikke i tvivl om informationens pålidelighed? »Har jeg nu fået den sidste skrivelse om dette emne«? »Er der udsendt rettelsesblade til dette reglement«? »Hvor er det nu, der står noget om dette her«? Man er sjældent helt sikker på, at de data, man anvender, er pålidelige. Distribueringen af informationer i Forsvaret følger ofte meget snørklede kanaler. Ofte vil sagsbehandlere, især på lavere niveauer, have svært ved at finde og få adgang til de informationer, de har behov for. Den praktiske sagsbehandler bygger gradvist sit eget lille arkiv op med informationer, men hvad sker der med disse informationer efterhånden som tiden går. Nogle får ført deres oplysninger ajour, mens andre i lykkelig uvidenhed træffer beslutninger ud fra data, der forlængst har ændret værdi. Det er ikke mærkeligt, at to sagsbehandlere kan få højst forskellige resultater på samme opgave.
 
Mange antager, at virksomhedens data er under kontrol i dag. Men er der nogen i Forsvaret, der ikke genkender problemerne i følgende spørgsmål?
- Er det nødvendigt for dig en gang imellem at skulle vælge mellem to tal, der giver sig ud for at skulle vise samme ting?
- Afholder du dig en gang imellem fra at indhente information, fordi du ved, at det vil tage for lang tid at indhente denne?
- Er virksomhedens EDB-afdeling så overbebyrdet med systemvedligeholdelse, at de ikke kan opfylde dit informationsbehov?
- Sker der fejltagelser i løsninger på grund af dårlig information?
 
Hvis man genkender bare et af disse problemer, bør forvaltningen af virksomhedens informationer forbedres. Som følge af de nye koncepter og EDB-muligheder er mange virksomheder begyndt at omstrukturere deres EDB-afdelinger, og som ny funktion i afdelingen finder man en sektion, der oftest optræder som »Information Centre« eller »User Service Department«. Der er allerede set mange forskellige måder, hvorpå man forsøger at implementere de nye koncepter, men normalt ser man, at EDB-afdelingen kommer til at indeholde sammensatte stabsfunktioner, og at afdelingen får reference direkte til topledelsen.
Opgaverne ændres ligeledes og nye kommer til. Heraf kan nævnes:
- Koordination af decentrale systemers tilpasning til generel policy og systemkonfiguration,
- overgang fra at være producent af systemer til at være professionelt servicebureau,
- mellemled mellem brugermarkedet og systemudbudsmarkedet,
- konsulentbistand for forståelse af udbudsmarkedet,
- konsulentbistand vedrørende søgning, evaluering, installering, test, kontrakt, brug og vedligeholdelse af nye systemer,
- afgrænsning af nødvendig information, teknologi og uddannelse i organisationen og
- koordinering af dataintegritet og systemarkitektur på baggrund af ledelsens policy.
 
Afslutning
Jeg vil vove den påstand, at forudsætningen for en effektiv styring af Forsvaret i fremtiden er indførelse og anvendelse af EDB-teknologi. Effektiv set ud fra den målestok, som mere og mere trænger igennem i Forsvarets omverden, og som vil være afgørende for de krav, som denne omverden vil stille til Forsvaret. Forsvaret har i dag mange muligheder. Det ene yderpunkt er, at man læner sig tilbage og venter med at deltage i udviklingen under indtryk af, at det jo bliver billigere og bedre næste år. Det andet yderpunkt er, at man springer over 10-20 års problemer og begynder at bruge resultaterne af den udvikling, der allerede er en kendsgerning. Det vigtigste Forsvaret bør gøre er at træffe beslutning om, hvad man vil.
 
 
 
 
 
 
PDF med originaludgaven af Militært Tidsskrift hvor denne artikel er fra:
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Litteraturliste

Del: