sharepoint-arkitekt · olika ut från individ till individ. sharepoint-arkitektens erfarenhet och...

2010-02-01

Avsikten med detta White Paper är ett försök att definiera

vad en arkitekt inom IT sysslar med i samband med infö-

randet av SharePoint i en organisation.

Anledningen är den i mina ögon totala förvirring som rå-

der för närvarande om vad begreppet ”SharePoint Arki-

tekt” egentligen står för.

Dokumentet är en partsinlaga och ett diskussionsunderlag

som med fördel behandlas och diskuteras inom organisat-

ionen IASA – Sveriges IT-arkitekter.

Synpunkter, invändningar och önskemål om komplette-

ringar sker enbart via Linkedin och den öppna gruppen

Sveriges IT-arkitekter IASA Sweden.

SharePoint-arkitekt

Rollbeskrivning och arbetsuppgifter

http://www.linkedin.com/groups/Sveriges-ITarkitekter-IASA-Sweden-1965475?trk=myg_ugrp_ovr

Bakgrund

2 av 21

Innehåll

Bakgrund .................................................................................................... 4

Syftet med dokumentet ............................................................................................................................................ 4 Begreppsförvirringen och den oklara arkitektrollen ................................................................................................. 4 Min egen väg mot rollen SharePoint-arkitekt .......................................................................................................... 4

IASAs definitioner ...................................................................................... 6

De fyra fastställda rollerna ...................................................................................................... 6 Arkitektroller i Sverige enligt IASA (2007) ............................................................................................................ 6 När arkitekten jobbar med SharePoint är han alla fyra! ........................................................................................... 7

SharePoint-arkitekt = Programmerare? ................................................... 8

Ett försök att sortera rollbegreppen! ........................................................................................................................ 8

Vad som kanske stör bilden… .................................................................... 9

Tradition och ”gammalt” tänk.................................................................................................................................. 9 IT-avdelningen roll .................................................................................................................................................. 9 Företagsledningens roll ............................................................................................................................................ 9 Vem anlitar ”SharePoint Arkitekten”? ..................................................................................................................... 9 SharePoint som Internetlösning ............................................................................................................................. 10

SharePoint-arkitektens arbetsområden .................................................. 11

Målet och delmålen med SharePoint ..................................................................................... 11 Originalprincipen ................................................................................................................................................... 11 Effektivare samarbete ............................................................................................................................................ 11 SharePoint som socialt media ................................................................................................................................ 11 Dokumenthanteringen ............................................................................................................................................ 12 Dokumentavveckling ............................................................................................................................................. 12 Datasäkerhet (Backup och Restore) ....................................................................................................................... 13 Utbildning och indoktrinering (förändringsarbetet) ............................................................................................... 13 Internet eller ”bara” Intranät? ................................................................................................................................ 13

Analys av hela verksamheten ................................................................................................ 13 Kärnverksamheten ................................................................................................................................................. 13 Stödjande verksamheter ......................................................................................................................................... 14 De egentliga behoven ............................................................................................................................................. 14 Nuvarande processer och verktyg .......................................................................................................................... 14 Vem är projektägare för SharePoint-projektet? ...................................................................................................... 15

Informationsplanering och involvering ................................................................................ 15 Förändringsarbete är svårt, det handlar ju om människor och invända beteenden ................................................. 15 Media ..................................................................................................................................................................... 15 När, hur och varför................................................................................................................................................. 15 Uppföljning ............................................................................................................................................................ 15

Strukturer i SharePoint (Site på Site och Pages).................................................................. 15 Tro inte att SharePoint är enkelt även om det verkar så ......................................................................................... 16 Kan ISO9000 vara till hjälp? ................................................................................................................................. 16 Från Filservern till dokumentarkiven i SharePoint ................................................................................................ 16 Mappstrukturer ...................................................................................................................................................... 16 Metadata ersätter Mapparna ................................................................................................................................... 16 Om det sociala nätverket i SharePoint (MySite) .................................................................................................... 16

Processer och Workflows ...................................................................................................... 17 Säkerhet ................................................................................................................................. 18 Behörigheter i SharePoint och/eller Active Directory (AD) .................................................................................. 18

Bakgrund

3 av 21

Backup-strategi ...................................................................................................................................................... 18 Restore-strategi (Återläsningsstrategi) ................................................................................................................... 18 Disaster Recovery .................................................................................................................................................. 19

Utbildning, eller medveten ”indoktrinering” ........................................................................ 19 Inte bara handgrepp utan även hur och varför ........................................................................................................ 19 Utbildningsmaterial – «User Guides» .................................................................................................................... 19 Presentationer ........................................................................................................................................................ 19 E-learning .............................................................................................................................................................. 19

Förvaltning och support (Help Desk) .................................................................................... 20 Utbildningsaspekter ............................................................................................................................................... 20 Ansvar och befogenheter ....................................................................................................................................... 20 Verktygslådan ........................................................................................................................................................ 20 Problem management ............................................................................................................................................ 20

Integration med andra system .............................................................................................. 20 Anledningen är att SharePoint först måste fungera ................................................................................................ 20 Konventionell system- och programutveckling ..................................................................................................... 21

Illustrationer

Bild 1: IASAs fyra arkitektroller inom IT ...................................................................................... 6

Bild 2: Vad är en SharePoint-arkitekt jämfört med IASAs fyra definierade roller? ........................... 7

Bild 3: Alternativa färdigheter och profiler som SharePoint-arkitekt ............................................... 7

Bild 4: Fördelningen av Workflow Tools i SharePoint .................................................................. 17

Bakgrund

4 av 21

Bakgrund

Syftet med dokumentet Syftet med detta White Paper är att beskriva de arbetsuppgifter som ingår i en

SharePoint-arkitekts arbetsuppgifter så att det framgår vad som är arkitektarbete

för en arkitekt som jobbar med SharePoint. Dokumentet är en partsinlaga från

min sida och speglar därför min syn och erfarenhet.

Begreppsförvirringen och den oklara arkitektrollen Gång på gång har jag fått uppleva via konsultförmedlares erbjudande om upp-

drag som SharePoint-arkitekt att ”kunden” egentligen sökt en programmerare.

