I need a project! & Comments on Microsoft CRM
I should be working on an essay. School is winding down this week and and my last final is coming up. At work, there is nothing particularly interesting to work on. I am leading the way in developing an entirely custom interface for Microsoft CRM. Nothing particularly challenging. If you know of any hard programming problems or interesting ideas for software, LET ME KNOW!
The interface MSCRM ships is useless. The productivity of salesreps at my company has dropped at least 40% since we deployed MSCRM. I think what happened is Microsoft just plain decided to very rapidly develop MSCRM and ship it out. When you look at their original plans, this makes sense. MSCRM was supposed to be merely a platform, with third parties developing CRM applications on top of the platform. Apparently at some point they decided to build the application themselves and so the whole thing just feels rushed.
Frankly, if anyone out there is considering a CRM solution, stay away from MSCRM. It hardly provides any value for the investment. A half-decent web-developer could write a superior system in short order. What is the difference? You don't get a web-services API. You don't get role-based security. You don't get corporate support. You don't get exchange/outlook integration. You will probably get better search functionality. You will probably have an easier time integrating with your other systems. You will have a highly customizable UI (critical).
The web services get in the way more than anything else. The problem is that CRM never ever stands alone. It has to integrate with accounting and distribution management (at the very least). Want to search for customers based on how/what widgets they order? Good luck. You will have to ignore the webservices and query the tables directly (which in unsupported and loses the role based security benefit). THE MOST IMPORTANT point about MSCRM webservices though is that THEY AREN'T WEB SERVICES AT ALL. Want to call a webserice function? You need the Microsoft CRM dlls. You cant just hookup with the webserver the way you would with something like the google API or any other webservice. This is an absurd attempt at platform lock-in and holds zero value for the customer. Also, check out the paragaph below about integration for more reasons why web-services, as they are implemented in MSCRM, are Bad.
The role-based security is ok, though muddled. Take one part enterprise style security (company, divisions, vice presidents, managers, users) and one part small business application. Next, mix in a dash of very broad categories of security. For example, take your customer records. A given user can edit the record if the record is within their role (does the record belong to the user? the division? the whole company?). The problem is that merely "editing" a record is extremely broad. At my company, we would like to show the account's "Account #", a property of our distribution system. However, in MSCRM, if you show a field, that field will be editable. What if a user accidental changes the #? That will result in bad things like not being able to find the record and duplicate records (because at my company, new accounts in our distribution system are created in MSCRM). You may make a field non-editable through unsupported means, but then the whole reason you went with something MSCRM was to get support, right?
The support for MSCRM is silly. The only time you will ever call them is because you desperately need a feature that is not on their product roadmap. Good luck.
Exchange integration is also silly. Frankly, the way Microsoft recommends implementing it (that is, define a whole new subdomain exclusively for CRM) negates the whole benefit. You will need another exchange server (hardware $$$ and software $$$). Why not just deploy some free server for email? And for anyone thinking of getting MSCRM because of the Outlook integration, forget about it. They are integrated if your definition of integrated is "they are accessed through the same application through completely separate UI and almost no entities map correctly between the two applications and even when they do the mapping can be broken since one has significantly less functionality than the other."
The search functionality in MSCRM is horrendous. This is one area I could go into a lot of detail about. However, suffice it to say that whenever the question of improved search comes up (like in the Microsoft newsgroups), the inevitable answer is check out c360. More $$$. At my company, I have invested a very substantial amount of time implementing our own searching method.
Integrating with external systems is implemented in a useless way. Say you open up an account. The information for the account is broken up into tabs. Integration is accomplished by adding new tabs that point to web pages you develop. What if you want to show the customer's year-to-date sales on the main account screen? Good luck. The general answer to this is go check out scribe insight. Oh, and remember those wonderful webservices? Well, while you may not do any damage searching the and reading data directly from the database, it would be EXTREMELY unwise to directly write data. That's because the security system is implemented in a really strange way. Why does this matter? Because the maximum speed at which you can create/update records through web-services in MSCRM is about 10-15 records per second. You read that correctly. If you don't believe me, call up Scribe Software and ask them how fast insight is able to work with MSCRM. They will give you the same answer. Also, the 10-15 records per second is achieved only by using multiple-threads. If you know anything about programming, you know multi-threaded programming is much more difficult then single-threaded. <20 is the absolute maximum speed, regardless of hardware. This is caused by some bug/design in how MSCRM deals with it's own security. Last I read about this issue, there is no planned fix.
And then the UI. *sigh*.
The interface MSCRM ships is useless. The productivity of salesreps at my company has dropped at least 40% since we deployed MSCRM. I think what happened is Microsoft just plain decided to very rapidly develop MSCRM and ship it out. When you look at their original plans, this makes sense. MSCRM was supposed to be merely a platform, with third parties developing CRM applications on top of the platform. Apparently at some point they decided to build the application themselves and so the whole thing just feels rushed.
Frankly, if anyone out there is considering a CRM solution, stay away from MSCRM. It hardly provides any value for the investment. A half-decent web-developer could write a superior system in short order. What is the difference? You don't get a web-services API. You don't get role-based security. You don't get corporate support. You don't get exchange/outlook integration. You will probably get better search functionality. You will probably have an easier time integrating with your other systems. You will have a highly customizable UI (critical).
The web services get in the way more than anything else. The problem is that CRM never ever stands alone. It has to integrate with accounting and distribution management (at the very least). Want to search for customers based on how/what widgets they order? Good luck. You will have to ignore the webservices and query the tables directly (which in unsupported and loses the role based security benefit). THE MOST IMPORTANT point about MSCRM webservices though is that THEY AREN'T WEB SERVICES AT ALL. Want to call a webserice function? You need the Microsoft CRM dlls. You cant just hookup with the webserver the way you would with something like the google API or any other webservice. This is an absurd attempt at platform lock-in and holds zero value for the customer. Also, check out the paragaph below about integration for more reasons why web-services, as they are implemented in MSCRM, are Bad.
The role-based security is ok, though muddled. Take one part enterprise style security (company, divisions, vice presidents, managers, users) and one part small business application. Next, mix in a dash of very broad categories of security. For example, take your customer records. A given user can edit the record if the record is within their role (does the record belong to the user? the division? the whole company?). The problem is that merely "editing" a record is extremely broad. At my company, we would like to show the account's "Account #", a property of our distribution system. However, in MSCRM, if you show a field, that field will be editable. What if a user accidental changes the #? That will result in bad things like not being able to find the record and duplicate records (because at my company, new accounts in our distribution system are created in MSCRM). You may make a field non-editable through unsupported means, but then the whole reason you went with something MSCRM was to get support, right?
The support for MSCRM is silly. The only time you will ever call them is because you desperately need a feature that is not on their product roadmap. Good luck.
Exchange integration is also silly. Frankly, the way Microsoft recommends implementing it (that is, define a whole new subdomain exclusively for CRM) negates the whole benefit. You will need another exchange server (hardware $$$ and software $$$). Why not just deploy some free server for email? And for anyone thinking of getting MSCRM because of the Outlook integration, forget about it. They are integrated if your definition of integrated is "they are accessed through the same application through completely separate UI and almost no entities map correctly between the two applications and even when they do the mapping can be broken since one has significantly less functionality than the other."
The search functionality in MSCRM is horrendous. This is one area I could go into a lot of detail about. However, suffice it to say that whenever the question of improved search comes up (like in the Microsoft newsgroups), the inevitable answer is check out c360. More $$$. At my company, I have invested a very substantial amount of time implementing our own searching method.
Integrating with external systems is implemented in a useless way. Say you open up an account. The information for the account is broken up into tabs. Integration is accomplished by adding new tabs that point to web pages you develop. What if you want to show the customer's year-to-date sales on the main account screen? Good luck. The general answer to this is go check out scribe insight. Oh, and remember those wonderful webservices? Well, while you may not do any damage searching the and reading data directly from the database, it would be EXTREMELY unwise to directly write data. That's because the security system is implemented in a really strange way. Why does this matter? Because the maximum speed at which you can create/update records through web-services in MSCRM is about 10-15 records per second. You read that correctly. If you don't believe me, call up Scribe Software and ask them how fast insight is able to work with MSCRM. They will give you the same answer. Also, the 10-15 records per second is achieved only by using multiple-threads. If you know anything about programming, you know multi-threaded programming is much more difficult then single-threaded. <20 is the absolute maximum speed, regardless of hardware. This is caused by some bug/design in how MSCRM deals with it's own security. Last I read about this issue, there is no planned fix.
And then the UI. *sigh*.
posted by Abtin at 10:37 PM
0 Comments:
Post a Comment
<< Home