Morten Marquard

Startup-land: It-iværksættere dropper offentlige kunder efter absurd udbudsforløb

@Nikolaj - helt enig. Tror dog ikke det er manglende "brugervenlighed" som er problemet. Forstå mig ret - systemerne er ofte uigennemskuelige og meget svære at anvende i praksis, men det skyldes de ofte mere end 1000 krav som stilles til systemerne. Som krav nu 1001 tilføjes i sidste øjeblik så "det skal være brugervenligt". Jeg vil påstå at det er manglende forretningsfokus hos ledelsen som giver problemet! Et IT system er ikke et system "der bare skal virke", men en uadskillelig del af forretningen. Hvis ledelsen ikke med 5-7 krav klart kan beskrive hvad de vil opnå og hvodan systemet skal indgå som en integreret del af arbejdet kommer man ikke langt. Kommunikationsopgaven omkring systemet bliver simpelthen for omfattende grundet de mange krav. Pga mængden af krav vil der ofte være modstridende krav i kontrakten hvilket jo gør det temmelig svært at levere en løsning.

17. december 2014 kl. 09:00
Er det sociale intranet løsningen i din organisation? 5 spørgsmål du skal stille dig selv

Hej Anja, Glimrende indlæg. Tak for det. Grafikken afspejler på glimrende vis "udviklingen" i intranets de sidste 20 år. Desværre er hovedårsagen til intranet's manglende success nok netop udvikling som afspejles i figuren!

Argumentet om at det sociale intranet vil gøre videndeling enklere er en smule hult - specielt når man har hørt det så mange gange før, senest med web 2.0 og blogs som skulle gøre tingene enkle og dermed fremme videndelingen.

Problemet med Yammer, som med mange andre sociale medier, er, at de lever udenfor den kontekst som medarbejdere og virksomheder befinder sig i, dvs de værktøjer som anvendes til at udføre arbejdet. Dermed skabes der endnu en platform hvor viden kan deles, udover alle de platforme der allerede findes fx emails, intranets, web 2.0 og nu sociale medier. Nogle medarbejdere vil være med, andre ikke. Virksomheder og medarbejdere har ikke brug for flere platforme for videndeling! Tværtimod har de brug for færre platforme, helst blot en, for at sikre overblik og samarbejde.

Eksemplet med salgschefen der i et møde skriver til alle sine sælgere for at få input til en mulig kunde holder basalt set ikke. Dels forstyrrer han sine medarbejdere i andre gøremål, dels virker det temmelig uforberedt og "heroisk" at tro at problemer kan løses på den måde. Hvis alle "larmer" ved at kontakte alle ender det med at vi ingenting når i forsøget på at svare og holde sig orienteret om hvad der foregår. Denne form for "larm" kender og oplever de fleste allerede i overfyldte indbakker i deres email.

Anvendes sociale medier derimod i konteksten af forretningen, i eksemplet i den forretningsproces der understøtter salgsarbejdet er sagen en helt anden. Processen er rammen for det arbejde som skal udføres, og sikrer at relevante medarbejdere over tid bringes ind i teamet for at hjælpe med fremdrift. Når viden deles i en aktivitetsstrøm i konteksten af processen sikres det, at det er teamet som arbejder med aktiviteten der involveres, fremfor at "larme" i hele salgsorganisationen. Udover den strøm der foregår i processen kan man vise strømme med tværgående information fx baseret på emner, kendt bl.a. fra hashtags hos fx Twitter.

McKinsey Global Institute har analyseret værdien af bl.a. sociale medier og peger på et stort produktivitets potentiale, læs fx http://www.exformatics.dk/Nyheder/mckinsey.aspx. McKinsey peger på at videnmedarbejdere anvender op mod 28% af deres tid på at læse og besvare emails, og en tilsvarende undersøgelse vistnok her på Version2 viste at op mod 25% af danske IT medarbejdere bruger mere end 50% af dagen på at læse og svare på emails! Næppe den mest produktive måde at samarbejde på. De konstante skift af kontext stresser medarbejderne og fjerner fokus fra de vigtige opgaver.

