jesper a. frederiksen bloghoved

Jeg er dansker og jeg er afhængig af processer… Del 1

Af 17

Hvis man havde en nyslået rigsdaler for hver gang, man hørte ordet ’proces’ brugt i sammenhæng med it, så ville man være en holden mand. Vi skal have processer for alt! Det er faktisk et målbart kvalitetsstempel, at man kan fremvise et proceskatalog for de ting, man foretager sig. Flowcharts for incidenthåndtering, digre værker om change management processer, SCRUM-boards for udviklingsprojekter osv osv.

Hvad er til for hvad?

Min fuldstændigt uvidenskabelige påstand er, at vi et eller andet sted glemte, at det ikke er processen, der skaber den største værdi. Det er problemløsningen, opgaven, udfordringen eller det nye produkt, der skal være det klare og tydelige omdrejningspunkt. Og nej – det betyder ikke, at jeg ikke anerkender den erfarings- og effektiviseringsopbygning, der er indeholdt i at køre processer; men udgangspunktet kan ikke være processen.

Dokumentation kontra tillid?

Det slår mig også, om vores fokus på processer kunne være et udtryk for, at tilliden mellem de personer/virksomheder/afdelinger, som skal samarbejde omkring et givent stykke arbejde, ikke er, hvad den har været. Og dækker procesdiagrammerne så over, at vi så i det mindste har dem at holde hinanden op på? Har vi et flowchart eller en detaljeret procesbeskrivelse for en incidenthåndtering eller en udviklingsopgave, så har vi jo altid den at falde tilbage på og referere til, hvis opgaveløsningen ikke opleves tilfredsstillende af denne ene part. Jeg kan høre det for mig i et troubleshooting scenarie; hvor den, der har brug for hjælp, spises af med, at problemet er eskaleret til næste supportniveau jf. en aftalt eskalationsproces. Og så er tingene jo i fineste orden og i proces; men det gør jo reelt ikke at problemet er løst.

Kan det være, at det bliver vigtigere, at vi er i stand til at dokumentere, at vi er i gang med at løse opgaven på den måde, der står skrevet i en given aftale i stedet for at fokusere på faktisk at løse opgaven? Og kan dokumentationsivrigheden ikke så være et tegn på, at der ikke er tilstrækkelig med tillid mellem partnerne i et samarbejde? Så tænker jeg, at der kunne være en gigantisk konkurrencemæssigfordel for de virksomheder, der kan samarbejde tillidsfuldt med hinanden kontra dem, der må spilde en masse tid, ressourcer og bøvl på dokumentere over for hinanden, at de følger de processer, som de har aftalt mellem hinanden…

Eller er det måske for simpel en betragtning? Hvad siger procesfolket derude?

Kommentarer (17)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Allan Ebdrup Blogger

Noget jeg tit hører fra udviklere andre steder, er hvor mange møder de har.

Jeg tror du har ret i at processerne godt kan få deres eget liv og eksistere for processens skyld. Jeg kender mere en en person der er ret træt af fx ITIL.

Du får process-eksperter som kan fortælle folk hvordan de skal gøre, uden at lytte så meget til og folk nu synes det er super fedt at de skal gøre sådan.

Jeg har det her tweet i nogle af mine præsentationer:

The more well-defined your goals the less defined your methods. The more well-defined your methods, the less defined your goals.

https://twitter.com/afoolswisdom/status/657027847140212736

En god softwareudviklings-process skal have plads til, at lade hvad man gør i det konkrete tilfælde, være en vurderingssag. Du kan sagtens have en process hvor det er defineret at: "Her må du vurdere om der er behov for et kode-review". Klare mål, god information, klart ansvar og så store doser tillid, så kan folk godt vurdere fra sag til sag.

De ting der er ufravigelige krav i processen, skal være så få som mulige og skal være krav som alle er enige om er ting der faktisk hjælper. Sidst men ikke mindst skal det være naturligt at overholde kraven, bland andet ved automatisering og tooling.

  • 5
  • 0
