As you may have read in my other post Too Many Changes I recently got a new job.
In this new job, I will be the Administrator of an installation of Microsoft Dynamics CRM (Customer Relationship Manager). The Microsoft CRM product is a popular product in which there are not a lot of choices for larger companies. It has some interesting features. But mostly, it has been a series of one frustration after another for someone who comes from a programming background. I do realize that most of my frustration has come because I have not yet learned how to do what I may be wanting to do. But still, there are problems with CRM that are truly problems. Where to start…..
At my new company, a consulting group has been in place for over a year, mapping out the business of the company and how it will be represented in the CRM system. This consulting group has built-out a large portion of the implementation of the system. Most of the pieces are in place and it will be my job to polish things as needed once the consultants leave.
My problem is that the customizations available to the end users (my company) are limited to what the CRM can support. Basically, we have to map the business of the company using tools and concepts that are supported by CRM. We are not modifying CRM to meet the business model of the company. That is the first problem:
We’re adapting our business to suit the limitations of CRM.
The system that the company used previously was an open source system. So if a custom page/form was needed, it was coded up using normal .NET/ADO code and the user’s requests were met exactly. Those days are gone.
Basically, I am a power user. Not a developer.
As bad as I feel I have it, my “pain” is nothing compared to the pain felt by the DBA (Database Administrator) with whom I’m working.
CRM uses a thrid-party tool named Scribe to perform large data importing / exporting tasks (it’s not really a third-party tool since it is also provided by Microsoft as part of the CRM installation). Scribe can interact with CRM during imports so that CRM events are fired as data is imported into the system. But Scribe does not appear to be well-behaved. Often, our database is slow or non-responsive. In every case, it has been due to Scribe locking up our system or hanging our server. In fact, the consulting team that is installing our system will not use Scribe to perform a CRM installation in a sister company. Instead they will be developing a custom application as a replacement for Scribe to import data. But still, we will have to suffer with Scribe to perform our bi-weekly data imports. This will be a painful experience for our DBA with no relief in sight.
We have been given a tool that doesn’t work well and which has been abandoned by the consultants who put our current system together.
Is there any solution to my concerns? Of course. I’m a programmer. Anything you or I can think of can be coded up, given an environment that will support it.
Our current environment consists of several virtual servers onto which Windows Server 2008 software has been installed. The .NET framework is installed on to these servers. SQL Server has been installed onto a supporting server. So everything is in place to support a truly customizable web application to supplement/replace the parts of our CRM installation that just don’t work well.
In CRM 2011, the bulk of the work is done using web service calls from the client-facing web server to an application server. Were we to replace the bad web application with customized web forms, we would be able to meet our users’ needs completely. All the limitations imposed by the CRM web application could be eliminated. All while using the security provided by CRM.
We could build a custom application that meets the needs of our users. But we can’t.
Our management team is sold on anything that has the word “Microsoft” on its shiny, shrink-wrapped cover. So all my suggestions on how to improve our users’ experience have been cast aside in favor of the “they will get used to it” attitude from our IS Director. They have spent several million dollars on consultants to install a system that just doesn’t work well. They could have spent less money on a team of developers to put together a system that meets all their needs exactly. Instead they chose a shrink-wrapped system that only meets some of the needs of our users.
And I have to make it all better.
A challenge to be sure. Time to get to work. Updates to follow.