爱玩科技网
您的当前位置:首页业务管理系统设计

业务管理系统设计

来源:爱玩科技网


1.1组织结构概况

某公司是一家颇具规模的软件公司,它是集开发、销售、售后技术支持于一体的高新科技民营企业。某公司包括人事资源部、开发部、产品部、销售部、售后技术支持、财务部等部门。

1.2项目开发背景

某公司的软件产品开发主要围绕检察业务展开的。目前,某公司的检察业务软件产品已在好些省市的使用。产品的使用状况相当不错,已获得了各客户的一致好评。全国有3千多家,这是一个相当大的市场。这么大的市场自然需要相当数量的销售员来进行业务推广、客户联系、产品介绍、安装试用等。对于某公司日渐庞大的销售团体,如何来管理他们的销售状况,就成为销售部门需要提到日程上来解决的问题。作为一个软件开发某公司,开发一套销售业务管理系统自是成为不可避免的解决方案之一。

3信息系统目标

按照管理系统的原理和方法,采用新的信息技术和手段,支持某公司销售管理工作的信息化,提高某公司是管理工作的现代化水平。 销售业务管理系统的主要达到的目标是:

使销售员能够迅速了解某公司现有哪些产品,这些产品的报价资料等等。  使销售经理和某公司高层管理人员能够及时了解某公司销售员每天的工

作内容,拜访客户情况,了解用户对某公司现有产品的评价,知道每个销售员的销售状况,对销售员的跟单过程可以进行指导和其他帮助,了解客户的潜在需求,从而可以更好地制定、调整某公司的销售计划,并且对某公司现有产品可以有依据的书面的提出需要改进的地方。  可以对某公司销售员的销售业绩,阶段性地进行评比,从而达到鼓励员工

积极进取的目的。

 可以让某公司高层及时了解某公司产品的整体销售情况和经营状况,从而

为某公司的产品策略和销售策略的制定提供依据。

1.4信息系统范围

某公司销售业务管理系统主要是为某公司的销售部门的管理活动提供信息服务。系统能够对某公司的产品资料进行管理、销售员可以录入每天的工作内容,而销售经理和某公司高层可以随时准确查询、跟踪销售员的工作内容,可以对所签合同进行录入、修改、处理、查询、统计。可进行各种综合统计报表的汇总、查询和打印等功能。系统的数据来源主要是由销售部门的员工通过键盘录入。 1.5项目开发方法概述

项目所采用的一些开发方法及其工具:

1.销售业务管理信息系统开发方式:因为系统规模较小,系统功能有比较明确的需求,基本可预见,因此采用的是系统开发生命周期法。其中,系统模块的划分采用自顶向下,逐层分解的方式。

2.软件的开发方法:采用的是面向对象的开发方法,包括OOA面向对象分析、OOD面向对象系统设计和OOP面向对象的程序设计。

3.软件开发过程中采用了计算机辅助软件工具:MicroSoft Word,Microsoft Visio,MicroSoft Excel. 1.6项目开发计划

销售业务管理系统开发任务清单

系统设计项目 任务代号 节点序号 紧前工序 任务名称 预计完成时间(天) A 1 系统总体结构设计 10 B 2 1 程序规格制定 2 C 3 2 控制程序设计 4 D 4 2 各功能模块程序设计 10 E 5 2 编写控制程序+ 4 F 6 4 编写用户使用说明书 6 G 7 4 编写功能模块程序 20 H 8 5,7 测试控制程序 2 I 9 7 各功能模块单元测试 3 J 10 8,9 综合测试 3

功能模块清单 任务代号 任务名称 子任务 A 基本资料管理 B 产品资料管理 C 客户资料管理 D 员工基本资料管理 E 工作日志处理 F 工作日志的录入 G 工作日志的查询 H 工作日志报表 I 订单处理 J 订单录入管理 K 订单查询管理 L 销售订单提成计算 M 销售订单提成审批 N 综合统计报表 O 销售订单汇总表 P 销售订单明细信息表 Q 期间销售产品明细表 预计完成时间 1.5 1.5 1.5 1.5 1.5 1.5 4 2 3 2 1 1 1

