建模第13天:为一个模板字段,我们折腾了一整天

今天是推动公司从电子流程文档转向流程建模的第13天。

13天听起来不长，但这个项目的体量说实话有点吓人。去年规划的产品开发体系流程架构，L2流程组30+，L3流程190+，L4子流程480+。随着更多业务被显性化，L3和L4的数量还会再上一个台阶。我的重心已经从流程架构的微小迭代，转移到了另一个更棘手的问题上：怎么让这些流程架构真正落地？

当前企业的产品、组织、岗位、项目都已经是非常庞大的量级。我推动的这个变革，往大了说，有点像秦朝的“书同文、车同轨”——只不过是在一家公司里推行而已。

流程管理的理论已经很丰富了，甚至有点过于丰富了。落到具体企业、具体领域，到底该怎么实践？我的体会是：建模实践的过程，跟企业用的工具有很大关系，也跟流程成熟度有很大关系。（关于建模工具的思考，后面单独写一篇。）

目前我就是用公司现有的建模系统——一个比较成熟的商业软件——边摸索边推进。把过程记录下来，弯路肯定少不了，但我现在越来越坚信：管理体系建模，方向是对的。

因为是随笔记录真实场景，不一定很有逻辑，工作做到哪就写到哪。项目不按计划走是常态，但我还挺有冲动的，每天写写这些实践过程。

今天的大部分时间，都花在了一个看起来很小的事情上：“工作产品”的描述模板。

先解释一下。“工作产品”就是一个活动的输出。在当前建模平台里，每个流程空间的工作产品都是统一管理的。比如流程管理这个领域，在流程架构中是作为一个L3流程，在建模平台里独立建了一个空间。

空间的第一层目录有五个：工作流和活动、角色、工作产品、里程碑与节点、指南。我们在“工作产品”目录下，按L4子流程建文件夹，所有工作产品放进去。

每个工作产品有一堆属性字段。系统自动生成的有“输入于”和“输出于”，手动添加的有文件、指南和描述。今天折腾的重点，就是描述里的“模板”。

描述只是原生系统里的一个字段，空白到你想填什么都可以。但我们作为管理方，得让大家知道填什么，不能随心所欲，所以得给它配个模板。这些模板都放到通用元素库里，每个工作产品填描述时，去里面调用，保持一致性。

原来的模板有十个字段：

看着挺全的吧？跟我们体系文件的要求相差不大。

但问题恰恰出在“相差不大”上——那不多的几点差异，就足以让人改到崩溃。

比如要把“执行团队”改成“角色”，要把“备注”改成“存档责任单位”。想想目前系统里上千个工作产品的量级，这个改动量还是很恐怖的。

但为了后人乘凉，这次仔细想好了，统一改。我常拿秦始皇焚书宽慰自己：我现在就是规范的制定者，瞻前顾后做不成事。不能想太完美了，先动手。

十个字段改好了，填写说明也都现成的。本以为往里填内容就行了，结果发现：呈现出来的效果太差了。

问题出在“描述”这个字段上。

十个字段放在一个10×2的表格里，列宽是均分的。其他字段还好，但描述里的文字有的非常长，就像在Excel里列宽被压缩后，长文本把行高拉得巨高。建模之后打印出来的文件，就因为这个“描述”，表格足足占了三页，阅读体验极差。

我尝试过单独为这一列调列宽，但改善有限，同时还压缩了其他列的宽度。比如“编码”这个字段，被强制换行成三行甚至四行，看着非常别扭。

最后的解决方案是：把“描述”字段单独拎出来，放在表格外面。 另外“输出物“本身就是与工作产品是一个名称，完全多余，直接删除。其他字段的长度都比较可控，从十列变为八列，多出来的空间让它们自在了很多。

今天花了很多时间跟小组成员一起讨论、调整、填写内容，打印看效果。最后的主要成果，似乎仅仅是一个模板。放到再上一层领导那里，就要被K了。

但我认为这非常重要。

在推动建模的过程中，唯有自己亲自动手，才能知道这里面每个字符、每个宽度，都是为了提升用户体验。 这些细节看起来琐碎，但用户每天面对的就是这些东西。模板好不好用，字段合不合理，打印出来能不能看——这些直接决定了大家愿不愿意用。

管理体系建模，不是画几张漂亮的架构图就完了。它最终要落到每一个工作产品、每一个字段、每一行排版上。

第13天，为一个模板折腾了一整天。我觉得值。