Bing Hodneland logo

Fra 1. august 2012 vil jeg være advokat på heltid som partner i Bing Hodneland.



Nye bøker


Mer >>
Flere nye bøker

Gå til "bokhandelen"

Geocaching i Norge
Amazon US
In Association with Amazon.co.uk


Previous page:

Forarbeid hos kunden

Next page:
Previous page: Kap-3 Kort om anskaffelsesprosessen Next page: Valg av leverandør - kontraktsinngåelse

Kunden må først klarlegge sine egne behov. Hvis kunden ikke vet hva han egentlig ønsker, kan han heller ikke regne med at noen leverandør vil være i stand til å oppfylle disse ønskene. Kvalitet i denne delen av arbeidet er avgjørende for resultatet. ?rsaken til havarerte leveranser ligger ikke så sjelden i dårlig forarbeid hos kunden.

Følgende karakteristikk er gitt av en del edb-prosjekter. Om den stemmer, er det ikke til å undres over at man får problemer: (22)

* Målet er uklart og sannsynligvis feil definert.

* Prosjektplanen er utarbeidet uten diskusjon om prosjektstrategien.

* Prosjektet er bemannet med feil ressurser både når det gjelder kompetanse og mengde.

* Din strategiske samarbeidspartner for flere år fremover har en annen oppfatning av samarbeidsprosjektets mål enn du har.

* Det er ikke avtalt hvilke ressurser samarbeidspartneren skal avsette og hvordan de skal utnyttes i prosjektet.

* Samarbeidspartneren har ingen forpliktelser i samarbeidet.

Innføring av et (nytt) edb-system vil i mange tilfeller gi utgangspunkt for en gjennomgang av egen organisasjon som man tidligere ikke har foretatt. Selv om man anskaffer datasystem for andre eller tredje gang, vil det ha skjedd så mye siden forrige anskaffelse at man ikke uten videre kan basere seg på de analyser man gjorde den gangen. Man må se på hvilke oppgaver som utføres, hvem som utfører dem, hvordan de utføres, på informasjonsflyt, osv. I praksis kan analysen av organisasjonen og de oppgaver som utføres være mest arbeidskrevende i denne fasen, mens selve edb-systemet kommer mer i bakgrunnen.

Når man gjennomgår arbeidsoppgavene i en organisasjon, vil man alltid måtte være forberedt på at det skaper en viss uro. Det vil alltid være noen som føler sine posisjoner truet, som ikke liker at noen «kikker dem i kortene», som er redd for den nye teknologien, eller som bare er konservative av natur og ikke liker forandring.

Dersom man ikke har kompetanse i egen organisasjon til å foreta en slik analyse, bør man engasjere den nødvendige ekspertise. Selv om konsulenter koster, kan det komme til å koste mer om man gjør et dårlig forarbeid.

Man kan ikke basere seg på at leverandørene skal bidra med så mye i dette arbeidet. Konkurransen er hard og marginene knappe, så leverandørene vil ikke ha råd til å yte gratis konsulentbistand. En leverandør vil dessuten være mest opptatt av å selge sine produkter, uansett hva de måtte forsøke å få en kunde til å tro. En leverandør vil ikke anbefale konkurrentens produkter, selv om de skulle være bedre egnet ut fra kundens behov.

Hvis man engasjerer en konsulent, er det viktig at denne ikke har noen egeninteresse i at avtaler inngås med bestemte leverandører. Det er mange som kaller seg konsulenter, og konsulentene kan ha høyst ulik bakgrunn og kompetanse. Det er derfor viktig å klarlegge hva slags kompetanse de konsulenter man benytter har. Hvis konsulenten bare har kompetanse på en type systemløsning, kan man være ganske sikker på at denne vil bli anbefalt, selv om den ikke nødvendigvis vil være den beste for kunden. Om krav til konsulenten og spesifikasjon av konsulentens ytelse, se nærmere i .

