Office365 Lessons Learned: Office365 is niet je complete applicatielandschap

Op de laatste saMBO-ICT Conferentie gaf ik een presentatie met de titel “Office365 – Lessons Learned”. De hele presentatie is hier terug te vinden. Ik wil de afzonderlijke punten echter wel verder toelichten, aan de hand van de keus die we maakten, de reacties en gevolgen en hoe het verder moet.

  • Toelichting: Office365 is slechts één van de kernsystemen. Waarschijnlijk heb je nog kernsystemen voor financiën, HR, studentzaken en facility etc. Deze maken soms Office bestanden aan die je in de cloud wilt opslaan. Andersom kan ook, dat Office ‘bijlagen’ in andere systemen gehangen moeten worden.
    Zonder lokale synchronisatie als tussenstation kun je dit niet rechtstreeks doen. Dus van de ene cloud (Office365) naar de andere (SAAS systemen).
  • Keus:
    Als je met Office werkt dan sla je bestanden op in een daarvoor aangewezen teamsite. Formele processen lopen in andere kernsystemen.
  • Hoe: Als er geen synchronisatie is, zul je bestanden moeten Down/Uploaden naar een tijdelijke tussenplek. Of je opent de bibliotheek in de teamsite middels de knop “Openen in Explorer”, wat de Verkenner is. Deze dien je op je PC te favorizeren zodat de Verkenner dit plekje van je cloud ziet.
  • Reactie: “Ik krijg de hele tijd foutmeldingen.” Zie vorig bericht over instabiel WebDav.
  • Gevolg: Frustratie en omslachtig downloaden/uploaden als men een bestandje wil bewerken. Twee plekken bevatten het ‘origineel’: de site en het kernsysteem.
  • Hoe verder: Integratie aan leveranciers vragen? Of wel aan de slag gaan met lokale synchronisatie?

Daarnaast speelt er vaak nog een breder vraagstuk over de samenhang met de rest van je applicatielandschap. SharePoint als platform kan alles en niets tegelijk. In principe zou je vrijwel alle functionaliteit van andere systemen kunnen ‘bouwen’ met lijsten, content-types, (centrale) metadata en workflows. Maar dat het kan als je er (veel) tijd in steekt wil niet zeggen dat het handig is. Waar je deze grens legt is elke keer weer opnieuw een afweging. Een paar voorbeelden:

  • In ons HR systeem zit een self-service module voor het indienen van reisdeclaraties. Dit doen we niet in Sharepoint omdat de rest van de benodigde informatie in het HR systeem beter gewaarborgd is. De medewerker-kenmerken, het afwikkelen van de declaratie met instemming van je leidinggevende en de daadwerkelijke toekenning via je salaris etc, zijn daar ‘ingebakken’, na enige inrichting natuurlijk. Dit gaan we in Sharepoint niet met workflows nabouwen.
  • Voor cijfers en AAR vragen scholen toegang tot de informatie voor ouders. Voor minderjarigen is dit een valide functionaliteitsbehoefte. In ons studentensysteem zitten deze gegevens al (ouder-kenmerken, resultaten en AAR observaties). Daarom gaan we voor deze toegang niet nog een keer allerlei externe accounts beheren en handmatig toegang geven tot informatie op SharePoint.

Daarom is ons standpunt in het algemeen dat we voor workflows zoveel mogelijk de aangewezen kernsystemen gebruiken en niet alle workflows van de organisatie verplaatsen naar Office365. Overigens blijven er dan nog steeds zat leuke use-cases over voor workflows in Office365.

 

Geef een reactie

Vul je gegevens in of klik op een icoon om in te loggen.

WordPress.com logo

Je reageert onder je WordPress.com account. Log uit / Bijwerken )

Twitter-afbeelding

Je reageert onder je Twitter account. Log uit / Bijwerken )

Facebook foto

Je reageert onder je Facebook account. Log uit / Bijwerken )

Google+ photo

Je reageert onder je Google+ account. Log uit / Bijwerken )

Verbinden met %s