Aktuellt: En praktisk lektion i konsten att köpa dator

Informationshantering

En utveckling mot decentraliserad och användarnära databehandling äger rum ute i näringslivet. Denna utveckling kan leda till att olika företag inom koncerngrupper och enheter inom ett företag får svårt att utbyta information. Informationen, som är en av företagens värdefullaste resurser, måste vara tillgänglig i den utsträckning det gagnar verksamheten.

Databaser som byggs upp får inte raseras av förändringar i arbetssätt och organisation. Vid planeringen av informationen är det en god hjälp att först definiera informationsstrukturen. Informationen kan då lämpligen grupperas enligt följande:

* Koncern/Företagsgemensam information, som behövs vid flera enheter och funktioner samt där en hög grad av gemensamma regler måste iakttagas. Exempel på sådan information är redovisningsinformation, budgetinformation, cash-flow och valutainformation samt planeringsinformation mellan enheter som har produktionssamarbete.

* Lokal information är sådan information som enbart behövs vid ett företag eller enhet och vars hantering i hög grad kan anpassas till de enskilda förutsättningarna som gäller.

* Personlig information är sådan som utnyttjas av en eller ett fåtal personer. Informationen kan betraktas som arbetsmaterial och behöver inte regleras alls.

Vid utnyttjande av data är det lämpligt att skilja på spontan databehandling med hjälp av ett antal basprogram samt databehandling för den operativa verksamheten. Basprogram är exempelvis:

• Ord- och textbehandling

• Hjälpmedel för planering

• Kalkylering och minnesanteckningar

• Meddelandeöverföring

Basprogram kommer att utvecklas snabbt. En spridning av dessa tjänster bidrar till att höja datamognaden och därigenom skapa en god miljö för rationell systemutveckling. För den operativa databehandlingen kan en indelning av systemen ske som i stort sett följer den uppdelning av informationen som beskrivits ovan.

ADB-teknik

Organisation

Under denna rubrik beskrivs ansvarsfördelningen av företagets ADB-resurser. Det är framförallt inom områdena Utveckling, Drift och Användarstöd/Utbildning som olika alternativ kan finnas.

Säkerhet

När ett företags beroende av ADB-tekniken ökar är det viktigt att skapa ett skydd som minskar effekterna av en utslagning av datorer och system. Den vanligaste och nödvändigaste åtgärden är säkerhetskopiering och ett brandsäkert förvar. Det är dock nödvändigt att mera detaljerat analysera sårbarheten per system och typ av hårdvara samt att skapa ett skydd som svarar däremot.

I strategin skall framgå den säkerhetspolicy som skall ligga till grund för bedömningar och utformning av skydd i samband med säkerhetsgenomgången. Resultatet skall dokumenteras i en ADB-säkerhetsplan.

1. FAKTAINSAMLING

Eftersom varje företag har speciella förutsättningar för upphandlingsarbetet måste en faktainsamling starta arbetet. Om extern konsulthjälp anlitas är det nödvändigt att dokumentera arbetet ordentligt eftersom det också kan ses som en uppdragsbeskrivning för upphandlingsarbetet.

I faktainsamlingen samlas uppgifter in om:

* Företagets ADB-erfarenheter. Den nuvarande ADB-lösningen beskrivs mera i detalj eftersom den är viktig för den fortsatta utbyggnaden.

* Finns en ADB-strategi formulerad skall den självklart ingå i faktainsamlingen. Det är det viktigaste dokumentet genom att inköpsarbetet härigenom får en klarlagd inriktning.

* Orsaken till att upphandlingsarbetet har aktualiserats.

* Speciellt känsliga och viktiga rutiner för företaget.

* Företagets krav och synpunkter på nya rutiners utvecklingstakt, tidplan för önskade förändringar etc.

* Egna resurser. Det är viktigt att konstatera personalsammansättning, kunskapsnivå, attityder och arbetsbeläggning. Dessa uppgifter ger dels svar på hur företagets personal kan/skall fungera i den fortsatta upphandlingen, dels erhålles en uppfattning om datamognaden.

