Dynamics 365 实施中业务架构师的作用

微软ERP的版本基本三年一个大版本， 最早的版本功能较少，企业也是以中小企业为主，3.0以前得版本以很多顾问一个人可以独立完成一个项目，随着功能的增加，逐步细分成功能顾问和技术顾问，功能顾问又细分为生产顾问，财务顾问，物流顾问等。顾问名称同SAP的叫法有点不同。到2012 (6.0) 这个版本开始， 一个人做完所有事就有点难度了。到了D365版本后，应该增加一个顾问工种---架构师。为什么要增加这个功能职位呢，个人认为，使用D365 的企业一般都是大型企业了，跟AX4.0， AX2009的企业相比而言，用户的规模明显大了很多。一个项目少则10多个，多则几十上百个顾问在合作。顾问与顾问之间的沟通变得越来越复杂，业务顾问和技术顾问之间甚至是远程进行合作，加上业务顾问和技术顾问之间没有一个通用的语言进行沟通，很容易造成理解错误。因此就需要有一个架构师，作为总设计师来架起业务顾问与业务顾问，业务顾问与技术顾问之间沟通的桥梁，形成多对一的沟通，有效避免了多头沟通带来的无序状态。

业务架构师最佳人选是技术出身的业务顾问，其次是资深的业务顾问，项目经验较少的顾问不宜担任架构师。为什么技术出身的业务顾问是首选呢，因为现实项目中顾问编写的FDD是业务顾问执笔，基本上是从业务角度去描述，很难考虑如何实现以及是否能够实现。技术顾问根据功能文档的描述，未必能够准确理解业务顾问表达的真实含义，因此实现的结果也未必是用户想要的结果。技术型架构师可以很好的当起桥梁的作用。 因为首先自己对业务有全盘的了解，非常清楚需要什么样的功能。 其次，自己是技术出身，能够判定功能是否能够实现以及如何实现，所以在修改FDD的时候可以适当增加程序员明白的语言进行说明。如果没有这样的资源，那么资深顾问也是非常适合的人选，因为资深顾问经历的项目多，跟技术人员经常打交道，也熟悉了技术人员的语言，所以也能够胜任这份工作。所以，业务架构师在大型ERP项目中的作用非常关键。这种职位用好了能够减少很多沟通及返工所带来的项目风险。