办公自动化建设思路汇报

时间上 同一用户在不同时间不同 发展时期对软件系统的需 求的不一致性
用户需求的个性化
OA系统受到的挑战 研发周期长、无法深度满足用户个性化需求 系统实施期间用户的需求变化快、需求难以把握 开发另外一个系统时一切从头做起 系统的维护成本大，随着时间的积累，系统越来越庞大 、越来越难以维护 面临很大的市场不确定因素
软件的灵活性和通用性
OA系统层次的演变－加剧了需求与建设的矛盾
• OA系统经过多年的演化，呈现出以下的发展趋势
– 从深度上来看：对于传统的公文处理，要求更多更细的功能和特色 （如详尽的统计分析、监控跟踪、实现更复杂的办理逻辑等）；对 于接入的方式，从普通的PC扩展到VPN接入、移动设备接入；对 于交互的模式，从Web扩展到WAP、短信等； – 从广度上看：OA系统除了传统的公文处理，需要适应更多的行政 管理活动（如报销、意见调查、绩效考核），包含更多的业务模块； OA系统的流程需要与其它业务系统的流程有交互和整合的能力； OA系统需要能够融入到更高层次的企业信息化体系中（如EIP、 ESB等）
用品申领
物品/礼品分类 物品/礼品信息 仓库信息 供应商信息 安全存量 申领规则 物品/用品申领
基 础 信 息 及 规 则 工 作 流 引 擎
第二代OA系统（续）
• 基于Domino的OA系统，也逐渐暴露出种种弱点
– Domino在九十年代，是一个划时代的杰出产品，但是由于研发年 代的关系，其体系结构较为封闭，虽然几经改进，整个体系趋于老 旧； – Domino使用自己专有格式的文件型存储（NSF文件）。其突出的 弱点在于：随着文件体积的增长，性能下降很快，需要不断增加硬 件设备；全文检索不够精确；很难实现在关系型数据库中非常成熟 的各种关联和查询功能；
发言提纲
• 公司情况汇报 • OA系统建设总体考虑 • OA系统功能设计与实现 • 同类案例汇报 • 优势小结 • 致谢
设计框架
第一部分：
基于工作流引擎实现企业内部广泛的协同作业
基于工作流的协作中心效果图
办公流程
收发文 签报 传真电报 信息审批 ……
业务流程
电子报销 客户投诉 用品申领 客户响应 资源预定 增值业务协同 集团客户生产流程…
线性
循环
ቤተ መጻሕፍቲ ባይዱ
分支
会签
加办、转交
知会
回退
条件
子流程
子流程
主流程和子流程数据交换 子流程 主/子流程在单一视图上 的痕迹查阅
完善的流程权限控制
• 运行权限 • 设计权限
催办督办
短信事务办理提醒
第1.2部分：
Web客户端功能
统一待办事宜
集成现有OA系统待办公 文流程和未来各类待办的 业务流程
流程查询
OA中的各种办公流程
Call Center中的投诉流程
电信业务中的各种工单流程
没有专门的支撑工具
传统数据层面的开发流程
• 目前大多数软件产品采用的方法
各种系统中的常用基本操作 仓库管理中产品的新增、 修改、删除、查询 人事管理中人员的加入、 离职、部门调动、查询 供应商管理中厂商的新 增、修改、删除、查询 其它各种增、删、改、查
ERP
CRM
SCM 开发体系
业务建模工具： 用户主导、快速 开发、灵活调 整、持续完善
应用构建平台具有的特点
• • • • • • • 技术和业务剥离 以业务导向和驱动的、可快速构建应用软件 开发速度快 系统灵活性高 系统集成性好 面向业务的设计模型 技术无关
基于应用构建平台开发模式带来的好处
– 在传统三层次架构上，使应用软件多了一个层次，并将应用软件的业务 逻辑和开发技术分离开来； – 在平台之上快速形成各种OA应用系统； – 使应用程序的结构更加清晰； – 大大缩短建设周期； 开发周期 – 灵活的根据用户的需求快速的进行业务调整；
第二部分：
OA系统建设中的典型困难
OA系统建设的典型困难
用户需求非常多 变 系统的开发周期 很长 随着需求的变化 系统变得越来越 庞大和复杂 投资浪费、升级 困难 系统的稳定性、可 维护性、可扩展性 变得越来越差 需求的变化带来 程序的结构更加 混乱
OA系统开发和实施困难的根源
矛盾产生的根源
空间上 不同用户对软件系统的需 求的不一致性
• IBM规划的Domino路线图中，Domino的最终归宿 将是完全融入基于DB2、WebSphere而构建的 J2EE架构中。这也是群件系统的发展趋势。
第三代OA系统
• 第三代OA系统（2000年起）
– 基于开放的J2EE架构或微软的.Net平台构建。完全的N层次体系 （通常为三层：展示层、业务逻辑层和数据层），大部分基于B/S 架构； – 使用关系型数据库作为数据存储；使用应用服务器承载企业应用； – 依托底层架构的优越性，系统的灵活性和扩展性较强，性能响应较 基于群件的系统平滑； – J2EE平台的优势在于研发较早，产品众多，标准开放，得到大多 数业界主流厂商的鼎立支持，在企业系统领域已经有很成熟和深入 的应用，是当前建设企业信息系统的首选； – .Net平台的优势在于对XML及Web Service等新技术的内建的完全 的支持，其本身也是一个很优秀的平台，微软利用其在业界的影响 力大力推动，有部分成功的应用，但在国内企业高端应用较少，其 在大规模应用环境下的可靠性和适应性尚待观察。
办公自动化系统工程 建设汇报
发言提纲 • 公司情况汇报 • OA系统建设总体考虑 • OA系统功能设计与实现 • 同类案例汇报 • 优势小结 • 致谢
第一部分：
OA系统技术架构演变
第一代OA系统
• 第一代OA系统（90年代中期至后期）
– 基于C/S架构，两层次架构（前台客户端、后台数据 库）； – 完全定制开发，需要从底层开始编码，使用早期的RAD 工具（VB、PowerBuilder等）协助开发； – 缺乏流程引擎的概念，所有功能均固化于代码中； – 并发性能很低（一般通过直连方式，后台数据库难以承 受过多的并发连接）； – 部署困难、基本不具备定制性和可扩展性、对用户需求 变更基本无法在短时间内做出响应； – 此类OA系统目前已经趋于淘汰；
应用构件平台＋小模块通用开发框架＋良好的实施项目管理＝成功
第四部分：
OA系统建设总体思路
OA系统建设总体考虑
• 选择正确的技术路线，基于J2EE架构建设
– 开放性、跨平台和易于集成异构应用 – 先进性和成熟性，是企业信息化主体框架的一致选择
• 建立健壮的企业信息门户基础框架 • 采用快速应用构建的方式提高IT能力
图形化表单设计
• • • • • 不需要编码 主从表 跨数据库 图形化 标准开发接口
流程设计工具
• • • • 零编码 图形化工作界面 多级授权机制 轻松应对各类复 杂业务 • 标准开发接口
各种复杂的流程路径设计
• 支持顺序、分支、循环、 条件等多种方式的跳转； • 支持多级嵌套子流程； • 支持一个步骤单人、多人 处理； • 支持通过标准数据库接口 存取所有流行的大型关系 型数据库； • 支持组件接口，可以实现 复杂的业务逻辑处理。
新建系统
现有产品
采用应用软件平 台构建应用系统 扩展性
风险、成本
应用构件平台是又一个银弹吗？
• 应用构件平台不代表着建设一个OA系统，一行代码都不用 编写，而是意味着对于一个典型的OA系统，最核心、最常 用的功能都是通过配置来完成部署和变更的。这意味着用 最短的时间完成了最核心最常见的功能，这是任何OA项目 成功的重要保证； • 应用构件平台并不能完全覆盖一个OA的所有应用，特别是 一些高度个性化的小模块，是无法通用化的。这些小模块 的建设，需要有一个良好的开发框架来保证建设速度、质 量和扩展性； • 我们的OA建设成功公式是：
门户平台：包括内容聚集、应用聚集、个性 化管理、统一应用资源管理等 报表平台：各类业务报表的汇集、设计和展 示以及安全控制等 工作流平台：包括组 织架构管理、业务处 理、业务工作流、业 务集成、业务自动化 及安全控制等 知识管理平台：包括 信息发布管理平台、 档案管理平台、全文 检索、统一搜索引擎 等 技术驱动程序： Unix、Linux、 Windows、关系型数据 库、文件数据库、应用 服务器、Web服务器、 XML技术、DHTML技 术等
– 提高系统实施速度，降低系统建设风险和成本 – IT业务逻辑随需而变，大幅减少代码开发工作量
• 对已建信息化成果的良好继承,不断丰富管理应用 • 长远的统一规划，和切实可行的分步实施
OA信息化工程－建设路线图
Portal三期 Portal二期 Portal一期 OA •公文流程 •信息发布 •档案管理 •短信通知 •组织架构 •VPN接入 •门户展现 •应用聚集 •统一认证 •统一账户 •业务系统集成 •OA扩展应用 •专业子系统 •即时通信 •移动办公 •分公司园地 •团队空间 •业务流程整合 •知识管理中心 •运营信息展示 •ITIL服务管理
技术架构能够解决所有的问题吗？
• 先进的、良好的架构并不是建设OA系统的银弹
– J2EE和.Net只提供了一套体系、标准和服务，并不能 保证应用系统本身的设计和构建是符合规范的，合理分 层的； – 存在着很多伪N层架构的应用； – 技术架构和基础平台只提供了应用系统灵活性、健壮性 和扩展性的实现可能，没有正确的方法和实施，应用系 统并不能与生俱来地享受这种优势； – 即使采用J2EE的三层架构，我们依然会在OA系统开发 和实施中遇到许多难题；
编程修改
业务变化 面 向 业 务 的 开 发 模 式
ERP 面向 业务 的设 计和 建模
业务应用构建平台
SCM CRM OA...
配置修改
什么是应用构建平台
• 实现软件开发过程中技术和管理业务之间的分离 的平台工具 • 以业务导向和驱动的、可快速构建应用软件的软 件平台
OA系统 电子政务 系统 应用构建平台
定制开发（可能是基于 J2EE架构，但对每个业 务是重新编码）
没有将与业务无关的相 同应用逻辑抽象出来
传统开发模式 vs 基于应用构件开发模式
业务变化 ERP SCM CRM OA...
传 统 开 发 模 式
面向 编程 的设 计和 建模
C/S及多层技术 PB, VB, Delphi, Develop等 J2EE技术 （各类JAVA开发工具） .NET技术 .NET Stuido，Delphi for .NET
实现与外部系 统的流程互动
EJB/WebService
MIS系统
企业级工作流引擎
EJB/WebService
财务系统
组织架构
可视化 流程定制
可视化 表单定制
访问安全
CRM系统
第1.1部分：
工作流引擎管理端功能
组织结构
• • • • • 图形化设计环境 树状结构 分布式地域组织 多种管理视图 支持LDAP V3标准
• 这种演变趋势使得OA的整体复杂性增加，建设周期拉长。 建设部门和厂商既要迅速拿出成果，又要保证可持续发展 性。处理不好，将给系统建设带来巨大的风险
第三部分：
OA系统建设方法对比
传统流程的开发过程
• 目前市面上常见的关于业务流程开发方法
根据需求定制开发 各种系统中的业务流程
各种业务表单通过编程实现 MIS中的各种业务流程 各种流程通过程序或者通过 简单配置实现
流转痕迹
个性化的流转提醒设置
工作代理及委托
1. 工作代理 －单级代理 －多级代理 2. 委托机制
第1.3部分：
流程应用效果图示
各类公文流程和表单
基于业务工作流实现统一信息平台扩展应用
电子报销
预算规则管理 费用类型 会计科目映射 单据生成规则 额度规则
资源预定
资源分类 资源基础信息 资源申请规则
第二代OA系统
• 第二代OA系统（90年代末期至今）
– 基于群件系统Domino或Exchange Server开发，早期多为 C/S两层架构，后期引入B/S架构； – 底层平台功能较强，性能可靠；应用系统的功能和可靠性 比第一代OA有较大程度的提高； – 底层平台提供了较多的预置功能和API（如邮件、消息传 递、团队协作、日历、工作流等），开发不必从零开始， 整个开发周期得到缩短； – 引入了工作流的概念，提供了通用的引擎，流程可以由开 发人员定制，系统的灵活性比第一代有了长足的进步； – 在相当长的一段时间内，Domino甚至成为了OA的代名词， 时至今日，仍然有大量OA系统运行于Domino之上；