R S T U V W X Y Z 系统维护 产品销售情况表 1 员工销售排行榜(销售金额) 1 员工销售排行榜(签单次数) 1 员工销售提成情况表 1 应收帐款表 1 代码表维护 1.5 权限维护处理 2 销售提成计算公式设定 1.5 系统需求分析 2.1现行业务系统描述

2.1.1组织结构图

【图2-1】 2.1.2业务流程图

【图2-2】 2.1.2业务流分析

开发部开发各种产品,并提供给销售部这些产品的所有相关功能信息,销售部在充分了解这些产品的实现功能和某公司报价的基础上,向各地方开展销售

工作。

对于某公司没有档案记录的客户,销售员应及时地向某公司提交客户资料,由商务助理汇总统计客户资料,形成客户联系表,以便让所有人及时的了解

所有客户的资料,并便于某公司制订销售计划,展开销售活动。

对于销售员每天的工作内容,包括拜访客户的详细情况,销售员都应该以某公司打印的固定格式的工作日志表格记录下来,并且提交上级主管或销售经理审核,以便上级了解业务工作的进展,并且提供销售员需要的帮助。同时这种填写工作日志的方式也是销售员自我记录,以便工作回顾和自我调节和安排工作的必要方

式。

当销售员与客户的沟通到一定阶段,客户对需要的产品亦了解到一定程度,并且愿意购买某公司产品,就会与某公司签订销售产品合同。合同签订了后,等合同款项一到帐,销售经理就可以根据某公司的提成算法,计算签单销售人员的提成,并形成报告提交总经理,得到审批后,销售员就可以到某公司财务领取销售提成

了。与客户所签的合同必须交付财务处保管留底。

注:这里需要说明的是,有的时候合同的签订并不是一个人能完成的,也许是2个人甚至更多的人一起来合作完成的签单。这种情况下,就存在签单过程中,谁付出的多,谁的功劳大,谁拿取的提成奖金就多,这就必须量化这种签单权重。 销售经理每过一段时间都必须向总经理和某公司董事会提交各种报告,包括销售进展情况,合同签订情况等。由某公司高层根据这些销售报告,来制订未来的销售策略和销售计划。同时根据销售员的工作业绩报告以及表现,予以嘉奖,激励

员工,以达到某公司与员工双赢的最佳状态。

2.2现行系统存在的主要问题分析

1.目前,某公司销售部门对销售人员工作的管理方式,还是采用传统的管理方式,销售员对于每天所做的事情,包括对业务的熟悉、计划的制定、客户拜访、出差、培训等,必须填写工作日志,销售经理为了了解销售员的业务工作展开情况,每天得催促并收集这些纸质的工作日志,而且经常因为看不清手写的潦草的工作日志而烦恼。随着销售队伍的扩大,这种工作渐渐变得让人无所适从,给某公司的销售管理工作带来极大的不便。因此,原有的管理工作缺乏规范性,随意性很大。

2. 随着某公司市场的扩大,已有的客户和潜在的客户逐渐增多,仅仅将所有的客户资料输入Office文件,已经远不能满足大家的需求,不能迅速的准确的查询客户资料,不能及时共享所有的客户资料, 不能做到信息的一致性。

3.某公司的合同收款,一向以合同的签订为准,合同一签订好,用户所付款项到某公司帐后,这份合同的相关财务信息由某公司财务整理并入某公司的财务管理信息系统,可是某公司的财务系统是笼统的一个财务管理信息系统,它包括了某公司一切的收入、支出和其他内容。却无法得出某公司高层所需要的各种销售业务统计报表,销售员的销售业绩情况表等。

