Skønt databehandlings-litteraturen er sparsom i sin omtale af IDBbegrebet og oftest forviser bemærkningerne herom til sidste kapitels mere løse omtale af den forventede fremtidige udvikling på databehandlingsområdet, er det dog få forfattere, der helt undlader at komme ind herpå. Som udgangspunkt for artiklen refereres derfor nogle typiske eksempler på den uenighed, der gør sig gældende i fortolkningen af begrebet.

Som repræsentanter for den rent databehandlings-tekniske opfattelse
siger Gregory og Van Horn i et definitionsappendix:

Integrated Data Processing - A system designed as a whole so
that data are recorded at the point of origin in a form suitable for
subsequent processing without any human copying.1)

En klar teknisk opfattelse, der uddybes i teksten:

Recent work called »integrated data processing« has aimed at
developing a system of completely mechanized handling, from the
original collection of data to the preparation of final documents

---

*) cancl. oecon., lektor ved Aarhus Universitet.

1) R. H. Gregory og R. L. Van Horn: Automatic Data-Processing Systems, Chatto og Windus Ltd., London 1960, side 677.

and reports. An important facet of some integrated systems is the
use of punched tape as a common language between many kinds
of office equipment .... 2)

Andre forfattere synes at opfatte IDB som en konsekvens af rationalingseringsarbejde
og ønsker om omkostningsminimering:

The objective in integrating, or uniting, operations in data processing is the familiar one of elimination of effort or duplication of effort. The need for integration arises in part from the multiplicity of needs of the users of data. Obviously, if the needs of all users can be met by means of a combined and unified operation, rather than a series of separate operations, there will be resulting economies₃).

En variant af denne opfattelse tænker først og fremmest på udnyttelsen
af et givet databehandlingsanlasg:

If a computer is installed to deal with a limited number of applications,
which ultimately involve only partial utilisation of available
computing time, the economic case for inclusion of further
applications to share the cost of installation is very strong
further cost sharing is often possible by .... building up an integrated
system.4)

Som repraesentant for forfattere, der opfatter begrebet i en videre
betydning, siger Felix Kaufman i sin bog om databehandling og revision:

Integration. Organization arrangements based primarily on arbitrary divisions of responsibility affect paper work patterns. These arrangements are frequently in conflict with the needs of effcient data processing. The concept of integration implies data processing patterns based upon the logic of information itself, whch transcends divisions created for other purposes.

The word »integrated« also has a popular connotation associated with »IDP«, or »integrated data processing«, which refers only to the preparation of original data in machine-sensible form, and the knitting of subsequent processes so that all information is transferred from process to process without manual recopying. The word is not used in that context (in this book).⁵)

---

2) samme, side 38.

3) Haskin og Sells: Introduction to Data Processing, 1957, side 97.

4) A. J. Burton og R. G. Mills: Electronic Computers and their Business Applications, Ernest Benn Ltd., London 1960, side 283.

5) Felix Kaufman: Electronic Data Processing and Auditing, The Ronald Press Co., New York 1961, side 9.

Endelig defineres begrebet på følgende måde i en databehandlingsordbog:

Integrated Data Processing. System or method of processing data throughout an organization in such a way that there is no duplication of function or interruption requiring human intervention to complete the total operation. Normally implies the use of electronic machine assemblies. Methodical interrelation of data from all sources within a system.⁶)

I den følgende diskussion ses der straks bort fra den snævre tekniske opfattelse af IDB-begrebet, som har fundet udtryk i de tre først citerede bøger. Der er her tale om at gøre IDB til et begreb, der er i familie med det kendte kontorrationaliserings-slogan »udnyt primærnoteringen«, hvilket givetvis ikke er uden værdi, men som på den anden side end ikke antyder de konsekvenser, som en mere abstrakt opfattelse af IDB medfører.

Den abstrakte opfattelse af IDB-begrebet dækkes til dels af de to
sidste citater, men det er hensigtsmæssigt at præsentere begrebet i en
lidt anden formulering.

