Ledelse av systemutvikling (MS kap. 10)

Presentasjon om: "Ledelse av systemutvikling (MS kap. 10)"— Utskrift av presentasjonen:

1 Ledelse av systemutvikling (MS kap. 10)
Personalhåndtering Vellykket systemimplementering Organisasjonens basis (”legacy”) systemer Hvordan kan vi måle nytten av IT systemer? MS kap. 10

2 Personaladministrasjon
MS kap. 10

3 Mange bedrifter har svak personaladministrasjon
Store bedrifter ofte bedre enn små, har ofte faste rutiner for personaladministrasjon I små bedrifter er dette helt opp til lederen Viktig å utnytte potensialet i hver medarbeider Entusiasme, følelsen av å jobbe for felles mål, kompetanseoppbygging, m.m. er sentralt for å få 100% ut av medarbeiderne Insentiver for den enkelte i overensstemmelse med organisasjonens overordnede mål MS kap. 10

4 Flat ledelsesstruktur
Alle deltar i styring og ledelse Men likevel en leder som har siste ord Krever mindre av lederen, andre kan ta seg av deloppgaver, et team kan ha alle gode egenskaper samlet Utnytter kunnskapen til hver ansatt Egnet for kunnskapsbedrifter MS kap. 10

5 Hierarkiske bedrifter
Ledelsesstyrte Beslutninger tas på toppen Krever gode ledere Gode ledere er en mangelvare Gode ledere koster mye (men dårlige ledere koster mer!) Mange krav: Analytisk (ta beslutninger ut fra tall) Kreativ (kunne se nye muligheter) Sterk (tørre å ta upopulære beslutninger) Sosial (få medarbeiderne til å yte, gi medarbeiderne følelse av at de er viktige, en del av teamet) Modig (ta risiko) Konservativ (begrense risiko) og som vi ser: ofte motstridende MS kap. 10

6 Lederen er viktig Tradisjonell bedrift, begynner å gå dårlig (mister markedsandeler, redusert fortjeneste), på kanten av stupet… Ny leder… Dramatiske forbedringer, men samme bedrift, samme markeder, ofte de samme produkter Dette er mulig fordi en god leder kan Få alle til å yte sitt ytterste Felles innsats for felles, klart definerte mål God organisering Personalressursene er altså ikke faste, de kan utnyttes godt eller dårlig Eksempel: Lotus (behandlet i kap. 4) MS kap. 10

7 Utnytting av personellressurser
Case UPS - United Parcel Service (UPS) - privat ”postforetak” Sjåførene hadde en viktig posisjon (kundekontakt m.m.) Stort gjennomtrekk, UPS ønsket å beholde sine sjåfører En undersøkelse viste at de fleste mislikte jobben med å laste bilen hver morgen (kjedelig og tungt) Lot en annen gruppe ta seg av denne jobben. Fikk selvfølgelig høyt gjennomtrekk her men det hadde mindre betydning da nyrekruttering var enkel (høy lønn, ingen bakgrunnskrav, enkel opplæring) MS kap. 10

8 Motivasjonsfaktorer MS kap. 10

9 IT personell (undersøkelser)
Behov for å vokse i jobben, lære noe nytt, bruke ny teknologi, få øket ansvar og utfordringer Lite krav om interaksjon med andre, kunne gjerne jobbe alene (”trenger ikke møter”) kan skape problem i kontakt med brukere Dette kan endre seg etter som faget blir mer modent (utvikling i team, mange spesialiteter nødvendig) Vedlikeholdsarbeid (f.eks. av et basissystem), mindre utfordrende. Står dessverre for en stor del av programvarearbeidet. Kan øke bredden i oppgavene ved å organisere i grupper som for ansvar for flere systemer Få fram helheten og betydningen av arbeidet arbeide tettere med brukerne? MS kap. 10

10 Software Engineering For rigide metoder kan gjøre programmering kjedelig Lite kreativitet, rutinejobb Samtidig er dette en jobb som krever dyktige personer En motsetning som kan føre til tap av de dyktigste MS kap. 10

11 Vedlikeholdsarbeid Blir ofte sett på som irriterende (systemet var bra nok før, hva er galt nå) Ofte mye arbeid for små resultater (tar tid å sette seg inn i problemstillingen og systemet) Kan være vanskelig, lett å gjøre feil Vedlikehold av et dårlig system er lite tilfredsstillende (brannslukking) Mer interessant i et system med god struktur (perfeksjonere) Enklere å bygge tillegg som er tilpasset systemets struktur, mer vanskelig å gjøre strukturendringer MS kap. 10

