Microsoft Dynamics NAV en SharePoint: de integratie mogelijkheden Veel gebruikers van Microsoft Dynamics NAV (voorheen: Navision) geven aan hun informatievoorziening te willen verbeteren. Na de invoering van het ERP pakket als basis horen we vaak de volgende vragen: hoe kunnen we eenvoudiger samenwerken en informatie delen met klanten en leveranciers, hoe kunnen we ongestructureerde informatie beter beheren en hoe kunnen we onze medewerkers productiever laten worden? SharePoint oplossingen kunnen hierbij een belangrijke bijdrage leveren. Op het gebied van applicatie integratie noemen we de volgende argumenten: 1. Samenwerking bevorderen en informatie delen Een belangrijke beweegreden om met het SharePoint platform te werken is de interne samenwerking te bevorderen en informatievoorziening te verbeteren. Portalen bieden veel standaard functionaliteit voor afdelings- of projectwerken. In essentie gaat het erom wat ermee bereikt kan worden. Het grootste voordeel is dat men er tijd- en plaats onafhankelijk mee kan werken. Bovendien werkt dit ook op verschillende soorten devices, zoals tablets. Dit kan niet standaard met Dynamics NAV of andere bestaande backoffice applicaties. 2. Toegang tot verschillende applicaties Een SharePoint portaal biedt de mogelijkheid om via één consistente gebruikersinterface toegang te geven tot verschillende backoffice applicaties. Hierbij kan het onderscheid worden gemaakt tussen heavy users en light users. Een heavy user is bijvoorbeeld iemand die in een financieel pakket de boekhouding doet en daarbij de volledige functionaliteit nodig heeft. Dit type gebruiker werkt over het algemeen niet via een portaal om gegevens in te zien of te bewerken. Een light user is iemand die af en toe wat informatie nodig heeft uit dit financieel pakket om de juiste beslissing te kunnen nemen of informatie te verschaffen. Voor dit type toepassing is een portaal uitermate geschikt. Externe gebruikers zijn in principe altijd lichte gebruikers. Het is functioneel en qua beveiliging niet wenselijk dat zij rechtstreeks in het ERP systeem werken. Samenvattend kun je dus tijd- en plaats onafhankelijk werken, waarbij lichte gebruikers ook informatie aangereikt krijgen uit achterliggende applicaties. Daarnaast biedt het SharePoint platform ook heel nadrukkelijk document management functionaliteiten. Het is mogelijk om alle papieren documenten zoals dossiers, contracten en facturen te digitaliseren met behulp van aparte digitaliseringsoftware. De documenten komen automatisch op de juiste plek in SharePoint terecht. Op een heel efficiënte manier kunnen mensen vervolgens gezamenlijk aan documenten werken. In het algemeen worden
portalen vaak gecombineerd met document management functionaliteiten, zodat men op verschillende locaties, afdelingen of projecten makkelijker toegang heeft tot informatie. Deze combinatie van gestructureerde informatie (uit back office applicaties) en ongestructureerde informatie (Word documenten, PDF s, e-mails, etc.) kan gerealiseerd worden middels een Enterprise Informatie Portaal. Zoals uit bovenstaande blijkt, is een dergelijke oplossing niet alleen een Portal vraagstuk maar gaat het ook om het integreren van achterliggende applicaties. Op dit gebied heeft Thysia gemerkt dat er de nodige vragen leven in de praktijk. Wat zijn de mogelijkheden om met SharePoint te koppelen naar Dynamics NAV? Welke beperkingen zijn er? Hoe pak je een dergelijk project aan? In dit document worden praktijktips gegeven over de mogelijkheden en beperkingen van applicatie integratie met SharePoint. Vervolgens wordt er uitleg gegeven over de aanpak en met welke stappen dit te realiseren is.
Mogelijkheden/beperkingen van applicatie integratie met SharePoint In algemene zin is SharePoint een informatieplatform. Bovendien is het volledig gebaseerd op standaard Microsoft technologie en zijn de integratiemogelijkheden zeer uitgebreid. Voor de gebruiker wordt deze integratie vaak getoond in een WebPart, ofwel een web onderdeel, op SharePoint. Web onderdelen zorgen dat er voor de gebruiker een eenvoudige en consistente gebruikersinterface ontstaat. Hiermee kan dus ook informatie uit andere bronnen getoond worden. Als er meerdere achterliggende systemen zijn, dan zien de web onderdelen er voor de gebruiker er in basis hetzelfde uit en je beseft daardoor ook niet dat je informatie bekijkt, die elders vandaan komt. De vraag is echter hoe je er voor kunt zorgen dat die informatie uit een ander pakket getoond kan worden in het WebPart. En dat wordt voor het overgrote deel bepaald door de mogelijkheden van de achterliggende applicatie(s). Maar voordat we nader gaan inzoomen op die vraag, is er nog een belangrijk vraagstuk dat we eerst dienen te adresseren. En dat heeft te maken met de algemene strategie m.b.t. het informatie management. Binnen veel organisaties zien we dat er in het verleden vele applicaties aangeschaft zijn. Vrijwel elke organisatie heeft meerdere pakketten in gebruik en dat is logisch omdat er geen systemen zijn die in alle informatiebehoeften kunnen voorzien. Maar een deel is ook ontstaan uit minder bewuste keuzes in het verleden of vanwege fusies. In dat geval zien we vanuit informatie management vaak het beleid ontstaan dat er geconsolideerd moet worden en dat er applicaties uit gefaseerd zullen worden. SharePoint kan hier ook een rol in spelen. Vaak zien we dat er applicaties in gebruik zijn, waarvan de functionaliteit eenvoudig geboden kan worden op basis van SharePoint. Voorbeelden zijn Kwaliteitshandboeken en het doen van meldingen/aanvragen. Dit wil overigens niet zeggen dat het aan te raden is, om allerlei applicaties in SharePoint te gaan bouwen Maar sluit de functionaliteit goed aan bij (standaard) SharePoint, dan kan op deze wijze het aantal applicaties teruggebracht worden. Met applicaties die gaan verdwijnen hoeft niet gekoppeld te worden. Vervolgens stelt men zich de vraag welk applicatielandschap er overblijft en hoe men daar mee wil integreren. In grote lijn zien we daarin 2 varianten: 1. Enterprise Service Bus (ESB) Een ESB is een architecturele softwareconstructie waarmee de communicatie tussen aanbieders van diensten ( service ) en afnemers hiervan vereenvoudigd wordt. DE ESB biedt hiertoe aan de kant van de aanvrager een met de aanvrager afgesproken interface aan, dit kan b.v. een webservice zijn. Aan de kant van de aanbieder zal de ESB via de interface die met de aanbieder is afgesproken communiceren. In het bovenstaande plaatje van het EIM portaal komt er daarom een extra component tussen de achterliggende applicatie en SharePoint. Deze ESB communiceert met SharePoint dus altijd op dezelfde wijze, waarbij de integratie met achterliggende systemen specifiek ingevuld kan worden. De ESB zorgt voor de vertaalslag. Dit leidt tot standaardisatie en vereenvoudiging van de koppelingen.
Binnen het Microsoft portfolio wordt Microsoft Biztalk Server ingezet voor de implementatie van een ESB architectuur. 2. Specifieke Integraties Uiteraard brengt het ontwerpen en implementeren van een ESB oplossing ook tijd en kosten met zich mee. Deze zijn aanzienlijk en in de praktijk zien we ook dat het beheren van een dergelijke oplossing specialistisch werk is. ESB oplossingen zijn dan ook vooral geschikt voor grotere, complexe omgevingen waarbij ook in de toekomst een grote diversiteit te verwachten is aan applicaties en koppelingen. In de meeste gevallen zien we daarom dat de vraag gaat over het realiseren van één of meerdere specifieke integraties. In het vervolg van dit document gaan we hier nader op in. Als we het hebben over specifieke integraties met SharePoint, dan is er goed nieuws. SharePoint neemt wereldwijd een leidende positie in op het vakgebied Enterprise Content Management (ECM) en de toepassing van het platform groeit sterk. Recente cijfers van AIIM (leidend onafhankelijk kennisinstituut voor ECM) tonen aan dat het aantal organisaties dat SharePoint gebruikt vorig jaar met 28% gestegen is. Dit betekent dat het platform niet meer te negeren is voor bedrijven die software ontwikkelen. Steeds meer software leveranciers bieden standaard mogelijkheden om hun applicatie te integreren met SharePoint. Het verdient dan ook aanbeveling om in een specifieke situatie eerst te onderzoeken of dit het geval is. Als de leverancier nu nog niets heeft, kan het zijn dat men iets aan het ontwikkelen is. Microsoft zelf timmert op dit vlak ook hard aan de weg. Zo zijn er vanuit Microsoft Dynamics NAV 2013 standaard mogelijkheden voor integratie met SharePoint. Voor Microsoft Dynamics CRM en AX was dat al eerder het geval. Ook bij deze standaard integraties is het echter zaak om vanuit functionele wensen en eisen te blijven redeneren. Niet alle scenario s worden ondersteund. In het algemeen kunnen we stellen dat het belangrijk is om te onderzoeken of (en hoe) er ook informatie naar het pakket weggeschreven kan worden. Het bieden van leesmogelijkheden is immers relatief eenvoudig. Bijna elk pakket heeft tegenwoordig wel een (relationele) database waar informatie uit te halen is. Maar kunnen er ook transacties aangemaakt/gewijzigd worden vanuit SharePoint? En hoe wordt op dat moment omgegaan met de business logica (denk aan zaken als controles, berekeningen en foutmeldingen). En hoe wordt omgegaan met gebruikersbeheer en rechten? Denk hierbij ook aan scenario s waarbij er externe gebruikers zijn. Verder is een belangrijke vraag hoe configureerbaar de oplossing is. Met andere woorden, kun je door middel van inrichting de koppeling realiseren, of moet er (steeds opnieuw) geprogrammeerd worden? In de situatie dat er geen standaard integratie is of de mogelijkheden niet toereikend zijn, dan zijn er globaal de volgende mogelijkheden om te integreren met SharePoint: 1. Een connector In aanvulling op wat de software leverancier te bieden heeft, zijn er ook derde partijen die producten leveren op het gebied van applicatie integratie. Een voorbeeld hiervan is IT IS AG (Duitsland) die een connector levert voor de koppeling
tussen Dynamics NAV en SharePoint. Hiermee kunnen op generieke wijze integraties gerealiseerd worden. De business logica wordt volledig aangesproken en de integratie is real-time en volledig configureerbaar. De informatie wordt in SharePoint getoond in een Web Part. Bij de selectie en beoordeling van dergelijke connectoren, gelden dus in basis dezelfde vragen als genoemd onder de standaard integraties. En uiteraard speelt altijd de vraag of de aanschaf van de oplossing zich terugverdient in lagere kosten van implementatie en beheer van de koppelingen. 2. Iframe Als weinig/geen standaard mogelijkheden en connectoren voorhanden zijn, dan is het nog steeds de vraag of er iets ontwikkeld moet worden. Ook dit hangt af van de gewenste functionaliteit. Veel applicaties bieden inmiddels de mogelijkheid om via het web benaderd te worden. Er kan dan vaak ook via een zogenaamd Iframe informatie getoond of bewerkt worden. Dit is een soort zwevend venster voor de achterliggende applicatie. Voor de gebruiker is dit een andere ervaring dan een web part, hij werkt daadwerkelijk in een andere applicatie. Voor bepaalde toepassingen kan dit echter een prima (tussentijdse) oplossing zijn. Vraag/aandachtspunt is wel of er gewerkt kan worden met single sign on ofwel éénmalig inloggen. SharePoint ondersteunt dit standaard, maar de achterliggende applicatie dient er uiteraard ook mee om te kunnen gaan. 3. Specifieke koppeling Als derde mogelijkheid noemen we het ontwikkelen van een specifieke koppeling. Dit kan vanuit SharePoint onder andere vanuit de Business Connectivity Services. Met dit onderdeel van SharePoint (voorheen heette het Business Data Catalogue) kunnen externe gegevens binnengehaald worden, compleet met lees- en schrijfmogelijkheden. Een andere mogelijkheid is om via een specifiek ontwikkeld WebPart de informatie op te halen. Vaak wordt er hierbij gebruik gemaakt van het aanspreken van zogenaamde web services. Dus als een systeemleverancier geen standaard integratie heeft dan is het de vraag of men wel web services ondersteunt. Dit is steeds vaker het geval, waardoor op dit gebied ook meer met standaard technieken gewerkt kan worden. Eerder genoemde vragen over gebruikersbeheer en business logica gelden uiteraard ook hier. Dynamics NAV ondersteunt web services standaard vanaf de versie NAV 2009 R2. Op basis van onze ruime ervaring met het integreren van Dynamics NAV en SharePoint is een iframe de minst voor de hand liggende optie. Er zijn immers betere alternatieven voorhanden. Een specifieke koppeling is een goede optie voor eenvoudige scenario s. Bijvoorbeeld het tonen van klantengegevens. Voor een complete portal oplossing waarbij ook data ingegeven moet worden is dit veelal een dure en inflexibele optie. Vandaar dat Thysia in de praktijk in die gevallen adviseert om een connector in te zetten en in het verleden het product IT IS Active heeft geselecteerd. Het generieke en configureerbare aspect is reeds genoemd. Daarnaast is de oplossing beschikbaar vanaf Dynamics NAV versie 3.7. Het grootste gedeelte van de Dynamics gebruikers werkt immers niet op de allernieuwste versie. En dat zal ook nog een tijd zo blijven, omdat een upgrade vaak een kostbare migratie is vanwege toegepast maatwerk in het ERP systeem.
In de communicatie laag kan standaard gewerkt worden met web services (uiteraard vanaf NAV 2009 R2). De oplossing is veilig en schaalbaar naar grote aantallen gebruikers/transacties. Voor de gebruikers van NAV 2013 en partners die hun ERP oplossingen aan het upgraden zijn, is het een belangrijke vraag wat de mogelijkheden en beperkingen zijn van de standaard SharePoint client in NAV 2013 ten opzichte van IT IS Active. In de volgende paragraaf gaan we specifiek in op deze vergelijking. SharePoint client in NAV 2013 en IT IS Active In het algemene adviseren wij altijd om standaard Microsoft oplossingen te gebruiken waar mogelijk en alleen add-ons in te zetten wanneer dat toegevoegde waarde heeft. De vraag is dus wat de mogelijkheden zijn van de standaard SharePoint client in NAV en waar de begrenzingen liggen. Hierna behandelen we de belangrijkste aspecten. Om het overzichtelijk te houden, bepreken we ons tot de hoofdlijnen. 1. De Web Client, Web Pages De SharePoint client biedt de mogelijkheid om een Dynamics NAV pagina te publiceren als een web pagina. Dit gebeurt 1 op 1, dus alle velden en functies die beschikbaar zijn in NAV zijn daarmee ook direct beschikbaar op SharePoint. Het voordeel hiervan is dat dit generiek en snel werkt en dat de business logica van NAV ook volledig gebruikt wordt. Een nadeel is dat de schermen in NAV veelal rijk aan functionaliteit zijn en bedoeld voor de zwaardere ERP gebruiker. Hierdoor zijn ze vaak minder geschikt voor de lichtere gebruiker die via een portaal werkt. Het is mogelijk hier specifieke pages voor te maken en die als web page te publiceren. Dat is echter (dubbel) werk en het is ook geen configuratie. Verder is de web page niet hetzelfde als een web part. De gebruikerservaring is prima, maar de kanttekening is dat het is alsof je door een venster naar NAV kijkt. 2. Overige SharePoint integratiepunten De web page biedt de functionaliteit om NAV functionaliteit beschikbaar te stellen. Bij portal oplossingen is het echter ook vaak gewenst om te integreren met SharePoint lijsten of documenten bibliotheken. Of om in één web part ook data of functionaliteit uit een andere applicatie te tonen. Bijvoorbeeld een klantenlijst met een combinatie van gegevens uit NAV en CRM. Deze mogelijkheden zijn niet standaard aanwezig in de nieuwe web client. Ook directe support voor touch is niet voorhanden, wat de toepassing op tablets en mobile devices beperkt. 3. Gebruikers en rechten Het gebruikersmodel en het rechten systeem berusten op de NAV client. Dit betekent ook dat de gebruikers in een Active Directory omgeving ondergebracht dienen te zijn. Forms Based Authentication (FBA) wordt (nog) niet standaard ondersteund. Dit is geen bezwaar als het gaat om interne gebruikers die ook via een portal werken. Het is echter een belangrijke beperking als er vele rollen zijn en/of externe gebruikers. Verder is het de vraag is of de oplossing by design geschikt is voor grote aantallen gebruikers en hoe cloud enablement het beste in de praktijk gebracht kan worden.
4. Licenties Dit whitepaper is niet bedoeld om alle licentieaspecten volledig te behandelen Echter is er met NAV 2013 een belangrijke verandering die impact heeft op NAV licenties voor portals. Bij alle voorgaande versies van NAV was het nodig om een externe connector te licenseren om externe gebruikers toegang te bieden. De definitie van extern is niet op de loonlijst, dus geldt ook voor uitzendkrachten, freelancers, etc.. Met de connector kon (per database) een onbeperkt aantal externe gebruikers gelicenseerd worden voor toegang tot informatie uit NAV. In NAV 2013 is deze connector niet meer beschikbaar. In de plaats daarvan is er een externe gebruiker beschikbaar. Deze is gratis, maar dat geldt alleen voor klanten. Leveranciers en andere externe gebruikers moeten via een reguliere (concurrent) licentie werken. Er is ook een beperktere gebruikerslicentie mogelijk, maar die geeft slechts schrijfrechten op 4 tabellen. In scenario s met veel gebruikers en/of veel functionaliteit kunnen de licentiekosten van een portal scenario op NAV 2013 dus sterk oplopen. IT IS Active wordt gelicenseerd per connectie. De applicatie kan gelijktijdig gebruikt worden voor vele gebruikers, maar de vuistregel is 10-25 concurrent users per connectie. Het aantal hangt af van het aantal en type transacties. Dus hoe meer gebruikers/transacties er zijn, hoe meer connecties en hoe duurder het wordt. Je kunt echter klein beginnen en opschalen. Bovendien kan exact worden bijgehouden hoeveel (gelijktijdige) sessies er gebruikt worden via SharePoint. Op basis van bovenstaande aspecten kunnen we concluderen dat de SharePoint client in NAV 2013 een nieuwe mogelijkheid biedt om vanuit SharePoint eenvoudig toegang te krijgen tot informatie en functionaliteit in NAV. De oplossing is vooral geschikt voor interne gebruikers en relatief eenvoudige portal scenario s. IT IS Active biedt toegevoegde waarde voor additionele functionaliteiten, externe gebruikers en schaalbaarheid. Uiteraard is bovenstaande informatie gebaseerd op de huidige stand van zaken. De verwachting is dat Microsoft in toekomstige releases additionele functionaliteit gaat bieden. Dat geldt echter ook voor leveranciers van connectoren, zoals IT IS. Een nieuwe grote release van NAV zal nog enige tijd duren (want deze is net uit) dus de mening van Thysia is dat de bovenstaande grote lijnen de komende jaren blijven gelden. Tot nu toe hebben we een overzicht gegeven van de basiskeuzes t.a.v. de architectuur en de soorten integraties die er bestaan. In het vervolg van dit document geven we enkele belangrijke tips om een dergelijk project succesvol aan te pakken.
Aanpak van succesvol integreren met SharePoint Groot denken, klein beginnen Enerzijds moet je als organisatie goed bepalen waar je over 1,5 tot 2 jaar wil staan. Anderzijds moet je klein en praktisch beginnen met projecten die snel succesvol zijn. Op deze manier creëer je automatisch draagvlak binnen de organisatie. Vanuit IT management bepaal je dus je strategie en plan voor de toekomst, en maak je dit plan gereed voor kleinere stappen. Het is van belang een gezonde mix te zoeken tussen het inzetten van een platform voor de lange termijn, en anderzijds het realiseren van kleine projecten op korte termijn en daarmee voortgang boeken. De vraag is natuurlijk: wat is een klein project?. Integratie is meestal geen klein project. Zelfs met gebruikmaking van een standaard koppeling of connector is het al snel een paar weken werk om (meerdere functionaliteiten van) een achterliggend systeem beschikbaar te stellen. Vooral als er ook informatie aangemaakt of bewerkt moet worden. Maar klein beginnen kan ook betekenen dat er eerst een Proof Of Concept gerealiseerd wordt met een werkend voorbeeld van de beoogde integratie. Dit kan vaak op logische wijze gecombineerd worden met een basis implementatie van standaard functionaliteit. Denk b.v. aan een teamsite voor een afdeling met daarop documentenbeheer een gezamenlijke kalender. Hierdoor raakt men ook beter bekend met het SharePoint platform. SharePoint is immers geen punt oplossing maar een platform met uitgebreide mogelijkheden op vele vlakken. Draagvlak creëren Het is dan ook verstandig om eerst draagvlak te creëren voor het platform. IT Management kan op meerdere manieren draagvlak creëren. De inrichting van een projectensite kan binnen enkele dagen gerealiseerd worden. Als medewerkers merken dat deze andere manier van werken veel efficiënter is, gaan ze zich ook afvragen of het platform ook voor andere doeleinden ingezet kan worden. Op deze manier groeien de vraagstukken en creëer je dus meer draagvlak. Aansluiting op werkprocessen Het werk en de passie van medewerkers ligt bij hun primaire taak (b.v. verkoop of technische dienst), en niet bij het werken met complexe IT toepassingen. Hierdoor moet er vanaf het begin gekeken worden naar hoe de werkwijze voor gebruikers zo eenvoudig mogelijk gemaakt kan worden, wat ze nodig hebben en wat ze willen. Een portaal kan hierin sterk ondersteunend zijn, maar moet zodanig gemaakt worden dat het gebruik eenvoudig is.
Thysia Information Management Thysia Information Management is expert op het gebied van SharePoint en informatiemanagement. De oplossingen van Thysia helpen organisaties eenvoudiger samenwerken en informatie delen. Specialisaties zijn SharePoint portals en document & workflow management oplossingen die naadloos geïntegreerd zijn met backoffice systemen zoals Microsoft Dynamics NAV. Thysia Information Management Haagsemarkt 1 4813 BA Breda Nederland Tel: +31 (0)76 521 88 46 Fax: +31 (0)76 521 16 84 www.thysia.eu info@thysia.eu 2013, Thysia Information Management Nothing from this document may be multiplied and/or copied by means of printing, photocopy, microfilm or by any other means without prior written approval of Thysia Information Management.