Using Zurmo to manage one or more bussiness processes seems easy but like any software implementation requires some serious thought. One of these choices may concern the use of existing modules rather then writing your own. It seems that this choice has some hidden pit-falls that need to be seriously considered.

Zurmo CRM - Using Existing modules

Zurmo is an upcoming CRM system with some great features. In the past I have worked with sugarCRM and vTiger and must say that Zurmo is a great improvement.

A lot of the flexibility in Zurmo is focused on the customization of existing modules. With the possibility to add fields, hide fields, change labels; the options seem endless. While great for fast and easy solutions it should be handled carefully. The structure of opportunities, leads, contacts and companies is well thought out and serves the purpose of managing the sales process.
In many cases a CRM system is used to manage a different company process or a similar process with it's own characteristics. It is tempting to use Zurmo's flexibility to model existing modules to specific needs. In my experience this process rarely works successfully (in any CRM) and will generally cause problems in the future.

In our specific case we use CRM packages to adminster the a process of employment seekers through steps several training steps with the final goal to match them to a permanent employer. We soon ran into problems when using the contact module to register employment seekers and opportunities to register vacancies.
The the jobs were coupled to companies which had contacts, which were of course very different from job seekers. Due to our design choice both types of contact had the same functional properties and dependencies. We tried using product to register job seekers but ran in to similar problems.

This dilemma is not new to CRM systems, the illusion of flexibility may lead to dangerous design choices that may lead to problems that are hard to solve once the CRM system is online and in use.

The causes for these problems seem to be:

• Perceived functional similarities between module and desired data. Contacts seem similar to job seekers, they are both persons.
• Functional similarities between processes: matching a job seeker to a job vacancy is not functionally the same as coupling a contact to an opportunity. This relation is probably meant to know who to contact with questions about the vacancy.

This does not mean that Zurmo is not able to handle these processes. It just means that the quick and dirty solution is not good enough in this case. Especially considering the focus of Zurmo on user experience. We want a CRM system to be as uncomplicated as possible, especially since any software system is often overwhelming and hard to use for new users. Hammering a module into a different shape is not the way to help this process along, it creates double and unclear functions. In the above project we ended up creating our own modules to suit our specific needs. A bit more work but a lot cleaner.