程序文件编写:从模板到落地

新来的体系工程师花了三天，写了一份文件控制程序。满怀信心交上去，第二天就被打回。

质量经理的红笔批注只有一句话："你这是抄标准的，不是写程序的。"

程序文件到底该写什么？怎么写才能落地？这个问题困扰了无数体系工程师。

01

程序文件是什么

一句话定义：程序文件是过程的操作说明书。它描述的是——谁，在什么时候，做什么事，怎么做。

质量手册告诉你"体系长什么样"，程序文件告诉你"每个过程具体怎么跑"。一个管骨架，一个管肌肉。

ISO 9001:2015要求"形成文件的程序"的场景在减少，但"过程的运行准则"依然需要明确。不管你叫它程序文件还是过程规范，本质都是一样的。

程序文件存在的唯一目的：让过程的执行者照着做就能做对。

02

程序文件的标准结构

一份规范的程序文件，通常包含七个要素。不是每个都必须有，但缺少任何一个都可能留下执行漏洞。

目的——为什么写这个程序；范围——管什么不管什么；职责——谁负责干什么；定义——关键术语解释清楚；流程——步骤怎么走；相关文件——引用了哪些上位和下位文件；记录——会产生哪些表单。

七个要素里，"流程"是灵魂。其他六个要素都是为流程服务的——目的说清为什么做，范围框定在哪做，职责明确谁来做，定义统一怎么说，相关文件和记录连接上下游。

流程写不清楚，其他写得再漂亮也是空中楼阁。

03

流程图化：让程序可视化

好的程序文件，文字描述之外，一定配一张流程图。文字告诉你逻辑，图形告诉你全貌。

一张流程图的价值在于：任何人扫一眼就知道这个程序从头到尾怎么走，哪里有分支，哪里有决策点，哪里需要评审。

以文件控制程序为例，看看一个完整的流程图长什么样。

注意流程图里的决策菱形——"评审通过？"这个分支是关键。没有分支的流程图是假的流程图，真实的过程一定有判断和回路。

还要注意那个虚线的反馈回路——执行中发现问题，触发修订，重新走流程。这才是闭环管理。

04

程序文件的可执行性检查

程序文件写完不算完，还要过一道关——可执行性检查。用5W1H逐条追问，任何一项答不上来，就说明文件有漏洞。

Who——谁来做？岗位是否明确？What——做什么？动作是否具体？When——何时做？时间节点是否清晰？Where——在哪做？地点/系统是否指定？How——怎么做？方法/工具是否提供？How much——做到什么程度？判定标准是否量化？

检查的最佳方法：找一个没参与编写的人，让他照着程序走一遍。如果他走通了，文件就过关了。走不通，就回去改。

05

程序文件常见问题

程序文件最常见的四个问题，几乎每个企业都踩过：

一是照搬标准。把ISO条款原文搬进来，换个标题就算自己的程序。结果审核员问"你们具体怎么做的"，答不上来。

二是职责不清。写"由相关部门负责"，但没说哪个部门是"相关部门"。出了问题互相推，谁也不认账。

三是流程断裂。上一步做完，没说下一步交给谁。或者有交接但没有交接标准，"半成品"在部门之间游荡。

四是缺乏可操作性。写了"应确保质量"，但没写怎么确保、用什么方法、达到什么标准。等于没写。

程序文件不是写给人审的，是写给人用的。

写之前问自己一个问题：如果把这份文件交给一个新入职的同事，他能照着做吗？

如果能，恭喜你，这是一份好程序。如果不能，那它只是一部"给审核员看的表演稿"。

从模板到落地的距离，说远也远，说近也近——近到你只需要多想一步：真正用它的人，需要什么。

想通了这一步，程序文件就不再是纸上谈兵。