Theo Besselink

Project Visma succesvol afgesloten

by

Eind juni 2021 heb ik een interessante opdracht bij Visma Idella succesvol afgesloten.
Doel was om documenten die via een Azure Portaal worden geüploaded naar Dynamics, automatisch te
laten herkennen en indien de herkenning niet akkoord was, via een Canvas oplossing die
geïntegreerd is met Dynamics het door de gebruiker visueel te laten beoordelen. Wat voorheen een 100 % handmatige oplossing was, is nu volledig geautomatiseerd en zo worden meer dan 85% van de geüploade documenten zoals pdf’s, jpg’s en png’s etc. automatisch verwerkt zonder ingreep van de medewerkers. Dit geeft een enorme besparing en verwerking wordt in seconden volledig verwerkt. Hierbij praat je over images van bankpassen, salarisspecificaties, UWV
documenten, etc.

Basis is de Cognitieve Services van Microsoft waarin documenten zogenaamd machine getraind
worden zodat het systeem documenten herkend en via labels op het document informatie van de
geüploade documenten haalt. In die services zit ook functionaliteit zoals gezichtsherkenning en
object herkenning. Op de achtergrond wordt met diverse Azure oplossingen gewerkt zoals Power Apps, Dynamics CRM, Power Automate, Logic Apps, Storage accounts en andere resources in Microsoft Azure. Het is
ongekend wat de mogelijkheden zijn van dit platform en verassend welke oplossingen mogelijk zijn
met behulp van JSON, Javascript, Azure functions en Power Platform functionaliteit.

Het was een zeer leerzaam project en fijn gevoel dat het project de OTAP straat prima heeft
doorlopen en momenteel in Productie is.
Op naar de volgende opdracht en uitdaging waar ik medio augustus aan ga beginnen.

Oplossing “Letselschade”

by

Op de valreep van 2020 heb ik nog een oplossing opgeleverd binnen Dynamics CE voor urenregistratie van declarabele uren die verrekend kunnen worden bij de verwerking van letselschade en wel voor de MTL Groep in Nijmegen.
Het is een prima oplossing voor organisaties die zich bezighouden met afhandelen van schade gevallen en om de verrichte werkzaamheden kunnen doorberekenen aan hun klanten of de verzekeringsmaatschappijen waarbij de klant verzekerd is, maar kan ook prima ingezet worden voor dienstverleners die hun werkzaamheden doorberekenen aan hun klanten.
Het is een ideale oplossing voor bedrijven die met Office 365 werken.

Uitgangspunt was om een gebruikersvriendelijke oplossing binnen Dynamics CE te bouwen om de declarabele werkzaamheden te beheren, de geregistreerde uren klaar te zetten voor export naar een boekhoudsysteem en het management inzicht te geven in de voortgang van de afhandeling.
De export van de gewerkte uren wordt voorlopig handmatig gedaan aan de hand van Excel bestanden, maar zodra de Applicatie gewend geraakt is, zal er via een API services een directe koppeling gemaakt worden met het boekhoudsysteem.

Gepubliceerde artikelen in de huidige reeks:

Omgeving Power Platform

Als basis hebben we een volledig nieuwe model gestuurde App gebruikt, maar dat had ook prima Dynamics Sales kunnen zijn. In de basis volstaan de tabellen Accounts en Contactpersonen, plus gerelateerde tabellen, en zijn daar nieuwe tabellen aan toegevoegd.
Binnen de Office 365 wordt naast de Office applicaties o.a. gebruik gemaakt van Dynamics 365, Power Apps, Power Automate en SharePoint.
Zoals Microsoft adviseert is de oplossing binnen Power Platform gebouwd (Unified Interface), al heb ik nog wel wat Javascript en in C#.net geschreven plug-ins toegevoegd.

Werkzaamheden registreren

De gebruiker maakt eerst binnen Accounts een verzekeringsmaatschappij aan, tenminste als die nog niet aangemaakt is. Vervolgens wordt binnen Contactpersonen een nieuwe Client aangemaakt als die nog niet bestaat.
In een nieuwe tabel “Kwesties” (cases) worden vooraf zoveel mogelijk beschrijvingen van werkzaamheden geformuleerd, zodat uiteindelijk een gestructureerde oplossing ontstaat waarbij de omschrijving van de werkzaamheden afgedwongen wordt.

De gebruiker zal een nieuw dossier aanmaken. Per cliënt kunnen er meerdere dossiers geopend worden. Een plug-in zal een dossiernummer genereren indien het een nieuw dossier is of de gebruiker neemt een bestaand nummer op. Het dossier is essentieel omdat het niet alleen voor de voortgang en urenregistratie gebruikt wordt, maar ook de basis is voor het documentbeheer binnen de SharePoint omgeving.

