Konsulent: Hvorfor accepterer virksomheder at få software leveret med møggreb?

Virksomheder køber alt for ofte standardsystemer, der ikke er standardsystemer, mener DevOps-konsulent.

Det bliver alt for ofte kaotisk, langsomt, dyrt og forfærdeligt håndholdt, når virksomheders såkaldte standardsystemer skal opdateres. Og det i en grad, at virksomheden burde sætte foden ned overfor leverandøren, mener Leif Sørensen, der er partner og medstifter af konsulentvirksomheden Praqma.

Læs også: Kronikør: Illusion at staten kan købe færdige it-løsninger i det private

»Jeg forstår ikke, at mange firmaer accepterer at få leveret software på den måde, de får det leveret,« siger han prompte og tilføjer:

»Mange steder får man det smidt ind med en møggreb.«

Læs også: Konsulent om stort EPJ-udbud i Region Syddanmark: »Det er præget af stor uvidenhed«

Ofte er der ingen proces der definerer, hvordan software egentlig skal leveres, og derefter hvordan det skal opdateres, fortæller Leif Sørensen, der rådgiver virksomheder, som gerne vil arbejde mere agilt og med continous delivery.

»Der er mange steder, hvor integreringen med det, man fik leveret sidste gang, ikke er en kontrolleret proces, men foregår ved at nogen kommer ud, og får det hele til at virke igen,« fortæller han.

Mange virksomheder får leveret software med en møggreb, siger partner og medstifter af Praqma Leif Sørensen.

Kaotisk og dyrt

I stedet oplever Leif Sørensen, at det hele sker manuelt og håndholdt.

»Jeg ser en hel del steder, som har fået leveret et standardsystem,« indleder han over for Version2 og fortsætter:

Læs også: Amazons DevOps-strategi: Udviklingshold skal kunne mættes med to pizzaer

»Men når de får leveret et ny release af det standardsystem, så får de sendt en CD, kopierer en masse filer rundt manuelt, og har en manuel proces til de lokale ændringer og opdateringer«

Der er altså ingen veldefineret og automatisk proces for, hvordan standardsystemerne skal opdateres. Og konsekvensen er at virksomheden reelt ikke har et standardsystem.

Læs også: Er du obs på DevOps?

»Vi ser virksomheder, hvor der sidder folk, der bruger al deres tid på at integrere nye leverancer fra leverandørene, og prøver at få det til at merge med det, de selv sidder og laver,« siger Leif Sørensen og fortsætter:

»Det er forfærdeligt håndholdt, kaotisk, langsomt og dyrt.«

Standard - ikke standard

Ifølge Leif Sørensen bliver it-systemer ofte solgt som standardløsninger, fordi de er blevet solgt til to kunder.

»Men hvis man ikke har fået lavet til en virkelig standardløsning, hvor man har en arkitekturnæssig måde at lave lokale ændringer og en effektiv måde at opdatere på, så bliver det en håndholdt standardløsning - og så er det ikke en standardløsning, selvom man kalder den det,« siger han.

Læs også: Undersøgelse: DevOps-organisationer arbejder langt hurtigere end andre

Hvis man for alvor skal kalde sin løsning for et standardsystem, skal opdateringer og levering være reproducerbar og automatiseret, vurderer Leif Sørensen og slutter:

»Så det her handler om at stille krav til sin leverandør.«

Tips og korrekturforslag til denne historie sendes til tip@version2.dk

Følg forløbet

Kommentarer (10)

Carsten Poulsen

