Modernisera ett 12 år gammalt lagersystem utan att stoppa lastbilarna

Den farligaste programvaran i ett litet företag är den som fungerar. Inte det buggiga verktyget som alla klagar på — det byts ut till slut. Den farliga är det tolv år gamla systemet som ingen älskar men alla är beroende av, det som startar från en beige låda i hörnet och har drivit lagret sedan innan halva teamet anställdes. Det fungerar. Tills den dag det nästan inte gör det, och alla inser på en gång att hela verksamheten balanserar ovanpå det.

Det här är historien om ett sådant system och hur vi bytte ut det. Kunden är en regional grossist — några tusen artiklar, ett enda lager, omkring trettio anställda på golvet och kontoret. Vi har anonymiserat dem och rundat av siffrorna, men projektets form är precis som det gick till. Om du sitter på ett åldrande system du är rädd att röra, är det här ungefär hur en vettig modernisering ser ut inifrån.

Det finns ingen heroisk omskrivning i den här historien, ingen helg där vi slog om en strömbrytare och allt var nytt. Hela poängen — det som fick det att fungera — är att inget dramatiskt hände. Lastbilarna fortsatte att lastas. Lagret märkte knappt att golvet flyttade sig under det. Det är målet med arbete på äldre system, och det är värt att förstå varför.

Situationen: ett system som hölls samman av en persons minne

Lagret drevs på ett skräddarsytt system byggt runt 2013 av en utvecklare som sedan länge gått vidare. Det skötte kärnuppgiften — höll koll på lager, skrev ut plocklistor, skickade ut order genom dörren — och en vanlig dag gjorde det det bra. Problemet var egentligen inte programvaran. Problemet var allt som hade vuxit fram runt programvaran för att hålla den användbar.

Under ett decennium hade teamet tyst byggt ett skuggsystem av silvertejp: ett kalkylblad för lagersaldona som programvaran fick fel, ett andra kalkylblad som stämde av det första mot verkligheten, en WhatsApp-grupp där lagerchefen flaggade artiklar som systemet inte kunde representera, och en utskriven pärm med kringgåenden som nyanställda fick lära sig utantill. Inget av detta var nedskrivet på ett ställe. Det levde i huvudet på driftchefen — en lugn kvinna i femtioårsåldern som varit där i fjorton år och funktionellt var dokumentationen.

När ägaren först ringde oss var det inte på grund av en krasch. Det var för att hon hade meddelat att hon ville gå i pension om två år, och han hade räknat och insett att den dag hon slutade skulle en betydande del av hur lagret faktiskt fungerade gå ut genom dörren med henne. Det är en vanligare utlösare för modernisering än något tekniskt fel: inte att systemet går sönder, utan insikten att människorna som lappar ihop det inte finns kvar för evigt.

Symtomen alla hade slutat lägga märke till

När vi tillbringade våra första två dagar med att bara se lagret arbeta fanns det gamla systemets kostnader överallt — men de hade blivit så normala att ingen längre flaggade dem som problem. Lagersiffror litade man på att de var fel med en förutsägbar marginal, så varje stor order fick en manuell fysisk kontroll 'för säkerhets skull'. Nyanställda tog veckor på sig att bli användbara eftersom så mycket av jobbet var oskriven folklore. Och systemet kördes på ett operativsystem så gammalt att det inte längre kunde uppdateras, på ett nätverk som ägaren privat visste var en säkerhetsincident som väntade på att hända.

• Lagernoggrannheten låg runt 80 %, så personalen dubbelkollade saldon för hand på allt viktigt — timmar om dagen, i det tysta.
• Plocklistans logik klarade inte lagrets nuvarande layout, så plockarna gick en rutt som pärmen sa, inte skärmen.
• Lageravstämningen vid månadens slut tog två personer större delen av tre dagar.
• Bara en maskin kunde köra administrationsdelen av programvaran, och om den dog hade ingen en tydlig plan.
• Inget var kopplat till onlinebeställningskanalen som företaget lagt till 2019 — de ordern skrevs in på nytt för hand.

Vad vi medvetet inte gjorde

Det självklara draget — det som många leverantörer skulle ha pitchat — är att köpa en stor färdig lagerhanteringsplattform, migrera allt över en helg och stänga av det gamla systemet på måndag morgon. Vi har sett det tillvägagångssättet gå fel tillräckligt många gånger för att inte föreslå det för ett företag som det här. En smällstart förutsätter att du förstår det gamla systemet fullständigt. Med ett decennium av odokumenterade kringgåenden gjorde ingen det — inte ens de som körde det.

Det andra frestande draget är en fullständig skräddarsydd omskrivning från grunden: ta allt det gamla systemet gör, bygg om det rent, leverera det nya. Det låter ansvarsfullt och är ett klassiskt sätt att bränna ett år och en stor budget medan verksamheten väntar, fastfrusen, på en ersättare som hela tiden glider iväg. Problemet är att en omskrivning måste återskapa varje egenhet innan den kan lanseras — inklusive de egenheter som ingen minns är bärande förrän de saknas.

Så vi gjorde varken eller. Vi behandlade det gamla systemet inte som något att riva, utan som något att omge och långsamt ersätta — en förmåga i taget, med det gamla systemet fortfarande igång under som ett skyddsnät hela vägen. Oglamoröst. Också den enda versionen av detta som pålitligt fungerar.

