Whether off the shelf, on demand, or built in house with open source software, companies will need to customize their SFA systems
For the rest of the June 2007 issue of CRM magazine please click here
No matter the stripe or flavor, it's likely that that new SFA solution the company implemented won't do what the business needs it to do. This reality, while unsettling, isn't all bad: Tinker with the software a little, or let your consultants, vendor, or IT staff have a go at it, and a great SFA system can be created. The tinkering equates to configuring and/or customizing the system to the enterprise's unique uses. Whether it's as simple as making changes to the display or as advanced as integrating a new SFA application with an arcane financial system, customization is now almost expected.
Ten years ago buyers who signed off on a new SFA system knew they faced heavy lifting ahead, according to Jim Dickie, partner at CSO Insights (and a contributor to CRM magazine). With that in mind, buyers would bring in programmers or consultants in tandem with the new system. Those third parties adjusted the application's code until it ran exactly as the buyer needed--but that attitude won't fly today. "Now buyers ask, 'Why should we have to do this all ourselves?'" Dickie says. "Before, it was like they'd buy a car, but get only the car parts and they'd still have to assemble it themselves or hire someone. Now they're saying, 'Hey, when I get a car I want to be able to put a key in the ignition and have it work.'"
Survey 1,000 companies and you won't find two that use their SFA system the same way. A B2B's needs differs from a B2C's, or a business-to-retailer's from a straight retailer's, and so on (and on). No SFA vendor can cover all those disparate bases. None even tries. Still, today's systems can usually meet about 50 percent to 70 percent of any buyer's needs right out of the box, according to Dickie. Customization takes it the rest of the way.
Customizing and configuration is easier than ever because of the way software is written today. Now a system's varied functions are encoded each in their own layer, so the whole is built layer upon layer like a cake, rather than line after connected line of what the software industry not-so-affectionately calls spaghetti code. The layer cake means today's code is easier to get at and modify.
When you configure a system you make it your own without much tinkering with the actual code. You might change the number of options in a pull-down menu, say, or the number of fields within a report. Vendors expect their customers will make these common changes, which are easily made, with a little help from the buyer's IT staffers or systems administrator. True customization requires some expert knowledge of the code and makes for more advanced changes--for example, building a middleware link from an SFA system to a financial or ERP application.
We asked three consultants and researchers about the most common ways buyers make the systems their own, and break out costs and implementation time for the three main types of SFA systems on the market today: on demand, on premise, and open source. All vendor packages, whether vendor hosted, on premise, or open source, allow for most of these changes.
Make It Mine
Russ Lombardo, president and owner of Peak Sales Consulting, calls the most common alterations made the banal changes--which everyone wants. It's configuring the system to personalize its look. "If you can't do them, you don't belong in the SFA industry," Lombardo says. These types of configurations include doing away with unwanted icons on the screen, hiding, moving, or changing field names, modifying the contents of a drop-down list, restricting entry, specifying required and nonrequired fields, creating forms and records, and changing the way users navigate between screens.
Moving up a little in the configuration hierarchy, most companies make changes to their application's forecasting capability to reflect the way the system's buyer does business, Lombardo says. "The number of gates you need to go through to close the deal varies, and this can be programmed into the SFA system. You set it up so that you can't advance to the next gate until you've gone through the previous one."
Users also often change the way the system is programmed for sales callbacks. Because SFA systems are commonly integrated with email programs like Microsoft Outlook, companies can add a designated button to their SFA screen to take them from SFA immediately into the email program to send a reminder, according to Dickie. The way the system generates sales quotes, proposals, or sales contracts is often personalized to a particular company's style. Many times, companies set up their own report formats that follow the method they've always used. "Every company likes to report differently," says Barton Goldenberg, president and founder of ISM (also a contributor to CRM magazine). "Some have three columns, some have five; they're with or without comments; they're weekly or monthly."
These basic alterations are easy to make, as they mainly entail configuring the software just as you would with your home email account--or, for that matter, your iTunes program. The next step in SFA customization involves writing a short application-programming interface (API) that can automatically move select data from SFA to another software system. Let's take an example from the bad old days, when you walked a newly signed sales contract over to the legal department to let it have a look. Now, the SFA can automatically whisk it there for you courtesy of that API. But the way a contract winds its way through a company is unique to the company--it may need to move to the financial department before it makes it way to legal. The trail can be customized. Press a button, and customized middleware automatically moves it where it needs to go next.
"Everything having to do with how your application receives or sends data can be customized," Goldenberg says. Take AAA Mid-Atlantic. You're likely familiar with the emergency road service provider's business model. Your car breaks down, you pull off the highway and call AAA, which dispatches a tow truck. Your auto is reeled on and sprinted to safety. Though your first AAA contact was with the dispatching system, by calling for a tow you've created a customer relationship. AAA integrates its dispatching and CRM systems through a customized link, according to Goldenberg. The dispatch system populates the CRM system with the date and time of your tow as well as your phone number so a representative can follow up and make sure everything went smoothly.
For its customization job, Architectural Systems (AS), which sells flooring, ceiling, and wall covering to retailers, hotels, restaurants, and the like, has brought in the consulting firm Castle CRM. Anthony Castle, founder and CEO, is busy creating a gateway for AS's SalesLogix system from Sage Software, the Microsoft Dynamics SL accounting system, and the company's Web site, from which sales are often initiated. Integrating these systems will boost business by closely tying sales and marketing, according to Ronald Jackson, president of AS. Because sales information and accounting information hadn't touched in the past at AS, much of that information was duplicated in each system. Vendors were assigned two numbers--one for sales and one for accounting, which created confusion in both departments, Jackson says. "It was okay when we were selling $5 million, but now we're at $25 million and we need to support the growth."
This level of customization can be tricky. Jackson is presently defining his company's workflows so that Castle CRM can best tie the systems to mirror those workflows. "A lot of thought goes into it," he says. "I have a book about an inch and a half thick that I've been studying. We do this one time, so it's going to be right. We'll make enhancements and improvements along the way, but we're planning and [using] forethought to make sure everything is done correctly to improve efficiencies."
What follows is an up-close look at the way customization and configuration works for three main flavors of SFA--and like everything, each has its pros and cons.
First, on-demand systems, such as those from NetSuite, NextSale, Oracle, and Salesforce.com: With these you don't own the application--you are, essentially, renting it from the vendor, which hosts it on a server. The sales force taps into the system "on demand," via a broadband connection. Because the application exists in one location that any number of users access, the cost per user is kept down through the simple mathematics of supply and demand. And a user's IT department needn't be tied up installing and updating new software, because the vendor takes care of all that. But those cost advantages are a drawback when it comes to customization.
While basic configurations like changing the look of a screen or the name of a field are relatively inexpensive with these systems, larger changes can really add up, because the vendor owns the software. When a company does these big changes the vendor must create and host a version specific to that company. As not all its customers are tapping into the same application, the vendor's profitability goes down and it passes that loss on to the customer.
The second SFA system style, on-premise, relies upon a common business model. A company buys these applications outright, hosts them in house, and pays for upgrades. This is a common model, the same one you subscribe to when you pick up a copy of Microsoft Office for your home computer. With no hosting vendor to make the changes for them, buyers must do their own customizations. This option, offered by vendors like Microsoft, Onyx, Pivotal, Sage Software, and SAP, is great for companies looking for an SFA system that can be married to their business style. Because a company buys the software license outright, it can do whatever it likes with it.
Drawbacks here include expense and upgrade problems. Because these companies' IT departments need to do the customization, it can get expensive, though unlike the expense of on-demand systems, once a customization is done, it's done. Companies don't keep paying a higher monthly premium. Still, when it comes time to upgrade, they could lose previous customizations and have to reinvent the wheel. Large companies that bring in on-premise SFA systems to fit their unique needs can face expensive customization due to company size and amount of necessary changes. Customization on this scale can take a while to get up and running.
Sometimes a company has such a wild SFA process, according to Dickie, it needs to build a system completely personalized to the firm's needs. This is where open-source CRM software like offerings from SugarCRM comes in, Dickie says. "I've seen apps in the property and casualty insurance industry that need a detailed analysis of someone's current insurance policy in order to recommend what they should buy. Configuring this type of solution is so complex. They're selling 500 deals a year in 500 unique ways. The system is all custom."
Open-source code allows for easy customization--a company purchases the first 100,000 lines of debugged code and uses it as a base to build its own system. But that's the reason open-source customization is the most expensive of the options. Companies do it all. And don't forget about attendant costs, like expense for the training and documentation that must be written in tandem with the application, Goldenberg says. Companies going with this option will need to bring in skilled IT people. They'll need to remember that no customer support will be included should something go awry. "It can be a headache, it can be expensive, but if you need something suited exactly to your needs, open source can be the best option."
So in terms of expense, on premise is the least expensive choice for major customization and open source the most expensive. However, like everything, the devil is in the details. Not all companies will find that the expense progression holds. In terms of time, Goldenberg says, a major customization that would take between 30 and 90 days to create for an on-demand system would take about 60 to 120 days for an on-premise and about 90 to 150 days for an open-source system because of the extent the software needs to be tinkered with.
Like everything about a major technology implementation, companies need to first look at their needs--to the point of defining workflow as close up as Jackson is doing--to determine the amount of customization or configuration they'll need to do. With that information in hand they can then wade into the SFA vendor field to compare customization pros and cons.
Jean Thilmany is a freelance technology writer. She can be reached at Thilmanyj@yahoo.com.
|Learn more about the companies mentioned in this article in the destinationCRM Buyer's Guide:
Magic Quadrant for SFA '07: Oracle's Siebel has to share the spotlight in sales force automation, and additional challengers are closing in.
Magic Quadrant for SFA '08: Gartner's latest sales force automation report shows some movement, including some dropouts, as the research firm focuses on big business; Oracle and Salesforce.com top the field.
destinationCRM 2008: Whether it's Web 1.0 or 2.0, sales and marketing still need to communicate.
Sponsored By: Jacada, Avaya, Confirmit, inMoment and BoldChat
Sponsored By: Genesys, Avaya, Verint, and Aspect
Sponsored By: Informatica
Sponsored By: Verint®, Confirmit and inContact