人人范文网 范文大全

OA系统建设项目需求方案建议书

发布时间:2020-03-02 16:53:26 来源:范文大全 收藏本文 下载本文 手机版

方案建议书

1前言

1.1 编写内容、编写目的、面向读者

本文主要阐述我对OA系统建设的总体构想。

内容包括:设计原则、需求分析、系统体系结构设计、软硬件技术解决方案及项目实施等。

本文的编写目的在于向用户阐述我公司对OA系统建设的方案,听取领导及相关部门的意见,为做好系统设计打好基础。

本文面向的读者为:公司各级领导、OA系统建设意向服务商

1.2项目背景

集团公司急需一套协作工作管理系统降低领导的工作强度,解决管理覆盖面和管理成本难度之间的瓶颈,并通过协作系统提高员工的个人工作管理能力。

1.3项目要求

根据项目背景现状,提出以下的建设要求: 总体部分: 系统要求

可扩展的应用服务器设计; 完善的系统备份方案;

完整的外部应用系统的接口以及接口规范,如档案系统、人事系统,以及其他关系型据库; 源码开放; 功能要求

综合信息平台部分:

完善的信息采编、发布、归档以及全文检索功能; 符合业务要求的权限管理;

可持续扩展的API(应用程序编程接口)底层架构; 完善的体系规范 整合移动办公业务; OA 系统部分:

A、满足集团化组织结构的要求;

B、实现集团公司和分公司应用的独立运作,并实现兼职人员的跨单位身份和文档衔接;

C、具有结构扩展性,可以快速新增实施/拆卸二级单位的应 用部署; D、合理部署OA及网站应用结构,以适应2000人同时在线访问和无限制总用户数; E、成熟的用户管理和应用模块管理、流程定制,可将权限下放给各级管理员独立维护;

F、各关键应用模块需保留详细事后审查日志;

G、文件办理时效统计,系统提供文件流转日志统计分析模块,供业务审查部门分析文件流转数据;

F、相关文档的关联,可按事件、人物、时间等因素将相关文档进行关联。

2需求分析

2.1 现状分析

集团公司现正处于成立之初,在集团成长过程中,其功能和业务应用将不断进行集成、扩展。需要建立集团网站、子公司网站部署系统、OA系统和邮件系统、以及以关系型数据为核心的各类非核心业务应用。

2.2 长远目标

综合信息平台是企业信息门户,是企业所有员工日常办公最频繁使用的一个平台。在充分考虑集团化发展方向以及结合集团发展规划,在对综合信息平台所承载的企业信息和业务功用进行分析的基础上,提出了将综合信息平台逐步建设成为集团的业务集成平台、业务协作平台、信息发布平台、信息展示平台、沟通渠道平台、二次开发平台;通过对这些远景目标的逐步分解实施,可使OA系统能够不断适应集团各个时期发展所带来的各种信息化需求。

2.2.1 业务集成平台

以综合信息平台为核心,提供各业务系统的接口,对跨系统的业务流程进行整合,真正实现企业应用集成(EAI)的业务整合。此时,综合信息平台不单单是企业信息的展现以及工作流处理的平台,更是一个各异构系统、专有系统进行数据交换和业务衔接的技术和协作平台。

2.2.2 业务协作平台

以工作流为基础,整合、优化企业内部的多种业务流程。在此基础上,逐步丰富加强工作流的数据交换功能以及对工作流各指标项的统计分析功能。在熟练掌握工作流理论知识和实际业务的基础上,可逐步尝试利用J2EE 技术实现相关功能,为构筑一个统一技术平台的基础框架打下基础。并将以工作流开发为核心的OA 系统逐步发展成为以业务流程整合为主的业务协作平台。

2.2.3 信息发布平台

建立一个统一的、分级别的、BS模式的信息发布平台。公司所有的信息采编、发布工作通过该平台实现,并制订相应的发布规范。

2.2.4 信息展示平台

多种样式、风格的信息展现,同时借助自主研发或第三方的搜索引擎,全面支持全文检索。在实现展示风格样式的同时,并集成企业数据仓库项目的前端展现。

