Som ett brev på posten, eller åtminstone som en tidning, kom Pravda, förlåt Computer Sweden, med en liten artikel som illustrerar grunkvärde och mjukvaruekonomin.
Det är Accenture som gjort en liten undersökning hur mycket gamla system kostar.
Några citat från teknikstrategen Bob Suh:
Många företag vet hur många it-anställda de har, men vet inte vad de lägger tiden på.
Precis. Och läsare av denna blogg vet precis vad det beror på, nämligen att man heltokigt budgeterar efter antal anställda, och inte efter vilka system/tjänster/grunkor som verksamheten vill ha.
Lösning: Grunkbudget först, sedan kan man börja tänka på hur mycket folk som behövs.
Som man ropar får man nämligen svar. Frågar slanträknarna inte efter vilka grunkor (produkter och tjänster) som IT-avdelningen levererar, så förblir IT-avdelningens arbetstid ett töcken. IT-strategin faller redan redan innan den lämnat ekonomiavdelningen, långt innan den nått utvecklarrummet.
Mer visdomar från Accenture:
Mycket resurser läggs på dokumentation, men lite energi läggs på att se till att systemen verkligen stöder nya affärer.
Förutom att det inte alls är ovanligt att inte alls mycket tid läggs på dokumentation (den går åt till att släcka bränder i gamla skrotfärdiga datasystem i stället), så är det rätt.
Att se till att systemen stöder nya affärer, det börjar man med redan under utvecklingen. Redan i början av utvecklingen. Redan i början av inceptionsfasen (fasen i utvecklingen där man ska börja fatta vad det är man överhuvudtaget ska göra). Och sedan fortsätter man med det. Affären, the Business Case, måste vara drivande i utvecklingen. Det är de dyrbara problemen som ska fixas, annars blir lösningarna inte lönsamma. Och ansvaret för att projektet löser de dyrbara problemen vilar främst på projektets sponsorer och på projektet. Gemensamt. Och projektet är inte liktydigt med utvecklarna, utan däri ingår även beställarna.
Lösning: en projekt- och utvecklingsmetod som från början är inriktad på lönsamhet. Till exempel RUP. Och den metoden börjar och slutar inte i utvecklarrummet. Den börjar långt tidigare, och fortsätter under systemet livslängd.
Företag med gamla system lägger ned för mycket tid på att fixa dem. De är i en loop där de inte kan investera i nya system, medan de som frigjort resurser för att investera i nytt har färre problem och lättare att dra nytta av de fördelar som systemen ger.
Lösning: Verksamheten måste för det första fatta att det man betalar för nu är priset för gamla synder. Man valde en väg för två år sedan (eller tidigare) som kändes enkel, men som blundade för avskrivningstiden för systemet.
Om man utvecklar system som ska vara lönsamma, då måste man beräkna kostnaden för systemet. Och kostnaden är hela kostnaden, under hela systemets livslängd. Och då måste man från början ha bestämt sig för hur stor livslängd systemet ska ha. Och systemets livslängd beror inte på systemet i sig självt, utan systemet satt i sin omgivning (dvs verksamheten). Och om verksamheten förändras tillräckligt på, låt säga två år (vilket inte är ovanligt), så är systemets livslängd tjugofyra månader, no more no less.
Försöker man fuska och säga: "Äh, vi räknar på tre år istället", då har man förbundit sig att inte förändra sin verksamhet så mycket under dessa tre år. Visst, kan man stå för det så är det OK. Men vill du om två år vara bakbunden av att nya affärer hindras pga gamla system? Vill du kasta in dina IT-resurser i precis den dyrbara hantering som artikeln talar om (handpåläggning, brandsläckning, fix och jox), och aldrig få tid för att utveckla vare sig affär eller system?
Det är ditt val. Men skyll inte på någon annan om du hamnar i träsket. Skyll i synnerhet inte på IT-avdelningen för att du själv glömt matematiken.
Så länge det finns ett gap mellan dem som använder tekniken bra och de som gör det dåligt, kommer it att spela roll, säger Bob Suh.
Välj rätt.
Inga kommentarer:
Skicka en kommentar