Använda standard, varför och hur?
En sak jag blivit känd för att göra är att alltid sätta upplösningar baserat på standard. Man skulle kunna säga att användande av standard är omöjligt då alla är olika, att genom standardisering så förlorar företag sin konkurrensfördel.
Det är ganska lätt att förstå den mentaliteten då många av oss arbetat inom IT industrin under väldigt lång tid. För inte så länge sedan så betydde användningen av standard att anamma mjukvaruleverantörens strikta beskrivningar hur programmen skulle användas. På den tiden så utvecklades mjukvaran baserade på kundönskemålen och på den tiden var IT avdelningar. Ta. T.ex. Microsoft hade då den mesta kontakten med IT avdelningarna på de stora företagen i världen och i mindre utsträckning slutanvändare. IT avdelningarna begärde mer administrativ funktionalitet, t.ex. säkerhetsfunktionalitet och enklare administration. Mjukvaruleverantörerna var många gånger begränsade till att enbart få synpunkter och återkoppling av större IT avdelningar, det var inte slutanvändarna själva som återkopplade direkt.
De större IT avdelningarna behövde lösningar på hur man administrerar användare, grupper samt funktioner. UX var något som det inte investerades på samma sätt i vilket gjorde att applikationerna ofta inte uppfattades användarvänliga men IT avdelningarna var överlag nöjda. Systemen fungerade, de var enkla att administrera och de var stabila, vad mer behövdes egentligen?
Alla glada överallt, inte riktigt, användarna var inte imponerade och när IT avdelningarna fick kritik så försökte man hjälpa till och lösa problemen genom att anpassa systemen. Det kunde vara standard konfiguration man gjorde med t.ex. GPO i Windows eller genom anpassad utveckling i SharePoint. Det var både svårt och kostsamt att anpassa att ha flera varianter så ofta blev det en variant för alla användare. Alla användare hade Word ikonen obligatoriskt på start-menyn.
I slutändan blev det då två olika standarder på varandra, mjukvarutillverkarens och IT avdelningens. Det blev avårt att aministrera i långa loppet och uppgraderingar av mjukvarorna var svåra att göra, uppgraderingsprojekt tog lång tid.
Molnet innebar en ny era inom IT, jag skulle säga att mycket blev upp och ner, användarna fick direktkontakt med leverantörerna genom t.ex. UserVoice, twitter, återkoppling i applikationerna eller helt enkelt de senaste nyheterna via publika källor på internet. En två-vägs kommunikation uppstod mellan leverantörer och slutanvändare vilket ökade hastigheten på användarfunktionalitet, ofta till IT avdelningarna, juristers och säkerhetsexpeters förtret. Användarna utnyttjade de nya sätten att arbete utan hjälp från interna IT avdelningarna och de kunde göra saker enklare, snabbare och till lägre kostnad än förr – man skulle kunna säga att allt detta ledde till ”shadow IT”.
Det blir då viktigt med förståelsen kring varför shadow IT uppstår och jag påstår det är för att användarna tror det behövs. Shadow IT uppstår på grund av att IT avdelningarna är till synes som en leverantör än som en integrerad del av verksamheten. Shadow IT borde vara något som är inkorporerat inom IT avdelningarna och det tror jag enbart kan hända när det inte finns någon separation mellan IT och verksamhet, shadow IT är enbart IT. När IT avdelningarna förstår varför användarna behöver ny funktionalitet och när användarna förstår att IT kan hjälpa till med säkerhet, administration och applikationens livscykel så kan ett fördjupat samarbete uppstå. Vem är ansvarig att förändras? Det krävs två för att dansa tango så självklart gäller förändring för alla parter men jag tror nog ändå att IT avdelningarna behöver visa ett förändrat tankesätt. Det är t.ex. att gå från ”nej” till ”varför” och sedan öppna upp för diskussioner om lösningar och utmaningar. Alla ansvarar för slutresultatet men varje funktion primärt för sin del.
Det är här standard kan bli omdefinierad och med hjälp av allas synvinklar kan implementationen av mjukvara göras som tar med sig så många aspekter som möjligt in i lösningen. Att kombinera ett evergreen tankesätt och att hjälpa användarna med förståelse om mjukvarors livscykel för det möjligt för IT avdeningarna i sin tur få frågor som ”varför” och ”hur”. Hur kan en kombination av användarvändliga- samt administrationsvänliga lösningar uppstå? För mig så kokar det ner til att använda standard, med en ny definition kring dagens standard genom ett flöde av funktionalitet som begärts av tusentals användare i världen. För att göra detta behöver vi hjälpa till med hur vi kan hålla en hög hastighet utan att förlora den nödvändiga kontrollen som i verkligheten verksamheten och slutanvändarna även vill ha. Alla vill ha ny och bra funktionalitet men inte om det påverkar produktionen. Jag tror detta kan uppnås genom ett samarbete i hela organisationen. Alla behöver ”ge och ta” och IT avdelningarna behöver ändra sättet att arbeta men samtidigt behöver också användarna kunna ta emot och acceptera nya möjligheter som kan komma att förändra deras sätt att arbeta.
Accepterande och anammande av ständig förändring är något som IT branschen arbetat med under ett antal år och nu är tiden kommen för användare ute i verksamheten att också anamma ständig förändring, eller rättare sagt förhoppningsvis ständig förbättring. Genom att leverera mjukvara så nära standard som möjligt möjliggör vi smidigare och snabbare uppgraderingar samt leveranser av nya förbättrade funktioner. Anpassningar bör göras utanför mjukvaran självt med hjälp av API:er så man har möjligheten att den är så frikopplad som möjligt från applikationen, att använda ett mikrotjänsttänk i allt man gör. Detta möjliggör att applikationerna kan uppgraderas samt att det förenklar avvecklingen av anpassningarna när standardfunktionaliteten kan ta över de delarna. Se till att hålla anpassningarna till ett fåtal, håll nere kostnaderna för dessa anpassningar och enligt mig ersätt de så fort det går med standardfunktionalitet. Om det aldrig kan ersättas med standard? Då kanske man kan fundera på varför och alltid utvärdera om anpassningarna är värda kostnaderna.