Gå til innhold

Ansatte sykemelder seg etter langvarige problemer med IT-system


Anbefalte innlegg

Videoannonse
Annonse

Hvem har prosjektstyringen? har det blitt utført grundige tester før utrulling? ar de ansatte blitt skikkelig lært opp i det som er nytt? Finnes det et testmiljø som er identisk med produksjonsmiljøet? Har noen skrevet en skikkelig endringsforespørsel? Har noen i så fall husket å skrive en skikkelig rutine for å rulle tilbake?

 

90% av tiden som brukes på oppgradering skal brukes til forberedelser. Hva er fordelingen av tidsbruken her?

  • Liker 2
Lenke til kommentar

Hvem har prosjektstyringen? har det blitt utført grundige tester før utrulling? ar de ansatte blitt skikkelig lært opp i det som er nytt? Finnes det et testmiljø som er identisk med produksjonsmiljøet? Har noen skrevet en skikkelig endringsforespørsel? Har noen i så fall husket å skrive en skikkelig rutine for å rulle tilbake?

 

90% av tiden som brukes på oppgradering skal brukes til forberedelser. Hva er fordelingen av tidsbruken her?

Jeg tenker at du trykker fingeren på skoen akkurat der det gjør vondt. Og man trenger ikke mer enn at et par av disse er fraværende eller har utilstrekkelige tidsrammer/prioritering/ressurstildeling før korthuset raser.

 

Og det er alltid dette "noen". Alle peker på "noen". Når alle blir lei av å peke på hverandre så peker man ofte til slutt nedover, da det er enklere enn å gå i seg selv og innrømme hva man faktisk ikke har sørget for.

 

Det er helt utrolig at slikt kan skje i store organisasjoner ol. men det gjør det faktisk. Det som også er litt trist er at man veldig ofte ikke lærer av det i etterkant heller ved at:

 

a) har etablert en systemisk fryktkultur som preges av "ansvarsfraskrivelse" og "skylddytting".

b) Nedspiller tilbakemeldinger underveis som burde tas mer alvorlig. Også benektelse i etterkant.

c) ikke evalurerer prosjektet med åpne kort i etterkant

d) utelater de som  har vært delaktige, har kjent det på kroppen og kan fortelle det "fra innsiden", fra den evt. evalueringen. (som er helt hinsides all fornuft).

e) avstår fra noe som kan kalles en evaluering og konstruerer en sannhet basert på antakelser og egen "pynting" av 

fakta.

 

 

Prestisje kommer ofte i veien for en god evaluering i etterkant. Ofte også mens man har problemer underveis.

Endret av Theo343
  • Liker 6
Lenke til kommentar

Jeg tenker at du trykker fingeren på skoen akkurat der det gjør vondt. Og man trenger ikke mer enn at et par av disse er fraværende eller har utilstrekkelige tidsrammer/prioritering/ressurstildeling før korthuset raser.

 

Bytt sko?

Lenke til kommentar

Hahahaha, der jeg jobber så må vi bare vente når det er data problemer, som det er ofte også må vi bare jobbe overtid uansett, jeg jobber ikke i NAV riktig nok, men det sier litt om de som jobber der, aldri gjort ett arbeidsslag i hele sitt liv uten om å sitte på en stol å flytte papirer også blir de sykemeldt for noe så lite som dette.

Lurer på hvordan disse folka hadde blitt av en dag med fysisk arbeid, ufør resten av livet?

Endret av meg0709
  • Liker 1
Lenke til kommentar
Gjest Slettet+987123849734

Er alle disse systemene egentlig et resultat av "jo flere kokker, jo mer søl" problematikken? Man skal i utgangspunktet lage forholdsvis enkle systemer, men siden det er så mange involverte, har ingen oversikt og alle jobber i hver sin retning mot noe man tror er et felles mål. Man har inkompetente arkitekter som spesifiserer systemet, man har inkompetente testere hos kunden også blir det ikke godt nok spesifisert hva som faktisk skal utvikles, så utviklere lager ikke forventet funksjonalitet. Alt i alt bruker man mye resurser bare på å rydde opp etter hverandre og koordinere arbeidet.

Lenke til kommentar

