Varför IT-organisationer behöver lägga mer fokus på flaskhalsar

Detta är del 1 av 2 om flaskhalsar hos IT-organiationer. Denna första del tar upp varför IT-organisationer bör lägga mer fokus på att identifiera och hantera dem. Del 2 tar upp strategier om hur man kan gå tillväga för att hantera dem.

Intern effektivitet ligger högt på varje organisations agenda. Många metoder och ramverk används och vissa effekter brukar kunna skönjas men bestående effekter är svåra att etablera.

I forskningen kring ”theory of constraints” av Eli Goldratt konstateras dock att alla försök att effektivisera eller förbättra verksamheten är meningslösa om de inte är riktade mot flaskhalsar i produktionen eller flödet. Enkelt kan det beskrivas som den svagaste länken, åtgärdar vi inte den så blir hela kedjan dålig. I Eli Goldratts värld så existerar varje organisation endast för att ta gods, varor och produkter och förädla detta för att därefter distribuera det vidare till nästa organisation/kund i kedjan.

Vad är en flaskhals?

Enligt wiktionary är definitionen av en flaskhals: ”en kritisk del i ett flöde eller system som utgör hinder för den normala utvecklingen; den svagaste länken i en kedja”.

En flaskhals är alltså ett fenomen där prestanda eller kapacitet för ett helt system är begränsat av en enstaka eller mindre antal komponenter nödvändiga för processens färdigställande.

Hur ser då flaskhalsar ut i en typisk IT-organisation? Man kan säga att det finns två typer av flaskhalsar. Dels tekniska flaskhalsar. Någon specifik maskin- eller programvara som utför någon given men kritisk uppgift. Och med kritisk här menar vi egentligen bara kritisk för flödet den ingår som en del av.

Det kan vara en singel ftp-server eller en hårdvara som hanterar överföringar etc. I vanliga fall löser vi hårdvarubegränsningar med redundans med utgångspunkt från att undvika ”single-point-of-failures”.

Bara häromdagen satt jag med en organisation som inte kunde fatta go-nogo beslut om en release eftersom huvudutvecklaren satt på ett flygplan och ingen vågade fatta beslut utan honom.

Varför blir så ofta personberoende?

Några vanliga förklaringar kan vara:

• IT-organisationer söker och utvecklar specialistkompetens. Specialisten blir per definition en flaskhals, annars skulle hen vara en generalist i organisationer.
• För att veta vem som gör vad lägger vi mycket kraft och tid på att utveckla tydliga roller och ansvar  för respektive uppgift dvs. inte för helheten, den är oftast för komplex.
• Organisationen delas upp efter kompetens men leveranser kräver korsfunktionella samarbeten för att kunna ske. Detta är egentligen den moderna motsvarigheten till Fords löpande band.
• Verksamheten (och därmed de anställda) värderas utifrån deras beläggning i första hand och inte utifrån organisationens ”throughput”-förmåga. Gärna understött av ett budgetstystem som baserar sig på samma principer.
• Bonus- och belöningssystem implementeras som inte i första hand främjar samarbete med andra funktioner utan istället suboptimering på den egna funktionens resultat.
• Ett överdrivet fokus på standardisering för att säkra låga omkostnader och IT-säkerhet gör att allt som inte passar ”mallen” blir svårt att hantera.
• Slutligen så finns också den tråkiga men oundvikliga effekten att personal för att säkra sin anställning och löneutveckling gärna gör sig oumbärliga på olika sätt med hjälp av ”unik kompetens” eller liknande.

Vilka effekter kan vi vänta oss av flaskhalsar?

Det uppenbara svaret är långa leveranstider, personberoende, svagheter i leveranskapacitet, stopp i produktion, missnöjda kunder/mottagare av leveranser etc. Det finns också följdeffekter i termer av missnöjd personal, interna frustrationer och naturligtvis ”blame game”. Inom ITIL känd som den icke officiella processen ”Scapegoat Management”.

Men mer konkret så uppstår också ett antal osynliga problem. Alla resurser som befinner sig efter en flaskhals får långa ställtider, dålig beläggning eller ett ojämnt flöde. Åtgärdar vi flaskhals så återkommer ändå bara problemet i flaskhals B och sen C och så vidare.

Resurserna som befinner sig mellan tenderar också att använda den lediga tiden till att hitta på nya saker som skapar nya bekymmer alternativt helt enkelt bara är ett resursslöseri med icke efterfrågade aktiviteter.

Några exempel från verkligheten

Projektgruppen lyckas inte få till ett möte förrän om 4 veckor för alla resurser är uppbokade på annat.

Releasen kan inte produktionssättas för den enda nätverksteknikern som kan hantera den avancerade brandväggsöppningen är inte på plats denna vecka, hen är på kurs/eller annan valfri plats.

Testmiljön kan inte uppdateras den här veckan för att vi väntar fortfarande på svar från leverantören om vad som är den rekommenderade inställningen.

Driftsteknikern (valfritt namn) kan inte lägga tid på uppdateringen av firmware på rack-controllers för han är upptagen med att lösa en större incident som uppstått på produktionsservrarna för den centrala ERP-lösningen.

I del 2 tittar vi närmare på strategier för att hantera och bygga bort flaskhalsar.

Resurserna som befinner sig mellan tenderar också att använda den lediga tiden till att hitta på nya saker som skapar nya bekymmer alternativt helt enkelt bara är ett resursslöseri med icke efterfrågade aktiviteter.