Kundens medvirkningsplikt

Download Report

Transcript Kundens medvirkningsplikt

Contracts, responsibility,
liability, risks in Systems
development
Advokat Arve Føyen
FØYEN advokatfirma DA
Tema
•
•
•
•
Prising av ikt-leveranser
Fokus på risikohåndtering
Kontraktsregulering av betydning for prising
Noen praktiske utfordringer knyttet til
–
–
–
–
Organisering
Samhandling
Underleverandører
Endringskontroll
2
Aktører
Planlegging
Kravspesifikasjon
Kunde
Konsulent
Milepæler
Faser
Faser i anskaffelsesprosessen
Forespør.
om
tilbud
Forberedelse
av
tilbud
Vurdering
Forhandlinger
Valg lev.
Bestillingstid
Klargjøring
Installasjon
Drift
Godkjenningsperiode
Garantiperio
Leverandører
Kunde
Leverandør
Kunde
Leverandør
Kunde
Leverandør
Kunde/Lev.
Kunde
Kunde
Tilbud
Avtale
Levering
Godkjenning
Ordinær drift
3
Milepæler
Faser
Faser i anskaffelsesprosessen
Planlegging
Kravspesifikasjon
Forespør.
om
tilbud
Forberedelse
av
tilbud
Tilbud
Vurdering
Forhandlinger
Valg lev.
Avtale
Bestillingstid
Klargjøring
Installasjon
Levering
Drift
Godkjenningsperiode
Godkjenning
Garantiperio
Ordinær drift
Kontraktsoppfølging
4
Hva er en kontrakt?
•
•
•
•
•
Hvem gjør hva
Til hvilken tid
På hvilken måte
Til hvilken pris
Og hvilke øvrige vilkår
5
To regelsett gjelder sammen
• Avtalen
• Bakgrunnsretten
– Alminnelig kontraktsrett bl. a. uttrykt
i avtaleloven og i kjøpsloven
– Spesialregler (NS 3430 osv.)
– Bakgrunnsretten for øvrig
(rettspraksis, juridisk metode)
6
Konsekvenser av dette
• Kontrakten som rettesnor
– I gode og onde dager
• Ta hensyn til bakgrunnsretten
– Gir den ønskede løsninger?
• Skolemesterklausuler pedagogikk
7
Kundens rolle
Kunden er svært ofte ”underleverandør”
• Bidrar med personer i prosjektgrupper
• Har laget spesifikasjoner
• Oppgi parametere, tilrettelegging for
leveranse etc.
• Stiller infrastruktur, lokaler og andre
ressurser til rådighet
8
Kundens medvirkningsplikt
• Manglende oppfyllelse kan medføre ansvar for:
– Leverandørs rentetap som følge av forsinket
fakturering
– Omkostninger til retting og omlevering
– Konsekvenstap for selger
• Leverandøren kan få rett til:
– Utsettelse
– Tilleggsbetaling
– Heving og erstatning
9
Manglende oppfølging av mislighold
• Kan medføre rettstap
• Kan endre innholdet i avtalen
• Kan påvirke tolkningen av
avtalen
10
Betydning for kontraktsutforming
• Avtalen må angi tydelig:
–
–
–
–
Kommunikasjonslinjer
Skriftlighet for alle endringer
Frister, prosedyrer
Hva som skal gjøres for å følge
opp kontrakten
11
Praktisk kontraktsoppfølging
• Avtalen er et sentralt
styringsdokument
• Analysér avtalen
–
–
–
–
Hva skal følges opp
Hvem skal gjøre det
Når?
Utarbeid rutiner
12
Sørg for at de som skal følge opp:
• Forstår hele leveransen
• Forstår kontrakten
• Vet hva de skal gjøre dersom ikke
alt går som det skal
13
Overordnet hjelpedokument for
kontraktsstyring
• Oversikt over milepæler, varslingsfrister og datoer
av betydning
• Oversikt over hendelser som gir handlingsplikt
– Betalingsfrister
– Frister for feilmelding
– Behandling av endringsmeldinger etc.
• Beskrivelse av andre forhold under kontrakten vedr
rettigheter og forpliktelser
– Rapporter, dokumentasjon, endringer, oppsigelse etc.
14
Oversikt over hjelpedokumenter
i ordinær driftsfase
Hjelpedokument for kontraktsstyring
Standardbrev for
endringsordre
Feilmelding under drift
Standard reklamasjon
15
Oversikt over hjelpedokumenter ved
utvidelser av leveransen
Sjekkliste for
installasjon
Standardbrev for feil
Og avviksmelding
før levering
Godkjennelsesprotokoll
Standard
godkjennelsesbrev
Avvisning av
leveransen
16
Passe særlig på ved kritiske punkter
• Når noe går galt
• Ved levering/
overtakelse/akseptanse etc.
• Ved frigivelse av
forskudd/betaling av avdrag
frigivelse av garantier
• Milepéler
17
Taktiske grep når ting skjærer seg
• Prosessen frem til konflikt
– Posisjonering meget viktig
• ”Red Flags”
– Krangel om kontraktsforståelse
– ”Forslag” om forskuddsbetaling,
– Endring med uoverskuelige
konsekvenser eller lignende
– ”Bekreftelser” fra motparten på
overenskomster du ikke kan huske
18
Hovedhensyn for kunden:
• Sørge for kontraktsmessig levering
• Posisjonere seg best mulig for utøvelse
av misligholdsbeføyelser
– Sørge for at uklarheter avklares
– Konsekvenser må gjøres kjent for
motparten
– Begrense skadevirkninger
19
Praktiske tiltak
• Sikre bevis
– Fysiske bevis
– Elektroniske bevis
• Skriftlige avtaler!
• Gi skriftlig uttrykk for bekymring
– Pek på konsekvenser og ta
forbehold
– Be leverandøren ta ansvar, samt
rapportere hyppig
20
Vurdere sannsynlig utfall
• Varsle egen organisasjon og evt
medkontrahenter som berøres
• Anføre force majeure i forhold til
medkontrahenter
• Passe på utbetalinger/frigivelser
21
Risiko og prising - Konseptuelt
Sammenhenger mellom
• Kostnadsestimering
• Contingency (sikkerhetsmargin for uforutsette forhold)
• Prising
Prinsipielt
 Estimering/costing og prising er i utgangspunktet to atskilte
