本文希望引导网友思考，现在或将来，是否该帮公司导入工作流？是否该学习微软的 WF？何时该导入？如何导入？本帖较偏向管理理论，非编程技术文。读完后若有兴趣深入学习者，可参考本文最下方的「相关文章」连接。
其实不然，不论企业规模大小或行业别为何，工作流有一定的重要程度。大家都知道速度与应变能力将是 21 世纪企业不可或缺的能力，因此就不得不去思考工作流与 e 化的结合，将会让你的企业成为下一个 10 年的{lx1}族群。因此，我们来思考，哪些企业最需要将已经 e 化的系统再导入工作流，以下为思考重点：
- 企业的据点分布：企业的据点越分散、据点越多，对工作流的需求越大，因为人员分散各地，透过传统的沟通方式已无法有效地管理。
- 企业人数的多寡：一般来说，越多人的企业对工作流的需求越大，人数少于 20 人的企业较没有需要 (人数是指计算机用户数，非员工总数)。小型企业的员工人数少，每个人都身兼数职，导入工作流后，有可能造成自己输入的单据，又交给自己批阅，或别人签完后又丢给自己待办，在效率上反而不如传统的信息化系统。
- 行业别特性：若行业的特殊性，是人员会经常流动、常出差或开会，对工作流的需求就越大。此外，服务业会比制造业需求大，因为服务业的机动性与变化性较高，例如有 1000 名员工的服务业，和有 1000 名员工的制造业，前者对工作流的需求会大很多。
- 有强烈的 BPM 需求：必须依赖制度的落实与时效性要求特别高的企业，对工作流的需求就越高，以透过工作流管理来落实 BPM (业务流程管理)。
从企业 e 化走向工作流
- 硬件及网络部门：负责掌管硬件维修、网络服务、防毒、网站及邮件服务器基础设施。
- ERP 应用部门：掌管企业核心帐务与应用，从业务订单、生产管理到出货，以及应收、应付等财务相关，与人力资源、供应链...等等，是企业的核心。
- OA 或 KM 部门：以企业知识的累积、分类、复用为目标，因为涉及到企业的文件宝库及工作流，可以说是企业营运管理的xxxx。
我们在导入工作流的过程里，最基本概念就是以电子表单，搭配工作流来打造 OA (办公自动化) 电子审批系统。在填表或流程审批过程中，经常有某些数据是来自 ERP 系统，例如企业常用的请xx，就会用到 HR 系统里的个人数据，像：假期天数，基本薪资...等等。当流程完毕后，又会把请假扣款金额更新到 HR 系统里。复杂一点的应用，如：ECN / ECR (工程变更通知 / 工程变更申请)，涉及的部门，从：业务部、设计部、生产部、采购部、品管部门；而系统数据交换上，会牵涉到：业务订单系统、合约管理系统、生产管理系统。在文件管理应用上，ISO 文件审批管理系统就是一个很好的实务应用，因为涉及公司各个单位的管理规章。
通常一个工作流开发，预期要有如下的用户操作：
- 请xx送出后，要能自动送到直属主管。主管审批后，按请假天数逐级上呈、予以核决。
- 请xx填表时，输入请假时间，就能自动计算剩余的假期或请假天数...等等。
- 能自动 E-Mail 通知，及放入待办事项文件夹中。
- 自动稽催...等自动化的功能预期。
这些预期都需要有一套完整的架构来支持工作流的运作，因为我们都希望未来在维护时不要有太大的负担，基本上要做到：流程修改、组织变动、表单修改、权限管理...等，模块都要独立分离，且不能相互影响，因为实务上 10 张表单 + 10 个流程 + 5 个部门 (大约 25 个用户) 是很容易开发跟维护的；但当企业扩展到 100 张表单 + 100 个流程 + 3 个分公司 * 5 个部门 (150 个以上的用户)，这时就可能天天会因为业务变革或组织调整，而影响到工作流，造成常有大量的维护、调整工作要进行。所以在实务推动中，就会考虑到组织结构 (职务与人员的虚拟对应) 与工作流 (包含主流程与子流程及流程版本) 独立分离，这样才能让工作流推展顺畅。
许多国际的 ERP 大厂，到了台湾会发生水土不服的现象，其实工作流的引进也有同样的问题。国外的组织架构已经进化到扁平化矩阵式管理，但台湾还是以金字塔型组织架构为主。虽然某些公司已经扁平化，但还是东方传统金字塔型架构，所以包括市场占有率{zd0}的 IBM Domino/Notes，在面对金字塔组织的管理，还是需要新建或修改内置的组织数据库结构。另一个严重的问题，是西方在管理流程是任务导向，注重稽核点，且协同合作的观念很强；但台湾的企业，多半职位、工作职责及其流程会很固定，且流程又会因为业务需求的变动而调整，观念上是自己管好自己的事，所以在职位权限表、流程修改方便性上，必须加强许多「东方管理特色」上的东西，来完善工作流的核心架构，此时表单设计反而变成最简单的一个环节了，难题变成与其他系统相互连接的接口上。
有了完善的工作流基础架构后，接着要先推动哪一类的电子表单呢？现在很多公司都在推请xx、公出单、加班单、文具用品申请、ISO 文件管理、OA 行政表单，因为推行上较容易。但是从管理层面来看，这些并无法给企业带来价值跟效益。而像公文审批、任务交办追踪管理、跨部门联系支持请求单、项目管理、工程设计变更管理、协同设计...这些才是对流程变革及核心竞争力提高有帮助的，且能提升部门之间的信息传递效率、大量减少沟通上的错误。
工作流的推动，从公司内部可以延伸到供应链上下游厂商间的协同工作，例如：业务单位发出一批出货单、订货单，上下游厂商可以透过互联网进行收单确认、交期确认、分批交货计划时程确认...等等，只要公司核发给他们账号密码，就可以进行供应链协同了，非常方便。但是当工作流的推动往公司外部延伸时，立即会面临到工作流软件授权费的问题。授权费有的是依照用户数或流程数目来计费，一般来说国际大厂都很高，但功能也非常强大，如：、、、。当中小企业面对这样高的成本，通常只能做个示范项目 (通常是 25 个用户左右)，或改选择台湾本土的工作流软件，且基于预算考量，只能选一般的 OA 套装软件简单用用而已，且未来扩展上也会有问题，没有源代码也不能修改，且其工作流也不是业界标准。如此一来，可能又要像 ERP 系统的导入那样，在跌跌撞撞中推倒重建、痛苦摸索个好几年。
有些有研发实力的公司，会采用 Java 开放源代码的工作流工具，或微软的 WF (Windows Workflow Foundation)，如此一来，既符合业界标准又没有用户数授权费的问题。之前笔者带领过几个上市公司推动工作流，集团都是上万人，用的是国际级{zh0}的工作流系统，当时也同样为了上万用户的授权费大伤脑筋。如今时机及技术都已相当成熟，客户端就是 Web Browser，服务器端也没有用户授权数量限制。
微软 Windows Workflow Foundation 逐渐流行
WF 可作为 Windows 平台上的 Workflow 共同标准，微软提供基本的「活动 (Activity)」组件，让大家针对企业的工作流以组件的形式来开发。可预期的是未来将出现更多以 WF 为基础的商用软件，而且也逐渐影响到现有的 Workflow 厂商，将产品改成以 WF 为基础。
微软的 WF 到底架构如何呢？首先它的引擎是可以有状态的、持久化的，透过序列化的机制能记住上一次执行的状态。此外，它也是一个异步执行的工作流程应用程序，不用让调用者一直等待。它还提供了一个友善的视觉化工作流设计工具，用来描述应用系统所需要的处理过程，透过图形化界面，让开发人员能够将应用程序逻辑和商业逻辑分离，达到容易理解与维护的目的。
WF 还为开发者提供了一系列的流程活动，以组件化的方式呈现，结合流程引擎，让活动组件可受到外界的指挥来执行对应的方法。WF 可整合 Web Service 或其他远程服务，以整合流程中各个活动组件、需要配合的商业逻辑。在 SOA 面向服务架构风行的今日，与其他服务的整合变得更为重要。
但事实上，WF 只是实现 Workflow 系统的基本配备而已，企业若要利用 WF 来自行开发工作流程系统，将是非常辛苦的差事。目前台湾市面上，直接提供 WF 的现成组件，并能直接整合 WF 引擎，可让企业xx不必开发程序，就能直接享用 WF 的成果。这些产商根基于 WF 的产品，可提供 10 多个企业常用的流程组件，透过 WF 的 XOML 格式来定义企业流程，可轻易做到：会签、串签、加签及复查的动态签核，并结合 E-Mail 的发送来通知用户进行在线审批 (签核)。
本文出自 讯光科技。本博客已获得该公司授权发表于内地网络。
讯光科技 - 软协e化博客 (台湾台北)：
----------------------------------------------------------------------------
相关文章：
[2] 相关博客 (按英文字母排序)
[3] WF 4.0 基础篇 (三十 完) 对学习 WF 的一点建议
[4] Windows Workflow Foundation 教程
[5] .NET Framework Developer Center
[6] 请问 WF 可否实现 OA 那种自己去定义的工作流
[7] 《WF 编程》系列 1-45
[8] 以工作流来实现企业 BPM (作者：讯光科技，繁体中文 / 台湾网站)
(何谓工作流？企业为何要导入 Workflow 系统)
[9] 英文、简体中文、繁体中文 IT 词汇对照表
----------------------------------------------------------------------------