Det är de besked jag för det mesta får från konsultförmedlaren.

Ett annat område är en offentlig upphandling där Job-beskrivningen såg ut att

stämma väl överens med dels min profil men även i form av en tänkt arkitekt

inom SharePoint. Av de så kallade skallkraven som måste uppfyllas fanns även

här en uppräkning av ett antal programmeringsspråk. Döm om min förvåning när

det idag gamla programmeringsspråket COBOL fanns med. Visserligen var jag

enligt mitt tycke en rätt bra COBOL-programmerare under 80-talet men vad har

COBOL med SharePoint att göra i dagens läge? Jag klev av anbudsprocessen

trots att uppdraget var långt och för övrigt stämde väl med vad jag tänkt om min

och min familjs öden och äventyr.

Min egen väg mot rollen SharePoint-arkitekt Under större delen av 90-talet var jag involverad i uppdrag och projekt som var

rena kvalitetsutvecklingsprojekt. Det hela kröntes av att jag som projektledare

fick ansvaret att erövra certifikatet ISO9001 TickIT för det företag där jag då var

anställd som IT-konsult.

Utifrån dessa erfarenheter fick jag en god inblick i ett par organisationers verk-

samhet ända uppe från ledning ner till de enskilda arbetsuppgifterna ”på golvet”.

I efterhand har jag insett att jag iklädde mig rollen som verksamhetskonsult men

avsaknaden av akademisk utbildning har alltid varit ett trauma eller hinder att er-

känna att jag faktiskt kan något. Helt enkelt en form av tillämpad ”jantelag”.

Några systemutvecklingsprojekt, utredningar och systemförvaltningsroller kom

sedan i vägen eller också var det som så att jag ansåg att jag skulle lära mig ytter-

ligare områden på vägen mot arkitektrollen?

När jag sedan hamnade i ett team som sysslade med «Desktop Management»

inom dåvarande Scandinavian IT Group så inleddes en viktig inlärningsprocess.

Jag fick eller snarare tog mig rollen som «Information and Quality Manager».

Här såg jag vådan av att gå från en filserver till ett modernt dokumenthanterings-

system typ «Documentum» och senare SharePoint. Inledningsvis utvärderade jag

ett antal verktyg för dokumenthantering bland annat för att vi inte fick ta

«Documentum» i bruk av politiska skäl. Sedan hittade jag SharePoint 2003 och

resan inleddes mot nya insikter som slutade med en genomgripande implemen-

tation av SharePoint 2007 (WSS3).

Senare kände jag att jag ville få ett eget område i en för övrigt mycket kompetent

organisation som helt ägnade sig åt SharePoint. Jag fann DocAve från företaget

AvePoint och lärde mig på egen hand deras produkter. Jag blev omedvetet en IT-

säkerhetsexpert inom SharePoint och upprätthåller än idag en sådan roll i och

med att jag jobbat med DocAve, TSM for SharePoint samt SMMOSS för kun-

ders räkning. De två sistnämnda är OEM-versioner av AvePoints produkt

Bakgrund

5 av 21

DocAve. Backup och Restore av SharePoint plus lång erfarenhet av behörighets-

kontrollsystem (BKS) blir för mig en roll som handlar om säkerhet i SharePoint.

Men även IT-säkerhetsexpert är ett begrepp som förvirrar. Min syn och erfaren-

het är skyddet av information och dokumentation i SharePoint samt BKS och i

princip inget annat. Penetration (konsten att hacka sig in) är en profession som

andra är mer kompetenta att hantera, exempelvis företaget TrueSec.

Säkerhetsfrågorna inom SharePoint är en viktig del i min tänkta roll som Sha-

rePoint-arkitekt, men det finns mer. Men först måste vi ta en titt på vad IASA

anser att en arkitekt inom IT jobbar med.

IASAs definitioner

6 av 21

IASAs definitioner

De fyra fastställda rollerna

Bild 1: IASAs fyra arkitektroller inom IT

Arkitektroller i Sverige enligt IASA (2007) Dokumentet som beskriver rollerna mer i detalj hittar du via länken

http://www.iasa.se/wp-content/uploads/2009/08/Arkitektroller-i-Sverige-2007.pdf

Ur min synvinkel tycker jag att dokumentet är bra ur många avseenden. IASA

har sorterat ner arkitekturbegreppet från runt ett 50-tal varianter inom IT ner till

fyra samt definierat vad de olika rollerna innebär.

Jag stödjer därför definitionen fullt ut och ser möjligheter att klargöra dels var

jag själv befinner mig i förhållande till arkitektrollen men även som ett klargö-

rande på marknaden för att undvika missförstånd speciellt vid rekryteringar och

köpandet av konsulttjänster.

En annan fördel blir på sikt att vi som erkänner oss som arkitekter inom IT kan

samverka genom begreppen i sociala medier typ Linkedin, Facebook, Twitter

och en och annan blogg.

http://www.iasa.se/wp-content/uploads/2009/08/Arkitektroller-i-Sverige-2007.pdf

IASAs definitioner

7 av 21

När arkitekten jobbar med SharePoint är han alla fyra!

Bild 2: Vad är en SharePoint-arkitekt jämfört med IASAs fyra definierade roller?

Betrakta bilden ovan och se dig själv i spegeln. ”Spindelnätet” som jag lagt över

IASAs fyra roller har jag stämt av med IASA. Reaktionen var överlag positiv!

Beroende på utbildning och tidigare erfarenheter så menar jag att spindelnätet ser

olika ut från individ till individ. SharePoint-arkitektens erfarenhet och utbildning

medför att man drar i de fyra hörnen uppåt, nedåt och åt sidorna i ett försök att

förstå vad som är den individuella styrkan och även ambition.

Bild 3: Alternativa färdigheter och profiler som SharePoint-arkitekt

Mer och bred utbildning i kombination med erfarenhet medför att spindelnätet så

gott som täcker hela bilden. Lägre utbildning och erfarenhet medför att spindel-

nätet rör sig åt en bestämd cirkel och smalnar av antingen horisontellt eller dia-

gonalt.