Definition af »integreret databehandling«.

Integreret databehandling skal her defineres som et princip, der for
et givet problem i sin yderste konsekvens medfører:

1. at enhver grundoplysning (ethvert input) kun registreres en gang,

2. at enhver ønsket resulterende oplysning (ethvert output), der bygger
på en eller flere af grundoplysningerne, kun fremstilles en
gang, og

3. at samtlige resulterende oplysninger fremkommer efter den simplest
mulige bearbejdning af grundoplysningerne under hensyntagen
til den anvendte teknik.

IDB er altså ikke et mål i sig selv, men et princip, der kan finde anvendelse,
såfremt det ud fra økonomiske eller organisatoriske målsætninger
viser sig ønskeligt.

IDB er heller ikke en teknik, men et princip, hvis gennemførelse for et givet problem kan ske under anvendelse af alternative former for teknik, idet valget af teknik atter må bero på økonomiske eller organisatoriske

---

6) Glossary of Terms Used in Automatic Data Processing, et særtryk af tidsskriftet »Automated Data Processing«, distribueret i Danmark af Dansk Formulartryk Af S, side 16.

IDB-princippets konsekvenser skal illustreres i det følgende

I figur 1 repræsenterer enhver lille cirkel på den nederste linie en enkelt grundoplysning, medens tilsvarende enhver firkant på den øverste linie repræsenterer en ønsket oplysning. (Herefter omtales grundoplysninger som input-data og ønskede resulterende oplysninger som output).

Uden at angive forbindelsens detaljerede karakter kan man nu taenke sig at forbinde et givet output med de for konstruktionen af dette output nedvendige input-data ved hjaelp af linier. Gennemfores dette for hvert enkelt output, vil det utvivlsomt vise sig, at nogle af forbindelseslinierne krydser hinanden. Dette svarer til, at et givet input-datum indgar i beregningen af mere end et enkelt output, og heraf folger, at hvis man vil afgraense problemet til beregningen af et enkelt output, medforer dette uvaegerligt, at det input-datum, der ogsa. skal bruges ved beregningen af andre output end det betragtede, ma registreres mere end en gang.

På input-siden må problemet derfor udvides til at omfatte flere og
flere input-data, indtil man har et antal input-data og dertil svarende
output, for hvilke det gælder:

1. at input-dataene er nødvendige til fremstillingen af output-dataene,

2. at input-dataene er tilstrækkelige til fremstillingen af outputdataene,

3. at intet input-datum indgår i fremstillingen af output-data, som
ligger uden for problemets afgrænsning.

Dette kan også udtrykkes sådan, at problemet må udvides, indtil det er muligt at tegne en kasse omkring et antal input og et antal output på en sådan måde, at kassens sider ikke overskærer nogen forbindelseslinie mellem et imput-datum og et output. (Jfr. den stiplede kasse i figur 1).

Da det for den administrative databehandling er karakteristisk, at der består et meget kompliceret netværk af forbindelseslinier mellem input-data og output-data, vil princippet i praksis medføre en næsten übegrænset vækst i problemets størrelse. Det vil endog oftest være organisatoriske forhold, der trækker en grænse, før problemet i sig selv lader sig afgrænse.

Output-niveauer.

Medens det for input-dataenes vedkommende i reglen vil være forholdsvis let at trænge igennem til de mest oprindelige grundoplysninger, idet man simpelthen forsøger at finde det sted og det tidspunkt, hvor oplysningen opstår, d. v. s. modsvares af et faktisk hændelsesforløb, er det for outputs vedkommende forbundet med betydelig større vanskelighed at trænge igennem til det, der i sidste instans er det ønskede output. Dette skyldes, at visse former for output har karakter af »mellemregninger«, som indgår i senere og mere koncentrerede former for output.

Eksistensen af en sådan afhængighed mellem forskellige output gør
åbenbart figur 1 urealistisk, idet samtlige output er placeret på samme

