Syftet med att ta steget till automatiserade arbetsflöden à la devops eller en robotiserad processautomatisering där mjukvara tar över ruljangsen är att dra ner på rutinarbete och på så sätt frigöra kvalificerade medarbetare så den kan ta sig an mer avancerade uppgifter.

Men det är inte alltid som det scenariot uppfylls. Vår amerikanska systertidning CIO.com har talat med it-proffs om deras misstag och fått fram ett antal tips för att inte göra om dem. Här är några av dem.

1. Se till att alla blir delaktiga i automatiseringen

Benjamin Willenbring, mjukvaruutvecklare på Autodesk, tyckte det lät toppen när företaget skulle införa automatiserad testning av mjukvara 2015. Men när testerna väl nådde produktionen höll de inte vad de lovat.

Ett av de största problemen var att de som byggt de automatiserade testerna var de enda som förstod hur de fungerade – och de satt inte ens i samma stad som utvecklingsavdelningen.

– En av svårigheterna med testramverket var att det inte gav riktigt tydlig feedback när något var fel, säger Benjamin Willenbring.

– Så om något misslyckades var det första du gjorde att kontakta testledaren på Slack för att fråga varför det misslyckades. Och då körde han testet igen manuellt – en speciell version av ramverket så att han kunde se resultaten – och sedan kommunicerade han tillbaka vad som hände.

Bristen på dokumentation gjorde de automatiska testerna oöverskådliga för Willenbrings team. Det ledde till att de inte kunde förstå resultaten och de förlorade förtroendet för testerna och teamet som skapade dem.

Först när utvecklingsavdelningen på Autodesk fick en ny chef som slog fast att ”kvalitet är allas jobb” – även testautomatisering så hamnade det hela på rätt köl igen.

Nu kan utvecklingsavdelningen skräddarsy tester efter sina behov och integrera processen i sin vardag.

– Man måste ha en nolltoleranspolicy mot ”det är inte mitt jobb”-attityd, säger Benjamin Willenbring.

2. Var förberedd på komplexitet

Tripwire arbetar med säkerhetsautomatisering och när en av deras stora kunder i finansbranschen började använda en av deras lösningar reagerade de. För i stället för att licensanvändningen snabbt ökade som den skulle när lösningen rullade ut så hände det ingenting.

Det visade sig då att lösningen höll på att rullas ut på en mängd affärsområden där alla hade sina egna skräddarsydda mjukvarukomponenter.

– De fanns över 30 applikationer som de försökte få in, säger Irfahn Khimji, Tripwires landschef i Kanada.

– Att justera sin pipeline för att hantera alla dessa applikationer bromsade verkligen automatiseringsprocessen, eftersom det inte bara handlade om ett klick för att distribuera.

Det finns ingen enkel lösning för att lösa det problemet men det gäller att vara medveten om att när fler komponenter ska in i den automatiserade processen så ökar komplexiteteten i handpåläggningen som krävs för att koppla ihop de olika komponenterna exponentiellt. I sin tur gör det att övergången till en automatiserad process kräver både mer pengar och mer resurser.

Om mjukvarukomponenterna dessutom är en mix av egenutvecklat och tredjepartsutvecklade ökar komplexiteten ytterligare.

3. Se upp för den svarta lådan

Finansbranschen har varit snabb med att använda sig av robotiserad automatisering och chattbottar men Muddis Sudhakar som är vd på mjukvaruföretaget Aisera varnar för ett scenario som han ofta sett just där. Nämligen att processerna är utformade som en enda, monolitisk enhet av funktionalitet som blir en ”black box” där det är svårt att reda ut de interna processerna när man ska felsöka.

– I en monolitisk struktur kommer kunden att kontrollera status på sitt konto, och om han vill ta ut pengarna och flytta dem kommer det att ske i ett steg, säger han.

– Om något går fel, och det inte finns någon granskad övervakning av det steget är det enda sättet att få tillbaka pengarna om det kraschar att ringa kundtjänst – kanske måste du rentav gå till banken personligen för att få dem.

Enligt Muddis Sudhakar är den typen av design ofta ett tecken på att det rör sig om ett tidigt försök med automatisering. Ett sådant projekt kan ge goda resultat så länge allt går enligt plan. Men när det inte gör det måste organisationer i allmänhet gå tillbaka till skrivbordet och dela upp de ”svarta lådorna”.

– Dela upp varje process i byggstenar där varje byggsten är möjlig att granska och övervaka.

4. Glöm inte säkerheten

En sak som man inte alltid pratar om är att många automatiserade processer för kontinuerlig integration och kontinuerlig leverans är en del av skugg-it som ofta rundat olika säkerhetskrav.

Irfahn Khimji förklarar det med att ”utvecklare vill utveckla” – de gillar helt enkelt inte att bromsas utan vill vidare till nästa iteration så när de stöter på formella och noggranna säkerhetsprocesser så vill de gärna undvika hindret.

Det innebär inte nödvändigtvis att de automatiserade processen är osäker men det kan vara bra att kolla vad det kan ha kompromissats med på vägen för att nå ökad effektivitet.

Dessutom så utgör den automatiserade processen ytterligare en möjlig attackyta.

5. Slarva inte med kompetensen

När något hajpas är det vanligt med missförstånd. Ajeet Dhaliwal, huvudutvecklare på, och grundare av, Tesults, anser att många organisationer har en bild av automatiserad testning som skiljer sig mycket från bästa praxis.

Det handlar framför allt om mindre organisationer där cheferna inte har en teknisk bakgrund. Eftersom de förstår manuella tester tror de att automatiserade tester bara är en version av deras manuella tester som kan ske utan mänsklig intervention.

Det leder i sin tur till att de uppmuntrar traditionella kvalitetssäkringstestare som utför manuella tester men inte har någon bakgrund i mjukvaruutveckling att automatisera testerna.

– De som utvecklar automatiserade tester måste också vara mjukvaruingenjörer. Det är bra att ha några juniorutvecklare involverade, men de här företagen behöver åtminstone några erfarna utvecklare som leder arbetet och de har inte det, säger Ajeet Dhaliwal.

Läs också: Vad är CI och CD? Så funkar det ständiga flödet
Fyra tecken på att du har en dysfunktionell it-kultur – och hur du fixar det