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.
Because of this there is no real programming for me to do. This frustrates me. I did manage to write one plug-in which integrates with CRM to perform a specific task. I have also had to write some Javascript modules which interact with the CRM system. But in both of these cases, the limitations and requirements of developing for this system are PAINFULLY frustrating. Something that can be coded in a few minutes to the exact requests/specifications of our users takes hours (perhaps days) to implement. Worse the implementation is almost always not exactly what the users want (sometimes, we have to admit that what the user wants can not be done in 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. Although Scribe is a separate product from a separate company, the vast majority of CRM installations use Scribe as their data importing/exporting tool. 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.
Have you considered taking the database admin aside and asking if he’d be interested in building a custom solution?
Obviously rebuilding a CRM from the ground up is a huge undertaking, but it sounds like the company you work for has the capital. Working on it, on your spare time at home, weekends etc.
The reason I ask is this. I had a friend that recently ran into a similar problem with a company he was working for. Big fortune 500, that only dealt with ‘name brand service providers’. They were integrating the Oracle CRM into there system and it was one of the most painful processes known to man.
However, he kept notes as he was working on the integration process, he learned from it and built a better solution. Now he’s got a new office, title, and some serious stock options.
Just a thought 🙂
Thanks for reading my rant!
I think my approach is going to be to create a parallel site to provide a solution for the stuff that “can’t be done” in the standard CRM interface. That way we can at least provide an alternative for the users who currently can’t get what they need from the system.
As for the DB, the DBA and I have already started “pondering” what it would take to bypass Scribe and use a solution similar to what the consultants are going to be integrating for our sister company.
Still, I don’t know why we need to go to these lengths to get an acceptable solution from a product which costs as much as this one does.
The answer to your question is that you don’t need to go around Scribe. If it’s not working for you then 1) your hardware is inadequate, 2) your network is inadequate and/or 3) whoever set up Scribe did not do so effectively. What makes you think that it is Scribe’s problem? It sounds like whoever set this up for you does not know what they are doing. Also, you stated that Scribe comes with Microsoft CRM from Microsoft and maybe your consulting company told you that but that just gives me a hint that they either blantantly lied to you or they really have no idea what they are doing since Scribe is a completely separate company and does not come with Dynamics CRM. With that said, it is the best tool on the market for doing this if configured properly in a properly scaled environment.
Before you waste a lot of time trying to ‘fix’ something you really don’t know well yet, you might want to explore all that the SDK can do for you with web services, Silverlight, HTML, and custom .net pages that are fully integrated and embedded into the CRM system.
Before completely blaming the product for what you feel are major shortcomings, you may want to really learn all that it can do and how it can be extended using the tools you prefer to be using.
Thanks for reading my rant!
As I mentioned in the article, yes, I will be using the CRM web services to do “the work” when/if I use different interfaces to fill-in what I can’t do in the CRM UI that comes out of the box.
As for my Scribe problems:
The hardware/network is more than adequate: a dedicated box for the DB and a dedicated box for Scribe. Each box has 4 CPU x 4 Cores at 3.6GZ;96GB of RAM; and they communicate with each other on a Fiber subnet dedicated for server-to-server use.
Our consultants are featured PROMINENTLY on the Microsoft Website and the Scribe website as well (although not as prominently as on the MS site).
But you are correct that Scribe is separate from CRM. They are two different products from two different companies. That being said, Scribe is used in over 90% of CRM installations that have data import/migration needs. So, by default, if you have data migration/integration needs, you will get Scribe, unless you (or your consultant) specifically ask for something else (source: Scribe/MS Tech sales support phone calls I made yesterday).
I did speak with our DBA to get a more detailed description of the problems that we are having with Scribe. Specifically, our problem is that Scribe hangs on imports intermittently (not horrible in itself), but when it hangs, it leaves in place a table lock on the Organization table, which makes the entire system unusable until the Scribe process is killed and the locks released. It seems that Scribe has been contacted about this and they are working with our consultants/us in trying to diagnose the problem.
Nonetheless, I do appreciate your input/comments above. Obviously Scribe works well for most people. It wouldn’t still be around if it didn’t. But in my particular installation, we are having problems. That’s why our sister company will be writing their own import/migration tools for their use and we may roll those tools over to our installation in the future.
Again, thanks for your input!
Sorry to hear about your issues with Dynamics CRM.
I wanted to inquire have you ever tried working with SQL Server Integration Services? It is a complete ETL platform which is part of the SQL Server license. It is very powerful platform and contains alot of good transformations standard. The company I work for COZYROC delivers third-party extension library of tasks and components for SSIS. The product is called COZYROC SSIS+. The library includes Dynamics CRM adapters. All CRM deployment types are supported – Premise, Live, Hosted, Federation. The product has been available commercially since Aug, 2010 and is already deployed in production in many organizations. The starting price for the library is $399.95/Year.
I hate this technology so much. I just recently 3 monthes ago got scammed into taking this stupid position when i thought it was a .NET position. My company is trying to build a space shuttle out of this and we have like 50 plugins. These plugins are so flaky, the code is all correct, but there are bugs in the CRM plugin execution environment itself. Things that I can do in 2 minutes with .NET take 2 days. Debugger is a pain as it doesnt 100% work. Debuggin takes 6 steps to set up and compiling take 5 minutes due to ILmerge. Testing javascript requires a publish which is a pain. All you are doing is databasse read and saves and nothng else. talking about great experience.
Doesnt help when my dumb manager that doesnt know scratch about code think’s he is the final resource. I quit this stupid job and my last day is in 3 weeks because I am nice.
Why the hell would they hire a .NET developer for these kind of jobs? It’s totally not related, I might as well pursue a career in acting.
I’m sorry that you had to go through this. Personally I am determined never to work with this technology again. However, just in the last two days, I have received several inquiries about my availability for a project in my area (probably the same project that I left last year).
I am surprised that so many companies continue to use this product. In the case of the company that I worked at last year, a custom coded solution would have been better and at a much lower cost. But it is hard for a business to ignore the Microsoft logo on the product brochures.
Thanks for your empathy Thomas. I hear that the situation with sharepoint is the same. With my previous company, it is the fact that they do not have any front end web skills. It doesn’t matter if I have the web skills and am able to produce a MVC application as a replacement within 3 months with the exact same functionality at a lower cost since I don’t have a tattoo of a Microsoft logo branded on my forearm.
Anyways, the pain is over for me but I just have a hard time understanding why name and brand is so important when they are pouring money into this stupid project with expert dev leads leaving on a monthly basis.
I really hate MS CRM 4.0 and 2011. I come from a desktop app development background.
The problem with MS CRM is that it gives people too much hope on what it can do. It does not tell people how much effort is involved to achieve so. Plugins are slow to debug, Java scripts are even worse. A small problem takes days to resolve because of it.
Simply put it, customziation in MS CRM is very maintenance intensive.
Thanks for sharing your thoughts. Maybe some day, MS will try to address all the problems that this technology has.
I am involved in purchasing a CRM for my company. I am tired of hearing sales BS so I googled “I hate Microsoft CRM” and here I am. I recognize the issues that you have put down here and I am definitely going to address the Scribe thing.
I am a fan of making our own tools, personally. We are using a dinosaur right now called Telemagic – it’s basically a flat file database done in FoxPro. I could do better but, I am swamped and the company has basically decided to buy a CRM. When you do that, you are going to end up letting the software shape how you conduct business. I have seen ERPs cause luny behavior that makes no sense out in the shop because that’s how we have to do it to appease the software. I was in a position to refuse that behavior, and I did. I know ERP isn’t CRM, but the concept is the same.
We too, would like to build a space shuttle out of our CRM. Nobody will admit this, but I know what they are going to want and I know CRM doesn’t come that way out of the box.
At least we are not into having it hosted remotely, that seems like a patently bad idea.
Question is: Who does it better? Or are these issues you bring up just a consequence of buying commercial software and trying to bend it to your will?
Looking back on this after more than a year, I can conclude that the single biggest problem was the combination of an IS Director who was more than willing to work with an almost-corrupt consulting group to force an MS solution where a custom application would have done the job better.
Had the consultants been a bit more ethical, things could have been different. But they weren’t.
For as much money as was spent on this implementation, custom software could have been deployed and updated. Twice.
“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). ”
Have you ever used Scribe? Seems not ever.
This expression is kind of misleading. Scribe is developed by Scribe Software and must be purchased in addition, while SSIS is something delivered with MS SQL Server and also is used for integrations.
Alex,you are correct. Technically, Scribe and Dynamics are separate products from two different vendors.
However, the plain simple truth is that Scribe and Dynamics CRM are OVERWHELMINGLY distributed together. In my experience with Dynamics CRM, Scribe was present at every installation. Every. Single One.
The reason for this is that CRM is usually initially installed by a third party integrator who specializes in MS Dynamics CRM. These integrators overwhelmingly “push” Scribe as part of their package. Customer Effective, a leading integrator is proud of the fact that they have installed Scribe at “ninety five percent” of their installations (source).
So while you are right that Scribe and Microsoft Dynamics CRM are not sold by MS as a unit (and I will update my text), I stand by my assertion that the two products are a de-facto single unit at time of installation in the overwhelming majority of the time.