Slik kjører du en leverandørytelsespilot som beviser noe

Del med

Mesteparten av programvaren for leverandørytelse evalueres på en måte som garanterer et usikkert svar. Slik utformer du et pilotprosjekt som fører til en beslutning i stedet for en debatt.

Når et innkjøpsteam begynner å se seriøst på programvare for leverandørytelse, er problemet vanligvis godt forstått internt. Scorekort ligger i regneark, halvparten av interessentene svarer aldri, den kvartalsvise gjennomgangen avhenger av hvem som husket å oppdatere filen, og ingen kan produsere en tolvmåneders trend for en strategisk leverandør uten å miste en dag på det.

Det som skjer videre er der de fleste evalueringene går galt. Teamet bestiller tre demonstrasjoner, velger en favoritt, kjører noe som kalles en pilot i noen uker, og oppdager så at piloten aldri svarte på spørsmålet de faktisk trengte svar på. Den var for liten til å vise noe, for kort til å vise en trend, eller avgrenset på en måte som i stillhet unngikk de vanskelige delene.

En pilot er ikke en lengre demonstrasjon. Det er et eksperiment, og den fortjener å bli utformet som et.

Start med å skrive ned hva piloten tester

Funksjonsspørsmål hører hjemme i en demo. Du kan bekrefte på tretti minutter om en plattform støtter vektede kriterier, flerspråklige spørreundersøkelser eller en CAPA-arbeidsflyt. Det er dyrt å bruke åtte uker på å bekrefte det samme.

Et pilotprosjekt eksisterer for å teste atferd, og det er egentlig bare tre spørsmål som er verdt innsatsen:

  1. Vil våre interne interessenter reagere? Adopsjon i innkjøpsorganisasjonen er det vanligste enkeltstående problemet, og det har nesten ingenting med programvarekvalitet å gjøre.
  2. Vil leverandørene våre engasjere seg? En leverandørrettet prosess som leverandører ignorerer er en rapporteringsøvelse, ikke et ytelsessystem.
  3. Endrer resultatet en avgjørelse? Hvis pilotprosjektet produserer dashbord som ingen handler på, har du kjøpt synlighet, ikke resultatstyring.

Skriv disse ned, med dine egne ord, med dine egne tall vedlagt. Alt nedenfor tjener til å besvare dem.

Velg pilotleverandørene bevisst

To instinkter for å motstå. Det første er å velge de enkleste leverandørene, de med en engasjert kundeansvarlig som vil fylle ut alt du sender. Det beviser ingenting, fordi disse forholdene allerede fungerer. Det andre er å fylle pilotprosjektet med de dårligste leverandørene, noe som gjør en programvareevaluering til en rekke vanskelige kommersielle samtaler og forvirrer de to.

En representativ gruppe på femten til tjuefem leverandører fungerer bedre enn begge ytterpunktene. I praksis:

  • To eller tre strategiske leverandører der forholdet er godt, for å teste dybde: flerkriterieevaluering, felles forbedringsplaner, rapportering på ledernivå.
  • Ti til femten taktiske eller gearingleverandører, for å teste skala: fjerner automatiseringen faktisk jakten, eller flytter den den bare til et nytt verktøy?
  • To eller tre leverandører med et problem med live-ytelse, for å teste handlingsløkken fra ende til annen, fra å finne problemet til å lukke det.
  • Minst én leverandør utenfor hjemlandet eller språket ditt, fordi det er der forutsetningene om portaladopsjon bryter sammen.

Dekk minst to kategorier med ulike interne evaluatorgrupper, for eksempel kvalitet og drift, eller IT og anlegg. Hvis innkjøp er den eneste funksjonen som scorer leverandører under pilotprosjektet, har du testet et innkjøpsverktøy og ikke lært noe om hva som skjer når evaluatoren er en ingeniør uten interesse i prosjektet ditt.

Registrer grunnlinjen før dag én

