Kategoriarkiv: Enterprise Architecture

Strategisk verktøy for virksomheten. EA omfatter både IT og prosessanalyse (EA Modellering = EAM).

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.

 

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.