Kategoriarkiv: Ny virksomhetsarkitektur

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.

 

Hvordan velge CAD/PLM verktøy i et marked i endring og vekst?

Fremveksten av 3D for printing, additiv produksjon, robotisering, design-orientert produksjon og IoT har gitt grobunn for vekst i 3D programvaremarkedet. I en ny rapport vises det til 7% årlig vekst i markedet og fremvekst av nye aktører som baserer seg på OpenSource.

Markedet for CAD/PLM programvare har lenge vært dominert av dyre 2D og 3D programvar. Endring av lisensmodell fra kjøp til leie og måling av bruk gir noen besparelser (les: Du betaler kun for det du bruker), men CAD er fremdeles de programmene du betaler mest for per bruker. Vil det komme rimeligere alternativer? Svaret er: JA. Som så mange andre områder finnes det rimeligere og fullgode alternativer.

Fremover gjelder «design tankegang» og interaktive 3D løsninger, visuelle modeller i ennå større grad. Dette markedet er i ferd med å ta av. Derfor er det at nye åpen kildekode CAD/PLM aktører som f.eks. Aras.com annonserer ny kapitalinnsprøytning på 70 Millioner dollar for å styrke sin posisjon i et voksende åpen lisens marked. Aras er fremdeles ikke blant de store, men interessante storkonsern som Airbus R&D er på listen – og listen vokser.

CAD/PLM markedet har lenge tilbudt Saas (Software-as-a-Service), men prisene er like «stive» for lisensenser fra de 4 store (Dassault, Autdesk, Siemens og PTC). Under er en estimert markedsutvikling for de største markedsaktørene fremover (Kilde: BISresearch.com):

CAD_market_1

Veksten i CAD markedet er estimert til 7% per år fremover til 2023 – og størst i Nord-Amerika. Litt annerledes er det i Europa hvor også markedet for åpen kildekode er i fremvekst. Dette segmentet er knapt synlig på listen over. Markedsandelen for åpen kildekode basert CAD er imidlertid estimert til oppimot 20% i 2023, noe som tilsvarer vekst høyere enn 7% per år.

Ved valg av CAD/PLM løsning må man vurdere sine behov nøye. Hva slags prosess har vi idag og i fremtiden? Hva er hovedformålet med CAD/PLM løsningen? Har vi et produkt eller et prosjektfokus? Hva krever kundene av oss? Hva slags produktdata trenger vi i service og vedlikeholdsfasene? En analyse vil si litt om kravet til informasjon i CAD modellen.

Her er en liste av faktorer som også kan være nyttig å gjennomgå og vekte i en CAD/PLM anskaffelsesprosess (Kilde: Aras.com):

– Systems Engineering behov
– Bill-of-Material behov
– Change Management
– Configuration Management
– Manufacturing Process Planning
– Quality Management
– PDM/PLM Integration

Punktet integrasjon er ikke minst viktig, da det viser seg at de fleste har et behov for å integrere CAD/PLM systemene med neste ledd i kjeden, eller CRM og ERP systemene om du vil.
Dette er imidlertid et tema som fortjener sin egen artikkel.

Ta kontakt om du ønsker å diskutere vurdering og valg av IT løsninger innen CAD/PLM.

ERP for prosjekt-orienterte bedrifter

I jungelen av ERP-systemer snakker man stadig oftere om skybaserte løsninger – og det er vel og bra. Viktigst er det imidlertid at virksomhetens prosesser understøttes. Effektive IT løsninger gir lavere driftskostnader og kanskje også mer effektive basisprosesser – f.eks. digital fakturahåndtering. Likevel er det helt andre utfordringer for å skape lønnsomhet av å levere produkter og prosjekter fra industrien. At løsningen er skybaserte er bare et av mange basiskrav.

Vår erfaring fra å stille krav til ERP i olje- og gass, samt annen industri viser klart at store standardsystem dominerer, men ikke alle gir effektive prosesser. Disse såkalte ERP-systemene kan være gode på håndtering av store mengder transaksjoner og bokføring, samt rapportering av årsregnskap, leverandørreskontro osv., men mange er likevel dårlig på prosjektkontroll. Og for mange er det en dårlig deal når det er prosjektene som er hovedinntektskilden. For mange er erfaringene i prosjektene ofte et være eller ikke være. Her er det rom for forbedring.

– Hva var marginen på siste prosjekt – og hvorfor gikk det ikke bedre? Var det ressursbruken, materialforbruket eller noen få, dårlige underleveranser?