De ansatte har krav på å bli tatt med i en slik prosess. Etter aml § 12 nr. 3 har de ansatte krav på å bli holdt orientert om systemer som nyttes ved planlegging og gjennomføring av arbeidet, herunder om planlagte endringer i slike systemer. De skal også være med på å utforme systemet. Edb-systemer vil ofte bli omfattet av dette. De ansatte har videre krav på den opplæring som er nødvendig for å sette seg inn i systemet. I en høyesterettsdom gjengitt i Rt 1988 s. 1188 Sara Hotel(23))ble det ikke ansett for grovt pliktbrudd, og dermed ikke avskjedsgrunn når baransatte nektet å delta i opplæring i bruk av et nytt datasystem, da det var uklart om informasjons- og drøftelsesplikt var overholdt.

Innenfor LO/NHO området er de ansattes medbestemmelse på dette punkt utdypet gjennom Hovedavtalen.(24) Tilleggsavtale II, avsnitt II har nærmere bestemmelser om informasjon, avsnitt III om medvirkning og avsnitt V om opplæring.

Et slikt forprosjekt hos kunden bør ende i et dokument som kan presenteres overfor aktuelle leverandører med forespørsel om tilbud. Hvor presis og detaljert en slik forespørsel vil være, avhenger av hva som skal leveres. Noen ganger vil man klart angi hva man vil ha, slik at leverandøren bare behøver å komme med et pristilbud for spesifisert utstyr og programmer. Andre ganger vil man bare kunne gi en viss beskrivelse av de problemer som skal løses, slik at leverandørene nærmest får som oppgave å foreslå en løsning. Eller leverandørene inviteres med for å utvikle en slik løsning. (25)

Man må også vurdere hvem man skal sende forespørsel om tilbud til, eventuelt om forespørselen skal kunngjøres. Man bør sende det til leverandører som man tror kan levere et tilfredsstillende system til en akseptabel pris, og som man kan tenke seg å inngå et nærmere samarbeid med. Leverandører som blir bedt om å komme med tilbud bør også få en liste over hvilke andre leverandører som har fått samme forespørsel, slik at de vet hvem de konkurrerer med.

Hvis det er en leverandør som man av en eller annen grunn vet at man ikke vil inngå avtale med, så bør de heller ikke oppfordres til å gi tilbud. Dette kan f.eks. gjelde leverandører som har satset på en teknologi som ikke passer inn i kundens IT-strategi, eller kunden kan mangle den nødvendige tillit til leverandøren. Det er dyrt å utarbeide et skikkelig tilbud på et litt større edb-system, og man skal som kunde ikke påføre leverandørene slike utgifter dersom man helt fra begynnelsen av vet at de ikke vil få leveransen. Ved offentlige anskaffelser vil man som hovedregel ikke ha adgang til å utelukke leverandører.

Ved offentlige anskaffelser gjelder særlige regler gitt i og i medhold av lov om offentlige anskaffelser m.v. av 27. november 1992 nr. 116. Loven gjelder i henhold til § 1 for anskaffelser til statlige, kommunale og fylkeskommunale organer. Videre for virksomheter innenfor vannforsyning, energi, transport og telekommunikasjon, når disse er kontrollert av det offentlige, og for visse nærmere angitte typer virksomhet når disse er gitt særlige eller eksklusive rettigheter av offentlig myndighet. Endelig gjelder den når det offentlige yter tilskudd lik halvdelen eller mer av anskaffelsens verdi. I medhold av denne er det fastsatt forskrifter om gjennomføring av E?S-avtalen av 12. desember 1992, nr. 908, 909 og 910, endret senest 16. desember 1994 ved forskrift nr. 1111. For statlige anskaffelser som faller utenfor E?S-reglene, gjelder Regelverk for statens anskaffelsesvirksomhet av 17. mars 1978, med senere endringer. Loven er erstattet av ny Lov om offentlige anskaffelser 1999-07-16-69 (26)

Dersom det er spesielle forhold hos kunden som vil få stor betydning for leveransen, må man opplyse om dette allerede i den første forespørselen. Det mest typiske vil være at man har eldre installasjoner som gir sterke føringer når det gjelder hva man vil komme til å velge. Det kan også være behov for at nye og gamle systemer skal kunne kommunisere, at man skal kunne benytte de data man har lagret i et gammelt system, osv.

