公司内部管理系统概述.docx
- 文档编号:85242
- 上传时间:2022-10-02
- 格式:DOCX
- 页数:57
- 大小:74.52KB
公司内部管理系统概述.docx
《公司内部管理系统概述.docx》由会员分享,可在线阅读,更多相关《公司内部管理系统概述.docx(57页珍藏版)》请在冰豆网上搜索。
内部管理系统详细设计方案
二○○二年七月二十七日
设计方案简介
本设计方案是为内部管理程序开发而编写的,它包括了系统可行性研究,系统模块设计,模块的具体流程设计,一些需要进一步讨论或者研究的问题,需要的资料与硬件,数据表的定义等。
但它没有包含关于编码的更多主题。
例如编码的约定,注解的格式等。
尽管这些问题对于实现这个系统都是非常重要的,但因为是设计方案它没有被包括在其中。
整个设计方案的大致目录如下:
一.内部管理系统项目方案(第2页-第20页)
1.项目开发背景(第2页)
2.项目可行性研究(第2页-第6页)
3.系统的大致模块划分(第6页-第18页)
3.1市场部(第6页-第17页)
3.1.1系统登陆模块(第8页)
3.1.2系统设置模块(第8页)
3.1.3事件添加模块(第8页-第9页)
3.1.4事件查找编辑(第9页-第11页)
3.1.5事件参数设置(第11页)
3.1.6事件跟踪模块(第11页-第13页)
3.1.7人事基本管理(第13页)
3.1.8部门参数设置(第14页)
3.1.9资料票据管理(第14页-第15页)
3.1.10业务收入统计(第15页)
3.1.11工资参数设置(第15页)
3.1.12员工工资管理(第15页-第16页)
3.1.13数据加密备份模块(第16页)
3.1.14数据库管理模块(第16页-第17页)
3.2网管部(第17页)
3.3制作部(第17页-第18页)
4.数据流图(第19页-第20页)
4.1市场部业务数据流图(第19页)
4.2市场部工资数据流图(第20页)
二.内部管理系统所需资料(第21页)
三.内部管理系统所需硬件(第22页)
四.数据库设计(第23页-第25页)
1.上层数据库设计(第23页)
2.市场部数据库设计(第24页-第25页)
五.项目工作量估算(第26页)
内部管理系统项目方案
一.项目开发背景
为了提高公司内部管理的效率,所以需要编制一套完整的用于公司内部管理的系统。
这样一个系统可以在整个公司范围内使用,做到了公司资源的整合与共享。
二.项目的可行性研究
1.技术方面:
整个系统属于一个规模比较大的MIS系统。
尽管其在组织关系上存在着很大的复杂性,繁琐性,不确定性,但是就整个系统的技术构成上来看,它还是属于一个数据库应用类的系统。
其基本操作还是对存在数据库进行添加、删除、查找、编辑等。
所以就单纯的数据库应用来看,暂不存在太大的技术问题。
2.经济方面:
由于系统对公司的正常运行的影响是相当大的,所以必须要设置单独的服务器来运行这个系统。
又考虑到所有计算机硬件软件都是存在出错可能的(具体到这个系统,由于其需要不间断的运行,所以其出错的可能就会变得更大),因此整个系统应该考虑使用双机热备份技术。
使用两台服务器同时运行,一个为主一个作备份,这样可以避免服务器故障对整个系统的影响。
又考虑到这个系统是为公司内部服务的,而且数据库设置和调试时候都必须要直接使用服务器,所以应该将服务器设置在公司内部。
纵观整个系统需要的硬件,我们认为整个项目的投资将可能是比较巨大的。
这方面,提请公司再作详细讨论。
3.法律方面:
整个系统由于是自行开发,自行使用,所以系统本身不存在法律上的版权争议。
在服务器软件方面,应该使用正版软件,因为整个系统尽管是开发给内部使用,但它毕竟很多部分还是要依靠Internet的,一旦服务器连接到Internet上,它的操作系统可能会被Microsoft跟踪,如果不是正版软件,将不得不面临民事诉讼的风险。
4.目前存在的问题:
目前我们觉得最大的问题仍然是数据库访问方式上的问题。
和一般的MIS系统不同,我们面临着更广泛范围内的数据库访问。
这个范围已经不可能用局域网解决了,但一旦使用Internet网,数据传输的有效性和安全性就会成为严重的问题。
现在将三种可能数据访问的方式列举如下,并逐一作分析:
a.使用纯单机版的数据库系统
这是最简单的数据库访问方式。
采用这种方式不涉及网络传输,所以无论在哪个部门,也不管其上网设施是如何的,总能采用这种方法的。
采用这种系统后,如果要实现数据同步,必须定期将数据库全部上传(注意:
这里应该是上传整个数据库,因为采用这种方式操作的系统,它上传的时间间隔一般是比较大的,如果记录哪些记录是更新的,在实际同步时候,将花费很多时间作整个更新记录的比对,在记录量增大时候,这个检测的时间也会急剧增加,反而增加了处理时间),服务器在收到整个数据库后,在服务器端运行一个特殊的软件,用于数据的同步。
然后将处理后的数据库放在一个特定的区域,客户端可以将处理后的数据库收下来,以实现数据库同步。
整个系统采用的传输示意图如下(仅以市场部为例):
总部服务器
市场部
DB
DB
DB
市场部
总部服务器上应该运行特定软件用于数据同步,此过程可能需要人工干预。
这段传输可以采用任何传输方式,包括FTP,Email
b.采用纯网络数据库的结构:
采用这个结构从理想的角度来看,是最适合这个系统的。
因为它具有最好的实时性,可以将当前获得的数据立即传输出去,这样其他部门也就立即可以得知目前的业务情况。
而且采用这个结构,从数据库应用角度来看,对网络底层的传输情况不需要有太多的了解(这部分由SQLServer提供的网络传输协议保证)。
但是就公司目前各市场部上网情况来看,由于很多市场部采用的仍然是Modem和ISDN,不能24小时在线,因此再不对目前各市场部上网设备改造的情况下,很难使用这种结构。
这种结构还有一个问题是它很大程度上依赖于中心数据库,对中心数据库可靠性和稳定性的要求相当高。
这种结构的示意图如下(以市场部为例):
总部服务器
DB
市场部
市场部
市场部
市场部
C.采用本地数据库和网络数据库同时使用的结构这里的结构和示意图a)中的结构看上去有些相似。
但其原理是完全不同的。
图a)中,需要上传的是完整的数据库,它依靠运行在服务器端的程序对数据进行整理以达到同步的目的。
而这个结构中,实际上并不存在一个文件上传的过程,它是依靠数据库访问接口来直接实现数据交互的。
数据库访问接口屏蔽了很多网络的细节。
在这个结构中,在服务器上不需要再单独运行管理程序来实现数据同步。
:
这是这个系统最有可能采用的数据库结构。
它的特点是平时数据存储在本地数据库,以天为单位,让本地数据库和总部的一个共享数据库进行交互,以实现数据的同步。
这种方式的优点是数据因为在本地和网络数据库上共存,所以可靠性是比较高的。
而且就Modem,ISDN和宽带共存的情况下使用这种结构也是比较现实的。
它的缺点是:
在每日用于同步的数据量大的情况下是无法使用的,另外,即使每天用于同步的数据量并不是很大,但是本地数据库或者网络共享数据库的存储量已经很大,这样再搜索用于需要同步的数据的时间也将成倍增加。
系统在刚投入使用时候可能速度比较快,但是存储量达到一定程序后,系统运行速度将会急剧减慢。
(根据实验,当数据记录条数达到5万条以上时,完整的数据库搜索花费的时间会很长很长),而在这种系统结构下,为了保持两者数据库的完全同步,可能要反复搜索数据库。
此段时间的开销是相当大的。
除此之外,这个结构最大的问题是:
如何保证数据的完整同步。
因为诸如Modem等上网设备,其传输过程极易由于外界干扰或者线路传输速率的突变造成传输中断。
重传这些数据可能会造成数据的重复。
(比如经过检测,这次需要上传10条记录,现在客户端开始上传,上传一半Modem断线了,所以实际只传了五条。
客户端检测到这一错误,开始重传,但实际上尽管断线仍然有五条记录是成功传送的,重传全部必定造成重复,但是要很准确的定位具体是在那条中断是相当困难的。
这和网络传输协议里错误检测是类似的)
采用这个结构的示意图如下:
直接数据库交互
总部服务器
DB
市场部
DB
DB
市场部
介于以上原因,我们认为选用何种数据库结构需要进行进一步研究。
可以作一下实验,比如使用各种现有的上网设备来进行一下数据库连接。
测试在不同的数量情况下,对性能的影响。
特别要对Modem连接SQLServer作更多的实验。
因为其连接速度比较慢,必须要对数据库连接超时时间作调整。
(此值过小或者过大都会对性能造成影响。
过小的值可能会使使用Modem的机器无法连上SQLServer,过大的值在确实发生错误时候,需过很多时间才能检测到此错误)
三.系统的大致模块划分
由于整个系统最后使用的结构还没有最后确定,所以这里的模块划分只是一个大致的划分。
在经过实验,确定使用哪种数据库结构后,需要对此部分进行进一步修正。
1.市场部
从最大的方面市场部管理系统可以划分成业务管理、人事管理、财务管理、数据统计与备份、系统设置等模块。
其中业务管理模块包括事件记录添加、事件记录修改,事件记录删除、事件提醒等功能。
这部分侧重的是对客户服务的,它是以客户为中心开展的。
是整个系统数据的入口处。
在人事管理和财务管理等模块中,有很多数据是要依靠业务管理模块的。
人事管理模块指对分公司内部人员的管理,包括用工、退工、员工平时所领取资料、合同等其他凭证的管理与查询。
这里要注意各种凭证领取时候的记录;在凭证丢失时候的处理。
这些凭证都是由业务产生的,所以其与业务管理模块之间存在很多相互访问的情况。
由于存在这个特性,所以必须要做好数据保护,以防止数据交叉访问时候对原先数据的破坏。
财务管理模块是用于市场部内部工资结算的。
由于市场部工资很大部分是有业务员的业绩决定的,所以其在很大程度上也是依赖于业务管理模块的。
它就是根据业务管理模块的统计结果,再利用一定的算法来计算业务员当月的工资和市场部管理人员当月的工资。
这部分繁琐的地方在工资结算方法和各分公司之间算法的差异上,尽管可以设置一些可选项,但如果差异过分悬殊则可能需要为有些分公司编写单独的处理模块。
数据统计功能依赖于业务管理模块和财务管理模块,它按照一定的时限生成各种业务报表供公司内部留存、上交等。
除了打印出来的报告外,程序应该提供一定的界面供数据查阅(不打印)。
备份是所有MIS系统都应该具备的,尽管数据安全可靠存储大部分应该由服务器来保证,但是程序中仍然应该具备数据备份功能,用于数据定时的导入导处。
或者与其他程序交互时候可以使用。
系统设置模块用于对程序进行初始设置。
这部分应该尽量考虑到可扩展性。
对于能够进行设置的部分在此处应尽量设置设置选项。
当然,调整只能在一定范围内进行,一般是数值上或者选项组合上的。
由于系统设置对于系统的运行是起全局影响的,所以再调整前要进行安全性验证。
整个市场部程序模块示意图如下:
(本图仅供参考)
市场部管理程序
系统设置模块
系统登陆模块
业务管理模块
财务管理模块
人事管理模块
事件跟踪模块
员工工资管理
工资参数设置
资料票据管理
部门参数设置
事件添加模块
事件查找编辑
业务收入统计
人事基本管理
事件参数设置
注意这里一个粗的双箭头表示这些数据库访问之间将有频繁的交互。
财务数
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 公司内部 管理 系统 概述