Stikkordarkiv: redusere kompleksitet

Behovet for bedre intern IT

Dagens interne IT avdeling er stadig under press. Jeg vil si: «Mellom barken og veden». På den ene siden har man brukernes krav til moderne brukergrensesnitt, skyløsninger, tilkopling til mobile tjenester osv. På den andre siden virksomhetens tekniske gjeld – i form av gamle IT systemer, siloer av informasjon – mangel på informasjonsflyt mellom design og produksjon osv. Hva slags plan skal vi lage for å bøte på dette?

Finnes det en quick-fix? For mange er det å ty til skyløsning et bidrag. Vi trenger dele data, men resultatet er likevel en dobling av data, bilder, dokumenter osv.

Få vil unngå skyen om de starter en ny virksomhet idag? Tilgang til programlisenser er bare første fase, så er det deling i ulike form for skylagringsmedier. Vet du hvor mange steder bedriftens data ligger lagret?

I virkeligheten har mange bedrifter mye «in-house» data. Og det kreves interne IT ansatte, eller spesialister for å konvertere til riktig format av verdi. Hva med de 20 år gamle prosjektene og dokumentasjon som ligger på fjernlager? Hva er kravet på tilgangen til data –  nå og fremover – og hva slags kategorier av data finnes? Har du tenkt over om det er optimalt?

En handlingsplan for bedre intern IT vil ta hensyn til tilgang til data og en transformasjon av arbeidsoppgaver over tid; data og interne prosesser – fra gammelt til nytt. Kanskje vil man også legge opp til større grad av selvbetjening for brukerne. Det som ligger i bånn er hensynet til virksomhetsarkitekturen; Dette kan fort bli en unnskyldning for intern IT. Vi har så gamle IT systemer osv.

De fleste forbedringsprosjekt innen IT starter med kartlegging av behov. En kjent metode for kartlegging av virksomhetsarkitektur er metoden TOGAF, men det finnes også andre. TOGAF sikrer at man har med seg alle sider av virksomhetens behov. Det starter med krav til fremtidig IT løsninger – overordnede og med basale krav; Dernest dokumenteres dagens IT og systemløsninger, for til slutt å ende opp i en løsningsdiskusjon og et endringsønske.

Virksomhetsarkitektur som fag er ikke for hvem-som-helst. Det er en yppelig oppgave å kjøpe eksternt  både av hensyn til kvalitet og fordi man kan trenge en «uavhengig advokat» med spesialkompetanse på IT. Det finnes få om noen ansatte som har full oversikt over alle aspekter ved dagens muligheter på IT-infrastruktur, alle interne arbeidsprosesser – og ikke minst organisasjonens informasjonseierskap.

Jeg anbefaler en fasilitert forstudie med målsetting om «Bedre intern IT». Da vil også IT være en aktør på linje med brukermiljøene. Måle er å skille det vesentlige fra det mindre vesentlige og samtidig sikre seg informasjonssikkerhet på veien. IT sikkerhet er nemlig et særdeles viktig element i en endringsplan på IT – og ofte uteglemt. Hva med sårbarhet for data angrep? Ettersom skyløsninger gir bedriften global eksponering; Tilgang til data via Google, Amazon, Microsoft, Facebook osv. øker trusselen, men den kan samtidig enkelt skjermes ved en godt forankret IT strategi.

Til slutt: Skal du igang med å forbedre organiseringen av IT kommer du nok ikke utenom ITIL (standard leveransemodell for IT service organisasjoner). Har du planer om – eller vurderer outsourcing? Vil du se på fordelingen på hva du gjør internt og hva du kan kjøpe som en IT tjeneste? Da er det en fordel å forstå ITIL basis for å kunne stille krav til IT leveranser fra underleverandør. ITIL gjennomgås i separat artikkel. Det starter gjerne med å sende intern IT på ITIL kurs. Da får man både kunnskap om hvordan «beste praksis IT» bør leveres – og man kan stille krav om ITIL mot IT leverandører; Og kanskje er det en god målestokk for IT internt?

-Har du erfaring med ITIL?

Del dine erfaringer om intern IT og ITIL-prosesser via sosial kanaler.

 

