Cranfield-modellen

Den model der bliver gennemgået nedenfor vedrører IT strategier. Jeg har kaldt den Cranfield-modellen fordi den er inspireret af et foredrag jeg hørte for mange år siden. Foredragsholderen var fra universitetet i Cranfield og han var en god underviser. Desværre udleverede han ikke noget materiale og mine notater var sparsomme, så det er muligt at jeg har misforstået meget af det, men de fire hovedkategorier er i hvert fald rigtige. Problemområderne er baseret på mine egne erfaringer og kan anvendes på Application Architecture niveauet i Winding Stairs metoden.

Modellen foreslår at man kategoriserer it-systemerne i fire katagorier (A, B, C, D) + noget systemintegration, jf. Kompleksitet.

De fire kategorier er:
A. Key Operational
B. Support
C. Strategic
D. High potential

Desuden er der så noget systemintegration der skal få det hele til at hænge sammen.

I det følgende beskrives hver enkelt kategori nærmere, og det anføres hvilke strategier der bør anlægges samt hvilke problemer der typisk er knyttet til dem.

Systemer i denne kategori er fx systemer til styring af økonomi, produktion og logistik. De er:

• Forretningskritiske
• Tværorganisatoriske
• Legacy eller standard ERP
• Forholdsvis statiske.

Netop fordi de er tværorganisatoriske kan man ikke uden videre ændre dem, og da de endvidere er forretningskritiske, er den anbefalede strategi at etablere dem i et:

• Stærkt kontrolleret miljø

Typiske problemer med systemerne i denne katagori er:

• Fastlåst teknologi (legacy), svært at skabe sammenhæng med nye teknologiske muligheder.
• Store omkostninger til drift og vedligehold
• Afhængighed af nøglemedarbejdere, manglende dokumentation
• Problemer med større ændringsprojekter
• Manglende funktionalitet (ERP)
• Besværlige/uforståelige processer
• Problemer med opgraderinger
• Problemer med support
• Dårlig overensstemmelse med systemets virksomhedsmodel

Systemer i denne kategori:

• Letter det daglige arbejde
• Er typisk baseret på office-produkter eller værktøjer (fx SAS)
• Anvendes Lokalt
• Kompenserer for manglerne ved A (key operational).

Strategiel for denne kategori bør være:

• Standardisering og omkostningskontrol

Typiske problemer er:

• Skjulte (ofte store) omkostninger
• Afhængighed af enkeltpersoner
• Ofte forkert teknologivalg (regneark i st. f. Database)
• Mangler dokumentation, konfigurationsstyring og kvalitetskontrol
• Skrøbelige men ofte forretningskritiske

Disse systemer

• Støtter virksomhedens konkurrencefordele. Som Michael Porter siger: Man har kun fordele frem for andre hvis man gør nogen ting anderledes end andre.
• Forskellige fra andre virksomheders systemer
• Specialudviklede eller emerging tech. (teknologisk forspring).
• Afgørende for virksomhedens fremtidige forretning

Strategi:

• De skal identificeres og implementeres så hurtigt som muligt i organisationen.

Typiske problemer:

• Problemer med at fastholde fokus på forretningsstrategien
• Projektet ”gror”, kompleksiteten stiger, resultater udebliver
• Problemer med brugerorganisationen
• Problemer med systemintegrationen

Disse systemer er:

• Alle de gode ideer der opstår i organisationen
• Typisk baseret på aktuelle behov

Strategi:

• Afgør på så tidligt et tidspunkt som muligt om de har en fremtid som kategori A, B eller C

Problemer:

• Der går for lang tid før de gode ideer bliver afprøvet i praksis
• Der går for lang tid før de dårlige ideer bliver sorteret fra
• De opstår lokalt og bærer præg af manglende overblik

Dette består af de delsystemer, databaser, værktøjer etc. der får det hele til at hænge sammen. Det helt afgørende her er datadefinitionerne. Forskellige systemer har ofte forskellig opfattelse af de samme ting. Fx:

En kunde i salgssystemer er en som man afgiver tilbud til (eller på anden måde arbejder/bruger tid på). I økonomisystemet er det en debitor. En startdato i ordresystemer kan være kontrakttidspunktet. I projektsystemet er startdatoen den dato hvor man begynder på scope definition hvilket sker (eller bør ske) i tilbudsfasen. Bemærk at opgaveafgrænsningen er en del af projektet.

Problemer:

• Datadefinitioner
• Dataaktualitet på tværs af platforme
• Integritet
• Kompleksitet
• Opgraderinger. Når ét system opgraderes vil det ofte kræve tilsvarende opgradering af de systemer det udveksler data med.

Systemerne i de fire kategorier A-D vil ofte ændre status med tiden.

• Systemerne i kategori A vil være de mest statiske, men de vil være genstand for revidering, opgradering, evt. udfasning. Erfaringerne viser at den gennemsnitlige levetid er 10 år eller mere.
• I kategori B kan det forekomme at vigtig funktionalitet bliver inkorporeret i kategori A systemerne. I øvrigt vil de ofte forsvinde i forbindelse med ændringer af opgaver eller personale.
• Katagori C ses nogen gange inkorporeret i A, fx i de tilfælde hvor det strategiske hænger sammen med et teknologisk forspring. Fx indebar et MPS-system (materiale og produktionsstyringssystem) for mange år siden et forspring. Nu er det for det meste standardfunktionalitet i et ERP system.
• Kategori D vil (hvis man er heldig) vise sig at have strategisk potentiale. Ellers vil det (og det er nok det almindeligste) få status som supportsystem. Endelig kan det vise sig at idéen ikke var så god endda - og det droppes.