Reni Friis bloghoved

Processer duer alligevel ikke...

Nej… det gør de ikke. Hvis de bare ligger på fællesdrevet eller inde i hovedet på folk.

Jeg står jævnligt i en situation, hvor medarbejderne har mistet troen på, at processer kan bruges til noget som helst, fordi der HAR været kørt både 1 og 2 projekter over tiden, hvor processerne er blevet tegnet op, præsenteret, sendt rundt på en e-mail, lagt på intranettet eller så. Ingen kan se nogen værdi af de der processer og de har ret! I den form jeg beskriver ovenfor har de heller ingen værdi. Øv, siger jeg, som står der og har fået til opgave at hjælpe dem med at få processerne til at virke og give værdi…

Det er absolut ligegyldigt (næsten) hvor flotte, korrekte, ITIL-agtige og detaljerede processer er, hvis de ikke leves og udgør skelettet i den måde medarbejderne og lederne i en organisation arbejder på. Og det sker ikke af sig selv. Det kræver hårdt og vedholdende arbejde fra især ledernes side at reelt påvirke og bestemme HVORDAN medarbejderne udfører deres arbejde på.

Jeg må ærligt indrømme, at jeg ikke forstår hvorfor ikke alle ledere ser måden hvorpå organisationens services eller produkter bliver til på, som noget de bør interessere sig dybt for. Måden de bliver til på, er da en kæmpe faktor ift hvor dyre de er at fremstille, hvor lang tid de tager at levere etc.

Hvad siger I?

Kommentarer (13)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Reni Friis

Hej Pelle

Jeg er for så vidt enig med dig - til et vist niveau. Kan godt følge dig i, at de ikke behøver blande sig i hvordan i detaljerne. Det ville jo være en form for slaveri egentlig.

Men at interessere sig for at folk noterer sig checklister for ikke at lave samme fejl igen og igen, at ting bliver registreret og noteret på samme måde af alle medarbejdere, så man kan danne sig et overblik over hvor mange ressourcer der er brug for, om man kører SCRUM eller vandfald fx - det mener jeg jo, at de bør interessere sig for. Det er jo trods alt et arbejde hvor man er en del af en større sammenhæng...

Jeg oplever bare ofte at lederne SLET ikke tager stilling til hvordan folk arbejder, og dermed hvilken rækkefølge ting laves i, hvem der gør hvad osv. Og det synes jeg er galt...

Man kan jo godt have fx 5 intelligente og kreative medarbejder i en afdeling, som hver især gør et fantastisk stykke arbejde. Men det, at de gør ting vidt forskelligt, og fortolker ting forskelligt gør, at de kan læse hinandens dokumentation, overtage for hinanden etc...

Reni

  • 3
  • 4
Pelle Söderling

Hej Reni

Jeg er enig i at vidensudveksling er vigtigt, men man skal være meget påpasselig med hvordan man implementere det. Hvis der er sat for mange barriere op og krav til dokumentationen osv. så vil mange "silent" sige fra og kvaliteten af det der produceres vil så være derefter og værdien minimal.

En wiki med rimelig frie rammer kan ofte fungere bedre end et komplekst system med en masse krav fra eks. ledelsen eller rigide ledesesprocesser. Det vigtigste er at man formår at overbevise medarbejderne om værdien i det og at gøre vejen fra ide til skrift kort, således at medarbejderne føler værdien i at notere det ned overstiger indsatsen (ellers kan du være helt sikker på der er mange ting som burde være skrevet ned som bliver skippet).

Ang. SCRUM og vandfald etc. så er jeg tilbøjelig til at sige de er ligegyldige - hvilket muligvis er kontroversielt, men i sidste ende er det folk det handler om og det er ikke rocket science at finde ud af at afholde et ugentligt statusmøde eller hvad man nu finder nødvendigt eller at udvikle tingene lidt skridt-vis (det har vi gjort meget før disse processer blev formuleret) - og den eneste grund til nogen arbejder i det vi kalder "vandfald" er fordi der er nogen i ledelsen som har underskrevet en kontrakt med en alt for stor kravsspecifikation de nu hænger på som "v1", du finder ikke mange udviklere der naturligt vil arbejde på den måde.

Det er fint at udstikke guidelines omkring eks. dokumentation men pas på med at ophøje det til regler.

Og det vigtigste for at folk kan læse hinandens kode og overtage andres projekter er at man arbejder efter ensartede kodestandarder og er enige om hvordan projekter grundlæggende struktureres og altid er åben overfor at forbedre den fælles forståelse af dette.

  • 10
  • 0
Peter Johan Bruun

....og det er her systemudvikleren viser sit værd.

Ledelsen bør virke ved at ramme præcis det abstraktionslag der skal til for at arbejdet går i den retning virksomheden ønsker, og som samtidigt sikrer at systemudvikleren har mulighed for at udfolde sit talent - hverken mere eller mindre.

SCRUM, ITIL, LEAN, PRINCE2 ..... de virker sikkert alle hvis man forstår det princip og følger det i sin daglige gøren.