»bearbejdningsniveau«, hvilket indebærer, at intet output på en gang er ønsket som output og samtidig nødvendigt ved beregningen af et mere kompliceret output. Skal denne opbygning af underordnede og overordnede output afbildes grafisk, må det ske i en form som vist i figur 2.

I figuren angiver de stiplede vandrette linier forskellige niveauer af output, idet det karakteristiske for de output, der ligger på samme niveau, er, at de kan bygge på delvis samme input-data, men at intet enkelt output i sin helhed indgår som en del af et andet output på samme niveau.

Det understreges, at to output på samme niveau ikke kan bygge på nøjagtigt samme sæt input-data, da dette i en vis forstand ville gøre de to output identiske. På den anden side må to output på samme niveau nødvendigvis bygge på mindst eet fælles input-datum, da de to output ellers ikke ville tilhøre samme problem.

Output og mellemregning.

Ved arbejdet med en databehandlingsløsning for et givet problem er det meget vigtigt at skelne mellem output og mellemregninger. En mellemregning er resultatet af en bearbejdelse af nogle input-data, som er et for den pågældende teknik nødvendigt led i beregningen af et mere kompliceret, ønsket output. Der er intet i vejen for, at en sådan mellemregning i sig selv kan være ønsket: som output, og der er for så vidt ingen grund til at beskæftige sig med dette forhold.

Det er imidlertid karakteristisk for simple former for databehandlingsteknik - typisk manuel databehandling - at det er nødvendigt at opdele beregningen af et kompliceret output i en række stadier, hvor resultatet af det enkelte stadium principielt er en mellemregning, men hvor man i tidens løb har vænnet sig til, at det fremkommer, og måske fundet anvendelse for det, hvorved det nu fremtræder som output. Det kan undertiden være vanskeligt at trænge til bunds i sådanne forhold, fordi de personer, der angiver, at: de ønsker sådanne mellemregninger som output, ikke er klar over (eller ikke vil indrømme), at baggrunden er, at databehandlingen er så usikker, at man undervejs til det endelige output må foretage kontrol af beregningerne, eller at man må sikre sig muligheder for at gå tilbage til mellemregningerne, dersom det endelige output viser et »usandsynligt« resultat. I sådanne tilfælde er ønsket om mellemregning som output åbenbart betinget af den anvendte teknik, og behovet må tages op til en ny vurdering, dersom man overvejer en anden teknik i databehandlingen.

Formen på output.

En anden karakteristisk egenskab ved den administrative databehandling er, at den form, et givet output har for øjeblikket, ofte mere afspejler den hidtil anvendte teknik, end det output, man kunne ønske sig, dersom man stod helt frit.

Omend visse output - typisk til brug for instanser uden for virksomheden - kun er tilfredsstillende, dersom de overholder helt klare regler om hyppighed af fremkomst, mængde af detaljer, den tidsperiode (det tidspunkt) output refererer til samt undertiden endog typografisk opsætning, gælder det for den største del af de output, der fremstilles til intern brug, at der kan forhandles om mange af disse sider af formen på output. Det er typisk for oplysninger til ledelsesbrug, at de i første omgang blot skal oplyse f. eks. »noget om svingningerne i lagerbeholdningen af vigtige varegrupper«, idet ledelsen ikke er voldsomt interesseret i på forhånd at specificere de enkelte krav om hyppighed, gruppeopdeling, valg af måleenhed etc., såfremt de blot er fuldt oplyst, når output foreligger. Man er kort sagt indstillet på hellere at tage oplysningerne på en ikke helt hensigtsmæssig, men lettere opnåelig form, end at gøre en stor indsats for at frembringe det helt ideelle output for hvert enkelt formål.

Det er for mulighederne for at gøre en givet databehandlingsopgave mere integreret vigtigt, at man ikke for tidligt strammer kravene til formen af de forskellige output mere end nødvendigt. Herved øges nemlig mulighederne for integration af opgaver, der ved første blik forekommer uforligelige.