12 Dagens Næringsliv Fra 2005, like aktuell i dag. MS kap. 10

13 Aftenposten 2008 og i 2011 Store deler av avisen er fylt opp av søknader etter IT personell Mange firma gir bonus til ansatte som klarer å rekruttere nye folk Dette blir bare mer hektisk framover: IT studier bygges ned, mange IT lærere pensjoneres nå MS kap. 10

14 Utviklingen framover Finanskrisen virker inn
Men det er akkurat nå bedriftene burde satse på IT IT kan gi mer effektiv produksjon, høyere kvalitet og lavere kostnader MS kap. 10

15 Case - vedlikehold: Propellerprogram for Oshaug Metall
Første versjon: fast antall målepunkt pr. blad, statisk brukergrensesnitt, inntasting av verdier Jobb-belønning: Se at systemet fungerer, meget stor produktivitetsgevinst, høyere kvalitet, fornøyde brukere Ny versjon: fritt antall målepunkt, dynamisk (generert) brukergrensesnitt, innlesing av verdier fra regneark - krever strukturelle endringer Jobb-gevinst: Ble stort sett tatt ut i første utgave. Men: motivasjonen for å gjøre arbeidet blir større når en ser dette som et ledd i bedriftens strategiske satsing på kvalitet MS kap. 10

16 Implementering av nytt system
Ofte for stor fokus på teknologi og på nye innovative løsninger Bruker vil ha noe som fungerer! Det vil ha systemet nå! Endringer (fra gammelt til nytt system, fra gamle til nye måter å gjøre jobben på) kan være vanskelige for brukerne Lære nytt system (grensesnitt) Takle problemer med det nye systemet Lære å gjøre jobben på en ny måte Erfaringer fra tidligere blir mindre verd Motta klager i overgangsfasen Enklere med in-house utvikling MS kap. 10

17 Oppdatering - Case: Microsoft Office
I begynnelsen hadde vi minimumsversjoner av Windows og Office Men for noen år siden begynte disse å bli komplette, dvs. de tilfredstilte de mest avanserte brukerne Nå er det mest garnityret som er endret i nyere versjoner Men det er en stor kostnad å tilpasse seg nye brukergrensesnitt Derfor blir mange værende i gamle utgaver, som XP og Office 2003 (i noen tilfeller kan dette også skyldes ren konservatisme) Mens utviklerne ofte har fokus på nye funksjoner, vil de som benytter systemene kunne ha fokus på helt andre områder, som for eksempel: Raskere oppstart Bedre batterier på bærbare enheter Lettere enheter Gode, enkle og sikre backuprutiner Enkel installasjon og oppsett av nye maskiner Dvs. på løsninger som gjør hverdagen enklere MS kap. 10

18 Min erfaring Av og til kan de kreative og avanserte programmene ha en gjennomslagskraft Men ofte etterspør brukerne små kosmetiske forandringer Siden disse virket ubetydelige for utvikler blir de ofte ignorert eller nedprioritert Men for en bruker som sitter ved systemet store deler av dagen kan små detaljer ha stor betydning Moralen er derfor: Lytt til brukerne

19 Organisere/styre endringer
Sponsor Legitimerer endringene (nytt systemet, nye funksjoner, nye prosesser…) Gjøres gjerne av en i ledelsen, har ansvar for å motivere VIKTIG, ofte helt nødvendig! ”Change agent” Får endringene til å skje (ofte en IT person) Målgruppe Bruker (gruppe) som skal lære en ny måte å gjøre jobben på Viktig å få fram: Omfanget av det nye systemet/de nye funksjonene Grad av delaktighet (”commitment”) fra sponsor Dyktigheten til ”change agent” Støtte/motstand fra målgruppen MS kap. 10

20 Case: BOC (produsent av industrielle gasser)
BPR prosjekt 9 team, hver team så på en prosess 6 måneder for bakgrunnsstudie, hvert medlem så på alt Bedriftslederen hovedsponsor for alle team, men avdelingsledere praktisk sponsor, praktisk vanskeligheter da disse var opptatt også med andre gjøremål Fikk opplæring i det å være sponsor Konsekvenser av endringer for de ansatte Hvordan ansatte skal tilpasse seg endringene Bygge ”sponsorsystemer” nedover i organisasjonen ”Hva med vår organisasjonskultur kan føre til at prosjektet ikke lykkes?” ”Ber vi om for mye?” ”Er prosjektet realistisk?” Ærlighet, realisme, finne mulige hindringer MS kap. 10