Er alle disse systemene egentlig et resultat av "jo flere kokker, jo mer søl" problematikken? Man skal i utgangspunktet lage forholdsvis enkle systemer, men siden det er så mange involverte, har ingen oversikt og alle jobber i hver sin retning mot noe man tror er et felles mål. Man har inkompetente arkitekter som spesifiserer systemet, man har inkompetente testere hos kunden også blir det ikke godt nok spesifisert hva som faktisk skal utvikles, så utviklere lager ikke forventet funksjonalitet. Alt i alt bruker man mye resurser bare på å rydde opp etter hverandre og koordinere arbeidet.

Husk også på at tjenesten NAV leverer er spesifisert av våre folkevalgte, en spesifikasjon som er summen av lure påfunn, valgløfter, hestehandler og forhandlinger mellom vinnere og tapere i alle valg siden krigen(hvilken krig? Velg selv)

 

Så kan man ønske seg et system som er fleksibelt nok til å takle alle disse sprikende spesifikasjonene, og grøsse over hvilket kaos man kommer til å ende med til slutt..

  • Liker 1
Lenke til kommentar

Det generelle problemet i offentlige IT-organisasjoner er at de ikke ser på seg selv som teknologi-virksomheter. De skjønner ikke at de må bemanne opp hele "verdikjeden" med folk som har fingerspisskompetanse på teknologi. Spesifikt, så tror ledelsen i disse virksomhetene ofte at de kan bemanne opp mellomlederstillingene med rene byråkrater, folk uten teknisk utdanning av betydning, men med ønske om å "være med på å prege den offentlige digitaliseringen". Det er disse sistnevnte såpekokerne som er det store problemet. Når man er en teknologiorganisasjson, så må teknologisk innsikt gjennomsyre alle ledd. Det holder ikke å ha ingeniør- og teknologikompetanse bare på bunnen. Det må eksistere helt til topps.

 

Jeg tror grunnen til at det blir som det blir, er at byråkrater ansetter byråkrater. Når man først har fått en byråkratitung organisasjon, så har byråkratene en tendens til å ville ansette flere byråkrater. De har en tendens til å forsøke å "rigge" organisasjonen til å bli noe som kan styres av rene byråkrater. De vegrer seg på en måte litt for å ansette teknisk kompetente folk side om side med seg selv, fordi de da vet at de vil bli "trumfet" på teknisk innsikt. Det er en slags overlevelses- og beskyttelsesstrategi som kicker inn.

 

Resultatet er at disse organisasjonene forblir dysfunksjonelle når de først har kommet i dette uføret... Det gjelder sikkert NAV, og det gjelder IT-organisasjonene til andre store offentlige etater, som f.eks. Politiet og Statens vegvesen.

 

Det som trengs, rent faktisk, men som det er nesten umulig å få til i praksis, er at man må sparke ut de som bare er der basert på et ønske om å "være med på å prege digitaliseringen av det offentlige Norge", og man må få inn folk som faktisk har systemutvikling og utvikling av teknologiske systemer som fagbakgrunn og utdanning...

  • Liker 4
Lenke til kommentar

 Spesifikt, så tror ledelsen i disse virksomhetene ofte at de kan bemanne opp mellomlederstillingene med rene byråkrater, folk uten teknisk utdanning av betydning, men med ønske om å "være med på å prege den offentlige digitaliseringen". 

 

Dette er også et problem i det private, enkeltledere som setter prestisje i enkeltprosjekter, uten å ha rådført seg med nøytrale eksperter eller snakket med ansatte. 

  • Liker 2
Lenke til kommentar

Husk også på at tjenesten NAV leverer er spesifisert av våre folkevalgte, en spesifikasjon som er summen av lure påfunn, valgløfter, hestehandler og forhandlinger mellom vinnere og tapere i alle valg siden krigen(hvilken krig? Velg selv)

 

Så kan man ønske seg et system som er fleksibelt nok til å takle alle disse sprikende spesifikasjonene, og grøsse over hvilket kaos man kommer til å ende med til slutt..

Utfordringene NAV har med IT går langt tilbake.

 

