Modernisering av et 12 år gammelt lagersystem uten å stoppe lastebilene

Den farligste programvaren i en liten bedrift er den som virker. Ikke det buggy verktøyet alle klager på — det blir byttet ut til slutt. Den farlige er det tolv år gamle systemet ingen elsker, men alle er avhengige av, det som starter opp fra en beige boks i hjørnet og har drevet lageret siden før halve teamet ble ansatt. Det virker. Helt til den dagen det nesten ikke gjør det, og alle innser på én gang at hele virksomheten balanserer oppå det.

Dette er historien om et slikt system, og hvordan vi byttet det ut. Kunden er en regional grossist — et par tusen varelinjer, ett enkelt lager, rundt tretti ansatte på gulvet og kontoret. Vi har anonymisert dem og rundet av tallene, men formen på prosjektet er nøyaktig slik det skjedde. Hvis du sitter på et aldrende system du er redd for å røre, er dette omtrent hvordan en fornuftig modernisering ser ut innenfra.

Det finnes ingen heroisk omskriving i denne historien, ingen helg der vi vippet en bryter og alt var nytt. Hele poenget — det som fikk det til å virke — er at ingenting dramatisk skjedde. Lastebilene fortsatte å bli lastet. Lageret merket knapt at gulvet flyttet seg under det. Det er målet med arbeid på gamle systemer, og det er verdt å forstå hvorfor.

Situasjonen: et system holdt sammen av én persons hukommelse

Lageret kjørte på et skreddersydd system bygget rundt 2013 av en utvikler som for lengst hadde gått videre. Det gjorde kjerneoppgaven — holdt styr på lageret, skrev ut plukklister, sendte ordrer ut døra — og på en vanlig dag gjorde det det greit. Problemet var egentlig ikke programvaren. Problemet var alt som hadde vokst opp rundt programvaren for å holde den brukbar.

I løpet av et tiår hadde teamet stille bygget et skyggesystem av gaffateip: et regneark for lagertallene programvaren fikk feil, et annet regneark som avstemte det første mot virkeligheten, en WhatsApp-gruppe der lagersjefen flagget varer systemet ikke kunne representere, og en utskrevet perm med løsninger nyansatte måtte lære utenat. Ingenting av dette var skrevet ned på ett sted. Det levde i hodet til driftslederen — en rolig kvinne i femtiårene som hadde vært der i fjorten år og funksjonelt var dokumentasjonen.

Da eieren først ringte oss, var det ikke på grunn av en krasj. Det var fordi hun hadde annonsert at hun ville pensjonere seg om to år, og han hadde regnet på det og innsett at den dagen hun sluttet, ville en betydelig del av hvordan lageret faktisk fungerte gå ut døra med henne. Det er en mer vanlig utløser for modernisering enn noen teknisk svikt: ikke at systemet ryker, men erkjennelsen av at folkene som lapper på det ikke er her for alltid.

Symptomene alle hadde sluttet å legge merke til

Da vi brukte de første to dagene på bare å se lageret arbeide, var kostnadene ved det gamle systemet overalt — men de hadde blitt så normale at ingen lenger flagget dem som problemer. Lagertall stolte man på var feil med en forutsigbar margin, så hver store ordre fikk en manuell fysisk sjekk 'for sikkerhets skyld'. Nyansatte brukte uker på å bli nyttige fordi så mye av jobben var uskreven folklore. Og systemet kjørte på et operativsystem så gammelt at det ikke lenger kunne oppdateres, på et nettverk eieren privat visste var en sikkerhetshendelse som ventet på å skje.

• Lagernøyaktigheten lå rundt 80 %, så de ansatte dobbeltsjekket tall for hånd på alt viktig — timer om dagen, i det stille.
• Plukklistens logikk klarte ikke lagerets nåværende layout, så plukkerne gikk en rute permen sa, ikke skjermen.
• Lageravstemming ved månedsslutt tok to personer storparten av tre dager.
• Bare én maskin kunne kjøre administrasjonsdelen av programvaren, og hvis den døde, hadde ingen en klar plan.
• Ingenting var koblet til nettbestillingskanalen selskapet hadde lagt til i 2019 — de ordrene ble tastet inn igjen for hånd.

Hva vi bevisst ikke gjorde

Det åpenbare grepet — det mange leverandører ville pitchet — er å kjøpe en stor ferdig lagerstyringsplattform, migrere alt over en helg og slå av det gamle systemet mandag morgen. Vi har sett den tilnærmingen gå galt nok ganger til ikke å foreslå den for en bedrift som denne. En smell-omlegging forutsetter at du forstår det gamle systemet fullstendig. Med et tiår av udokumenterte løsninger gjorde ingen det — ikke engang de som kjørte det.

Det andre fristende grepet er en full skreddersydd omskriving fra bunnen: ta alt det gamle systemet gjør, bygg det rent på nytt, lever det nye. Det høres ansvarlig ut og er en klassisk måte å brenne av et år og et stort budsjett på mens virksomheten venter, fastfrosset, på en erstatning som stadig glipper. Problemet er at en omskriving må gjenskape hver særegenhet før den kan lanseres — inkludert særegenhetene ingen husker er bærende før de mangler.

Så vi gjorde ingen av delene. Vi behandlet det gamle systemet ikke som noe som skulle rives, men som noe som skulle omsluttes og sakte byttes ut — én evne om gangen, med det gamle systemet fortsatt i drift under som et sikkerhetsnett hele veien. Uglamorøst. Også den eneste versjonen av dette som pålitelig virker.

Tilnærmingen: kvel det gamle systemet, ikke spreng det

