Med SharePoint 2010 i arkitekturen står flere og flere av våre kunder ovenfor valget om hva de skal bruke SharePoint til og hva skal de ikke bruke det til.  Mantraet om at SharePoint er en plattform og ikke ferdig ut av boksen hører vi alle. For mange kan SharePoint blant annet være dokumentsystemet, betjene dokumentsentrisk samhandling og være informasjonskanalen i bedriften, men det kan også være arbeidsflaten, rapporteringsløsningen og kvalitetssystemet.

Jeg har ikke vært borti en organisasjon som ikke har dublerende funksjonalitet til mulige SharePoint-roller i andre systemer, og både fagkunnskap og systemkompetanse trengs for å velge rett arena til den enkelte oppgave.

Har vi leverandører av tjenester tatt dette inn over oss? Fremdeles ser man stillingsannonser og kurs for SharePoint-konsulenter og flinke (og for tiden svært etterspurte) fagfolk omtales som SharePoint-konsulenter.  Jeg tror tiden er inne for å hente inspirasjon fra ERP-verden, og akseptere at som plattform trenger SharePoint to hovedgrupper mennesker i leverandørindustrien: de som jobber under plattformen og de som jobber på den.

De som jobber under plattformen

La oss begynne med de som jobber under den. Fra ERP-verden kjenner vi to grupper her: de som setter opp miljøet klart for konfigurasjon, og de som lager det verktøyet ikke fikser.  En gammel SAP-konsulent vil si Basis og ABAP.  Disse installerer, bygger miljø sammen med driftsorganisasjon, ordner avanserte koblinger med kataloger og ting som en konfigurator ikke har bakgrunn for å fikse.  Her regner jeg også med utvikleren med .Net-kompetanse som koder løsninger som ikke er tilgjengelige “ut av boksen” eller som en plugin fra en tredjepart.

Grunnen til at jeg omtaler disse sammen er at dette i mange mindre prosjekter er samme person, selv om det nok er to forskjellige roller. Felles for disse er at disse har en IT-faglig bakgrunn og trygt kan klassifiseres som IT-folk. Blant IT-folk har vi selvfølgelig undergrupper igjen, se blant annet denne bra bloggposten om forskjellene mellom scientist, programmer og developer.

De som jobber på plattformen

Så er det de som jobber på plattformen.  Her er det største gapet i dag på SharePoint.  Tar vi inn over oss at dette er en plattform – som må konfigureres og tilpasses for å støtte prosesser og forretningsbehov – så må vi slutte å betrakte dette som en jobb for en utvikler.  Dette er, som i ERP verden, en jobb for folk med god forretnings- og prosessforståelse. Deres hovedverktøy er SharePoint Designer.

Når plattformen først er valgt skal de søke løsninger innenfor mulighetsbildet på plattformen – og heller undersøke muligheten for å møte forretningsbehov på andre måter eller anvende andre verktøy, enn å begynne å programmere.

Ser vi til ERP-verden ville en for eksempel aldri benyttet en ekspert på SAP lønn til å konfigurere logistikkdelene av verktøyet. Dette er ikke fordi grensesnitt og verktøykasse er så annerledes, men fordi en tror at den faglige ekspertise som trengs for å ta gode konfigurasjonsvalg er så forskjellig.  Det er også stor forskjell på kopmetansen som trengs for å vedlikeholde og bygge god metadatahåndtering som støtter dine søk og dokumenthåndteringsbehov, etablere god praksis på workflowkonfigurasjon / navnestandard eller å gjøre “skinning” – altså farger, logoer og interaksjonsprinsipper.

Hvilken kompetanse bør man ha?

I BEKK snakker vi ofte om at de gode resultatene er preget av at vi spiller hverandre god.  Vi prøver å være tydelige på at selv om en utvikler eller prosesskonsulent kan ha meninger om lesbarhet så bør typografien utvikles av en med designkompetanse.

Vi mener at funksjonell design – altså hvordan løsningene faktisk skal fungere i interaksjon med brukerne – ikke bør bestemmes av en utvikler som er god å programmere.  SharePoint-konsulenten – slik stort sett hele bransjen omtaler vedkommende – kan ende opp med en rolle hvor vedkommende er “jack of all trades – master of none”

Skulle vi hatt spesialiserte SharePoint-konsulenter?  Kanskje noen av de er spesialister på andre fag, men kan omsette faget på blant annet SharePoint?  Og kunne en slik ERP-inspirert rollefordeling avhjulpet mangelen på SharePoint-konsulenter? Hva er dine forslag?