#2 Claus Bobjerg Juul

og it-håndværker, vil jeg bare sige at processer er procedurebeskrivelser, har sin berettigelse, for når man har prøver (som også jeg har) at stå med et system, hvor der ingen dokumentation er, så ved man hvor svært det kan være at finde hoved og hale i hvordan og hvorfor et system virker/arbejder som det gør.

Det at stå uden noget dokumentation, syntes jeg personligt er spændende. men sådan har de fleste det ikke, og jeg ønsker mig da ikke at dem som håndtere mine personfølsomme data, skal finde på nye måder at behandle mine data hver dag eller hver uge eller hver måned for den sags skyld.

Hvornår er den form for procesbeskrivelses/procedure beskrivelse så rigtig god. Jo det er den fx når man skal overtage en anden persons opgaver, hvilket så igen kan ske med få timers varsle, når ens kollage er blevet fjernet fra arbejdspladsen i forbindelse med mistanke om bestikkelse eller illoyalitet.

  • 4
  • 0
#3 Claus Bobjerg Juul

hvad med at kunden forventer at leverandøren fortæller om til og fratrædelser hos leverandøren, men at leverandøren ikke mener at dette er vigtigt, så de undlader at gøre dette.

Det kunne betyde at, rengøringsmedarbejderen/leverandøren, der ankommer hos kunden går rundt med et id kort der ikke tilhøre personen, hvilket er væsentligt, da nye personer skal sikkerhedsgodkendes eller have en sikkerhedsinstruks, som chefen/ledelsen hos leverandøren ikke kender noget til, da produktionen af medicin ellers kan blive forurenet.

  • 1
  • 0
#4 Søren Larsen

Jeg synes at du blander tingene lidt sammen; dokumentation af en funktions, tjenestes, applikations virkemåde burde være en selvfølgelighed. Det er bare ikke det artiklen handler om, men derimod det overskruede, allestedsnærværende enorme behov for cover-my-ass processer, som jeg i øvrigt er helt enig i, i de fleste tilfælde er nærmest dræbende for innovation, agilitet, time-to-market og simpel rettidig omhu.

  • 5
  • 0
#5 Michael Zedeler

Ligesom man i UNIX kan have Zombie-processer som ingen gavn gør, så findes den slags i allerhøjeste grad også når det gælder arbejdsprocesser.

Problemet med den slags processer er bare at det kan være pokkers svært at afgøre om de skaber værdi, eller ej.

Processer er i virkeligheden ikke andet end en meget formaliseret måde at afstemme forventninger på, f. eks.: "hvis jeg siger at jeg er færdig med en opgave, betyder det at x, y og z gælder".

Der hvor kæden hopper af er når man glemmer at processerne egentlig blot er der for at forenkle arbejdet og forvilder sig ned af den sti hvor man mister overblikket på grund af processerne og leverer på trods af dem.

  • 5
  • 0
#6 Chris Bagge

Er selv til dels ramt af, at der skal være beskrevne processer, det jeg på almindeligt dansk kalder "beskrivelse af hvordan noget gøres". Det er ikke nok at tingene gøres, og at der er "objektive vidnesbyrd" (log) på at det er gjort. Dette er et krav ved diverse godkendelser og sikkerhedsvurderinger. Så kan man sagtens råbe "Agile" m.m. men det er auditor totalt ligeglad med. Velkommen til virkeligheden. Så kan vi så forsøge at bruge sundt fornuft når vi skriver vores processer, men det forudsætter så at de der skal bruge / overholde processerne følger spillereglerne, hvilket ikke altid er tilfældet. Når det så er tilfældet, så bliver man ramt af det store papir tyranni.

  • 4
  • 0
#7 Denny Christensen

En god proces beskriver lige netop nok til at de handlinger der SKAL være ens bliver udført ens, uanset hvem der udfører dem, og skal samtidig understøtte at resultatet har den ønskede kvalitet.