Du kan ikke demonstrere forbedring mot et minne. Før noe som helst konfigureres, bruk en halv dag på å registrere hvor du er i dag. Det er den minst glamorøse delen av et pilotprosjekt og den delen som bærer forretningsargumentet.

Grunnleggende beregning Hvordan fange den Hvorfor det betyr noe
Svarprosent for interessenter i din siste evalueringsrunde Sendte invitasjoner kontra fullførte Det primære interne adopsjonssignalet
Forløpte dager fra lansering til et komplett scorekortsett Kalenderdatoer fra din siste syklus Måler den reelle kostnaden ved å jage
Timer brukt per syklus på å samle inn og konsolidere data Spør den som faktisk gjør det Tallet som økonomifunksjonen din vil bry seg om
Åpne leverandørsaker med navngitt eier og forfallsdato Tell dem De fleste lagene oppdager at tallet er nær null
Leverandører med sammenlignbar poengsumhistorikk over tolv måneder Tell dem Skiller en trend fra en samling anekdoter

De fleste av disse tallene er ubehagelige å skrive ned. Det er nettopp dette ubehaget som er poenget. I løpet av nitti dager blir de før-kolonnen i en sammenligning på én side, og en før-og-etter-tabell er langt mer overbevisende enn noen leverandørs referanseindeks.

Kjør den i to sykluser, ikke én

Seksti til nitti dager, som strekker seg over minst to fulle evalueringssykluser.

Én syklus forteller deg at plattformen kan sende en undersøkelse og bygge et scorekort. To sykluser forteller deg om noe har endret seg mellom dem: om svarprosentene økte da interessentene visste hva de kunne forvente, om en handling som ble tatt opp i den første syklusen ble avsluttet av den andre, om en score endret seg, og du kan forklare hvorfor. Leverandørytelsesstyring er en løkke, og det å teste en halv løkke lærer deg svært lite.

Hvis produksjonskadensen din er kvartalsvis, komprimer den i løpet av pilotperioden i stedet for å vente i seks måneder på en konklusjon. Kjør månedlig, eller kjør to sykluser med seks ukers mellomrom. Du kan avgjøre produksjonskadensen og styringsmodellen når du vet at prosessen fungerer.

Sett inn ekte leverandører

Det er her utrullinger dør, og det dukker sjelden opp i en intern pilot.

Leverandørene dine har allerede portalpålogginger for de fleste av sine største kunder. Hvis din trenger et nytt passord, en opplæringssamtale og en PDF-manual, er engasjementsraten du ser hos tjue leverandører den samme engasjementsraten du vil se hos fire hundre, bare verre, fordi hos fire hundre er det ingen som ringer for å hjelpe dem.

Ting som er verdt å måle på leverandørsiden:

  • Hvor mange leverandører fullfører sin første handling uten å kontakte noen for å få hjelp
  • Forløpt tid fra invitasjon til første pålogging
  • Hva skjer når den registrerte kontakten er en delt postboks, eller når personen videresender forespørselen til en kollega
  • Om en leverandør kan se hva de blir målt på, før de blir målt på det

Det siste punktet er ikke en brukervennlighetsdetalj. Leverandører som forstår kriteriene, forbedrer seg mot dem. Leverandører som får en poengsum uten synlig grunnlag bestrider den, og bestridelser er den dyreste produksjonen et scorekortprogram kan generere.

Avtal suksesskriteriene skriftlig før avspark

Én side, signert av sponsoren din og delt med leverandøren. Spesifikke tall, ikke adjektiver:

  • Svarprosent for interessenter over en definert terskel innen andre syklus
  • En komplett scorecard satt innen et definert antall virkedager, uten manuell forfølging fra innkjøpsteamet
  • Et definert antall leverandørhandlinger som er opprettet, tildelt en navngitt eier og avsluttet inne i plattformen
  • Minst én reell avgjørelse som brukte pilotresultater som bevis: en forhandlingsposisjon, en volumomfordeling, en leverandørutviklingsplan, eller en deeskalering