For mange er svaret på spørsmålet å gå til sitt storsystem som SAP, IFS, Oracle, NAV eller liknende. Her finner de sjelden svaret fordi planene ikke er detaljerte nok. Vi har sett mange selskaper implementere ERP – og, ja, de har fått bedre kontroll, men ikke bedre lønnsomhet i prosjektene. Det er imidlertid heller ikke noe alternativ å miste kontroll over logistikk, lager og prosjektleveranser. Dette må kontrolleres, men hvordan gjøres planleggingen? Her er svaret ofte: Excel.

Vi har den senere tid fått jobbe med mer detaljerte prosesser på produksjon til prosjekt i industrien. Her finnes det produksjonsrettede systemer som gir kontroll fra planleggingen av hele leveransen og ikke minst salg, tilbuds- og anbudsfasen hvor detaljbeslutninger tas, ja, helt frem til leveranser og servicefasen. Dokumentasjon fra denne fasen er meget viktig.

Eksempel på et slikt system er nederlandske Trimergo ERP. Dette er et prosjektorientert system med full produksjonsoppfølging, shopfloor-løsning, mobile enheter osv. Det er først og fremst egnet for prosjektbedrifter som vil ha kontroll fra kalkyle, ressursplanlegging frem til  oppfølging av leveranse av deler, sammenstillinger og service i hele produktenes levetid.

Det finnes også norske systemer, men ikke i samme skala for SMB og de er sjelden godt integrert med større løsninger som SAP, IFS, Oracle, NAV osv. Trimergo er et hederlig unntak. Trimergo spiller f.eks. godt på siden av SAP og går samtidig MS-Project en høy gang med sin integrerte ERP ressursplanleggingsmodul. Bo Hjort Christensen kaller det det omvendte ERP-begrep; Trimergo fokuserer ikke på bokføring som mer og mer foregår i skyen, men fokuserer på effektivitet i prosjektene, samt sørger for maksimal kontroll med virksomhetens prosesser.

Nye moduler og integrasjoner utvikles for å koble sammen mot atter andre ERP-systemer feks. Xledger m.fl. i skyen. Et eksempel på brukere og som også bruker SAP er Airbus Defence – altså ikke noen smågutter dette. De bruker Trimergo på sine FoU-prosjekter og for å følge opp delproduksjoner i Benelux.

Dersom du er interessert i alternative, prosjekt- og planorienterte ERP løsninger, så ta kontakt med Beste Praksis for mer informasjon, evt. gjennomgang av deres kravspesifikasjon. Vi har mangeårig erfaring med leverering av ERP implementeringsprosjekt.

 

For eller imot offshoring av IT?

Det siste tiåret har det pågåt mye Offshoring av IT, dvs. at større private og offentlige virksomheter kjøper IT-tjenester fra et land utenfor Norden. Ikke bare IT, men tjenesteutsetting er også tatt ibruk på flere andre sektorer som bank, finans, HR og f.eks. på kvalitetssikring, leverandøravtaler for å nevne noe. Stikkordet har vært: Har dere repeterende arbeidsprosesser som er timeintensive, så tilbys lavkost ressurser og en tjenestemodell. Dette er gjerne samtidig en sentralisering av tjenester hvor mange små enheter eller avdelinger slås sammen til en stor som betjenes fra utlandet.

Rasjonalet for offshoring er selvsagt i økonomisk teori – lov om spesialisering, og lov om lønnsomhet av skalering. Offshore selskapet er spesialist på den aktuelle tjenester, de er mao. effektive og gjør dette for flere andre kunder i samme situasjon. De kan også bedre dra ut skalaeffekter. De som selger deg «Offshoring av IT» kan love deg kanskje 30-35% reduksjon av årlige IT kostnader. Dette høres jo forlokkende ut, men hvilke fordeler og ulemper er der i dette bildet? Store konsern som f.eks. Telenor, Aker m.fl. har sett at slike storskaleffekter kan oppnås også internt ved å slå sammen stabsenheter. Dette resulterer så i spin-offs hetende såkalte Business Partners. Kostnadsreduksjonen blir da en lønnsom investering.

Nye momenter kommer inn ift. de tradisjonelle mot argumentene som  har vært 1) mangel på nærhet, 2) kommunikasjonsutfordringer, 3) fremmedgjøring av tjenesten overfor brukere osv. De økonomiske gevinstene har i noen tilfeller uteblitt eller tatt lengre tid, men så er det fundamentale også at IT utvikling går så fort at man har problemer med å tilfredstille avanserte forbrukere fra en intern IT avdeling.