Jag vill med det här dokumentet hjälpa dig att förstå hur ditt eget spindelnät bör

se ut eller vilka ämnen du bör läsa inom universiteten om du strävar efter att bli

en arkitekt inom IT. Som du ser så väljer jag att skriva «arkitekt inom IT» istället

för IT-arkitekt. Det sistnämnda begreppet ger på något sätt en viktning åt något

håll som blir i motsats till IASAs fyra definierade roller.

I förlängningen vill jag naturligtvis att rekryterare och konsultköpare ska förstå

problematiken samt skriva vettiga platsannonser och ansökningar av konsulter

utifrån en samsyn på den svenska företagsmarknaden och offentlig sektor. Målet

är att rätt resurs arbetar med implementationer av SharePoint på rätt sätt och i

rätt ordning samt inte minst med rätt målbeskrivning med implementationen.

SharePoint-arkitekt = Programmerare?

8 av 21

SharePoint-arkitekt = Programmerare?

Ett försök att sortera rollbegreppen! Naturligtvis finns det anställda och konsulter som även kan programmera och

som galant kombinerar detta med färdigheter som en arkitekt sysslar med enligt

IASA genom att även programmera inom samma teknikområde. Så det finns

egentligen inget bra svar på huvudrubrikens fråga. Dessutom är det min be-

stämda avsikt att inte rangordna någon. Jag känner själv flera kompetenta Sha-

rePoint-nördar som både är duktiga arkitekter som skickliga programmerare.

Om ett företag letar efter en sådan stjärna så ska man naturligtvis göra det och

sätta sina krav utifrån vad man vill ha ut av individen ifråga. Men risken finns att

det blir en aning förvirrat. Vad är det egentligen man vill ha och vart är man på

väg med sin SharePoint-installation? Går det dessutom att utläsa av platsannon-

ser och konsultannonser vad kunden ifråga är någonstans i processen med att in-

föra SharePoint? Jag har inget svar på den frågan.

Finns det dessutom risk att man missar de resurser som inte faller inom ramen?

Jag vill tro det eftersom jag skriver det här dokumentet. Man kanske har en upp-

fattning om vad som ska genomföras men som riskerar att ställas på ända om

man anställer eller anlitar en ren arkitekt som har djupare kunskaper och erfaren-

heter av n rad områden och som är specialistkunskap som kanske bara arkitekter

lärt sig?

Bredden som krävs idag av IT-folk medför att problemen blir fler och fel. Därför

är det viktigt att begrepp tydliggörs och definieras så att dels företagen får in rätt

resurser och dels att specialisterna ser att kraven stämmer överens med vad man

kan och har erfarenhet av.

En programmerande SharePoint-arkitekt tror jag har svårt att fördjupa kunskaper

i arkitektspecifika arbetsuppgifter eftersom det å andra sidan tar tid att bli duktig

på alla tekniska detaljer som dagens programmeringsspråk innebär. Om man

dessutom lägger till de personliga egenskaperna samt vad individen ifråga helst

vill jobba med så blir bilden än mer komplex. Ett eget djupt intresse där man

känner att ens egen talang kommer mest till sin rätt är enligt min mening att fö-

redra speciellt när man tänker i termer som «Kul på jobbet», «Intressanta utma-ningar» med mera.

Vad som kanske stör bilden…

9 av 21


Tradition och ”gammalt” tänk Jag har en känsla av att SharePoint kommer in i företagen och stora organisat-

ioner via sin IT-avdelning. Alltså är grundidén systemutveckling i konventionell

mening där synen på SharePoint som en utvecklingsplattform med en SQL-

databas i botten leder in tänket mot kravspecifikation, projektering, utvecklings-

projekt, test, systemtest, skapandet av utbildningsmaterial och dokumentation

samt överlämning till en förvaltare. Med andra ord den traditionella långa vägen

trots Scrum och Agila metoder.

Det tydligaste problemet när SharePoint tas i bruk är ändå bruket av foldrar som

härstammar från filservrar och PC. Till och med den mest inbitne teknikern är

van att gå ner i Windows och leta detaljer via folder på folderstrukturer även i ett

så nytt operativsystem som Windows 7. Så insikten och fördelarna med Meta-

data finns inte eller står långt ner på prioritetslistorna. Man inser och kan inte se

fördelarna eftersom det är ett helt annorlunda tänkesätt som dessutom ger massor

med nya fördelar i att hitta rätt dokument.

IT-avdelningen roll IT-avdelningar har i allmänhet en egen agenda! Man vill sysselsätta sin IT-

personal som för utvecklingsdelen är programmerare. Det är därför rätt naturligt

att man ser SharePoint som en ny och modern plattform för system och pro-

gramutveckling.

På övre nivå inom verksamheter från VD och strax under har man i allmänhet

inte tid att sätta sig in i vad SharePoint kan göra för verksamheten. Man litar

dessutom helt på sin CIO som mer eller mindre omedvetet har en annan agenda

än förtagets kärnverksamhet.

Företagsledningens roll De som borde hitta SharePoint som ett led att effektivisera verksamheten genom

effektivare processer, effektivare möjligheter till samarbete, information samt

inte minst effektivare dokumenthantering borde vara företagsledningen från VD

och nedåt.

Företagsledningens primära uppgifter är att sänka kostnader, öka försäljningen,

öka marknadsandelar, tillfredsställa aktieägare samt växa som företag för att

nämna några viktiga arbetsuppgifter. I konkurrens med dessa arbetsuppgifter står

inläsningen av vad man kan åstadkomma med hjälp SharePoint långt ner på

agendan. Man har helt enkelt inte tid. Därför måste företagsledningarna lita på

sin IT-personal och där har vi problemet förutsatt att jag har rätt i mitt antagande

tidigare.

Det kan helt enkelt bli fel från början genom att man börjar implementation i fel

ända av tidsaxeln. Det börjar komma signaler om behovet av strategier visavi

SharePoint. En signal som säger mig att företagsledningen «har vaknat till».

Vem anlitar ”SharePoint Arkitekten”? Jag menar att företagsledningen anlitar eller anställer en SharePoint-arkitekt. An-

ledningen är att SharePoint i mina ögon och erfarenhet är ett verktyg för att inom