Fem gode råd for at få success med sociale intranets

  1. Identificer de vigtigste forretningsprocesser, herunder ejere og andre stakeholders. Navngiv processerne.
  2. Sæt strøm til processerne, ved at facilitere fremdriften elektronisk, hvor processen løbende justeres til at afspejle virkeligheden.
  3. Gør det muligt at kommunikere i kontexten af processerne - typisk ved brug af aktivitetsstrømme
  4. Integrer de forskellige systemer så de spiller godt sammen - kedeligt og dyrt ja, men en vigtig forudsætning for success
  5. Begræns interne emails til et absolut minimum - #NoEmails

Naturligvis kræver det engagerede medarbejdere. Når ledelsen sætter en klar retning og kommunikerer den tydeligt er det ofte let at finde engagement. Specielt når tingene fungerer.

9. april 2014 kl. 07:49
CPR-data – som en åben (telefon)bog

Problemet er - som Peter netop skriver - at cprnr bruges som en nøgle. Hvis man får en bøde i metro eller s-tog skal man oplyse cprnr. Kender en som har fået en bøde på denne måde. Problemet er sådan set ikk bevisbyrden - men al det bøvl man skal håndtere efterfølgende. Uanset hvad koster det - og at kræve erstatning for bøvlet er næppe en sag man kan vinde. Så jeg holder det hemmeligt...

11. juni 2013 kl. 19:28
ITU-forsker: Her fødes de offentlige it-skandaler

Glimrende pointe. Prøv at høre juristerne om de ikke fremover kan tage hensyn til de arbejdsgange man anvender ifm lov justeringer. Spændt på deres kommentarer :-)

Helt enig omkring vandfaldsmodellen. Lene's arbejde understreger vist pointen nemlig at man ikke kan definere alt før man går igang. Spørgsmålet er så: hvad gør man som offentlig myndighed hvis man skal overholde udbudsreglerne? Vil stille dette spørgsmål på konferencen imorgen til Devoteam og Rambøll. Spændt på hvad de svarer!

27. februar 2013 kl. 16:56
Consumerization er blevet normen - it-afdelingen må tilpasse sig

Helt enig - BYOD er der ikke meget nyt i. De fleste medarbejdere har i mange år kunnet læse mail via webben (Outlook Web Access). I og med at de har kunnet tilgå e-mail på denne måde har de tilgået vigtige virksomhedsinformationer fra eksterne enheder. I mange år har man kunnet læse e-mail via sin telefon. I mange tilfælde har det nok været en firmatelefon - men mon ikke enkelte skulle have sat e-mail op på deres private tablet. Voila - BYOD er en realitet.

Diskussionen om BYOD drejer sig således blot om virksomheden udelukkende tillader at man kan læse og besvare e-mails fra eksterne enheder (fx en PC i en lufthavn) eller om man åbner op for andre vigtige data i virksomheden.

Men det er ikke kun sikkerhed, der er et issue med at bringe egne enheder og derfra læse data. Hvad med videndelingen? Ufatteligt meget går da tabt, når man "lige læser en mail" på vej til et møde. Informationerne i den mail og dit eventuelle svar blafrer i vinden og lander måske i nogle enkelte, der har været så "heldige" at finde vej til cc-linjen.

På min arbejdsplads har vi gennet det sidste års tid tilladt medarbejdere at tilgå virksomhedsdata via deres private mobiltelefoner og tablets. Med en app kan de læse informationer i aktivitetsstrømmen, se dokumenter, søge o.l. Data opbevares ikke på enheden og dokumenter gemmes ikke her. Sikkerhed er baseret på (1) brugerid + password som for e-mails samt (2) enhedens unikke ID. Den enkelte enhed skal godkendes af den ansvarlige, før man kan få adgang, og den kan dermed også nemt spærres, hvis den bortkommer.

Det centrale er således ikke BYOD eller ej, da BYOD allerede er tilladt for emails. Men hvis virksomhederne kun tillader BYOD til emails så har bruger medarbejderne emails til alt. Dermed anvendes interne systemer, fx intranets ikke, og videndelingen går fløjten. Derfor bør man naturligvis åbne op for videndeling.