4.所有有关合同的详细信息都只是在那张某公司财务保险柜中保留的那张合同上记录着。一旦某公司需要去查询以往的合同订单信息,非常地麻烦,需要从一大叠的合同中搜寻出来。无法根据需要迅速地、准确地查询和统计这些合同信息。 2.3提出可能的解决方案

上述的这些问题困扰着某公司的管理者,为了解决这些问题,最好的方法就是开发一套销售业务管理系统。开发的这套销售业务管理系统,可以解决上面提到的问题。

2.4可行性分析与抉择 技术可行性:

开发工具:采用Borland某公司的DelPhi5.0为开发工具,DelPhi是一种面向对象的开发工具。具有强大的开发类库,是市场上最好的编译系统。  数据库:采用MicroSoft某公司的SQl Server 7.0数据库存储数据,可

以适用开发Client/S程序。(注:因为SQl server 数据库文件较大,不太方便携带,故在毕业设计中,采用Access数据库替代之)。  采用的开发工具和数据库,某公司具有非常熟悉该技术的技术人员,经验

非常丰富。所以从技术上来说该系统的开发是完全可行的

经济可行性:

该软件虽然不能直接为某公司带来经济效应,但是,它的应用却为某公司带来潜在的利益。它加强了某公司销售的管理工作,提高了员工的工作效率,使某公司的管理工作走向规范化,促进的员工工作的积极性,从而为某公司带来了不能用金钱来估计的无形的价值。 营运可行性:

从硬件条件来说:作为一个软件开发供应商,某公司的每个员工都有一台属于自己使用的机器。这就为该系统日后的使用提供了良好的硬件条件。  从人的角度来说:无论从员工的个人工作角度,还是从某公司的管理角度,

都希望能有这么一套管理软件,来提高工作效率,加强管理。所以,某公司从上到下,对该软件都有较高的积极性。

总之,从各个方面特别是某公司目前的销售业务管理工作方面的现状,这套销售业务管理系统已成为某公司迫切的、可行的、必要的一个开发项目。

新系统逻辑方案

新系统的逻辑模型主要是以系统的数据流程图和数据字典为主要描述工具。 3.1 数据流程图

数据流程图的绘制是在系统调研的基础上绘制而成。它遵循明确系统界面和自顶向下逐层扩展的原则,将信息处理工能和彼此之间的联系,从逻辑上精确的描述了销售业务管理系统应有的数据加工功能、数据输入、数据输出、数据存储及数据来源和去向。

如下图所示,为销售业务管理系统的关联图(图3-1)和顶层数据流程图(图3-2)

【图3-1】 【图3-2】

数据流程图说明:

从上图中可以看出,整个销售业务管理系统可以分为基本资料管理、销售员工作日志管理、订单管理、综合统计报表管理、系统维护 等五大块。

以下为扩展的流程图(图3-3和图3-4)

【图3-3】 【图3-4】

3.2数据词典

数据词典的描述采用图表格式。如下表格

数据流 系统名:销售业务管理系统 编号: 条目名:销售订单合同 别名:订单 来源:销售员所签合同 去处:某公司财务处保管 数据流结构: 销售订单合同(由3大块组成)={合同表+合同明细表+合同签约人} 合同表={合同编号+客户编号+签单日期+合同总额+应收总额+实收总额+合同说明} 合同明细表={合同编号+产品编号+产品售价+产品数量+产品总价} 合同签约人={合同编号+签约人+签约比重} 简要说明: 客户购买某公司的产品有可能会超过一个,所以用合同明细表来表示一份合同中,客户所购买的产品明细信息。 一份合同的签订,有时是由几个人来完成的。这几个人在签单过程中所付出的和所起的重要性,通过量化的签约比重来表示,这个签约比重将决定每个参与了签约的销售员所能够拿到的提成。 销售订单合同一旦签订,则表示销售员的跟单工作结束. 修改记录 编写 邬师芬 日期 2003-4-25 审核 日期

