I processen att välja den bästa mjukvaruleverantören för logistikflöden förlitar sig många företag idag fortfarande till den traditionella Request For Information (RFI) trots den framväxande, mer effektiva metoden Proof of Concept (PoC)
Att välja programvara är kritiskt. En mjukvara som inte överensstämmer med en organisations verksamhetsbehov och utmaningar kan generera en förlust av miljontals kronor. Mot den bakgrunden kommer denna text fokusera på varför RFI är en förlegad metod vid val av mjukvaruleverantör och rikta ljus på PoC som kan anpassa leverantörens mjukvara direkt till din organisation och affärsutmaningar. (Gäller även för Request for Proposal (RFP) och Request for Quotation (RFQ), för enkelhetensskull hänvisar vi till RFI i detta inlägg.)
5 nackdelar med RFI
Strategin bakom RFI är enkel i teorin. Skapa en lista över programkrav och välj den leverantör som uppfyller mest krav, tyvärr fungerar det inte så i praktiken vilket alla som genomfört RFI-processen vet. Nedan följer exempel av de vanligaste problemen med RFI.
1. Funktionalitet istället för företagsmål. Alla måste veta vad affärsmålen är för att en RFI ska fungera, om du har tidigare erfarenhet av supply chain projekt vet du att så inte är fallet.
2. Utförlig lista med krav. Listan med ”must have” kan innehålla flertalet krav från flera olika team där listan snabbt kan växa sig lång, men som egentligen inte är nödvändig. Kraven kan utlämna kapaciteten du inte visste att du behöver och istället innehålla funktioner som inte behövs.
3. För allmängiltig. En RFI kan ta hundratals timmar att skapa, för att spara tid och arbetskraft lånar vissa organisationer en RFI från en annan. Ingen leverantör är den andra lik, likaså har inget företag exakt samma behov som den andre.
4. Prognosriktighet som slutmål i stället för verktyg. En organisation fokuserar ofta på vad de vet och det som ingen vet något om lämnas också förlorat i RFI som en blind fläck. Att organisationen koncentrerar sig på rätt mätvärden är något som RFI antar. Till exempel betonar RFI: er i leverantörskedjan ofta prognosens noggrannhet. I flyktiga försörjningskedjer är prognoser i sig alltid felaktiga. Ju längre prognoshorisont, desto mer felaktiga är de. Vid optimering av försörjningskedjan bör prognoser ses som ett verktyg, inte som en slutpunkt.
5. Slöseri med resurser. Att skapa en RFI kan ta hundratals timmar och att utvärdera svar kan ta ännu längre tid, bara för att resultera i minimala skillnader leverantörer emellan. Lösa tolkningar av en funktion är en risk för kunden som ofta blir en fördel för leverantörerna.
Slutsats
Ett Proof of Concept som testkörning är ett bättre sätt att utvärdera en programvara för logistikflöden. Medan RFI låter bra i teorin fungerar PoC i verkligheten. Många intressenter vill se bevis på vad mjukvaran kan göra för dem och att det fungerar i verkligheten.