22. oktober 2012 kl. 15:44
Intranettet: fra dokumentarkiv til samarbejdsplatform

Kære Anja, Tak for indlægget.

Du nævner intranet-teamet, der "hele tiden skal være i tæt dialog med resten af organisationen om deres behov på intranettet."

For mig at se er det en stor fejl. Det svarer vel til at sige, at man har udnævnt et nyt team til at varetage ledelsesopgaverne for alt der drejer sig om videndeling og samarbejde. Lidt paradoksalt.

Ledelse - måske vi skal kalde det digital ledelse - drejer sig om at sikre at viden forankres, deles og konsolieres i afdelinger og hele virksomeheden. Det er ikke noget som kan overlades til et "intranet-team".

Et intranet er defineret som "et internt internet" (Netscapes definition anno 1995) - men har alt for længe fokuseret på at være der hvor menuen fra kantinen, telefonbogen og diverse instruktioner/manualer som ofte ikke er opdaterede placeres. Måske er det derfor at der er så relativt få brugere af intranettet - når man altså lige ser bort fra menuen i kantinen som ofte udgørt 90+% af den samlede trafik.

Fremfor at flytte det "rigtige" arbejde ind i intranettet foregår dette stadig mange steder væk fra intranettet. Hvorfor? Måske fordi man ikke ledelsesmæssigt har forstået vigtigheden af at fange arbejdet digitalt for derigennem at opnå større effektivitet.

Vi møder ofte intranetansvarlige, som er placeret i kommunikationsafdelingen - men hvordan kan vores interne arbejde mest være et spørgsmål om kommunikation?

I moderne videnvirksomheder er alt det vi gør noget som kan og bør foregå i intranettet. Vi bør fastlægge vores arbejdsgange således, at de kan udføres i intranettet og således at relevant viden flyder til de involverede afhængigt af hvad der sker. Vi bør kunne danne relationer til kolleger og eksterne samarbejdspartnere og videndele mv i konteksten af det vi arbejder med. Dermed bliver intranettet "socialt" som basalt set drejer sig om at vi kan kommunikere med hinanden i intranettet. Om det er et intranetprojekt, ny salg til en mulig kunde, leverance af en løsning til vores kunde er sagen uvedkommende. At fange konteksten sikrer, at viden hurtigere kan forstås - viden og informationerne skal ud af medarbejdernes hoveder og ind i intranettet - hvis det er det, det skal kaldes?

10. oktober 2012 kl. 14:23
Fingrene væk fra send-knappen!

@Lars dit forslag til auto-reply er bestemt ikke tosset. Dog vil jeg anbefale at der svares på emails når du er mindst oplagt - og starter dagen med det sværeste og vigtigste. På det tidspunkt er hjernen frist - og derfor klarer vi de sværeste opgaver bedst. Så kl 11:30-12:00 før frokost og igen kl 15:30-16:00 inden dagen afsluttes er nok det bedste.

Læs også http://www.erica.biz/2011/no-email/ - andre har gode og interessante erfaringer.

5. marts 2012 kl. 22:35
Dansk it-firma: Befriende med e-mailfri januar

@Jacob jeg vil svare både ja og nej til dit spørgsmål.

Nej - det er naturligvis ikke emailens skyld. Det er mennesker som bruger emailen - ikke emailen der af sig selv sender emails. Så det er indlysende at det er brugen af teknologien som er skyld i problemerne.

Ja - det er naturligvis emailens skyld. Problemet med email er at den foregår i en anden "kontekst" end der hvor vi udfører vores arbejde. Når vi får en email eller skal sende en skal vi skifte "kontekst" fra vores digitale arbejdsplads, typisk i intranettet, til et andet system. Dette skift af "kontekst" koster ressourcer fra medarbejdernes side. Og dermed er email mindre effektivt end fx sociale medier (vi kan også kalde det et indlejret email system) der hvor vi udfører vores arbejde.

Jeg plejer at sammenligne det med da vi først fik emails. På det tidspunkt skrev rigtigt mange deres besked i Word, hvorefter de fremsendte Word dokumentet. Fremfor at læse beskeden i Outlook skulle dokumentet åbnes for at læse beskeden. Nu er vi blot i næste fase - hvor det selvstændige email system forsvinder og indlejres i den platform vi udfører vores arbejde i.

