关于MS Dynamics AX 和 MS Dynamics CRM实施

Posted 2023-04-26

想请教一位高人，如果 MS Dynamics AX 和 MS Dynamics CRM 都准备实施，而由于各方面原因，只能先实施一个，再实施另外一个的话，应该先实施哪个？
另请高人给点宏观上的介绍和指导，想知道二这之间的关系（好像是CRM是ERP的一个模块，但强于那个模块），谢谢。
到处复制粘贴的就算了，谢谢。
是我说的不是很明白，我的意思是，所有前提都一样的话，先实施哪个好点，也就是，先实施哪个，让下一个实施起来稍微方便点，无论是入手，还是配置。
打个比方，就像一个人想学数学和物理，又只能一门一门的学，我会推荐他先学数学，后学物理，因为数学学好了，一是逻辑思维好，二是运算基本功强。

取决于业务需求，而不是系统本身。AX是ERP，主要管理内部资源，如库存、生产、财务；CRM主要管理外部资源，主要是客户及围绕客户的流程。
先实施哪个，看业务部门的迫切性，软件是一个工具，无所谓先实施哪个，只是实施时，要考虑到未来可能会涉及到接口的地方，如产品、订单、客户，这些要注意编码规则尽量提前统一好，避免两套规则。 参考技术A 个人建议先实施AX，基本是ERP是必须要有的，而CRM只是锦上添花的效果。
CRM也很重要，但没ERP重要。

ERP需要管理起公司所有部门业务和问题，在去解决客户生命周期中的问题和加快客户签约。 参考技术B 本人是做SAP软件销售的。之前曾在微软的MBS任过职。对于您提的这个问题，我觉得。。。怎么说呢？我觉得。非常。。。。
先说一下原则吧，不管是ERP也好，CRM也好。或者其它任何系统也好，都得要有一个全面的规划。所谓不谋全局者不足以谋一隅也是这个道理。总体来说，应该是业务驱动是软件的主流。
这又引出另一个话题了。什么是业务驱动，以及业务如何驱动？系统是起支撑做用的。CRM——ERP——PLM——SCM等等，不管什么软件和系统。。都得产生业务上的闭环，打通各部门的关节。实现整体的运营效率。
不知道我说这些对你有帮助没有。另外，我很好奇的是，你的软件服务商没有为你们的系统做整体规划吗？如果真的已到了实施阶段了，应该早就有完整的计划和规划了。还会产生这个问题纠结吗？我疑惑 。。。。。。 参考技术C 无论从哪个角度讲，一定是先MS Dynamics AX啦

Dynamics 365-关于Solution的那些事

　　这一篇的内容，是关于Solution的使用建议的，如果大家一些实用的建议，欢迎留言讨论。

　　一. 版本控制

　　Solution是有版本号的，率性的人可能在新建一个solution的时候，直接赋值1.0，就不再管了。但是这里还是简单说下MS风格的版本号，一般是用.分隔的四个数字：主版本号.子版本号.编译版本号.修正版本号。后面两个版本号可选或者互换位置，前面两个必须。建议迭代周期，要做好Solution版本号的设计和管理。这方面的好处不多赘述了，毕竟不管是不是开发，都能想得明白。

　　二. 分门别类

　　分类其实是为了更好对Solution进行管理。我们知道CRM有不少类型的Components，而在Solution里，如果你把所有的Components都放到一个Solution里，你会发现越到后期，你的Solution就越难维护。那么是不是我把components从数量上简单地拆分开就可以了呢？比如我把很多的workflow，plugin，Entity拆分到多个Solution里。并非如此，这里说的分门别类，一般可以从这几个方面考虑：

　　1. component本身的类型

　　2. component涉及的业务：包括业务逻辑，业务部门

　　3. component的依赖关系

　　4. component的数量

　　5. component与项目迭代的关联

　　现在MS的产品，走的是模块化的设计理念，那么这个模块化，我们应用到Solution里，也是一样适用的。比如你要考虑，哪些Solution可以规划成一个“模块”，如果部署之后，将来客户不要了，可以在不影响当前业务的前提下直接删除（看现在的AppSource里的Solution产品，都是可以在不影响环境结构的前提下，实现Solution的导入和删除的）；哪些Solution是属于xx部门的，即使以后Solution有更新，也可以在不会影响其他部门业务的前提下实现更新；哪些Solution对其它的Solution有依赖，而被依赖的Solution是不是设计的比较Common等等。

　　三. 下载日志

　　一般情况下，Solution导入成功或者失败，最后都会有download log选项。借用这个日志，我们可以准确高效地定位出错的Component以及可能的原因。

　　1. 导入失败

　　不要用记事本打开下载的log文件，那样你会看到密密麻麻的信息，很不直观。使用Excel打开log，你会发现所有的component信息，状态信息，comments信息都已经有条理的列好了，很方便地就可以找到失败的component，以及失败的描述信息，来帮助我们解决问题。有一点需要注意的是，因为CRM的导入操作就是往数据库里修改数据，那么就会碰到一个让人很无奈的情况：即使你的Solution问题再多，CRM也只会导入一次才暴露一个问题，而不是像有统计列表那样，一次把所有的问题都暴露出来。

　　2. 导入成功　　

　　可能许多人看到CRM显示Solution导入成功，就直接关闭窗口，觉得log可有可无了。在这里，还是建议大家，即使导入成功了，也把log保存下来。有两方面的原因：一方面是即使导入成功了，还可能会有很多的warning信息，有些warning信息甚至会影响后续的操作。比如，你更新一个workflow的Solution，导入虽然成功了，但是你发现为什么workflow activate失败了呢？如果你查看导入log的warning信息，就可能找到一条提示信息“workflow涉及到user在当前环境没有......”。另一方面的原因，是如果以后有一个环境问题是因为当初的这个Solution，还可以当做一个处理问题的依据。

　　3. 导入ing

　　之所有说导入Solution一般都会下载log的选项，是因为还存在非一般的情况。如果硬件资源不足，或者Solution本身太复杂，可能会出现的情况，是进度条卡在最后的85%左右，然后就再没有反应了。这种情况，可以通过检查Solution的版本号，来确认Solution是否导入成功，当然，这个时候，就不会有下载log的操作了。