Tidigt i min karriär byggde jag ett gränssnitt för att driva en mottagningsstation på ett lager. Jag var stolt över det jag tyckte var en väl utformad och elegant slutprodukt. Det visade sig dock att den varken var funktionell eller intuitiv för lageroperatören, som utan omsvep sa: ”Det här är det dummaste jag någonsin har sett.”
Aj.
Det var en tidig lärdom i att bygga programvaruprodukter som kan användas i en fysisk miljö – i det här fallet ett lager. Om programvaran driver ett gränssnitt som ser bra ut men inte är byggt för verkligheten är den värdelös.
Även om det jag hade byggt såg bra ut (åtminstone för mig) innehöll det inte den funktionalitet som gjorde det verkligt användbart för mottagaren – vilket var hela poängen.
I dag registrerar mitt företag Flowspace över 200 000 fysiska händelser dagligen i vårt nätverk för e-handelsorderhantering. Jag har fått djupgående kunskap om de unika kraven på att bygga teknik som är beroende av den verkliga världen.
Att känna till att dessa händelser inträffar är bara en av utmaningarna med att bygga programvara för den fysiska världen. Den andra är att optimalt samordna händelserna för att möjliggöra effektiv och tillförlitlig orderhantering samt kompatibilitet med andra kritiska tekniska system.
Den här artikeln beskriver hur utvecklare bör hantera de unika utmaningar som uppstår när man bygger digital programvara som driver handlingar i den fysiska världen.
SaaS i en materiell värld
Programvara som tjänst (SaaS) driver vanligtvis en stor mängd osynligt arbete. Ett exempel med relevans för e-handelsområdet är Shopify.
Varumärken kan använda Shopify för att lansera en butik på bara en halvtimme utan behov av en fysisk butikslokal. Handlare styr butikens utseende, känsla och funktion. De kan integrera över 6 000 appar och integrationer för att möjliggöra ytterligare funktioner och ansluta till tredjepartsplattformar. För slutkunden framstår dock allt som en enkel och sömlös butik som möjliggör e-handelsköp.
Om man ser på den andra sidan av e-handelsmyntet – orderhanteringen – är SaaS något helt annat. Här måste logistiken verkställa ett fysiskt kommando. Till skillnad från teknik som bara finns i molnet och på skärmar finns det en status på 0/1 inom orderhantering. För handlarens slutkund är frågan: ”Kom mitt paket fram eller inte?”
I den verkliga världen måste programvaran ta hänsyn till hundratals nivåer av fysisk detaljrikedom som påverkar algoritmiska slutsatser. Koden kan vara perfekt, men handlingar i den verkliga världen som ligger utanför programvarans kontroll tillför ett lager av komplexitet för fysisk SaaS.
Togs beställningen emot av anläggningen i tid? Plockade operatören rätt produkt från hyllan? Styr programvaran dem till rätt storlek på kartong för att välja den optimala och mest kostnadseffektiva transportören? Levererades produkten i tid och som förväntat, eller försvann, skadades eller försenades paketet under transporten?
I alla dessa scenarier måste programvaran som driver orderhanteringsprocessen utföra en handling som sker på plats för att skapa bästa möjliga resultat.
Den unika utmaningen med programvara för orderhantering
Programvarusystem som driver både digitala och fysiska produkter drabbas av fel. Men i ett fysiskt system kan ett fel leda till verkliga problem, såsom felplockade varor, försenade lastbilar eller arbetare som inte har något att göra.
Därför kräver logistikprogramvara tre kritiska komponenter: noggrannhet, kompatibilitet och effektivitet. Annars blir lagernivåerna felaktiga, plattformarna kan inte kommunicera med varandra, beställningarna försenas och alla blir frustrerade.
Hela ekosystemet är beroende av korrekta och tillförlitliga data. Om dessa data inte tillhandahålls eller om ett fel uppstår i beräkningarna kanske det önskade resultatet – effektiv och tillförlitlig orderhantering – inte uppnås.
Allt detta bygger på att systemen kommunicerar med varandra – särskilt viktigt inom e-handel med dess många kontaktpunkter och marknadsplatser. När data finns isolerade i silor och andra tekniska detaljhandelssystem inte kan kommunicera effektivt förstår handlarna inte vad som händer. Därför kan e-handel i toppklass inte uppnås utan programvara i toppklass.
Utöver datanoggrannhet och plattformskompatibilitet måste systemet optimeras. Om en handlare till exempel skickar en beställning till en mindre lämplig anläggning måste den transporteras längre och snabbare för att nå kunden, vilket ökar kostnaden. Marginalerna är små för handlaren och lageroperatören, så varje optimering spelar roll. För slutkunden är varje insats för att sömlöst leverera en produkt efter köpet avgörande.
Att bygga programvara som driver fysisk verksamhet
Den första kritiska delen i att bygga programvara för orderhantering i den fysiska världen är en djup förståelse för kunden. Vilken verksamhet bedriver de? Vilka produktkrav har de? Vilka data de samlar in, vilka analyser de utför och vilka åtgärder programvaran måste vidta beror på att man förstår och löser deras slutkunders behov.
För att effektivt bygga programvara för den verkliga världen krävs erfarenhet. På Flowspace får vi kunskap genom att involvera ingenjörer tillsammans med våra kunder – direkt på lagergolvet – för att se hur operatörerna utför en åtgärd manuellt, föreslå en idé och iterera därifrån.
Den andra aspekten av att bygga programvara för att hantera order och leveranser i den fysiska världen är data. Samla in så mycket realtidsdata med så hög detaljrikedom som möjligt. Även om den inte används omedelbart kan denna rika informationskälla vara användbar veckor, månader eller år senare för att driva analysen eller optimeringen av en ny algoritm eller process. Datalagring är billigt, och du kanske inte kan komplettera med de data som saknas längre fram.
Slutligen bör du experimentera och iterera. Ofta fungerar en idé som verkar rimlig i teorin helt enkelt inte i verkligheten. Min tidiga erfarenhet av lageroperatörens reaktion på mitt programvarugränssnitt bevisar detta.
Framtiden för SaaS inom verksamhetsdrift
Verkligheten i den fysiska världen är att den existerar. Många teknikgrundare vill åstadkomma förändring och argumenterar för en vackrare lösning, ett vackrare ekosystem eller ett bättre arbetssätt. Det är det fantastiska med teknik – det byggs alltid något större, bättre och kraftfullare.
Men en annan aspekt av den fysiska världen är att vissa saker förändras långsamt, så försök hitta en balans mellan att bygga lösningar som agerar utifrån det som finns och det som i slutändan är möjligt.
Det finns en möjlighet att samordna och optimera fysiska system med hjälp av programvara. Programvaruapplikationer kan modellera optimala scenarier innan arbetet utförs i den verkliga världen. Genom att samla in så mycket omfattande realtidsdata som möjligt blir systemen intelligentare och mer kapabla. Att säkerställa att alla plattformar kan samverka driver en förstklassig implementering.
Och eftersom allt detta möjliggör handling i den verkliga världen finns det en extra glädje i att veta att arbetet i slutändan kommer att göra någons liv enklare, bättre eller mer njutbart.
Vilka lärdomar har du dragit av att bygga programvaruprodukter för den verkliga världen? Dela med dig i kommentarerna nedan och gå med i The CTO Clubs nyhetsbrev för fler branschnyheter och diskussioner.