Om det er mindre junk - eller slet og ret mindre information og derfor mere exformation (læs Tor Nørretranders "Mærk Verden") er vi ikke i tvivl om. Ofte stoler vi ikke på interne systemer og sender derfor ofte lige en mail til fx projektlederen eller sælgeren for at få den seneste status på projektet eller kunden. Dermed "opdrager" vi folk til ikke at stole på de interne IT systemer - hvilket naturligvis medfører en øget mailtrafik. #NoEmail medfører at interne systemer opdateres, bl.a. af den enkle årsag at forespørgslen om status foregår i projektrummet - hvor status tydeligt fremgår. Dermed begynder vi at stole på de informationer vi har internt - hvilket betyder mindre kommunikation om basale ting.

10. februar 2012 kl. 08:19
Twitter-holiker? E-mail og Twitter er mere vanedannende end sprut

I januar forbød vi interne emails, #NoEmail.

En af de interessante og overraskende side-effekter er, at min dårlige vane med at tjekke mails hele tiden og alle steder er mindsket kraftigt - for ikke at sige næsten forsvundet.

Når man ser på det udefra er det indlysende at det er spild af tid og manglende fokus på det vigtige - udfordringen er dog at komme væk fra dårligt indgroede vaner. Det er i overraskende grad lykkedes.

8. februar 2012 kl. 01:35
Dansk it-firma: Befriende med e-mailfri januar

Anders Elbak, IDC, mener det er nemmere at komme i kontakt med folk på den amerikanske vestkyst via email. Jørgen Rahbæk, produktchef i Microsoft med ansvar for Unified Messaging, svarer til #NoEmail at "modtageren behøver ikke svare med det samme og beskeden bliver gemt, det er nemt at tilføje flere modtagere og sende filer og andre typer af indhold" se http://www.comon.dk/art/213153/microsoft-derfor-vil-email-ikke-doe. Det er der næppe meget nyt i - det gælder jo også aktivitetsstrømme i diverse sociale medier. Måske Unified Messaging er knap så Unified når det kommer til stykket?

Jeg vil på det kraftigste anbefale Jer, at I overtaler jeres respektive organisationer til i en måned at droppe emails. Det vil helt sikkert ændre jeres opfattelse og perspektiv - og desuden spare Jer en del tid.

Den unge generation har droppet email og gået over til aktivitetsstrømme i sociale medier som Twitter, LinkedIN og Facebook. Jeg tror også alle os 30+ kan gøre det.

Og så lige en mindre korrektion til Anders kommentar ovenfor. Beskedder i aktivitetsstrømmen er automatisk arkiveret på relevante forretningsobjekt - så vi behøver ikke gøre andet end at drøfte tingene online.

8. februar 2012 kl. 01:31
Den historie vi bare for en gangs skyld gerne ville høre….

Jeg er helt enig i at godt håndværk er forudsætningen for at få sådanne projekter i mål. Desværre er gode håndværkere uhyre svære at få fat i. Jeg ansætter gerne et par stykker hvis nogle kender sådanne folk :-)

Jeg vil derfor tilføje "Bli ved din læst" til ovenstående. Alt for mange undervurderer det at formulere krav og udvikle systemer. Ledelsen bør fokusere på ledelse - dvs hvilke overordnede forretningsmæssige mål vil man opnå, og så styre projektet udfra disse mål.

Hvilke kompetancer kræves der så? Vi plejer at lede efter folk med evnen til hurtigt at sætte sig ind i nye forretningsområder hurtigt samtidig med at de har en dyb teknisk forståelse - arkitekturmæssigt såvel som udviklingsmæssigt, og gerne kombineret med tilstrækkelig procesforståelse til at de kan indgå i teamwork med andre og følge en fælles metodik for at få projektet i mål. Hvis man ikke forstår hvad et program er og undervurderer udfordringen så går det helt galt. Det at skrive koden er ofte den mindste af alle udfordringerne hvis man kan sit håndværk. Kan man det derimod ikke aner man ikke hvad man arbejder med og ender derfor ofte med mystiske algoritmer som basalt set ikke giver mening. Det er sådan set ikke programmet der er fejlen - men derimod algoritmen som fra kravstiller er lavet forkert - og sådan en slipper man aldrig af med igen.

