[YesBoss]

Ursprungligen postat av ConnyWesth

Vitsen är nog att kunden/beställaren måste ha tillräcklig kompetens för att kunna testa att applikationen verkligen uppfyller de krav som kunden själv ställer, annars ska man inte ta det ansvaret själv utan anlita en konsult som tar just beställarrollen eller anställa någon som kan detta. Men det är alltid kunden som måste ta ansvar för sitt beslut och måste därmed även ha förmågan att bedöma om den de anlitar passar för det kunden vill.

Jag har sett detta på nära håll, då det hänt att jag hamnat i projekt där projektledaren helt enkelt inte vetat vad de gett sig in på, PL hade bemannat projektet med en hel drös programmerare men de fanns INGEN som tog hand om krav eller arkitekturfrågorna. Det projektet gick åt skogen kan jag säga...

Det är som när du bygger ett hus, om du inte vet hur du vill ha ditt hus så ska du inte ge dig in på att köpa ett. Det är samma sak med datasystem.

Visst, det finns leverantörer av IT-system som kan mycket mer än kunden och har brancherfarenhet så de vet vad kunden behöver trots att kunden ger fel information, men de kostar därefter. De ger sig aldrig in i uppdrag på småbelopp utan vill ha rejält betalt, vilket de oxo får. Jag misstänker att det ligger långt utanför denna budget.

När du beställer ett hur och har gjort egna ritningar (som normalt en yrkesskicklig arkitekt tar fram) så blir kanske inte ritningarna gjorda med så hög kvalitet att de går att använda för att kontrollera i efterhand.

Leverantören bygger huset efter de ritningar han fått, men kunden har alltid rätt i sin beställning så även om leverantören tycker det är konstigt så är det ju vad kunden skriftligt har specat....

När kunden senare även accepterar huset som det blev byggt genom att betala alla fakturor så är affären avslutad.

Man kan inte lasta leverantören för att kunden slarvat med leveranskontrollen. Det finns ju flera vedertagna "processer" eller "rutiner" när det gäller beställningar av IT-system till fastpris och det är just offertförfrågan, offert, avtal, produktion, leverans, acceptanstest, fakturering, betalning.... Det finnas andra varianter särskilt för längre avtal då man har en mer utdragen produkltion, leverans och betalningsplan. Men fastpris måste man alltid ha avtal på papper annars är det praxis att allt arbete sker på löpande räkning till leverantörens ordinarie priser.

Jag har som sagt ingen vetskap om exakt hur denna affär upprättats men man måste när man beställer ett system veta vad man gör annars blir man annorlikt missnöjd även om leverantören gjort allt rätt. Det är ett typiskt problem just när man beställer skräddarsydda lösningar oavsett om det gäller byggbranchen, databranchen, oljebranchen eller vilken annan branch man än ger sig in på.

Ger du dig in på att bygga en restaurang så måste du veta vad du ger dig in på, annars är risken stor att misslyckas eller att det kommer kosta massor med pengar som man inte räknat med.

Eller så kan man se det så här, jag anlitar dig för att jag vill att du utvecklar en applikation som gör att när jag skriver in 1+1 så får jag resultatet 2. Du vet vilket resultat jag förväntar mig, jag vet vilket resultat jag förväntar mig. Både jag och du vet var resultatet ska vara, finns inga oklarheter och inget att älta om.

Du blir färdig med projektet och jag testar det på din server och precis som sagt så får jag 2 i resultatet, jag betalar och du flyttar det till min server. Jag provar samma applikation och får fram 100345678 dvs ett helt galet resultat, ska jag då betala för att han har gjort fel?

Målet är tydligt, kan du få fram en 2:a via en applikation så får du 1 sek. Jag betalade men du levererade inte det vi bestämde om.

Det är verkligen så enkelt, inget om eller men. Jag betalade för att få en 2:a, du levererade inte det, jag har gjort mitt och betalat men det har inte du. Simpel business....