Vi oplever for ofte, synes vi, at tilretninger m.v., som vores leverandør - et dansk Navision Solution Center - leverer til os, er fejlbehæftede. To eksempler: 1, En dataport, som skal indlæse en lønfil fra et eksternt lønsystem, kunne end ikke få fat i den fil (fra diskette), som den skulle indlæse. 2, Der skulle hæftes bemærkninger til nogle nye stamkort. Men når standardknappen for Bemærkning aktiveres for indtastning af ny bemærkning, åbnes der ikke for indtastning, men der fremkommer en fejltekst. Er det urimeligt at forvente, at et Navision Solution Centre afprøver sine tilretninger m.v., inden disse leveres til kunden? Hvad kan kunden med rimelighed forvente af sin leverandør?
Hejsa, Nej, det er absolut ikke rimeligt at forvente at der altid er fejl i de tilretninger du modtager. Ikke for at forsvare Solution Centrene (jeg er selv ansat i et), men det er nu en gang umuligt altid at lave alting fejlfrit. Dette skal naturligvis ikke være en sovepude for Solution Centrene, som efter min mening bør gøre en indsats for at sikre at kavliteten af de de leverer er i top - om ikke andet så for at slippe for at skulle lave tingene om. Det er min opfattelse at kimen til mange “dumme” fejl bliver lagt allerede i det øjeblik kunden ønsker en speficik funktionalitet. Solution Centret “kører” næsten omgående “derudaf”, uden at høre kundens problemstilling til ende. Derfor får man kun halvdelen af problemstillingen med, og man laver det man tror kunden ønsker. For at begrænse denne uhensigtsmæssige måde at udvikle på, mener jeg det er meget vigtigt at konsulenten for det første sætter sig ned, og hører på kundens krav og ønsker, og for det andet spørger ind til hvilket FORRETNINGSMÆSSIGT problem, det er kunden gerne vil have løse. Jeg har adskillige gange set en tilretning, som kunden havde ønsket, men som i princippet var dækket 95% af standardfunktionaliteten. Nå det er sagt, så er det altså også vigtigt at kunden tager ansvar for at få kommunikeret hele problemstillingen til konsulenten, så de hele er med fra starten af. Desuden mener jeg at kunden bør være villig til at “justere” en lille smule på krav og ønsker, hvis det indebærer at problemstilligen kan løses uden tilretninger - eller med minimale tilretninger. Generelt mener jeg - selv om jeg nok får nogle konsulenter på nakken her - at vi er alt for hurtige til at tænke i “kodelinier” uden at have øre for den forretningsmæssige del af en problemstilling. Og hvis vi ikke snart tager os sammen, og får ændret denne holdning, så bliver vi overhalet indenom af folk der kan tale kundens sprog. Indlægget vil af nogle nok blive opfattet som provokerende (en konsulent, der giver kunden ret, det er jo uhørt 
). Men jeg synes det er på tide at vi får en debat om dette enme, så fyr løs allesammen Lars Strøm
Tak for interessant indlæg, Lars Strøm. Vi, kunderne, engagerer en IT-leverandør, fordi denne formodes at kunne et håndværk, som vi andre ikke er udlært i, nemlig at konstruere og implementere IT-løsninger. De fleste af os er vel typisk økonomi-ansvarlige. Vi kan måske nok beskrive, hvad vi forventer os af IT-systemet, men har brug for IT-leverandørens erfaring til f.eks. at komme rundt i hjørnerne, bl.a. med hensyn til at analysere, hvilke fejlsituationer (fejlindtastninger) og undtagelser, der kan forekomme, og som systemet bør kunne håndtere. I mit eksempel med en dataport, som skal indlæse en lønfil, synes opgaven meget enkel: “Lav en dataport, som kan indlæse en fil fra det eksterne lønsystem”. Men tanken, om at der i det eksterne lønsystem kunne være indtastet ugyldige kontonumre m.v., kom først, da vi testede den leverede dataport. Du når bredt rundt i dit indlæg, medens jeg gerne vil holde mig til afslutningen af processen: Er det urimeligt at forvente, at et Navision Solution Centre afprøver sine tilretninger m.v., inden disse leveres til kunden? Hvilke standarder og krav stiller Navision Software Danmark a/s til sine Navision Solution Centre med hensyn til afprøvning af tilretninger m.v. forud for leveringen til kunden?
Hej Henrik (og Lars), Jeg vil svare dit spørgsmål med et andet spørgsmål. Vil du betale for det? Hvis svaret er ja, så tror jeg desværre at du høre til en af de få. For generelt er min opfattelse at kunderne, især de mindre virksomheder, ikke vil betale for det. At mange kunder har især svært ved at forstå disse omkostninger skyldes ofte deres Navision konsulenter som, nøjagtigt som Lars skriver, tænker programlinier, men også ofte blot sætter sig ned og laver det kunden beder om, uden først rigtigt at dokumentere. En tilretning tager måske kun konsulenten 30 minutter at lave hos kunden. Skulle han lave det den “rigtige” måde, så ville kunde sandsynligvis komme til at betale mellem 60 og 120 minutter, da tid til dokumentation af krav, selve programmering samt leveringen også skulle regnes ind i prisen. Da jeg tog min edb-uddannelse for mere end 10 år siden, kunne vi vælge et kursus specielt om testning af edb programmer. Og skulle vi følge disse henvisninger så ville et gennemsnits Navision projekt blive både to og tre gange dyrere. For en rigtig aftesning kræver at der her bruges meget tid på dels først i detaljer at dokumentere systemkrav især med eksempler på input og hvilket output dette skal genere. En meget tidskrævende proces. Men når dette er sagt har du selvfølgelig ret. DET ER IKKE RIMELIGT. Især ikke de fejl du beskriver. De lyder ret grundlæggende. Og burde have været fanget inden leveringen. Hos os, Business Management International, har vi også fejl i programmering (det har man alle steder). Men jeg vil voge at påstå at vi ikke har ligeså mange fejl som hos vores NSC kollegaer. Og det skyldes at vi gør det anderledes. Vi arbejder nemlig med konsulenter og udviklere som to adskildte grupper. Dsv. konsulenten MÅ IKKE udvikle, udover skærm- og rapporttilretninger. Og det er kun få af dem der kan. Vores konsulenters baggrund er forretningssiden, for det meste med enten en MBA eller CPA (certified public accountant - autoriseret revisor). Deres opgave er at tage imod kundens krav og lave en enkel opgave beskrivelse som vores udviklingskoordinator enten selv estimere eller får estimeret hos en udvikler. Og når kunden har accepteret opgaven og udvikleren har lavet tilretningen, så sendes denne til konsulenten, der så til ansvar at sikre at tilretningen dels installeres, dels at denne er aftestet. Udvikleren er ansvarlig for en såkaldt “A testning”, som burde have fanget dine fejl. Og konsulenten skal teste at tilretningen også rent faktisk fungere hos kunden, når den er installeret. Ulempen ved dette system er naturligvis at det tager lidt længere tid, men erfaringsmæssigt ikke meget. Ofte blot en time eller to mere (afhængig af projektet). PS til Lars: Jeg synes ikke du er specielt provokerende, jeg tror faktisk at de fleste konsulenter er klar over disse problemer men at de føler at de har svært ved at gøre noget for at rette op på dem. Og BMI’s metode er jo ikke lige frem “løsningen” for alle. Best regards, Erik P. Ernst, webmaster Navision Online User Group
Hei igen, Jeg synes stadig det er rimeligt, at NSCerene aftester deres løsninger inden de bliver leveret. Det er med andre ord ikke urimeligt at kunden har en forventning om, at det han modtager er nogenlunde fejlfrit - 100% fejlfrihed opnår man ikke udelukkende ved test. Det er jo også derfor at software-releases bliver betatestet i rigtlge driftssituationer før endelig frigivelse. Det er - i hvert fald i teorien - rimeligt enkelt at foretage en test af de tilretninger der er brugt som eksempler. Det vil simpelthen indebære at man opstiller et antal målepunkter (som kunden også er enig i), og når den pågældende dataport så testes, så tester man om den kører fejlfrit i forhold til de angivede målepunkter. Problemet her er naturligvis at få målepunkterne så dækkende som muligt. Konsekvensen af målepunkter er dog også at hvis der ikke er et målepunkt, der dækker fx. forkerte kontonumre i lønsystemet så fungerer dataporten ikke tilfredsstillende for kunden, men leverandøren vil kunne henholde sig til at dataporten overholder målepunkterne, og dermed også er fejlfri. Det er jo ikke en situation, der er ønskelig for nogen af parterne. Derfor vil jeg give Erik ret i at det altså er tvingende nødvendigt at der bliver lavet en analyse af problemstillingen før man påbegynder konstruktionen af løsningen. Dette betyder også at det tager længere tid, og dermed at prisen bliver højere. Vi skal dog lige holde fast i at hvis der ikke bliver gennemført en analyse af problemstillingen, så er risikoen for fejl langt større, og fejlretninger og driftstab vil ofte koste en del mere end den merpris, der vil være for den samlede løsning når den inkluderer en analyse. (en analyse behøver jo ikke nødvendigvis at betyde et stort arbejde, det betyder bare at problemstillingen bliver gennemarbejdet). /Lars
Selvom, der er en gammel post, synes jeg nu alligevel at jeg vil nævne, at det kunne være rart om Navision kunne / ville stille et værktøj til rådighed, der kunne køre en automatiseret test. Dette ville jo kunne afsløre om nogle af de rettelser der er lavet har ødelagt noget standard-funktionalitet. ________________ Kind regards, Henrik Helgesen, Moderator Danish Edited by - hhelgesen on 2001 May 01 16:08:19