17. januar 2012 kl. 01:15
Så kom softwaretest endelig på bloggen

Hvis fejlene primært stammer fra kravene så er udfordringen at finde en model at lave gode krav på.

Hvordan gør man så det bedst? Noget tyden på at mange års erfaringer med at hyre konsulenthuse ikke sikrer success. Men hvad gør man så?

Vores bud er:

  1. Få styr på de overordnede forretningsmæssige mål - hvad vil vi opnå
  2. Start et agilt projekt med en udbyder som på 3-8 uger kan understøtte jeres unikke forretningsobjekter og forretningsgange uden programmering (dvs vha et semantisk web, web 3.0).
  3. Kom i mål indenfor tidsplanen - det sender et vigtigt signal til organisationen. Juster scope hvis det kniber så tidsplanen overholdes
  4. Sæt ressourcer af til opfølgning - og implementer justeringer løbende - gerne hver uge
  5. Konstant forandring sikres ved, at brugere i organisationen får et mindre budget til selv at gennemføre mindre ændringer. Det sikrer stort ejerskab - og det er vores erfaring at brugerne passer rigtigt godt på pengene
16. januar 2012 kl. 17:55
Kold tyrker: Dansk software-firma dropper interne e-mails

Hej Kasper, Alle bruger intranettet - og fordelingen mellem mænd og kvinder er 17-5 - vi arbejder på en bedre fordeling mellem mænd og kvinder.

Vi arbejder med produktudvikling og leverance heraf - samt naturligvis salg, marketing og support. Vi bruger intranettet til al intern IT.

Mht medarbejdernes kommentarer - de følger primo februar. Er spændt på deres feedback.

16. januar 2012 kl. 11:32
Kold tyrker: Dansk software-firma dropper interne e-mails

Hej Kasper, Primo februar laver vi en sammenligning af antallet af emails internt og eksternt (dem vi har sendt) i november hhv januar. Som sagt ser det allerede rigtigt positivt ud. Mvh Morten

16. januar 2012 kl. 10:56
Så kom softwaretest endelig på bloggen

Der ER fejl i alle IT produkter! Simpelthen fordi det er et vilkår, at mennesker begår fejltagelser, uanset hvor dygtige vi er, hvor meget vi gør sig umage, og hvor gunstige betingelser vi har.

Jeg er meget enig. Udfordringen er imidlertid at der også er fejl i de kravbeskrivelser og specifikationer der udarbejdes. Jeg vil endda gå så langt at hævde at der er flere fejl i beskrivelserne end i løsningerne - af den simple årsag at løsningerne kan udføres på en maskine mens beskrivelserne er uformelle og kan tolkes på mange forskellige måder.

Det centrale spørgsmål bliver derfor: Hvordan kan vi lave en formel specifikation af systemet som kan udføres af en maskine og som brugerne umiddelbart kan forholde sig til? Dvs en semantisk beskrivelse af systemet som ikke skal fortolkes af mennersker. Hvis det er en sådan specifikation der er tale om så er jeg helt enig. Start ikke implementationen før den er på plads. Af den simple årsag at der ikke er nogen implementation efterfølgende.

Vi arbejder netop med formelle teknikker til at lave sådanne specifikationer og har et system som kan omsætte dem uden menneskehånd til færdige løsninger. Jeg kalder det nogen gange Web 3.0.

Hvis vi skal gøre os håb om at få bedre IT-produkter på markedet til en fornuftig pris og inden for en fornuftig tidsramme

så skal vi arbejde mere agilt med formelle specifikationer i et semantisk web. Og stille krav om realiseringsprocesser, fra beslutning til implementation og ibrugtagning på uger - fremfor år.

13. januar 2012 kl. 15:36
Nyt ESDH-dogme: 40 % forberedelse, 20 % implementering, 40 % opfølgning

Jeg er helt enig i at opfølgningen er det absolut centrale. Vi har kunder som over de sidste år næsten hver uge har justeret i deres ESDH løsning - fordi forretningen ændrer sig og de bliver klogere.