2. FÖRSLAG TILL PRINCIPLÖSNINGAR

Även om en ADB-strategi finns så ger den inte alltid entydiga lösningar på problemen. Det kan därför vara lämpligt att formulera ett antal principiella lösningar som kan vara tänkbara i den aktuella upphandlingssituationen.

För varje förslag beskrivs förutom innebörden även vilka tänkbara för- och nackdelar som finns samt en ungefärlig kalkyl baserad på riktvärden.

3. KRAVSPECIFIKATION

Kravspecifikationen skall framförallt beskriva funktionskraven på applikationsprogramvaran, men även de tekniska och allmänna kraven är viktiga att få fram och dokumentera. Dispositionen av kravspecifikationen kan byggas upp kring följande delar:

A. En översiktlig beskrivning av det totala systemet

Ett överskådligt och bra sätt att beskriva applikationssystem är att grafiskt illustrera systemets olika delar (= moduler eller delsystem) i ett flödesdiagram som visar modulernas namn och den koppling som finns dem emellan. Beskrivningen av kopplingarna görs med pilar som visar mottagande och avlämnande modul. Dessutom bör kravet på automatiska kopplingar poängteras. Är delsystemen företagsspecifika kan det även vara lämpligt att kortfattat verbalt ange deras syften.

B. Funktionsbeskrivning av varje delsystem

Denna del av kravspecifikationen är ett av upphandlingens viktigaste dokument. En slarvigt formulerad kravspecifikation minskar möjligheten att hitta en bra lösning både om den skall sökas bland standardsystem eller om den skall skräddarsys.

För att åstadkomma en detaljerad kravspecifikation kan exempelvis checklistor användas. För de vanligaste administrativa rutinerna i ett företag finns i litteraturen upprättat checklistor på funktioner som kan/måste ingå. Genom att för varje punkt i checklistan värdera och beskriva det egna företagets krav erhålles en ganska snabb väg att formulera en kravspecifikation. Det är dock viktigt att kritiskt värdera checklistorna så att inte väsentliga funktioner glöms bort.

Om ett företag står inför större genomgripande förändringar kan metoden innebära svårigheter dels med att frikoppla sig från det befintliga, dels att beskriva arbetsflödet i och mellan de olika rutinerna. Om förhållandena är på detta sätt kan kravspecifikationen ske med hjälp av en mera omfattande behovsanalys.

C. Tekniska krav på maskinvara

Med tekniska krav på maskinvaran avses de krav som måste ställas på hårdvaran och den nödvändiga maskinprogramvaran (= operativsystem och hjälpprogram). Kraven formuleras i termer av

– prestationer

– miljö

– säkerhet

– sekretess

– handhavande

– service.

4. OFFERTFÖRFRÅGAN

När de systemmässiga och allmänna kraven sammanställts skall de fogas in i en offertförfrågan som skickas till de leverantörer som valts ut enligt pkt 5 nedan. Offertförfrågan kan lämpligen disponeras enligt följande mall:

A. Följebrev

Inbjuder leverantören till offertgivning. I brevet ges information om hur lång offertperioden är, vem som besvarar frågor under denna period, till vem offerten skall ställas och i hur många exemplar.

B. Beskrivning av företaget

Som offertgivare är det nödvändigt att få information om företaget. En kortare beskrivning av företagets historia, dess produkter, marknad och kunder är bra information. Dessutom är vissa fakta nyttiga som beskriver företagets storlek och tillväxttakt. Finns en årsredovisning som ger dessa uppgifter kan den lämpligen bifogas.

C. Kravspecifikation

Enligt ovan beskrivna uppställning.

D. Tidplan

Beskriver vilka aktiviteter som skall ske och vid vilken tidpunkt innan de efterfrågade rutinerna är satta i drift.

E. Offertmall

Anger hur leverantören skall disponera sitt svar.