2.2.5 沟通渠道平台

为突破时空局限性,逐步建立多种用户交互渠道。逐步集成以RTX、移动办公为主要形式的沟通渠道,将进一步提升办公效率。通过实时通讯平台,可方便的实现点对点沟通、企业信息发布、群组会议等功能;通过移动办公,用户可利用手机短信的方式进行信息浏览和业务办理,同时,对于高端手机用户,还可利用wap方式以及pushmail方式进行信息查询以及业务办理。随着通信技术的快速发展,特别是第三代通信技术(3G)的应用推广,在构建用户沟通渠道上,可尝试性的结合3G 技术考虑企业应用的拓展及延伸方式,以便更好的服务于企业用户。2.2.6 二次开发平台

为建立以J2EE 技术为基础的系统架构,重构综合信息平台底层实现,统一基础API(应用程序调用接口)框架,同时为适应其他业务系统的集成以及与其他专有系统进行业务对接,将逐步制订相应规范,如综合信息平台接口规范、二次开发规范等等。在此技术上,形成深航信息中心的J2EE 核心技术架构,便于快速开发新的业务应用。另一方面,在逐步搭建二次开发平台的同时,逐步形成项目的规范化运作,同时项目组成员逐步分化为多种不同角色,形成一个分工明确、责权明晰的高效技术团队。

2.3 本次项目目标

以上目标的达成是一个逐步的过程,并非本项目可达成的一次性目标。但是依据上面的长远目标,我们制定了本次项目目标:

a.集团化组织架构改造,并适合多岗多部门兼职等复杂应用现状;并完善岗位角色的权限管理体系;

b.可扩展的应用服务器群集设计,满足未来发展的情况下,服务器可以平滑的升级和扩张;

c.完成一次完整的外部应用系统的接口以及接口规范的整理工作,使得将来再开发的系统可以按照规范的调用; e.提供初步完整的API 底层架构;

h.整合移动办公业务,提供移动办公的平台;

f.完整的数据字典设计,合理的输入输出设计,有相应的数据备份措施; g.完善的信息采编、发布、归档以及全文检索功能;

2.4 几个具体化的指标目标

2.4.1 容量

系统上线之后可以: n 在线用户300 人左右 n 并发用户200 人左右

n 峰值访问量200-500 请求

将来再扩展可以通过增加服务器的方式。

2.4.2 稳定性

正常每个用户访问首页的速度不超过3 秒。 每年系统意外当机的次数不多于2 次。

2.4.3 管理

实现集团型架构的分权管理,总部的人员具有最高的管理权,可以管理全集团的流程和权限。二级机构的管理员只能管理本机构的业务和数据。数据大集中管理,便于统一的备份和维护。 3 方案路线

3.1 系统架构

1,实现单点登录、集成其他业务系统、个性化界面三大内容。也可以采用初步应用一些技术和手段,在保证单点登录和集成其他业务系统的基础上,为不同部门和岗位定制不同的个性化界面。这样可以降低硬件成本,更可以提高系统的整体性能。

2,新建集团型的架构,以适合多岗位多部门兼职等复杂应用的需求。

3.2 设计思想

组织架构必须实现可伸缩性

组织架构体系作为整个企业最基本最重要的内容,同样要反应到系统的基础设计结构中。当企业的组织结构变化时,系统无需做过多的调整即可符合要求。

岗位(角色)的管理模式

任何一个企业的管理模式都是采用面向岗位(角色)而不是具体的个体进行的。本产品的管理体系也顺应了企业的管理模式,着重于工作岗位而不是个体。主要表现在:

1.岗位和组织架构的关系 2.岗位和权限的关系 3.岗位和人员的关系

4.岗位在工作流程中的体现

集中式的管理中心

所有的操作都在web 上实现,大量的批量操作都通过这个管理中心一步解决。这就避免管理员需要全面了解系统,阅读操作手册的高要求和繁琐,以及潜在的操作失误。

全面的信息系统,统一的系统平台,防止信息孤岛

