How Trek Solved Its IBM i-to-Cloud Data Integration Challenge
February 4, 2015 Alex Woodie
When the bicycle manufacturer Trek started looking for a CRM system several years ago, the cloud beckoned loudly. While the company has happy with its on-premise ERP system running on IBM i hardware, the new CRM would live in the cloud. But getting data back and forth between the two systems wouldn’t be easy. Luckily, the company found a tool that made data integrating cloud and on-prem data simple.
From its headquarters in Waterloo, Wisconsin, Trek Bicycle Corp. makes and sells hundreds of thousands of bicycles every year to customers around the world. The privately held company, which in 2006 had revenues estimated at $600 million, sells bikes primarily through a network of 1,700 dealers in North America, as well as through a network of subsidiaries and distributors across Europe and Asia.
The company automates core business processes on Oracle‘s JD Edwards EnterpriseOne software running on an IBM Power Model 740 equipped with the IBM i operating system and the DB2 for i database, a combination that has served the company well over the years.
While the JD Edwards ERP software is well-suited to handle core back-office processes such as accounting, payroll, and distribution, it’s not necessarily ideal for front-office tasks, such as supporting the network of dealers and independent bike shops that sell Trek’s products. Beyond the likes of Excel spreadsheets and Post-In notes, the company had no regimented process in place to track or guide how its representatives interacted with its dealers.
Much of the support data that Trek wanted to track was unstructured, which made it a bad fit for the ERP system, says the company’s enterprise collaboration manager, David Peterson. “There was a need to track data about our customers that didn’t belong in the ERP system, things like birthdays or kids’ names or their favorite sports teams,” Peterson says. “Imagine if you’re trying to track birthdays for your dealers in the JD Edwards system. That just doesn’t make sense.”
About three years ago, Trek decided to augment its core ERP system with a new CRM application that could automate the storage and tracking of data used in the support of its dealer network. In addition to storing the occasional birthdate or name–information that can help Trek representatives land a deal–the CRM system would centrally manage communications with the dealer network, including phone calls and emails.
The company wanted an enterprise-grade, cloud-based CRM system delivered as a service. Those criteria narrowed Trek’s search down to two providers: Salesforce.com and Microsoft Dynamics CRM, according to Peterson. Owing to the company’s existing investment in Microsoft’s Office productivity software and its SQL Server-based business intelligence stack, the company opted for the cloud version of Dynamics CRM.
The Dynamics CRM roll-out, like most enterprise software deployments, was not without its drama, according to Peterson, who was not with Trek when the CRM system was implemented. Nevertheless, the company pushed through and successfully completed the roll-out, and today it’s used by nearly 200 Trek employees.
Data Integration Challenges
One of the toughest nuts to crack was integrating data between the JD Edwards system and Dynamics CRM. While the CRM system maintains its own database, there is a need to push data from the IBM i system into the Dynamics CRM software running on Microsoft’s servers.
That’s not exactly a simple task because Microsoft doesn’t readily expose the underlying SQL Server database that the software runs on, Peterson says. “Getting the data into the CRM is a problem because you can’t talk to the tables on the other end,” he says. “You don’t have rights to just get to the SQL. You’ve got to do it through Web services.”
The IT folks at Trek sought a tool that could help ease the integration, and found one from a company called Scribe Software. According to Peterson, Scribe abstracts a lot of the complexity of pushing data from the DB2 for i database into the hosted SQL Server database that underlies Microsoft Dynamics CRM.
“If I had a .NET developer, we could talk to the REST end points. But Scribe has done the work for us,” Peterson says. “Scribe has done all that effort up front to write those connectors that already talk to the Web services.”
Scribe’s GUI makes it easy for Trek’s IT administrators to set up data sharing between the JD Edwards and Dynamics CRM system. “It’s all pre-packaged, all point and click and GUI-based. There’s no coding involved,” Peterson says. “You get your user name and password and URL, and hit go. Then you chose your entities–really, they’re stable, but they call them entities–that you want to connect to, and you just map your fields one to one.”
In addition to just moving the data over its ODBC-based driver, Scribe will perform a range of other SQL commands, including inserts and updates. While it supports bi-directional replication, Trek is just using it for one-way replication. “You can do whatever you want,” Peterson says. “It’s pretty slick.”
Trekking to Customer Satisfaction-Ville
With Scribe handling data integration between the ERP system and the CRM system, Peterson was free to focus on using the CRM to improve his employees’ productivity and boost customer satisfaction. Trek is a big Office user, and Dynamics makes it easy to track email communication between Trek and dealers.
The Office-Dynamics CRM integration is a boon for Trek. “With CRM and Outlook integrated, you get all the tracking capabilities and tasks and calendar names that you get in Outlook, but you also get the reporting capabilities,” Peterson says. “So I can ask, ‘Where did you spend most of your time over last six months?’ or ‘Who were you doing most of your business with?'”
More recently, Peterson completed the computer telephony integration (CTI) aspect of the project, whereby Trek employees will get a screen pop whenever a dealer or customer calls. The screen that pops up contains the pertinent data about the Trek customer, such as upcoming birthdays and other pieces of CRM information that can help close a deal.
“When your account pops up, I can see what brands you’re carrying, I can see your address or any tribal knowledge about you, maybe your wife’s name or that your child is having a birthday,” Peterson says. “I can say, ‘Did you buy something for your son’s birthday?’ while we’re working to solve your issue. It’s all about creating a more personalized service.”
Since the CRM system went in, Trek’s customer service response time has dropped from a maximum of eight or nine weeks to an astounding 15 minutes, Peterson says. That eight or nine weeks is a worst-case scenario for how long it could take to solve an issue, but it does demonstrate how much more responsive Trek has become.