Zodra de gebruiker de werkzaamheden start om aan het dossier te gaan werken, zal de gebruiker eerst een dossier openen en vervolgens op de menuoptie “Gerelateerd” klikken

De gebruiker selecteert een kwestie, vult eventueel bij aanduiding nog wat extra info in voor de naam, selecteert tijdstip van starten en tijdstip einde werkzaamheden.
In dit geval vult de gebruiker start en eindtijdstip tegelijkertijd in, maar het is natuurlijk ook mogelijk om eerst tijdstip starten aan te maken en nadat de werkzaamheden afgerond zijn, pas het eindtijdstip in te vullen.
De gebruiker drukt op opslaan en dat zijn alle handelingen die van de gebruiker verwacht worden.
Het systeem heeft berekend dat de eigenaar 1 uur en 15 minuten (1,25 uren) aan het dossier heeft gewerkt. Er is automatisch een naam aangemaakt en de Status Facturatie is op “Concept” gezet.

Gaan we terug naar het dossier dan zijn de werkzaamheden door een plug-in gecumuleerd op dossierniveau. Na de eerste registratie zijn er 1,25 uren (1 uur en 15 min) gewerkt, wat overeenkomt met de gewerkte uren/minuten in concept.

In het voorbeeld ga ik nog wat extra werkzaamheden boeken om vervolgens het managen van de uren te laten zien.

Managen van de uren en exporteren

Ik laat alleen de hoofdzaken zien, dus laat de details even achterwege.
Er zijn meerdere Dashboards aangemaakt en legio Views om de voortgang vanuit meerdere perspectieven te kunnen zien, waaronder overzicht van werkzaamheden die nog geen eindtijd hebben. Die moeten eerst afgerond worden voordat er gefactureerd kan worden.

De manager bekijkt de gewerkte uren en zal dossiers selecteren die naar het boekhoudsysteem geëxporteerd kunnen worden.
Er zijn meerdere views, maar ik gebruik ‘geavanceerd zoeken’ waarmee ik records kan selecteren per dossier en op concept.

Resultaat in de view

Al deze uren mogen gefactureerd worden, regels worden geselecteerd en de workflow ‘Uren aanbieden voor facturatie’ wordt geactiveerd

Ik pas het filter even aan (er zijn ook kant en klare views voor aangeboden regels) en bekijk de aangeboden regels op dit dossier.

Om te exporteren selecteer ik alle regels en druk op Geselecteerde records exporteren

Excel
Links onderaan staat het bestand welke in Excel aangemaakt is en die kan geïmporteerd worden in het boekhoudsysteem. De werkzame tijd is weergegeven in het aantal minuten per regel.

Voortgang dossiers
Als we nu onder Beheer bij het dossier 2018045 kijken, dan zien we dat er 4 uren en 30 minuten aangeboden zijn voor facturatie.

Zodra de werkzaamheden met goed resultaat verwerkt zijn binnen het boekhoudprogramma, worden de werkzaamheden als gefactureerd gemeld.
Door middel van geavanceerd zoeken selecteer ik de aangeboden uren op het dossier en druk vervolgens op de knop Werkstroom uitvoeren.

Kies voor de werkstroom ‘Uren zijn gefactureerd’ en activeer de workflow.
Ga ik nu naar het dossier 2018045 en Uren, dan zijn de regels inderdaad veranderd in de status ‘Gefactureerd’

Eindresultaat

Dit was in het kort hoe de oplossing werkt.
Het bespaart veel tijd, geeft veel meer structuur, geeft veel meer inzage in de voortgang en kwalitatief op een veel hoger niveau dan handmatig met allerlei afzonderlijke bestandjes zonder duidelijke controle.
Voor het management een gigantische verbetering en ondersteuning, en voor de medewerkers een minimum aan inspanning.

Migratie X applicatie naar Dynamics 365

by

Een belangrijk onderdeel bij het implementeren van een Dynamics 365 omgeving is de migratie van content van een bestaand pakket naar de nieuwe Dynamics 365 omgeving. Vaak wordt dit essentiële onderdeel onderschat en als sluitpost gezien.

Gepubliceerde artikelen in de huidige reeks:


Als het om een simpele applicatie gaat dan is een migratie wel snel en eenvoudig op te lossen, maar het wordt lastiger als het een complexer pakket betreft en de oude applicatie tot op het moment van livegang 100% in gebruik blijft. En dat is in de meeste gevallen zo.
Een betere aanpak is om een migratie traject op te zetten waarbij eerst data wordt opgeschoond, ontdubbeld en wordt verrijkt voordat het naar Dynamics 365 overgezet wordt. Eén op één migratie is bij de meeste migraties bijna onmogelijk en zelfs sterk af te raden omdat de data vaak verontreinigd is en een andere datastructuur heeft dat de nieuwe omgeving. Een ander facet is dat de OTAP omgeving van Dynamics 365 constant veranderd en dus ook de migratie bestanden constant aangepast moeten worden. Het is een continue proces van ontwikkelen, aanpassen, testen en nog eens testen.