prosesser.
 En leverandør må i alle tilfelle ha nødvendig trygghet for sine
basis estimater og de ulike kostnadselementene forbundet
med den jobben som skal gjøres.
 Hvordan et konkret prosjekt skal prises er imidlertid annen
vurdering – time & material, fatspris, verdibasert, strategisk,
transaksjonsbasert etc.
 Det viktige budskapet her er at kostnadsestimatet ikke under
noen omstendighet bør endres, dersom det foreligger en
prismessig utfordring
 Skal kostnadsestimatet endres må man også endre på
 Forutsetninger og/eller
 Scope for den jobben som skal gjøres
23
Sammenhenger mellom
kostnadsestimering, contingency og prising
Costing
Technology Blueprint
Business Process Layer
Interfaces
Business Process Layer
{documentation =
RoutingController
CollectionController
ReportController
SettlementController
Adapters
{documentation =
«interface»
TransactionFileInterface
DeliveryController
ValidationController
FeesProcessor
«interface»
FERISInterface
«interface»
EditRulesInterface
«interface»
CMLSInterface
«interface»
VFTSInterface
BillingController
TranslationController
EditsController
Matcher
Storehouser
ProfileSynchroniser
«interface»
FeeInterface
CurrencyConverter
}
«interface»
IBInterface
Cost
«interface»
RefDataInterface
«interface»
CONFIGInterface
}
Business Entity Layer
0..*
Business Entity Layer
{documentation =
1..*
FeeRules
Fee
MemberProfile
1
0..*
0..*
0..*
0..*
Batch
0..*
* *
Reports
BillingRules
1..*
Reports
SettlementReport
{documentation =
ClearingReport
QualifierReport
BINStream
*
0..*1
0..*
1
0..1
1
1..*
SchemeProfile
TransactionException
*
File
1..*
Transaction
ClearingWindow
0..1
*
0..*
0..*
*
0..*
FeeReport
Currency
1
BatchAcknowledgement
0..*
TCEditRules
Return
Report
VMLEditRules
ReclassificationAdvice
Bill
1
*
*** **
Advice
FormatDefinitionMapping
DebitRevBridgeMessage
3rd Parties
1
}
*
1
*
1..*
Screens
1
1..*
CustomEditRules
TC-VMLMapping
ASCII-EBCDICMapping
TXT-PDF-XLSMapping
«interface»
User Screens
ReportTemplate
}
Screens
«interface»
{documentation =
MemberProfileScreens
«interface»
SettlementSchemes
«interface»
FeeScreens
«interface»
EditRulesScreens
Frameworks Layer
Frameworks Layer
{documentation =
SecurityService
ReportFramework
LoggingService
«interface»
CurrencyRateScreens
BatchOnLineSynchroniserService
Solution
Contingency
«interface»
CollectionWindowScreens
WorkflowFramework
BatchFramework
ReferenceDataCacheService
OnlineFramework
ErrorManagerService
«interface»
EnterpriseManagementAdapter
ArchivingController
SystemProfileService
BackupController
PersistenceService
TimestampService
«interface»
FileDetailScreens
«interface»
ExceptionScreens
«interface»
MonitoringScreens
«interface»
RefDataScreens
«interface»
BillingScreens
ReconciliationService
«interface»
TapeAdapter
«interface»
MQAdapter
«interface»
FTPAdapter
«interface»
HouseKeepingScreens
«interface»
HelpScreens
«interface»
SystemTableScreens
}
}
Business Process Blueprint
Other Costs
Additional considerations
(client, team, schedule…)
Training & Performance
Support Blueprint
200x
Oct
Nov
Direct
Non-Payroll
Estimating Model
200y
Dec
Jan
Feb
Mar
Apr
May
Jun
Jul
Aug
Sep
Oct
Nov
Dec
Product Readiness
Technical Design
Implementation
Date
Build / Unit Test
System Test
(Value Date 17/11)
BAT
Organisation Readiness
Conceptual Readiness Phase
Preparation Task Execution
Line Training
Op. Test
Customer Readiness
Account
Opening
Initial Customer Visits
Release Brochures
Info Roadshows
Training
Payroll
Simulation
Application Blueprint
Business Process Layer
Interfaces
Business Process Layer
{documentation =
RoutingController
CollectionController
ReportController
SettlementController
DeliveryController
Adapters
{documentation =
«interface»
TransactionFileInterface
ValidationController
FeesProcessor
«interface»
FERISInterface
«interface»
EditRulesInterface
«interface»
CMLSInterface
«interface»
VFTSInterface
«interface»
FeeInterface
«interface»
IBInterface
Sourcing
BillingController
TranslationController
EditsController
Matcher
Storehouser
ProfileSynchroniser
CurrencyConverter
}
«interface»
RefDataInterface
«interface»
CONFIGInterface
}
Business Entity Layer
0..*
Business Entity Layer
{documentation =
1..*
FeeRules
Fee
1
MemberProfile
0..*
0..*
* *
1..*
Reports
BillingRules
0..*
0..*
0..*
Batch
Reports
SettlementReport
{documentation =
ClearingReport
QualifierReport
BINStream
*
0..*1
0..*
1
0..1
1
1..*
*
File
1..*
Transaction
SchemeProfile
TransactionException
0..1
*
ClearingWindow
0..*
0..*
*
0..*
1
Currency
BatchAcknowledgement
0..*
TCEditRules
Return
Report
VMLEditRules
ReclassificationAdvice
Bill
1
*
*** **
Advice
FeeReport
FormatDefinitionMapping
DebitRevBridgeMessage
1
}
*
1
*
1..*
CustomEditRules
Screens
1
1..*
TC-VMLMapping
ASCII-EBCDICMapping
TXT-PDF-XLSMapping
«interface»
User Screens
ReportTemplate
}
Screens
«interface»
{documentation =
MemberProfileScreens
«interface»
SettlementSchemes
«interface»
FeeScreens
«interface»
EditRulesScreens
Frameworks Layer
Frameworks Layer
{documentation =
SecurityService
ReportFramework
LoggingService
BatchOnLineSynchroniserService
«interface»
CurrencyRateScreens
«interface»
CollectionWindowScreens
WorkflowFramework
BatchFramework
OnlineFramework
ReferenceDataCacheService
ErrorManagerService
«interface»
EnterpriseManagementAdapter
ArchivingController
}
SystemProfileService
BackupController
PersistenceService
TimestampService
«interface»
TapeAdapter
«interface»
FileDetailScreens
«interface»
ExceptionScreens
«interface»
MonitoringScreens
«interface»
RefDataScreens
«interface»
BillingScreens
ReconciliationService
«interface»
MQAdapter
«interface»
FTPAdapter
«interface»
HouseKeepingScreens
«interface»
HelpScreens
«interface»
SystemTableScreens
}
24
Costing, contingency and pricing
Solution Contingency is a budget allocation added to a solution estimate to cover risks that may or may not
arise during delivery of the solution. Risks that need to be covered by solution contingency fall into two broad
categories:
• Delivery Risks - Represents
contingency to cover expected
outcomes of events that impact the
ability to deliver the effort on time and
budget. This covers events such as:
• Dependent effort(s) not
delivered on time
• Sign-offs not achieved on time
• Resources not available when
required or with the right skills
• Rework due to quality issues
Price range
Cost
Negotiating
Contingency
Additional
Value
Minimum
Margin
Solution
Contingency
Other Costs
Cost
Direct
Non-Payroll
• Estimate Variability - Represents
contingency to cover the variability of
estimates for known tasks, e.g.:
• Uncertainty linked to new
technology/application
• Estimating assumptions
incorrect
• Limited detail or specificity of
business or technical
requirements
• Skills and experience of staff
lower than previous experience
Payroll
25
Betraktninger knyttet til risiko
 En leverandør må gjøre risikovurderinger langs