Tillvägagångssättet: strypa det gamla systemet, inte spränga det

Det finns ett väletablerat namn för det här mönstret bland utvecklare — 'stryparmetoden', uppkallad efter en ranka som växer runt ett träd tills den kan stå på egen hand och originalet tyst försvinner. Du ersätter inte det gamla systemet i ett enda drag. Du bygger nya delar runt det, dirigerar verkligt arbete till dem en i taget och låter det gamla systemet krympa tills det som återstår är litet nog att stänga av utan att någon håller andan.

För det här lagret innebar det att vi i förväg kom överens om en sekvens: vilken förmåga vi skulle skala av först, vilken vi skulle spara till sist och — avgörande — en regel att i varje skede, om den nya delen betedde sig illa, kunde vi falla rakt tillbaka till det gamla sättet samma dag. Inget steg fick vara en punkt utan återvändo förrän allra sist. Just den regeln lät ägaren sova, och lät lagerpersonalen lita på projektet i stället för att spjärna emot det.

1. 1
   Kartlägg vad systemet faktiskt gör

   Tre veckor av att skugga golvet och kontoret för att dokumentera det verkliga arbetsflödet — inklusive varje kalkylblad och pärmkringgående. Vi skrev ner systemet som fanns, inte det som den ursprungliga specifikationen beskrev.
2. 2
   Städa datan innan du flyttar den

   Vi genomförde en fullständig fysisk lagerinventering och rensade produktdatabasen mot den. Att migrera smutsig data in i ett nytt system ger dig bara ett snabbare fel svar — så detta kom innan någon ny programvara rörde datan.
3. 3
   Ersätt den mest smärtsamma delen först

   Vi byggde den nya modulen för lagerspårning och -räkning, körde den parallellt med den gamla, och litade på den först när siffrorna matchade verkligheten i en hel månad.
4. 4
   Koppla in kanalerna som det gamla systemet ignorerade

   Därefter kopplade vi onlinebeställningskanalen direkt till den nya lagerdatan, och dödade den manuella ominmatningen som tyst hade funnits sedan 2019.
5. 5
   Skala av resten, pensionera sedan den gamla kärnan

   Plockning, rapportering och avstämning flyttades över en i taget. När nästan inget verkligt kördes på det gamla systemet stängde vi äntligen av det — en icke-händelse vid det laget.

Delarna som var genuint svåra

Det vore oärligt att framställa detta som smidigt. Det tekniska arbetet var den lätta delen. De svåra delarna var mänskliga och procedurmässiga, och de är samma svåra delar i nästan varje projekt med äldre system.

Den odokumenterade regeln som bröt en funktion

Två veckor in i att köra den nya lagermodulen parallellt drev siffrorna isär för en produktkategori och vi kunde inte se varför. Efter en dags grävande nämnde driftchefen, nästan i förbifarten, att vissa bulkartiklar räknades per pall, inte per styck, och att det gamla systemet hade en dold omräkning inbyggd som ingen hade dokumenterat på ett decennium. Det fanns inte i någon specifikation. Det levde bara i hennes huvud och i pärmen. Vi hade aldrig hittat det bara från koden — bara från att köra båda systemen sida vid sida och fråga varför de var oense. Det är hela argumentet för parallellkörning i en anekdot.

Vinna över golvet

Lagerpersonalen hade överlevt mer än en välmenande 'förbättring' som gjort deras dag sämre, så de mötte projektet med rimlig misstänksamhet. Vi bekämpade det inte med en presentation. Vi valde ut plockaren som klagade högst, satt med honom en förmiddag och byggde om plockskärmen runt hur han faktiskt gick på golvet. När han började försvara det nya systemet i fikarummet följde resten efter. I projekt med äldre system blir den tuffaste kritikern, vunnen över, din bästa förespråkare — och det kan du inte köpa med ett PM.

Resultaten, ett år senare

Vi är försiktiga med blanka före-och-efter-siffror, eftersom varje företag mäter olika och dina kommer att variera. Så behandla dessa som ärliga, avrundade värden från ett projekt, avsedda att visa avkastningens form snarare än ett löfte. Rubriken handlar mindre om något enskilt mått och mer om vad som slutade vara skrämmande.

Siffran som ägaren brydde sig mest om fanns inte i något diagram. Den var att när driftchefen verkligen gick i pension — några månader före schemat, som det visade sig — vacklade lagret inte ens. Kunskapen som förut levde i hennes huvud levde nu i ett system som vem som helst kunde tränas på inom dagar. Den ursprungliga anledningen till hela projektet var tyst och fullständigt löst.

Om du sitter på ett system som det här

De flesta ägare med ett åldrande kärnsystem känner samma två saker på en gång: det är riskabelt att behålla och skräckinjagande att byta ut. Båda är sanna. Misstaget är att låta den andra rädslan vinna, för risken med det gamla systemet står inte stilla — den växer tyst varje år, allt eftersom människorna som förstår det kommer närmare att sluta och plattformen det körs på driver längre bort från support.

Du behöver inte välja mellan 'låt det vara och be' och 'satsa företaget på en stor omskrivning'. Mellanvägen — omge det, ersätt det en bit i taget, behåll det gamla som nät tills det nya förtjänat förtroende — är långsammare och långt mindre heroisk. Det är också den version som inte stoppar lastbilarna. Om det finns en sak att ta med från hela den här historien, så är det den.

Vanliga frågor