Et digitaliseringsprosjekt har flere sider

IT og digitaliseringsprosjekt står på agendaen. Hvilke tiltak virker – og hva er verdien av prosjektene? Skal vi bare i gang uten en styringsmodell? Hva med governance? Disse og flere spørsmål dukker opp når en virksomhet står foran nye strategiske valg.

Når IT og digitaliseringsstrategier skal vurderes mot hverandre, fremstår disse for mange som mangehodete troll og både en mulighet og en trussel.
-Hva er hensikten med prosjektet?
-Må vi endre oss?
-Har vi råd til å la være?

Eierskap til endring er viktig. Noen vil lage en gevinstrealiseringsplan – andre vil bare gå igang. Ledelse av CDO eller digitaliseringsprosjekt er ikke for nybegynnere; Det kreves alt fra IT og teknologiforståelse, organisasjonsforståelse, litt psykologisk erfaring, samt endringsledelse (m.m.). Mulighet eller risiko?

«For en snekker som har en hammer, er alt en spiker».

Og for en CIO er det lett å ty til de samme verktøyene som vi bruker for å styre IT kjerneprosesser – og risiko; Bruke PMO.

Har du et program- og prosjektkontor (PMO) er det nærliggende at både IT og digitalisering legges innunder dette. Men hva betyr det for kreativiteten i prosjektet? Hva taler for – og imot? Mye tyder på at digitaliseringsinitiativ har lettere og bedre kår når de kjøres helt på siden av byråkratiet som små eksperimenter. Forbrukerrettet innovasjon styres vel best av brukerne? Hva skal slippes fritt – og hva skal tøyles? Hva med IT sikkerheten oppe i det hele?

