.svg)
Vad katastrofplanen oftast missar
Återställningsplanering följer företagets inventarielista. Servrar, databaser, applikationer och nätverkslänkar finns med på listan, var och en med en ägare och ett återställningsmål. Integrationer hamnar sällan på den listan, eftersom ingen har köpt dem som en enskild produkt.
En punkt-till-punkt-anslutning mellan ett affärssystem och ett lagersystem är ofta ett skript på en server eller ett schemalagt jobb i ett system som ingen har det fulla ansvaret för. Det saknar licens, leverantör och ofta även dokumentation. När katastrofplanen skrevs var den inte tillräckligt synlig för att inkluderas.
Luckan visar sig genom fyra frågor som ingen kan besvara under en incident:
- Vad var under överföring: vilka ordrar, leveranser eller produktionsinstruktioner som hade lämnat ett system men inte anlänt till det andra när anslutningen bröts
- Om något gick förlorat: om dessa poster ligger i kö och väntar, eller om de helt enkelt är borta
- Vem startar om den: vilket team som äger anslutningen, till skillnad från att äga de två systemen i vardera ände
- I vilken ordning ska omstart ske: om affärssystemet måste vara igång innan lagersystemets flöde återupptas, eller tvärtom
Var och en av dessa frågor kan besvaras i förväg. Ingen av dem går att besvara under ett avbrott om det inte finns nedskrivet, vilket är anledningen till att den första timmen av en integrationsincident oftast går åt till att förstå vad som hänt snarare än att återställa det.
Varför märks inte integrationsfel?
En trasig server märks direkt. Användare kan inte logga in, instrumentpaneler lyser rött och någon larmas inom några minuter. Ett integrationsfel är tystare, eftersom alla system som den kopplar samman fortfarande körs som vanligt.
Webbutiken tar fortfarande emot ordrar. Affärssystemet visar fortfarande gårdagens lagersaldo. Lagret plockar fortfarande det de blev tillsagda att plocka för en timme sedan. Ingenting är trasigt ur något enskilt systems perspektiv, och ingenting kommer att vara det förrän datagapet blir tillräckligt stort för att någon ska märka det.
Det är därför integrationsfel oftast rapporteras av kunder snarare än av övervakningssystem. En köpare frågar var deras order är, och någon upptäcker att orderflödet stannade klockan 02:00. Att upptäcka detta tidigare är uppgiften för övervakning och loggning, vilket är en annan disciplin än att återställa systemet när felet väl är känt.
Vad en timmes driftstopp i integrationen kostar
Kostnaden för ett integrationsavbrott är inte proportionell mot dess längd. Den är proportionell mot hur mycket verksamheten är beroende av flödet och hur länge felet förblir oupptäckt:
- En produktionslinje som väntar på arbete: ett MES-system utan nya order eftersom ERP-kopplingen ligger nere, och ett skift som får betalt medan de väntar
- Order som tas emot för lager som inte finns: en butik som säljer i fyra timmar baserat på den senaste siffran den tog emot
- Leveranser som aldrig når transportören: leveransinstruktioner som ligger i kö i ett system ingen övervakar, och som upptäcks nästa morgon
- Dubbletter efter omstart: ett flöde som startas om utan att veta vad som redan gått igenom, vilket skapar en kopia av varje order som fastnade i glappet
- Avstämning som tar dagar: ekonomiavdelningen som jämför två system manuellt för att hitta vad som flyttats och vad som inte gjort det
Det fjärde alternativet är den dyra överraskningen. Att starta om en anslutning är enkelt. Att starta om den utan att duplicera eller missa det som var under bearbetning kräver att man vet exakt var det stannade, och de flesta punkt-till-punkt-anslutningar loggar inte det.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
