I revisors verden er det ofte fordi der optræder specialløsninger, baseret på særlig specialist viden, udviklet af særligt fagligt kyndige personer. Sådanne programmerede løsninger kan sætte revisor i stand til at tilbyde nogle specialiserede ydelser, som ellers kunne kræve særligt uddannede revisormedarbejdere og måske også en urealistisk stor indsats af arbejdstid.
Naturligvis er der også tale om alle de generelle Microsoft Office programmer, som vel altid findes på revisors skrivebord.
Hertil kommer ofte udgaver af særlige kunders systemer, diverse online bankprogrammer, adgange til forskellige informationssøgninger eller portaler og så selvfølgelig det elektroniske postsystem.
Endelig er der 'det egentlige revisorprogram', som i mange revisionsfirmaer stadig kan være et antal forskellige programmer (time-/sagsregnskab, bogholderi, regnskaber, revision o.s.v.), som kan være anskaffet over længere tid og uden overordnede krav til nogen sammenhæng.

Når programmerne ikke spiller godt sammen, bruges der alt for megen tid på hver gang at overføre data fra et program til et andet, og derpå måske at føre det andet programs resultat tilbage til det første. Og måske er tidsforbruget det mindste problem, fordi fejlrisikoen ved de mange 'håndbårne integrationer' i virkeligheden kan få meget større betydning.

Revisors kunde er jo også en del af revisors verden.
De systemer kunderne bruger byder ofte på så ringe mulighed for effektiv sammenhæng til revisors system, at revisor er henvist til kundens papirudskrifter, som grundlag for indtastning af 'de samme tal en gang til'.

Den ideelle løsning på problemstillingen findes ikke. Den er en teoretisk abstraktion, som forudsætter at alle programmer fra starten og i alle detaljer er udviklet med henblik på perfekt integration med hinanden (læs: 'de kommer fra den samme fabrik').
Den næsten ideelle løsning til revisionsfirmaet er IT Revisor systemet, hvor alle revisors vigtige opgaver kan løses i eet integreret system, og hvor revisors kunde med IT Business løsningen kan være perfekt integreret med revisors løsning.

Der er imidlertid også mange andre muligheder, der kan bringes i anvendelse for at opnå et fornuftigt sammenspil mellem forskellige programmer. Der er dog ingen nemme genveje - alle brugbare muligheder kræver et stykke udviklingsindsats i det mindste i det ene af de to programmer, som ønskes 'integreret'.

Microsoft beskriver i deres eviggyldige 'Guidelines for Application Integration' dokument syv principielle teknikker, der kan bringes i anvendelse for at opnå automatisk integration mellem to (eller flere) forskellige applikationer:

1. Web services
Dette instrument har i fem år været den accepterede principielt rigtige generelle teknik, hvormed programmer på en standardiseret måde (via API) kan stille nødvendige eller ønskværdige funktioner og data til rådighed for andre programmer. Det er stadig langt de færreste af revisors programmer, der i noget omfang er født med denne mulighed, og det er under alle omstændigheder et princip, der kræver indarbejdelse af udviklede web services i begge programmers udvikling. Rigtigt anvendt er denne teknik helt ufølsom i forbindelse med versionsændringer i programmerne, og i princippet også overfor 'sammenblanding' af platforme (såvel tekniske platforme som styresystemer).

2. Udtræk, transformer og indlæs (ETL)
Når integrationsproblemet helt specifikt består i konsolidering og samlet præsentation af store informationsmængder fra flere kilder, har dette i mange år været den brugbare teknik. Den kræver naturligvis viden om og en tilstrækkelig grad af stabilitet i datakildernes strukturer og definitioner.

3. Interne programmeddelelser via kommunikationsprotokoller
Dette er det supereffektive 'low level' tekniske princip for kommunikation mellem f. eks. et program og det af programmet benyttede databaseprogram. Kun i helt særlige tilfælde er denne teknik relevant for 'samspil mellem revisors programmer'.

4. Skærm'luring'
Teknisk er det muligt for eet program at 'lure' på de interne datastrømme et andet program genererer i sit bruger-interface. Med tilstrækkelig forståelse heraf, kan det første program bringes til at opføre sig som 'synkroniseret'.
Denne metode vil givetvis være noget man kun gør i en absolut nødsituation.
Hvis det ene program får 'rykket et komma' kan det andet program fejle.

5. Direkte Programkald
Er en ofte anvendt integrationsteknik, der enten forudsætter at det ene program er bygget hertil, ved at udstille og dokumentere sine programmerede metoder (API), eller ved at der gøres en grundig udviklingsindsats i begge programmer, for at opnå det tilsigtede i en brugbar fælles forståelse. Det er typisk med denne teknik man integrerer sit program med Microsofts Office programmer (for slet ikke at tale om selve Windows systemet), men eftersom teknikken er følsom i forbindelse med versionsændringer i programmerne, er det nok kun en metode som er relevant, når det andet program vedligeholdes af en særligt troværdig part.

6. Direkte datatilgang
Det er generelt yderst betænkeligt at lade to programmer læse og manipulere direkte i hinandens data, uanset om de to programmer benytter forskellige eller samme databaseprogram. Det kræver en meget sikker forståelse af generel datastruktur og logiske datasammenhænge samt en klar 'oversættelse' af den detaljerede datamodel i begge programmer, for med fornuft at søge integration i datadeling. Hertil kommer at teknikken er ekstremt følsom i forbindelse med versionsændringer i programmerne, fordi alle tre elementer i den 'sikre forståelse' typisk vil kunne falde til jorden i det ene eller i begge programmer. På det detaljerede data-niveau vil definitioner jo altid være del af den enkelte programleverandørs intellektuelle råderum.
Kun i situationen, hvor de to programmer i virkeligheden er det samme program fra den samme leverandør, er direkte datatilgang den indlysende rigtige teknik.

7. Eksport/import af data(filer)
Den mest anvendte af alle integrationsteknikker, som naturligvis kan automatiseres mere eller mindre. Teknikken er følsom i forbindelse med versionsændringer i programmerne, men slet ikke i samme grad som en direkte datatilgang, fordi en automatiseret eksport/import pr. definition må være baseret på et 'fælles aftalt' grundlag (mellem de to programmer).

Det er utvivlsomt, at teknikkerne 1, 5 og 7 er de mest frugtbare tilgange til opnåelse af et rimeligt automatiseret sammenspil mellem revisors forskellige programmer. Det er sikkert, at anvendelsen af web services er den teknik, der skal vælges i fremtidens udvikling af nye programmer.

Hvad gør Focus IT?
Kendetegnet for de tre fornuftige teknikker til opnåelse af automatiseret integration er, at de alle kræver en høj grad af enighed mellem to programmer, der søges integreret. Hvis det ene program er klart dominerende (Microsoft Windows/Office eller lign.), udgøres grundlaget for enigheden naturligvis af dette programs muligheder (API).
I alle andre situationer (skatteprogrammer og andre værktøjer samt flere af markedets dominerende kundesystemer) søger Focus IT samarbejde med leverandører af de pågældende programmer med henblik på at aftale et effektivt grundlag for integration med IT Revisor.