必须至少提供同其他系统的数据接口,否则这个系统将成为信息孤岛,这部分业务管理也就有脱离企业统一管理的危险(或者每个用户都必须装上访问各类系统的客户端)。

充分考虑结构化和非结构化业务数据

现实生活中的绝大部分数据都属于非结构化,同样,在企业管理中,大量存 在的应用数据也是非结构化的,例如文档、审批文件、扫描件、声音、图像、附 件等等。

3.3 网络拓扑整体规划 (采用服务器托管业务) 3.4 备份方案 1,须采用专业的存储,使公文类应用的数据和OA平台的文件数据的稳定性和可靠性都得到保证。建议制定备份周期。

2,OA平台部分的应用,包括邮件和公文的应用,都可以采用复制,与OA备份服务器之间备份。可以采用每天晚上增量复制的方式,数量不大,可以降低备份的人工工作量,由系统自动完成。由于邮件的数据量特别大,所以建议备份服务器的硬盘配置大。

3.5未来扩展

OA系统

建议未来采用分布式架构,将较大的分(子)公司,或者具有较多应用的分(子)公司逐渐独立出去,即分(子)公司有自己独立的一台服务器,此服务器放在分(子)公司的机房里。但在人员信息上,仍然保持由总部的LDAP 验证和管理方式。 优点:

这样的扩展方案保持了统一的集团型架构,保持了人员信息的统一管理,同时也保证邮件仍然能畅通流转,公文也能进行上下级的传递审批。能减少总部的负荷,提高系统性能,而又不会减少任何业务应用功能

各业务部门的邮件和公文系统自行管理维护,特殊应用也能自行自主开发扩展。总部的信息中心才有更多的精力进行整个集团IT建设的规划和管理。

4 OA系统主要功能及简述

4.1 用户权限基础

岗位和组织架构的关系 岗位和权限的关系 岗位和人员的关系

岗位在数据访问和工作流程中的体现

4.2 统一的web用户身份验证

本系统完全采用B/S 架构,普通用户的操作、系统管理员的管理维护、外来人员的信息浏览等,全部都在浏览器上操作完成,基本实现系统的零培训和简单维护。为了确保用户安全可靠地访问相应的功能和信息,平台需提供统一用户及权限管理系统来实现对用户的认证(包括身份证书机制)、权限、加密管理,以达到访问控制的目的。本系统可为不同的人员、部门和岗位(角色)定义相应的权限,并对权限做了进一步的细分,定义用户可以访问哪些应用、数据、功能等。

4.3 人员组织架构管理

将人员组织架构信息的存储完全集中在“内部通讯录”模块中,管理功能完全放在“管理工具”中,最大限度地保证人员信息存储和管理的统一性和安全性。

4.4 工作流引擎

工作流侧重于灵活性、可扩展性、可定义、操作简单、功能强大。作为系统的基础部分,工作流引擎更是贯穿了全系统各个应用模块。 主要功能如下: 流程完全可定制;

多人、多部门同时会签流转,并可指定串行流转和并行流转;

支持授权(工作代办),并可支持对不同审批业务流程进行不同的授权; 提供知会功能;

采用岗位、群组配置;

独立地对企业各种复杂和多变流程进行设置; 根据给定的逻辑条件自动选择流程分支进行流转; 详细完整的流转日志 统一简单的流转操作

可收回、退回,或直接返回拟稿人 多人表决

不同流程的串接 支持文件作废

支持文件的办理期限,到期自动提醒 自动催办和人工催办

字段的可编辑、可读等信息屏蔽功能,完全由用户自行指定 可支持手工输入意见、手写笔意见签名和图片签名 定义常用意见

可自行定义节点的名称,适应企业业务调整 随时查阅和调整文档的阅读范围

与RTX消息和短信集成,支持可定制的短信内容

在流程结束后,可通知到拟稿人、所有审批各环节人员

4.5 知识管理模板

在系统软件架构中,知识管理模板和工作流引擎是作为整个系统最基本的两 个模板。各类文档、资料、图片等非工作流的应用模块基本上都是以知识管理为 基础。 概念:

