One of the prevailing challenges that I encounter over and over again, is that companies that I talk to reveal that they leave some integration aspects with other systems of record as after-thoughts or last-thoughts.
The reason this happens can be numerous, they can be because the initial scoping was rushed and incomplete, it can be because the implementation initiative was executed in isolated of conventional implementations as perhaps a ‘shadow IT’ project or it could be that the budget was exhausted before the integration could be considered.
It could also be, that the integration requirements have simply evolved over time and the current integration models and structures are no longer aligned with the requirements of the business.
Many systems – many integration points
We see these challenges all the time at Winshuttle.
We use several systems ourselves. Microsoft GP for financials, Salesforce for Sales and Service and a slew of other systems.
The market indicates that on average every business has at least ten additional systems of record in addition to the core system of record. A common one is Salesforce in companies that are sales or service centric but another might be SAP ERP or Oracle EBS. Excel, although often not considered a system of record is also ‘everywhere’ and heavily depended on for data collation and reporting.
Part of the core challenge with having all these systems is having a unified view of the customer. The absence of a unified view of the attributes of a customer means that different departments could be either duplicating customers or working off data that is inconsistent or incorrect.
Master data and finance groups are potentially constantly in catch up mode with respect to synchronizing data in the absence of robust real-time (or batch based) integration infrastructure. A further challenge is that modifying integration often takes time and requires multiple resources before it can be put in place.
Excessive dependence on the SF Administrator
As an interim step the business will often have to work closely with its Salesforce Administrator to have them push and pull data from Salesforce with various tools like the salesforce dataloader. While this is an effective way of manipulating records and enriching Salesforce data, it doesn’t really stand up to the scrutiny of audit groups and more importantly, it places an extraordinary burden on the salesforce administrator while they have other tasks to perform and projects to execute.
Up until now, the only way to address this gap was either to continue with this asynchronous approach to data maintenance tasks along with all the risks or to build capabilities into the salesforce UI itself to support a self-service approach. As a last resort, business users might key the data manually.
Business users take ownership of data management
Taking advantage of the experience that thousands of SAP customers had with working with SAP data the challenge with Salesforce was pretty clear and similar. Empower the business users to leverage the rich API libraryprovided by Salesforce but in an elegant and robust way. In a way that would minimize risk.
We started out using a shell of our existing desktop product and then built the integration for the Salesforce API’s enabling an ‘Author’ – who might be a super user or Salesforce Administrator to expose, distil and publish access to one or more API’s and then make that available to ‘Runner’ class users to leverage for retrieving, updating and creating data in Salesforce on demand, interactively and most importantly from the comfort of Excel, in a resilient way.
The success internally has been phenomenal and for companies that use both SAP and Salesforce the benefits are very clear and apparent.
Our own use of Salesforce continues to evolve and our customer community is exploring ways in which the product can be used in their scenarios too.
If you’re interested in getting your hands on the product please do visit the AppExchange listing for Winshuttle and contact us for details.
Director of Product Management