Med standardsystem forstår jeg f.eks. Visual Studio, som i grunden opdateres let og elegant. Mange andre systemer på samme måde.
Problemet er, at der meget ofte ligger tilpassede processer og domæneviden omkring 'standardsystemet', som gør, at der i bund og grund ikke er tale om et 'standardsystem', men et højt specialiseret system, som er tilpasset en bestemt kunde eller afdeling i en virksomhed.
Min egen historie er, at jeg er ved at lave et 'standardsystem'.
Det er ledelsens forventning, at 'standardsystemet' dissimineres til hele virksomheden med det argument, at det samme overordnede problem findes i andre afdelinger.
Det er i sig selv prisværdigt at tænke på den måde og afspejler den øverste ledelses strategi om samarbejde og genbrug.
Men det viser desværre samtidig, at ledelsen ikke har forstået, at det er almindeligt, at processerne er de same, men anderledes, og at lokal domæneviden er en forudsætning for samarbejdet. Det betyder, at processerne ikke (umiddelbart) kan genbruges og at domæneviden er en forudsætning for det udbredte samarbejde, som ledelsen forudsætter. Ofte kræver det organisatoriske ændringer at opfylde kravet om genbrug og samarbejde. Det kommer ikke ved at indføre et system og tilpasse det.
Og det er selv om de samme grundlæggende værktøjer med lethed kan bruges overalt.
Der er altså en manglende ledelsesforståelse, som bevirker, at ’standardsystemet’ ikke findes!
Men det tilpassede system er en forudsætning for effektiv drift i virksomheden.
Samtidig er der ofte en manglende forudsætning som, at modtageren (application owner) ikke er helt klar over de vedligeholdelsesmæssige udfordringer, som er omkring et tilpasset system. Det stilles sjældent krav til leverandøren af systemet, som består af standardsoftware og tilpasninger, om hvordan opdateringer og tilpasninger leveres. Ofte er det en forventning, at når’standardsystemet’ er indkørt, så passer det sig selv. Forkert. Virksomheden forandrer sig, så det skal ’standardsystemet’ også.

Frithiof Jensen

Så de får ikke lige med i kontrakten at der skal leveres MERE end en CD-ROM med "setup.exe". Der skal "management" med.

Ud over hvad der er bygget ind i Windows, findes der "generelle" värktöjer som Puppet, CF-Engine eller ConfD der nemt kan håndtere at rulle applikationer, der er spredt over mange stykker forskellig hardware ud, ändre config-filer, indsamle data og alt muligt andet. Hvis noget kan programmeres så kan det automatiseres også.

Man välger et management system f.ex. Puppet/CF-Engine, derefter man specificerer at man også behöver et "rollout-script" til sit värktöj leveret sammen med applikationen.

Det koster nok lidt mere, men, nok end del mindre end at en PFY springer rundt til 50 maskiner med en USB-disk og et papir med config-updates.

Simon Lodal

Det lader til at være et buzzword som alle lægger deres egen mening i.

Jeg ville tænke på et system der bruger standardiserede dataformater og protokoller.

Altså noget der kan integreres og driftes på en standard måde, og ikke er en "blackbox".

Men åbenbart betyder det oftere noget a'la:

  • Et system der allerede eksisterer og er i drift hos andre kunder.
  • Et system som alle andre bruger, uanset hvor ringe det måtte være.
  • Hvad som helst man kan betale sig fra i stedet for at tænke selv.
  • Det må være lige så utilgængeligt og u-administrerbart som det vil, bare der er et nummer man kan ringe til.

Andre bud?

Mogens Lysemose

Et standardsystem er (for mig) et der bliver supporteret uden en selvstændig vedligeholdelsesaftale, og herunder kan opdateres med sikkereds- og fejlrettelser der stilles offentligt til rådighed uden nogen sidder og special-udvælger eller håndkoder til den konkrete virksomhed.
Standardsystem og supporteret system hænger derfor sammen for mig. Men det er ikke nok.
Standardsystemet skal også være brugertilpasset rigtigt så det kan opdateres uden problemer.
Eksempler er f.eks. et Web-CMS (content management system) som Wordpress, Typo3 osv.
Er brugertilpasningerne lavet ordentligt kan man sagtens bruge den indbyggede automatiske opdatering af alle moduler og opgradere til en ny version af CMS'et.
Men alt for tit har jeg set at hurtige, selvlærte programmører hacker kildekoden til systemet eller modulerne for lige at flække kundens ønsker ind der uden at forstå at det er fundamentalt forkert. Det har jeg set mange gange med web-CMS.
Ved næste opdatering går alle tilpasninger dermed tabt eller gør ligefrem hele systemet ubrugeligt. Så hvis ejeren opdaterer som brugerfladen anbefaler går det galt.

