En order på insulin är inte en rad i ett system. Den kan sluta på en vårdavdelning, i någons kök eller i ett tillfälligt boende — och den som beställer är nästan aldrig den som tar emot. När ExFlow Sales Order gick live i januari 2024 var det den verksamheten jag designade flödet för.
Jag designade hela flödet: hur en order tas emot, vad som kontrolleras innan den blir en order, när en människa måste svara, och hur den lämnar huset som en leverans och en faktura. Utgångspunkten var ingen demo. Det var en medicinleverantör vars produkter håller människor vid liv, och som levererar till sjukhus, privata hem och tillfälliga boenden.
Fallet
Ett standardflöde för säljorder utgår från att köparen och mottagaren är samma person, på en fast adress, med en planerad leverans. För livsviktig diabetesmedicin håller inte det antagandet.
Regionen eller sjukhuset köper. Patienten, hemtjänsten eller ett tillfälligt boende tar emot. Adressen kan ändras sent i processen, och en feladresserad eller försenad leverans är inte ett irritationsmoment — det är ett sjukvårdsproblem. Samtidigt måste priset stämma mot rätt avtal, och ingen får lova en leverans som lagret inte kan plocka.
Tre saker formade designen: mottagaren är inte köparen, avvikelsen är normalfallet, och en order du inte kan följa är en order du inte har.
Vad den löser
- Alla ordrar in i samma kö. EDI från regioner, mejl med PDF och det som kommer på telefon hamnar i samma lista med samma status. Ingen order lever bara i någons inkorg.
- Kontroll innan ordern blir en order. Avtal och pris per kund, artikel, mängd och leveransadress kontrolleras när ordern tas emot. Det som stämmer går vidare; det som avviker går till en människa — med orsaken utskriven, inte tyst vidare.
- Godkännande som eskaleras. En order som kräver godkännande går till rätt person och vidare uppåt om ingen svarar. Livsviktig medicin får inte ligga stilla för att någon har semester.
- Mottagare per order, inte per kund. Leveransadressen hör till ordern: vårdavdelning, privat hem eller tillfälligt boende. Direkt från lager till mottagare, utan mellanlandning.
- Leveranslöfte mot verkligt lager. Ett datum lämnas bara om lagret kan plocka det. Annars syns det direkt i stället för tre dagar senare.
- Ett flöde hela vägen. Plock, leverans, faktura och kredit hänger ihop. Ingen rad skrivs in två gånger, och inget steg kräver att någon minns vad som sades i telefon.
- Spårbarhet. Vem som ändrade vad, och när. I en verksamhet där en felaktig leverans är en patientsäkerhetsfråga är det inte compliance-teater — det är själva poängen.
Andra kunden: en tillverkare av precisionsavtryckare till gevär
TriggerTech i Kanada bygger avtryckare till bolt action-gevär, AR-plattformar och armborst och säljer dem över hela världen. Där var problemet ett annat: ordrarna kom in i många olika former och landade hos olika personer, och arbetet med att få ihop dem tog tolv timmar i veckan.
Samma lösning — alla ordrar in i ett flöde — tog det arbetet från tolv timmar i veckan till en timme i veckan. Inte för att någon jobbade snabbare, utan för att det inte längre fanns något att leta efter.
Varför flödet ser ut som det gör
Tre regler styrde arbetet mer än något gränssnitt gjorde.
Mottagaren är inte köparen. Adressen och mottagaren hör till ordern, inte till kundregistret. Det låter som en detalj tills man inser hur många system som är byggda på motsatsen.
Avvikelsen är normalfallet. I den här branschen är det vanliga att något inte stämmer: en ändrad adress, ett pris som inte matchar avtalet, en order som måste fram i dag. Därför designade jag undantagen först och den lyckliga vägen sist.
Status måste vara sann. En order som ser ut att vara på väg, men inte är det, är värre än ingen status alls. Varje steg ska gå att lita på utan att ringa och fråga.
Inget av det här är sofistikerat. Det mesta av arbetet låg i att välja bort steg, inte i att lägga till dem.
Vem som står bakom
ExFlow byggdes av SignUp Software i Solna — grundat 1999, ExFlow lanserat 2003 — och säljorderdelen är en del av den portföljen för Microsoft Dynamics 365 Business Central. 2026 bytte bolaget namn till Truvio, efter att ha samlat fyra Microsoft-ISV:er i en portfölj: ExFlow (AP-automation, data capture, e-fakturering, säljorder), Axtension (produktion, projekt, shipping), SKsoft (bank och treasury) och DynamicWeb (commerce och PIM).
Allt är byggt inuti Dynamics 365 F&O och Business Central snarare än ovanpå, och Truvio beskriver sitt uppdrag som att stänga “ERP Value Gap”: skillnaden mellan vad ERP:t kan och vad verksamheten faktiskt får ut. Ovanpå portföljen ligger numera också agentisk AI under namnet TruvioSense. Säljorder är en liten del av en stor portfölj. Det är den del jag designade.
Har din verksamhet ett orderflöde som fortfarande lappas ihop av mejl, telefon och en excelfil — där mottagaren aldrig riktigt är den som står i kundregistret — är det precis sådant jag bygger. Tjänstesidan säger vad jag gör; mejla [email protected] med flödet du fortfarande lappar ihop.