Er zijn meerdere technieken om data over te zetten, zoals PowerShell scripts, TIBCOScribe, SQL Server Integration Services, etc. Met Scribe zijn uitgebreide mogelijkheden die prima resultaten opleveren. Tijdens de migratie met Intermediate Stages gaan werken. Voorkeur is om een tijdelijke omgeving in te richten met SQL server. Hierin komt de opgeschoonde en verrijkte data uit de content te staan. De datastructuur in die omgeving is gebaseerd op de datastructuur van de Acceptatie omgeving uit de OTAP omgeving van de Dynamics 365 omgeving.

Migratieomgeving

X Content bestaande applicatie
ISX Intermediate Stage X
OSX Ontwikkelomgeving Intermediate Stage X
O Ontwikkelomgeving Dynamics 365
T Testomgeving Dynamics 365
A Acceptatieomgeving Dynamics 365
P Productieomgeving Dynamics 365
A1 Datastructuur Acceptatie overnemen (script)
A2 Scripting onderdelen X naar OSX (voor ontwikkel en testen)
A3 Scripting onderdelen naar ISX (continue vullen ISX)
A4 Scripting onderdelen van ISX naar Acceptatie Dynamics
A5 Uiteindelijke scripting (import) naar Productie Dynamics
L Leegmaken ISX omgeving

Stappen

Het doel is om een op een bepaald moment de data van X om te zetten naar Productie Dynamics zonder dat de bedrijfsprocessen hiervan hinder hebben en niet onderbroken worden.
Op moment Y sluit de omgeving X en neemt vanaf dat moment Dynamics 365 het administratief beheer over.

S1
In de Ontwikkelomgeving worden entiteiten ontwikkeld en aangepast.
Zodra een onderdeel klaar is (Sprint bijv.) wordt er een solution gemaakt en overgezet naar de Test omgeving van Dynamics 365

S2
Normaliter gaan solutions van O naar T, naar A etc. maar af en toe is het nodig om de Ontwikkelomgeving leeg te maken en weer op te bouwen met de solution die in de Testomgeving staat, maar dat kan theoretisch ook vanuit Acceptatie of Productie gedaan worden.

S3
Nadat in de Testomgeving de oplossing getest is, gaat de solution naar de Acceptatie omgeving.
Daar wordt de oplossing uitvoerig getest door key-users en testers.
Zodra in de Acceptatie omgeving de oplossing goedgekeurd is, kan de datastructuur overgenomen worden in de tijdelijke omgeving

S4
Als de Acceptatie omgeving door het team goedgekeurd is en ook getest is met de actuele data uit de X omgeving, kan de solution overgezet worden naar de Productie omgeving.

A1
In de Ontwikkel Intermediate Stage X omgeving wordt een database oplossing gebouwd waarvan de structuur overeenkomt met de structuur van de Acceptatie omgeving en waarop later eenvoudig transmissie files te koppelen zijn om de data over te zetten naar Dynamics 365.
(bijvoorbeeld d.m.v. de DTS files in TIBCO Scribe)

A2
Afhankelijk van de databasemanager (Oracle of SQL?) worden transmissie files (SSRS) opgezet en wordt data vanuit X frequent geïmporteerd naar de files van OSX/ISX. In dat proces wordt data herstructureerd, ontdubbeld, fouten er uit gehaald en verrijkt. Zo ontstaat een tijdelijke omgeving als een kopie van de X omgeving, maar dan veredeld.
In deze omgeving worden onderdelen/entiteiten ontwikkeld en getest.

A3
Als een onderdeel gereed en getest is, wordt de migratiefile overgezet naar de ISX omgeving.
Tijdens het migratie project komen er steeds meer entiteiten bij totdat de volledige omgeving is gespiegeld (met een nieuwe structuur). Met een vaste frequentie (bijvoorbeeld elke nacht) wordt met scripts de Flows uitgevoerd en wordt de tijdelijke database gevuld.
De flows controleren wat de laatste aanpassingen zijn en wordt alleen dat overgezet wat nieuw of aangepast is. Natuurlijk bestaat ook de mogelijkheid om alles leeg te maken en weer opnieuw via SSRS de database te gaan vullen.

L
Zo af en toe is het handig om de database te legen en opnieuw te beginnen, maar ook bijvoorbeeld om een verse omgeving op te zetten of gereed te maken voor definitieve import naar de Productie omgeving Dynamics.
Met een script worden dan de entiteiten leeg gemaakt.

