Publicerad
Författare
Till vardags är det vanligt att företag informerar om att de bestämt sig för att upphandla och köpa ett nytt system (ex Affärssystem eller HR-system). Mer sällan hör man talas om företag som bestämt sig för att köpa en leverans. Trots detta är det egentligen det som är syftet med köpet. Enbart micro-företag kan köpa ett system, ladda ned det och sedan omgående börja använda det (plug & play). Istället är det regel att det krävs ett relativt omfattande projekt för att konfigurera och färdigställa ett nytt system inför driftsättning. Detta innebär att kunden köper en leverans (ett sk nyckelfärdigt och konfigurerat system) som omfattar både ett system och ett konsultarbete för att sätta upp systemet. Varför är det då viktigt att förstå och skilja på begreppen system och leverans?
I och med övergången till molnbaserade system blir det allt vanligare att återförsäljaren vid avtalsdialogen hänvisar till att systemet är ett standardsystem, där licens och nyttjanderätt ska avtalas med tillverkaren av systemet (Ex Microsoft eller SAP) medan konsultprojektet för att konfigurera och färdigställa systemet för drift ska avtalas med återförsäljaren/partnern. Detta scenario leder till två skilda avtal. Och som följd av detta är det vanligt att återförsäljaren avsäger sig allt ansvar för systemets kvalitet och framtida utveckling, för att istället hänvisa till det enskilda avtalet som kunden tecknat med tillverkaren av systemet.
Att kunden hamnar i situationen med två separata avtal kan tyckas logiskt sett utifrån hur avtalen idag ofta ser ut när det gäller molnbaserade system. Konsekvensen är dock att detta inte speglar den dialog som parterna har haft under upphandlingen. I merparten av alla upphandlingar sker ett stort interaktivt utbyte av information där leverantören slutligen lämnar ett anbud med löften om hur det nya systemet kommer att uppfylla kundens behov när det sätts i drift. Och verkligheten landar ofta i att ”allt inte blev riktigt som det var tänkt” och där en av orsakerna är att systemet visar sig ha brister. Ibland kan det avhjälpas via alternativa processflöden men ibland får man helt enkelt konstatera att det finns brister.
Frågan som uppstår i detta läge är vem som bär ansvar för vad och hur kunden ska kompenseras för att systemlösningen inte motsvarar det som utlovats under upphandlingen. Med två separata avtal blir det betydligt svårare för kunden att nå en uppgörelse med återförsäljaren, som helst tvår sina händer och hänvisar till att denne inte kan ansvara för eventuella brister i systemet. Och möjligheten för kunden att söka kompensation från tillverkaren av systemet är obefintlig.
I den bästa av världar ska kunden enbart teckna ett enda och samlat avtal med kunden som avser leverans av en nyckelfärdig systemet som motsvarar kundens behovsbild. Och då ett avtal som också inkluderar systemet oavsett om det avser onpremise eller en molntjänst. Nu är inte verkligheten så enkel att det alltid går att nå ett samlat avtal (av flera olika anledningar) men det är viktigt för kunden att förstå skillnaden mellan att ”köpa ett system” kontra att ”köpa en leverans”. Och det är viktigt för kunden att hitta en fungerande avtalskonstruktion som oavsett ett eller flera avtal håller ihop återförsäljarens ansvar för ”hela leveransen inklusive systemet”.
Precis ovanstående situation har varit utgångspunkten när HerbertNathan & Co utarbetat ett eget leveransavtal, med fokus på Affärssystem och komplexa implementeringsprojekt, ihop med Danowsky & Partners. Det innebär att det numera finns alternativ till de traditionella leverantörsframtagna avtalen IT-projekt och Avtal-90 som både har brister när det systemprojekt.
