Smartare inköp!

Bättre upphandling kan ge stora besparingar. Men att sköta inköp så att man dels följer regelverken och dels får leveranser i rätt tid med tillräckligt bra kvalitet till förmånligaste pris både på kort och lång sikt är svårt. Leverantörerna  är ofta välutbildade och vältränade på att göra bra affärer – de är säljare på heltid. För att möta upp på ett professionellt sätt kan det vara lönsamt att kompetensutveckla kommunens upphandlare och oftare använda extern kompetens för att köpa kvalitet och funktion till bra priser.

Vad kännetecknar då bra upphandling ?

Grundregler är  att man inte  skriver  offertförfrågningar som driver kostnader, alltid upphandlar i konkurrens och genom att undvika krav som inte ger nytta och värde väljarna. Man bör avstå så långt som det är möjligt från att ställa krav på hur en produkt har framställts. Det är vad som levererats som man ska betala för – krånglar man till det så ökar priset. Köp om möjligt standardprodukter, det blir oftast billigare i längden och innebär också att man lättare kan byta leverantör om något oförutsett skulle hända.

Man bör också fundera på vad som är syftet med ett specifikt krav. Ekologiskt eller KRAV är ett vanligt och populärt krav som inte definierar egenskaper hos det som levererats utan bara hur produkten odlats eller framställts. Mer intelligenta krav på livsmedel  är att dels ställa konkreta krav på kvalité och lågt innehåll av skadliga kemikalier, dels på miljöpåverkan och annat skadligt. Minsta möjliga användning av antibiotika är ett exempel på vad som borde finnas i kravlistan. Ekologisk djurhållning begränsar dessvärre inte antibiotikaanvändningen – kolla själv i EU-förordningen nr 834/2007! I stället föreskriver  EU att man i ekologisk djurhållning hellre ska använda örtmediciner och homeopatisk mediciner i första hand och vetenskapligt erkända mediciner i andra hand. Örtmediciner till kossor som har problem med magen – fascinerande tanke!

Om man upphandlar något som ska byggas eller konstrueras bör man  ange funktionella krav, d v s beskriv vad som skall klaras av snarare än hur. Lämna till leverantören att föreslå den tekniska lösningen. Detta innebär att man inte ska formulera detaljerade tekniska krav och lösningar i kravspeci­fikationen. Det är betydligt bättre att definiera vad man vill ha ut av det  som upphandlas. Undantag från denna regel är t.ex.  kompletteringar av ett befintligt system, utbyggnad av en anläggning där den tekniska lösningen redan är vald eller om man vill få till stånd standardisering.

Att ta som vana att lämna så mycket som möjligt av den detal­jerade tekniska lösningen till leverantören är fördelaktigt både för köparen och leverantö­ren. Det  kan ge uppslag till bättre tekniska lösningar än köparen har förutsättningar att tänka ut och  innebär att köparen på ett bättre sätt utnyttjar leverantörens kompe­tens. Om köparen föreslår en teknisk lösning så kan detta innebära att man ofrivilligt förhindrar att bättre lösningar prövas. Det är svårt för en leverantör av psykologiska och försälj­ningsmässiga skäl att lägga fram en annan lösning än vad som anges i en kravspecifika­tion. Det innebär ju att leverantören ifrågasätter kundens förslag vilket upplevs som en dålig inledning på en försäljningsansträngning.

En annan fördel med funktionella krav är att köparen mera entydigt kan lägga ansvar på leverantören för det som upphandlas ska fungera tillfredsställande. Om kunden har lagt fast en lösning så kan leverantören vid problem hävda att köparen ”fått vad det han begärt”. Det är då svårt att hävda att leverantören har ansvaret för att rätta till problem som uppstått.

Det viktiga i kravspecifikationer är inte frågeförteckningar utan tydliga och genomtänkta  funktionella krav. De som deltagit i utarbetande av en kravspecifikation vet att det är väldigt lätt att ta med ett antal frågor ”för säkerhets skull”. Dvs man funderar inte så mycket på vad man ska använda svaret på frågan till. Det innebär att frågan kan vara meningslös – upphandling inte är till för att skapa sysselsättning för säljare och utvärderare.