A4
Met bijv. Scribe worden DTS bestanden aangemaakt en die importeren met een vaste frequentie data van ISX naar Acceptatie. Dat kan met een vaste regelmaat plaatsvinden, maar ook handmatig.
Enkele organisaties kiezen er voor om naast de Acceptatie ook een migratie-test omgeving te hebben die onafhankelijk van de Acceptatie omgeving werkt. Er wordt dan vaak een backup gemaakt van de Acceptatie omgeving en gerestored naar die migratie omgeving.
Dit is om de testen betrouwbaarder te maken. Houd er wel rekening mee dat de Acceptatie omgeving altijd leading is. De structuur van Acceptatie bepaald de structuur van de ISX omgeving en niet bijvoorbeeld de Testomgeving.
Het zal niet de eerste keer zijn dat er een DTS gebouwd wordt op basis van de Testomgeving en dat daarna de heleboel vast loopt omdat de Acceptatie omgeving niet synchroon loopt met de Acceptatie omgeving.

A5
Uiteindelijk wordt de actuele data van ISX (dus X) naar de Productie Dynamics overgezet.
Eerst zal de ISX omgeving leeggemaakt worden, vervolgens wordt de ISX database gevuld met bijvoorbeeld de flows in SSRS en onstaat een kopie van de X omgeving.
Op het moment suprême (bijvoorbeeld in een weekend) wordt de data via DTS bestanden geïmporteerd in de Dynamics 365 omgeving.
Vanaf dat moment is P Dynamics leading en zou de X omgeving gestopt kunnen worden.
Enkele organisaties laten daarna de X omgeving doorlopen om eventueel terug te kunnen grijpen naar de oude omgeving

Aanmaken entiteit in Dynamics 365 met Power Apps

by

In dit artikel beschrijf ik hoe je binnen Power Apps een nieuwe entiteit aanmaakt.
In de vorige artikelen heb ik in User Stories beschreven dat ik binnen de Dynamics 365 CE omgeving 6 nieuwe entiteiten zal aanmaken.
Je kunt de klassieke weergave gebruiken, maar Microsoft stimuleert het gebruik van de Unified Interface en daarom behandel ik zoveel mogelijk het bouwen van de Apps binnen Power Apps.
Voor de opbouw van de entiteiten verwijs ik naar de kennis artikelen die ik reeds in deze serie geschreven heb.

Gepubliceerde artikelen in de huidige reeks:

Wil je alvast het resultaat zien van deze oplossing, klik dan op de onderstaande link.

https://youtu.be/yIIgmfT8Fcw

Vanuit Power Apps klassieke weergave

Power Apps is nog niet volledig uitontwikkeld dus je zult af en toe toch verwezen worden naar de klassieke weergave om specifieke aanpassingen te doen. Ikzelf gebruik de klassieke weergave o.a. om Javascript toe te voegen en te koppelen aan de Formulieren. Inmiddels werk in al bijna 10 jaar met de klassieke weergave, dus kan ik daar sneller onderdelen vinden.
Sinds de komst van de Inified Interface dwing ik mij wel om zoveel mogelijk met de Unified Interface te ontwikkelen. Als je bijvoorbeeld op het hoofdformulier Account bezig bent, dan kun je midden boven kiezen voor de klassieke weergave. Sluit de pagina en je komt weer terug in de Unified Interface.

Vanuit Unified Interface naar de klassieke weergave

Je komt vanuit de Unified Interface in de klassieke weergave door rechts bovenaan bij instellingen voor geavanceerde instellingen te kiezen. Het voordeel hierbij is dat je vervolgens bij instellingen naar alle componenten kunt switchen.

Uitgever
Nadat je Power Apps hebt opgestart, zorg dat je eerst een Oplossing aanmaakt met je eigen ‘uitgever’ en dus voorvoegsel. Dat levert achteraf meer duidelijkheid op en werkt ook sneller.
Maak de Publisher (uitgever) aan door in de klassieke weergave bij instellingen te kiezen voor aanpassingen en dan uitgevers.

Maak een nieuwe oplossing aan.
In deze behandeling heb ik de oplossing ‘TheoDev’ aangemaakt.

Eventueel kunnen de instellingen van de oplossing later aangepast worden door op ‘…’ te klikken en bij instellingen de oplossingsinstellingen aan te passen

Nieuwe entiteit “Assortiment”

Voeg een nieuwe entiteit toe en vul zo wie zo de verplichte velden in en druk op gereed

Vervolgens worden de gevraagde velden aangemaakt