Først når alle outputs form er endeligt fastlagt og beskrevet i detaljer,
er det muligt endeligt at klarlægge, i hvilket omfang output på et højere
niveau kan bygge på lavere output i deres uændrede form.

Problemets størrelse.

Definitionen af IDB-princippet medfører en stadig udvidelse af et problems størrelse, indtil man når en afgrænsning, hvor der ikke er nogen forbindelse mellem et input foutput, der omfattes af problemet, og et output finput, der falder udenfor problemet. Og det er karakteristiskfor den administrative databehandling, at der er så mange forbindelsermellem input og output, at næsten uanset med hvilket problem, man begynder sin undersøgelse, vil IDB-princippet medføre, at det må udvidefi og atter udvides, indtil man støder på en organisatorisk afgrænsning,der svarer til, at et af de input, der skal inkluderes i problemet,opstår

blemet,opstårudenfor virksomhedens rammer. Virksomhedens organisationkommer
derved til at danne en arbitrær afgrænsning af problemet.

Skønt denne side af emnet rummer mange interessante spørgsmål og åbner muligheder, hvoraf samarbejde mellem en virksomhed og dens leverandører, kunder, banker, offentlige myndigheder og brancheforening eller samarbejde mellem sideordnede virksomheder i samme branche (banker og sparekasser) med henblik på yderligere integration af databehandlingen tværs over de organisatoriske grænser er den mest fascinerende, skal nærmere drøftelse i denne forbindelse undlades. Allerede inden for en virksomheds organisatoriske rammer medfører IDBprincippet problemer af en størrelse, som det er vanskeligt at overse.

Begrænsning af problemets størrelse.

Ønsket om begrænsning af problemets størrelse udspringer af praktiske vanskeligheder og er i modstrid med IDB-princippet. De praktiske vanskeligheder dækker over forhold, der er individuelle for den enkelte virksomhed; men det er alligevel muligt at angive typiske eksempler:

Tidsfaktoren spiller ind på den måde, at en løiming af det samlede problem for en virksomhed måske anslås at ville vare 4-8 år, hvorimod løsningen af et delproblem kan gennemføres på 1-2 år. Man må altså afveje fordelene ved en samlet løsning om adskillige år mod værdien af en isoleret, men meget tidligere gennemført løsning af et delproblem.

Ønsket om erfaring før man giver sig i kast med meget store opgaver
kan forklare, at man udvælger et delproblem som forsøgsområde.

Problemformuleringen kan volde vanskeligheder på områder, hvor der foregår gennemgribende forandringer, og en databehandlingsanalyse må vente på afklaring af forholdene. Foregår der f. eks. arbejde med indførelse af akkordløn, ændring af konteringsreglement, revision af vareudvalget, større tekniske ændringer i produktionsapparatet eller forhandlinger om sammenslutning med eller køb af andre virksomheder, vil de pågældende delområder være mindre egnede som analyseobjekter vedrørende dataproblemer. Men heraf følger ikke, at der ikke i virksomheden findes andre delområder, som med fordel kan undersøges på dette tidspunkt.

De forhold, der oftest vil stille sig i vejen for et angreb af virksomhedenssamlede
databehandlings-problem, er imidlertid af organisatoriskart,
og dette hænger naturligvis sammen med, at ændringer i databehandlingenmedfører

behandlingenmedførersærligt voldsomme konsekvenser for organisationenog
medarbejderne i administrationen.

Skønt det må konstateres, at begrænsning af problemets størrelse er i modstrid med IDB-princippet, kan nødvendigheden heraf ikke afvises, og man må da spørge, om IDB-princippet kan yde nogen hjælp i afgørelsen af, hvordan en afgrænsning kan gennemføres med de færreste skadelige konsekvenser for en senere udvidet integration.

Der kan her blive tale om tre principielt forskellige synsvinkler:

a. afgrænsning ud fra input-siden

b. afgrænsning ud fra output-siden

c. afgrænsning ud fra »kartotek-siden«,

som skal omtales i det følgende.

Afgrænsning ud fra input-siden.

Denne synsvinkel medfører, at problemet afgrænses til at omfatte en
bestemt samling input-data og alle de output, der helt eller delvis bygger
på disse input. (Figur 3).

Den pris, der betales for afgrænsningen, repræsenteres af, at de output,
der også bygger på input-data, der ligger uden for problemets grænser,
må akceptere disse input i en form, der ikke er så velegnet for bearbejdningen,og

ningen,oghvis indhold måske endog ikke er helt forligeligt med indholdetaf
de data, som registreres inden for problemets grænser.

Det vil især være registrerlngstekniske forhold, der gør det ønskeligt at afgrænse problemet udfra input-siden. Overvejer man en ny - måske mekanisk - registrering af visse input-data, kan der være grund til at udvide registreringen til at omfatte alle input-data, der organisatorisk lader sig registrere på samme tid i samme medium. Som eksempel kan nævnes alle input-data, der modsvarer hændelsesforløbet i en producerende afdeling, f. eks. vare-numre, styktal, vægtangivelser, oplysninger om materialespild, arbejderes lønnumre, akkordsatser, tidsforbrug, tidspunkter, temperaturer og luftens fugtighed.

På output-siden vil det kun være ganske simple output, der kan opbygges uden anvendelse af andre input end dem, der registreres inden for problemet. Ved opbygning af et anvendeligt output om materialespild må oplysninger om spildets størrelse sikkert kombineres med oplysninger om de indkøbte materialers kvalitet, som ikke foreligger som input-data inden for problemet. Oplysningerne om lønnumre, styktal og akkordsatser kan nok danne basis for beregning af indtjent akkordløn; men beregning af nettougeløn forudsætter yderligere oplysninger om kantineforbrug, personlige tillæg, sygeløn etc., som igen registreres uden for problemet.

En problemafgrænsning ud fra input-siden efterlader således mange problemer i sit kølvand, og det forekommer umiddelbart fristende at udvide problemet til også at omfatte de input-data, som savnes for beregningen af de forskellige output. Integrationsprincippet er åbenbart ikke så verdensfjernt!

Afgrænsning ud fra output-siden.

Denne synsvinkel medfører, at problemet afgrænses til at omfatte en bestemt samling output og de for beregningen af disse output nødvendige input-data. Man ser, hvordan denne synsvinkel næsten kan siges at udspringe af de uhensigtsmæssige virkninger af en afgrænsning ud fra input-siden, som blev illustreret ovenfor.

Princippet kan illustreres ved indtegning af grænserne for et problem
i figur 4.

Den pris, der betales for afgrænsningen, repræsenteres her af, at en række input-data, som af hensyn til de betragtede output registreres på en særlig måde, ofte må registreres på flere andre måder af hensyn til deres benyttelse ved opbygningen af output, der ligger uden for

problemets grænser. Princippet medfører altså dobbeltregistrering af de
input-data, der også anvendes uden for problemet.

Det, der taler for afgrænsning ud fra output-siden, vil især være utilfredshed med den nuværende arbejdsgang til fremstilling af en type output, måske endog blot utilfredshed med en enkelt output-formular. Faktureringen går måske for langsomt, lønudregningen kræver et stort kontorpersonale, interne statistikker fremkommer med stor forsinkelse o. s. v. Det ligger lige for at søge at indsamle netop de inputdata, som er nødvendige for de pågældende output, på en måde, som letter bearbejdningen.

Som illustration anvendes eksemplet fra foregående afsnit, idet det
forudsættes, at man ønsker at afgrænse problemet, så lønberegningen
går så glat som muligt.