Da det som nå er NAV skulle over fra papir til digital satte de ansatte gjennom fagforeningene seg fullstendig på bakbena, og det ble løsninger i form av "digitalt papir" istedet for vettuge forretningssystemer. Konsekvensene har de strevd med helt siden den tid, og det begynner å bli maaange år.

 

Det der har ikke noe som helst med politikerne å gjøre bortsett fra evt påvirkning de ansattes fagforeninger måtte ha hatt på AP/SV osv.

  • Liker 1
Lenke til kommentar

Hvem har prosjektstyringen? har det blitt utført grundige tester før utrulling? ar de ansatte blitt skikkelig lært opp i det som er nytt? Finnes det et testmiljø som er identisk med produksjonsmiljøet? Har noen skrevet en skikkelig endringsforespørsel? Har noen i så fall husket å skrive en skikkelig rutine for å rulle tilbake?

 

90% av tiden som brukes på oppgradering skal brukes til forberedelser. Hva er fordelingen av tidsbruken her?

 

Du vet også da at uttømmende test ikke er mulig, og at selv med prod like miljø etc så er det en risiko at feil kan oppstå? I sær hvis vi tar hensyn til at NAV er en av få "bedrifter" med stormaskin og som er en sammenslåing av ymse etater med ditto mange systemer som skal snakke sammen?

 

Hahahaha, der jeg jobber så må vi bare vente når det er data problemer, som det er ofte også må vi bare jobbe overtid uansett, jeg jobber ikke i NAV riktig nok, men det sier litt om de som jobber der, aldri gjort ett arbeidsslag i hele sitt liv uten om å sitte på en stol å flytte papirer også blir de sykemeldt for noe så lite som dette.

Lurer på hvordan disse folka hadde blitt av en dag med fysisk arbeid, ufør resten av livet?

 

Slapp av, dette skjer i det private og, dårlige systemer som motarbeider og ødelegger for brukerne kan skape så mye frustrasjon at over en lenger periode slik det er nevn her kan medføre at stresset blir for mye. 

 

Er alle disse systemene egentlig et resultat av "jo flere kokker, jo mer søl" problematikken? Man skal i utgangspunktet lage forholdsvis enkle systemer, men siden det er så mange involverte, har ingen oversikt og alle jobber i hver sin retning mot noe man tror er et felles mål. Man har inkompetente arkitekter som spesifiserer systemet, man har inkompetente testere hos kunden også blir det ikke godt nok spesifisert hva som faktisk skal utvikles, så utviklere lager ikke forventet funksjonalitet. Alt i alt bruker man mye resurser bare på å rydde opp etter hverandre og koordinere arbeidet.

 

Nav er sammenslåing av flere etater, med flere systemer hvilket gjør at man har et myriad av systemer som må jobbes med over tid og få til å snakke sammen. Resten er vel bare et sammensurium av antakelser :)

 

Det generelle problemet i offentlige IT-organisasjoner er at de ikke ser på seg selv som teknologi-virksomheter. De skjønner ikke at de må bemanne opp hele "verdikjeden" med folk som har fingerspisskompetanse på teknologi. Spesifikt, så tror ledelsen i disse virksomhetene ofte at de kan bemanne opp mellomlederstillingene med rene byråkrater, folk uten teknisk utdanning av betydning, men med ønske om å "være med på å prege den offentlige digitaliseringen". Det er disse sistnevnte såpekokerne som er det store problemet. Når man er en teknologiorganisasjson, så må teknologisk innsikt gjennomsyre alle ledd. Det holder ikke å ha ingeniør- og teknologikompetanse bare på bunnen. Det må eksistere helt til topps.

 

Jeg tror grunnen til at det blir som det blir, er at byråkrater ansetter byråkrater. Når man først har fått en byråkratitung organisasjon, så har byråkratene en tendens til å ville ansette flere byråkrater. De har en tendens til å forsøke å "rigge" organisasjonen til å bli noe som kan styres av rene byråkrater. De vegrer seg på en måte litt for å ansette teknisk kompetente folk side om side med seg selv, fordi de da vet at de vil bli "trumfet" på teknisk innsikt. Det er en slags overlevelses- og beskyttelsesstrategi som kicker inn.

 

