企业质量管理系统(QMS)项目可行性研究报告

-云质QMS原创文章，转载请注明来源-

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的同时也解决了陈年基础资料混乱的顽疾。

-领导层决心

这个是老生常谈的话题，不用过多解释，大家都懂。

同一个行业，产品类似，规模类似的两个甲方，一个QMS2个月就能上线，另外一个2年还没上线。领导不关心，系统上线就会遥遥无期。领导要是关心，那么项目能够上线的概率会大大提高。所以在项目开始阶段取得老板的支持与承诺非常重要。

6.需求确认

如何收集QMS项目的需求？

有些企业QMS项目成功了，有些则逐渐被废止，甚至根本就不能上线。

有些QMS系统接地气，给企业带来了价值，有些QMS系统则被人称为花架子。

为什么？

制定出合理的和关键的需求是保证系统成功的要素之一。

甲方提出的需求大部分都是合理的。问题在于需求太多，那该如何做出取舍？

那如何判断需求是否关键呢？

没有统一的答案。

但我们可以以客户为价值判断的中心。

客户分为外部客户和内部客户。

优先满足外部客户的需求

质量部的责任是保护企业声誉和管控产品质量，如有投诉必须及时解决。

因此制定需求时，可用QFD等质量工具进行展开，当然也可以是其它工具，大家头脑风暴亦可。这个属于老生常谈，大家通常都是这样做的。

容易被忽视的是内部客户的需求。

企业是一个整体，紧密合作，按照节拍生产才能创造出更多的利润。千万不要把QMS数字化转型仅仅理解为节约几张纸，线下审批搬到线上这些功能优化。而是应当把它用作提高管理效能的催化剂。

举个例子，通常对于有上万种原材料的离散组装行业而言，停工待料、半包生产、加班赶工期、临时改变生产计划、找领导紧急放行、调配原材料、换线生产等等一系列鸡飞狗跳的乱象最大的原因是什么？是来料不合格。

这时，生产部门和计划部门就是质量部门的内部客户。

我们可以简单模拟计算一下，现在很多企业都是按订单生产，假设一天20个订单，平均每个产品有100个零部件组成，那么来料就是2000批，在这种情况下，即使来料批合格率为99.5%，最大可能会影响10个订单生产，占全部订单的50%，这还不包括在产线上发现的不合格品导致的停线。这样大家也就能够理解为什么生产线领班经常和计划员打架的原因了。

以前限于手段的落后，质量部门的职责往往是保证不让不合格品流入到生产线。通过数字化质量的供应商协同功能，我们是否可以重新定义质量部门的责任：按时收到合格品。

再举一个例子，通常模具维修都是按照合模次数或者时间，可是实际生产情况千变万化，问题的种类也是多种多样。

就以简单的“飞边”为例，最高效的方式是发现“飞边”苗头，及时维修，而不是等到问题很严重了才维修。如果有数字化手段，质量部门的数据完全可以共享给维修部门，让维修部门也可以实时掌握模具的状态，真正做的预防性维护的同时又不浪费过多的无效维护。

同理，研发部门和销售部门也是质量部门的内部客户。

研发部门开发新产品是需要类似产品的生产过程质量统计和客户对于类似产品的投诉清单和整改方案。

销售部门历经千辛万苦才让客户到企业做质量评审，如何让客户对企业的质量管控放心才是质量部门对销售部门最大的支持。

质量部门可以说拥有海量的数据，如何充分使用这些数据，让这些数据创造价值是制定需求的主线。

企业之间都有竞争，对于如何进行产品报价就是一个很现实的问题。

价格报高了没有竞争力，报低了公司亏损。

大家可以反问自己的企业，报价时想查看一下类似的产品在不同的产线直通率是多少？在每道工序的前三个疵点又是什么？客户都投诉过什么问题？贵司能在5分钟之内提供给销售部门吗？

财务部门也可能是质量部门的内部客户。

很多人会说，可以通过财务报表看看哪里还有成本节省的空间，可惜传统的财务报表数据是以真实发生的交易或事项为依据，以便能够知道企业的经营状况以及财务状况。传统的财务报表更多反映的是结果，而不是为了显示成本发生的来源或原因，更不是为了降低成本来设计的，所以也就很难通过传统的财务报表看出成本发生的背后原因，作为企业非常重要的一个成本--质量成本，也就非常容易的被绝大多数的企业忽视了。

菲利浦·克劳士比曾说，不合格质量成本很容易达到公司销售额的15~30%。这是企业增加利润的金矿。详细内容，请参见《质量管理系统QMS-质量成本如何影响企业利润？》

这时根据前些年国外87家企业统计得出的数据，常见的注塑行业质量成本占销售额14.70%，节约降本的空间巨大。

当然，也可以根据企业具体情况，围绕提高质量，提高工作效率为重点展开提出可落地的需求也是合理的。

需求是否能落地？

QMS系统，还要看是否可以落地，而非一个花架子。

时速300公里的跑车，需要一个非常平整的路面，在坑坑洼洼低等级公路上不仅速度比不上SUV，甚至可能都没有办法移动。

