So I’m a sales and marketing guy. It’s what I do.
In a previous life I worked for a manufacturing company running on IBM i that used salesforce.com to manage accounts, contacts, opportunities, and tasks like logging sales calls and follow up activities. The overall inside sales team and the individual inside sales rep needed a streamlined way to:
- Know which accounts are mine
- Know who to call when
- Know when the last time was that they contacted an account
- Know what the last conversation was about
- Have a way to “rate” accounts based on their previous buying history and habits
- Rate sales opportunities by probability of closing so appropriate focus can be given to highest probability opportunities
- See the last time a given account had purchased something
- See what the last order actually was
- See the sales history of an account by year and by month
- Generate reports based on sales criteria of accounts
- Easily update contact data which changes frequently
And there were many more that I’ll save for another day.
The core challenge was that all of the sales and order data resided within IBM i and a DB2 database.
The company (like many others) had written custom ordering and estimating applications in RPG that were used internally by customer service, estimating, and accounting departments. When it came to having insight into recent sales and order data, a bridge needed to be built between salesforce.com and the transactional data existing within IBM i.
Option 1: Import sales and order history data periodically from IBM i into salesforce.com as CSV files
This became a job function of mine. Lucky me!
I learned how to “map” data attributes from CSV file column headings to salesforce.com “Objects”. I learned that if the column headings in the CSV files weren’t spelled exactly the same as the object names in salesforce.com I got duplicate records. I learned that it takes a good chunk of time to map spreadsheets that were filled with many order data attributes accurately. I learned that other people on the inside sales team will get mad if their account data is not accurate in salesforce.com. I learned that submitting ongoing “query requests” to the IBM i technical support team to get the data I needed out of IBM i kinda, well…stunk. And I learned that I often forgot to include all the data I needed on my initial query request and then we got to do it all over again. (More fun)!
I also learned that one of the IBM i query “administrators” had an enormously large Big Gulp of some presumably caffeinated beverage on her desk at all times to get her through the day.
Option 2: Leverage the Salesforce.com API to automate the real-time exchange of sales and order data from IBM i into Salesforce.com
When it came to understanding XML, web services, “APIs”, and related technologies, the manufacturing company I worked for was a little behind the times. They had rock stars for RPG programmers. The had people who knew database design and DB2 inside and out. They maintained a core business system within IBM i that seemingly was never “down“. Many aspects of overall I.T. operations worked flawlessly. But when it came to implementing an automated “sharing” mechanism of data between IBM i and anything else, the barrier was up and in full force.
The year was 2004. RPG-XML Suite had yet to be developed as a usable “bridge” the RPG development team could use to close this gap.
Fast forward ten years to today – 2014.
This spring I was contacted by another manufacturing company that is presently doing what sounds like the exact same thing. They import CSV files containing order data from IBM i into salesforce.com three times a day. They import CSV files containing year-to-date sales data of accounts every month. They import other elements of customer data at other time intervals.
I might be in sales but I’m pretty convinced the internal RPG development team either doesn’t have the experience or the right tools to eliminate the manual data processing methods they’ve used and depended on for years. By combining a free proof of concept with a quick scan through the salesforce.com API Developer Guide, manually importing CSV files can be a thing of the past.
And you can even keep the Big Gulp. It’s a good conversation starter.
But free up your inside sales time to close more deals, not massage more CSV files.
Just my two cents. But then again, I’m in sales.
(And if you don’t like sales guys, talk to our support team – they like Big Gulps too).