2014-05-23
Vid flera tillfällen under mina år inom IT service managementområdet har jag blivit ombedd att sätta upp config hos kund. Varenda gång har det visat sig att föreställningen hos kunden varit att vi ska populera en databas.
Vid ett uppdrag var fantasierna om configarbetet, hos personalen så svåra att överkomma att det tog mig åtta månader att få SAP kodarna att våga berätta hur deras system var uppbyggt. De hade närt föreställningen att de skulle bli tvungna att handmata in varje kodändring i något metasystem och därför bestämt sig för att tiga som muren eller om det blev tvunget obstruera genom att ge disinformation. Ok, en del av förseningen berodde nog på att jag hade svårt att förstå deras dilemma. För mig är ju config en process. Har jag tappat dig nu, kära läsare?
Config är i allra högsta grad en process och noggrannhet är kännetecknet. En sån process behöver ett strikt arbetsflöde med regler,som accepteras och efterlevs av alla inblandade aktörer. Processen omfattar den strategiska subprocessen med aktiviteter för hur arbetet ska struktureras, vilka uppgifter som ska ingå i definitionen av ett konfigurationsobjekt ( CI) Att identifiera innehåll betyder att vi måste utreda vilka som är användare av informationen och det omfattar identifiering av kravställare och upprättande av regelverk. Identifiering av vem som ska vara uppgiftslämnare; funktionsbaserat- och avtalat genom OLA och/eller kontrakt) . Vidare måste namnstandard sättas och upprätthållas. Sällan har jag funnit sådana flöden i de utvärderande uppdrag jag också anlitats för att göra.
Till detta kommer den taktiska subprocessen som omfattar uppsättning av struktur. Genom åren har jag lärt mig att föreställnigen om en databas är naiv. Den taktiska processen, som inte är ett engångsprojekt utan måste sättas upp som ett repetitivt flöde ( världen förändras och config managern måste ha ett vedertaget sätt och mandat att ständigt utmana nya källor) omfattar identifiering av originalkälla för information samt införande av den namnstandarden och innehåll, som kommer av den strategiska subprocessen. Förvaltning av configmodellen kräver förståelse för att modellen innehåller unik och intrångskänslig information vilket i sin tur kräver att ingående databaser risk- och kontinuitetshanteras. En av de roligaste och svåraste aktiviteterna i detta flöde handlar om identifiering av beroendekedjor och beslut om vilka källor som är master och vilka som är slave. Många källor byter information med varandra och configprocessen har en viktig uppgift att se till att data inte kan förvrängas utan behåller sin integritet genom hela beroendekedjan. Regler för att tillse spårbarhet på förändringar och datats okränkbarhet blir viktigt att reda ut med säkerhetsavdelningar och operativt ansvariga tjänste- och komponentägare.
Nu- och först nu är vi framme vid det operativa flödet. Där blir configmanagern en arbetsledare med ansvar att kontrollera andras aktiviteter. De som utför aktiviteter i det här flödet är tjänste- och komponentägare och även supportpersonal. Hur ska de få använda systemet? Hur ska change driva och reglera ändringar? Hur ska rättningar göras och av vem, är aktiviteter som måste regleras och ledas. Det är mycket lite i config som handlar om att populera en databas.
Vem skulle vara mest lämpad för detta arbete då? Jag har alltid hävdat att IT-avdelningar har alldeles för få bibliotikarier anställda. Där har ni de verkliga specialisterna på att systematisera information. Att ha ett genuint intresse för systematisering av data och förstå riskerna i manuell hantering och beroendekedjors påverkan, är av yttersta vikt.