Integration Designers and Developers Need Business Context

By Steve Endow

At the GPUG Summit 2016 conference in Tampa 2 weeks ago, I gave a presentation on Dynamics GP system integration design with Tim Wappat.

This is one of my final slides in the presentation:

Out of context, this slide may not seem as meaningful as it is in the presentation, but the idea is that when system integrations are not simplified or designed strategically, they are just glorified data imports that do not help the business strategically.

The next slide offers some goals:

Part of making system integrations successful and more valuable is designing them to meet business requirements.  It isn't just about pushing data into GP.  It's about ensuring that the entire purchasing process, for example, from requisition to PO to receipt to invoice, goes smoothly and with as little manual effort as possible.

To do that properly, the entire team needs to be aware of the context of the system integration and understand the business use cases and requirements.



I mention this because of an integration I am currently working on.  I was asked to develop an integration that reads data from a SQL table and imports the data as Purchase Orders in Dynamics GP.  I was given a sample database table layout and told to go forth and create the integration.  No problem.

While developing the integration, I inquired why the PO data tables did not have a Site ID field. That led to a call where I was told that the customer did not use the Site ID field in GP.  Hmmm, that sounds odd, as the Site ID is a required field on Purchase Orders in Dynamics GP.

I was then informed that everything is a non-inventory item, so Site ID doesn't matter.  So the client is asking that I import purchase orders for only non-inventory items into 30 different companies in 20 completely different industries, and they don't use Site IDs in GP?

Some alarm bells started to ring in the distance.

I asked the customer if they could discuss an example of what was being purchased--what items are being requisitioned that will end up on the purchase orders.  Only 2 people from the client were on the call, and they were both from IT, so they were unable to provide any specific examples.  But they had spoken to the finance folks several times, and finance insisted that the Site ID was not used in GP.

Okay, no problem.  I modified the integration to read a fixed generic Site ID from a config file, and that single Site ID could be used in all companies for all purchase orders.  The integration was delivered and tested.

During testing, you'll never guessed what happened.

"Oh, you mean THOSE Site IDs????  Of course we use those Site IDs in Dynamics GP!"

So we are now at a point where the 5 different roles on the project (internal IT, internal end users, and 3 different external consultants) understand that there was apparently some miscommunication during the design stage of the much larger project, and we are going to have a call with all parties to revisit the fundamental requirements.  And those requirements don't just affect my integration--they fundamentally change the requirements for the requisition system that is capturing the data to be imported into GP as purchase orders.

The conversation we will be having will be about business process and business requirements and how we will get the requisition system and Dynamics GP to work together to meet those requirements.  The subsequent integration requirements are trivial relative to those.

So when you design system integrations, work from business requirements first, and let those guide your technical requirements.  Don't start by listing fields and designing tables and mapping data--that process comes later.

Steve Endow is a Microsoft MVP for Dynamics GP and a Dynamics GP Certified IT Professional in Los Angeles.  He is the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.

You can also find him on Google+ and Twitter

http://www.precipioservices.com