The Sage CRM development team are working to make sure that beyond the powerful core features that you'd expect from a modern CRM system we've got APIs that are open, standard-based, and free to developers and ISVs. We want our APIs to be used integrate Sage CRM beyond the Sage Business Cloud and become part of an ever expanding ecosystem.
For most customers and partners the need for development is on a small scale. It is typically focused on an integration with a business management solution or on adding a new entity within the system and generally these are relatively small projects with tight time frames.
The design of Sage CRM emphasises code-less customisation. It is a very easy tool to install, adapt and configure around a customer's requirements. A consequence of this is that many partners who do Sage CRM implementation are not coders by background. Some partners of course have been through IT courses at university or college and are very much skilled in coding. But most business partner staff would probably admit that they are not experts in coding but instead have expertise in other areas such as the installation and configuration of ERP and BMS (Business Management Solutions) systems, and have solid skills in analysis and business consultancy that allows the customer needs to be fully understood. The majority of business partners are also generalists and they typically have to perform multiple day to day roles. They may be creating a demo one day, installing CRM at a customer site the next, and logging a support call the day after.
Whether development in Sage CRM is approached using a traditional waterfall methodology or an agile development technique or even just using an informal ad hoc approach there are a number of very clear elements to a development that go towards determining the quality of the end implementation.
We can determine the features. We can decide to go for a big bang implementation where all features are added at once. Or we can go in an incremental way that allows both the business and partners to understand whether or not the assumptions and decisions that have been made initially are correct.
The decisions about features will impact the time and the necessary costs. And the reality of budgets will control the time that can be committed to the project and the eventual scope of the finished implementation. If the balance is not correct then it is the quality that will suffer.
And of course the aim of an implementation of Sage CRM is to provide an exceptional customer experience.
During the training course I asked how many of the participants were certified consultants. All of the class were certified and all of them had greater or lesser experience in delivering successful implementations of Sage CRM and all knew what a problematic project looked like. The participants observation were important and it allowed me to stress that all partners have some degree of expertise which allowed the participants to learned from each other as well as just listening to my more formal teaching.
Community Resources
One of the best ways that Sage CRM consultants who are approaching a development project can prepare themselves is to use the resources on Sage City and Sage CRM Community. These sites have many resources that are easily searchable. Possibly the most accessible way of making sure that skills and knowledge are up to date is to use the Sage CRM Playlist on the Sage Support and Training YouTube Channel and the Sage CRM eLearning platform. The Help Center contains links to all the essential PDFs and documents a developer may need whether these are the System Administrator Guide, the Developer Reference and the Implementation Workbook.
Project Pain Points
I have been thinking about the typical problems that a business partner may face when trying to help a customer. Especially if they are a relatively new member of the team and the customer's implementation is new to them.
The following represent some of the challenges that a consultant may face when familiarising themselves with a system.
- Upgrades! Systems are not static, they need to be changed.
- Existing code is not commented.
- No assumptions are stated.
- The Business purpose of code is not explained.
- The code is complex, disorganised.
- The customisation lacks consistency or conventions.
- The partner doesn't have access to the source files (.Net).
- The partner didn't make the changes.
- Business rules are divided between meta data and script.
Some of the problems creep in because projects just keep on growing. A little bit of code is added, and then a little more and then some more and before you know it you have a unmanageable beast that has grown beyond the understanding of the person next required to edit the code.
Some of the problems are specific to the way in which Sage CRM allows business rules to be developed. Partners may face a challenge trying to track down issues across the database, ASP pages (or .NET dlls) and JavaScript files.
And of course the customer may have a 3rd party component or Integration installed in their system; unpicking/editing/'fixing' that can be a pain.
In the following articles I will discuss more about these pain points and how they can be overcome by careful preparation.
Links to articles in series