Kravet om innvoasjon, digitalisering og brukerens krav om forbrukerløsninger er også momenter for outsourcing. Offshoring er bare en type medisin for et symptom – interne krav mot IT avdelingen, men det er unektelig økonomiske gevinst som er hovedargumentet. At den du outsourcer til har skalafordeler og kan spesialisere seg på IT og digitaliering er en annen fordel. Dermed oppnår du ideelt sett både kostnadsfordeler og innovasjonsgevinst på tjenestetilbudet for IT leveranser.

Offshoring sementerer muligheten for endring, hevder noen. Man har jo ikke lenger innsikt i prosessen og forutsetninger for å si om den er digital nok. Her vil motargumentet være benchmarking av tjenester mot andre tilsvarende leverandører. Likevel er det unektelig faktum at mange nå henter hjem igjen arbeidsplasser for å få kortreist effekter, samt kunne robotisere eller aksellere digitaliseringen.

Avhengigheten øker ift. business partneren. Dette kan over tid medføre lavere IT servicenivå. Hvis man da ikke har klare KPIer og muligheter for å begrense skadene – eller hindre mulige «hold-up» situasjoner.

Når man så har bestemt seg og skal igang med offshoring av IT, så kreves god bestillerkompetanse. Foruten gode standarder og krav til kontraktsforståelse i innkjøpsprosessen, så kreves godt definerte tjenester som lar seg outsource. Det du vurderer å sette bort må være på et vis standardisert – eller ha som mål å bli standardisert.

Leverandører tilbyr deg gjerne å gjøre standardiseringen, men det kan fort blir dyrt om man outsourcer før man har laget en god beste praksis prosess med KPI-er som måler effektivitet.

Forholdet til ITIL bør avklares. ITIL er en beste praksis IT service management standard som nyttes av tjenesteleverandører. Ikke alle er like flinke til å bruke en ITIL-leverandør. ITIL kjøp gir  også en rigiditet som ikke alltid oppleves som brukervennlig, Man må derfor ha gode avtaler som er forståelig og ikke kun iht. IT leverandørens standard.

Det bør være snakk om å sette igang med benchmarking og at IT leverandøren har opplegg for å gi ut måltall. Dette må inn i kontrakten med IT leverandøren for å unngå at denne får for mange soveputer under armene som vi kaller det på godt norsk. Uten målinger blir oppfatning av service subjektivt og individuelt – og vi blir ute av stand til å ha et objektivt kritere for reduksjon i betaling.

Gevinstdeling er for de som har benyttet dette et must og resulterer i mer fornøyde kunder.
En tjenesteleverandør skal være hyggelig og imøtekommende, men det er klart at dersom man har økonomiske insentiver til å oppføre seg på en pen og høflig måte, så vil det hjelpe på. Servicemålinger kan være en måte å måle brukertilfredshet på. Slik man møter i sikkerhetskontrollen på en flyplass for eksempel.

Sikkerhetsfokus og mål for risiko er like viktig i basisorganisasjoner som har IT brukere som i
Offshoring. Ellers gir det økt sårbarhet. Vi har sett i den senere tid at persondata kommer på avveier. Vi har også sett at tilgang for offshorepersonnel til helsedata gir sårbarheter som vi vil være foruten. Å sikre seg er enkelt ved å gjennomføre sikkerhetsanaslyser før, under og etter. Man bør også lage seg et risikobasert ledelsessystem som kan monitorere kritiske prosesser og få på plass sikre katastrofeplaner. Dette gjelder både SMB og konsern.

Digitaliseringsutfordringen kommer også på dette området. Mange ønsker å våre i «lead» på digitaliseringsområdet. Tjenester vil kunne forandre og helt eller delvis eliminere prosesser – med uvisst utfall, men dette kan jo også innbakes i kontrakter med din IT business partner.

En trussel kan være at man ikke lenger trenger offshoringvirksomheten, men IT kompetansen er uansett nødvendig enten den kjøpes fra en IT business partner eller eies internt. Kunnskapen om effektive arbeidsprosesser går forhåpentligvis heller aldri av moten.

Outsourcing og nearshoring er også i endring. De fleste bransjer er i endring, og robotosering av tjenester er på vei inn – f.eks. i form av chatbots for support. Kanskje er man enda bedre rustet til å ta ibruk nye tjenester ved en kjøpsbasert IT tjenesteleveransemodell?  Vi vil nok se store endringer også på dette området i årene fremover. Man kan ha de beste intensjoner, men uten KPIer og uten gode IT kontrakter som gjenspeiler gjensidighet i  partnersavtalene så ville jeg vært skeptisk til outsourcing.