Man måste få leverantörerna att inse att det är viktigt att mallen följs eftersom den i hög grad underlättar den kommande utvärderingen. Att läsa och få en jämförande överblick av 67 offerter som alla är uppställda på olika sätt tar väsentligt längre tid än motsvarande antal som alla har informationen sammanställd enligt en angiven mall. Tyvärr bryr sig många leverantörer inte om den föreslagna offertmallen eftersom de har egna utformade mallar som finns inlagda i ordbehandlingssystem. I större omfattande upphandlingar skall dock offertmallen vara ett orubbligt krav. En offertmall kan förslagsvis bestå av följande rubriker:

• Företagsbeskrivning

• Systemförslaget beskrivet genom flödesschema, standardsystemdokumentationer etc

• Maskinvara

• Maskinprogramvara

• Back-up/återstartsrutiner och övriga säkerhetsskapande möjligheter

• Omläggningsassistans

• Service

• Dokumentation

• Utbildning

• Leverans- och betalningsvillkor där även en komplett prissammanställning skall göras

• Avtalsvillkor och garantier

• Referenser

5. VAL AV TÄNKBARA LEVERANTÖRER

Att välja rätt leverantörer att skicka offertförfrågan till avgör kvalitén på den slutliga upphandlingen. Med den specialisering som sker hos dataleverantörerna är det omöjligt för en inköpare som inte har kännedom om branschen att vara säker på att samtliga ”bra” leverantörer är utvalda, därtill krävs specialistkunskap. De källor som finns att söka i är huvudsakligen bland

• större hårdvaruleverantörer

• system och programvaruhus

• turnkey-leverantörer

• böcker och facktidskrifter

• Dataföreningens Applikationsforum.

Maximalt skall 7–8 leverantörer tillfrågas, men 5 rekommenderas som ett lämpligt antal.

Så kallade kontrollofferter rekommenderas inte eftersom det ger ett oseriöst upphandlingsintryck och visar på dålig respekt för leverantörernas arbete. Kräver man att leverantören tar seriöst på offertförfrågan skall även offertmottagaren ta seriöst på offerten.

6. OFFERTPERIOD

Under offertperioden hålls kontakt med leverantörer per telefon för att besvara frågor m m. Om möjligt skall personliga besök från säljarna undvikas eftersom det lätt utvecklas till en påverkan mot lösningar som inköparen på detta stadium har svårt att ta ställning till. Offertförfrågan skall vara så utförligt formulerad att det inte skall krävas mer än enstaka kompletterande frågor.

7. OFFERTINLÄSNING – FÖRSTA VAL

Inkomna offerter läses igenom en gång för att få en allmän uppfattning om de är kompletta. Dessutom skall ett första allmänt intryck erhållas. Därefter sker en grov systematisering för att fånga upp de frågor som leverantören måste förtydliga.

Några jämförelsekriteria som offerterna skall ställas mot i denna systematisering är följande:

A. Leverantören

• Ekonomisk stadga

• Erfarenheter

B. Maskinvaran

• Utbyggnadsmöjligheter

• Språngkostnader

• Antal levererade system

• Kringutrustning (skivminne, skrivare, terminaler etc)

C. Programvaran

• Jämförelse mot kravspecifikationen

• Filhantering

• Kommunikationsprogramvara

• Rapportgenerator och andra hjälpprogram

• Säkerhetsmöjligheter

D. Dokumentation/Utbildning

E. Service

• Servicekontor – var?

• Inställelsetid

• Service på programvaran

Efter denna genomläsning och sammanställning är det lämpligt att träffa leverantörerna och låta dem dels presentera sin offert, dels utveckla lösningar som de tycker är lämpliga. Frågor som uppstått vid genomläsningen skall även lämnas till leverantören vid detta tillfälle. Besökets längd beror naturligtvis på offertens omfattning, men behöver sällan överstiga en halv dag och sker lämpligen hos det upphandlande företaget. Arbetssteget skall leda fram till att två leverantörer väljes ut för fortsatta detaljstudier. Valet sker alltså först utan hänsyn till lönsamhetskalkylen för att inte förledas till att ta för stor hänsyn till alternativens kostnader. Det viktigaste är att finna alternativ som uppfyller funktionskrav, tillväxtkrav m m för att därefter försäkra sig om att alternativen är ekonomiskt realistiska innan det slutliga valet görs.