数据元素 系统名:销售业务管理系统 编号: 条目名:合同编号 别名:合同编号 属于数据流: 存储处: D7合同表 D6合同明细表 D5合同签约人 D8提成记录表 数据元素值: 代码类型 大小 取值范围 意义 字符 11位 XXXX XX XX XXX (有数字组成的字符串) 序号 合同签订日期 合同签订月份 合同签订年份

简要说明: 销售订单合同的合同编号由系统自动生成。每个合同都有自己的唯一的合同编号。 修改记录 编写 邬师芬 日期 2003-4-25 审核 日期

数据存储 系统名:销售业务管理系统 编号: 条目名:客户资料表 别名: 存储组织: 记录数:3000多 主关键字: 客户编号 每个客户一条记录 数据量: 辅助关键字:客户名称 按客户编号排序 数据结构: 字段名称 字段类型 字段大小 客户编号 字符型 7 客户名称 字符型 16 联系人姓名 字符型 8 固定电话 字符型 16 移动电话 字符型 12 联系地址 字符型 20 邮政编码 字符型 6 所属省份 字符型 7 备注 备注型 简要说明: 客户编号,是由客户所在省份简称加上3位序列号组成。如江苏省人民可以编号为JSS-001,其他编号以此类推。 客户资料表含有了相关的销售员需要了解的客户基本信息。 修改记录 编写 邬师芬 日2003-4-25 期 审核 日 期

数据加工 系统名:销售业务管理系统 编号: 条目名:合同录入管理 别名: 输入:签约客户 输出:合同详细信息表

合同金额信息 销售产品明细信息 签约销售员信息 销售合同汇总表 销售合同明细信息表 期间销售产品明细表 产品销售情况表 员工销售排行榜(销售金额) 员工销售排行榜(签单次数) 员工销售提成情况表 应收帐款表 加工逻辑:  系统自动生成订单编号:根据订单生成的系统日期如(20030405), 加上3位当天所录订单的最大序列号。编号从001开始。      允许用户选择客户资料,来表示当前合同的签约客户 允许用户选择产品资料,并且默认产品数量和产品售价为产品资料里的相应信息 允许用户选择签单的销售员和在签约过程中所起的作用(量化:签约比重) 并自动计算合同中所有产品的订单总额 通过该订单的录入的信息可以统计出各种综合统计报表 简要说明: 合同录入管理是本销售业务管理系统的中心。 修改记录 编写 邬师芬 日期 2003-4-25 审核 日期

外部项 系统名:销售业务管理系统 编号: 条目名:销售经理 别名:订单 输入数据流: 输出数据流: 工作日志审核 工作日志审核信息 销售签单提成处理(生成和审批) 销售提成记录信息 主要特征: 销售经理:为销售部门的主管人员。 其主要特征和员工相同: 员工编号、姓名、出生日期、性别、部门岗位、手机号 简要说明: 销售经理在本系统中起重要作用。 销售经理每天得了解销售员的销售工作和进展情况,并且具有提出和审批销售签单的提成权利,并且生成各种统计报表提交给某公司高层,为高层决策提供可靠的依据。 修改记录 编写 邬师芬 日期 2003-4-25

审核 3.3基本加工的说明书

日期 加工名称 销售签单提成计算 描述工具 决策数 销售签单提成奖金计算方法决策树 

系统总体设计

4.1软件模块结构的设计

软件模块结构的设计采用HIPO技术,它包括两个方面的内容: 4.1.1 HIPO分层图:

表示自顶向下分解所得系统的模块层次结构。如下图所示

4.1.2 IPO图(输入-处理-输出图):

IPO图采用图表格式来描述。它用来描述分层图中的一个模块的输入、输出和处理内容、本模块的内部数据和模块间的调用关系。如下表格所示,分别描述了HIPO图从上到下,连贯的3个模块。