mange dimensjoner i forbindelse med estimering av
utviklingsprosjekter og prissetting
 Typisk må følgende aspekter vurderes:
 Selve estimatet (arbeidsomfang fordelt på ulike kategorier
og de ulike kostnadselementene)
 Avtalen og dens betingelser
 Varighet av avtalen og mulighet for tilpasninger av avtalen
over tid
 Kunderelasjonen – styrke og varighet/erfaring
 Underleverandører
 Endringskontroll
26
Selve estimatet og de ulike
kostnadselementene
• Hvor sikker er leverandøren i det konkrete tilfellet på
kostnadsestimatet og på sin egen evne til å levere i henhold til
estimatet?
• Har leverandøren den nødvendige forståelsen av løsningen
som skal leveres, forvaltes og/eller driftes?
• Omfangsdefinisjon og avgrensning, kompleksitetsforståelse og
forutsetninger er viktige elementer i denne sammenheng
• Et annet sentralt forhold er i hvilken fase estimatet blir
utarbeidet.
– Vanskelig å estimere med høy presisjon i en tidlig fase. Her
brukes ofte en top-down estimeringstilnærming, der
estimeringsusikkerheten er stor. I praksis ikke mulig å gi en
fast pris på dette stadiet.
– I senere faser – typiske etter analyse og/eller design, er det
mulig å benytte en bottom-up tilnærming, der
estimeringsusikkerheten er lavere, og der det kan være
grunnlag for å gi en fastpris
27
Avtalen og dens betingelser
• Her er spennet stort – alt fra det enkle og oversiktelige
for et isolert utviklingsoppdrag til store og komplekse
kontrakter
• Både kostnads- og prisvurderinger må vurderes konkret i
lys av betingelsene i kontrakten,
• Sentralt at Leverandøren forstår innholdet i og
konsekvensene av de ulike betingelsene i Kontrakten
• Typisk må Leverandøren klare å skille ut de betingelsene
som er kostnadsdrivere, og som det eksplisitt må tas
høyde for i Leverandørens estimering.
• Krav til kvalitet ved go-live er et typisk eksempel på dette
– strenge krav til utestående feil ved sluttstilt test påvirker
test-estimatet direkte
28
Avtalen og dens betingelser (forts)
• Et annet eksempel er SLA-krav eller
godkjenningskriteria
– Leverandøren må være sikker på at enkelthetene i
SLA-regimet/godkjenningskriteria er analysert og
vurdert, slik at det kan tas høyde for dette i
estimatene.
• Typisk vil man i sammenheng med SLAkrav/godkjenningskriteria skille mellom
– Den innsatsen som i et normaltilfelle må legges inn
for å kunne opprettholde SLA eller oppfylle
godkjenningskriteria
– Estimat som må legges til for å dekke eventuell
straff dersom SLA-krav eller godkjenningskriteria
ikke nås (må sees i lys av antall SLA’er, SLA-nivå og
nivå på strafferegime)
29
Avtalen og dens betingelser (forts)
• Et annet viktig forhold er hvordan tolkningsrommet i
kontrakten vurderes.
– I en omfattende og kompliserte kontrakter vil gjerne
tolkningsrommet være forholdsvis stort på flere
områder
• Systemet med Kundens funksjonelle kravspesifikasjon
som styrende og leverandørens løsningsspesifikasjon
med trinnhøyde tolkningsmessig etter kundens
spesifikasjon, som i SSA-U, skaper noen utfordringer
– Dette må Leverandøren ta med i vurderingene når
arbeidet skal estimeres og prises – hva er risikoen for
disputter på kontraktssiden, og hvor smidig er
konflikthåndteringsregimet?
30
Noen sentrale avtalebetingelser (SSA-U)
•
•
•
•
•
•
•
•
•
•
•
•
Leveranseomfang – Pkt 1 og 2 og Bilag 1-7
Tolkning – Rangordning Pkt 1.3
Pkt 8, jfr bilag 7 Pris, Samlet vederlag og betalingsmåte
Akseptansetest, Idriftsetting og levering pkt 2.4 og kriteria for
godkjennelse pkt 2.4.5
Godkjenningsperiode og Leveringsdag pkt 2.5
Avbestilling – midlertidig stansing Pkt 2.6
Endringsregime Pkt 3
Garantiperiode pkt 4
Kundens ansvar og medvirkning – pkt 6 jfr Bilag 6 –
Sanksjonsmuligheter ved ikke-oppfyllelse?
Leverandørens Mislighold Pkt 11.
Kundens Mislighold – Pkt 12
Rettsmangler – Pkt.13
31
Akseptanse og godkjenning
Forberedelser til produksjonssetting
(xx virkedager)
Design,
utvikling,
systemtest
Spec.
fase
1
4
5
Godkjenningsperiode
(3 mnd)
6
2
3
Akseptansetestperiode
7
8
9
1. Sign off spesifikasjonsfase
2. Akseptansetest plan oversendt fra kunde (xx virkedager før oppstart av
akseptansetest)
3. Tilbakemelding akseptansetest plan (xx virkedager)
4. Gjennomføring av planlagt akseptansetest iht. omforent plan
5. Retting av innmeldte feil etter endt akseptansetest (xx virkedager)
6. Retest av rettelser før Akseptansedag (xx virkedager)
7. Akseptansedag
8. Oppstartsdag
9. Leveringsdag
32
Varighet av kontrakten og mulighet for
tilpasninger av kontrakten over tid
•
•
•
Hvor låst er kontrakten og hvilke tilpasninger kan gjøres underveis?
Er det rom for re-forhandlinger underveis og hvilken
forhandlingsposisjon vil det da være mulig å ta som leverandør?
Hvilke prisreguleringsmekanismer finnes i kontrakten?
– Det utgjør en stor forskjell for leverandøren om han kun justerer ut fra
KPI eller om man benytter for eksempel Tekna indeks eller IKT Norge
indeks
– Ved offshoring etc – er det tatt høyde for COLA-justeringer lokalt
•
I en kompleks langtidskontrakt som favner bredt med få muligheter for
tilpasninger underveis, er det viktig for leverandøren å vurderer den
helhetlige kontraktsrisikoen.
– Det er ofte vanskelig å gjøre dette vitenskapelig – erfaringer,
rimelighetsvurderinger og vurdering av kundeforholdet er viktige
parametre
•
I estimeringssammenheng må Leverandøren i tillegg sørge for å ha
tatt nødvendig høyde for management kapasitet i ulike dimensjoner,
– Contract management
– Juridisk bistand over kontraktens løpetid.
33
Kundeforhold
• Når Leverandøren vurderer risiko, er vurdering av
styrken og varigheten av kundeforholdet svært viktig
– Er kundeforholdet i stor grad et partnerskap der
relasjonene er tette og gode
– Er det et kunde/leverandør-forhold der det er en
profesjonell distanse og der kunden i stor grad agerer
kontraktuelt?
• Heller ikke her finnes noen fasitsvar på hvordan
man kvantifiserer risiko,
• Helhetsvurderingen er svært ulik i de to
ytterpunktene.
34
Underleverandører
• Risikovurderingen i denne sammenheng kan deles i to:
– Avtaleforhold, avtalens betingelser, fleksibilitet i kontrakten
og leverandørrelasjon på samme måte som mot kunde på
den ene siden og
– Vurdering av underleverandørens evne til å levere som
avtalt på den andre siden
• Bruk av back-to-back mekanismen kan i stor grad fungere som
en sikkerhet
– I noen tilfelle kan det imidlertid være aktuelt for
underleverandøren å legge inn begrensninger på øvre
ansvar eller mulige straffereaksjoner som gjør at back-toback ikke gjelder fullt ut – eksempelvis SLA-ansvar ifm.
tilgjengelighet på en tjeneste som Hovedleverandøren har
totalansvar for
– Problemet med standard programvare fra 3. part som del
av leveransen og totalansvar for hovedleverandøren
35
Underleverandører (forts)
• Det er også noen ganger slik at hovedleverandøren må ta over
oppgaver helt eller delvis fra underleverandør der
underleverandøren ikke evner å utføre oppgavene
– Dette resulterer ofte både i mer operativt arbeid og
prosessarbeid i tilknytning til avtaletolkning (hvem har
ansvaret osv.).
– Erfaring viser at det skal mye til før man klarer å løfte
denne typen kostnader over på underleverandøren pga.
krav til ’bevis’ og dokumentasjon
• I mange tilfelle er det ikke god kost/nytte for Leverandøren å
kreve dette
– Med mindre man har en krystallklar sak, så ender denne
typen disputter i beste fall med et kompromiss, og
kostnadene ved å drive frem kompromisset er høye
• Derfor blir tydelig avgrensning av ansvar, governance struktur
og underleverandørens evne til å leve opp til sine forpliktelser
viktige parametere i en risiko- og kostnadsvurdering
36
Samhandling og koordinering
• Ved flere sidestilte leverandører i større prosjekt
– Egen samhandlingsavtale med betydelig krav til
koordinering ansvarsavklaring og konfliktløsing på
leverandørnivå
– Kunden velger ofte å stille seg utenfor og etablerer en egen
samhandlingsavtale der leverandørene selv må sørge for
avklaringer uten å involvere kunden
– Kostnadene for samhandling må kalkuleres inn
• I hovedkontrakt
• Alternativt i samhandlingsavtalen
– Svært vanskelige vurderinger og rom for ”fingerpeking”
– Viktig med fall-back og konfliktløsing/eskalering
– Kontroll med valg av samhandlingspart
37
Risiko ved endringer
Påvirkningsmulighet vs endringskostnad
Forpliktede kostnader
Initieringsfase
Planleggingsfasen
Gjennomføringsfasen
Påvirkningsmulighet
39
Størst påvirkningsmulighet i tidlig fase
Bemanning
Gjennomføring
Initiering
Planlegging
Tid
Prosjekt
Start
Prosjekt
Slutt
40
Endringskontroll
• For å sikre mot risiko initielt og underveis, er endringskontroll
svært viktig
– For det første må det foreligge dokumentert et avgrenset
scope og en enighet med kunde om at endringer skal
håndteres som nettopp det – som endringer
– Underveis må Partene sørge for å ha et strengt regime på
hvordan endringer – og ikke minst gråsone tilfeller –
håndteres
– Vesentlig mye viktigere innenfor en fastpriskontrakt enn i en
time&material basert kontrakt
– Men også innenfor T&M er endringskontroll viktig for å
kunne sikre
• leveransekvalitet
• overholdelse av avtalt leveringstid,
• og for å etablere et bevisst forhold til kostnadspådrag hos
begge parter
41
Spørsmål?
[email protected]
www.foyen.no