Deze entiteit die ik Assortiment genoemd heb, heb ik vervolgens met een meer tot één relatie gekoppeld aan de entiteit product.
In de volgende stap maak ik binnen Formulieren een nieuw hoofdformulier aan

De entiteit wordt opgeslagen en gepubliceerd

Aanpassen van de Interface
Binnen Power Apps ga ik naar ‘Apps’
Ik heb de ‘Sales Professional’ als voorbeeld gebruikt om verder uit te werken. Kies voor bewerken.

Selecteer ‘Siteoverzicht’

Ik heb gekozen om de entiteit in de Groep ‘Ondersteunend materiaal’ te plaatsen
Daarvoor ga ik hetop blokje ‘Ondersteunend materiaal’ staan en druk op toevoegen en kies voor Subgebied. Vul de gevraagde informatie in.

De oplossing opslaan en publiceren.
Druk op Afspelen om het resultaat te bekijken.
Vul het eerste record in

In de User Stories staat beschreven zijn de handelingen beschreven die de gebruiker zal uitvoeren en ook hoe de entiteiten samengesteld zijn.
Hieronder het overzicht van de entiteiten die toegevoegd zijn.

Het uiteindelijke resultaat is hieronder te zien

Om het resultaat van de Business Case te bekijken, treft je hieronder een Video presentatie aan.
In de presentatie heb ik de onderstaande case uitgewerkt:

  • Er is reeds een afnemer UMC Amsterdam aangemaakt, net als contactpersonen
  • Aanmaken record “Locatie stroom”
  • Aanmaken van een NSVcontract (NoodStroomVoorziening) installatie en operationeel beheer
  • Er wordt een Installatieverzoek aangemaakt
  • Vervolgens wordt er een inspectieverzoek aangemaakt
  • De installatie wordt geïnstalleerd en afgemeld door de monteur
  • De Inspecteur gaat de installatie inspecteren en meldt de inspectie af
  • De inspecteur maakt certificaat aan
  • Er wordt een nieuw onderhoudsverzoek aangemaakt
  • En vervolgens een nieuw inspectie verzoek

Voor het uiteindelijke oplossing klik op de onderstaande link:

https://youtu.be/yIIgmfT8Fcw

User stories ‘NoodStroomVoorziening’

by

In de User Stories ga ik op een eenvoudige schrijfwijze beschrijven hoe de gebruikers omgaan met de processen waaraan ze werken. In de praktijk zullen de User Stories veel uitgebreider worden beschreven, maar niet nodig om de lezer een duidelijk beeld te geven wat er geautomatiseerd gaat worden. De bedrijfsprocessen starten zodra de accountmanager succesvol de order afgesloten heeft. M.a.w. acquisitie, relatiebeheer, offerte-, order- en factureringsverwerking liggen buiten de scope van deze beschrijving.

Gepubliceerde artikelen in huidige reeks:

Users

Binnen de beschrijving hanteer in de onderstaande user beschrijving:

• Officemanager (OFF)
• Inspecteur (INS)
• Onderhoudsmonteur (MON)
• Afnemer (AFN)
• De applicatie (SYS)

In de eerste User Story beschrijving ga ik ervan uit dat alle administratieve handelingen handmatig verwerkt worden. In toekomstige Business Cases worden onderdelen nader geautomatiseerd.

Summiere procesbeschrijving

Zodra de order succesvol is afgesloten, wordt er een NSVcontract aangemaakt en worden opdat moment ook een installatie- en inspectieverzoek aangemaakt.
Nadat de Noodstroomvoorziening (aggregaat) is geïnstalleerd, zal er een inspectie plaatsvinden en wordt vervolgens een certificaat afgegeven.
De Noodstroomvoorziening wordt operationeel en al naargelang contract wordt er een onderhoudsverzoek aangemaakt voor periodiek onderhoud en een inspectieverzoek voor de periodieke inspectie. Aan de hand van de inspectie wordt het certificaat verlengd.
Dit proces herhaalt zich telkens. Indien er een reparatie moet plaatsvinden, dan zal er een reparatieverzoek worden aangemaakt en worden uitgevoerd. Voor onderbouwing user stories heb ik tevens de essentiële entiteitsbeschrijvingen toegevoegd.

