Moderniseringsplanen är klar, budgeten preliminärt godkänd. Leverantören ställer sin första fråga: ”Var finns systemdokumentationen?” Det visar sig att det finns en wiki som senast uppdaterades för fem år sedan, några diagram ”någonstans på nätverksdisken” och kod som får tjäna som sin egen dokumentation. Offerten växer med en tredjedel. För leverantören prissätter inte arbetet, utan osäkerheten.
Den här texten beskriver en praxis som lyfter bort den osäkerheten från bordet: innan någon rör koden i en gammal applikation återskapar man kunskapen om den. För inte så länge sedan innebar ett sådant steg veckor av analytikerarbete och få valde att ta det. I dag utför AI merparten av analysen på ett antal arbetsdagar. Och det ändrar ordningen i hela projektet.
Först kartan, sedan koden
Att modernisera ett system utan aktuell dokumentation påminner om att renovera en byggnad utan installationsritningar. Det går, men varje vägg man bilar upp är ett lotteri: kanske finns där inget, kanske ett rör som halva våningen hänger på. I applikationer är det röret ofta en integration med grossisten som bara kodens upphovsman kände till, eller en nattlig export som ekonomiavdelningen i tysthet förlitar sig på.
Därför är den rimliga ordningen den omvända mot den intuitiva. Man börjar inte med att skriva ny kod, inte ens med en offert. Man börjar med kartan.
Vad AI hämtar ur kod, databas och loggar
Moderna analysverktyg kan läsa tre sanningskällor om ett system: källkoden, databasstrukturen och loggarna från produktionsdriften. Ur korsningen av dem uppstår en systemkarta som omfattar fyra lager.
Det första är modulerna: vad systemet består av och vad varje del ansvarar för, beskrivet på ett språk som även personer utanför IT förstår. Det andra är dataflödena: var data kommer in, vad som händer med dem på vägen, var de hamnar. Det tredje är integrationerna, det vill säga alla ställen där applikationen talar med andra system: ekonomi, lager, butik, partner. Det är de som oftast brister vid förändringar.
Det fjärde lagret är det minst uppenbara: död kod. Logganalysen visar vilka funktioner som inte anropats på flera år och vilka tabeller ingen skrivit till sedan 2019. I äldre system utgör sådan barlast ofta en stor del av helheten. Varje rad som inte behöver flyttas är en verklig besparing i projektet.
Vad kartan ändrar i beslutet ”skriva om eller modernisera”
Om själva beslutet har vi skrivit separat, i texten om de fyra kriterierna: beslutsramverket. Systemkartan ger de kriterierna hårda data. Utan den bedöms den tekniska skulden på känsla och risken utifrån anekdoter. Med den syns det svart på vitt: vilka moduler som bär affärsvärde, vilka som är döda och var de integrationer sitter som höjer risken vid varje förändring.
Resultaten kan överraska åt båda hållen. Ibland visar sig systemet som ”måste skrivas om från grunden” vara friskt till tre fjärdedelar, och det räcker att byta ut två moduler. Ibland är det tvärtom: applikationen ser oskyldig ut, men kartan avslöjar ett dussintal odokumenterade kopplingar som gör en partiell modernisering dyrare än en omskrivning. I båda fallen fattas beslutet på data, inte på känslor. Och en leverantör som får en karta i stället för en gåta prissätter arbete i stället för risk.
Vår uppfattning är att framtagningen av kartan bör vara ett eget, första steg i moderniseringsavtalet, med egen leverans och eget godkännande. Även om du efter det steget bestämmer att någon annan gör moderniseringen, eller att den inte blir av alls, stannar dokumentationen i företaget och fortsätter att göra nytta.
Hur du verifierar det som AI har genererat
Automatiskt genererad dokumentation är inget orakel. Den måste kontrolleras. Den effektivaste metoden är enkel: en genomgång med den person som känner systemet bäst, ofta den enda sådana i företaget. Skillnaden mot det klassiska upplägget ligger i personens roll. Du ber hen inte att skriva ned sin kunskap, vilket ingen tycker om och vilket drar ut i månader. Du ber om en granskning av en färdig beskrivning, och att peka ut ”här stämmer det, här inte” går många gånger snabbare än att skriva från noll.
En god praxis är att gå igenom några av de viktigaste processerna från början till slut: order, faktura, reklamation. Om kartan korrekt beskriver de kritiska flödena och de stickprovskontrollerade detaljerna kan man lita på den i övriga områden. Det går att göra på en dag.
Vad AI inte kan återskapa
Här en ärlig reservation: koden säger vad systemet gör, men inte varför. Ett märkligt undantag i rabattberäkningen kan vara ett fel, men det kan också vara en affärsöverenskommelse från 2016 som fortfarande gäller för en stor kund. Det avgör ingen kodanalys. Affärsintentioner från ett decennium tillbaka återskapas genom intervjuer: korta samtal med människorna på försäljning, ekonomi och drift, förda med kartan i handen. Kartan visar vad man ska fråga om, men svaren har människan.
Ett separat ämne är applikationens omgivning: servrar, nätverk, säkerhetskopior. Om dokumentationen av det lagret har vi skrivit i texten om granskningen av infrastrukturdokumentationen.
På ESKOM AI genomför vi kartläggningssteget med ett team av specialiserade AI-agenter under överinseende av erfarna ingenjörer: analysen av ett typiskt företagssystem tar ett antal arbetsdagar, och resultatet är dokumentation som är begriplig för både ledning och tekniskt team. Om beslutet därefter blir modernisering fortsätter arbetet i en automatiserad mjukvaruutvecklingsprocess med en komplett uppsättning tester — enhetstester, integrationstester, E2E, UI samt säkerhets- och prestandatester.
Var du börjar hos dig
Välj ett system: det vars modernisering du skjutit upp längst eller det du är mest rädd för att röra. Beställ framtagningen av dess karta som ett fristående, litet steg innan du ber någon om en offert på ombyggnaden. Under en kostnadsfri konsultation ger vi råd om hur ett sådant steg planeras och vad du kan förvänta dig av det.
Boka en kostnadsfri konsultation via kontaktformuläret →