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

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.

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.

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.

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.

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.

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.

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.

Processer har en værdi (den kan endda være temmelig stor) hvis de konstant evalueres og revurderes for hvor meget de bidrager og om de kan ændres til noget bedre.
I det øjeblik de bliver til ritualer er værdien væk.

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 !

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...

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.

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?

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.

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."

Jeg beklager min holdning ikke var mere tydelig. Mit nytårsfortsæt bliver at, at jeg bliver bedre til at fremhæve ironien eller indsætte "Ironi kan være anvendt" i indlæg som det jeg lavede tidligere.

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?

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.