hela företaget omforma arbetssätt, processer (Workflow), dokumenthantering

och information i en ambition att sänka kostnader samt öka produktiviteten.


10 av 21

Om IT-avdelningen får ansvaret så blir det med automatik ett IT-projekt eller

flera. Konstigt vore det annars och så har det alltid varit.

Jag menar att det krävs nya kunskaper om verktyg typ SharePoint på hög nivå

inom företagen innan man sätter igång en omfattande implementation som

kommer att förändra mycket inom organisationen samt i synnerhet företagets

processer.

SharePoint som Internetlösning Om man valt SharePoint som sin nya hemsida för företaget så är bilden en an-

nan. Här finns med all säkerhet djup teknisk kunskap tidigt med i processen.

Branding

Ett företags profil måste implementeras från första stund där tekniska kunskaper

i att hantera «SharePoint Designer», och CSS «Cascading Stylesheet» ligger ti-

digt i utvecklingsfasen. Även andra tekniker som «Flash», «Silverlight», JQuery, C++ eller C# är kunskaper som är en form av programmeringsprofil

där det gäller att vara skicklig på animeringar. Utöver skicklig på tekniken så bör

sådana tekniker har en utpräglad stilistisk förmåga, en form av konstnärlig ådra

rent utav. Framför allt gäller det att omsätta den dokumenterade företagsprofilen

till SharePoint-funktionalitet. Företagsprofiler är ofta framtagna av reklamföre-

tag och omfattar allt från logo ner till hur företagets brev ska se ut.

SharePoint som hemsida medför sedan ett antal fördelar i att sedan hantera den

nya hemsidan från organisationens sida. SharePoints Webb-gränssnitt är enkelt

att jobba med till skillnad mot gamla tiders Webb-verktyg som då krävde spe-

cialistkunskap i något verktyg, exempelvis FrontPage.

En del som tangerar SharePoint-arkitektens roll är här säkerhetsfrågorna som får

en dimension till, än om SharePoint «bara» implementeras som en ren intranät-

lösning. Speciellt om man dessutom väljer att kombinera internetlösningen med

intranätlösningen.

Slutsats

SharePoint-arkitekten jobbar i nära samarbete med de tekniker som behövs i en

internetimplementation men behöver inte göra de tekniska handgreppen själv.

Däremot skall en SharePoint-arkitekt finnas med under utvecklingsarbetet gärna

då i en ledningsroll/projektledare.

SharePoint-arkitektens arbetsområden

11 av 21


SharePoint-arkitekten är en mångsysslare utan att dessutom belastas med kravet

att kunna programmera. Däremot ska denne veta när olika specialister ska invol-

veras för att vid sådana tillfällen iklä sig en ledarroll som projektledare.

I IT-ålderns forntid och även före denna tidsålder hade vi Managementkonsulten

vars arbetsresultat för det mesta föranledde stora omorganisationer. Kanske den

typen av konsulter fortfarande är verksamma men då måste dessa sätta sig in i

hur företaget använder SharePoint. Annars blir det inte roligt. Kanske är Sha-

rePoint-arkitekten rent av dagens managementkonsult? I alla fall kommer denne

att bli det ju mer SharePoint inflätas i företagets verksamhet.

Målet och delmålen med SharePoint

Det gäller att fånga upp varför företagsledningen beslutat om att införa Sha-

rePoint samt, om detta saknas, formulera det hela i ett lättbegripligt mål.

Önskvärt om slutdatum kan fastställas. Det medför att SharePoint-arkitekten in-

ledningsvis måste vara en utredare.

Införandet är så pass omfattande att målet ska delas upp i väldefinierade delmål.

På så sätt kan beslut fattas om att stoppa eller ändra färdriktning efter varje del-

mål. Att inte dela upp projektet i delmål skapar risken att man aldrig blir färdig.

Måldatum bör vara då det löpande arbetet med att administrera SharePoint över-

går i förvaltning och att man nått alla delmål.

Originalprincipen Boken ”Kvalitetsutveckla med SharePoint 2007” definierar Originalprincipen

utgiven på Recito förlag i Borås 2008. Beskrivningen går ut på att man helt slutar

med eller minimerar E-post internt inom förtaget. Anledningen är att E-post är

ett jämförelsevis ineffektivt sätt att hantera information och diskussioner. När

alla inom en organisation förstått SharePoint och använder SharePoint på rätt sätt

så effektiviseras processerna dels genom att information och dialog inte upprepas

gång på gång mellan olika grupper av medarbetare dels att dessa informationer

och diskussioner automatiskt blir dokumenterade samt åtkomliga för vem som

helst inte bara för det lilla fåtal som en utväxling av E-post medför. Speciellt blir

effekten tydlig med anledning av att SharePoints information och dokumentation

blir internt sökbar.

Originalprincipen kan med fördel vara ett mätbart mål för implementationen av

SharePoint.

Effektivare samarbete En gruppering som ett företag eller större organisation är faktiskt en organisering

av samarbete där man syftar till att nå gemensamma mål. SharePoint är ett verk-

tyg skapat för att samverka.

SharePoint som socialt media Sociala medier växer så det knakar på Internet. Facebook, Linkedin och Twitter

är tre exempel där många hittat varandra och fortfarande hittar varandra för att

utbyta både privata som professionella åsikter, tankar, erfarenheter, kunskaper,

insikter med mera.


12 av 21

SharePoint har via sin funktion «MySite» en plats som internt inom företa-get fungerar som ett socialt verktyg. Jag ser användningen av «MySite» som ett delmål som kräver både utbildning och skapandet av egna erfa-renheter i vad MySite kan göra för den enskilde i samvaron med kolle-gor. Här bryts gränserna mellan avdelningarna effektivt ner och påverkar positivt faktorer som produktivitet, företagskultur, kunskapsutbyte, vän-skap, intressen, professionella egenskaper…

Denna del av implementationen är ett viktigt delmål.