8. DETALJSTUDIE

I detta arbetssteg tas förnyad kontakt med leverantörerna som valts ut i föregående arbetssteg för att få en detaljerad kunskap om de olika alternativen. Innan kontakterna tas skall upphandlingskriterierna formuleras mera detaljerat.

Det gäller alltså att konkretisera mera detaljerade krav på olika kriterier som leverantörens lösning skall ställas mot. I en mera omfattande värderingsmodell med många kriterier är det ibland nödvändigt att poängbedöma leverantörerna mot varje kriterium samt fastställa vikten per kriterium som visar hur väsentligt det bedöms.

Ifyllandet av bedömningsmallen kräver oftast ingående studier av exempelvis ett offererat standardsystem eller hårdvaran med tillhörande maskinprogramvara, vilket lämpligast sker dels genom demonstrationer hos leverantören, dels genom referensbesök hos något lämpligt företag.

För att demonstrationen av ett standardsystem skall bli lyckad måste de egna kraven ha formulerats så detaljerat för unika och viktiga funktioner för företaget att det är möjligt att ordentligt testa standardsystemet mot dessa. Tyvärr formuleras funktionskraven oftast så allmänt att det är svårt att riktigt klart kunna betygsätta systemen. Ett annat önskemål inför en demonstrationskörning är att testsystemet förbereds med det egna företagets artiklar, order och andra företagsunika data. Detta innebär en del förberedelsearbete men kan vara väl värt denna insats.

Ett av upphandlingens viktigaste moment är att genomföra ett referensbesök hos ett företag som nyligen har installerat motsvarande produkter.

Referensbesöket fyller många olika syften. Bland dessa kan nämnas möjligheten för det egna företagets blivande användare att få se och höra andra användare berätta om för- och nackdelar med systemet både under löpande drift och under själva installationsarbetet. Vidare ger referensbesöket möjlighet att se systemets förmåga att klara bearbetningskrav, svarstider m m under realistiska volymförutsättningar. Det är en fördel om referensbesöket kan ske utan att leverantören varken har varit med och valt ut företaget eller medverkar vid själva besöket.

Förslag till slutlig leverantör skall avsluta etappen.

9. KONTRAKTSFÖRHANDLINGAR

Slutförhandlingar med den utvalda leverantören skall leda fram till ett avtal och en projektplan med tidsatta aktiviteter som reglerar installationen.

De flesta datorleverantörerna använder sig av Avtal 80 för att reglera villkoren mellan leverantör och kund. Detta har naturligtvis den fördelen att avtalstexterna inte behöver granskas för varje enskild offert. Det är dock viktigt att ha klart för sig att vissa av paragraferna i Avtal 80 och SDA 82 är leverantörsvänliga så att dessa kan omförhandlas. Exempel på sådana paragrafer är:

• Leveransförseningsparagrafen

• Skadeståndsparagrafen

• Garantitidsparagrafen (för programvara)

I slutförhandlingen med leverantören finns hos många inköpare en önskan att reducera den totala kostnaden för upphandlingen genom olika former av prutning. Min uppfattning är att detta är möjligt i de flesta upphandlingar och också önskvärt. Självklart skall prutandet inte drivas så att affären inte blir ekonomiskt intressant för leverantören, utan mera vara ett uttryck för ”god vilja”.

I dessa diskussioner kan det vara lämpligt att se på förutsättningarna att reducera kostnaden för utbildningen. Detta motiveras med att en installation blir en bra installation endast om användarna har kunskap om systemets möjligheter och begränsningar. Saknas denna kunskap kommer en negativ attityd att växa fram mot systemet, vilket faller tillbaka på leverantören. Genom att investera i utbildning kommer leverantören att tillförsäkra sig en nöjd kund som kommer att ställa nya krav på systemet, vilket kan generera nyförsäljning. Prutningen på utbildningskostnaden blir en investeringskostnad för leverantören och därför inte bara en prutning.