This is a quick, useful video that describes some of the high level keys to a successful CRM implementation.
There are a many more things to consider that can sink an implementation ranging from technical, process and organizational issues.
However, the three things they identify are very important and worth highlighting. Find out more at http://www.salesforce.com/learn for more best practices.
Sunday, March 13, 2011
Tuesday, March 1, 2011
Go Native
One of MondayCall Solutions design principles is to go native wherever possible. "Going native" means using native, out-of-the-box configuration whenever and wherever you can. As long as you can meet the business requirements, the preferred method is to avoid writing custom code.
For those unfamiliar with building and managing systems, there are clearly pro's and con's to each approach. Going custom often gets you exactly what you want. After all, you are customizing it to your special needs. As your business requirements change, you also can continue to customize the system to meet your specific requirements. Going custom gives you ultimate control. Salesforce.com offers the Force.com platform and API's to give you that control.
Of course this is a double-edged sword. Customized solutions often take longer to build because you have to build many of the pieces yourself. In addition, customized solutions often take more overall maintenance effort, because changes to the requirements must necessitate changes in the customized solution. This can get very expensive as the system becomes more complex. I remember very distinctly one developer at a company who defended the "spaghetti" code that was written in their environment as "job security."
All is well and good until the requirements necessitate a major overhaul, or if the administrator of the system suddenly decides to take a job somewhere else. Without a deep investment, custom solutions tend to become more brittle and untouchable over time.
Using native functionality means a faster time to market. With Salesforce.com's SaaS platform, you will not only be able to maintain the system with greater ease but also be able to take advantage of the constant improvements made to the system. Not all changes will be welcome but most will. Salesforce.com after all is improving the platform based on customer feedback to stay competitive.
So wherever possible, go native. When you can't, and there will be times when you can't, then really evaluate its priority and scope and see if it is a good business decision. Still, the productivity, accuracy and information visibility you get from a well running sales, marketing and service infrastructure usually trumps the costs. If you do need to go custom, then keep things as simple as possible, build the things that you need now and if it makes sense, wait for the day that Salesforce.com adds the functionality so you can migrate to a native set up.
For those unfamiliar with building and managing systems, there are clearly pro's and con's to each approach. Going custom often gets you exactly what you want. After all, you are customizing it to your special needs. As your business requirements change, you also can continue to customize the system to meet your specific requirements. Going custom gives you ultimate control. Salesforce.com offers the Force.com platform and API's to give you that control.
Of course this is a double-edged sword. Customized solutions often take longer to build because you have to build many of the pieces yourself. In addition, customized solutions often take more overall maintenance effort, because changes to the requirements must necessitate changes in the customized solution. This can get very expensive as the system becomes more complex. I remember very distinctly one developer at a company who defended the "spaghetti" code that was written in their environment as "job security."
All is well and good until the requirements necessitate a major overhaul, or if the administrator of the system suddenly decides to take a job somewhere else. Without a deep investment, custom solutions tend to become more brittle and untouchable over time.
Using native functionality means a faster time to market. With Salesforce.com's SaaS platform, you will not only be able to maintain the system with greater ease but also be able to take advantage of the constant improvements made to the system. Not all changes will be welcome but most will. Salesforce.com after all is improving the platform based on customer feedback to stay competitive.
So wherever possible, go native. When you can't, and there will be times when you can't, then really evaluate its priority and scope and see if it is a good business decision. Still, the productivity, accuracy and information visibility you get from a well running sales, marketing and service infrastructure usually trumps the costs. If you do need to go custom, then keep things as simple as possible, build the things that you need now and if it makes sense, wait for the day that Salesforce.com adds the functionality so you can migrate to a native set up.
Subscribe to:
Posts (Atom)