En risk med införandet av «MySite» är att samarbetskulturen när det gäl-ler gemensamma dokumentarkiv försenas. Orsaken är att «MySite» även har individuella dokumentarkiv med från start. I och med detta så forts-ätter processerna att fungera på det sätt som personliga datorer lärt oss genom åren. Var och en hanterar sina dokument i personliga arkiv som påminner om «Mina dokument» i var och ens PC. Skillnaden är att do-kumenten finns tillgängliga och dessutom sökbara via var och ens «Browser» men förutsättningen är att var och en öppnar upp läsbehörig-heter till sitt «Privata» dokumentarkiv i «MySite» genom att internt inom organisationen tillåta anonym access till var och ens dokumentarkiv.

Här krävs en genomgripande utbildningsinsats med syfte att lära ut för-delarna med gemensamma samarbetsplatser och dokumentarkiv. En na-turlig plats är organisationens projekt där möjligheterna till en förändrad dokumenthanteringskultur lättast kan förstås av det stora flertalet. Här gäller det att påverka vårt invanda beteende som personliga datorer lärt oss under lång tid.

Dokumenthanteringen Steget från en filserverkultur till ett modern och effektivt dokumenthanteringssy-

stem kan inte nog överdrivas som ett viktigt delmål. Denna del är synnerligen väl

motiverad när man nämner begreppet produktivitet.

Dokumenthanteringen kan vara ett huvudmål och ett delmål i ett större samman-

hang. Idag är ofta dokumenthanteringen det enda målet med implementationen

av SharePoint. Övrigt strategiskt tänkande kommer senare.

Dokumentavveckling Att skapa dokument samt lagra dem är hur enkelt som helst. Det är bara att

klicka på «Spara» eller «Save»! Men hur avvecklar man dokumentation som inte

längre gäller och vad är det som gäller för att ändå spara dokumentation? Här

handlar det först och främst om ett regelverk som man sedan kan effektuera med

hjälp av bland annat SharePoint. Med hjälp av tredjepartsprodukter kan man

dessutom enkelt få det att fungera genom att utgångna dokument flyttas ut från

SharePoints SQL-server till andra media. Med hjälp av produkter från exempel-

vis AvePoint kan dessa avvecklade dokument eller snarare dokumentarkiv flyttas

ut från SharePoint men ändå både ses och bli sökbara via SharePoint trots att

dessa dokument och dokumentarkiv egentligen placerats på annat medium, ex-

empelvis en gammal hederlig filserver.

Här menar jag att SharePoint-arkitekten har en roll för att få det att fungera. För-

delarna blir att SharePoints SQL-databas kontinuerligt rensas från dokumentat-

ion som inte längre gäller men där man vill ha kvar dokumenten för att uppfylla

ställningstagandet beskrivet i ISO9001 enligt det avsiktliga beslutet «Sparas för

att behålla kunskaper och erfarenheter».


13 av 21

Datasäkerhet (Backup och Restore) Att säkerställa att information och dokumentation inte försvinner eller hamnar i

händerna på fel individer är ett viktigt delmål. Här finns det massor att göra för

arkitekten. Här handlar det om att kunna behörighetsmöjligheterna i SharePoint i

kombination med viss kunskap om Active Directory (AD).

Den andra sidan av myntet «Säkerhet» är att säkerställa att all information går att

återställa i stort och i smått. Från enskilda versioner av dokument till SharePoint-

servern och även hela datorhallar.

Inom detta område är SharePoint-arkitekten även en typ av specialist på IT-

säkerhet. En roll som jag själv utvecklats mot.

Utbildning och indoktrinering (förändringsarbetet) Införandet av SharePoint är både mödosamt, omfattande och svårt. Alla inom fö-

retaget påverkas på ett eller annat sätt. Utbildning, information, erfarenhetsutbyte

är några ingredienser som är viktiga. Området är helt avgörande om införandet

av SharePoint ska lyckas och räknas hem i ekonomiska termer.

Internet eller ”bara” Intranät? Är det frågan om att företaget ska implementera en ny hemsida baserat på Sha-

rePoint eller ska SharePoint enbart implementeras som ett nytt Intranät? Dessu-

tom både och, alltså en total implementation?

Analys av hela verksamheten

Utan en inledande genomlysning av verksamheten så kan implementationen av

SharePoint gå ordentligt snett. Alltså en konventionell förstudie där möjligheter-

na med SharePoint ska vara ständigt närvarande.

Jag vill här belysa att en implementation av SharePoint kommer att påverka all

personal vare sig man vill eller inte.

Det är viktigt att även belysa vad som inte ska hanteras av eller via SharePoint!

Kärnverksamheten Jag menar att införandet av SharePoint kräver goda kunskaper om verksamheten

och att konsulten snabbt kan förstå företagets kärnverksamhet samt omgivande

stödverksamheter. Dessa delar ska enligt min mening påverka hur man inför

SharePoint.

Man kan frestas att utgå från organisationsbeskrivningar samt bygga SharePoint

baserat på dessa. Det kan bli riktigt bra och tydligt! Men vad händer vid kom-

mande omorganisation? Hela SharePoint måste struktureras om, behörigheter

ändras o.s.v.

Ett exempel som jag känner rätt väl är terminalverksamheter på en flygplats.

Kärnverksamheten är lätt att se även för den oinvigde. Uniformer, arbetskläder

och fraktcontainrar är väl synliga på en station förutsatt att man kan se skillnaden

mellan trafikassistenter och flygande personal i form av piloter och kabinperso-

nal. Kärnverksamheten är därför följande tre områden

Insidans personal som hanterar allt som rör passagerare till flygen och

även besökare på flygplatsen som inte ska iväg eller kommer per flyg.

Utsidans personal som hanterar passagerarnas bagage

Frakt eller närmare bestämt flygfrakt


14 av 21

Övrig personal ingår i den stödjande organisationen och är som du förstår svåra

att skilja från passagerare och övriga besökare på en flygplats i och med att de

inte har uniform eller arbetskläder i vanlig mening.

För tillverkande företag så tillkommer exempelvis lagerhållning och distribution.

Stödjande verksamheter Det är troligt att de stödjande verksamheterna kommer att påverkas mest av Sha-

rePoint mycket beroende på att det handlar om information och dokumentation.

Stödjande verksamheter är exempelvis

Ekonomiavdelning