For IT ledelsen kan det oppstå dillemmaer og man møter ofte motstand. Nye prosjekt, krever ofte ny infrastruktur for å tas ibruk i stor skala. I strategilitteraturen snakker vi om risiko og muligheter. Disse går gjerne hånd i hånd. Digitale forretningsmuligheter kan innebære trusler, men også gi fortrinn i markedet, økt kapitalavkastning, økt læringsforsprang i produktutviklingen osv. (Dette er en av grunnene til fremvekst av nye stillinger i organisasjonen f.eks. CDO (Chief Digital Officer. Man vil tross alt utvikle digitale satsningsområder (red.anm)).

Gevinstrealiseringsplan kan være et kriterie for å gå igang. Innovasjon starter med observasjon av eksperimenter – og innovasjonsteorien er klar på at det foregår en adopsjons- og modningsprosess (ref. Gartner). Det kan således ta tid før man får verdi av en innovasjon. Noen velger å vente til gevinsten er åpenbar. Reklamen for roboter sier selvsagt noe annet;
Dette er teknologi som kan kjøpes nå! Ja, det kan være vi trenger et eksperiment, men da er det vel litt tidlig å be om en gevinstrealiseringsplan?

– Vet vi potensialet for vår virksomhet før noen har prøvd? Kanskje ikke.

Med ny teknologi er jo eksperimentet i seg selv nødvendig for å kunne «regne på det». Verdien av en anvendelse er ofte meget uklar før man sjekker ting i praksis for en virksomhet.
Da er uttesting – gratislisenser og skyløsninger uvurderlige nyheter.

Det er altså mulige utfall eller resultater av digitaliseringsprosjekt og nye IT innovasjoner som ikke er gitt på forhånd. Gartner påstår i sine adopsjonskurver at det handler om å finne timing på når innovasjonen er moden nok til å realisere en verdi for en virksomhet – eller en gruppe brukere.

For noen har digitaliseringsprosjekt egenverdi. Det er utelukkende snakk om posisjonering i markedet. Du kan jo med egne øyne observere antallet artikler om emnet på Google, LinkedIn og Facebook. ALLE vil eie det som er nytt og nyskapende for å tiltrekke seg de rette medarbeiderne. Alle nyere IT selskaper vil også ta del i det fremvoksende markedet; Det handler om posisjonering og kamp om kunnskapsressursene – de kloke hodene.

vektskål

– Hva er gevinsten av digitalisering? Er det en risiko eller en mulighet?

La oss prøve å regne på skalaeffekten av et eksperiment i det minste. Vi trenger tross alt en målestokk eller metode for å evaluere og prioritere initiativet (les: Prosjektet) – enten det heter digitalisering, prosessforbedring med ERP, SEO markedsføring, FoU-utviklingsprosjekt eller teknologiforbedring med bruk av 3D for våre produkter.

Når man så velger å sette innovasjonen i system, vil tradisjonelle verktøy kunne komme til hjelp såsom PMO (Project Management Office), Scrum for inkrementell utvikling og Prince2/PMP for prosjektoppfølging og gjennomføring.

Å tillatter ansatte å feile er populært innen ledelsesteori – og kanskje til og med klokt, Det heter seg at kreativitet ikke trives i et vakuum. En annen måte å si det på er at virksomheter må gi tilstrekkelig rom for kreativitet.

Kreativitet er vanskelig å måle i et PMO. Likevel trenger vi å nyttevurdere innovasjon – digitalisering og nye IT prosjekt, ihvertfall om det gjøres implementering i stor skala. Evnen til tilpasning, endringsvilje og styringsevne er ikke minst like vikitig.

– Hva om vi kjører 20% av prosjektporteføljen som eksperimenter utenom PMO?

Balansen mellom risiko og mulighet er viktig å finne for sin virksomhet. Det finnes derfor ingen regel uten unntak. Kanskje er det ikke så farlig å feile med digitalisering hvis man lærer av det og unngår å gjøre samme feilen igjen? Organisasjoner består jo av mennesker av kjøtt og blod – og snart også roboter.

I private virksomheter er det erfaringsmessig nok nyttefokus. Min påstand er at uten en regel  om at «det er lov å feile i det små», vil mange storskala digitaliseringsprosjekt feile, slik mange IT prosjekt har gjort det historisk. Eller sagt på en annen måte: Ikke gi forventet avkastningsverdi.

Kommunale digitaliseringsprosjekt (les: eksperiment) innen IT og digitalisering som går for felleskapets regning burde kunne koordineres slik at vi kan lære av hverandre. Her skjer mye storskala utvikling parallelt. Kanskje ikke så lurt å gjøre alle de samme tabbene – alle sammen? Har man et felles PMO?

Lykke til med digitaliseringen!

Trenger du en IT strategi, så hold det enkelt

Du kjenner vel begrepet «KISS! – Keep it simple stupid!»? Sjelden er ordet mer treffende enn når det gjelder å lage en IT strategi. Du har sikkert lest tekniske IT dokumenter fullspekket med fremmedord og forkortselser. Nå når IT er et allment verktøy, behøves et enklere språk – i alle fall dersom man ønsker at strategien skal brukes i praksis.

Kunsten å skrive enkelt om noe komplisert gjelder ikke bare IT, men IT-bransjen er vel bransjen med suverent flest TBF-er (trebokstavsforkortelser). Utgangspunktet er derfor dårlig. Likevel er det endel enkle grep som kan gjøres for å redusere kompleksitet…

IT strategikaos
Innholdsfortegnelsen. Allerede her varsler vi jo leseren om hvor vanskelig og omfattende dette er. Klarer du å lage en IT strategi som kan leses som en vanlig «forretningsplan», så har du gjort mye bra. Leseren av en forretningsplan er gjerne et styre eller en investor i en bedrift som ikke trenger alle detaljene, men enkelte ting må være med som for eksempel:

  • et sammendrag (for ledelsen)
  • beskrivelse av nåsituasjonen (i vanlig terminologi)
  • overordnede mål for perioden
  • styringsprinsipper som gjelder
  • satsingsområder for perioden
  • (noen ord om) gjennomføringen
  • vedlegg (her er det tillatt å gå litt mer i dybden, men hold deg til saken!)

Det å lage en IT strategi kan gjøres enkelt, men dette er jo bare resultatet av en prosess. Når det gjelder prosessen for å komme fram til en IT strategi, så krever dette langt mere av oss.

Medvirkning. En IT strategi bør muligens forfattes av personer med IT kompetanse, men virksomhetsledelsen må eie den – ellers blir den bare et dokument. Det er derfor fornuftig å etablere et diskusjonsgrunnlag med forslag til retning. Her kan man bruke et uttall av innfallsvinkler f.eks. hvor-hva-hvordan (where-what-how) analyse, analyse av styrker, svakheter, muligheter og trusler (SWOT). Man kan kjøre en risiko-analyse med deltakere osv. Å skape enighet om en høynivå målsetting er utkommet av det hele.

Styringsprinsipper. Fundament for all strategi er ressursgrunnlag og ressursforvaltning. Hvilke midler og valgalternativer rår man over? Hvordan samsvarer dette med dagens forvaltningsmodell? Dette er et ganske ofte et undervurdert område. Dersom det er et problem med manglende styring, sier det seg selv at man bør ha dette som et satsingsområde og få det på plass. Det finnes mange gode rammeverk, og innen IT sektoren har man etterhvert ITIL (nok et begrep!) som en slags minste standard for å definere en tjenestemodell (NB! Disse begrepene må forklares for leseren!). Symptomer på sviktende forvaltningsmodell kan være dårlig opplevd service fra IT avdelingen, mangelfulle innkjøpsrutiner og leverandørstyring, eller manglende eierskap til systemer.

Nye satsingsområder. IT strategi skal jo helst innbefatte en endring, men her er det viktig å kjenne virksomhetens rammebetingelser. Står man overfor en vekstfase, så er det andre forhold som gjelder enn om man er i konsolideringsmodus som følge av markedsstagnasjon eller nedgang i virksomheten. Det er også naturlig å peke seg ut hele eller deler av porteføljen av IT systemer. Er det mye gammelt som ikke «snakker sammen» og som gir utfordringer i arbeidsprosessene? Har man behov for fornyelse? Igjen er det viktig å sikre at IT strategien forankres og diskuteres i løpet av strategiarbeidet, slik at man sikrer at IT strategien faktisk kan gjennomføres med gitte ressurser og rammebetingelser. Når det gjelder «nye områder», bør man sikre tilgang på kilder som kan si noe om utviklingen og utfordringer med ulike veivalg. Et tips er Gartner Group. Glem ikke å spørre IT-bransjens fagfolk om hva som kommer og hva det er vi bør ta hensyn til av IT trender og ikke minst på IT sikkerhetsfronten. En workshop på «gapet» mellom dagens og nye satsingsområder vil kunne avsløre om man har for høye ambisjoner.

Gjennomføring. En god IT strategi må kunne gjennomføres, og har man for mange satsinger i flere retninger, vil det vise seg når man forsøker å lage en gjennomføringsplan. En god gjennomføringsplan tar høyde for at målbildet kan endre seg, men sørger for at delmål attid oppfylles underveis. Det er viktig å ha klare delleveranser for første året, slik at man får «øvd seg» på å treffe med ambisjonsnivået. Forutsetninger for gjennomføring må også klargjøres, slik at uforutsette hendelser som påvirker utfallet av IT strategien ikke kommer som en overraskelse. En god risikoanalyse med tilhørende risikoreduserende tiltak er et bra tillegg for en god plan. Den klassiske risikoen er av operasjonell art; At IT prosjekter går utover forvaltningen – eller at IT drift tar fokuset bort fra den strategiske endringen og dermed forsinker gjennomføringen av IT strategien.

Kommunikasjon. Til slutt tilbake til det opprinnelige utfordringen. Når en IT strategi foreligger etter en omfattende IT prosess, kommer behovet for å informere de som ikke har vært med på den interne prosessen. Språk, form og virkemidler er nesten like viktig som innholdet. Det krever mye å lage ting enkelt. Derfor anbefaler vi at selv enkle begreper forklares – gjerne i vedlegg, og at man i minst mulig grad bruker forkortelser.

En IT strategi kan lages vanskelig og den kan lages enkel. Jeg har utelatt beskrivelsen av nå-situasjonen, av den enkle grunn at den er unik for hver virksomhet og veldig avhengig av kontekst. Som en regel bør den begrenses til 1 side, men likevel er det jo den som danner grunnlaget for hvilke satsningsområder som er realistiske å foreslå. Beskrivelsen skal gi en slags «IT status» og bør definitivt inneholde rene tallfakta om IT infrastuktur, forvaltningsprinsipper og dagens bruk av IT-systemer. Og glem ikke fakta om dagens utfordringer.

Problemer er til for å løses. Lykke til med ny IT strategi!

Ny virksomhetsarkitektur – Hvordan prioritere riktig?

Nyere IT løsninger har den fordelen at man endelig kan se fremover og ikke trenger å tenke på fortiden. Eller er det ikke så enkelt? Hvem kan svare på det? Vi snakker ikke om enkle «apper», men komplekse virksomhetskritiske IT-løsninger. Kartlegging bør være første steg på veien. Det er her virksomhetsarkitekten kommer inn.

Eksterne konsulenter er gjerne eksperter på å lage gode business-case som et grunnlag for å foreslå ny IT arkitektur. Enten du har vokst ut av dagens ERP løsning eller vurderer hvordan du skal ta vare på kunden bedre ved hjelp av CRM. Vurderingen av hvor godt systemet passer med bedriftens interne prosesser har imidlertid ingen andre enn bedriften selv forutsetninger for å vite noe om. Her kreves analyse. Konsulenter kan i beste fall være en katalysator for endring.

shakehands

En konsulentvurdering som ikke tar hensyn til dagens arkitektur hopper gjerne også bukk over muligheten til å intervjue dagens brukere og ledere. Innføring av nytt CRM, ERP eller PLM system uten reell brukermedvirkning er ingen god ide. Man kan ha god avkastning på papiret, men uten reell forankring av nye IT-løsninger vil resultatet fort bli negativt.

En helhetlig virksomhetsarkitektur ser både på dagens og fremtidens behov. Når man planlegger prosjekt og initiativer i forhold til virksomhetens arkitekturbehov, behøves et godt rammeverk – et  som ikke er for snevert. For hensikten er ikke å lage et IT-system, men å støtte forretningsmålene og tilhørende forretningsprosesser. Metoden må sikre eierskap til krav – både prosess-, teknologi- og brukerkrav. Teknologi er oftere i seg selv et krav og en egen premissgiver for å sikre bedriftens fremtidige konkurransekraft. Storkonsernet General Electric (GE) sier i sin markedsføring av programvare at enhver produksjonsbedrift må bli en programvarebedrift for å overleve på sikt. Kanskje har de rett?

En god virksomhetsarkitektur beskriver sammenhenger mellom prosess, IT arkitektur og organisasjon. Uten en god forståelse fra eier av forretningsprosessene, får man liten gevinst. Det er derfor viktig at virksomhetsarkitekturen kan beskrives på forståelig vis for alle parter. Tilstrekkelig analyse må også til for bedriftens utgangspunkt. Endringer fra dagens til fremtidens løsninger betinger gjerne en kostnad. Hvilke kostnader finnes det? Definisjonen av begrepet kostnad må omfatte kostnad ved å endre; kostnaden ved å bytte ut dagens operative IT infrastruktur, men også kostnaden ved endring og opplæring i nye prosesser. Likevel kan det lønne seg å investere i nye løsninger, da de ofte er mer brukervennlige enn sine forgjengere.

managing complexity

Kompleksitet koster. Gap ikke for høyt. På bakgrunn av kompleksiteten i dagens virksomhetsarkitektur er det mange som vegrer seg for å gå i gang. Og i mange tilfeller vil bedriften ha for knappe ressurser til f.eks. å kunne løfte seg på en helt ny IT plattform. I andre tilfeller vil det oppfattes som en befrielse å forenkle løsningene som mange ganger er basert på et «lappverk» av overlappende systemer. En enkel analyse vil kunne avdekke hvor kompleks og kostbar en endring kan bli.

Plassering av ansvaret for arkitektur. Forretningssiden bør definitivt forstå viktigheten av eierskap til en helhetlig virksomhetsarkitektur. Den bør ikke for lett delegeres bort, men beholdes på forretningssiden, gjerne under en CIO rolle. Den interne IT avdeling har gjerne en annen agenda som går ut på å forvalte dagens struktur. Her ligger det en mulig konflikt; Å legge arkitektur til Intern IT kan medføre en sammenblanding av roller. Samspillet med forretningssiden bør tillegges vekt, slik at man sikrer prosesseierskap til teknologien. Arkitekten blir da som rolle tilsier – en arkitekt med oppdragsgivere.

Arkitektens egenskaper. Hun bør være mest mulig uavhengig, ha god forståelse for effektive arbeidsprosesser og en god porsjon «mot i brystet». Hvorfor det? Et spørsmål fremover kan være: Skal vi la brukerne styre mer selv og legge til rette for «selvbygging» eller skal vi sentralt styre dette ved hjelp av intern IT? Eller sagt på en mer direkte måte: Trenger du hushjelp når du har alle disse flotte husholdningsmaskinene? Arkitektens rolle blir nok mer og mer å designe og tilrettelegge kjøkkenet basert på aktørenes krav til komponentene som inngår.

Et arkitektur-prosjekt er et planleggingsprosjekt. Da må man kunne diskutere overordnet prioritering – om det er viktigst å vedlikeholde eksisterende «haltende» portefølje, eller tenke nytt og helhetlig om arbeidsprosesser. Med dagens raske utvikling kan det siste være et nødvendig skritt for å overleve. I tillegg bør man spørre hvordan prosessen kan bli mer effektiv med støtte av teknologi. Det må være lov å stille seg hypotetiske spørsmål!

Teknologi som driver i seg selv. Det er viktig at arkitekten spør seg hva ny teknologi kan gjøre for prosessene og hvilke rammebetingelser digitaliseringen gir? Alternativt kan utfallet fort bli et IT prosjekt uten avkastning om man ikke tar hensyn til alle fire sider av diamanten: Prosess, system, teknologi og organisasjon. Og så var det var det å huske på bedriftens evne til omstilling…som allerede nevnt.

Gode verktøy nødvendig. Bruk av strukturerte modeller og verktøy kan overdrives. Likevel skal man ikke undervurdere organisasjonens behov for en god visjon eller et godt «konsept» for å beskrive arkitekturutfordringen – et bilde sier mer enn 1000 ord. Vi forstår alle arkitektens utfordring i overført betydning når det er snakk om fysisk infrastruktur f.eks. hvor komplisert det er å bygge veier eller høyhus. Vi glemmer imidlertid at informasjonsstrukturer er kompliserte – og lite konkrete for de uinnvidde. Derfor kreves detaljerte planer eller programmer for endring av «informasjonsveien» i bedriften.

Til slutt. Det er viktig med felles mål og felles begreper; Et steg kan være å etablere felles referansemodell for virksomheten, slik at flere forstår helheten og kan diskutere begreper, retning og innsatsfaktorer. Ved å forstå sammenhengen mellom prosess, systemer, teknologi og organisasjon kan man bedre prioritere de riktige arkitektur-prosjektene. Dette krever imidlertid at man investerer i å få eiere av prosessene og teknologien på banen i en felles diskusjon om lønnsomme veivalg. På den måten unngår man i overført betydning å lage ubrukelige veitrasseer som ikke viser seg liv laga som pressen ynder å omtale det som – «unngå flere myslykkede IT prosjekter» som det jo allerede er for mange av.

Del gjerne dine erfaringer med virksomhetsarkitektur og kommenter på CIO bloggen.

Konfigurasjonsstyring – en kilde til lønnsomhet

Når du skal kjøpe bil, velger du i blant teknikk- og sportspakker og andre opsjoner som tilbys. Det sies at en bil kan ha mer enn 6000 varianter å velge i for en modell. Dette er vel å bra for høyvolumprodusenter som i bilindustrien. I den norske leverandørindustrien som selger til olje- og gassbransjen er volumene så lave av like deler at det gir få eller ingen skalaeffekter. Da er det fort måten man jobber på som skiller de lønnsomme fra de ulønnsomme.

Begrepet konfigurasjonsstyring er kjent for ingeniører som jobber med produktutvikling som en måte å sikre konsistens på produktleveranser for hele produktets levetid – og for solgte individ f.eks. anleggsmaskiner. Konsistent kvalitet er en stor utfordring i norsk leverandørindustri, både fordi det er få enheter som selges og fordi det etterspørres mange endringer – en lite kostnadseffektiv kombinasjon. Ettersom det blir mange mulige kombinasjoner, blir enhetsprisen høy. Tenk om vi tross lavt volum kunne lage «unike produkter» for hver kunde slik som i bilindustrien? Med automatiserte konfigurasjonsverktøy er dette idag mulig, men det krever forståelse for standardisering av engineering på detaljnivå og evne til å bygge opp produktstrukturer og moduler som er forberedt for gjenbruk.

DB_bil

Konfigurert på bestilling

I mangel av et bedre norsk ord på Configure-to-Order, konfigurert på bestilling beskriver prosessen fra kunden velger opsjoner til du har en ferdig konfigurert maskin / bil / produkt. I industriell sammenheng innen leverandørindustrien i Norge er dette en sjelden mulighet. Vi har nå verktøy som gjør det mulig å effektivt gjenbruke dokumentasjon og holde full oversikt over hvilke komponenter og varianter som er forbrukt i de solgte individene. Dette gjør det både mulig å tilby kunden en unik serviceopplevelse, og det gir en etterlengtet kostbesparelse. Hvordan er det mulig?

Arv og Intelligens

I et verktøy som støtter en konfigurasjonsprosess bygges det opp strukturer og logikk for gjenbruk og arv. Intelligensen ligger innkapslet i hvert objekt i strukturen (f.eks. vet bildøren at den henger på bilen). Konseptuelt er dette ikke vanskelig å forstå. Derimot er det vanskelig for oss legfolk å forstå den kompleksitet som ligger i design av et produkt som f.eks. en bil representerer. Hva kreves ikke av tegningsunderlag, underleveranser, byggeinstruks, sammenstillingsveiledning, brukerveiledning og myndighetsgodkjennelser? Alt-i-alt en hel bråte med dokumenter som man gjerne vil slippe å vedlikeholde manuelt, både i innhold og utforming.

Det fine med konfigurasjonsverktøy er at du kan lage produktet som du vil innenfor gitte rammer. Utfordringen er vedlikehold av informasjon. Uten intelligens og kjennskap til bransjen og produktets egenart er det tilnærmet umulig å automatisere prosessen med verktøy. Logikken må i tillegg tilpasses kontekst.

Arv og Miljø

En leveranseprosess er det mer enn produktdesign. Når produktet ser dagens lys som en prototype, er det ennå langt fram til leveranse. Produktet skal gjennom en prosess av multiple systemer (CRM, ERP, PLM osv.). Konfigurasjonsverktøyene må være tilpasningsvennlige overfor denne konteksten de inngår i. Hvilke verktøy benyttes i bransjen osv.

Produktleveranse

Med et konfigurasjonsstyringsprogram vil man til slutt sette sammen individene ved at deler som gjenbrukes «arver» innholdet (dokumentet) og ikke dupliseres med mindre det er annerledes enn sine foreldre. Dette gjør at en sykkel med fargen rød hovedsaklig har samme dokumentasjonssett som en blå osv. (de har jo like egenskaper ellers). Uten et konfigurasjonssystem vil man derimot fort mangedoble dokumentasjonsbehovet. Tar man kopi av dokumentasjonshaugen forsvinner hele grunnlaget eller økonomien i leveransen av den blå kopien.

Konklusjon

I leverandørindustrien i Norge trengs mer bruk av verktøy for konfigurasjonsstyring for å få ned enhetskostnadene ved å produsere enkeltkomponenter og sammenstillinger. Her har vi mye å lære av bilindustrien i Sverige og Europa, men ikke alt er gjennomførbart ettersom miljøet og bruken av verktøy ofte er annerledes. Veien mot full konfigurasjonsstyring krever derfor tålmodighet, men kunnskapen kan generelt sett lett overføres på tvers av bransjer.

Lykke til med å forbedre lønnsomheten i din bedrift!

Del gjerne dine erfaringer med programvare for konfigurasjonsstyring og kommenter på CIO bloggen.