To CRM or not to CRM (MS)?

We use MS Dynamics 4.0 at work for our CRM. This handles all contact management, marketing, resource sharing w/ sharepoint integration, workflow management / collaboration and essentially is used by every department in the firm in some way or another.

We have requirements from business for a new application that we have a tight timeline on. We have only just started rolling out CRM, and most of the custom development was done by a consulting firm.

We need a relatively simple application that we need to track some data for sharing for a specific group. Some of this information already lives in our 'company' and 'client' CRM entity.

This new project would require us to add around 26 fields - we don't want to bloat our already large company entity - especially since only around 5% of our companies would use these extra fields.

We are basically debating a design right now - hybrid solution (create our own ASP.NET app that looks like CRM and communicates to it via web services and store all the 'supplemental' fields on our own database, possibly living on the same DB server as our CRM DB so we can easily write queries). The other alternative is to do it 100% in CRM.

I'm just looking for advice for people who have done something similar to this. Would you recommend doing a hybrid solution such as this or should we do 100% CRM? Our deadline is tight and the developers working on the project have limited CRM knowledge; this is why it's a bit of a debate. For those working with MS Dynamics - how would you typically handle a project like this, where we need to add many fields (and even sub fields with parent->child relationships of their own) that would only apply to a very small percentage of our main 'company' entity.. something to note: we are already having performance issues when people load up this company entity as is (it could take 5 seconds for the page to render) and the same goes for advanced finds.

Last thing to note - this portion of the application is only for storing the data. In the end, the user will be opening a VBA Excel workbook, pushing a 'pull down data' button, that will pull this data from wherever we wind up storing it. We just aren't sure where we should store/manage this data/UI.

开发者_运维百科Thanks very much for any advice.

EDIT: How can I create 2 list boxes next to each other with 2 buttons in the middle where one listbox is a lost of 'my foos' and the other is 'all foos' and you add/take away from 'my foos' list box??? the classic 'i have these foos as part of me' UI control with 2 list boxes and 2 arrow buttons... Should/can I use jquery for this? and does anyone happen to know of any jquery control that already does all of this out of the box? This is such a common control I'm sure it must be out there somewhere. I've browsed some toolkits and controls and some threads on here and seen some really awesome, even more complicated controls but not this particular one..

EDIT2: After doing more research, it seems like keeping the UI all in CRM would be more complicated then just making an ASP.NET app for that portion and putting it in an iframe or modal popup in CRM.

We can still setup all the data fields and relationships in CRM - and have the ASP.NET do the CRUD using Webservice calls.

It seems we would wind up having to do the same amount of work to get the functionality needed in CRM - except it would be more hackish and done in javascript. At what benefit? Keeping the UI in one place??? Not that much of a trade off IMO...

so far we are leaning towards keeping all data in CRM but putting the UI in ASP.NET

Any advice is greatly appreicated. Is what I'm saying sane? Thanks

I agree, you're better off going with 100% CRM.

If (and I stress if) you find the performance impact is significant, consider using a related entity to hold the additional fields.

CRM doesn't provide a 1-to-1 relationship type so you'll have to manage that yourself. Make your company entity the N side of the relationship so the related entity appears as a lookup.

Alternately, if the related entity lookup is too abstract for your users, add a tab with an iFrame to the company entity form. Use javascript to show/hide the tab and also to set the src of the iFrame to the url of the related entity.

I'd use CRM to store the data. You can stick the new fields in a separate pane in the UI so that it won't clutter. You can even add some Javascript to the UI to hide pane/fields from users who are not part of the group that requires them. I know this sounds a little hacke-ty, but it's a lot less work than coming up with an entirely different app and users will get a consistent experience. Having the data in one place is also a boon for reporting and such.

I can't say for sure, but I don't think adding a few columns to an entity (which already has a bazzilion columns) will deteriorate performance much further. I'd go over the installation and check for the usual performance pitfalls.

Creating ASP.NET applications to create a complex UI in an iframe is a simple solution that I use frequently for MS Dynamics CRM 4.0 applications.

Keeping all of the data in CRM makes a lot of sense, but make the UI however you want it.

The iframe calls your ASP.NET application with a Querystring containing the entity's GUID so that you can use web services to pull any related information.

You can both modify the fields showing on the form with JavaScript, directly update the database or both for consistency. Frequently it is easier just to hide the fields being updated in the ASP.NET application so there is no confusion.

An example from a long time ago was a loan morgage calculator that I built for an iframe of an opportunity that a sales representative would have up. It would find all of the customer's related loan balances and calculate different options that the sale representative could then turn into a quote. Click a few check boxes, and press a button and they were done without having to rekey a lot of information. Data was written to a number of CRM entities, emails were generated and the autodialer list would be modified not to call that customer again.

Learning to use MS CRM as a big development toolbox is the first step to being able to do some serious business process automation.

If you have any questions let me know.

I know that this doesn't fit your situation as you are deep in MS CRM, but there is a good article by Neal Ford that was recently posted to IBM Developer Works (http://www.ibm.com/developerworks/java/library/j-eaed10/) that discusses COTS vs home grown software. Here's a snippet.

One of the common questions that arise in big companies is the decision whether to build or buy: for the current requirements, should we buy COTS (Commercial Off-the-Shelf Software) or build it ourselves? The motivation for this decision is understandable — if the company can find some already written software that does exactly what's needed, it saves time and money. Unfortunately, lots of software vendors understand this desire and write packaged software that can be customized if it doesn't do exactly what the client needs. They are motivated to build the most generic software they can because it will potentially fit into more ecosystems. But the more general it is, the more customization is required. That's when an army of consultants shows up, sometimes taking years to get all the custom coding done.