都说数字化转型难，那么究竟难在哪里？有人说技术难？有人说投入难？有人说转意识难？有人也说买软件，用第三方软件也很难，功能不匹配，搞二次开发要钱，售后也要钱，不如自己成立技术团队量身订制搞软件开发，那么自己动手数字化建设就会丰衣足食吗？错！并不是掌握了技术数字化转型难题就会迎刃而解，数字化的难题在于意识、在于管理、更在于全员对数字化是否达成共识，技术与业务融合一起来解决问题。

今天老杨将内部开发软件的相关难题总结如下：

一、立项难

在当前数字化环境下，虽说企业内部对数字化系统的应用有了全新的认识，都清楚软件系统的应用的好处，但当决定是否做某一个信息系统时，就难以下决定了，一方面软件系统的透明性让某些员工、领导有所顾忌，用软件意味着透明、灰度没有了，同时又担心数据安全；如果不用系统工作效率难以提高，因为传统的文档、表格用起来实在麻烦；特别又是在企业“降本增效”模式下，大家都秉承多一事不如少一事的心态，担心搞数字化建设工作出了错，引起不必要的麻烦，因此除非非常有必要，否则业务部门不会做数字化项目立项。

立项阶段的工作难点还体现在过程沟通上、价格谈判上、流程审批上。

1.1. 需要和各级领导、企业负责人沟通，内容如下：

解释为什么做这套系统？

当前的工作痛点是什么？

软件系统能解决什么？

准备如何做？

现在做了什么？

选型过程是怎样的？

为什么选了**软件？

我们准备如何实施？

业务部门如何配合？

会遇到什么问题？如何解决？

预计工期多长？

什么时候软件上线？

上线时会有什么问题？如何解决？

上线后预计会达到什么效果？

1.2.在价格谈判上的难点包括：

谁主导谈判？

谁参与谈判？

谈判策略如何？

软件价格计算依据是什么？

后期运维价格如何计算？

后期接口提供如何收费？

二次开发如何收费？

项目人员构成及核算规则是什么？

谁最终在谈判中确定系统价格？

谁最终同意项目费用？

价格双方如有异议怎么办？

乙方价格不下调怎么办？

1.3.在审批上的难点包括：

谁负责向各级领导汇报最终项目建设方案？

谁发起审批流程？

哪些人参与该项目审批？

谁负责起草合同？

谁参与审批合同？

合同条款有异议怎么办？

项目急着开工，审批未完成怎么办？

从以上各个环节的问题不难看出，软件系统建设立项工作需精细化运作，需事前充分沟通、确认，与相关领导达成共识后方可进行下一步的工作，未批先建，是数字化建设风险也是大忌。

二、需求收集难

需求收集是数字化建设的重要环节，尤其是涉及企业订制开发项目。今天老杨主要聊的就是企业内部技术团队订制开发业务系统的那些难点那些事。

在老杨经历的众多软件开发项目中，大部分业务部门在项目初期对于需求是模糊的，只会说如下内容：

我就要一套ERP系统；

软件我不懂，你们看着搞吧！

你们按这个页面去开发就是了！

你们不是专业的吗？怎么还问我？我不知道

这个功能我不清楚，你问其他部门

造成软件系统需求收集难、需求不明的原因有如下：

2.1.业务部门对系统的理解停留于技术阶段，以为软件开发知道一切功能需求；

2.2.业务部门只关心自己所使用的功能如何实现，对于功能背后的数据逻辑实现缺乏深度理解；

2.3.或许业务部门连自己想要什么都不清楚，但什么都想要；

2.4.业务部门缺乏企业协同力，缺乏系统化思维；

需求不明、需求收集难，对于订制开发团队来说是非常致命的陷阱，业务部门对于需求有可能朝令夕改，让技术开发部门陷入不断修改、不断推翻的死循环，因此在需求收集阶段，产品经理的沟通能力非常重要，一方面要从与业务部门沟通的只言片语中寻找价值线索，拼凑出一个初步的产品框架，同时又要引导业务部门，防止业务部门的思维不断发散，让产品架构变的非常庞大，功能做的非常臃肿，导致开发周期遥遥无期。

三、开发过程难

需求确定了、立项报告通过了，那么接下来就是技术部门火力全开搞软件开发的阶段，这个阶段也可以说是无比艰辛，要经历如下磨难：

