1.前言
通常情况下，企业要上一个项目，都会大致评估一下项目的必要性、风险以及收益等相关要素。
审核项目的方式也多种多样，小企业有可能由实战经验丰富的老板一个人在脑海中想一想就决定了，中等规模的企业可能是大家讨论一下，然后拍板下结论。有些企业则有可能要求详尽的可行性分析报告。
这里面没有谁对谁错，只是不同的企业选择适合自己方式而已。
本文就企业实施QMS过程中通常讨论的要素进行一些归纳和总结，同时提供相关模板仅供参考。
2.项目概况
对项目的背景以及可实现情况进行基本描述，这个条目既容易又艰难。
容易是--无需太多说明，都会填写。
艰难是--得出这些结论不是随便写写的事情，而是根据充分的调研分析得出的结论性信息。
下面是举例说明要填写的条目。
3.项目目的
为什么要导入QMS？
在此，我们不是站在道德的高地来强调“实话实说”重要性，而是从保证项目成功的角度来要求，我们认为“实话实说”是保证项目成功的一个关键策略。
首先，甲方要回答的第一个问题是为什么要实施QMS？
每家公司可能不一样，但总结起来可大致分为如下几类：
-撑门面：应付客户的审核、准备上市等，有一个QMS系统存在，显得高大上或面子上过得去，无太多实际用途需求；
-赚补贴：如果导入QMS这类数字化系统，可以拿到一些补助或者可以申请到其他一些资质。自己不用花多少钱，不要白不要；
-客户的要求：必须实现数字化质量管理。如苹果、华为等一些国际大公司已经开始对自己的部分供应商明确提出数字化质量管理的要求，否则可能影响订单。这种情况就要求不但有系统，并且还会对供应商的质量管理系统进行非常严格详细的审核；
-攀比心：隔壁企业都已经有QMS系统了，所以我也得有；
-竞争压力：同行已经开始用QMS系统进行质量管理了，感受到了竞争的压力；
-质量管理的需要：质量数据还是用纸+excel,统计分析不仅慢，维度低，不能持续不断地提高客户满意度。企业自身质量管理需求的不断提高，需要有一个数字化质量管理系统或一个更加完善的系统，这种应该是大多数情况。
-没有独立的QMS系统：质量数据分散在SRM，ERP，CRM，MES，LIMS等系统中，这些系统不是为质量部门人员设计的，不仅是数据没有关联，而且各种统计分析也不专业，显得鸡肋。质量人需要专业的QMS软件：别的部门都有管理系统，唯独我这个质量部没有属于自己的系统。
-替换原有的QMS系统：已经有QMS系统，但存在很多问题（比如速度慢、没有移动端、经常宕机、需要线下辅助、无法统计关键指标等），不能满足现在的业务需求，需要更换；
这个一定要实话实说，它不仅是项目的基石和规划路线的指南，也是估算应该投入多少资源的才合理的依据。
对于这一条目，可能是多种因素并存。
4.必要性分析
是否有必要导入一个专业的QMS系统？
出发点不一样，企业所在的行业不同、规模不同、运营方式不同、员工水平不同等各种独有的特性，企业对质量管理软件的需求也不同。
那么在进行质量管理软件(QMS)选择时，需要考虑的因素就会有很大差别，企业一定要从自身的实际情况出发，只有综合考虑了这些因素，才有可能选出最适合的软件并且将失败的风险降到最低：
第一种情况（应付客户审核、准备上市或者充门面），处理起来最简单粗暴。随便买一个就好，只要客户来了能打开，证明软件存在即可，越便宜越好。不需要花费大量的人力资源搞需求调研，评估方案，转变管理方式等一系列劳神费力的事情，也节省了企业相当大的资源，减少了成本投入。
第二种情况（赚补贴或者申请资质），考虑的因素就稍微多一些，比如是否兼顾企业真正的质量管理需求，对于软件或者软件企业的资质、地理位置是否有要求（否则可能拿不到补贴）。
后续的几种情况，则要更多地考虑每个企业的需求以及软件能够实现的功能了，这些因素有很多，也是本篇文章讨论的重点：
对于必要性，我们不仅要分析实施QMS系统可能带来的收益，还要问自己：如果不实施QMS会有什么样的后果：
-是否被同行超越？
-是否会影响新客户的导入？
-是否会导致客户满意度降低？
-是否会影响企业按时交货指标的进一步提升？
-是否会影响APS的顺利导入或APS的运行效果？
-是否会影响企业的整体工作节拍的提高？
-…
以上提示，仅仅是为了帮助甲方更好地判断QMS在现阶段是否是一个刚需。
每个企业都有各自的特点，我们不能期望所有的答案一定是Yes，就好比赤道的居民永远不会像北极的居民那样高比例购买羽绒服一样，因为专业的QMS对有些企业并不是刚需。
5.先决条件
实施QMS，你真的准备好了吗？
即使我们得出的结论是QMS系统是必要的，也要认真梳理一下，在实施QMS前，需要满足什么先决条件，至少我们要对关键制约条件有个大致了解。
-清晰的需求
有了实施的初衷（目的），还要制定清晰的需求。
举个例子，企业实施QMS初衷（目的）之一是提高采购原材料的性价比，毕竟，对于大部分制造企业来说，原材料采购成本可能占到公司产品总成本的50%，每节约1%的采购成本，利润增加可能高达10%。要实现这个目标，就要将目标转化为具体可操作的质量软件需求，比如：
a.供应商录入出货检验报告。
b.本企业的检验数据实时与供应商的数据对比，可以从短期和长期两个维度分别侦测供应商数据是否可信。
c.实时分享质量数据给采购，帮助采购充分发挥采购资金效用。
举个例子，同一类原材料，供应商或料号可能不同，但其水份含量的质量标准是一致的，这时系统就可以横向对比，分辨出供应商质量水平的高低，让采购可以有更多的谈判筹码和策略，而不是像留声机一样只知道说“降价”，却没有得心应手的工具来达成目标。
需求的效果有高低之分，也要考虑轻重缓急，对要实现的目标的贡献程度差别会很大，因此要注意取舍，不能胡子眉毛一把抓。
甚至，有些需求可能对企业有负面作用。
比如，修改生产时间以满足保质期要求，或修改加班时间以满足法律法规要求等。基层提出的需求，上层要进行审核，避免出现不必要的风险。
-人员能力
人员是否有能力掌握数字化系统？与ERP，PLM等软件不同，很多QMS的用户是一线检验人员，员工的接受能力也要照顾到。因此在方案选择时，QMS软件的操作难易程度也是非常重要的一环。
-人员配合
不是所有的员工都支持实施QMS。有习惯上的原因，也有观念上的原因，甚至还有一种情况，数字化转型触及了他们的利益（包括金钱、权力甚至是偷懒的程度等）。
比如，在转制的企业，很多老员工的精神状态一潭死水，往往失去了学习新事物的兴趣，企业不可能因为数字化转型就把老员工都换掉。
导入QMS系统后，公司老板或者管理人员可以实时掌握一些以前不可知的质量信息，而这也是有些人不希望看到的。
-企业的基础资料是否完备
比如，图纸是否正确，检验标准是否已经制定，不合格品流程是否落实等等。
当然，这些因素不会导致系统无法实施，但在实施QMS过程中要留足时间和资源，对这些历史欠账也要同步落实。很多聪明的企业发现通过这个契机，在推行QMS的同时也解决了陈年基础资料混乱的顽疾。
-领导层决心
这个是老生常谈的话题，不用过多解释，大家都懂。
同一个行业，产品类似，规模类似的两个甲方，一家的QMS系统2个月就上线，另一家2年了还没上线。
领导不关心，系统上线就会遥遥无期；领导积极，则项目上线的概率也会大大提高。所以在项目开始阶段取得老板的支持与承诺非常重要。
6.需求确认
如何收集QMS项目的需求？
有些企业的QMS项目成功了，有些则逐渐被废止，甚至根本就无法上线。
有些QMS系统接地气，给企业带来了价值，有些QMS系统则被人称为花架子。
为什么？
制定出合理的和关键的需求是保证系统成功的要素之一。
甲方提出的需求大部分都是合理的。问题在于需求太多，那该如何做出取舍？
那如何判断哪些需求是关键的呢？
这个没有统一的答案，但我们可以以客户为价值判断的中心。
客户分为外部客户和内部客户。
优先满足外部客户的需求
质量部的责任是保护企业声誉和管控产品质量，如有投诉必须及时解决。
因此制定需求时，可用QFD等质量工具进行展开，当然也可以是其它工具，大家头脑风暴亦可。这个属于老生常谈，大家通常都是这样做的。
容易被忽视的是内部客户的需求。
企业是一个整体，需要紧密合作，只有按照节拍生产才能创造出更多的利润。千万不要把QMS数字化转型仅仅理解为节约几张纸，或线下审批搬到线上这些功能的优化，而是应当把它用作提高管理效能的催化剂。
举个例子，通常对于有上万种原材料的离散组装行业而言，停工待料、半包生产、加班赶工期、临时改变生产计划、找领导紧急放行、调配原材料、换线生产等等一系列鸡飞狗跳的乱象最大的原因是什么？是来料不合格。
这时，生产部门和计划部门就是质量部门的内部客户。
我们可以简单模拟计算一下，现在很多企业都是按订单生产，假设一天20个订单，平均每个产品有个零部件组成，那么来料就是批，在这种情况下，即使来料批合格率为99.5%，最大可能会影响10个订单生产，占全部订单的50%，这还不包括在产线上发现的不合格品导致的停线。这样大家也就能够理解为什么生产线领班经常和计划员打架的原因了。
以前限于手段的落后，质量部门的职责往往是保证不让不合格品流入到生产线。通过数字化质量的供应商协同功能，我们是否可以重新定义质量部门的责任：按时收到合格品。
再举一个例子，通常模具维修都是按照合模次数或者时间，可是实际生产情况千变万化，问题的种类也是多种多样。
就以简单的“飞边”为例，最高效的方式是发现“飞边”苗头，及时维修，而不是等到问题很严重了才维修。如果有数字化手段，质量部门的数据完全可以共享给维修部门，让维修部门也可以实时掌握模具的状态，真正做预防性维护的同时又不浪费过多的无效维护。
同理，研发部门和销售部门也是质量部门的内部客户。
研发部门开发新产品需要类似产品的生产过程质量统计和客户对于类似产品的投诉清单和整改方案。
销售部门历经千辛万苦才让客户到企业做质量评审，如何让客户对企业的质量管控放心才是质量部门对销售部门最大的支持。
质量部门可以说拥有海量的数据，如何充分使用这些数据，让这些数据创造价值是制定需求的主线。
企业之间都有竞争，对于如何进行产品报价就是一个很现实的问题。
价格报高了没有竞争力，报低了公司亏损。
大家可以反问自己的企业，报价时想查看一下类似的产品在不同的产线直通率是多少？在每道工序的前三个疵点又是什么？客户都投诉过什么问题？贵司能在5分钟之内提供给销售部门吗？
财务部门也可能是质量部门的内部客户。
很多人会说，可以通过财务报表看看哪里还有成本节省的空间，可惜传统的财务报表数据是以真实发生的交易或事项为依据，以便能够知道企业的经营状况以及财务状况。传统的财务报表更多反映的是结果，而不是为了显示成本发生的来源或原因，更不是为了降低成本来设计的，所以也就很难通过传统的财务报表看出成本发生的背后原因，作为企业非常重要的一个成本--质量成本，也就非常容易被绝大多数的企业忽视了。
菲利浦·克劳士比曾说，不合格质量成本很容易达到公司销售额的15~30%。这是企业增加利润的金矿。详细内容，请参见《质量管理系统QMS-质量成本如何影响企业利润？》
这是根据前些年国外87家企业统计得出的数据，常见的注塑行业质量成本占销售额14.70%，节约降本的空间巨大。
当然，也可以根据企业具体情况，围绕提高质量，提高工作效率为重点展开提出可落地的需求也是合理的。
需求是否能落地？
QMS系统，还要看是否可以落地，而非一个花架子。
时速公里的跑车，需要一个非常平整的路面，在坑坑洼洼低等级公路上不仅速度比不上SUV，甚至可能都没有办法移动。
笔者在10多年前实施QMS系统时在这方面是有深刻教训，不能离开具体环境谈需求，就像种麦子还是种水稻都要先看是旱地还是水田一样。
我们当初设想的供应商协同系统是这样的：供应商先行录入，提交以后客户才进行下一步，麻烦就在这里发生，尽管供应商的管理层都同意这个要求，但供应商现场的一线员工在执行时经常忘记，或者是为了下班赶班车就不填写了，结果是系统无法顺畅运行，影响了企业业务。因此，在设计业务流程时，要对复杂的实际环境给予充分重视，当然，缺少数字化方面的经验也是不可忽视的一个因素。
所以要根据企业的实际状况，对需求的优先级和落地风险要予以排查。这些都会影响到QMS软件产品的选择和项目阶段的安排。
参考样例：
7.实现方式
自研，外包还是购买产品？
其实都可以，各有好处也各有不足，要根据企业实际情况因地制宜。
这个话题展开比较大，对于大多数企业，最好选用成熟的产品，这样成功率比较高。
详细内容请参见《质量管理系统(QMS)-6.自己开发,外包还是购买产品?》
这里不再赘述。
补充一点，即使是外包或者购买产品，也要懂一点IT知识，最好有监控乙方的能力。
如果不懂，建议要货比三家，对不理解的事，要让乙方解释清楚，毕竟不是所有的乙方都会撒谎。
举一个真实的例子，国外数一数二的工业软件巨头，它收购的QMS是C/S架构的，为了满足客户需求，代理商重新开发了B/S架构的部分功能模块，一个PPT方案里的产品，竟然有3种完全不同的风格。这个时候就要问清楚，到底什么部分在C/S？什么部分在B/S？苹果电脑（非Windows系统）的用户能不能使用？升级时候怎么办？如果让乙方实际操作展示时，可能发现其PPT吹的太大了。
还有的企业号称有低代码平台，能够便捷地支持业务拓展。这个时候就要看一看，这个低代码达到了什么程度？
有些公司把改个字段名称，添加几个字段也叫低代码；有的则可以在表单和工作流级别进行修改或者调整。对于一款业务属性极强的软件来说，即使有了低代码平台，也需要其具备高度抽象的业务规则和关联逻辑，如果只是简单地堆砌表单和审批流，搞一套质量部的“OA”，那就无法形成一个多模块且在业务层面打通的“系统”，只能形成一座座数据孤岛，更不要提通过QMS系统来跨部门协同处理质量业务了。因此，需求对于软件的选择起着方向性的指导作用。
要敢于向乙方提出任何问题，如果他没有听懂，那是乙方的解释水平有问题。
8.如何选择乙方？
答：最有效的手段之一就是--试用！试用！还是试用！
试用的方法有多种，推荐一个即高效又可检验出乙方专业水平的方法，即进行POC测试。
第一步：甲方根据自身需求，把相关的脱敏资料（可公开的数据或者模拟数据）如，来料检验报告、过程检验报告、出货检验报告、客户投诉、评审报告、纠正预防（8D）、不合格品管理流程、以及质量月报等资料发给乙方。
第二步：由乙方搭建一个临时的测试系统，物料号、工序和检验方式都完全模拟甲方真实运营的情况。
第三步：如果乙方是一个较为完备成熟的系统，可以很快搭建出一个模拟系统，而不会用什么审批之类的借口来拖延时间。
第四步：甲方按照实际生产和业务处理的流程，录入一些实际的检验、不合格品、客诉等数据，不仅可以检验乙方的系统是否能够实现企业所需的数据录入方式、质量报表分析效果，流程是否能够满足要求等，还能够快速评估系统对当前需求的匹配程度、对未来可能存在变化的灵活配置能力，并且可以通过这个模拟系统来进一步考察乙方对甲方的业务理解水平，以及技术支持能力。
第五步：通过测试系统，对于不能满足需求的地方，让乙方给出开发周期以及大致的报价，对项目的整体预算要做到心中有数。
第六步：对乙方的系统，人员专业水平，支持能力，价格等做出综合服务评价，选出合适的系统。
详细说明，请参考《评估质量管理软件系统(QMS)试金石--试用，试用，还是试用!》
9.IT的支持
尽管业务部门比IT部门更懂业务，更了解系统是否符合实际工作需求，但IT部门的作用不可小觑。
比如：
-选择C/S还是B/S？
-未来升级怎么办？
-本地还是云端？
-如何与其它系统对接？
-支持多大的数据量？
-移动端是APP还是web端应用?
-如果是多工厂，如何解决？
-如果有海外工厂，如何解决？
-如果QMS与ERP用的术语不一样，如何避免混乱？
-…
IT还有一项很关键的指标：从技术角度评估需求实现的可能性。
需求大部分都是业务部门提出的，在有限的预算条件下，技术上还要考察一下是否可行。
对于一个成熟的软件产品来说，技术可行性的风险相对较小。
但自研或外包，这个风险非常大。
还是举例子说明：
-架构的选择。
-产品的抽象程度。
-产品应对未来变化需求的能力
-业务数据量
-产品的运行速度
-权限粒度
-产品的后续升级服务（如果是定制开发产品，后续升级会是一场灾难）
-…
10.经济效益分析
实施QMS项目，老板们非常