笔者在10多年前实施QMS系统时在这方面是有深刻教训，不能离开具体环境谈需求，就像种麦子、种水稻要先看是旱地还是水田一样。

我们当初设想的供应商协同系统是这样的，供应商先行录入，提交以后客户才进行下一步，麻烦就在这里发生，尽管供应商的管理层都同意这个要求，但供应商现场的一线员工在执行时经常忘记，或者是为了下班赶班车，就不填写了，结果就是系统不能顺畅运行。在设计业务流程时，没有对复杂的实际环境给与充分重视，当然，也缺少数字化方面的经验也是不可忽视的一个因素。

所以要根据企业的实际状况，对需求进行优先级排序和落地风险要予以排查。这会影响到软件产品的选择以及项目阶段安排。

样例仅供参考：

7.实现方式

自研，外包还是购买产品？

其实都可以，各有各的好处，也都有不足，因此要根据企业实际情况因地制宜。

这个话题展开比较大，对于大多数企业，最好选用成熟的产品，这样成功率比较高。

详细内容请参见《质量管理系统(QMS)-6.自己开发,外包还是购买产品?》

这里不再赘述。

补充一点，即使是外包或者购买产品，也要懂一点IT知识，最好有监控乙方的能力。

如果不懂，建议要货比三家，对不理解的事，要让乙方解释清楚，毕竟不是所有的乙方都撒谎。

举一个真实的例子，国外数一数二的工业软件巨头，它收购的QMS是C/S架构的，为了满足客户需求，代理商重新开发了B/S架构的部分功能模块，一个PPT方案里的产品，竟然有3种完全不同的风格。这个时候就要问清楚，到底什么部分在C/S？什么部分在B/S？苹果电脑的用户能不能使用全部功能，升级时候怎么办？当让乙方实际操作展示时，发现PPT的牛吹的太大了。

还有，有的企业号称有低代码，可以方便支持二开，这个时候就要看一看，这个低代码达到什么程度。有些公司把改写字段名称，添加几个字段也叫低代码。有的则可以进行表单以及工作流级别的低代码产品修改或者调整。即使有了低代码，那么对于一款业务功能属性极强的软件来说，即使用了低代码，那么还是需要背后有高度抽象出来的质量业务逻辑以及业务规则集成，否则也只能实现基本的表单数据录入、基本的工作流、以及数据分析，无法形成一个多模块业务层面打通的“系统”，数据就会形成一座一座的孤岛，更不要提希望通过系统实现质量处理业务的跨部门协同了。所以需求对于软件的选择就起着方向性的指导作用。

要敢于向乙方提出任何问题。如果没有听懂，那是乙方解释水平的问题。

8.如何选择乙方？

答：最有效的手段之一就是--试用、试用、还是试用！

试用的方法有多种，推荐一个即高效又可检验出乙方专业水平的方法。

第一步：甲方根据自身的需求，可以把相关的脱敏资料（可以公开的数据或者模拟数据）如，来料检验报告、过程检验报告、出货检验报告、客户投诉、评审报告、纠正预防（8D）、不合格品管理流程、以及质量月报等资料发给乙方。

第二步：由乙方搭建一个临时的测试系统，里面的物料号、工序、检验方式都模拟甲方真实运营的情况。

第三步：如果乙方是一个较为完备成熟的系统，可以很快搭建出来一个模拟系统，而不会用其它借口，什么审批之类的来拖延时间。

第四步：甲方按照实际生产和业务处理流程，录入一些实际的检验、不合格品、客诉等数据，不仅可以检验一下乙方的系统是否能够实现企业所需要的数据录入方式、报表分析效果，以及流程是否能够满足要求。还能够快速评估系统对当前需求的匹配程度、以及未来可能存在变化的灵活配置能力，并且可以通过这个模拟系统来进一步考察乙方对甲方的业务理解水平，以及技术支持能力。

第五步：通过测试系统，对于不能满足需求的地方，让乙方给出开发周期以及大致的报价，对项目的整体预算要做到心中有数。

第六步：对乙方的系统，人员专业水平，支持能力，价格等做出综合服务评价，选出合适的系统。

详细说明，请参考《评估质量管理软件系统(QMS)试金石--试用，试用，还是试用!》

9.IT的支持

尽管业务部门比IT部门更知道系统是否符合实际的工作需求，但IT部门的作用不可小觑。

比如：

-选择C/S还是B/S？

-未来升级怎么办？

-本地还是云端？

-如何与其它系统对接？

-支持多大的数据量？

-移动端是APP还是web端应用?

-如果是多工厂，如何解决？

-如果有海外工厂，如何解决？

-如果QMS与ERP用的术语不一样，如何避免混乱？

IT还有一项很关键的指标：从技术角度评估需求实现的可能性。

需求大部分都是业务部门提出的，在有限的预算条件下，技术上还要考察一下是否可行。

对于一个成熟的软件产品来说，技术可行性的风险相对较小。

但自研或外包，这个风险非常大。

还是举例子说明：