Les mer om offshoring og nearshoring i andre artikler.

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.

Utfordringen med å være ERP-leverandør

For bedrifter som lever av å produsere standard programvare for mange virksomheter, såkalte ERP-leverandører, er det viktig å hegne om intellektuell kapital for å sikre fremtidige lisensinntekter. Man bygger tradisjonelt murer rundt produktet og barrierer mot konkurrentene. Mangel på åpne løsninger gjør det imidlertidig vanskelig å integrere ERP mot fagsystemene hos brukerbedriftene, noe som igjen kan føre til dårlig datakvalitet i overføringer mellom systemer og tidkrevende dobbeltarbeid.

For kunder av ERP-leverandører som er brukere over tid oppstår gjerne flaskehalser i arbeidsprosessen og relativt kunstige grenser for hva som ligger i ERP systemet og hva man «må gjøre på siden» i MS-Excel eller i fagsystemer. Man skulle tro at ERP-leverandørene etter 30 år har funnet en løsning på dette. Svaret er nei, ettersom ERP først og fremst er standardsystemer. Ved innføring sementeres gjerne arbeidsprosesser som man senere vokser ut av uten mulighet til å endre en rigid ERP-plattform i ettertid. Det er jo bygd inn enorme mengder funksjonalitet i ERP-system. Likevel er det et betimelig spørsmål om ERP-systemet fremdeles er tilpasset arbeidsprosessen, eller om det ble motsatt. Brukerne kjenner gjerne kun en brøkdel av hva som er mulig, og man blir prisgitt dyre konsulenter (SAP, Oracle, IFS) for å lære seg nye veier. Brukervennligheten oppleves dermed ofte som lav – så også nytten. Dette er dårlige signaler til ERP-leverandørene.

ERP-PLM-fag

Brukerbedrifter som opplever at ERP-systemet ikke lenger dekker hele behovet blir ofte tvunget til halvmanuelle løsninger for å omgå problemet.  Eller man forsøker å overføre informasjon til ved å integrere ERP med andre IT-systemer i verdikjeden, enten det er CRM, CAD, PLM eller fagsystemer – noen ganger også Excel(!). Det er da problemene oppstår. Ettersom ERP-systemene ofte er «proprietære» eller beskyttet, koster det veldig mye å integrere. Dårlige integrasjonsløsninger gir igjen utfordring med kvaliteten på data; Sjulte kostnader som følge mangelfull ERP-prosesser oppstår når man ikke lenger kan stole på det man har hentet ut i Excel.

tannhjul

Utfordring nr.1 er altså at ERP-systemene ikke bygger på åpne standarder som gir tilgang til riktig informasjon og kvalitet på dataene til enhver tid.

Ethvert IT-system har en innebygd arkitektur som ligger i bunnen av produktet. Denne er det vanskelig å gjøre noe med. Og som bruker er du prisgitt leverandørens valg ift. åpne standarder for å integrere mot andre IT-system. Selv har jeg erfaring fra SAP-verdenen, hvor muligheten for å konfigurere standardløsninger er mange. Likevel brukes enorme krefter på tilpasning fordi systemet ikke er tilstrekkelig basert på en åpen standard. For å trekke en parallell; Det er ikke et tilfang av valgmuligheter som tilsvarer det vi finner av Apper og muligheter på mobile plattformer som Android osv., selv om ERP-bransjen er langt mer moden. Min påstand er derfor at det er ERP-leverandørene selv som holder tilbake for standardisering og åpenhet.

ERP-leverandørene er store og uten sammenlikning forøvrig, likner de store bilprodusenter som ligger etter på å fylle behovene til kunden og fremdeles satser på diesel når forbrukere (i Norden) forøvrig ser etter plug-in hybrider og bensin som regnes som mer miljøvennlig. Vil ERP-leverandørene klare å omstille seg iht. brukerkravene, eller har de resignert?

