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 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 MS kap. 102 Personaladministrasjon

3 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 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 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 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 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 MS kap. 108 Motivasjonsfaktorer

9 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 MS kap 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 MS kap 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 MS kap Dagens Næringsliv Fra 2005, like aktuell i dag.

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

28 MS kap 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 MS kap 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 MS kap 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 MS kap 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 MS kap 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 MS kap 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 MS kap 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 MS kap 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 MS kap 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