Löneavdelning

IT-avdelning

VD och verksamhetsstaber

Informationsavdelning

Säljavdelning

Marknadsavdelning

Lokaler

Städning

Säkerhet

för att nämna några stödjande avdelningar som finns i princip inom varje organi-

sation. Tillkommer några till som är specifika från företag till företag beroende

på vilken verksamhet man bedriver.

De egentliga behoven Vad är det företagsledningen vill uppnå med införandet av SharePoint? Målet

kan vara

Rationalisering

Förbättring av dokumenthanteringen

Nya arbetssätt för effektivare processer

Ordning och reda

Besparingar

Personalreduktioner

Certifiering enligt någon standard, exempelvis ISO9001 för att höja an-

seendet på marknaden och kvaliteten inom verksamheten.

Förbättra samverkan

Minska det interna skickandet av E-post

Avveckla nuvarande dokumenthantering via filservrar.

Nuvarande processer och verktyg Hur fungerar verksamheten idag och vart är organisationen på väg?

Rätt man och kvinna på rätt plats

Så kallad byråkrati som även kan vara av positiv art och kallas då för

administration


15 av 21

Manuella rutiner och processer

IT-hjälpmedel

Dokumenthantering

Dokumentavveckling och informationsavveckling

Säkerhet

Vem är projektägare för SharePoint-projektet? Förslagsvis en styrgrupp med VD som ordförande eftersom införandet av Sha-

rePoint kommer att bli mycket genomgripande. En av de största förändringspro-

cesser som en organisation gör under sin livstid.

Informationsplanering och involvering

Förändringsarbete är svårt, det handlar ju om människor och invända beteenden Omgående kommer arkitekten att jobba med information i en eller annan form.

Jag rekommenderar starkt att tidigt ta i bruk bloggverktyget i SharePoint samt

använda detta som ett sätt att även få kommentarer. Alltså ingår ”informatören”

som arbetsuppgift för arkitekten. Området blir så pass stort att arkitekten måste

omge sig med utpekade specialister på information, gärna med en bakgrund som

journalist.

Media Vilka media ska användas och på vilket sätt. Utöver bloggandet, presentationer,

dokument, meddelanden, diskussioner så bör man utnyttja både ljud och bild och

då gärna filmer. Tillkommer interna tidningar samt en och annan bok.

Twitter, som hanteras utanför företaget via Internet, kommer att öka i betydelse i

kombination med interna verktyg. Twitter medför att enskilda utökar sitt sociala

nätverk och kan på så sätt ta del av information som har med de egna arbetsupp-

gifterna att göra. Twitter kommer att bli nya sätt att inhämta kunskaper och erfa-

renheter om det inte redan är det.

När, hur och varför Införandet av SharePoint är ett gigantiskt projekt där planering och uppföljning

är viktigt. Arkitekten har ett projektledaransvar med allt vad det innebär.

Utöver projektplaner så ska arkitekten även informationsplanera så att rätt in-

formation distribueras vid rätt tillfälle. Här är arkitekten en form av publicist el-

ler chefredaktör.

Uppföljning En viktig uppgift är att följa upp att information nått berörda och att budskapen

blivit förstådda.

Strukturer i SharePoint (Site på Site och Pages)

Man kan släppa skapandet av Site på Sitestrukturer fritt, men det har sina risker

vilka kan vara svåra att rätta i efterhand utan verktyg som stödjer en omfördel-

ning av strukturen. Det finns utmärkta tredjepartsprodukter som skickliga använ-

dare med verksamhetskunskap kan använda.


16 av 21

Tro inte att SharePoint är enkelt även om det verkar så Snabbheten och enkelheten är både en möjlighet och en risk. Möjligheten är att

det går snabbt att skapa SharePoint-strukturer. Riskerna är, enligt talesättet «Fort

men fel», att man skapar en massa sajter som hamnar fel eller används på ett fel-

aktigt sätt både ur behörighetssynpunkt som i själva handhavandet.

Just för att SharePoint är så pass komplett som intranät så finns det risker att det

går för fort. Risken blir att man inte ser skogen för alla träd. Jag fick för några år

sedan invändningar om att det var för svårt och omständligt att navigera rätt i

struktur som jag införde bland erfarna och duktiga IT-tekniker. Den risken är

speciellt uppenbar när det går för fort.

Kan ISO9000 vara till hjälp? Mitt svar är ja, mycket beroende att jag tidigare jobbat med ISO och har förstått

att regelverket är ett stöd att få med allt på ett strukturerat sätt.

Från Filservern till dokumentarkiven i SharePoint Den här punkten brukar vara kärnan i hela implementationen och därför oerhört

viktig att hålla styr på. Alla som går från en filserverkultur börjar omedelbart

bygga folder på folderstukturer i SharePoint. Himla tur att man från centralt håll

kan ta bort möjligheten så att man får tillfälle att skjuta in det fiffiga med Meta-

data. Men räkna med att det kommer att ta tid och att inte alla kommer att bli

frälsta. Här krävs det att arkitekten både är pedagog och diplomat samt inte minst

uthållig och oerhört envis och fokuserad där stödet från en företagsledning, väl

insatt i vad SharePoint kommer att medföra, kan vara helt avgörande.

Mappstrukturer I flertalet fall kan man genomföra förbättringen från en ingrodd folder på folder-

stuktur till en mer moderna och ändamålsenlig Metadatakultur. Men det finns na-

turligtvis undantag som måste både lokaliseras och definieras nogsamt.

Metadata ersätter Mapparna En genomgående analys av behovet av metadata måste genomföras. Här finns

det «mandatory» och övriga metadata. Med övriga metadata menar jag både lo-

kala behov som unika för vissa områden.

Ett bra underlag för ett nytt metadata är namnen på de foldrar som många skapat

på organisationens filservrar. Genom att ta med denna informationsmängd som

metadata så kan förståelsen bland användarna underlättas i att sluta skapa folder

på folderstukturer.

Här är arkitekten en utredare och kanske metadatakonstruktör.

Om det sociala nätverket i SharePoint (MySite) Jag anser att man kan öppna kranarna fullt ut. Det fungerade ju för Facebook och