User Stories

  • De user OFF maakt binnen de APP een nieuw NSVcontract aan en vult de onderstaande velden in:
    – Naam
    – NSVcontract
    – Type contract
    – Plandatum installatie
    – Afnemer
    – Locatie installatie
    – Contactpersoon afnemer
    – Type onderhoud
    – Type inspectie
    – URL kennisbank van dit type aggregaat
    – Opmerkingen
  • De user OFF maakt een installatieverzoek aan en vult de onderstaande gegevens in:
    – Naam installatieverzoek
    – NSVcontract
    – Monteur
    – Plandatum
    – Verwachte installatie tijd
    – Status installatie
    – Opmerking
  • De user OFF maakt een inspectieverzoek aan en vult de onderstaande velden in:
    – Naam
    – NSVcontract
    – Inspecteur
    – Plandatum inspectie (indien bekend)
    – opmerkingen
  • De user OFF plant een afspraak voor de monteur in de agenda in
  • De user OFF verstuurt een email naar de monteur met de ingeplande afspraak
  • De user MON gaat naar de locatie van de afnemen en installeert het aggregaat
  • De user MON raadpleegt eventueel de kennisbank binnen het systeem indien meer informatie gewenst is
  • De user MON installeert aggregaat en meldt binnen het systeem dat de oplevering is gerealiseerd en afnemer akkoord is
    Velden
    – Datum oplevering
    – Status contract
  • Indien de user MON de oplevering niet kan afronden, neemt hij contact op met de user OFF
  • Indien oplevering succesvol plant user OFF een afspraak in de agenda is voor de inspecteur
  • User OFF werkt record NSVcontract bij
    Velden:
    – Plandatum installatie inspectie
  • User OFF werkt inspectieverzoek bij
    Velden:
    – Inspecteur
    – Plandatum inspectie
  • Zodra de user OFF de afspraak voor user INS heeft ingepland verstuurt de user OFF een e-mail naar de user INS
  • Indien oplevering niet succesvol is afgerond plant de user OFF een onderhoudsverzoek type reparatie in voor user MON
    Velden onderhoudsverzoek:
    – Naam
    – NSVcontract
    – Monteur
    – Plandatum onderhoud
    – Type onderhoud (reparatie)
    – Opmerkingen
  • Na inplannen onderhoudsverzoek stuurt de user OFF een e-mail naar de user MON
  • User MON gaat de reparatie uitvoeren en zal alsnog de installatie opleveren
  • User vult de onderstaande velden in:
    Onderhoudsverzoek:
    – Status installatie
    – Datum uitgevoerd
    – opmerkingen
    Installatieverzoek:
    – Datum oplevering
    – Status installatieverzoek
    – Opmerkingen
    NSVcontract:
    – Datum oplevering
  • De user INS gaat de installatie inspecteren en indien akkoord zal de user INS het inspectieverzoek positief afmelden
    Vult de onderstaande velden in:
    – Inspectiedatum
    – Resultaat
    – Opmerkingen
  • De user INS vult binnen het systeem een certificaat in
    Velden:
    – Naam
    – NSVcontract
    – Inspecteur
    – Type certificaat
    – Datum afgifte
    – Duur geldigheid
    – Verloopdatum certificaat
  • De user INS slaat een afdruk van het certificaat in pdf formaat op
  • De user OFF verstuurt per e-mail het certificaat naar contactpersoon afnemer
  • De user OFF maakt binnen het systeem een onderhoudsverzoek aan
    Velden:
    – Naam
    – NSVcontract
    – Plandatum onderhoud
    – Type onderhoud
    – Type tekst
    – Opmerkingen

Entiteitsbeschrijving

Assortiment

• Naam
• Vermogen
• Aansluiting
• Afmeting
• Tankinhoud
• Ledig gewicht
• Geluidsniveau
• Brandstof
• Product

NSVcontract

• Naam
• Aggregaat – assortiment
• Type contract (huur of koop)
• Plandatum installatie
• Locatie installatie
• Afnemer
• Contactpersoon afnemer
• Type onderhoud
• Type inspectie
• Datum oplevering
• Plandatum installatie inspectie
• Datum installatie inspectie
• Datum certificaat
• Datum operationeel
• Status contract (in behandeling, installatie, opgeleverd, beëindigd)
• Datum laatste onderhoud
• Plandatum onderhoud
• Datum laatste inspectie
• Plandatum inspectie
• Datum noodsituatie
• Status noodsituatie (stroomstoring, in actie, startproblemen, afgerond, geen)
• Afgegeven certificaten (1:meer)
• Geleverd onderhoud (1:meer)
• URL kennisbank dit type aggregaat
• Opmerkingen

Installatieverzoek

• Naam
• NSVcontract
• Monteur
• Plandatum installatie
• Verwachte installatie tijd
• Datum oplevering
• Status installatie verzoek (te doen, in bewerking, afgerond, problemen)
• Opmerkingen

Inspectieverzoek

• Naam
• NSVcontract
• Inspecteur
• Plandatum inspectie
• Type inspectie (Installeren, periodiek basis, periodiek basis + brandstof)
• Inspectiedatum
• Resultaat
• Opmerkingen

Certificaat