Det finnes et velkjent navn for dette mønsteret blant utviklere — 'kveler'-tilnærmingen, oppkalt etter en slyngplante som vokser rundt et tre til den kan stå på egne bein og originalen stille forsvinner. Du bytter ikke ut det gamle systemet i ett trekk. Du bygger nye deler rundt det, ruter ekte arbeid til dem én om gangen og lar det gamle systemet krympe til det som er igjen er lite nok til å slå av uten at noen holder pusten.

For dette lageret betydde det å bli enige på forhånd om en rekkefølge: hvilken evne vi ville skrelle av først, hvilken vi ville spare til sist og — avgjørende — en regel om at på hvert trinn, hvis den nye delen oppførte seg dårlig, kunne vi falle rett tilbake til den gamle måten samme dag. Ingen trinn fikk være et point of no return før helt til slutt. Nettopp den regelen lot eieren sove, og lot lagerpersonalet stole på prosjektet i stedet for å stritte imot det.

1. 1
   Kartlegg hva systemet faktisk gjør

   Tre uker med å skygge gulvet og kontoret for å dokumentere den virkelige arbeidsflyten — inkludert hvert regneark og hver perm-løsning. Vi skrev ned systemet som fantes, ikke det den opprinnelige spesifikasjonen beskrev.
2. 2
   Rydd i dataene før du flytter dem

   Vi gjennomførte en full fysisk lageropptelling og renset produktdatabasen mot den. Å migrere skitne data inn i et nytt system gir deg bare et raskere feil svar — så dette kom før noen ny programvare rørte dataene.
3. 3
   Bytt ut den mest smertefulle biten først

   Vi bygde den nye modulen for lagersporing og -telling, kjørte den parallelt med den gamle, og stolte først på den da tallene matchet virkeligheten en hel måned.
4. 4
   Koble til kanalene det gamle systemet ignorerte

   Deretter koblet vi nettbestillingskanalen direkte til de nye lagerdataene, og drepte den manuelle gjeninntastingen som stille hadde eksistert siden 2019.
5. 5
   Skrell av resten, og pensjoner så den gamle kjernen

   Plukking, rapportering og avstemming flyttet over én om gangen. Da nesten ingenting ekte kjørte på det gamle systemet, slo vi det endelig av — en ikke-hendelse på det tidspunktet.

Delene som var virkelig vanskelige

Det ville vært uærlig å fremstille dette som glatt. Det tekniske arbeidet var den enkle delen. De vanskelige delene var menneskelige og prosedyremessige, og det er de samme vanskelige delene i nesten ethvert prosjekt med gamle systemer.

Den udokumenterte regelen som brøt en funksjon

To uker inn i å kjøre den nye lagermodulen parallelt drev tallene fra hverandre for én produktkategori, og vi kunne ikke se hvorfor. Etter en dags graving nevnte driftslederen, nesten i forbifarten, at visse bulkvarer ble telt per pall, ikke per stykk, og at det gamle systemet hadde en skjult omregning bygget inn som ingen hadde dokumentert på et tiår. Den sto ikke i noen spesifikasjon. Den levde bare i hodet hennes og i permen. Vi ville aldri funnet den fra koden alene — bare fra å kjøre begge systemene side om side og spørre hvorfor de var uenige. Det er hele argumentet for parallellkjøring i én anekdote.

Å vinne over gulvet

Lagerpersonalet hadde overlevd mer enn én velmenende 'forbedring' som gjorde dagen deres verre, så de møtte prosjektet med rimelig mistenksomhet. Vi bekjempet det ikke med en presentasjon. Vi plukket ut plukkeren som klaget høyest, satt med ham en formiddag og bygde plukkeskjermen om rundt hvordan han faktisk gikk på gulvet. Da han begynte å forsvare det nye systemet i pauserommet, fulgte resten etter. I prosjekter med gamle systemer blir den tøffeste kritikeren, vunnet over, din beste talsmann — og det kan du ikke kjøpe med et notat.

Resultatene, ett år etter

Vi er forsiktige med blanke før-og-etter-tall, fordi hver bedrift måler ulikt og dine vil variere. Så behandle disse som ærlige, avrundede verdier fra ett prosjekt, ment å vise formen på avkastningen snarere enn et løfte. Overskriften handler mindre om noe enkelt mål og mer om hva som sluttet å være skummelt.

Tallet eieren brydde seg mest om sto ikke i noe diagram. Det var at da driftslederen faktisk pensjonerte seg — noen måneder før tiden, som det viste seg — vaklet ikke lageret engang. Kunnskapen som før levde i hodet hennes levde nå i et system hvem som helst kunne læres opp i på dager. Den opprinnelige grunnen til hele prosjektet var stille og fullstendig løst.

Hvis du sitter på et system som dette

De fleste eiere med et aldrende kjernesystem føler de samme to tingene på én gang: det er risikabelt å beholde, og det er skremmende å bytte ut. Begge er sanne. Feilen er å la den andre frykten vinne, for risikoen ved det gamle systemet står ikke stille — den vokser stille hvert år, etter hvert som folkene som forstår det kommer nærmere å slutte og plattformen det kjører på driver lenger vekk fra støtte.

Du trenger ikke velge mellom 'la det være og be' og 'sett bedriften på spill med en stor omskriving'. Mellomveien — omslutt det, bytt det ut én bit om gangen, behold det gamle som nett til det nye har gjort seg fortjent til tillit — er tregere og langt mindre heroisk. Det er også den versjonen som ikke stopper lastebilene. Hvis det er én ting å ta med fra hele denne historien, så er det den.

Vanlige spørsmål