At bruge lige så megen tid på forberedelse som på opfølgning kan jeg derimod ikke se fordelen i - men kan desværre godt genkende billedet med at mange bruger mere end dobbelt så megen tid og penge på at beslutte sig om ESDH end på at indføre ESDH. Vi har set beslutningsprocesser der tager flere år - efterfulgt at et implementeringsprojekt på ganske få måneder. Problemet i denne model er, at organisationen efter en så lang beslutningsprocess er kørt træt, og derfor ikke orker at gå igang med en opfølgningsfase. Den lange beslutningsvej for forandringer umuliggør derfor opfølgningsfasen som er altafgørende for success.

Såfremt man virkelig vil fokusere på opfølgningen så skal man se på beslutningsprocesserne for at gennemføre forandring, dvs ledelse. Hvis der hver gang skal udarbejdes lange kravspecifikationer og business cases stopper det de små og indlysende gevinster som samtidig motiverer medarbejderne og sikrer en forankring af løsningen i organisationen. Naturligvis skal større forandringer analyseres, men for at sikre fremdrift skal beslutningsvejen gøres kort og præcis. Dette er ledelsens udfordring. Vi anbefaler ofte vores kunder at give udvalgte forretningsbrugere et mindre budget de kan bruge til løbende forandringer. Det er vores erfaring at brugerne "holder på pengene" og får megen valuta for pengene.

13. januar 2012 kl. 13:34
Hvordan kommunikerer du?

På min arbejdsplads har man besluttet at januar er "email fri måned" - for interne emails. Baggrunden er at emails ofte medfører stress og kaos da medarbejdene skal "forlade deres arbejde" for at læse og skrive emails, for derefter at finde tilbage til deres arbejde. Disse "context swicth" tager tid - hvilket betyder lavere produktivitet og mere stress.

Erfaringerne fra de første dage er gode. Jeg "faldt kun i" selv to gange. I begge tilfælde svarede jeg hurtigt og uden at tænke mig om (suk) og spildte derfor både min såvel som mine kollegers tid.

Fremfor at bruge interne emails har vi de sidste 2-3 år anvendt "sociale medier" for den interne såvel som for dele af den eksterne kommunikation. Over det sidste år er antallet af interne mails faldet, men med ovenstående initiativ forsøger vi nu at fjerne de sidste. Formålet er at afsøge mulighederne i de sociale medier og se om de ikke helt kan erstatte emails, og få alle til at bidrage med ideer for at øge produktiviteten og nedbringe stress. Allerede efter 3 dage er der kommet adskillige gode ideer som vi er ved at realisere.

Vi bruger online chat, både Skype og andre ting, for kommunikation med kunder og partnere. Ifm support af vores kunder tilbyder vi naturligvis online chat som er populært og sparer tid - både for os og vores kunder.

Jeg finder det interessant at mange beskriver brugen af telefonen som værende faldende. Jeg har samme erfaring - men har dog lært at små opfølgende samtaler kan have stor færdi for at undgå misforståelser.

Twitter er en af mine favoritter. En af de største fordele ved SMS og Twitter er (eller måske var) at man skulle udtrykke sig på blot 140 tegn. Det at fatte sig i korthed er en fordel for specielt læseren - men kræver langt mere af forfatteren hvilket egentlig er ok.

Beklager så at jeg har overskredet de 140 tegn.

I kan iøvrigt læse mere om vores sociale medier her http://exformatics.dk/produkter/mikroblogging.aspx

4. januar 2012 kl. 12:06
Glem besparelserne

@Morten Jensen På jobcenter København har Magnus Nilsson fra IT Universitetet i København undersøgt arbejdsgange og systemer, som blev præsenteret på Infinit seminar i januar på ITU, se http://www.infinit.dk/dk/formidling/reportager/saet_stroem_til_forvaltningen.htm. Jeg blev overrasket over medarbejdernes velvilje til forandring specielt når vi fik beskrevet de op mod 10 forskellige IT systemer, herunder flere "portaler", som de skulle holde opdateret omkring en jobansøger.