• Naam
• NSVcontract
• Inspecteur
• Type certificaat (ISOxx1, ISOxx2, ISOxx3)
• Datum afgifte
• Duur geldigheid (1 maand, 6 maanden, 12 maanden, 24 maanden, onbeperkt)
• Verloopdatum certificaat

Onderhoudsverzoek

• Naam
• NSVcontract
• Monteur
• Plandatum onderhoud
• Type onderhoud (Basis, Basis + brandstof, basis plus testen, Reparatie)
• Type test (onbelast, belast)
• Resultaat test (akkoord, afgewezen)
• Status installatie (Akkoord, onderhoud gewenst, reparatie gewenst, niet akkoord)
• Datum uitgevoerd
• Opmerkingen

Business Case ‘Noodstroomsystemen’

by

Om een oplossing in Dynamics 365 te bouwen treft u hieronder een Business Case aan die vervolgens in de volgende kennisartikelen verder uitgewerkt zal worden.
In deze oplossing is besloten Dynamics 365 Sales als basis te gebruiken, echter had dat ook Dynamics 365 F&O kunnen zijn.

Publicaties in deze reeks:

Business Case conform Prince2

Doelstelling

De verkooporganisatie heeft onlangs besloten om met Dynamics 365 Sales te gaan werken.
Naast de aanschaf van Dynamics 365 Sales zal de Applicatie uitgebreid gaan met enkele entiteiten/functionaliteiten om een hogere betrouwbaarheid te kunnen aanbieden.
Het bouwen in PowerApps en operationeel maken zal binnen 2 maanden gerealiseerd worden.
Het project zal xx-xx-xxxx starten.

Aanleiding

De organisatie ‘AGGR’ is een verkooporganisatie die noodstroomsystemen verkoopt en/of verhuurt en service verleent op deze producten.
Ze huren onderhoudsmonteurs in en inspecteurs die de geplaatste producten regelmatig onderhouden en checken. Zij geven betrouwbaarheidscertificaten af zodat de afnemer verzekerd is van 100% functioneren in noodsituaties en van milieugaranties zodat de afnemer niet geconfronteerd gaat worden met toekomstige milieumaatregelen en lekkages. Etc.

De afnemer koopt of huurt een aggregaat, wordt geplaatst en geïnstalleerd, de verkooporganisatie geeft een certificaat bij oplevering installatie.
Periodiek vindt er onderhoud plaats en periodiek inspectie door een Kiwa gecertificeerde inspecteur die het aggregaat, brandstofleidingen, eventueel externe tank en omgeving inspecteert om werking te garanderen.

Tot heden wordt de daadwerkelijke levering en onderhoud in diverse Excel bestanden beheerd en dat veroorzaakte regelmatig miscommunicatie en ergernis op, zodat management besloten heeft om het professioneler aan te pakken.

Alternatieven

  1. Maatwerkpakket XX laten bouwen

    De concurrentie werkt met product XX, maar biedt te weinig voordelen en te duur

  2. Dynamics 365 F&O als basis gebruiken

    De organisatie behoort tot de Technico Holding en binnen de Holding wordt bij de productiebedrijven met Axapta gewerkt
    Echter te complex voor de verkooporganisatie en Axapta zal pas over 2 jaar vervangen gaan worden door Dynamics 365 F&0

  3. Dynamics 365 Business Central

    Er is nog geen duidelijkheid over het nieuwe financiële pakket en de Holding gaat de eerste 2 jaar nog niet over naar een ander systeem en is Dynamics 365 BU geen alternatief

  4. Doorgaan met Excel

Verwachte voordelen

• Hogere betrouwbaarheid uitgeleverde producten
• Meer inzicht in geleverde producten
• Duidelijkere planning en uitvoering onderhoud
• Duidelijkere planning en uitvoering inspecties
• Betere visuele presentaties managementrapportages
• Gebruikersvriendelijker
• Uiteindelijk kostenbesparing door gestructureerd werken

Risico’s

• Te weinig aandacht voor een gedegen informatieplan
• Te lage gebruikersacceptatie door de accountmanagers
• Gevoel teveel gecontroleerd te worden zodat gegevens niet ingevuld worden
• Gegevens niet op locatie van afnemer bijgewerkt worden en teveel indirect werkt ontstaat door binnendienst

Kosten

Buiten de scope van deze beschrijving
Voor een gedegen Prince2 project zou dit zeker essentieel zijn, maar dit kennisartikel gaat over de opzet binnen Dynamics 365

Planning