知识分为显性知识和隐性知识两类,显性知识表现为事实数据、常识数据等,隐性知识主要表现为人脑中存贮知识、挖掘的知识、会议信息等。

知识管理核心目标是信息共享和重用,知识管理是从收集、整理、发布、再利用四个环节重复循环提高,是一个永无止境的过程。 知识管理平台能实现以下功能: 知识的来源:除了传统的手工录入外,还支持其他工作流应用的结果文档自动导入到知识库中 知识的规划:

a) 可以将知识的存储分为单数据库多分类的存储方式,也可以存放在 多数据库下(各数据库内部可以继续再细分类别)

b) 规划哪些工作流应用文档将自动导入到某个知识库中

c) 规划各部门、人员、岗位的访问和使用权限,再利用知识库提供的多层权限控制分别设置不同的权限。

知识的编辑:正文内容和office集成,即编辑时完全采用office程序进行,而非一般的集成控件的方式。

知识的发布:支持草稿、删除到废纸娄、完全删除、从废纸娄中恢复、正式发布、发布到首页、取消发布到首页、修改后和已发布到首页的信息同步等功能。发布时可自动通知到预定的某些人员。并且支持三种提醒方式:邮件、RTX消息、短信。

知识的浏览:采用主流的树状结构浏览方式

知识的搜索:知识可归属多个分类,用户可在多个分类中(即从不同搜索路径)快速查找,分类可支持多级。提供模糊全文搜索和条件搜索方便查找,并可跨多个知识库进行搜索。

知识的共享:可支持点评、推荐等功能,让知识在共享中得到进一步的提炼和升华,并将知识及时提供给员工分享。

知识的过程管理:可支持版本管理,完整记录一个知识文档从最初的草稿到最终的定稿之间的所有版本内容,以供历史查阅。

知识与流程的结合:可将流程类知识自动转变为知识文档共享

人性化操作:无需逐一到文档列表界面下打开文档,而是在打开文档的情况下可直接跳转打开上一篇或下一篇文档进行查看。

知识的安全

1、对每个文档可以定义不同的读者范围,并可查阅读者范围。不同版本的文档安全性也可独立管理。

2、可实现只有有权限的人员才能对附件进行查看、下载、打印的控制。 知识订阅(主动式发布)

使知识的发布“主动式”地发送到订阅人的个人办公平台中,而不再需要用户到各个知识库中逐个寻找,从而极大地方便用户及时获知最新的文档,更有效地提高知识的共享和利用率。

4.6 信息发布

信息发布是OA系统的基本应用,但也是非常重要的,重要的信息需要通过严格的审批权限,以确定该信息是否应该发布,尤其是需要发布到公司级首页上的各种信息资料。因此在管理、审批和权限控制方面的要求是相当高的。

4.7 集成RTX 系统须实现和RTX的集成,主要实现功能如下:

直接在OA系统上发送短信(或RTX桌面消息)

发送邮件的同时能自动发送短信(或RTX桌面消息)给收件人

各个应用模块在审批流转时,都能同时发送短信(或RTX 桌面消息)给文件接收人,以提醒文件办理人收取待办事宜,加快文件流转 用户在不打开ie浏览器以保持oa系统打开的状态下,可以通过rtx客户端及时获知当前的工作安排。当点击rtx的提醒链接,即可自动进入OA系统处理工作。

系统管理员可以根据实际情况方便的设置不同群组、角色和人员发送短信的权限

RTX 的组织机构、用户信息完全同OA系统自动同步

4.8 统一的管理中心

主要功能包括:

用户管理:用户的注册、所属部门设置和调整、离职 设置人员所属岗位

机构/部门管理:机构/部门的增加、删除和改名

群组管理:群组的增加、删除和改名。查看人员的所属群组 岗位管理:岗位的增加、删除和改名、岗位具体权限配置 配置具体数据库模块的权限 配置具体岗位的权限

4.9 可自定义的查询统计和报表

系统提供可由用户自行灵活配置查询条件、输出结果、报表样式、是否需要 细节显示等。

4.10 支持二次开发

