1 juli 1985 startades den 20:e och sista föreningen i Stadshypoteks nya datasystem. Konstruktionsarbetet hade då pågått i mer än två år och man hade investerat 32 personår i det driftsatta systemet.
I denna artikel beskriver projektledaren Leif Wretholm hur projektorganisationen varit uppbyggd och hur systemet löpande har kontrollerats och modifierats.
Stadshypotek är Sveriges största långivare till bostäder. De utestående lånen uppgick 1984 till 119 miljarder kronor fördelade på 314.000 fastigheter.
Stadshypotek består av 20 regionalt verksamma föreningar, som svarar för utlåningen, samt Stadshypotekskassa som svarar för upplåningen, framför allt på obligationsmarknaden. Antalet anställda är 320, varav 50 på Stadshypotekskassan. Det system som beskrivs i denna artikel innehåller alla handläggnings- och förvaltningsfunktioner vad gäller utlåning. Dessutom innehåller systemet rutiner för rekvisition av betalningsmedel och administration av betalningsmedel och administration av kassans lånefordringar mot föreningarna. Så gott som samtliga föreningstjänstemän är således beroende av detta terminalsystem.
Det administrativa utvecklingsarbetet bedrivs i form av ett ADB-samarbete mellan föreningarna och kassan. Arbetet styrs av en ledningsgrupp, bestående av kassans VD och vVD samt fem verkställande direktörer från föreningarna.
Föredragande är chefen för ADB-samarbetet. Inom ADB-samarbetet sker utveckling i projektform. Kostnaderna fördelas mellan föreningarna och kassan.
Efter en förstudie, åtföljd av en huvudstudie, startades i april 1983 konstruktionsarbetet på ett modernt, terminalbaserat realtidssystem för föreningarnas och kassans utlåningsadministrativa rutiner. Projektet fick namnet SOL, Stadshypotek On Line. Fr o m juni 1984, då första föreningen gick i provdrift, lades föreningarna successivt om till det nya systemet. I juli 1985 startades den 20:e och sista föreningen i SOL-systemet.
Skälet till beslutet om att ersätta det äldre satsvisa uppbördssystemet med ett terminalbaserat realtidssystem sammanfattade ledningsgruppen enligt följande:
HÖGRE SERVICEGRAD
mot banker, låntagare etc
ÖKAD SÄKERHET
i handläggningen
i lagrad information
BÄTTRE BESLUTSUNDERLAG
STÖRRE FLEXIBILITET
datatekniska aspekter
allmän låneteknik
volymoberoende
MINDRE NYANSTÄLLNINGSBEHOV
FÖRBÄTTRAD ARBETSMILJÖ OCH ORGANISATION
Ledningsgruppen beslöt att systemet skulle innefatta följande funktioner:
All utlåning administreras i systemet
Registrering av ansökan och värdering
Rekvisition av medel och utbetalning av lån
Utskrift av lånehandlingar, restantielistor m m
Aviseringar och kravrutiner
Inbetalningar inkl överföringar från Pg/Bg
Bevaknings- och frågefunktioner
Statistik/analysunderlag
Likviditetsplanering centralt
Rent tekniskt är systemet uppbyggt enligt följande principbild (se figur 1)
Figur 1
Kassans systemuppbyggnad
FÖRENING | KASSA | |
FÖRENING | FÖRENING | PG/BG |
IBM 3033 |
20 föreningar
300 terminaler Ericsson 4-färg
50 skrivare Ericsson 4160
Nätverk DATEL och DATEX
Daglig DATEX-överföring från Pg/Bg
110 datarutiner
314.000 belånade objekt
400.000 lån
500.000 låntagare
119.000.000.000 kr i lånestock
12 MB primärminne
16 GB sekundärminne (skiva)
När projektet avvecklas i december 1985 har Stadshypotek investerat 32 personår i det driftsatta systemet.
Kvalitet
När man inom Stadshypotek diskuterade vilka kontroller som skulle utföras var man ganska snart på det klara med att man dels ville kontrollera om projektet hade möjligheter att innehålla tids- och kostnadsramar. Det var även av intresse att kontrollera huruvida det system som projektet producerade var kvalitetsmässigt godtagbart. Ett kvalitetsmässigt godtagbart system definierades på följande sätt:
a) Användarvänligt, så att det var en naturlig del av föreningarnas och kassans vardag. Systemet fick ej endast bli ett hjälpmedel vid sidan av verkligheten.
b) Kontrollerbart, så att såväl internrevisor som extern revisor genom systemet kan få rationell hjälp att nå uppsatta kontrollmål.
c) Skyddat, så att såväl misstag som avsiktliga försök till manipulering av information i möjligaste mån undvikes.
d) Tillgängligt under ordinarie kontorstid och tillförlitliga satsvisa bearbetningar, framförallt vad gäller uppbörd.
Projektorganisation
Ett av de viktigaste instrumenten för att hålla kontroll över att projektet är på rätt kurs d v s innehåller det ovan definierade kvalitetskravet och framställer ett användbart system är projektorganisationen. För Stadshypotek var de viktigaste kriterierna i detta sammanhang:
– Projektets sammansättning, vilket innebar en kraftig användarmedverkan i systemutformning och test. Fyra blivande användare med mycket god kännedom om föreningarnas verksamhet tränades i systemering och utförde, tillsammans med ADB-personalen, systemerings- och systemtestarbetet i projektets lokaler. Dessa fyra arbetade således 1/2-tid i projektet och 1/2-tid på sin förening under hela huvudstudien och etapp 1, d v s under sammanlagt drygt två år.
I övrigt användes konsulentmedverkan på specialområden som projektledning, databasteknik, programmering, utbildning och omläggning.
– Dedierad dator på IBM, d v s ingen ”egen” driftavdelning, byggdes upp. Med IBMs datacentral avtalades, efter en offertomgång mot 10 leverantörer/datacentraler, om totalt ansvar för drift, kommunikation och efterbehandling. Detta ansvar gällde såväl hårdvara som systemprogramvara och har hittills fungerat bra.
– Projektets organisation var sådan att formell och reell organisation under projektledaren var densamma under hela projekttiden. Detta ledde till en organisationsförändring efter huvudstudien och en smärre justering under etapp 1. Genomförandefasens organisation såg ut på följande sätt (se figur 2).
Figur 2
Ledningsgrupp | |||
Projektledare | Referensgrupp | ||
Teknik inkl DBA | Systemering utbildning test | Programmering | Omläggning |
Ledningsgrupp och referensgrupp sammanträdde 4–6 ggr per år och var de enda i projektet som ej tidsdebiterade sina insatser. Tidsdebitering ansågs vara av vital betydelse, eftersom man kunde göra uppföljning mot budget samt, genom att jämföra med t ex antal kodrader, fastställa programmeringsarbetets FARt genom vattnet, d v s produktiviteten i programmeringen. Detta kunde även ske vad gäller systemeringsarbetet. Den viktigaste principen i ovan nämnda projektorganisation är dock dualismen. En rutin (ett eller flera program) var klar, när de inhyrda användarrepresentanterna godkänt rutinen i fråga. Det var således ej en fråga för programmeringsledaren eller för någon enskild programmerare. Flertalet rutiner vandrade 3–5 gånger mellan systemeringsgrupper och programmeringsgrupper innan godkännandet var ett faktum. Dualismen fungerade även motsols, så att programmeringsledaren kunde sända undermåligt programmeringsunderlag i retur till systemeringsgruppen, vilket även inträffade.
Omläggningsgruppens arbete berörs närmare i nedanstående avsnitt angående driftsättning. Här bör dock påpekas att arbetet är ytterst känsligt från kontrollsynpunkt, dessutom mycket komplicerat.
– Projektets avveckling var en planerad aktivitet med lång framförhållning. Ledningsgruppen tog tidigt ett beslut om att inrätta en tjänst som systemförvaltare med ansvar för smärre modifieringar och korrigeringar i systemet. Till sitt förfogande har systemförvaltaren databaskunnig personal (databasadministratören) och programmeringskunnig personal. Idag arbetar totalt fyra personer i systemförvaltargruppen.
Projektledarens uppgift var att överlämna rutinerna till systemförvaltaren för drift. Systemförvaltaren kunde underkänna rutinen, om den efter hans, trots tidigare nämnda användartester, ej ansågs leva upp till specifikationerna eller övriga formella krav, t ex användardokumentation. Så skedde även i vissa fall. Systemförvaltaren kom genom detta förfarande tidigt in i arbetet och en dualism byggdes in även här. Det var även systemförvaltarens uppgift att kontrollera att föreningarna omlagts till det nya systemet på ett korrekt sätt. Avstämningsprocedurerna utarbetades i samarbete med representanten från Bohlins Revisionsbyrå. När samtliga föreningar omlagts, vilket skedde i juli 1985, och samtliga rutiner driftsatts, i december 1985, är projektet i sin helhet avvecklat. En successiv avveckling av projektpersonal har skett sedan våren 1985.
Kontroll av projektet
Kontrollen av att projektet hade möjligheter att innehålla tids- och kostnadsramar har en naturlig knytning till kontrollen av att ett kvalitetsmässigt godtagbart system framtas. Det är ingen större fördel att i en efterstudie konstatera att projektet innehöll tids- och kostnadsramar, men att systemet ej går att använda. Projektkontrollen utfördes i vårt fall sedan halva genomförandefasen av etapp 1 klarats av. Detta innebar således att ca 60 % av projektets totalkostnader redan tagits. Projektrevisionen, som detta arbete kallades, utfördes av en utomstående konsult med gedigen erfarenhet av projektledning och applikationsutveckling. En av hans svåraste uppgifter var att konstatera vilka program som var klara. Definitionen av ett klart program måste vara strikt. I vårt fall hade vi stor hjälp av vår projektorganisation. Ett program var klart om användargruppen godkänt programmet i fråga och inga anmärkningar återstod. Detta leder till en binär bedömning, d v s endast ”klart” eller ”ej klart” används. Skall 70 program vara ”klara” till en viss framtida tidpunkt måste ett visst antal program vara ”klara” vid kontrolltidpunkter. Vad konsulten konstaterade var att om vissa av honom konkreta mål var uppfyllda i april 1984, borde ledningsgruppen ge klarsignal till slutförande och start av första förening i maj 1984. Denna rekommendation ansåg han sig kunna göra efter det att han konstaterat att projektledningen tycktes ha grepp över utvecklingen och applikationen. Moderna metoder för projektadministration och projektstyrning användes och projektet var kapabelt att tyda metodernas utdata. Projektorganisationen och projektmedlemmarnas erfarenhetsbakgrund bäddade för att ett kvalitetsmässigt godtagbart system konstruerades. Hur kunde han säga detta?
Jo, därför att de 4 användarrepresentanterna i projektet skrev programförutsättningarna och testade programmen, visserligen med aktiv övervakning och bistånd av systemerare, men ändock. Det var inte endast fråga om att söka förankra tekniska lösningar hos användare i form av en referensgrupp e dyl som sammanträdde varannan månad eller så. Här arbetade 4 användare fram programförutsättningarna och testade produkterna. Dessutom följde programmeringsledaren arbetet i detalj och dokumenterade resultatet i lägesrapporter till projektledningen.
Projektledningen bestod av projektledaren samt cheferna för arbetsgrupperna. Dessa sammanträdde regelbundet varannan vecka för att kontrollera tid, kostnad och kvalitet. En oundviklig effekt är att vissa personer måste bytas ut, utöver normal avgång. Dessa beslut är svåra, men måste tas. I vårt fall skedde utbyte av tre personer. Detta skall ses mot bakgrund av att ca 20 personer var involverade i de 32 personår, som projektet omfattade.
Löpande avstämning
Fr o m huvudstudien avstämde projektledaren löpande det system som växte fram med en representant från kassans externa revisor, Bohlins Revisionsbyrå. Detta ledde till beslut om ett antal åtgärder, vad beträffar systemutformningen:
a) ingen integration mellan kassans reskontra vad gäller fordringar på resp förening
b) en särskild kontroll- och revisionsdatabas i SOL-systemet. I denna databas lagras alla förändringar, som användare gör via online-transaktioner
c) ett behörighetssystem med 15 behörighetsklasser. Detta system administreras av maskinleverantörens systemprogramvara och är oåtkomligt från applikationsprogramvaran
d) medverkan vid information till föreningarnas externa revisorer
Punkt a) fordrar en viss kommentar. Eftersom SOL-systemet administrerar rekvisition av medel från kassa till föreningarna och systemet även redovisar samtliga utbetalda lån, finns således med automatik kassans fordran på resp förening. Trots detta behålls ett fristående reskontrasystem, i vilket separat bokföring sker vid rekvisition, uppbörd, inlösen o s v. – Därigenom erhålls en perfekt avstämning, som visade sig värdefull vid driftsättningar av de första föreningarna och fortlöpande ger en säkerhet i medelsförvaltningen. Från kontroll- och revisionsdatabaserna erhåller föreningarnas externa revisorer löpande datalistor över utförda ändringar. Dessa ändringar kan gälla säkerheter, amorteringsplan, räntesatser o dyl för enskilda lån. Utöver detta kan revisorerna begära utlistning av förändringar under viss period.
Vad beträffar behörighetssystemet ansågs det bl a erforderligt att tjänstemän med skilda behörigheter beviljade lån och utbetalade lån. Ändringsrutinerna låg också i en mycket hög behörighetsklass. Det var även en självklarhet att tillse, att en föreningstjänsteman endast kunde se den egna föreningens lån. Det bör påpekas att många och långa diskussioner föregick utformning och införande av behörighetsklasserna. Föreningarna, revisorsrepresentanter, kassan deltog i dessa diskussioner med projektet.
Bohlins Revisionsbyrå har utarbetat en PM, som behandlar revisionsmål och hur dessa kan nås med hjälp av SOL-systemet. Detta är ett resultat av en ”revisorsdag” som anordnades våren 1985.
Till kvalitetsbegreppet enligt ovan hör även drift. Det första man där tänker på är svarstiderna, som i vårt fall enligt avtal med IBMs datacentral skall vara tre sekunder för 95 % av transaktionerna under en dag. Vissa bearbetningar har omarbetats för att uppfylla detta och en stor insats har gjorts av IBMs systemprogrammerare under 1985 för att ”trimma” systemet, framför allt användning av systemprogramvara. Lika viktigt är dock driftrutinerna på datacentralen för de satsvisa bearbetningarna. I vårt fall erhålls dagligen magnetband från Bankgirot och Postgirot med inbetalningar (OCR).I SOL-systemet finns programmerade kontroller som förhindrar inläsning av samma band två ggr. Likaså finns avstämningsrutiner med resp förenings fristående huvudbokssystem och denna inläsning, som omedelbart avslöjar om band ej har inlästs. Genom denna avstämningsprocedur avslöjas även ev fel i uppbördsbearbetningarna, d v s när lån aviseras för betalning eller kravrutiner körs. Alla parametrar för uppbördsbearbetningen sätts av systemförvaltaren via en beställningsbild on-line. För övriga satsvisa bearbetningar sker även beställning och sättning av ev parametrar av systemförvaltaren eller resp användare direkt (styrs av behörighetssystemet). Inga som helst parametrar sätts av driftpersonal. Inga som helst avstämningar görs av driftpersonal.
Idriftsättning
Som tidigare nämnts skedde igångsättningen av det nya systemet föreningsvis. Omläggningsgruppen hade konstruerat ett 20-tal omläggningsprogram, som
– Läste den gamla Sius-databasen (det äldre satsvisa uppbördssystemet), ”omvandlade” lånen till SOL-lån samt uppdaterade den nya realtidsdatabasen med dessa. Lån som var ”underliga” utlistades för manuell inläggning.
– Kontroll- och avstämningslistor upprättades, så att avstämning kunde ske mellan Sius och SOL för aktuell förening. Även avstämningsrutiner mot föreningens bokföring skapades.
– Specialrutiner skapades (on-line, realtidsuppdaterande) för att korrigera SOL-databasen vid omläggningsfel samt för att lägga in utlistade lån (ej omlagda), som ej tagits om hand av omläggningsprogrammen.
Resp förenings VD fick formellt godkänna omläggningen genom en skriftlig bekräftelse på att den lånereskontra som han erhållit i SOL-systemet överensstämde med föreningens räkenskaper (huvudbok).
Omläggningsrutinerna förbättrades successivt mellan de första föreningarnas omläggningar. Vissa felaktigheter i de tidiga programmen, både vad gäller omläggning som ordinarie program i SOL-systemet, föranledde att felaktiga data i SOL-databasen korrigerades med ”fixar”. I vårt fall gjordes detta av Teknik-gruppen. Databasadministratören använde en systemprogramvara, DB-fix, med vilken alla data kunde manipuleras på tecken-nivå. Någon automatisk loggning på dessa åtgärder kan ej ske. Återkomsten till DB-fix-användning för uppdatering i produktionsdatabasen begränsades via behörighetssystemet till databasadministratören. I samråd med projektrevisorn ålades DBA att föra en manuell logg på samtliga sådana ingrepp. I denna logg presenteras databasposternas utseende före resp efter ingreppet samt en förklaring och ett motiv för själva ingreppet. Vissa ingrepp förorsakades av användarmisstag, som i sin tur förhindrades i möjligaste mån fortsättningsvis, genom att bättre logikkontroller och valideringar gjordes i on-line programmen. Hittills har ca 15 DB-fix-ingrepp gjorts av DBA.
Ett kontrollinstrument, som projektet länge sökt efter, har nyligen installerats. Detta gäller en s k termkatalog. I ett realtidssystem uppdateras en term ofta av flera program, t ex termen lånesaldo. Syftet med termkatalogen är att få en tillförlitlig uppgift om vilka program som behandlar termen lånesaldo. Detta är en mycket användbar information för felsökning och revision. Likaså vill man gå motsatt väg och genom att fråga på programidentitet erhålla information om vilka termer ett visst program manipulerar med. Någon standardprogramvara, användbar mot DL/1-databaser, finns ej för närvarande på marknaden, varför den framtogs i samarbete med Systempartner. I en rutin på stordatorn läses programmen, s k cross-referens-tabeller, varefter informationen inmatas i en IBM PC, där termkatalogen finns för on-line-frågor eller utlistning. Ny överföring från stordatorn kan ske periodiskt eller varje gång aktuell information erfordras. För artikelförfattaren är det en gåta hur en revisor över huvud taget kan bedöma ett system från revisionell synpunkt utan ett sådant instrument.
Leif Wretholm, projektledare