Whenever I am brought into a new and exciting systems integration project (or any project for my clients, really), one of the first questions I ask, if I do not get beat to it by the client of course, is what other platforms or modules are currently being used that are in scope for this project?
Why is this question important? Or better yet, you must be saying to yourselves as you read this, "DUH! Of course that is important, Tal!".
Why, yes, it is important.
However - do we really know or need to know the breadth of what we are syncing, or better yet, why we are syncing it?
Here is a real-life example from a recent project that was successfully delivered to a happy client: we needed to restructure their entire CRM ecosystem (in this case, Zoho CRM) in order to be able to provide their internal users (accounting, fulfillment, sales, support - basically, everyone who uses the system on a daily basis) with the ability to better capture, but more importantly, find, the correct client and associated sale(s) related to that client.
Up until the point in which I was brought into working with their organization and started working together, the standard flow was to leverage manual email search in their internally-shared order mailbox, which as one can imagine, is far from ideal.
By connecting their CRM with a relatively easy-to-configure integration to their email server (Outlook 365 in this specific case), suddenly things became much clearer:
Instead of needing to go back and forth between CRM and email client or tabs in Chrome or Safari, all relevant correspondences with a given client or contact was clearly visible in the same contact's page in CRM, saving arguably hours of work for years to come.
So obviously, this is an example of a "good" sync to include in scope and configure for mass usage.
So what is a "bad" example, you might be asking?
Well much like the old adage of "there are no stupid questions, only stupid answers" (which the truth thereof we can argue on another day and time) - there are no bad use-cases of syncs if they work for the client, since every client and business is different and one use case might not work for one but work for someone else.
However, there certainly are bad setups; poorly-thought or half-complete configurations and syncs, field-mappings, or other band-aided solutions getting reprieve from permanent termination of database life, living the same harmful life but perhaps with a slightly refreshed look & feel, yet the messiness that got us here in the first place continues to live on and on.
So what is the moral of the story, then?
Simply put - data syncs can be considered a "necessary-evil", but they are only evil when they never properly worked or were not properly tested in the first place, and worse yet - do not get revisited and reconfigured (and likely removed) during a new data migration or optimization project.
Mistakes happen and are OK, and I will be the first to say that they are even welcomed (heck, this is how I learned ~95% of what I know today!), but making the same mistake twice is not OK - and if there is willingness to take the time and effort, but most importantly and open-minded and honest approach of revisiting our existing data-syncs at the relevant times - life becomes much clearer, cleaner and another much more important and value-adding adage creeps into the scope of the discussion:
Work smarter, not harder!
About the author: Tal Spirer is the owner and lead consultant of Spirer Technology Solutions LLC, a boutique systems integrator and business intelligence provider of technology consulting services to SMB's, based in the DFW area.
Comentarios