Resultatet er at disse organisasjonene forblir dysfunksjonelle når de først har kommet i dette uføret... Det gjelder sikkert NAV, og det gjelder IT-organisasjonene til andre store offentlige etater, som f.eks. Politiet og Statens vegvesen.

 

Det som trengs, rent faktisk, men som det er nesten umulig å få til i praksis, er at man må sparke ut de som bare er der basert på et ønske om å "være med på å prege digitaliseringen av det offentlige Norge", og man må få inn folk som faktisk har systemutvikling og utvikling av teknologiske systemer som fagbakgrunn og utdanning...

 

Pussig, jeg tror ikke du har jobbet i staten for å si det slik :)

  • Liker 2
Lenke til kommentar

Det generelle problemet i offentlige IT-organisasjoner er at de ikke ser på seg selv som teknologi-virksomheter. De skjønner ikke at de må bemanne opp hele "verdikjeden" med folk som har fingerspisskompetanse på teknologi. Spesifikt, så tror ledelsen i disse virksomhetene ofte at de kan bemanne opp mellomlederstillingene med rene byråkrater, folk uten teknisk utdanning av betydning, men med ønske om å "være med på å prege den offentlige digitaliseringen". Det er disse sistnevnte såpekokerne som er det store problemet. Når man er en teknologiorganisasjson, så må teknologisk innsikt gjennomsyre alle ledd. Det holder ikke å ha ingeniør- og teknologikompetanse bare på bunnen. Det må eksistere helt til topps.

 

Jeg tror grunnen til at det blir som det blir, er at byråkrater ansetter byråkrater. Når man først har fått en byråkratitung organisasjon, så har byråkratene en tendens til å ville ansette flere byråkrater. De har en tendens til å forsøke å "rigge" organisasjonen til å bli noe som kan styres av rene byråkrater. De vegrer seg på en måte litt for å ansette teknisk kompetente folk side om side med seg selv, fordi de da vet at de vil bli "trumfet" på teknisk innsikt. Det er en slags overlevelses- og beskyttelsesstrategi som kicker inn.

 

Resultatet er at disse organisasjonene forblir dysfunksjonelle når de først har kommet i dette uføret... Det gjelder sikkert NAV, og det gjelder IT-organisasjonene til andre store offentlige etater, som f.eks. Politiet og Statens vegvesen.

 

Det som trengs, rent faktisk, men som det er nesten umulig å få til i praksis, er at man må sparke ut de som bare er der basert på et ønske om å "være med på å prege digitaliseringen av det offentlige Norge", og man må få inn folk som faktisk har systemutvikling og utvikling av teknologiske systemer som fagbakgrunn og utdanning...

Tiltredes.

Et generelt problem er at teknologer og kundens "fagpersoner med påvirkingsmuligheter" ikke forstår særlig mye om hva de andre driver med. Byråkratinivået som du sikter til har som regel ikke kompetanse på noen av sidene. De forstår altså ikke brukerne særlig godt, og de forstår ikke teknologi i det heletatt.

  • Liker 1
Lenke til kommentar

Tiltredes.

Et generelt problem er at teknologer og kundens "fagpersoner med påvirkingsmuligheter" ikke forstår særlig mye om hva de andre driver med. Byråkratinivået som du sikter til har som regel ikke kompetanse på noen av sidene. De forstår altså ikke brukerne særlig godt, og de forstår ikke teknologi i det heletatt.

 

Enig...

 

Personlig mener jeg at utviklere og teknologer bør steppe opp, og "ta" noen av disse lederstillingene som i dag besittes av byråkrater. Jeg synes utviklere ofte er litt for apatiske når det gjelder å la inkompetente byråkrater "ture på". I prosjekter som går galt, så ser ofte utviklerne katastrofen komme fra 100 mils avstand. De ser underveis i prosjektet at styringen ikke er til stede, og at ting kommer til å gå galt, men likevel velger de å sitte musestille. Det er litt feigt. Flere teknologer bør våge å legge hodet på blokken, og å ta disse lederstillingene som i dag ofte er befolket av inkompetente byråkrater, spesielt i staten vil jeg si, men sikkert også i det private. Det følger ansvar med å ta lederstillingene. Men det er bedre at noen presumptivt kompetente har dette ansvaret, enn at man med åpne øyne lar inkompetente ha ansvaret helt til det går galt. Utviklere og teknologer bør ta kampen, i større grad enn de gjør i dag, mener jeg. Faglighet i ledelse er viktig.

  • Liker 2