3.1.业务需求变动频繁，软件架构难以成型：

这就是前期业务部门需求不明种下的恶果，因此老杨的建议是宁愿在需求调研阶段多花时间，也不要在开发阶段改来改去，技术部门最忌被业务部门牵着鼻子走，最后时间成本投入了，项目毫无进展；

3.2.时间进度把控难，成本控制难：

造成时间进度难以把控的原因有内外两部分原因：

内：是指技术部门本身，项目经理缺乏项目管理能力，开发过程缺乏计划性，有计划也难以按期保障推进，项目过程把控力弱，同时由于某些技术细节内部存在异议，大量时间花在内部技术协调上，导致项目延期，时间成本上升；

外：是指业务部门，在软件开发过程中不断提出新的需求，导致业务功能越来越多，系统越来越臃肿，影响前期既定的开发目标及计划，造成项目延期；在大部分情况下，业务部门以为开发团队是自己公司的，不是第三方，不需要成本，这是大错特错，技术团队的正常运营同样需求管理成本。

所以在软件开发过程中，时间即成本、需求反复即成本，业务部门、技术部门均需要有成本意识。

此外，系统开发过程中，项目进行过程中相关人员的异动也是导致时间进度难以把控的主要原因：

3.2.1.技术部门软件开发人员离职，导致项目开发无法正常进行；

3.2.2.业务部门对接人或业务骨干离职，导致业务需求及开发成果无法确认；

3.2.3.业务部门领导变动，管理思路改变，导致整个系统架构推倒重来；

3.3.软件系统质量把控难

由于在开发过程中的时间进度问题、人员问题、技术问题导致软件进度滞后，在这种情况下软件的质量也难以把控，由于缺乏专业测试导致相关的软件性能及功能性测试缺乏，使系统存在巨大的安全隐患。

3.4.精细化过程管理难：

在企业软件开发过程中除了技术难点，还有管理难点，这个难点就是要求的精细化过程管理与实际管理存在差异的矛盾，例如缺乏开发过程需求文档、需求说明书、测试用例、测试报告、上线审批流程等等标准化过程管理，这就是管理理想很丰满，但现实是技术人员都在追求开发进度，忽视过程管理很骨干的管理现状。

3.5.人员管理难：

体现在项目开发过程中计划制定、业务及技术交底、人员任务分配、人员权责分配、数据命名规则等开发管理环节，所以对项目经理的能力要求极高，一方面项目经理需要排兵布阵，把控项目进度，另一方面项目经理需要有成本意识，提高开发效率，如项目有外包部分，还涉及对外包团队的管理，尽量降低窝工的风险；所以一个优秀的项目经理必须具备较强的项目管理能力，对人员管理、开发进度、开发风险、软件质量有综合把控的能力，而非纯有技术能力。

四、应用难

软件开发完成后，项目团队面临的另一个问题即是应用难题，这个时候往往忽略的是以为软件是订制开发的，完全安装业务部门需求量身打造的，无需花大量时间精力去推广，结果导致被业务吐槽软件不好用、软件没有达到预期的管控效果、质疑开发团队的能力，为什么会出现该问题，老杨分析如下：

4.1.由于业务需求的高度不确定性、不稳定性、易变性导致实际应用与预期效果存在偏差，这个时候如果沟通不及时、不到位，很容易成为业务部门的吐槽点；

4.2.业务部门人员多，而对接的业务骨干只有一个，个人的应用习惯并不代表整个部门，所以系统在上线初期，业务人员对系统有一个适应期，这就对软件的易用性设计提出了很高的要求；

4.3.系统上线后相关配套的管理制度并未出台，导致系统在应用时数据的规则标准、及时性、完整性、准确性难以保障，导致数据分析应用难，数字化管理失去管理价值；这是系统运营管理的问题，也是应用难的最大问题；

4.4.系统上线后同样面临的还有售后的问题，虽说开发团队是公司自己的，但团队同样肩负着众多的软件开发项目，这就导致，后期一旦涉及系统调整及修改，面临响应慢的问题；

综上所述，企业数字化转型，不管是购买第三方系统还是自行订制开发系统，都会面临各种问题，如技术问题、业务问题、管理问题等，所以在数字化建设上要做到如下几点：

前期立项合法化

成本预算透明化

需求明确化

过程管理标准化

开发进度效率化