Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

30.06.2014 MS kap. 101 Ledelse av systemutvikling (MS kap. 10)  Personalhåndtering  Vellykket systemimplementering  Organisasjonens basis (”legacy”)

Liknende presentasjoner


Presentasjon om: "30.06.2014 MS kap. 101 Ledelse av systemutvikling (MS kap. 10)  Personalhåndtering  Vellykket systemimplementering  Organisasjonens basis (”legacy”)"— Utskrift av presentasjonen:

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

2 30.06.2014 MS kap. 102 Personaladministrasjon

3 30.06.2014 MS kap. 103 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

4 30.06.2014 MS kap. 104 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

5 30.06.2014 MS kap. 105 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

6 30.06.2014 MS kap. 106 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)

7 30.06.2014 MS kap. 107 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)

8 30.06.2014 MS kap. 108 Motivasjonsfaktorer

9 30.06.2014 MS kap. 109 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?

10 30.06.2014 MS kap. 1010 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

11 30.06.2014 MS kap. 1011 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

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

13 30.06.2014 MS kap. 1013 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å

14 30.06.2014 MS kap. 1014 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

15 30.06.2014 MS kap. 1015 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

16 30.06.2014 MS kap. 1016 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

17 30.06.2014 MS kap. 1017 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

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 30.06.2014 MS kap. 1019 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

20 30.06.2014 MS kap. 1020 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

21 30.06.2014 MS kap. 1021 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

22 30.06.2014 MS kap. 1022 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

23 30.06.2014 MS kap. 1023 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

24 30.06.2014 MS kap. 1024 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…)

25 30.06.2014 MS kap. 1025 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”)

26 30.06.2014 MS kap. 1026 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

27 30.06.2014 MS kap. 1027 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.

28 30.06.2014 MS kap. 1028 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.

29 30.06.2014 MS kap. 1029 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

30 30.06.2014 MS kap. 1030 Valgmuligheter (basissystemer)  ”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” Ny plattform Reengineer ?

31 30.06.2014 MS kap. 1031 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, …)

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 30.06.2014 MS kap. 1033 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?

34 30.06.2014 MS kap. 1034 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

35 30.06.2014 MS kap. 1035 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)

36 30.06.2014 MS kap. 1036 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

37 30.06.2014 MS kap. 1037 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!


Laste ned ppt "30.06.2014 MS kap. 101 Ledelse av systemutvikling (MS kap. 10)  Personalhåndtering  Vellykket systemimplementering  Organisasjonens basis (”legacy”)"

Liknende presentasjoner


Annonser fra Google