IPO图 系统名:销售业务管理系统 制图者:邬师芬 模块名:销售管理 日期:2003-4-26 由下列模块调用: 调用下列模块: 录入销售合同 销售业务管理系统主控制程序 查询销售合同 销售签单提成计算 销售签单提成审批 输入: 输出: 销售合同信息 合同表、合同明细表、合同签约人 提成信息 提成记录表 处理内容: 主要处理销售合同信息(录入、查询、删除、修改、打印等) 和销售合同的签单者的提成计算处理过程和总经理的审批。

内部数据元素: 备注:

IPO图 系统名:销售业务管理系统 制图者:邬师芬 模块名:销售录入管理 日期:2003-4-26 由下列模块调用: 调用下列模块: 录入合同 销售管理 修改合同 查询合同 删除合同、合同明细等 打印合同 输入: 输出: 合同信息及相关信息 合同 处理内容: 如有新合同签订,则调用录入合同模块 如合同中的金额到帐,则调用修改合同模块 如删除合同信息,则调用删除合同模块 如需要打印合同信息,则调用打印合同模块。。。 内部数据元素: 备注:

IPO图 系统名:销售业务管理系统 制图者:邬师芬

模块名:客户资料管理 日期:2003-4-26 由下列模块调用: 调用下列模块: 录入客户资料 基本资料管理模块 修改客户资料 删除客户资料 查询客户资料 输入: 输出: 客户资料信息 客户资料表 处理内容: 如销售员发现潜在客户,则调用录入客户资料模块 如客户的联系方式和联系人发生变化,则可调用修改客户资料模块 对于需要拜访的客户的联系方式不祥时,则可调用查询客户资料模块… 内部数据元素: 备注: 4.2数据库设计

数据库的设计过程采用了数据的规范方法(第一范式、第二范式、第三范式)和关系模式的转换规则。 4.2.1迅蓝某公司基本实体集

某公司员工、合同(订单)、客户、产品

注:在实体关系图中,销售经理、销售员以及开发人员,在本系统中可以统一为同一实体某公司员工,他们通过岗位来区别具体实体。

他们各有属性如下:

o 某公司员工(工号、姓名、性别、上级领导、进入某公司日期、岗

位、部门、)

o 客户(客户编号、客户名称、联系人、联系电话、联系地址、所属

省份)

o 产品(产品编号、产品简称、名称、参考报价、开发负责人、产品

功能简介)

o 合同(合同编号、签单日期、客户编号、合同总额、备注)

实体间联系:

o 某公司员工包括:总经理、销售经理、销售人员、开发人员:

销售部有一个销售经理,领导多位销售人员。 每个销售员可以拜访和联系多个客户。 不同的销售人员可以拜访同一个客户。

一份合同可以由一个或几个销售员签下来的。 一份合同上可以有多个不同产品。 一份合同只能有一个签约客户。

一个产品有一个开发负责人,一个开发负责人可以负责多个产品。

o

即存在以下联系:

1对一:合同与客户,

1对多:销售经理与销售人员,合同与产品,合同与销售人员,开发负责人和产品

多对多:销售人员与客户

 

实体关系图(E-R图)如下

转换规则

o 每个实体集用一个关系模式表示,其中实体集的属性被转换成关系

的属性。如:本系统数据库中的实体集 产品 可以由下面的关系模式表示:

产品(产品编号,产品简称,名称,参考报价,开发负责人,产品功能简介)

倘若实体集E2与实体集E1的联系为N:1,E2的关系模式应包含E1的主属性.

o 倘若实体集E2是它同实体集E1中的N:1联系中的一个可选成员,

那么这个联系往往由包括E1和E2主属性以及该联系中的每个属性的各个关系模式表示。如:本系统数据库中的 合同 和 产品 之间,可以引入另外一个表示联系 包含的 关系。

o

合同(合同编号、签单日期、合同总额、备注)