Problemet må nu afgrænses, så det omfatter netop de input-data, som er nødvendige for fremstillingen af de output, som udgør lønberegningensresultater: ugentligt lønudbetalingsgrundlag, lønjournal, oplysningertil skattevæsen, diverse lønstatistikker etc., og man må derfor fra produktionsafdelingerne medtage input såsom stykantal, lønnumre, akkordsatser,timeforbrug og tillægssatser; fra marketenderiet lønnumre og

debiterede beløb, fra interessekontoret tilbageholdte beløb til opsparing,
forsikring, skat etc.

De problemer, som denne afgrænsning medfører, består åbenbart i, at en række af de input, som her er inkluderet i problemet, også kræves til beregningen af andre output. Marketenderiforbruget må også indgå i det output, der hedder regnskab for marketenderiet. De producerede styktal indgår i de output, der hedder produktionsstatistik, lagerbevægelser, kontrol med materialeforbrug etc.

Det ligger lige for at undgå disse dobbeltregistreringer ved at udvide problemet til at omfatte alle output, som bygger på de input-data, som er nødvendige for beregningen af de første output. Man støder atter på integrationsprincippet.

Afgrænsning ud fra »kartotekssiden«.

Denne synsvinkel medfører, at problemet afgrænses til at omfatte de input-data, som er nødvendige for, og de output, som bygger på, et bestemt kartotek. Da ordet kartotek her anvendes i en lidt usædvanlig betydning, er en nærmere forklaring nødvendig.

Ved et kartotek forstås her en samling data, som ikke er egentlige input-data og heller ikke egentlige output. De er ikke egentlige inputdata, fordi de ikke forefindes i samme form eller samme gruppering, som input-dataene. De har altså været underkastet en vis bearbejdning. Men de er heller ikke egentlige output, for de har ikke den form, som kræves af noget ønsket output. De er altså heller ikke færdigbearbejdede. Man kan sige, at kartoteker har karakter af lagre af mellemregningsresultater, idet regning opfattes synonymt med bearbejdning efter visse regler, der ikke må opfattes snævert som f. eks. aritmetiske regneregler.

Forekomsten af kartoteker kan forklares ved flere forskellige egenskaber
ved de input og output, der omfattes 2if problemet.

Den ene forklaring forstås lettest, dersom man forestiller sig kartoteket som et lager af oplysninger. Behovet for dette lager kommer af, at den tidsmæssige fordeling af input-dataene er helt forskellig fra den tidsmæssige fordeling af de ønskede output. Dette medfører varierende tidsmæssig afstand mellem ønsket om et givet output og registreringen af de for beregningen af dette output nødvendige input-data. Forklaringen kan ligge dels i den tidsmæssige rækkefølge, dels i frekvensen af registreringen af input-data eller beregningen af output.

Som eksempel på, at den tidsmæssige rækkefølge indicerer nødvendigheden af et kartotek, kan nævnes ethvert egentligt oplysningskartotek. Det karakteristiske er, at input-data vedrørende de enheder, som kartoteket oplyser om, modtages i tilfældig tidsorden, og at output ønskes i en anden tilfældig tidsorden. Et forsikringsselskab må opretholde et kartotek over policeholderne, fordi ændringer af input-data til de enkelte oplysninger i kartoteket kommer i en tidsmæssig rækkefølge, der ikke er den samme som den tidsmæssige rækkefølge, i hvilken oplysninger (output) ønskes om bestemte forhold vedrørende en policeholder.

Som eksempel på, at forskellig input- og output-frekvens indicerer nødvendigheden af et kartotek kan nævnes kundebogholderiet i en virksomhed, hvor det karakteristiske er, at input (debiteringer og krediteringer) sker ved hvert køb og indbetaling (relativt ofte) og output (kontoudtog, »udestående fordringer«, etc.) ønskes relativt sjældent.