Jeg arbejder pt. med et perifært SAP-system (MII) og vil ikke ubetinget kalde det et standard-system da det ikke rigtigt overholder ovenstående.

Brian Vraamark

Er et system selve koden? Er det koden i form af en setup? Er det setup + levering som definere et standardsystem? Er det inklusiv undervisning og hotline/support? Betaler de alle det samme?

For mig er leveringsmetoden ikke hvad der definere et standardsystem. Hvis du leverer samme system (kode) til alle kunder, er det et standardsystem. Hvis levering af denne kode er på USB + installationsvejledning til alle kunder, er det en standardlevering. Du kan godt have et standardsystem uden en standardlevering og omvendt.

Vi har ca. 900 kunder som modtager den samme setup indeholdende samme kode. De modtager et elektronisk nyhedsbrev i systemet om at der er en opdatering. Herefter henter de opdatering på deres server, som automatisk ruller programmet ud på alle arbejdsstationer. Det er et standardsystem med en standardlevering. Ens for alle - uden undtagelse.

Hvis en kunde får opfyldt en ønsket feature, vil ALLE kunder modtage samme feature. De kan så ofte selv bestemme om de vil aktivere denne feature eller ej.

Morten Nielsen

Jeg mener det drejer sig om.
1. At der sidder folk som ikke har en formel IT udannelse, og evt. udvikler erfaring og arbejder med it systemer.
2. Virksomhedens ledelse ikke har forstået pkt. 1, og dermed ikke er deres opgave voksen.

Anders Poulsen

Et standardsystem er dét man får, når man har forlangt at leverandøren skal levere et standardsystem.
For et par år siden, talte jeg på en konference med et par fyre, som var ved at bygge et system som var ved at blive SKI godkendt som det første [hvad det nu end var] af sin slags. Det var fuldstændigt custom made til den kunde som de havde dialog med, men de klarede SKIs krav om at det skulle være et standardsystem ved at dokumentere med nogen screenshots at det kunne tilpasses på diverse måder. Screenshotsne havde de ganske vidst bare lavet i Photoshop, men det var åbenbart ikke noget problem for at blive godkendt som leverandør af et "standardsystem".

Denny Christensen

OK jeg vover pelsen.

Der findes flere betydninger af ordet standard, men jeg vil mene at 'ensartet' er det bedste bud.

Et standard system er dermed et system der er 'ensartet' på tværs af installationer. Eks. SAP der tilpasses den enkelte virksomhed.
Så kan standardsystemet have en standard installationsprocedure, der så ikke passer til alle virksomheder, idet hver virksomhed har indført egne procedurer og regler.

Derefter tilpasses, på godt og ondt, standardsystemet så det ikke længere ligner tilsvarende versioner i andre virksomheder. Og dermed passer standard installationsproceduren jo heller ikke.

En af mine tidligere chefer skrev engang et indlæg om at hvis man tilpassede et standardsystem mere end 10 pct så havde man ikke længere et standardsystem, hvilket talrige SAP installationer i tidens løb har vist korrektheden af.
Til gengæld kan man kickstarte en IT løsning og det har vel også en værdi.

Bente Hansen

Med Open Source eller som det mindste. Åben, frie, patent frie og dokumenteret dataformater. Eller noget der ligner og er tæt på, som pdf og jpg.
Det må vel være definition på et standardprogram, at data kan gemmes og åbnes og bruges i andre program.

Ellers er det vel standard proprietær software. Som man skal holde sig fra.

Log ind eller opret en konto for at skrive kommentarer

Pressemeddelelser

Big Data Lake Summit: Fast and Trusted Insights

If you want to outpace, outsmart and outperform your competition in a digital world, you need trusted data that can be turned into actionable business insights at speed.
24. apr 2017

Welcome to Free course to learn about the combined power of Alteryx and Qlik!

Affecto invites to a free course, where we want to share our knowledge of this self-service analysis platform together with the power of Qlik.
20. apr 2017

Robotics Process Automation (RPA) changes the way organizations think about and perform work at a reduced cost, higher efficiency and greater productivity

Join us for this exiting seminar, which Affecto hosts with our business partner SmartRPA May 3rd, 2017 at 13.00 in Copenhagen.
30. mar 2017