21 Case: BOC - ett endringsprosjekt
Rutiner for gassleveranse (beholdere), regning, m.m. Papirbasert: sjåførene fikk kjøresedler av kontoret krysset av på leveranseseddel til kunden håndskrevne notater til kontoret Krevde mye etterarbeid Feilbefengt MS kap. 10

22 Nytt system Over til PDA (personal-digital-assistant) eller en PODD (point-of-delivery-handheld device) Kjøreseddel lastes ned elektronisk til PODD om natten Gir informasjon til de som skal laste bilene Sjåførene tar med PODD, som også gir kjørerute Kunden signerer for leveransen rett på PODD enheten PODD skriver kvittering til kunden Sjåføren setter PODD tilbake i docking-stasjonen, og data overføres til fakturasystemet, osv. La vekt på å diskutere det nye systemet i organisasjonen; opplæring, scenario, testcase med stigende vanskelighetsgrad; hjelp og støtte MS kap. 10

23 Men I dette prosjektet ble helt ny teknologi innført, men rollene var stort sett de samme (laster, sjåfør, kunde). Andre prosjekter kan kreve at de ansatte lærer nye roller, f.eks.: Sjåfør, fra transportør til selger (når en bedrift overlater salgsansvaret til sjåførene) La studenter og ansatte utføre administrative oppgaver selv, istedenfor å bruke kontoransatte (større krav til brukervennlige system, opplæring?) Eller prosesser kan endres dramatisk: Selge over Internett istedenfor gjennom butikker (hva sier butikkeierne?) La journalister ta fotografier, og sette avisen selv (hva sier fagforeningen til fotografene og grafikerne) Da kreves det enda mer av sponsorer og de som skal være ansvarlig for å implementere endringene MS kap. 10

24 Forbedring av basissystemer
”Legacy systems” Y2K problemet viste oss i hvor lang levetid enkelte basissystemer har Mange systemer utviklet i 70-årene er f.eks. fortsatt i bruk Gjelder stort sett basissystemer: Flyovervåkning Store banksystemer Finansielle systemer Vedlikeholdssystemer Systemer for offentlig forvaltning (trygd, sosial…) MS kap. 10

25 Problemer Store og komplekse systemer Inneholder store mengder data
Spesifikasjoner bygget inn i systemet (eksisterer ofte ikke utenfor disse) Store beløp investert i opplæring Ofte vanskelig å endre Ikke alltid så lett å lage et nytt system Systemene virker (”if it ain’t broke, don’t fix it”) MS kap. 10

26 Erstatt eller ikke? Mange mislykkede forsøk på å lage nytt
Vanskelighetene ofte undervurdert Oppgradering ofte bedre løsning (nytt grensesnitt, konvertering til standarder, etc.) Men nytt system kan være beste løsning om systemet er basert på en teknologi som er i ferd med å forsvinne (maskiner, operativsystemer, basissystemer som ikke lengre blir vedlikeholdt..) Et alternativ er å simulere gamle maskiner eller gamle operativsystem på nye maskiner (skal se på dette under) Uansett, gjør analyse av: Kostnad-nytte for det nye systemet (vanlig å overdreve nytten og underkjenne kostnader) Risiko analyse for å mislykkes Framtidige problemer med å beholde dagens system Mulige løsninger: standardprogrammer, oppgradering, nyutvikling Kompetansen til IT personalet MS kap. 10

27 Case: Administrativt system for Oshaug
System utviklet i DataEase (slutten av 80-årene) DataEase versjonen (DOS basert) vil ikke lengre bli utviklet Kostnadene ved konvertering til ny DataEase versjon NOK Primitivt brukergrensesnitt Manglet sentrale funksjoner Ikke integrert med andre systemer Kostnadene ved utvikling av nytt system anslått til NOK , men dette hadde moderne grensesnitt, langt større funksjonalitet og var basert på standarder (programmeringsspråk, database) og kunne integreres med andre systemer Nyutvikling besluttet. Dette arbeidet ble betydelig forenklet ved at det gamle systemet kunne danne utgangspunkt for en kravspesifikasjon. MS kap. 10

28 Nyutvikling Oshaug Nyutvikling gikk lettere og ble rimeligere enn antatt, spesielt gikk det enkelt å overføre data fra gammelt til nytt system (god planlegging) Andre bedrifter som valgte konvertering fikk store problem, vanskeligere enn antatt, problemer med ny versjon, ga opp. Prisforskjellen mellom konvertering og nyutvikling forsvant. MS kap. 10