Det siste kriteriet er det som overbeviser en finansdirektør. De andre er hygiene.

Forvent at leverandøren forhandler om disse målene, og la dem. En leverandør som protesterer mot et spesifikt tall vet vanligvis nøyaktig hvor friksjonen sitter i den delen av prosessen, og den samtalen er mer avslørende enn noen demonstrasjon.

Bestem på forhånd hva som skjer på dag nitti

Tre utfall, alle legitime: utrulling, forlengelse med en spesifikk og navngitt løsning, eller stopp. Skriv ned hvilke bevis som fører til hva, og hvem som tar avgjørelsen.

Piloter uten en forhåndsavtalt exit har en tendens til å gli over i permanente gratis prøveperioder. Det er verre for deg enn for leverandøren. Det er ingen budsjettsamtale, ingen intern hastverk, mesteren sin oppmerksomhet flyttes andre steder, og i løpet av et kvarter har teamet stille gått tilbake til regnearket mens en ubrukt innlogging ligger i teknologistakken.

Slik ser en god pilotrapport ut

To sider, ikke tjue:

  1. Før og etter på grunnmålingene du fanget opp i uke én.
  2. Én leverandørhistorie, fra ende til annen. Problem identifisert, tiltak reist, eier tildelt, bevis for avslutning, poengsumbevegelse. Et enkelt komplett eksempel er mer overbevisende enn samlet statistikk.
  3. Adopsjonstall for begge sider, internt og leverandør.
  4. En ærlig liste over hva som ikke fungerte. Konfigurasjonshull, integrasjonsfriksjon, interessenter som aldri engasjerte seg.
  5. Kostnaden ved å ikke gjøre noe, uttrykt i timer og dager som har gått fra grunnlinjen.

Punkt fire er viktigere enn folk forventer. En pilotrapport uten negative elementer kan leses som et salgsdokument og blir deretter diskvalifisert av alle som er senior nok til å godkjenne utgiftene.

Fem måter piloter tar feil på

  • Kun deltakelse i anskaffelser. Du lærer ingenting om interessentene som vil avgjøre om utrullingen blir avgjort eller ikke.
  • Import av dårlige leverandørstamdata og skyld på plattformen. Rydd opp tjue poster ordentlig i stedet for å importere to tusen dårlig. Problemer med datakvaliteten dukker opp uansett, men i det minste vet du hvilke som er dine.
  • Endring av evalueringsrammeverket midt i pilotfasen. Da er ikke syklus én og syklus to sammenlignbare, og du har mistet trenden du prøvde å observere.
  • Kjører enkelttrådet. Én mester, ingen sponsor. Hvis den personen bytter rolle, avsluttes piloten uavhengig av resultater.
  • Måling av tilfredshet i stedet for atferd. «Alle likte det» er ikke bevis. Svarrater, avslutningsrater og syklustider er det.

Den korte versjonen

De fleste evalueringer av leverandørytelse ender uten en avgjørelse, ikke fordi programvaren er vanskelig å bedømme, men fordi ingen definerte på forhånd hva som skulle telle som bevis. Bruk den første uken på basisdata og suksesskriterier, sett inn reelle leverandører i omfanget, kjør to sykluser, og den endelige rapporten skriver mer eller mindre seg selv.


EvaluationsHub kjører strukturerte pilotprosjekter med et definert omfang, avtalte suksesskriterier og en fast sluttdato. Hvis du allerede kjører leverandørevalueringer i regneark, send oss ​​ditt nåværende oppsett, så bygger vi det opp igjen i plattformen slik at pilotprosjektet starter fra rammeverket ditt i stedet for en generisk mal. Bestill en time med en innkjøpsspesialist.

Våre siste blogger

Få verdifulle perspektiver på tilbakemeldinger fra kunder og leverandører fra B2B
ytelse gjennom bloggene våre, hvor bransjeledere deler erfaringer og
praktiske råd for å forbedre forretningssamhandlingen din.

Se alt