Linkedin så varför inte internt i en intern SharePoint-miljö. Så slutsatsen är att

många redan är «örnar» på sociala nätverk och verktyg i och med dessa populära

miljöer. Dessutom kan det vara positivt för själva implementationen att kunna

dela ut «MySite» där man får leka rommen av sig från allra första början. Öpp-

nandet och införandet av «MySite» blir en form av språngbräda i att komma in i SharePoint.


17 av 21

Processer och Workflows

En nyligen publicerad enkät visar att den vanligaste metoden att skapa Work-

flows i SharePoint är via SharePoint Designer, alltså ett tekniskt hjälpmedel som

kräver sina specialister. Jag hade hoppats på att Nintex Workflow skulle ligga i

topp på grund av enkelheten att skapa Workflows i SharePoint.

Bild 4: Fördelningen av Workflow Tools i SharePoint

Källa: http://www.slideshare.net/derweeksglobal/sharepoint-survey-results-2011

Min tolkning av ovanstående är att IT styr och inför Workflow inom de flesta

organisationer. Det tredje alternativet (7 %) hade annars varit betydligt större.

Att Visual Studio ligger så högt (32 %) är lite oroande. Backup och speciellt

Restore blir mer komplext när man inför «egna lösningar». Tidigare har inform-

ation från Microsoft gjort gällande att «native» Backup och Restore enbart stöd-

jer standardlösningar (out of the box). Ett exempel på det är att DocAve stödjer

Nintex Workflow 2007 för SharePoint 2007 men ännu inte SharePoint 2010.

Nintex har för övrigt ny version för Nintex Workflow 2010.

Varför nu denna information?

Kan man rita ett flödesschema i ett ritverktyg så är det lika enkelt att skapa

Workflows i ett verktyg typ Nintex Workflow. Skillnaden i tid är med andra ord

minuter mot dagar i att skapa avancerade väl fungerande Workflows.

Ett exempel på ett Workflow kan vara beställning, attest samt leverans av kon-

torsmaterial och datorutrustning inom företaget. Med andra ord datorstyrda pro-

cesser som spar massor av tid.

Arkitektens uppgift är att analysera samt föreslå vilka processer som kan datori-

seras.

Arkitektens roll i det här sammanhanget är även att antingen vara beställare av

specialister från IT-avdelningen eller att skapa Workflows åt verksamheten eller

utbilda interna resurser i att skapa och underhålla Workflows. Alltså resurser

som har som uppgift att jobba med produktivitetshöjande åtgärder inom verk-

samheten på övre nivå inom företaget.

http://www.slideshare.net/derweeksglobal/sharepoint-survey-results-2011


18 av 21

Säkerhet

Behörigheter i SharePoint och/eller Active Directory (AD) Vid en SharePoint-implementation är användaridentiteten central eftersom behö-

righetskontrollen i SharePoint bygger på användaridentiteter i AD.

Via en kombination av gruppbehörigheter i AD samt gruppbehörigheter i Sha-

rePoint så kan man skapa en bra säkerhetsnivå i SharePoint.

Problemet är att SharePoint har en egen grupphantering som inte är den samma

som i Active Directory. En stor skillnad är att den vanlige användaren inte släpps

in i AD på grund av att all hantering i AD kräver hög kunskap i att jobba i en

server.

I SharePoint är denna behörighetsadministration öppen för användning om an-

vändare är ägare till en del av SharePoint. Man ingår i en «ägargrupp» som även brukar kallas för «Owner». På så sätt kan man med stor fördel dele-gera behörighetsadministration i SharePoint där den hör hemma till skillnad mot AD där servertekniker enbart får administrera exempelvis ändring av lösenord, vilket inte finns i SharePoint. Med ägare menar jag här enskilda «sajter» samt underliggande «sub-sajter» i den struktur av Site på Site som SharePoint är eller kommer att bli.

Behörigheten som jag här beskriver kallas även för «Tillgång till» via standard-

grupper som brukar ha namnen «”Sitenamn” Ägare», «”Sitenamn” Medlem» samt «”Sitenamn” Besökare». Dessutom finns möjligheten till anonym ac-cess som en fjärde möjlighet.

Det som sedan krånglar till det är att behörigheter kan ärvas ner i Site på Site strukturer. Vidare kan sådana arv brytas för Site-unika behörigheter och dessutom slås på igen om ägaren så anser.

Möjligheter att ge behörigheter på individnivå finns men jag avråder be-stämt att skapa sådan även om det är möjligt och enkelt att skapa.

Här gäller att arkitekten förstår och kan använda behörighetskontrollsy-stem förkortat BKS samt dessutom sätta upp ett regelverk samt skapa dokumentation och utbildningsmaterial i hur det ska fungera inom orga-nisationen samt inte minst förklara varför.

Backup-strategi Backup finns med all säkerhet inom alla organisationer. Frågan är om den före-

gås av ett genomarbetat strategiarbete och om denna strategi samt genomförande

även resulterar i en uppdaterad SLA (Service Level Agreement).

Restore-strategi (Återläsningsstrategi) Till skillnad mot Backup-strategin så är «Återläsningsstrategin» viktigare och

mer omfattande. Orsaken är att «Restore-processer» används ytterst sällan vilket

medför att kunskaper och erfarenheter urvattnas hos de som verkligen behärskar

«Restore» av information och dokumentation i SharePoint. Ofta räcker dessutom

SharePoints egna «Papperskorgar» för dagliga återläsningar beroende på misstag

från användarhåll.

Strategin bör därför resultera i ständigt uppdaterad dokumentation, möjligheter

för tester och träning för de som ska kunna återläsa SharePoint-baserad informat-

ion och dokumentation.


19 av 21

Disaster Recovery Vad händer när det värsta tänkbara inträffar. Brand eller annan händelse som ut-

plånar serverhallen? Kan företaget överhuvudtaget få tillbaka allt efter att olyck-

an varit framme? I övrigt gäller samma kartläggning, dokumentering samt trä-

ning och utbildning som för «vanlig» återläsning. Det krävs återkommande öv-

ningar som bör schemaläggas ett par gånger under året. En anledning är att be-