Personligt har jeg kun set SCRUM virke et sted og på ét projekt - men der betød det til gengæld også forskellen på success og fiasko i et meget vanskeligt, omkostningstungt og strategisk vigtigt projekt, for den pågældende virksomhed.

For at kunne ramme dette abstraktionslag kræver det samtidigt at man som leder har haft fingrene i maskinrummet, og derfor forstår hvilke udfordringer flyt af enkelte datastrømme, integrationer, skærmbilleder, print eller for den sags skyld hele forretningsprocesser giver til en systemudvikler og de forretningsvidenspersoner der skal definere og udfordre det kommende system.....og på det punkt tror jeg at de fleste forfejlede projekter skal finde den primære årsag til at projektet ikke lykkedes, selvom man havde fulgt en bestemt udviklingsmetode eller "process" der siges at give bedre IT systemer efter endt udvikling.

Specielt med tanke på offentlige IT projekter er det vist det der er sket når fiaskoen er en realitet: Ledelsen kender ikke til hvad dem de leder, udførte af arbejde - en observation som kan begrundes i at forfejlede offentlige projekter henter eksterne "vurderingsbureauer" ind, for at klarlægge hvad der gik galt - men det sker så først når katastrofen er tæt på at indtræffe. eller allerede er sket.

I ledelseslaget er det vigtigt at forstå den naturlige udvikling, der kommer ud af den erkendelse: Dygtige IT folk bør ledes af dygtige IT folk - så kan diverse brodne kar i systemudviklingen bedre findes før katastrofen sker - efter det kommer et evt. behov for at indføre systemudviklings-styrings-processer og metoder til at styre udvikling af det nye system, som et - måske - nødvendigt supplement.

  • 2
  • 0
Jn Madsen

Det er meget kompleks det her.

Hvornår skal man styre, hvornår skal man slippe?

Nogle processer skal overvåges, styres, monitoreres, korrigeres, formidles ... osv osv
Andre skal slippes.

Kunsten for ledelse er at kunne indse hvornår det er bedst at slippe, hvornår der ikke er brug for den uendeligt store kasse med ledelses-værktøjer,- og hvornår der i høj grad er brug for den,

Et dejligt eksempel i nyerere historie er Red Buells lange sejrsrække i Formel 1.

Deres "hemmelighed" var, ud over at have penge nok og de rette personer (hvad mange andre teams også har), at de har løs styring. Ledelsen lader de dygtige specialister passe deres arbejde i fred. De styrer tingene selv.

Med det resultat at de udviklede sig lang hurtigere end alle andre teams.

McLaren er f.eks. kendt for det stik modsatte. Specialisterne er konstant styring af en leder. Lederne er kendt for konstant at rende rundt i "motorrummet" og blande sig i alt.

Red Buell blev så overlegne at det næsten blev komisk.

Der er nok ingen gyldne formler her,- hvornår skal ledelsen plapre om ITIL, processor, visioner, koncepter ...osv, og hvornår er det klogeste de kan gøre, at lukke døren udefra og køre til bageren efter godt brød til frokosten???

  • 4
  • 0
Jn Madsen

I forlængelse af dette ..

Hvis processer er i himmelråbende modstrid med arbejdets natur og naturlige flow,- så er processerne svære at implementere. Folk lytter ikke og gider dem ikke.

Jeg snakker ikke om firmaets "kroniske" brokkehoveder, jeg peger på dem der bliver forhindret/forsinket af process arbejdet. Dem der kunne have lavet den hurtigste bil, men havde travlt med dokumentation/beskrivelser/møder osv osv.

Alle de dygtige teknikere og ingeniører der i 5 år stod og kiggede misundeligt på Red Buell's suveræne bil,- mens de optimerede flowchart's til ledelsens næste krisemøde.

  • 5
  • 0
Pelle Söderling

En af de mest kontroversielle virksomheder i nyere tid hvad angår ledelsesprincipper er et softwarefirma de fleste der har spillet computerspil kender ganske indgående, nemlig Valve.

Det kan anbefales at læse og studere deres håndbog til nye ansatte:
http://www.valvesoftware.com/company/Valve_Handbook_LowRes.pdf

Og hvorom det måske kan argumenteres om de har vendt tingene lige lovligt meget på hovedet, så taler deres resultater et ret tydeligt sprog og i modsætning til de fleste amerikanske virksomheder så har de et uhyggelig lille antal ansatte på blot 300 mand - alligevel betragter mange dem som en af giganterne indenfor spilbranchen og deres distribueringsplatform Steam har sat sig tungt på digitalt spilsalg.

Hvilket i sig selv er imponerende - det er få firmaer der formår at lave mere end én guldkalv - Valve har allerede lavet adskillige.

  • 0
  • 0
Jesper Lorentsen

Jeg tror I er nødt til at definere nærmere hvad det er I snakker om. Altså hvilke processer.

Grunden til min holdning er at vi på min arbejdsplads Djurslands Bank har stor succes med at indføre 'sager'. En 'sag' hos os er en samling af en konkret opgave, en køreplan for opgavens udførelse, dokumentation om forretningsgangen, mv.
En opgave er i den forbindelse en bunden gentagen arbejdsopgave, som f.eks. Oprettelsen af et lån, eller Oprettelsen af en ny kunde.

