使用 CRM 还是不使用 CRM (MS)？
我们在工作中使用 MS Dynamics 4.0 来管理 CRM。它处理所有联系人管理、营销、带有共享点集成的资源共享、工作流程管理/协作，并且本质上由公司中的每个部门以某种方式使用。
我们收到了业务对新应用程序的要求，而且我们的时间表很紧。我们才刚刚开始推出 CRM，大部分定制开发都是由咨询公司完成的。
我们需要一个相对简单的应用程序，我们需要跟踪一些数据以供特定组共享。其中一些信息已经存在于我们的“公司”和“客户”CRM 实体中。
这个新项目需要我们添加大约 26 个字段 - 我们不想让我们已经很大的公司实体变得臃肿 - 特别是因为只有大约 5% 的公司会使用这些额外的字段。
我们现在基本上正在讨论一种设计 - 混合解决方案（创建我们自己的 ASP.NET 应用程序，它看起来像 CRM，并通过 Web 服务与其进行通信，并将所有“补充”字段存储在我们自己的数据库中，可能位于同一数据库服务器上作为我们的 CRM 数据库，以便我们可以轻松编写查询）。另一种选择是 100% 在 CRM 中实现。
我只是为做过类似事情的人寻找建议。您会建议采用这样的混合解决方案还是我们应该采用 100% CRM？我们的期限很紧，而且参与该项目的开发人员的 CRM 知识有限；这就是为什么这是一个有点争论的原因。对于那些使用 MS Dynamics 的人来说，您通常会如何处理这样的项目，我们需要添加许多字段（甚至是具有自己的父子关系的子字段），而这些字段仅适用于很小一部分我们的主要“公司”实体..需要注意的是：当人们按原样加载该公司实体时（页面可能需要 5 秒才能呈现），我们已经遇到了性能问题，高级查找也是如此。
最后要注意的是 - 应用程序的这一部分仅用于存储数据。最后，用户将打开一个 VBA Excel 工作簿，按下“下拉数据”按钮，该按钮将从我们最终存储的位置提取该数据。我们只是不确定应该在哪里存储/管理这些数据/用户界面。
非常感谢您的任何建议。
编辑：如何创建 2 个彼此相邻的列表框，中间有 2 个按钮，其中一个列表框丢失了“我的 foos”，另一个列表框是“所有 foos”，然后您添加/删除来自“我的 foos”列表框？？？经典的“我有这些 foos 作为我的一部分”UI 控件，带有 2 个列表框和 2 个箭头按钮...我应该/可以使用 jquery 吗？是否有人碰巧知道任何 jquery 控件已经可以开箱即用地完成所有这些操作？这是一个非常常见的控件，我确信它一定在某个地方。我浏览了一些工具包和控件以及这里的一些线程，看到了一些非常棒的、甚至更复杂的控件，但不是这个特定的..
EDIT2：在做了更多研究之后，似乎将 UI 全部保留在 CRM 中会比只为该部分制作 ASP.NET 应用程序并将其放入 CRM 中的 iframe 或模态弹出窗口中更复杂。
我们仍然可以在 CRM 中设置所有数据字段和关系 - 并让 ASP.NET 使用 Web 服务调用执行 CRUD。
看来我们最终不得不这样做获得 CRM 所需的功能所需的工作量相同 - 只不过它会更加 hackish 并且是用 JavaScript 完成的。有什么好处？将用户界面保留在一处？？？在我看来，这并不是一个太大的权衡...
到目前为止，我们倾向于将所有数据保留在 CRM 中，但将 UI 放在 ASP.NET
<强>非常感谢任何建议。我说的有道理吗？谢谢
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
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我同意，您最好采用 100% CRM。
如果（我强调如果）您发现性能影响很大，请考虑使用相关实体来保存附加字段。
CRM 不提供一对一的关系类型，因此您必须自行管理。将您的公司实体设置为关系的 N 方，以便相关实体显示为查找。
或者，如果相关实体查找对于您的用户来说过于抽象，请将带有 iFrame 的选项卡添加到公司实体表单中。使用 javascript 显示/隐藏选项卡，并将 iFrame 的 src 设置为相关实体的 url。
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.
我会使用 CRM 来存储数据。您可以将新字段粘贴在 UI 中的单独窗格中，这样就不会混乱。您甚至可以向 UI 添加一些 Javascript，以对不属于需要它们的组的用户隐藏窗格/字段。我知道这听起来有点黑客风格，但这比开发一个完全不同的应用程序要少得多，而且用户将获得一致的体验。将数据集中在一个地方对于报告等也有好处。
我不能肯定地说，但我不认为向一个实体（已经有无数列）添加几列会进一步恶化性能。我会检查安装并检查常见的性能缺陷。
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.
创建 ASP.NET 应用程序以在 iframe 中创建复杂的 UI 是一个简单的解决方案，我经常在 MS Dynamics CRM 中使用该解决方案4.0应用程序。
将所有数据保留在 CRM 中很有意义，但可以按照您想要的方式设计 UI。
iframe 使用包含实体 GUID 的查询字符串调用 ASP.NET 应用程序，以便您可以使用 Web 服务提取任何相关信息。
您可以使用 JavaScript 修改表单上显示的字段、直接更新数据库或同时执行这两种操作以保持一致性。通常，隐藏 ASP.NET 应用程序中正在更新的字段会更容易，这样就不会造成混乱。
很久以前的一个例子是我为销售代表可能拥有的机会的 iframe 构建的贷款抵押计算器。它将找到客户的所有相关贷款余额并计算不同的选项，然后销售代表可以将这些选项转化为报价。单击几个复选框，然后按一个按钮，无需重新输入大量信息即可完成。数据被写入许多 CRM 实体，生成电子邮件，并且自动拨号列表将被修改，以便不再致电该客户。
学习使用 MS CRM 作为大型开发工具箱是能够实现一些严肃的业务流程自动化的第一步。
如果您有任何疑问，请告诉我。
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.
我知道这不适合您的情况，因为您对 MS CRM 很深入，但是 Neal Ford 写了一篇很好的文章，最近发布到 IBM Developer Works (http://www.ibm.com/developerworks/java/library/j-eaed10/）讨论 COTS 与自行开发软件。这是一个片段。
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.