系统的设计需采用模板化的形式,提供标准的开发模板库和基础函数。只需要引用这些标准库,即可实现系统已有的功能,从而快速完成一个审批流程、信息发布或文档管理模块。这就使得设计人员和最终用户只需要关注于用户的具体业务要求,而其他技术层面则完全由基础平台提供。

4.11 个性化的首页定制

可根据用户需求自定义首页

4.12 完备的系统监控

系统提供标准的操作监控接口,在任何需要监控的操作都能自动记录在案。

4.13 可自定义的文号管理器

系统中有很多文档都需要有编号,而且各类文档的编号规则都不相同。 须了统一的编号管理器,可供用户自行定义文档的编号规则。

4.14 平台管理组件

基础支撑平台的大部分功能都提供了相关的配置项,通过修改这些配置项即 可实现不同的功能。这些配置项分别放在系统的各类管理组件中,作为系统管理 的中心,支撑着整个系统正常运行。包括:

全局系统配置、各机构系统配置、流程配置、菜单定制、管理工具、字段定 义、编号管理、公文配置、人事档案、工作代理、报表配置、监控日志等。

4.15 公文管理

公文管理系统包括发文(分为公司级和部门级)、收文、签报、部门办理、上会讨论、归档、自定流程等。

4.16会议管理

直观的查看会议的所有安排,保证利用的最大合理化,操作便捷。

会议管理包括维护会议室信息、预定会议室、会议申请和通知、会议纪要等。 完成一个会议从申请并预定会议室、发送会议通知、会后的会议纪要填写等完整 的会议过程。

4.17 后台管理

后台管理作为系统的综合管理中心,支撑着整个系统正常运行。共包括系统 配置、菜单管理、数据交换、系统管理4 个模块。

5OA系统建设其他须满足条件

5.1 手机移动功能

利用手机作为终端,通过手机平台实现部分OA功能:至少包括:通讯录查询、邮件收发、工作流程审批、信息查看等

5.2 监控

系统须提供实时管理监控功能,可通过web页面访问系统管理控制台。包括包括了应用部署、应用配置、应用监控统计、在线更新、安全审计、日 志查看、工作流管理监控等各种服务。

5.3二次开发能力

须为平台的建设提供了统一的软件架构、一致的项目开发方法和规范,并且自动生成详细设计文档,永远保证上线的系统在软件和文档上的统

一、可阅读,使得知识能够持续得以积累,并且能够进行有效地管理。

基于统一的应用平台,能够有效约束不同的开发商遵循统一的、标准化的应用架构进行开发,不同时期、不同厂商开发的应用系统彼此之间能够很好整合。

5.4 规范化管理

须对对页面的设计、应用框架的规划、目录规划、菜单构件规划、页面构件规划、CSS样式表规划、函数库规划进行规范化管理。

5.5项目实施

须提供详细的开发实施计划,进行详细的需求调研,对系统的整体设计以及系统详细设计须审批。开发阶段结束后应提交《系统操作手册》。须进行完整的测试并提供《项目测试计划》、《项目测试报告》。调试安装结束后应提供《软件安装实施方案》、《系统安装手册》,《系统操作手册》,《系统维护手册》、《系统调试报告》。系统验收后提交《系统试运行报告》、《验收报告》 5.6质量保证计划

须制定严格的项目实施流程规范,项目各阶段定义了清晰的输入、输出条件与质量控制点,通过对项目各阶段工作不断的检查、度量、评价和调整来确保项目的质量。

5.7技术支持与售后服务计划

为了保障项目的成功实施,须制定详细的技术支持与售后服务计划。

5.8培训计划

须制定详细的开发期、调试期、使用期的培训计划。

OA系统需求

公司内部OA系统需求方案(jbpm4+ext)

OA系统实施计划建议书

ERP系统建设项目建议书

OA系统方案v1.0

OA系统需要方案

OA系统方案书

学校OA办公系统功能需求分析解析方案

OA技术需求

OA需求文档

OA系统建设项目需求方案建议书
《OA系统建设项目需求方案建议书.doc》
将本文的Word文档下载到电脑,方便编辑。
推荐度:
点击下载文档
点击下载本文文档