Kravlista för affärssystem: prioritera innan du bokar demo
Gå igenom flödet avsnitt för avsnitt och märk varje rad som måste, bra att ha eller inte aktuellt. Du får en sammanfattning att skriva ut, spara eller skicka till de leverantörer ni pratar med. Allt stannar i din webbläsare.
SystemvalGratis, ingen inloggning · leverantörsneutral
Om verksamheten
Fälten är frivilliga, men de gör listan läsbar för den som får den. Allt du fyller i stannar i
din webbläsare och sparas där tills du rensar den. Ingenting skickas någonstans.
Vad som ska behållas är lika viktigt som vad som ska bytas. Ett byte där ekonomisystemet får
stå kvar är ett mindre projekt.
0 av 53 rader besvarade
0
krav är märkta Måste.
Försäljning och order
Offert som blir order utan att något skrivs in igen
Kundunika priser och prislistor per kundgrupp
Vanligaste orsaken till att order fortfarande skrivs för hand.
Rabattregler: staffel, kampanj, kundrabatt
Delleverans och restorder på samma orderrad
Orderbekräftelse och följesedel ut till kund automatiskt
Återkommande order eller avtal med fast leveransplan
Fraktkostnad beräknad på ordern
Lager och lagerplats
Saldo per lagerplats, inte bara per artikel
Skillnaden mellan att veta att varan finns och att veta var den står.
Flera lager, butiker eller externlager
Plockning med streckkod och handdator
Batch- eller serienummer med spårbarhet
Reservation av saldo mot order
Avgör om två säljare kan lova samma vara till olika kunder.
Löpande räkning i stället för stopp och helårsinventering
Överföring mellan lager
Inköp och leverantörer
Inköpsförslag ur behovet: beställningspunkt, order och prognos
Inleverans mot inköpsorder, med avvikelser
Landad kostnad: frakt och tull ut på artikelvärdet
Avgör om marginalen ni ser är den ni har.
Leverantörspriser och avtal per artikel
Uppföljning av ledtid och leveransprecision
Direktleverans från leverantör till kund
Produktion och arbetsorder
Artikelstrukturer och operationer
Arbetsorder med material- och tidrapportering
Planering mot maskiner och personer
Efterkalkyl: planerat mot verkligt utfall
Den siffra som avgör om nästa offert blir rätt prissatt.
Kvalitetskontroll och avvikelsehantering
Legoarbete hos underleverantör
Ekonomi och fakturering
Kundfaktura skapad ur ordern
Behålla nuvarande bokföringssystem
Ofta billigare än att byta allt samtidigt. Skriv vilket i rutan nedan.
Leverantörsfaktura matchad mot inköpsorder och inleverans
Lagervärde och lagerförändring till bokföringen
Moms vid EU-handel och export
Flera valutor
Kanaler, e-handel och frakt
Webbutik som visar saldo ur samma lager
Marknadsplatser: Amazon, Fyndiq, CDON och liknande
Kundportal där B2B-kunder ser sina priser och sin orderhistorik
Fraktbokning och etiketter mot transportör
Spårningslänk ut till kund
Kunder, ärenden och service
All kunddialog samlad på kunden
Ärenden och support med svarstider
Returer och reklamationer
Serviceuppdrag ute hos kund
Installerad utrustning per kund
Uppföljning och data
Nyckeltal på startsidan, olika per roll
Egna rapporter och urval
Export till Excel
Data till Power BI eller motsvarande
Historik: vem ändrade vad och när
Införande, teknik och behörighet
Öppet API för egna integrationer
Integration mot befintliga system
Migrering av artiklar, kunder och saldon
Underskattas nästan alltid. Fråga vem som gör jobbet.
Behörighet per roll
Mobil användning i lagret eller ute på fältet
Utbildning och support på svenska
Sammanfattning
Sammanfattningen byggs medan du fyller i. Den samlar Måste-kraven för sig, Bra att ha för sig
och dina egna anteckningar sist — i ett format som går att klistra in i ett mejl.
Prioritera, annars gör leverantören det
Den vanligaste kravlistan är en lista där allt är viktigt. Den är lätt att skriva och omöjlig
att svara på: varje leverantör plockar de krav som passar den egna produkten, visar dem i
demon och lämnar resten. Prioriteringen sker ändå, men någon annan gör den och ni ser den
inte.
Därför har varje rad här tre lägen i stället för en kryssruta. Måste betyder
att ett system utan det här faller bort. Bra att ha betyder att det påverkar
valet men inte avgör det. Inte aktuellt är lika användbart som de andra två:
det korta svaret spar demotid åt båda parter.
Blir det trettio måste-krav är listan inte prioriterad, den är bara nedskriven. Gå igenom dem
igen och fråga: skulle vi verkligen välja bort ett system som i övrigt passar perfekt, för
just den här raden?
Beskriv hur ni gör idag — inte vad systemet ska ha
Fritextrutan sist i varje avsnitt är den mest värdefulla på hela sidan, och den som oftast
lämnas tom. Ett krav som "stöd för delleverans" kan uppfyllas av vilket system som helst. Att
ni skickar cirka fyrtio delleveranser i veckan, att lagret meddelar dem i ett kalkylblad och
att kunden ringer och frågar var resten är — det går inte att svara ja på utan att faktiskt ha
en lösning.
En bra beskrivning innehåller ett antal, ett moment och ett problem. Två personer lägger en halv dag i veckan på att stämma av saldot mot webbutiken, och det
blir ändå fel någon gång i månaden säger mer än tio kravrader.
Det som kostar mest står sällan i kravlistan
Kraven handlar nästan alltid om funktioner, medan det som spräcker tidplanen är någonting
annat: migreringen av artiklar och saldon, integrationerna som ska byggas, och att personalen
ska hinna lära sig systemet samtidigt som verksamheten rullar vidare. Sista avsnittet finns
därför med, och de raderna förtjänar samma allvar som de andra.
Två frågor är värda att ställa tidigt till varje leverantör: vem gör migreringen, och vad
händer med den om datan i det gamla systemet är rörig? Svaret skiljer sig mer mellan
leverantörer än något funktionskrav.
Skicka samma lista till alla
Tre demonstrationer utan gemensam grund blir tre olika samtal, och det som fastnar är vem som
var mest övertygande. Får alla samma lista i förväg blir svaren jämförbara, och det syns
tydligt vem som svarar på frågan och vem som byter ämne.
Listan nämner inte Fluit i något krav. Det är avsiktligt: en kravlista med en leverantörskolumn
är en broschyr, och den hade ingen tagit med sig till nästa möte.
Efter listan
När raderna är ifyllda har ni underlag för tre saker: en intern diskussion om vad som faktiskt
ska bli bättre, en agenda för demon, och något att jämföra svaren mot efteråt. Vill ni se hur
Fluit hanterar era måste-krav finns funktionerna beskrivna, en
jämförelse med andra system och vad det kostar.
Ta med listan till demon. Vi går hellre igenom era rader än vår egen presentation.
Vanliga frågor
Vad ska en kravlista för affärssystem innehålla?
Två saker: vilka krav som är avgörande och hur ni arbetar idag. Det första gör att leverantören kan säga nej i tid, det andra gör att demon handlar om er verksamhet i stället för om produkten. En ren funktionslista utan processbeskrivning ger svar som alla leverantörer klarar att svara ja på.
Hur många krav ska vara märkta som måste?
Färre än man tror. Är hälften av raderna avgörande finns ingen prioritering kvar, och då gör leverantören prioriteringen åt er — i den ordning som passar leverantören. En handfull krav som verkligen fäller avgörandet säger mer om verksamheten än fyrtio som alla är viktiga.
Behöver ett mindre företag en formell kravspecifikation?
Nej, och en tjugosidig kravspecifikation med ska- och bör-krav är oftast fel verktyg under hundra anställda. Det som behövs är att alla internt är överens om vad som ska bli bättre, och att samma frågor ställs till alla leverantörer. Den här listan är gjord för det, inte för en offentlig upphandling.
Sparas det vi fyller i?
Bara i din egen webbläsare, så att listan finns kvar om du stänger fliken och kommer tillbaka. Ingenting skickas till oss om du inte själv klickar på Skicka till Fluit, och då öppnas ditt vanliga e-postprogram med texten ifylld så att du ser exakt vad som skickas.
Kan vi använda listan mot flera leverantörer?
Ja, det är meningen. Listan nämner inte Fluit i något krav, och den är skriven för att gå att skicka vidare. Poängen med att skicka samma lista till alla är att svaren blir jämförbara — annars jämför man tre demonstrationer av tre olika saker.
Vad händer om vi upptäcker fel krav senare?
Det gör ni, och det är normalt. Krav som formuleras innan man sett något system är gissningar, och de blir bättre efter första demon. Fyll i listan igen efteråt, den ligger kvar i webbläsaren, och notera vad som ändrades. Att kraven flyttar sig är information om verksamheten, inte ett misslyckande.