Tradisjonelle ERP-systemer er gjerne basert på teknologier fra 80- og 90-tallet. De er gjerne forsøkt fornyet, men er likevel umåtelig komplekse i oppbygning og uegnet til å linkes mot de mer kreative arbeidsprosessene som kreative produktbedrifter har. Innen ERP-industrien finnes det heldigvis lyspunkt – en voksende skog av løsninger som  er fullstendig nettbaserte og lett forståelig. De består gjerne av moduler og komponenter som lett kan integreres og har API-er som gjør det mulig å bygge IT-systemet etter egne behov. Ikke ulikt din mulighet til å velge  Apper på din mobil. Likevel er tilgangen til data i skyen for annen informasjon i systemene dine – fagsystemene ikke tilstede. Da er man tilsynelatende like langt. Kanskje er «in-house» ERP fremdeles en nødvendighet for å integrere mot tekniske fagsystemer?

Utfordring nr. 2 er at ERP-systemet av natur skiller seg fra fagsystemene dine.

Det finnes faglige behov som ikke løses av ERP-systemet. Fagsystemene inneholder informasjon som ikke er relevant for økonomer, men som trengs av fagteknisk personell og som vedlikeholdes i hele verdikjeden fra salg til service. (Her snakker vi om en verdikjede for en typisk produktbedrift.). I fagsystemet ligger alle detaljene som naturen til virksomheten krever. Den er gjerne også i ulike stadier «intern»,  «uferdig» og på analysestadiet, dvs. at data ikke er egnet til å publiseres.

Noen ERP-leverandører forsøker med vekslende hell å sluke leverandører av fagsystemer og tvangsintegrere dem via mer eller mindre vellykkede oppkjøp. Dette resulterer dessverre gjerne i overforenklede standardløsninger. Fagapplikasjoner er av natur tilpasset virksomheten over tid og blir gjerne «flikket» på av interne folk som kjenner bedriften; folk med teknisk bakgrunn eller andre eksperter på faget. ERP er jo først og fremst standardisering og oppfølging av administrative, økonomi -og logistikkprosesser. Fagprosesser kan være konsultative, gjerne ustrukturerte, komplekse og iterative av natur. ERP- og fagsystemer er mao. ofte av natur ulike.

Der man i ERP verdenen ser variasjon som en kostnad, ser man i fagapplikasjonen en kilde til differensiering. Samtidig  gir ERP økt kostkontroll og skalerbarhet på logistikk. Vi trenger dem jo begge til sitt bruk. Problemet er at  det krever så stor innsats å koble verdikjeden mellom fagapplikasjoner og ERP i en verden uten åpenhet (Utfordring nr.1).

ERP-leverandører har lenge forsøkt å gå oppstrøms og kjøpe seg fagsystemer for eksempel PLM-leverandører. Noen forsøker til og med å si at de er «PLM-orienterte». For kunder som biter på, vil det si at man erstatter fagsystemene med standardsystemer. Dette kan gi meget kompliserte utfordringer og er ikke en vei for å sikre differensiering og lønnsomhet. Dersom man derimot hos en ERP-leverandør har en åpen standard og en moderne teknologiplattform stiller det seg annerledes. Da er det gjerne mulig å skreddersy for egne behov utenpå det hele.

Oppsummering:
Utfordring nr. 1 – mangel på åpenhet. 
Enhver ERP-leverandør bør unngå fellen med å låse kunden inne i et proprietært system uten åpne standarder. Man bør også gjøre ERP-systemet tilgjengelig på åpne plattformer som gjør det mulig å integrere med PLM-systemer f.eks. gjennom et åpent API. Bedriftseiere bør se etter åpne ERP-systemer – ikke store proprietære løsninger.

Utfordring nr. 2 – ERP skiller seg av natur fra fagsystemene. ERP er standard og fagsystemer skreddersøm. Derfor er åpenhet også så viktig. Virksomheter av en hvis størrelse som har egne fagsystemer bør fortsette med det og ikke falle for fristelsen å løse alt i ERP-systemet. Fagsystemene bør selvsagt også basere seg på modularitet og åpenhet slik at informasjonsutveksling kan foregå med andre systemer i verdikjeden.

Integrasjon og skreddersøm er til en viss grad uunngåelig for en ERP-leverandør i 2015. Det er samtidig en mulig kilde til differensiering overfor konkurrenter om man legger til rette for det – og dermed en kilde til lønnsomhet for brukerbedriftene.

I en verden hvor standardisering er et mantra, trenger vi mer og flere åpne løsninger og muligheter for effektive arbeidsprosesser som overgår det dagens ERP-systemer gir. Utfordringen er herved overlevert ERP-leverandørene. Hele virksomhetens informasjonssystem bør baseres på åpenhet og integrerte løsninger til beste for brukerne og bedriften selv.

Gi din kommentar på CIO bloggen.