hovet av en full Recovery lyckligtvis sällan inträffar. Men när det väl inträffar så

gäller det att tillgång till sina specialister.

Här är kunskaper om «Riskanalyser» rätt bra att kunna för arkitekten.

Utbildning, eller medveten ”indoktrinering”

Inte bara handgrepp utan även hur och varför När enskilda för första gången börjar använda SharePoint så verkar det ganska

enkelt. Snabbt blir det dock avancerat vilket betyder att behoven av utbildning

kommer snabbt. En viktig del i sammanhanget är att förklara varför, samt i vilket

sammanhang som var och en ska jobba i och med SharePoint. I samband med en

sådan uppstart bör arkitekten ta initiativ till att sammanväga mål och strategier

med olika handgrepp i SharePoint.

Utbildningsmaterial – «User Guides» Arkitekten bör ta initiativ till olika utbildningsinsatser. Dels färdiga kurser ”ute

på stan” via utbildningsföretag men framför allt nyproduktion av interna «User

Guides» som väver samman hur SharePoint ska användas inom den egna organisationen.

För arkitektens del kan det handla om rollen som författare till ett antal dokument med pedagogisk prägling. Här är arkitekten kanske författare eller har en ledarroll i framtagningen av pedagogiska dokument.

Presentationer Arkitektens roll är ofta under genomförandeprojektet den som förklarar dels vad

SharePoint är men även syften, mål och delmål med utrullningen. Arkitekten är

ofta en skicklig presentatör där det gäller att på enkla pedagogiska sätt presentera

svaren på svåra frågor och komplexa sammanhang.

E-learning Vid implementationen av SharePoint så berörs så gott som alla inom organisat-

ionen mer eller mindre. Utbildningsbehovet är enormt så det gäller att ta tekni-

ken till hjälp för att alla ska ges en chans att utnyttja SharePoint på rätt sätt. Här

kommer hjälpmedel som «E-learning» som ett mer eller mindre självklart alter-

nativ.

Anskaffningen eller tillverkning av ett eget verktyg för «E-learning» är en lön-

sam investering när det gäller besparing och effektivitet, det har jag egen erfa-

renhet av. Kravet på verktyget är att det ska gå att använda vad som helst som

utbildningsmaterial, förutsatt att materialet som används är länkbart. Alltså ska

det gå att använda rena dokument skapade i en ordbehandlare som presentationer

typ PowerPoint. Andra underlag kan vara filmer eller rent av skapade samarbets-

platser i SharePoint. Det är viktigt att ni via verktyget kan följa hur utbildningen

förlöper så att det inte bara blir ett dokument distribuerat via E-post.


20 av 21

Förvaltning och support (Help Desk)

SharePoint-arkitekten ska säkerställa att SharePoint och ingående delar överläm-

nas till förvaltning och support efter att alla delmål nåtts.

Utbildningsaspekter Utöver Servertekniker som behöver träning i SharePoints «Central Administ-ration» så behöver Help Desk kontinuerlig utbildning i att ge support till användarna i att använda SharePoint samt framför allt lösa problem som användarna råkar ut för.

Ansvar och befogenheter Förvaltningsorganisationen av SharePoint medför att ett antal ansvar och befo-

genheter definieras och presenteras så att stödet och hanteringen av SharePoint

fungerar som det ska.

En viktig del är ansvar och befogenheter som har med behörigheter i SharePoint

att göra samt vem och vilka som ska hantera Backup och Restore samt Disaster

Recovery.

Verktygslådan Utöver «Central Administrator» i SharePoint så kan det vara en bra idé att an-

skaffa verktyg som brukar falla under kategorin «Tredjepartsprodukter». En grupp av sådana verktyg är exempelvis DocAve från företaget AvePoint.

Problem management Alla system medför problem för användarna, även SharePoint. Ofta finns redan

hjälpmedel för att hantera problem som rapporteras via Help Desk men det kan

finnas behov av att skapa speciella rutiner för SharePoint enbart. Det är relativt

enkelt att skapa ett hjälpmedel för Problem Management genom att etablera en

SharePoint-Site. Genom att utgå från Web Parten «Tasks» eller «Uppgifter» som

finns i exempelvis Site-mallen «Team Site» eller «Gruppwebbplats» så kan ett sådant verktyg skapas genom att först döpa om «Uppgifter» till «Pro-blem Management» samt därefter via Metadata och vyer skapa både in-matningsdelar som rapportdelar. Framför allt finns funktionen «Alert» eller «Avisera» där SharePoint sedan via E-post meddelar berörda vad som händer med problemlösningen.

Integration med andra system

SharePoint fungerar som ett fönster mot användarna när det gäller information

och dokumentation. Som intranät inom verksamheten så blir det snart intressant

att skapa dialoger och presentationer av data till och från omgivande system som

exempelvis personal och ekonomisystem.

Anledningen är att SharePoint först måste fungera Det tar tid bland användarna av SharePoint att bli varma i kläderna när det gäller

en rad områden som dessutom måste få ta sin tid. Implementerar man först dia-

logdelar mot omgivande system så vinner man inget annat än att exempelvis per-

sonalsystemen körs från en annan plats med ett nytt utseende och dialog. Visst

fungerar det och är egentligen inget stort problem. Om man istället lär organisat-

ionen i hur SharePoint fungerar så blir implementationen av inmatning och pre-

sentationer mer SharePoint-likt eftersom användarna förväntar sig det. Omvänt

blir dessa implementationer ingen större skillnad mot tidigare och i värsta fall


21 av 21

måste de implementerade dialogerna byggas om när organisationen väl lärt sig

hur SharePoint fungerar.

Konventionell system- och programutveckling Det är en klar fördel om samtliga processer på sikt körs via SharePoints gräns-

snitt. Det bör bli enklare att rulla ut sådana i organisationen eftersom handgrep-

pen redan finns i fingrarna på användarna.

I det här läget jobbar SharePoint-arkitekten som en kravställare på design och di-

alog samt hur resultat av slagningar sker samt presenteras.

sharepoint-arkitekt · olika ut från individ till individ. sharepoint-arkitektens erfarenhet och...

Documents