29 Case: Planleggingssystem for Oshaug
Utviklet i 1997 Den gang: Relativt få ordrer; fram til nå: svært mange ordrer - kapasitet belagt i mer enn ett år framover; finanskrisen: noe færre ordrer Ønske om et kjappere system, men vi ser at systemet må være fleksibelt Tungt å gjøre store endringer, krever nesten samme innsats som den gang systemet ble utviklet Løsning: Bygge inn de viktigste forbedringene med minimale endringer i programmet MS kap. 10

30 Valgmuligheter (basissystemer)
Ny plattform Reengineer ? ”restructure” (bedre: oppgradering av kode), automatiske program som reorganiserer koden, f.eks. ved å fjerne unødige GOTO, optimalisering, m.m. ny plattform (boka bruker galt ord her). Flytte eksisterende kode og data til ny hardware og software plattform (kan kreve at translasjon av koden fra et språk til et annet) ”refurbish”, utvid med ny funksjonalitet, Web brukergrensesnitt, etc. ”rejuvinate”, vesentlig utvidelse ”package”, erstatt systemet med standardprogrammer. Bør brukes i alle tilfeller der dette er mulig! ”rewrite/reengineer” MS kap. 10

31 Reengineering ”Reverse engineering”, ta ut informasjon (”business logic”, prosesser, grensesnitt, datastrukturer ...) fra eksisterende systemer Vi går altså baklengs, istedenfor å gå fra kravspesifikasjon/design til implementasjon (forward engineering) går vi motsatt vei, vi lager kravspesifikasjonen på grunnlag av det eksisterende systemet. Analyse fra utsiden (grensesnitt, dokumentasjon, forretningslogikk) og fra innsiden (datastrukturer, algoritmer, …) MS kap. 10

32 “Jukse” løsninger Om systemet kjører på en maskin/operativsystem som er i ferd med å bli avleggs kan denne maskinen og operativsystemet emuleres på en ny maskin Bygge et nytt grensesnitt (f.eks. Web-basert) over et gammelt program

33 Lønner IT seg? Store kostnader: Ikke alltid målbare resultater
Utstyr Programvare Support Opplæring Ikke alltid målbare resultater Beste resultater der IT bare er en del av nyutviklingen (nye metoder, nye prosesser, nye produkter – men IT driver dette) Vi har sett at Toyota kuttet ut ordrer, ordremottak, fakturaer, etc. relatert til sine leverandører. Er dette et resultat av en IT investering? MS kap. 10

34 IT investeringer? Det investeres mye i IT, effektene er ikke alltid målbare: Flere ansatte etter IT-prosjektene enn før Høyere totalkostnader, kanskje også høyere transaksjonskostnader Mye tid går tapt til opplæring, vedlikehold, utvidelser, installasjon Feil og mangler skaper problemer MS kap. 10

35 Hvorfor lønnsomheten ikke er der
Problemene kan være: Innfører IT men beholder ”manuelle” prosesser Regelverket og forretningslogikken tilpasses ikke ny teknologi IT brukes ikke alltid der effekten er størst (ofte mer til administrasjon enn i produksjon) Lav IT-kompetanse hos ledelse, utviklere og/eller brukerne Isolerte systemer Lite effektive systemer (Excel til drift) MS kap. 10

36 Enklere å få lønnsomhet nå?
De store effektene kommer kanskje nå: Internett, brukerne gjør jobben selv Standarder og nett, bedre integrasjon mellom systemer Applikasjoner, stor tilfang av programvare med høy kvalitet Bedre opplæring, mer kompetent IT personale Data er elektronisk Men igjen, poenget er å tenke nytt MS kap. 10

37 Hvordan kan fordelene med et system måles?
Skill mellom de forskjellige oppgavene til et system Effektivitet (transaksjonskostnader, …) Kvalitet (levering til deadline, høyre produktkvalitet,…) Markedsandeler (hvilken innvirkning har IT systemet) Fortjeneste (større inntekter, lavere kostnader) Ikke alle deler er like lett å måle, men vi kan: Studere virkelig bruk av systemet Intervjue ansatte, kunder, leverandører Utføre før-etter studier Sammenligne avdelinger som har nytt IT system mot de som ikke bruker IT eller har det gamle systemet Må se på helheten! MS kap. 10