4

我的组织正处于获取 CRM 4.0 以用作通用软件开发平台的最后阶段。卖给我们的公司已经说服高层管理人员相信 CRM 将解决我们所有的生产力问题,并使软件开发变得像点击一样简单。(他们不读布鲁克斯。)

在接受了我无法阻止 CRM 被强加给我们开发人员的事实之后,我一直在研究如何管理大规模 CRM 开发的复杂性。

到目前为止,我已经确定了以下需要解决的复杂性:

  1. CRM 似乎与基本的配置管理实践完全不兼容。
  2. 使黑盒 CRM 数据库与外部 LOB 系统保持双向同步对于项目成功来说既困难又关键。

在构建大型 CRM 应用程序时,我还必须考虑哪些其他复杂性?

CRM 作为开发平台有哪些限制?

编辑:主题提供了额外的见解。

4

3 回答 3

5

我使用过 MS CRM 3.0,现在是 4.0,这是我的看法:

  1. 尽可能关注标准的最佳实践。不要对 CRM 正在做什么或希望您做什么感到过度困惑。

  2. 不要害怕破坏 MS“支持”的东西。对 2 个主要因素有一些警告 - 贵公司是否会让您跳出框框思考以解决问题并进行不受官方支持的自定义/集成?- 你对 .Net、SQL、javascript 等是否足够熟悉,可以编织他们的代码并实现你需要的东西?

    有时,当对此处的 js 文件的一个小调整或那里的一个小的 db 修改给了我所需的东西时,我有时会尝试以“受支持”的方式做某事 100 次。

  3. 如果与其他 LOB 应用程序的持续数据集成至关重要,您应该考虑使用 Scribe ( http://www.scribesoft.com/ )等第三方工具。它并不便宜,但在与您的其他 LOB 应用程序集成时,基本上可以让您获得 90% 的成功。

  4. 作为一般规则,MS CRM 非常擅长联系人管理 - 执行诸如跟踪约会、进行邮件合并等操作。您能否将其用作您的核心 HR 系统 - 可能。财务系统 - 可能有点困难。您离执行联系人管理的核心能力越远,您需要做的自定义工作就越多。如果 MS CRM 是解决该问题的正确解决方案,您必须做的定制工作越多,您应该考虑的越多。

于 2009-07-14T02:23:41.123 回答
4

我知道您可能正在顺利部署 Dynamics CRM,但只是一些快速提示:

  • 我会避免进行不受支持的更改,纯粹是因为最终很难跟踪更改。由于 Dynamics CRM 允许开发人员制作 C# 插件并访问 Web 服务,因此通常不需要对任何不重要的事情进行不受支持的更改。另外,如果您必须致电他们的支持,您就必须向 MS 隐藏更改。我知道很多人会包含外部 javascript 文件(jquery 等)和其他一些良性的更改,但是当不受支持的编辑涉及任何非视觉内容时,请尝试在精神上阻止自己。

  • 查看 Microsoft Dynamics Xrm 这句话,有几本关于这个主题的书非常好,http://www.thecrmbook.com/特别好,因为它带有一些很好的自定义代码,可以与您的 CRM 一起使用。

  • 源代码控制您的自定义 xml,不要让人们接触数据库,还有 Google Halan CRM 工具,并使用它来编写 CRM 自定义和 javascript 文件的脚本。比编写自定义 powershell 脚本来完成相同的工作更容易。

于 2010-04-15T14:59:07.803 回答
2

交易支持

如果您的应用程序需要来自底层平台的事务支持,Dynamics CRM 不是正确的选择。原因是目前 Dynamics CRM SDK Web 服务不支持事务。

参考线程在这里:MSCRM Web 服务是否支持数据库事务?

由于您希望使用 Dynamics CRM 作为平台,这意味着所有业务逻辑都应使用 Dynamics CRM SDK Web 服务作为数据访问层。但是想象一下,如果没有事务支持,并且您正在调用一系列 Web 服务调用作为一个工作单元,并且其中一个 Web 服务调用失败。这意味着您可能会遇到数据完整性问题。

配置

通常我会创建一个名为 Configuration 的自定义实体,它将存储当前 CRM 应用程序所需的所有相关配置。创建完成后,您可以使用 Dynamics CRM SDK Web 服务从配置自定义实体中读取所有必要的配置

于 2009-07-07T23:21:45.167 回答