Ja nogle ITIL processer bliver også lige langhårede at læse samt følge, og ja når man har gjort det 117 gange kan man måske se en lidt bedre vej igennem, men det går først galt når en person i misforstået bedre viden omgår processerne isf at forsøge at forbedre dem.

Jeg er ikke proces menneske. Jeg ved også selv bedre end alle andre :) men i respekt for det firma der betaler min løn og mine kollegaer der også skal kunne udføre deres arbejde så følger jeg de processer der nu er og glæder mig over at man i mit firma ikke er gået proces amok. Med eksterne leverandører af IT er det nu også en gang imellem meget rart at man kan spore kommunikation og tager det så lige 5 min mere at få rettet en fejl så fred med det.

  • 2
  • 0
#9 Dave Pencroof

Det i skriver, ser for mig ud til at handle om iso-standarter gået amok, hvilket er helt håbløst, i lighed med at sundheds ansatte skal dokumentere røven ud af bukserne, så de kan hænges op på det de gør for dårligt eller forkert, hele vejen ned i papirklips afdelingen ! Her mistes der så vilde mængder af ægte produktivitet, på håbløs dokumentation, ofte i systemer der ikke virker efter hensigten eller ikke-intuitivt, fordi det er bosserne der beslutter hvordan skidtet skal virke, som med SAP i gl dage da de begyndte at implementere det i alle virksomhedens afd. hvilket det ikke var bygget til at være effektivt til

For mig er process-dokumentation et stk værktøj som skal gøre livet lettere på flest mulige måder, men desværre ser det ud til at økonomidirektøren og juridisk afd. har forplumret showet, ved at kræve at det også skal kunne bruges til prissætning ansvarsfralæggelse og til at fortælle kunden i jura vendinger (læs. ulæselig tekst) at, til trods for produktets navn så er der meget det ikke kan i den sammenhæng !

Process skal gøre det lettest muligt at, gå til produktet i flest mulige sammenhænge, det må aldrig erstatte sund fornuft, til trods for at jeg ser tydelige mangler på netop sund fornuft i denne verden af i dag, der skal også være plads til dem der har mindre rigide holdninger til hvordan noget SKAL laves, og som kan se at dette eller hint kan gøres smartere mere effektivt og mere elegant plus måske mere stabilt, kassetænkningen er gået amok, og at gå uden for boksen er næsten ulovligt, det er dybt håbløst samt udviklings bremsende og bagstræberisk !

  • 1
  • 0
#10 Jan Robin Stenmo

Hvis man skal forholde sig til problemet så kræver det ofte faktuel kundskab og gerne specialistviden og erfaring. I diskussionen om processer kan alle være med. Det er måske et spørgsmål om inklusion af ledelse, indkøbere og andre generalister. Så kan de leve i den tro at der er styr på tingene...

  • 2
  • 0
#11 Søren Harder

Jeg er lidt chokeret over at forvekslingen af processer og dokumentation er så udbredt som denne diskussion tyder på.

Processer er ikke dokumenter og dokumenter er ikke processer. Det kan være nyttigt at knytte et skrevet dokument til en process, det være sig for at lave en (evt. juridisk bindende) aftale, for at gøre det lettere at følge processen (for nye medarbejdere, hvis processen er langvarig eller kompleks, eller man er lidt glemsom), lette anden dokumentation/kommunikation ved at referere tilbage til procesbeskrivelsen eller som udgangspunkt for diskussion/ændring af processen, men det er altid en god ide at være opmærksom på at eksistensen af et dokument ofte er en indikation på fraværet af en proces.

  • 2
  • 0
#12 Jens Jakob Andersen

a) Processer må max fylde 2 sider. b) Processer SKAL have fokus på at fremme produktiviteten. c) Processer SKAL forbedres mindst hver 6 måned. d) Alle trin i en proces skal have fokus på fremdrift.

Den seneste ITIL Change Management proces jeg skrev - havde indbygget at INGEN aktører måtte afvise deres input. Hvis de mente der var mangler i et input - så var det DERES opgave at bruge deres viden, til at udfylde det manglende - og sikre fremdrift til næste trin i processen.

