企业数字化已经不是一个陌生的词汇。不论规模大小，有些企业已经进行过一些数字化的项目，对于如何进行数字化也有了自己的一些经验以及心得，但更多的企业正在准备或者处于观望状态，对于如何进行数字化，有点大姑娘上轿头一回，多多少少会有些不知道从何下手的感觉。
导入软件不像是购买了一个不大的设备，或者一个培训，影响相对来说涉及到的人员会少一些，亦或是暂时性影响，觉得不满意，可以随时喊停或者更换掉，成本和精力投入不会太高。但是导入系统就不一样了，不仅仅是导入软件本身，更多的是在系统导入过程中对流程操作习惯等进行改变，涉及到的人会比较广，而且一旦有了数据，那么更换起来的成本会更高。作为企业数字化的一部分--导入质量管理软件，当然也是一样。
很多公司都在人数以及职能方面扩充自己的IT团队，IT不再是帮大家装装电脑，布置一下电话线等这样支持性的工作，更多的是作为公司业务职能的一部分来进行价值创造。但无论如何，如果在导入系统前，能够知道一些数字化成功的企业都是如何导入质量软件的或者需要哪些步骤，虽然不一定可以全搬照抄，但至少可以借鉴一下，少交点学费也是好的。
导入质量管理软件之五步法
导入质量管理软件基本可以分为五步：规划设计，需求收集，购买决策，系统实施以及上线使用。当然了，导入其他工业软件也可以作为参考。
第一步 规划设计
千里之行，始于规划。需要进行业务规划，数据规划，技术规划，流程规划等等。
规划的第一步就是选人。
企业数字化建设一定是一把手工程。所以毫无疑问，企业的负责人必须是最大的负责人。
说数字化是一把手工程，不仅仅因为进行数字化需要资源的投入，而且需要跨部门人员的协调，以及可能涉及到公司业务流程的更改，甚至会影响到个别人的利益。如果一把手仅仅是象征性的支持（support），那么失败率就会很高。当然不是说需要一把手事事亲力亲为，但需要是最终的负责人。
企业数字化更多的是一种思维方式的改变
企业实行数字化质量管理建设，其实是一场变革，是对现有操作方式，更是对员工思维方式的改变，绝对不仅仅是导入一个软件。软件只是工具，更多的是对企业人员思维方式，做事流程的改变。所以不免会改变现有部分人员的舒适区或者某些利益。那么当公司选择参与质量数字化的主要人员，必须是熟悉业务，并且是支持数字化的人，否则很难推行下去，企业一把手既然下定决心进行数字化变革，就需要有足够的心理准备与魄力。要么换思维，要么换人。不仅仅是在规划阶段，在整个数字化过程中都要如此。
就像我们的一个客户，企业负责人非常想进行数字化建设，但因为质量经理担心导入了系统后老板就什么都知道了，所以总是以忙为理由阻碍数字化项目的进程，为了一己私利，不惜以牺牲整个公司的未来竞争力与存活空间为代价。
同时，如果参与质量数字化的项目人员中至少有一部分人有一些最起码的IT知识或者数字化经验，那么也会很有帮助，一是方便交流，还有就是如果选择的是外部数字化质量管理软件，那么也更容易进行判断软件的好坏或者不那么容易被蒙骗。就像某在华德资企业，在SAP与云质QMS进行检验对接时，按照正常流程,质量人员在QMS检验完成以后会将来料检验结果回传给SAP，SAP根据QMS回传结果进行对应入库操作，以及其他部门能够及时得到通知，以便进行相应的业务需求操作。但是该公司SAP系统负责人被SAP实施商告知，当不合格时，不需要将结果返回，完全不管生产计划部门，采购或者财务部门是否需要及时知道该信息，理由是这个通知会占用服务器的空间，导致系统会变慢！这个思路就像是地球上因为多了一粒灰尘，然后变得太重就不能正常自转了，如此荒谬，该公司的SAP负责人竟然还对此深信不疑。
或者有的ERP公司为了让客户使用自己的QMS，忽悠客户说，你买别的QMS还得和我的ERP对接，实现起来技术上很麻烦。稍微懂一点的人就知道，现在的大多数成熟系统都有现成的API，互相调用一下就可以了，多数情况下对接起来非常容易。这家软件厂商其实是为了借助这个客户的力量进行所谓的QMS产品开发，但又不能直说，最后的结果是开发了一个功能上缺胳膊少腿的QMS，然后QMS这个团队还得和ERP团队进行各种沟通进行对接。当然，这样的伎俩只能忽悠完全没有经验的客户，稍微有点经验的客户，早就把这样的厂商拉黑，鄙视的目光有多远，就让他滚多远了。
选完了领导和团队，那么就是对于公司数字化质量管理软件的正式规划了。
正式规划可以简要分为三个方面：
首先是制定希望达到或者完成什么样的企业业务目标。
这个直接决定了后续需求的实现。方向如果错了，那么做什么都是错的。比如公司希望提高客户满意度，能够进行全供应链全景追溯，那么当有些一线员工提出希望加快检验数据录入速度，希望系统自动生成在规格区间的数据时，就知道这需求有多么荒谬了。当然在可能的情况下提高一线员工的工作效率是合理的，但是不能以违背公司的原则和业务目标为代价。
第二个就是根据企业业务目标进行质量数字化架构的规划。
在规划时，首先要考虑到进行数字化的范围。是针对从供应商到内部生产，再到客户的全供应链质量管理，还是仅仅针对局部质量管理流程？
其次是要考虑到QMS与其它系统的交互以及功能的切割。不可能靠一套系统实现全部的功能，但现今社会又不允许一个系统孤岛式的存在。控制边界不仅仅是业务流程的需要，更是与内心欲望的一场斗争。各负其职，并且系统之间进行有效对接，做到高内聚低耦合，才能够最大程度保证系统的有效运行以及发挥系统的最大效率。例如，让QMS做库存管理就不是一个好主意，专业的QMS乙方可以开发出一个很简单的库存管理，但终究比不过专业的WMS软件。就好比，失去双腿的人通常可以用强健的双臂做部分代偿，但无论如何粗壮的双臂也比不过正常的双腿，让专业的软件做专业的事也是这个道理。
还有就是字段语言的统一。很难想象同一个东西在不同的系统叫的名称不一样，当一个用户需要用到多个系统，或者管理层开会时，大脑需要时刻进行名称的来回切换，这是多么的烧脑。比如有些公司原有系统都将物料代码叫SAP号，或者品号，那么新来一个QMS系统叫物料号，可能很多人就分不清楚了。
规划的第三个就是钱。
这个没必要多说。虽然这个数值大概率会有波动，但对于公司运营来说，大概的预算还是有必要做一下的。最终的费用会受到需求的影响，以及是内部开发，还是外部购买，外部购买还分为买的定制开发软件还是标准产品。对于中小企业来说需要花费的数额可能从几万块到几百万不等。当然了，对于公司来说，绝对不能仅仅考虑软件本身的价格，应该考虑的是TCO(Total Cost of Ownership)，即总拥有成本。这个方面来说，导入软件系统与购买设备是类似的。除了软件的购买成本，有可能还需要购买服务器，甚至机房等，同时还要考虑到内部公司人员的投入，实施以及后续的运维等等。
第二步 需求收集
需求收集包含两方面：
一个是所有相关用户需要实现功能的需求信息的收集与梳理。
用户需求收集与梳理当然有一套逻辑以及方法论。但总体上来说是找到所有相关用户以及利益相关者、选出用户代表，收集需求信息，对需求进行优先级排序（可以根据需求对于业务影响程度以及紧急程度来计算），选出需要实现的需求。这样不仅可以合理安排资源，先解决最主要的问题，不追求一步做到完美，还有就是有些当初提的需求，等后来慢慢发现其实可能根本就不需要。就像进行过人生中第一套房子装修的人肯定深有感触，当初想了很多，花了很多钱，但是等住进去后发现，很多东西根本没什么用，更糟糕的是，该做的却没有做，造成很大麻烦。
这一步的难点在于很少有业务人员能够把需求一次有条理的提出来并且梳理清楚。如果这一步说不清楚，后续今天提一个需求，明天再提一个，后天其他部门提一个，谁都没错，但对于软件架构设计以及开发来说可能就会是一场灾难。还有就是有些需求之间是互相冲突的，根本没法实现。
第二个就是业务背后逻辑的收集。
如果企业选择的是定制开发软件，业务逻辑的梳理与实现直接决定着产品能否开发成功，以及软件能否上线使用。进行数字化质量建设，绝对不仅仅是将纸质记录变成电子记录，更多的是将业务流程化，流程在线化。那么就需要将业务规则、流程逻辑梳理清楚，才能够进行流程化处理。
当然，如果企业最后选择的是市场上的标准产品（COTS），这一步骤可以轻松很多。如果该款标准产品可以进行灵活配置，并且已经融合了制造行业质量管理流程的最佳实践，那么企业完全可以采用拿来主义。省去大把时间与内部资源进行需求收集梳理，并且可以大大降低项目失败的风险。就像华为当初找IBM当顾问，对内部的要求就是，学习先进流程，先僵化，再优化，后固化。
这一步有两点需要特别注意。
一是需要格外注意级别不高的员工所提的需求。
这里不是将人分等级或者某种歧视，但确实因为所做工作级别的原因，会造成思路的高度，全局观的差异，造成所提的要求可能是完全出于个人或者极小部分的局部利益，会影响到大局的规划以及实现，其实就是某种程度的伪需求，而这种需求很多时候不太容易分辨，毕竟披着“合理”的外衣。如果全部的需求完全放任由基层员工提出，就类似让10岁的小孩进入超市，让其为一个家庭制定采购清单。巧克力，玩具肯定是有价值的，但一个家庭的采购绝对不能只有巧克力和玩具。
还有就是很多人提出来的“需求”，其实是解决方案。
头脑风暴没错，但需要非常小心的进行分辨以及采纳。否则，如果把用户提的所谓“需求”-实则是解决方案，来进行软件的需求收集进而进行产品设计以及实现，那么这样的系统最后垒出来的连鸡窝都不如，屎上雕花，you can you up。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
