Udbudsmateriale, forløb og aftalegrundlag DAu-konference, 14. september 2011

Transkript

1 Udbudsmateriale, forløb og aftalegrundlag DAu-konference, 14. september 2011

2 Udbudsmateriale, forløb og aftalegrundlag Udvalgte emner: Indledning: Hvorfor går softwaredelen ofte galt? Udbudsretlige forhold Valg og tilretning af kontraktgrundlag før der udbydes Ydelsesbeskrivelsen/projektmetoden, særligt agile udviklingsforløb Hvis vi har nok tid: Flerleverandørforhold Tvistløsning 2

3 Hvorfor går softwaredelen ofte galt? Hvad er der galt her?: if {VALUE=charset099y6z} < 20 then [x]; if {VALUE=charset099y6z} > 20 then [y] I f.eks. rejsekort-projektet repræsenterer softwaren under en femtedel af projektets kontraktværdi men er årsagen til de opståede forsinkelser. I Københavns Kommunes outsourcing af lønanvisning til Accenture var kerneydelsen ikke det underliggende it-system, men medarbejdere/processer/data. Alligevel var det den underliggende applikationsudvikling, der fejlede. Softwareudvikling er genstand for hurtig teknologisk fornyelse og Livet må leves forlæns, men forstås kun baglæns (S.A. Kierkegaard). 3

4 Udbudsretlige forhold Hvis offentligt (eller offentligt fund et) projekt eller projekt indenfor forsyningsvirksomhed (vand, energi, transport og tele), så finder EU s udbudsdirektiver anvendelse. Hvis ikke-offentligt projekt, så gælder der meget friere forhold, dog Almindelig loyalitetsforpligtelse overfor tilbudsgivere, og Rettighedsforhold vedrørende idéer, knowhow, tilbudsmateriale m.v. 4

5 Valg og tilretning af kontraktgrundlag før der udbydes Lad aldrig leverandørsiden foreslå kontraktgrundlag. Vælg en udbredt standardkontrakt: F.eks. K01, K02, OGC eller FIDIC. Anvend den aldrig uden tilretninger til det konkrete projekt, særligt ydelsesbeskrivelsen/projektmodellen (se næste slide) Sammenhængen til bilagsmaterialet skal sikres på udbudstidspunktet og undervejs. 5

6 Ydelsesbeskrivelsen/projektmetoden, særligt agile udviklingsforløb Vandfald Vandfaldsmodellen: Fast kravspecifikation, der har forrang indtil projektafslutning. Funktionsbes krivelse/over ensstemmels esmatrix Funktionsbeskrivelse/overensstemmelsesmatrix: Funktionelle behov er beskrevet og aftalt. Leverandøren har ansvar for at påpege ændringer m.v. i al efterfølgende projektdokumentation. Business Blueprint Procesfora ndring Business Blueprint: Nyere (mere specifik) projektdokumentation afløser funktionsbeskrivelser m.v. Procesforandring: Man tilpasser virksomhedens forretningsprocesser til standardapplikationen (eller eksisterende templates/parameteropsætning) i stedet for det modsatte Agil udvikling Agil udvikling: Se efterfølgende slides. T/M T/M. Regningsarbejde efter løbende identificerede behov. 6

7 Agile udviklingsforløb: Hvad er den bagvedliggende filosofi Hvor ofte anvendes funktioner i et it-systems? (Kilde: Standish Group, Third Int l Conference on Extreme Programming) Altid: 7% Ofte: 13% Sommetider: 16% Sjældent: 19% Aldrig: 45% Det der skal optimeres, er det arbejde, som ikke behøver at blive udført (The Elimination of Waste Principle). Paradigmaskift fra risiciallokerende til relationelle kontrakter 7

8 Agile udviklingsforløb: Hvad skal ændres i kontrakterne med hensyn til scope, tid og pris? Det korte svar: Alt! Fokus på proces, planlægning og fremdrift, usikkerheder, ressourcer og kompetencer, fremfor systemkontrakternes traditionelle fokus på resultatforpligtelsen. Opsigelsesadgang for kunden skal være indeholdt i kontrakten ved bestemte milepæle. Prisvilkår bør være sofistikerede og indeholde incitamenter og shared risk vilkår. Se eksempler fra PS2000, og 8

9 Agile udviklingsforløb: Hvilke projekter er egnede? Projekter hvor pris er underordnet i forhold til time-tomarket. Projekter, hvor softwarefejl er bandlyst (militær og medicinsk brug m.v.). Aftaleforhold, hvor både kunde og leverandør har høj modenhed. Aftaleforhold med afgrænsede, korte forløb og en efterfølgende reel konkurrencesituation mellem flere leverandører. 9

10 10

11 Flerleverandørforhold Hoved- og underleverandørkonstruktion Konsortiedannelse Flere leverandører med indbyrdes grænsesnit og afhængigheder 11

12 Hvis flere samvirkende leverandører: Samarbejdserklæring/Cooperation Agreement er en nødvendighed. Grænsesnit skal identificeres. Leverandørerne skal etablere et fælles organ til håndtering af f.eks. (i) indhentelse af forsinkelse, (ii) placering af ansvar for fejl. Bevisbyrden vendes, d.v.s. indtil leverandørsiden kan godtgøre, at fejlen skyldtes en bestemt dellevarance, er alle solidarisk ansvarlige (eventuelt kun ansvar for en valgt systemintegrator). 12

13 Tvistløsning Eskalation Disputes Resolution Board (afklaring af forhold, som er hindrende for fremdrift) Mediation Voldgift- eller domstolsbehandling 13

14 Debat, spørgsmål og tak for i dag! Lau Normann Jørgensen LNJ@kromannreumert.com Tlf.: