我的案例

北京德彩汇智图文设计有限公司做图书的录入、扫描、识别、排版、校对、改稿。这家公司用勤哲Excel服务器搭起图书制作ERP，起点是一个很磨人的问题：一本书到底改到第几版了。

一本书进来，先由客户发新稿，做一校；做完返给客户看二校稿，再回来做二校；二校完成又返客户看三校稿。三审三校走完，才轮到收款付款。

每返一次，就多一批修改；每多一批修改，就多一份谁改了什么、改了多久的记录。项目一多，这些记录就散在各人的电脑和纸质本子上。

系统要做的，就是让每一本书的每一步都留得下账。

普通图书的制作周期大约三个月，古籍类全在一年以上，有的项目要做十年。十年是什么概念？经手的人可能换过几批。

人员流动加上长周期，最直接的后果是原始制作明细容易断档。新人接手一本做了两年的书，不知道前面校到第几遍、哪些页已经定稿、客户退回过什么问题。

这种活拼的不是速度，是记忆。而记忆恰恰是公司最难留住的资产。

为了实现ERP集成，公司试过不少软件。它们有一个共同点：使用人必须按软件设定好的格式和业务流程去开通、关闭各种设置。

问题在于，图书制作的流程不是标准件。不同出版社的校对习惯不同，古籍和教辅的工序不同，同一个客户的不同书也可能走不同的路子。软件要求流程服从它，公司却需要系统服从业务。

经过很长时间的筛选和试用，最终确定用勤哲软件。打动他们的不是功能清单，而是搭建方式：从角色定义、部门设置，到表单录入、填表与审批流程，都可以围绕最终要得到的经营数据来组织。

说白了，是让系统跟着公司的管理方式和工作步骤，一步一步扩展，而不是一上来就把流程框死。

系统的主体只有三块：客户信息、制作流程、统计报表。块数少，是因为每一块都要吃透业务。

基础资料是底座：客户、员工、供应商、物料、BOM。对图书制作来说，BOM不是零件清单，而是一本书要做哪些工序、每道工序的计价方式。

底座立住的标志是：新来一本书，不用重新讨论怎么记，照着基础资料选就行。选择代替输入，错误率自然下降。

业务单据的流程，从客户发新稿开始，一校制作、返客户二校稿、二校制作、返客户三校稿，一直到收款付款，全部搬进了系统。

每本书在系统里是一条主线，每一校是主线上的一个节点。节点上记着交件日期、返回日期、修改量、经办人。

这样做的好处，在项目中期才显现出来。做到第三个月，客户突然问某一章改到第几版，翻系统比翻聊天记录快得多。

工作流的处理方式，是把数据录入拆成固定的几步：分任务、到工人、交客户、管理员审核、生成工资、备份文件。

这套设置保证了一件事：任何工作至少三人阅单，也就是一填一审；关键工作多人阅单，一填多审。

为什么要在流程里强制阅单？因为图书制作的错误往往很贵。一本书印出来才发现错页，损失的不只是重印费，还有客户关系。

这张表里，最容易被忽略的是最后一步。文件备份放进流程，意味着归档不是想起来才做的事，而是流程走完的必经环节。

公司把产量与工人收入直接联系了起来。工人填的产量，就是工资的计算依据，不需要月底再由统计员誊一遍。

对计件制的制作团队来说，这一点很关键。工人知道自己今天做了多少、能拿多少，管理上就少了一大半的解释工作。

同时，工作结果可以实时汇总成汇报。哪个组进度快、哪本书卡在校对、谁手上活压得多，当天就能看见。

把产量和收入绑在同一张单上，效率和公平才有共同的度量。

基础数据积累了一段时间之后，公司顺着明细延伸出了一些统计内容的表格。这些表不是为了好看，而是为了回答经营上的问题。

哪些书型毛利高、哪道工序最耗人、哪个客户的修改次数最多，都能从已有数据里算出来。这些结果不仅为业务开展提供参考，甚至可以直接用于管理会计的数据取得。

软件已经正常稳定运行三年多。三年里，最初那套只记流程的表，慢慢长成了一套能算账的系统。

勤哲Excel服务器在这里的价值，是允许这种生长发生：先解决最急的记录问题，再往上加统计、加核算，不必一次设计到位。对周期长达十年的古籍项目来说，能陪着业务一起变的系统，才留得住那些账。