Så - processer kan bruges til at skabe fremdrift og effektivitet - hvis man husker på at tænke forretning ind i alle trin.

Hvornår har DU sidst set en ITIL proces - hvor aktørerne blev målt på at skabe fremdrift - og det var FORBUDT at bruge processen til at bremse aktivitet?

  • 0
  • 1
#13 Thomas Hedberg

Den seneste ITIL Change Management proces jeg skrev - havde indbygget at INGEN aktører måtte afvise deres input. Hvis de mente der var mangler i et input - så var det DERES opgave at bruge deres viden, til at udfylde det manglende - og sikre fremdrift til næste trin i processen.

Det er en super ide..

Så når netværks folkene glemmer at allokere en IP og et VLAN, så opfinder server teknikeren da bare et - der er så mange alligevel og wupti så er serveren produceret. Produktiviteten er i top og alle er glade. Måske lige undtaget kunden der ikke kan nå sin nye server.

  • 1
  • 0
#14 Jens Jakob Andersen

Helt enig. Hvorfor skal servermanden stoppe sit arbejde, kaste sagen tilbage over hegnet til netværk, sætte det hele i stå og waste tid?

Det er meget bedre at servermanden har hurtig adgang til at skaffe de manglende oplysninger, og kan fortsætte med at skabe flow i sagen.

Det ville være meget interessant at læse en rapport om hvor meget tid/penge der går spildt i DK, fordi der er alt meget ineffektivitet i change-processerne.

Jeg tror det er store summer der bliver wastet hver dag - fordi processerne er opbygget omkring ITIL's ide om at "sende sagerne tilbage i kæden."

  • 1
  • 1
#16 Jens Jakob Andersen

Ironi er altid velkomment.

Men. Dybt alvorligt. Jeg mener det jeg skriver om optimering gennem processer der har fokus på at skabe fremdrift.

Fx kan man også vende CAB og standard-changes på hovedet og effektivisere.

Obligatorisk CAB er en udgift. Væk med den. Lad alt være standardchanges, med mindre change initiator markerer der er behov for CAB.

En heftig forenkling af processen - og frigivelse af dyre ressourcer.

Hvad så hvis brugerne "glemmer' at markere at en RFC skal forbi CAB?

Lad det være åbent for alle i processen at kunne sætte CAB flaget hvis de vurderer der er behov for det.

Giver det så ikke anarki?

Nej - det gør det muligt kun at anvende dyre CAB møder hvor der virkelig er brug for dem.

Men - er der ikke andre end os 3 der interesserer os for processer? Hvor er de andre debattører?

  • 0
  • 0
#17 Thomas Hedberg

Men. Dybt alvorligt. Jeg mener det jeg skriver om optimering gennem processer der har fokus på at skabe fremdrift.

Det er ligegyldigt, at patienten kom hurtigt igennem systemet hvis vedkommende døde af behandlingen. Derfor er f.eks. kvalitet eller ensartethed, som det vel egentligt burde hedde også vigtige elementer mange steder. Så jeg er ikke enig i et entydigt fokus på fremdrift nødvendigvis er en god ting - det kommer helt an på virksomheden.

Hvis man oplever det problem med at folk bare saboterer sager og sender dem retur pga. komma fejl, så er det snarere et kultur problem i virksomheden der skal løses og det er næppe via en ny process.

Men du har da helt ret i at man skal optimere sine processer og bygge dem så smidige som muligt. De skal være en hjælp - ikke en spændetrøje.

Men - er der ikke andre end os 3 der interesserer os for processer? Hvor er de andre debattører?

Tror det skyldes at der generelt er så mange dårligt skrevne processer og procedurer derude i danske virksomheder, så mange får tics, når de hører om det.

Det hjælper så heller ikke at de fleste blander process og procedure sammen og ikke ved hvad der hører til i hvad.

  • 1
  • 0
Log ind eller Opret konto for at kommentere
Job fra Jobfinder
Tip redaktionen