Forespørselen bør inneholde tidsfrister, krav til hvordan et tilbud skal se ut for at de skal være sammenlignbare, kriterier for vurdering av tilbud, hvilke prosedyrer som vil bli fulgt, osv. Hvis man som kunde ønsker å inngå avtale i henhold til en bestemt standardkontrakt, eller det er spesielle kontraktsvilkår man vil basere seg på (f.eks. bedriftens innkjøpsbetingelser eller statens standardavtale), bør dette opplyses. Hvor omfattende og detaljert forespørselen bør være, vil måtte vurderes ut fra leveransens art, omfang og kompleksitet.

For ordens skyld bør man ta et uttrykkelig forbehold om at man kan forkaste ethvert tilbud og at man ikke har bundet seg i forhold til noen leverandør, før endelig avtale er undertegnet. Om man så kan holde fast ved alle de krav man har satt opp i forespørselen, vil dels avhenge av om kravene viser seg å være hensiktsmessige og realistiske, dels av partenes forhandlingsstyrke.

Som kunde ønsker man å få alle tilbud satt opp etter én mal, slik at de skal være lette å sammenlikne. Leverandørene på sin side vil ønske å utarbeide sitt tilbud etter sin egen mal, som de bruker ved alle tilbud de utarbeider. En stor leverandør vil neppe fravike sin mal når den skal utarbeide tilbud på en mindre leveranse til en gjennomsnittskunde.

Jeg har unngått ordet anbud. Anbud er en strengt formalisert prosedyre for innhenting og vurdering av tilbud. Ved anbud er konkurranse mellom og likebehandling av leverandører sentralt. Det er ingen generelle lovregler om anbud. Så lenge det ikke gjelder anskaffelser til det offentlige eller til sektorer som av andre grunner er særskilt regulert i henhold til WTO og E?S-avtalen.(27)

Ved IT-anskaffelser som ikke bare omfatter levering av standardprodukter, vil man ofte ikke ha et godt nok spesifisert anbudsgrunnlag til å anvende anbud i den betydning dette har f.eks. i entrepriseretten. Anbud forutsetter i praksis at kunden har valgt løsning, og skal ha pristilbud fra flere leverandører. Ved IT-leveranser vil leverandøren i alle fall et stykke på vei måtte foreslå løsning basert på sin egen teknologi, slik at ulike leverandører ikke vil tilby det samme. Dermed vil men heller ikke ha direkte sammenlignbare tilbud, det er en rekke andre spørsmål enn pris som må vurderes, osv. Det er derfor vanskelig å unngå noen runder med avklaringer og forhandlinger med en eller flere leverandører med utgangspunkt i tilbudene. Anbudsformens forbud mot forhandlinger kan gjøre det vanskelig å komme fram til den for kunden beste løsningen uten at man bryter grunnleggende prinsipper for anbud. ? bruke anbudsformen på programvareutvikling er omtrent som å skulle legge ut et arkitektoppdrag på anbud og la laveste pris være avgjørende for hvilken arkitekt som skal få tegne huset. En konkurranse hvor man ber om tilbud, men også forbeholder seg rett til å føre forhandlinger med utgangspunkt i mottatte tilbud, betegnes gjerne som tilbudskonkurranse. I de fleste tilfeller er denne anskaffelsesformen best egnet for IT-systemer.

For offentlige anskaffelser må det her gjøres visse modifikasjoner. Ved slike anskaffelser er man i stor grad pålagt å anvende anbud ?? hvilket i praksis vil si at man er pålagt å bruke en anskaffelsesprosess som ofte er uegnet til formålet.(29)

For entrepriseavtaler er det i NS 3400 fastsatt regler om anbudskonkurranser for bygg og anlegg. Det er vanlig å anvende disse reglene i denne bransjen. Også for petroleumskontrakter finnes det særlige anbudsregler, og i en del tilfeller plikt til å benytte anbudsformen. Men her er det visstnok også akseptert at man fører forhandlinger ut fra innleverte anbud. For IT-leveranser finnes det ikke noen slike standardregler.(30)