架构的选择。

产品的抽象程度。

产品应对未来变化需求的能力

业务数据量

产品的运行速度

权限粒度

产品的后续升级服务（如果是定制开发产品，后续升级会是一场灾难）

10.经济效益分析

实施QMS项目，老板们非常关注投入产出比。

有些投入是可见的成本，比如设备费用、调研费用、购买软件费用、云费用、培训费用等等。

但有些投入是沉默成本，例如占用甲方人员的时间，上线调试对生产的影响等，尽管在会计统计中不会出现，但实际上发生了，如有可以也可以大致估算一下，这毕竟是企业真实投入的资源，是机会成本。

统计总投入时应当是以上二者之和。

再说收益。

收益的量化统计比较难。这不单是QMS系统的问题，很多IT系统都有类似现象。

很多企业的第一反应是可以节约纸和人员，的确如此，但如果仅仅统计节约纸和人的费用，就是捡了芝麻，丢了西瓜。

可分直接收益和潜在收益来讨论。有些可以进行相对准确的计算，但对于有些统计难的项目，可以集体拍脑袋，尽管不准确，但可以给大家一个量级上的概念，不准确比没有强。

同时，也是给相关团队设定一个目标，起到督促这些人充分利用QMS系统，发挥其效能。

具体如何统计，可以按照上文提及的需求初衷来估计。

11.项目规划及进度

这个也没有一定之规。毕竟需求不一样，企业规模不一样，资料的完整程度不一样，以及配合生产等多方面因素，都会很大程度上影响项目的整个周期。

但是我们发现一个现象，可以供大家参考。

在人们的印象中，似乎大企业有人、有钱、有资源，在数字化转型中应该更容易，但结果恰恰相反，大企业的烂尾项目比例更高甚至连供应商都找不到，反而是中小企业在质量软件导入项目上速度更快以及成功率更高，吃惊吗？

我们观察到，大企业的项目往往有几个特点：

-大而全

-周期长

-定制开发量大

-甲乙双方人员变动

-发生问题，没人负责，如果人员变化，更是推脱的好借口

-需求不断变化

所以我们的建议是尽量避免以上的事情。

-抓关键

-分阶段

-少定制

-人固定

-责任明

-控变化

没有什么项目在实施阶段完全是丝滑顺畅的，总归会遇到这样或那样的问题。

分阶段的好处是可以集中优势兵力一个问题一个问题有序解决，避免狼烟四起，同时，还可以不断复盘，为下一阶段实施积累经验，避免犯同样的错误，这样更容易保证项目成功。

至于实施进度，对于一个成熟的QMS来说，主要是看甲方的决心和投入的资源，

同样规模的系统，2个星期到2年都是有可能的，我们建议是宜快不宜慢。

12.项目预期寿命

我们很少会期望一个汽车开上20年，软件也是一样，自ERP诞生以来，一直在不断迭代变化，QMS也是一样的道理。因此，只需满足当下和可预见的未来即可，不用过度焦虑。

如果将来有多个工厂，最好查看一下是否有预留这个功能，或者至少有应对方案。同理，如果是跨国企业，就要关注多语言这个功能。

先有企业实践，后有软件抽象。没有人会有上帝视角，甲方不可能关注到所有的未来需求，即使甲方关注到了所有未来的需求，市场上的乙方也不可能都有应对方案。

13.项目风险

做任何事情都不可能100%成功的把握。何况是在企业里实施一个管理软件。所以在整个项目过程中会遇到可预测的，以及不可预测的风险，甚至可能造成项目的失败。同时，在开始时能够识别一些风险，不但可以提早采取对策，某种程度上也可以给万一不幸未来风险发生了，找到“解脱责任”的借口，毕竟早就说过有风险了嘛。所以对于项目风险的管控，就成为项目管理一个不可或缺的部分。

首先要识别出风险，对风险进行分析，然后根据风险采取对应测措施。

比如人员水平、员工意愿、高层支持情况、客观灾难（比如新冠疫情，就会很大程度上影响项目周期），市场经济形势，甲乙双方项目组成员更换，可能的产品技术瓶颈，需求变化，甚至法律法规影响等等。

有些风险可能是通过措施可以消除，有些能够降低影响程度，或者发生的概率，但有些可能确实无计可施。这些都需要在项目规划时进行考虑，并且在项目进行过程中进行持续的监测与更新。

样例仅供参考：

14.结论与建议

根据上述内容的研究分析结果，对于项目在建设必要性，技术可行性，经济可行性等方面进行全面的评价，对项目建设方案提出结论性的意见与建议，对于存在的问题以及争议进行的处置对策与结论。

15.参考文章

-有全能的QMS系统吗？

《海克斯康为什么不断收购质量管理软件(QMS)?》

-MES的质量模块可以代替专业QMS吗？

《西门子MES里面有质量模块，为什么还要收购质量管理软件（QMS）？》

-工业软件巨头的质量管理软件（QMS）都是怎么来的？

《霍尼韦尔为什么用人均4000万人民币收购一家质量管理软件（QMS）公司？》