• Schrijven van User stories
• Vastleggen in DevOps
• Aanmaken entiteiten
o Assortiment (alle noodaggregaten hierin opgenomen)
o Artikel (product welke uitgeleverd wordt aan afnemer
o Garantiecertificaat
o Onderhoud
o Certificaat
o Inspectie
o Bezoekrapportage
• Flows aanmaken PowerAutomate
• Alternatief plug-in bouwen
• Bedrijfsprocesstromen aanmaken
• Canvas oplossing bouwen servicemonteurs en voor inspecteurs
• Knowledge base aggregaten opzetten en toegankelijk maken buitendienst
• Vullen entiteiten (handmatig en import Excel)
• Evaluatie en voorstel vervolgtraject

Benodigde investering

Niet relevant voor deze denkbeeldige oplossing

Bijl: Dynamics 365 Sales omgeving

Apps ontwikkelen in Power Platform

by

Power Platform en Unified Interface

Hoe bouw je oplossingen in Dynamics met PowerApps?
Schijnbaar is er geen bedrijf die zulke korte “life-cycles” hanteert als Microsoft dat doet.
Hun marketingmachine bedenkt de ene na de andere verassing. Je hoort mij niet zeggen dat het allemaal nutteloze veranderingen zijn, wel dat ontwikkelingen zich snel opvolgen.
Sinds ik in 2009 met Dynamics CRM3 gestart ben, heb ik inmiddels alle CRM versies uitvoerig leren kennen en is nu de periode Unified Interface aangebroken.
Binnenkort spreken we niet meer van Dynamics, maar over Common Data Service met als basis Power Platform.
Er zal diepgaande integratie met andere platformen gaan plaatsvinden zodat gebruikers mobieler worden en gebruik maken van Tablets, Smartphones, etc.

CRM, Axapta en Navision

Al jaren staat de integratie van meerdere Microsoft Business producten opstapel. Sinds enkele jaren is het er dan toch van gekomen en zijn Navision en Axapta samen met CRM geïntegreerd in één programma. Samen met Office 365 gaan zij een platform vormen.
Omdat vorm te geven is één structuur bedacht en wel de Unified Interface. Niet dat de klassieke interface verdwenen is en zal het beheer voorlopig nog de klassieke interface gedaan worden. Microsoft is bezig om functionaliteit in ‘the cloud’ te bundelen samen met Teams, PowerBI, Word, Excel, PowerAutomate, SharePoint, etc.
Wat voorheen Axapta was heet nu ‘Dynamics Finance and Operations’ en Navision kreeg de naam Dynamics 365 Business Central.
In de basis op het zelfde platform alleen met behulp van andere componenten, die specifiek op een bedrijfsfunctie toegespitst zijn.
Voor de kenners zijn duidelijk de overeenkomsten te zien en voor de insiders is het bekend dat de onderliggende CDS hetzelfde is.

Gelijkenis oplossingen in Unified Interface

Let maar eens op de overeenkomsten. De linkermenu balk en de formulierbalk.

Voorbeeld van leverancier in Dynamics 365 (Unified Interface )
Voorbeeld leverancier in Dynamics Finance and Operations

Geen complex en duur maatwerk meer

Als Microsoft Dynamics Professional was ik gewend om met de klassieke interface te werken en met behulp van C#.net en Javascript maatwerk te maken. De achterliggende gedachte van Microsoft is om het maatwerk zoveel mogelijk te verbannen en hun Apps gebruikersvriendelijker te maken. De gedachte is dat iemand met redelijke ervaring in Excel snel oplossingen kan bouwen met behulp van PowerApps.
Zo’n Excel expert kan snel in PowerApps applicaties bouwen als Canvas oplossing of als model gestuurde oplossing.

Ontwikkelen binnen Power Platform

In de komende maanden zal ik lezers meenemen in het ontwikkelen van bedrijfsoplossingen zonder zware maatwerkoplossingen toe te passen.
Binnen PowerApps zijn er al veel kant-en-klaar componenten te downloaden en zijn snel toepassingen te bouwen. De vraag is natuurlijk hoe start je zo’n proces op en waar kun je volstaan met Power Automate of toch alsnog plugins bouwen met C#.net!
Nieuwsgierig? Laat je verassen door de ongekende mogelijkheden en kijk op de site van Microsoft. Bekijk wat de mogelijkheden zijn om je verder te verdiepen in reeds bedachte oplossingen. Er zijn tig aantal Apps te vinden binnen Power Platform.

Business case en User stories

In mijn volgend artikel zal in een Business Case gaan beschrijven en vervolgens aan de hand van User Stories oplossingen gaan beschrijven. Natuurlijk geen volledig ontwerp, maar wel voorbeelden om de lezer op gang te helpen. Dat aan de hand van een denkbeeldige casus.
Daarbij zal ik gebruik maken van DevOps om een gestructureerde aanpak te garanderen.
Voor de geïnteresseerden, Microsoft biedt allerlei online trainingen aan en specifieke trainingen zijn ook prima te vinden op de site Pluralsight.com