背景

本人5年Java开发经验，做过web和swing的开发，数据库主要使用Oracle，其他杂七杂八的技术也都用过一些。从去年开始，换了一家非IT公司，在这里IT作为业务的支撑，本人主要做系统分析的工作。刚刚转型，做的东西不像做技术，没有实实在在的东西，大部分时间是打补丁、重启系统、写文档和沟通。虽然技术上简单，但是业务上却复杂。要是按照我以前的想法，会觉得现在的工作形式大于内容，做了一段时间，觉得合理的安排工作和完善的方法，可以把错误将至很低。打个比方，好比种树，技术好的人可以种出一课参天大树，合理的工作安排可以创造出一片森林。

前言

很久不写东西了，今天开始，把这一年多做的工作总结一下，也算给自己一个交代。由于这一年的工作主要负责实施公司的工作流项目，因此本文主要阐述工作流的一些经验和教训，分析工作流的一些特点和注意事项，希望和大家分享讨论。

接触工作流

由于项目安排，把我调到了工作流项目组。虽然以前业务背景不是工作流，不过在以前的工作，也多少使用过这样的系统，比如报销，请假等。不过概念不难理解，简单可以理解为电子化，自动化审批。

 

首先介绍一下公司这个项目的背景。由于公司在全国各地有众多的子公司，而且采用的是逐级的集团管控模式，因此，有大量的表单需要在各个自动司和管理层所在地进行审批，不但时间长，而且有些重要文件还会传丢，因此需要一个专门的系统来管理这些流程，那么工作流系统应运而生。由于公司此前做过流程梳理的工作，在大家看来，有一个官方发布的审批流程遵守，我们在后面称这个规范为《审批规范》（后面要详细讨论这个规范的正能量和反作用）。经过选型，最后确定采用找一家有经验的公司做定制开发的方式进行。那么，也使我有机会参与了项目的开发和实施的过程，其中遇到的一些问题，就是此后文章主要讨论的内容。

认识《审批规范》

 

由于集团公司与各个子公司可以分别看作一个独立的公司，因此，很多做的有相当规模的子公司自己内部的流程。公司为了便于集团管理，发布了需要全部公司需要遵守的《审批规范》，同时，发布了该规范对应的一系列表单，各类表单加在一起有近百张。规范发布的相当正规，有过几次培训，之后又有几次更新。工作流项目最重要的就是流程梳理，这里也是工作流项目最复杂的一环，由于有了这样一个规范，一切看起来很美。

项目在一片祥和中开始。主要领导都认同工作流项目以此作为蓝本进行开发和实施。第一个问题出现了。在项目组内部，没有人去质疑该《审批规范》的实际实施效果。由于之前一直采用手工审批，审批的随意性非常大，由于各个公司的规模不同，层级因此也不同，比如有些公司只有有总经理，还有些公司不但有总经理，还有副总经理，甚至总经理还有秘书，这些在《审批规范》中都没有体现。其实，如果仔细推敲该规范，是可以发现这个问题的，如果公司只有这几个主要领导进行审批的话，那公司那么多主管岂不是要丢了饭碗。可惜的是，这个问题直到项目中期，部分表单上线后才体现的越发明显。当然导致这个问题的原因还有系统的功能，这一点在后面的章节中会继续讨论。

前文提到，与规范一同发布的还有表单。经过领导决定，系统采用与原表单相同的样式作为数据录入的界面。这样做的最大好处是用户容易理解各个填写的项，只要凭借原来手工填写的经验即可完成。但第二个问题出现了，由于以前的表单，主要针对手工填写与审批，因此，表单中有相当浓重的手工色彩，比如多个流程对应同一张表单，即使普通的电话费报销，也列出了CEO签字的位置；原表单中没有选项去标识表单对应不同的流程；另外，由于要与原表单保持样式一致，使用了大量css代码，但由于开发水平有限，并未达到与Excel一样的效果。种种的这种问题，限制了开发者对输入项的把握，有时候为了讨论是不是在表单中增加一个选项而浪费大把的时间。其实，我觉得一个正确的方式是适当的对表单进行分类，针对每一类表单做电子化改造，使其适应web常用操作，同时增加必要的流程选择标志。而表单样式，应当放到打印中，制作与原表单样式一直的打印模版进行处理，而不是纠结于录入时样式是否与原表单相同。

 

今天刚刚开了个头，老婆晚上做的麻辣香锅差不多消化完了，睡觉了，待续……

注意：为了避免本人被公司炒鱿鱼，因此本文不会透漏任何涉密的内容，如果有会立即删除。也请大家不要随意猜测，感谢大家的关注