For utviklingsprosjekter vil det ofte ikke være grunn til å inkludere alt utstyret og alle standardprogrammene som skal til for det samlede anlegg i utviklingskontrakten. Det bør være tilstrekkelig å ta med det som er nødvendig for utvikling og løpende testing. Så lenge det gjelder standard utstyr, f.eks. industri-standard PC'er, er det ingen grunn til å inngå noen avtale lenge før hovedsystemet er ferdig utviklet. Man trenger ikke være spåmann for å si at ytelsen vil bli forbedret og prisen vil synke mens systemet utvikles. Man bør derfor innhente nye tilbud på utstyr og standard programvare når systemet nærmer seg ferdigstillelse. Skal derimot utstyr utvikles særskilt for denne leveransen, må også det med i hovedprosjektet.

I noen av de skandalepregede IT-prosjekter man har sett innen det offentlige, ha man som første del av leveransen fått et stort antall PC'er som har ligget ubrukt i påvente av at hovedsystemet skulle utvikles ferdig. Resultatet er at man har betalt en alt for høy pris for utstyr som langt på vei er foreldet før det kan tas i bruk. At selve utviklingen kan vise seg vanskeligere og langt mer tidkrevende enn opprinnelig tenkt, er hva man må regne med. Men det er ingen unnskyldninger for å kjøpe et stort antall PC'er til lager mens utviklingen pågår. Med så mange dyre konsulenter som har vært involvert i noen av disse prosjektene, burde man i alle fall ha unngått så elementære feil i prosjektet.


Kontraktsledelse


More >>
Forfatter: Jan Ole Simila
Et skritt på veien mot bedre konkurranseevne. Forfatteren fokuserer i denne boken på ledelse av kontraktsprosessen.

Forfatteren fokuserer i denne boken på ledelse av kontraktsprosessen. Han peker på at det er stor variasjon i organisasjoners modenhet med hensyn til håndtering av kontraktsprosesser, og et mål med boken er å strukturere et slikt arbeid. Bokens første del omhandler kontraktsledelse, kontraktsøkonomisk teori, tillit i kontraktsforhold og kontraktsetikk. I andre del behandles kontraktsakkvisisjon, kommunikasjons-, forhandlings- og beslutningsprosessene, avtalen partene imellom, kontraktsoppfyllelse samt kontraktsevaluering. I bokens siste del beskrives kontraktsmodellen. Har litteraturliste og stikkordsregister.

Bestill fra:
Bokkilden
Level: , 236 pages RefNr: 9788245004458
Medium: Book (paperback)
Series:

Noen bøker om IT-kontrakter


More >>
The Outsourcing Revolution: Why it Makes Sense to do it Right: Why It
The Outsourcing Revolution" features case studies detailing how specific companies planned, implemented, and are managing BPO. Results from surveys of more than 1,500 companies provide real data on what organizations around the world are doing and why, as well as what does and doesn't work.
RefNr: 0793192145
Bestill fra:
Amazon UK
Amazon US
Bokkilden

More >>
The Managers Guide to Understanding Commonly Used Contract Terms: Comm
RefNr: 0852977581
Bestill fra:
Amazon UK
Amazon US
Bokkilden

More >>
Kontrakter for utvikling av programvare
Boka tar for seg utviklingskontrakter for dataprogramvare.
RefNr: 9788202196912
Bestill fra:
Bokkilden

More >>
Outsourcing: The Legal Contract
Providing an introduction to outsourcing, this title identifies and discusses the main aspects which should be specified in the contract and indicates the factors which facilitate a successful outsourcing relationship.
RefNr: 1841523607
Bestill fra:
Amazon UK
Amazon US
Bokkilden

Gå hit for full oversikt over bøker om IT-kontrakter.


Previous page: Previous page: Kap-3 Kort om anskaffelsesprosessenNext page: Valg av leverandør - kontraktsinngåelse Next page:

Previous page: Previous page: Kap-3 Kort om anskaffelsesprosessen