Da enhver tidsmæssig fordeling kan karakteriseres ved både rækkefølge og frekvens af begivenhederne, kan det være svært at afgøre, hvilken egenskab der i et givet problem indicerer et kartotek. Det kan også kun have teoretisk interesse at diskutere det, da indikationen benbart klar. Som eksempel herpå kan nævnes færdigvarelager-kartoteket i en virksomhed. Der er med sikkerhed tale om forskellig rækkefølge af input og output, men der kan også være tale om forskellig frekvens, f. eks. når kartoteket kun bruges ved statustidspunkter, men ikke til oplysninger om løbende lagerbeholdning af bestemte varer.

Den anden forklaring af behovet for et kartotek er af mere bearbejdtiingstefoiisk natur. Hvor der er tale om, at de enkelte input-data aldrig vil blive anvendt i deres oprindelige form, men at bearbejdningen følger faste regler frem til et vist niveau, uanset hvilket output man ønsker at fremstille, kan der være grund til straks at foretage denne standardbearbejdning og derefter lagre de fremkomne mellemresultater i et kartotek. Fremstillingen af ønskede output kan da ske på kortere tid, end dersom man skulle bygge på input-dataene i deres oprindelige form, og der er tillige grund til at forvente, at det vil være lettere at lagre de bearbejdede end de oprindelige input-data.

Kartoteker af denne art kan findes i enhver virksomhed f. eks. i form af fakturabind indeholdende en samling dagsrapporter vedrørende produktion, salg, lagerforhold etc. Dagsrapporterne er netop resultatet af den første bearbejdning af de oprindelige input-data, og hensigten er en komprimering, idet man går ud fra, at man aldrig vil få brug for de enkelte input-data.

Et andet eksempel på en sådan første bearbejdning findes i den opsummering af salget på forskellige varegrupper, som finder sted i de forskellige tælleværker i tidssvarende ksLSseapparater. Input-dataene er de enkelte salgsposter; men man forventer kun at have brug for mere summariske oplysninger for fremstillingen af de ønskede output.

Efter denne udvidelse af kartoteksbegrebet kan det fastslås, at afgrænsning ud fra kartotekssiden meget let vil medføre ønsker om udvidelse af problemet både på input- og på output-siden, idet der hele tiden vil være visse output, som ikke kan opbygges udelukkende på grundlag af kartoteket, idet der kræves yderligere input-data som grundlag, og dette gør det ønskeligt, at man inkluderer disse input i kartoteket. Herved kommer imidlertid andre output ind i billedet, idet nu disse output bygger både på oplysninger fra kartoteket og andre input-data o. s. v. Man genfinder tendensen til at udvide problemet.

Som en uægte form for afgrænsningsprincip skal endelig omtales problem-afgrænsning ud fra »funktionssiden«. Herved forstås, at man lader problemet omfatte de input-data og output, der knyttes sammen af en bearbejdningsmetode af saglig art. Når denne form for afgrænsning kaldes »uægte«, skyldes det, at det bliver databehandlingstekniske forhold, der kommer ind i billedet, og ikke blot abstrakte egenskaber ved problemet selv.

Der kan f. eks. være tale om, at en given opgave forudsætter en særlig form for bearbejdning, som er nedlagt i et program til en EDB-proces, eller til hvis udførelse man har anskaffet særlig arbejdskraft eller særlige kontorhjælpemidler. Det er da nærliggende at afgrænse databehandlingsproblemet ud fra denne tekniske synsvinkel, der dog intet har med problemet selv at gøre. Et praktisk eksempel ville være, at man ud fra arbejdsenheden »en skrivemaskine-stue« afgrænsede sit problem til at omfatte alle maskinskrevne output og de hertil nødvendige input! Det er åbenbart en ren rationaliseringssynsvinkel, der dog meget vel kan være økonomisk fordelagtig.

Valget af afgrænsningssynsvinkel må selvsagt bero på en vurdering af problemkredsens karakteristiske sider, idet det er afgørende, at man holder sig for øje, at IDB-princippets anvendelse ved problemets afgrænsning har til formål at sikre, at grænserne drages på en måde, som gør en senere udvidelse af problemet så simpel som muligt.