写得不错，初步展现了一个有众多子公司，采用逐级集团管控模式的工作流系统的一些业务信息，本人也做过一个简单的工作流系统供公司使用，公司一千多人,二三十个部门，另外也有很多子公司和外办，但业务都简单，管控也不复杂，所以系统本身也很简单，也很实用，但能看到这方面的一些复杂的业务信息很不错，期待看到下文
另外我的一些看法：1.表单有近百张，这个要么是业务特别多，特别复杂，否则不应该有这么多，物以类聚，人以群分，编程也讲面向对象，这么多表单肯定有很多是能以类来兼容通用的。
2.开始就有一个官方强制推行的《审批规范》，我一看到这里个人就感觉会出大问题在这，因为我觉得审批流程太灵活，不谈什么主审，代审，会审，谁操作，委托谁操作，评定反馈等等，流程也有很多需要自由流程，有的还需要支持流程返回、索回、跳跃、变向、改稿，无影响再造，流程合并、衔接，流程单项处理、集成处理等等，不可能以文件来规范，而且这（流程控制）刚好是工作流的核心，出了问题，后果可想而知，有了《审批规范》，开发肯定是简单了，直来直去，不用管灵活性，但肯定容易夭折。
3.过多的在意在表单的样式是否和原来一样，是否操作体验好，打印是否和原来纸张页面一样等等，这个是精力没用到对的地方，核心是流程部分，这个没弄好，其他都是空谈，这个弄好了，这些都可以慢慢解决，我个人认为，之所以会出现这种情况，应该是和非技术型的领导起决定作用有关，他们往往更重视表现的东西，做技术支持的应该在这个地方起到引导作用，定位于技术和业务的桥梁，忽视任何一方，桥梁都可能倒塌。
当然，上面只是我重复了楼主的观点，楼主在里面都有提到，我只是捧个场，希望看到楼主更深入的下文。

关注。

如果公司只有这几个主要领导进行审批的话，那公司那么多主管岂不是要丢了饭碗

这个问题可否详细探讨下

非常感谢您提出了很多好的建议，看了您的回复，觉得您对工作流系统十分的了解，期望有机会与您进一步沟通

由于公司的业务决定了业务特别复杂，不同的部门在有些公司可能都有资格独立成子公司了，但在本人所在的公司，作为管理公司，需要各个部门协调审批，因此表单较多。但是结构比较清晰，类别分的也很明确。


非常正确，当时确实方向走偏了，过多注重样式，而忽略了流程的灵活性。我觉得这个是公司内部的政治问题，大领导的做事方式就偏重于可见部分。现在确实提出来增加索回，跳签等问题，这些都涉及到了核心的代码，改起来非常的麻烦。而且有些是无法改变的，妥协后的操作，感觉有点不伦不类。


由于公司还算正规，因此，之前无系统时期，也花费了相当的精力对审核流程做了梳理，这些表单也是当时的产物。我觉得这点工作做的非常好，并且在手工时期，确实取得了非常好的效果。但是正像文中提到的，问题也来了，做电子化时，并未对其进行应有的改造，导致现在的项目进展非常艰难。

谢谢您的关注。其实这个很容易理解，表单上只有几个部门大领导签字的位置，但是实际手工操作时，都是由其副总经理，经理等先进行审核，通过后找到领导口述，直接签过，有些业务大领导根本不了解细节，因此就造成了审批系统的复杂性

持续关注。。。。。

参与哈个人看法：
1、样式、或者说最后打印出来的表格等这个其实可以用很多其它方式实现，不一定非得体现在流程等中；
2、你这个 完整的体现了一个类似一个政府的审批流程，个人意见是把流程配置为灵活性异动。比如子公司范围内怎么申报、初审、复审等，采用配置进行滚动；上升到整个公司，子公司相对总公司 可采用同样的方式进行。至于什么人初审、或者复审 完全在于配置怎么处理。这样就避免了 忽略一般的主管等，当然比如总经理等也有可能不直接操作而是秘书等代为处理。

您说的第二点中提到“活动性异动”我理解为每个人可以基于系统中流程提供加签和减签的功能。我觉得应该是这样的，否则不能能用同一个流程约束整个公司，因为每个子公司的规模和人员不同，有些公司可能一个人身兼数职，只需要他一个职位审批就可以了。

我觉得流程中应该增加“子流程”的概念，用户的管理员可以在原有节点中再细化，这样可以更好的符合各个下属公司的流程，这样既保证了集团的要求，又满足子公司的实际情况

呵呵，就是这个意思  还是你理解和表达能力强啊。 一般我说什么好多人都云里雾里，说两遍是必然的。  

我也发表下意见，我一直从事企业信息系统开发，公司现在有5000多人，组织架构分了4层，全国有30几个办事处，已实施了很多流程，如请假、报销等。对于楼主项目实施，想说3点：
1、项目实施前，流程没有梳理好。电子流程和纸质流程是又差异的，有些节点可能需要线下，

上面误提交了，再提交一次。
我也发表下意见，我一直从事企业信息系统开发，公司现在有5000多人，组织架构分了4层，全国有30几个办事处，已实施了很多流程，如请假、报销等。对于楼主项目实施，想说3点：
1、项目实施前，流程没有梳理好。电子流程和纸质流程是有差异的，有些节点可能需要线下，有些为了电子化需要加节点。我们实施流程时，都要求公司流程部门先对流程进行梳理，我们IT人员在对着设计电子流程。
2、表单需要尽量统一，100多个表单肯定不合适，如果是同一业务，肯定可以统一。不能统一成一类，统一成几类或10几类应该是可以的。
3、输入是没有必要那么注重和纸质样式一样，通过做报表打印，只要预览打印样式和纸质一样就可以了。