Lenke til kommentar

Nei, det er ikke å flytte problemet. Det finnes nok av teknologer som er for sneversynte til å sitte i roller hvor de også må forholde seg til kundens behov. Altså, rene kodere mer eller mindre. Men det er ikke disse jeg vil ha på banen. De jeg vil ha på banen er de som besitter både teknisk bakgrunn og kompetanse, samt evne til å forstå kundens behov. Utviklere som evner å se på tvers i et prosjekt, på samme måte som arkitekter f.eks. evner å se på tvers når de skal tegne et hus. Arkitektene forstår, eller skal forstå, hvordan kunden har tenkt å bruke huset, samtidig som de forstår konstruksjonsteknikk, estetikk og arkitektur. Innenfor teknologiutvikling og programvareutvikling trenger man folk i den samme type rolle. Dette er mangelvare i industrien i dag.

Lenke til kommentar

 

.. og man må få inn folk som faktisk har systemutvikling og utvikling av teknologiske systemer som fagbakgrunn og utdanning...

 

Yup, men kommer ikke til å skje da ingen gode mennesker har noen som helst interesse av å jobbe for det offentlige.

Jeg er 100% sikker på at det er folk som kommer inn med et reelt ønske om å forbedre, men så blir de over tid farget av den kulturen som ofte preger offentlige etater.

 

Jeg har åpenbart ikke jobbet hos alle offentlige etater, men jeg har jobbet hos noen (som innleid) og en gjenganger er at det er alt for mange mellomledere som sitter på sin egen tue med et ekstremt behov for å vise at deres kompetanse er viktig, men samtidig med voldsom beslutningsvegring - ofte i enhver lille beslutning også. Forsøker man som innleid å gjøre noe med dette, så er det fort dårlig stemning og forsinkelser, men det er ingen som skjønner at det blir forsinkelser og budsjettsprekker av all den beslutningsvegringen heller. Forsøk å fortelle det til en av lederne litt høyere oppe, så lærer du raskt at det er vi innleide som er problemet - ikke deres egen kultur.

 

Det kommer aldri til å gå bra så lenge en bedrift ikke erkjenner at de er en IT-bedrift med utviklere. Samtidig har jeg lært mye. Kanskje det viktigste er hvor mye penger man potensielt kan spare ved å privatisere eller konkurranseutsette store deler av det offentlige Norge (eventuelt at det offentlige lærer av det private hvordan man driver butikk).

  • Liker 1
Lenke til kommentar

Nei, det er ikke å flytte problemet. Det finnes nok av teknologer som er for sneversynte til å sitte i roller hvor de også må forholde seg til kundens behov. Altså, rene kodere mer eller mindre. Men det er ikke disse jeg vil ha på banen. De jeg vil ha på banen er de som besitter både teknisk bakgrunn og kompetanse, samt evne til å forstå kundens behov. Utviklere som evner å se på tvers i et prosjekt, på samme måte som arkitekter f.eks. evner å se på tvers når de skal tegne et hus. Arkitektene forstår, eller skal forstå, hvordan kunden har tenkt å bruke huset, samtidig som de forstår konstruksjonsteknikk, estetikk og arkitektur. Innenfor teknologiutvikling og programvareutvikling trenger man folk i den samme type rolle. Dette er mangelvare i industrien i dag.

Nå begynner det heldigvis å bli en stund siden jeg var involvert i slike prosjekter. Vi fikk fatt i 1-en- konsulent som hadde de egenskapene jeg tror vi er nokså enige om er ønskelige til et SAP prosjekt. Han er fortsatt den mest verdifulle personen jeg har hatt med å gjøre uansett om det gjelder IT eller andre typer prosjekter. Helt suverent.

 

Du må nok lete for å finne den forståelsen blant arkitekter også. Best å hente inn noen som KAN konstruksjon for å sikre teknisk integritet mm.

  • Liker 1
Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...