Medarbejderne elsker sager fordi de binder opgaver sammen med dokumentation om udførelsen, og de giver overblik.

Så jeg tror at enten så har I ikke lagt 'systemet' til at styre sagerne ind det sted hvor det naturligt vil være under udførelsen. Eller også har I ikke konsensus i koncernen om hvordan en process skal håndteres.

Eller også har jeg bare misforstået hvad I mener med 'processer'.

Med venlig hilsen
Jesper

  • 0
  • 0
Pelle Söderling

Hej Jesper

Jeg beklager det ikke fremgik tydeligt, jeg glemmer nogle gange vi ikke alle er udviklere herinde ;) - jeg udtaler mig primært om softwareudvikling.

Jeg er helt enig i at et system som du beskriver giver god mening til folk der sidder med kundekontakt eller udfører administrative opgaver.

  • 2
  • 0
Torben Mogensen Blogger

Edsgar Dijkstra har udtrykt fænomenet meget godt:

A number of these phenomena have been bundled under the name "Software Engineering". As economics is known as "The Miserable Science", software engineering should be known as "The Doomed Discipline", doomed because it cannot even approach its goal since its goal is self-contradictory. Software engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter "How to program if you cannot.".

  • 4
  • 0
Allan Ebdrup

Vi har lige lavet radikalt om i vores udviklingsprocess. Det er gået forholdsvis hurtigt og smertefrit - og vores tools og automatik er blevet tilpasset utroligt godt til den nye process. Næsten alt er blevet bedre.

Efter min vurdering gik det så smertefrit og hurtigt fordi ændringerne blev initieret og gennemført af udviklerene og teamleads selv, med godt samspil med PO'er, QA osv. En stærk vilje, et mandat og ikke mindst evnerne til at selvorganisere - Det virker.

  • 2
  • 0
Rune Larsen

Man kan jo godt have fx 5 intelligente og kreative medarbejder i en afdeling, som hver især gør et fantastisk stykke arbejde. Men det, at de gør ting vidt forskelligt, og fortolker ting forskelligt gør, t de kan læse hinandens dokumentation, overtage for hinanden etc...


Det, at de gør ting vidt forskelligt, og fortolker ting forskelligt er en kæmpe styrke, som gør, at de kan lære fra hinanden og supplere hinanden og sammen udgøre et effektivt udviklingsteam. Gerne med lidt hjælp udefra til at etablere effektiv kommunikation internt og eksternt. Fx scrum/kanban board, projekt-kontor, morgenmøder og lignende practises, som vi kender fra agil udvikling.

Det du omtaler "processer" er retteligt "proces-beskrivelser". Sådanne kan være glimrende. De skal bare formaliseres og fødes ind i en computer, hvor de kan gøre stor nytte i løsning af veldefinerede opgaver.
Et tungt procesaparat som ledelsesværktøj overfor kreative medarbejdere, der løser diffuse opgaver duer ganske rigtigt ikke.

  • 0
  • 0
martin nielsen

Processer virker kun hvis de gør livet nemmere for folk.

Det værste man kan gøre er at købe (endnu) et nyt sagshåndteringssystem, kaste det efter sine medarbejdere og så håbe på de tager det til sig*.

*Det gør de ikke.

Det er utroligt svært, fra dag til dag, at omlægge hele sin arbejdsgang til et nyt processs system, der forresten ikke følges eller støttes af ledelsen alligevel fordi en overambitiøs projektleder har fået en god ide, eller en konsulent er blevet hentet og betalt for at stå og prædke om hvor godt ITIL er, og forresten også kræver man skal bruge ugevis på at sætte sig ind i, for til sidst ikke at blive fulgt op på efterfølgende.

Den tid det tager at lære processer systemer at kende vil folk hellere bruge på alle de opgaver der i forvejen ikke er tid nok til at lave. Specielt hvis det kommer i form af et monstrøst nyt stykke værktøj der er ulideligt at arbejde i.

Så tag det et skridt af gangen. Vælg en mindre gruppe af villige deltagere til at starte med. Hjælp deltagerne til at analysere hvilke arbejdsopgaver de bruger unødvendigt meget tid på, hjælp dem med at få defineret disse opgaver, hjælp dem med at sætte struktur på opgaverne og hjælp dem til at indse hvor meget spildarbejde de kan undgå ved at bruge processer.

Når først man indser hvor meget der er at opnå ved at bruge processer, og man har fået defineret de mest gængse opgaver, så kan man begynde at tale om værktøjer til styring af processer.

Prøv eventuelt at læse 4 Disciplines of Execution: http://www.amazon.co.uk/Disciplines-Execution-Getting-Strategy-Done/dp/0...

Det omhandler ikke processer direkte, men derimod det underliggende problem med at få folk til at prøve noget nyt. Det kan være det giver noget inspiration.

Og følg for Guds skyld op på det. Det er en iterativ process at implementere en ny arbejdsgang.

  • 0
  • 0
Log ind eller Opret konto for at kommentere