案例：公司的QS部门在审核时发现，有的业务执行已经搬到了线上完成，但文件中的交付件还是线下的内容。QS认为造成这种问题的原因是IT开发线上的功能时没有QS部门的工程师参与审核，导致开发的功能和文件要求是不一致的，而且这种问题可能很普遍。因此提要求给IT部门，要求在系统开发需求的评审环节增加QS工程师的评审节点，以确保IT开发需求和文件要求是一致的。
对于QS部门来说，公司的数字化程度越高，越容易碰到这种IT和文件不一致的问题。对于国内的QS部门来说，QS的职责就是确保公司内的一切符合质量体系的要求。而审核是达成这个目标的重要（有时候甚至是主要）手段。因此QS部门提出要在需求评审时也参与进来是一件非常自然的事情。
但自然并不等于合理。案例中的问题仅仅是IT功能不符合文件要求，这个不符合从源头考虑并非仅仅是IT决定开发时没有QS参与而已。
其实不论是IT也好，文件也好，最终都是承载业务、支撑业务的手段和工具。业务的运行过程（即业务流程）随着业务的需要，可能随时都需要优化。这种优化可能源自IT技术的应用或发展，也可能源自业务活动顺序组合的变化。不论是哪种变化，业务部门首先是要基于这种变化设计业务方案（这里的业务方案更多的是架构层面的东西，会包含流程、组织和IT的方方面面）。
方案敲定的时候，业务部门往往并不会直接开发流程文件，而是会先考虑把IT工具开发出来进行方案验证，或是先在线下试点新的业务活动顺序。由于现在数字化进程加快，很多的业务都可以借助IT化来增加效率，因此新业务方案往往会伴随着IT工具的测试。当新的业务方案被验证确实可以运转，并且达到了业务目标时，IT工具往往已经上线运行了一段时间了，这时候除非是发生了什么问题，或者有其他的外力推动，否则业务部门可能就不会去发布新的业务方案所对应的流程文件。
业务优化阶段：业务方案→（流程文件开发）→IT开发→业务方案验证→业务方案推行
如果把以上的分析拆解成几个阶段，就会发现案例中的问题虽然表现是业务部门没有动力去更新流程文件（也是基于这种原因分析，QS部门才会考虑借由在IT开发环节增加管控节点的方式，迫使业务部门不得不把流程文件开发好），实质上是流程文件的作用和价值没有在业务部门内发挥足够的作用。
对于业务部门来说，平时做业务时使用的也不是流程文件而可能是具体的表单工具或IT系统，流程文件可能更多的是应付内外部审核的工具，对于业务部门的业务来说帮助不大。如果在业务方案已经借助IT固化且运行良好的前提下，没有必要再花时间去撰写流程文件了。
流程文件的价值：业务呈现形式、业务指引、IT开发依据
既然如此，解决问题的方式其实是去考虑如何能够让文件的价值提高，使得业务部门愿意主动及时地去更新文件，使文件能够与业务实践一致（IT只是业务实践的一部分而已，还有很多线下的活动及要求也是文件的一部分）。
这种及时更新，可以分为如下几种情况：
- 业务方案变更时更新：按照业务优化的阶段，在业务方案确定后主动开发更新流程文件，使提出的IT需求和拟更新的文件一致。在IT需求验证时，同步更新发布IT和文件；
- 业务方案变更后更新：业务提出IT需求时，不考虑文件的更新。等IT运行验证一段时间后再进行文件更新。
QS部门可以发挥的作用除了在节点环节中增加管控点来控制外，还可以选择通过事后的审核来促进业务部门对文件的更新。同时，增加文件的刷新周期要求，使得业务部门养成主动刷新文件的意识。
另外IT开发部门在设计IT方案时如果对流程文件有要求，也可以促使业务部门主动更新文件。
还有一点，文件的体系性和文件与什么IT系统需要建立关联，也是这个问题的核心之一。
