1 / 37

Ledelse av systemutvikling (MS kap. 10)

Ledelse av systemutvikling (MS kap. 10). Personalhåndtering Vellykket systemimplementering Organisasjonens basis (”legacy”) systemer Hvordan kan vi måle nytten av IT systemer?. Personaladministrasjon. Mange bedrifter. har svak personaladministrasjon

wilton
Download Presentation

Ledelse av systemutvikling (MS kap. 10)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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 250.000 • Primitivt brukergrensesnitt • Manglet sentrale funksjoner • Ikke integrert med andre systemer • Kostnadene ved utvikling av nytt system anslått til NOK 500.000, 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) Reengineer Ny plattform ? • ”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: • 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

More Related