产品(产品编号、产品简称、名称、参考报价、开发负责人、产品功能简介) 包含(合同编号#、产品编号#、产品数量、产品售价、产品总价)

o

N:M二元联系一般由另一个关系模式表示。这个关系模式由每个参加的实体集的主属性以及这个联系的任何属性一起组成。这种变化应用于参加实体集的各种成员类。如:销售员和客户之间的多对多联系,由另外一个关系模式表示

拜访(员工编号#、工作日期、 客户编号#)

关系模式

应用上述的转换规则,可得销售业务管理系统的关系模式是:

某公司员工(员工编号、姓名、性别、上级领导#、进入某公司日期、岗位、部门、)

客户(客户编号、客户名称、联系人、联系电话、联系地址、所属省份)

产品(产品编号、产品简称、名称、参考报价、开发负责人#、产品功能简介) 合同(合同编号、签单日期、客户编号#、合同总额、备注)

合同产品明细(合同编号#、产品编号#、产品数量、产品售价、产品总价) 合同签单人员(合同编号#、员工编号#、权重)

拜访(员工编号#、工作日期、 客户编号#、工作内容、上级审核日期、上级审核内容)

在这个模式中:

关系 某公司员工 内的外键 上级领导 表示联系 领导。 关系 产品 中的外键 开发负责人 表示联系 开发负责。

关系 合同 中的外键 客户编号 表示 客户 和 合同 之间的联系 签订

关系 合同产品明细 中的主键 合同编号 和 产品编号 表示的是 合同 和 产品 之间的联系 包含

关系 合同签单人员 中的主键 合同编号 和 员工编号 表示的是 合同 和 销售员 之间的联系 签订

关系 拜访 中的主健 员工编号 和外键 客户编号 表示的是客户和销售员之间的联系 拜访

4.3 计算机系统配置方案地选择和设计 4.3.1 硬件配置

硬件 推荐配置 计算机 Intel® 或兼容机 Pentium Ⅲ 500 MHz或更高 内存(RAM)1 128 MB w 本地安装:需要 CD-ROM驱动器 w 网络安装:可无 w 增强色16位或更高 监视器 w 800×600 分辨率或更高 网卡 100 MB 软驱 单机安装:需要 4.3.2系统软件配置

w Microsoft Windows NT Workstation 4.0 w Microsoft Windows NT Server 4.0 操作系统要求 w Microsoft Windows 98 w Microsoft Windows Me

w Microsoft Windows 2000 Professional w Microsoft XP w Microsoft SQl Server (网络版数据库) 其它软件要求 w Microsoft Office 4.4 系统总体安全性、可靠性方案与措施 ???

系统详细设计

5.1代码设计

基本数据项的代码格式说明:

在本系统中,所有代码都存放在 代码表 中。这样便于统一管理这些代码。代码的使用减少了数据库的数据冗余,遵从了数据设计的规则。本系统在相关的录入界面中充分利用这些代码,进行各种资料的信息录入。 代码表格式如下:

字段类别 字段长度 说明 字段名称 代码类别 字符型 16 组合关键字之一 代码编码 字符型 6 组合关键字之一 代码名称 字符型 20 代码简写 字符型 5 备用 本系统所使用的代码类别有:部门、省份、岗位、性别等。如下所示:

代码表 代码类别 部门 部门 部门 部门 部门 岗位 岗位 岗位 岗位 省份 省份 省份 省份 代码编码 11 21 31 41 51 1 2 3 4 100000 110000 200000 337019 代码名称 销售部 开发部 财务部 人事资源部 售后部 经理 销售 开发 商务助理 北京市 天津市 上海市 江西省 代码简写 CWB RSB SHB BJS TJS SHS JXS

性别 性别 1 2 男 女 5.2人机界面设计

5.3模块处理过程 ??

实施概况

6.1实施环境与工具的比较

因为某公司相关开发人员对Delphi 工具较为熟悉,所以相对比较选择Power Builder、 Visual Foxpro 和Delphi等开发工具,选择了Delphi作为开发工具。Delphi 5.0版相对其他版本来说使用较为稳定,所以采用了Delphi的5.0版本。

因篇幅问题不能全部显示,请点此查看更多更全内容