Udfordringen for leverandørerne er derfor at sikre at denne velvilje og begejstring fastholdes.

Tror du har ret mht samme løsninger igen og igen. Dit eksempel med CPR-brokeren er vel et glimrende udtryk for dette. Opslag i CPR burde være relativt enkel at realisere. Jeg tjekkede netop på CPR.dk og kunne ikke her finde en web service grænseflade for at hente cpr-oplysninger. Ikke megen selvbetjening over dette. Det burde jo ikke tage mere end et par timer at realisere CPR opslag - hvis ellers informationerne var til rådighed.

5. juni 2011 kl. 10:43
Glem besparelserne

Eksemplerne ovenfor illustrerer jo med al tydelighed at forvaltningsleddet ikke kan håndtere digital forvaltning, det være sig pasbillede eller registreringsattest! Det offentlige kan stille krav til borgeren om sådanne analoge ting men burde lovgivningen ikke blot sikre at vi som borgere kan interagere med forvaltning og myndigheder elektronisk?

Er problemet basalt set ikke at man forsøger at "klistre" digital selvbetjening på en analog forvaltning? Er det ikke den manglende digitalisering af arbejdsgangene som er problemet?

Hvordan skabes den nødvendige begejstring hos borgere og medarbejdere hos myndighederne så alle kan se fordelen i en på samme tid bedre servicering af borgerne kva en tættere dialog samtidig med en mere effektiv forvaltning kva den digitale interaktion?

4. juni 2011 kl. 12:49
Værsgo Lars Løkke - her er dine effektiviseringer

Hej Jørn, Tak for din kommentar - specielt omkring muligheden for at udveksle arbejdsgange som en smuk tanke.

Nøgleudfordringen her er naturligvis brugerinvolvering. Jeg er helt enig i at brugerne hverken kan eller skal til at være programmører. Men brugerne skal formulere krav til hvordan arbejdet tilrettelægges på en mere eksplicit måde end ved blot at skrive et Word dokument i fri prosa. Ellers bliver afstanden mellem bruger og system alt for stor - hvilket der jo er mange eksempler på.

Såfremt brugerne selv kan beskrive arbejdsgangene på et overordnet niveau så vil de involvere sig mere i tingene og endda løbende justere arbejdsgangene. Denne øgede involvering af brugerne medfører en større arbejdsglæde fra medarbejderne som nu synes de har mere kontrol over tingene.

Vi har idag kunden hvor brugerne selv har defineret og justeret arbejdsgangene uden at vi har været involveret. De retter naturligvis henvendelse omkring forskellige ting engang imellem hvor vi eller andre så hjælper. Men derved lærer de blot mere om hvordan de kan beskrive arbejdsgangene som de så "bygger ind" i deres andre arbejdsgange.

Så brugere kan idag, i et vist omfang, beskrive deres arbejdsgange formelt. Fra tid til anden behøver de hjælp for at lære mere om hvordan arbejdsgangene beskrives. Når brugerne justerer beskrivelsen af arbejdsgangen så følger systemet øjeblikket med, hvorved brugerne får et feedback på deres justering med det samme. Den ændrede beskrivelse skal ikke først igennem et konsulenthus som skal beskrive og implementere de nye rutiner før tingene sættes i produktion.

Muligheden for at justere i den arbejdsgang som anvendes og øjeblikket se konsekvenserne af det betyder at ledelse og medarbejdere involverer sig mere i beskrivelse af arbejdet.

Du har ret i, at der er forskellige forretningssystemer som formodentlig vil løse dette forskelligt. Derfor er der behov for en standard indenfor arbejdsgange for eksempel BPMN som KL's arbejdsgangbank understøtter. Det løser ikke alle problemer men det er et udtryk for at der arbejdes på at standardisere tingene. Jeg har længe været på jagt efter standarder og hælder mest til det som IT Universitetet kalder Dynamic Condition Response Graphs (se fx http://www.itu.dk/~rao/pubs_accepted/fsenpaper.pdf for mere information) men dette er desværre ikke med i BPMN 2.0 standarden (omend der er tiltag som peger i denne retning).

29. maj 2011 kl. 15:29