三,适合于用户的规程
在信息服务环境中，制定规程是最根本的一项工作，一个典型的计算中心有几十个书面规程，但是其中有三个对用户管理人员来说是尤其重要的，它们是：信息服务请求(SSR)的提交、系统开发方法、信息系统审查。
□ 系统服务请求
1.系统服务请求含义。系统(或用户)服务请求是用户管理人员向信息服务部门请求任何一种服务的正式媒介。一般由用户编制正式书面请求，将它提交给信息服务部门，并根据公司批准的规程来进行评价。
2.系统服务请求工作的内容。服务请求的工作有两个方面，首先，服务请求规程要求用户提出表达确切的、文字简炼的服务请求；其次，信息服务的领导和(或)信息系统政策委员会将根据实际情况，对信息服务请求作出正确的回答。
3.为了建立系统服务请求规程，有几个问题必须解决，即：
(1)谁批准服务请求?
(2)对否决的服务请求应有上诉规程吗?
(3)可能的决策选择是什么?
(4)信息服务请求应该包括什么信息?
一旦这些问题和其它一些问题得到解决，就能够建立系统服务规程。
4.系统服务请求实例。
图20.5.1的服务请求规程表明了一个公司是如何解决上述问题的，“矩形框”外面左上角的数字与下列编号所述内容相对应：
图20.5.1 系统服务请求规程实例
(1)用户管理人员提出一份关于建立计算机信息系统的建议，服务请求也可能与信息系统没有直接关系，例如，内部咨询。请求者通常是业务领域的管理人员，负责编制包括下列内容的系统服务请求：
①系统名称
②服务请求完成的日期
③提出服务请求那些人的名字、职务和单位
④包括下列内容的系统一般性描述：
A、陈述所推荐系统的目的
B、简要、生动地用文字图表描述所推荐系统的基本操作
C、推荐系统的工作范围，包括所有组织机构之间的关系、容量、活动的频率、系统复杂性和对人员的要求
⑤说明现有系统存在的问题
⑥说明推荐系统将如何解决目前的问题、加强服务、改进管理方法、节省开支，等等。
⑦资金来源说明
⑧预定系统开发的开始日期、实现日期、时间的紧急性说明
⑨说明公司对外发表的文件
⑩获得成功的其它类似系统一览表，包括负责类似系统组织的名称、部门领导成员
(11)推荐系统总的远景目标
B12其它有关的信息
服务请求是提交给信息服务部门的。完整的信息服务请求如表20.5.1所示。
(2)信息服务的领导只能对这样的项目作出决定：他(或她)估计工作量不会超过一年或项目支出不会超过30 000美元(这些数字是可变的，应根据公司的大小而异)，如超出，则信息服务项目要送到信息服务指导委员会那里作出一步研究。也就是说，信息服务领导人的权力是有限的。
(3)信息服务的领导根据资源的能力，或者接受请求或者拒绝请求。
(4)如果信息服务请求合理，信息服务领导就将状态报告提交给请求者，该报告说明了请求的确认、完成日期和所需成本。
(5)无需进一步核实就能完成请求工作。
(6)信息服务的领导将否定的状态报告提交给请求者并说明拒绝推荐项目的有关理由。 (7)请求者对信息服务领导的决定可以保留向上级权力机关(信息服务指导委员会)申诉的权力。
(8)将服务请求和否定的状态报告送到信息服务指导委员会复审。
(9)信息服务指导委员会可以否定信息服务领导的决定，也可以允许其继续有效。
(10)如果服务请求不再起作用，可把它搁置起来，在4个月(一个特定的数字)之后，请求者可使该请求重新有效。
(11)服务请求的副本要在召开信息服务指导委员会会议的两周之前分发给该委员会的每个成员。每个成员为复审该服务请求作好书面准备，并从他或她的角度提出利弊分析。
(12)信息服务指导委员会按推荐系统的原则和实际需要(此时批准是不可能的)而行事。该请求或者困为没有与公司的需要相一致而被搁置，或在应用方面有欠缺而被搁置，或赞成作进一步研究。
(13)信息服务的领导和相应的用户管理人员对人员的可用性进行估价。可用人员不足和在信息服务方面或业务领域方面人员委任不够也会使请求被搁置起来。
(14)信息服务的领导和相应的用户管理人员负责决定书面的人员委任书。
(15)可行性研究包含重要的人员委任、完成时间和公司的财力消耗，所以，信息服务指导委员会必须对是否花费资源作出进一步研究并作出决定。
(16)要编制系统服务请求的详细可行性研究报告，并提交给信息服务指导委员会审议。 (17)信息服务指导委员会审查可行性研究报告。实际上，审查的办法是仅仅在信息服务指导委员会会议上提出简略的口头评述。信息服务指导委员会对推荐的项目作出各种指示，不定期的搁置、或者批准同意开发、或者即使批准，但只能放在一个恰当的优先级位置上。
(18)批准该服务请求并在服务请求的队列中将它置于恰当的优先级位置上。
(19)信息服务指导委员会定期地审查批准项目清单及其优先级，并按公司需要作出批准开发的决定。
(20)信息服务指导委员会定期地给某些准许增加的项目开绿灯。
(21)否决其可行性研究报告并搁置该服务请求(详见第10项)。
上述提交和评价一个系统服务请求的规程包括两个决策层：一个上诉过程；另一个是关于项目的可行性研究要求以及关于完成可行性研究的其它可能的工作。详细介绍规程是为了说明这些选择方案。
表20.5.1某所大学的服务请求报告
课题：建立一个学生住房分配自动化系统
系统说明
系统的目标
主要目标
1.自动进行房间分配
2.自动进行帐单记录
最终目标
1.为工作人员提供信息，以便对学生住房分配作出有效的决策
2.替代现有的人工分配过程
系统的基本功能
系统的基本功能如下(由计算机完成)：
1.新生住房分配
2.上等住房分配
3.空房管理
4.编制学生费用表(包括损坏赔偿金)
5.自动进行文件更新(联机方式)
6.产生如下报告
(1)住校学生的地址(楼号、房间号)
(2)非住校学生的地址(楼号、房间号)
(3)学生家庭地址
(4)学生简况(以班级名作文件卷宗标题)
(5)宿舍楼统计
(6)房间分配说明
(7)待分配的学生名单
系统的范围
涉及到的部门和人员
1.注册员和会计——提供学生信息
2.校园维修工——报告宿舍楼和房间的完好情况
3.餐厅服务员——报告各类用餐的学生人数
4.招生办公室——提出新生住房需求
(1)学生数量
(2)住校学生约2 100个
(3)住校外学生约1 000个
(4)系统应能管理的学生数约4 000个
(5)新生约1 000个
人工系统的问题
1.整理文件的工作量太大
2.分配住房和确定同宿舍人员花的时间太多
3.对实际的空房和占用房掌握不准确
4.对宿舍的维修情况不清楚
5.在什么时间和地点出现空房不能马上知道
正确处理的方法
新系统应能解决上述提出的问题。为便于作出比较好的决策，系统应能及时提供信息。通过学生住房分配自动化系统，达到更有效的更合理的分配住房的目的。
资金的提供
系统开发和使用所需资金应另外提供，不能包括在人工系统费用预算内。
时间的估算
从可行性研究开始到系统完成，估计需要两年时间。并行工作是节省时间的关键。
特别说明
系统首先应保证新生的住房。
上等房间应分配给优秀学生居住。
按照学校的奖惩条例，对损坏宿舍的学生应进行处理。
长远规划
在两年之内完成学生住房分配自动化系统。在3年之内将该系统与学生信息系统合并成一个系统。
□ 信息系统审查
系统实现后的审查一般归入到系统开发方法中，但后来的系统审查通常只有在建立了定期审查的正式规程后方能实行。建立定期的系统审查是维护信息系统的最好方法。这些定期审查促使用户和信息服务人员在系统的缺点成为系统有效性的主要问题之前就识别和得到纠正。重新改变公司的需要比预先考虑到这些需要花钱更多。
图20.5.2 系统审查预定计划表
图20.5.2所示的系统审查预定计划表能够用来计划定期审查和确定开始这些审查的时间。在完成系统审查后，才开始编制系统审查预定计划表，请将图12.5.2各项栏目中圆圈内的数目与下列解释相互参照：
1.系统名称：指应用系统的名称(如工资单、总帐等应用系统)。
2.系统审查周期：指两次审查的时间间隔(例如：一季度一次，半年一次，等等)，审查周期一般不小于三个月，不大于一年。
3.审查日期：指每次审查的开始日期。审查日期应该与第5条一致。它能够为确定信息服务远景规划的周期提供依据。
4.审查协调员：指预定进行审查或实际进行审查的人员。
5.审查的起始日期：指系统审查的开始和结束日期。
6.进行的活动：一般填写“没有”或“修正过”。如果审查协调员建议该系统以某一方式进行修正，则须另加详细说明。这种说明应包括用户和信息服务人员关于适应性、清晰度、可用性、格式、响应时间、来回往返时间、规程、报告、文件等方面的评价和要求。这种说明还应包括根据定期审查结果所建议的活动及从这些活动中可能获得的利益。
在信息服务环境中，制定规程是最根本的一项工作，一个典型的计算中心有几十个书面规程，但是其中有三个对用户管理人员来说是尤其重要的，它们是：信息服务请求(SSR)的提交、系统开发方法、信息系统审查。
□ 系统服务请求
1.系统服务请求含义。系统(或用户)服务请求是用户管理人员向信息服务部门请求任何一种服务的正式媒介。一般由用户编制正式书面请求，将它提交给信息服务部门，并根据公司批准的规程来进行评价。
2.系统服务请求工作的内容。服务请求的工作有两个方面，首先，服务请求规程要求用户提出表达确切的、文字简炼的服务请求；其次，信息服务的领导和(或)信息系统政策委员会将根据实际情况，对信息服务请求作出正确的回答。
3.为了建立系统服务请求规程，有几个问题必须解决，即：
(1)谁批准服务请求?
(2)对否决的服务请求应有上诉规程吗?
(3)可能的决策选择是什么?
(4)信息服务请求应该包括什么信息?
一旦这些问题和其它一些问题得到解决，就能够建立系统服务规程。
4.系统服务请求实例。
图20.5.1的服务请求规程表明了一个公司是如何解决上述问题的，“矩形框”外面左上角的数字与下列编号所述内容相对应：
图20.5.1 系统服务请求规程实例
(1)用户管理人员提出一份关于建立计算机信息系统的建议，服务请求也可能与信息系统没有直接关系，例如，内部咨询。请求者通常是业务领域的管理人员，负责编制包括下列内容的系统服务请求：
①系统名称
②服务请求完成的日期
③提出服务请求那些人的名字、职务和单位
④包括下列内容的系统一般性描述：
A、陈述所推荐系统的目的
B、简要、生动地用文字图表描述所推荐系统的基本操作
C、推荐系统的工作范围，包括所有组织机构之间的关系、容量、活动的频率、系统复杂性和对人员的要求
⑤说明现有系统存在的问题
⑥说明推荐系统将如何解决目前的问题、加强服务、改进管理方法、节省开支，等等。
⑦资金来源说明
⑧预定系统开发的开始日期、实现日期、时间的紧急性说明
⑨说明公司对外发表的文件
⑩获得成功的其它类似系统一览表，包括负责类似系统组织的名称、部门领导成员
(11)推荐系统总的远景目标
B12其它有关的信息
服务请求是提交给信息服务部门的。完整的信息服务请求如表20.5.1所示。
(2)信息服务的领导只能对这样的项目作出决定：他(或她)估计工作量不会超过一年或项目支出不会超过30 000美元(这些数字是可变的，应根据公司的大小而异)，如超出，则信息服务项目要送到信息服务指导委员会那里作出一步研究。也就是说，信息服务领导人的权力是有限的。
(3)信息服务的领导根据资源的能力，或者接受请求或者拒绝请求。
(4)如果信息服务请求合理，信息服务领导就将状态报告提交给请求者，该报告说明了请求的确认、完成日期和所需成本。
(5)无需进一步核实就能完成请求工作。
(6)信息服务的领导将否定的状态报告提交给请求者并说明拒绝推荐项目的有关理由。 (7)请求者对信息服务领导的决定可以保留向上级权力机关(信息服务指导委员会)申诉的权力。
(8)将服务请求和否定的状态报告送到信息服务指导委员会复审。
(9)信息服务指导委员会可以否定信息服务领导的决定，也可以允许其继续有效。
(10)如果服务请求不再起作用，可把它搁置起来，在4个月(一个特定的数字)之后，请求者可使该请求重新有效。
(11)服务请求的副本要在召开信息服务指导委员会会议的两周之前分发给该委员会的每个成员。每个成员为复审该服务请求作好书面准备，并从他或她的角度提出利弊分析。
(12)信息服务指导委员会按推荐系统的原则和实际需要(此时批准是不可能的)而行事。该请求或者困为没有与公司的需要相一致而被搁置，或在应用方面有欠缺而被搁置，或赞成作进一步研究。
(13)信息服务的领导和相应的用户管理人员对人员的可用性进行估价。可用人员不足和在信息服务方面或业务领域方面人员委任不够也会使请求被搁置起来。
(14)信息服务的领导和相应的用户管理人员负责决定书面的人员委任书。
(15)可行性研究包含重要的人员委任、完成时间和公司的财力消耗，所以，信息服务指导委员会必须对是否花费资源作出进一步研究并作出决定。
(16)要编制系统服务请求的详细可行性研究报告，并提交给信息服务指导委员会审议。 (17)信息服务指导委员会审查可行性研究报告。实际上，审查的办法是仅仅在信息服务指导委员会会议上提出简略的口头评述。信息服务指导委员会对推荐的项目作出各种指示，不定期的搁置、或者批准同意开发、或者即使批准，但只能放在一个恰当的优先级位置上。
(18)批准该服务请求并在服务请求的队列中将它置于恰当的优先级位置上。
(19)信息服务指导委员会定期地审查批准项目清单及其优先级，并按公司需要作出批准开发的决定。
(20)信息服务指导委员会定期地给某些准许增加的项目开绿灯。
(21)否决其可行性研究报告并搁置该服务请求(详见第10项)。
上述提交和评价一个系统服务请求的规程包括两个决策层：一个上诉过程；另一个是关于项目的可行性研究要求以及关于完成可行性研究的其它可能的工作。详细介绍规程是为了说明这些选择方案。
表20.5.1某所大学的服务请求报告
课题：建立一个学生住房分配自动化系统
系统说明
系统的目标
主要目标
1.自动进行房间分配
2.自动进行帐单记录
最终目标
1.为工作人员提供信息，以便对学生住房分配作出有效的决策
2.替代现有的人工分配过程
系统的基本功能
系统的基本功能如下(由计算机完成)：
1.新生住房分配
2.上等住房分配
3.空房管理
4.编制学生费用表(包括损坏赔偿金)
5.自动进行文件更新(联机方式)
6.产生如下报告
(1)住校学生的地址(楼号、房间号)
(2)非住校学生的地址(楼号、房间号)
(3)学生家庭地址
(4)学生简况(以班级名作文件卷宗标题)
(5)宿舍楼统计
(6)房间分配说明
(7)待分配的学生名单
系统的范围
涉及到的部门和人员
1.注册员和会计——提供学生信息
2.校园维修工——报告宿舍楼和房间的完好情况
3.餐厅服务员——报告各类用餐的学生人数
4.招生办公室——提出新生住房需求
(1)学生数量
(2)住校学生约2 100个
(3)住校外学生约1 000个
(4)系统应能管理的学生数约4 000个
(5)新生约1 000个
人工系统的问题
1.整理文件的工作量太大
2.分配住房和确定同宿舍人员花的时间太多
3.对实际的空房和占用房掌握不准确
4.对宿舍的维修情况不清楚
5.在什么时间和地点出现空房不能马上知道
正确处理的方法
新系统应能解决上述提出的问题。为便于作出比较好的决策，系统应能及时提供信息。通过学生住房分配自动化系统，达到更有效的更合理的分配住房的目的。
资金的提供
系统开发和使用所需资金应另外提供，不能包括在人工系统费用预算内。
时间的估算
从可行性研究开始到系统完成，估计需要两年时间。并行工作是节省时间的关键。
特别说明
系统首先应保证新生的住房。
上等房间应分配给优秀学生居住。
按照学校的奖惩条例，对损坏宿舍的学生应进行处理。
长远规划
在两年之内完成学生住房分配自动化系统。在3年之内将该系统与学生信息系统合并成一个系统。
□ 信息系统审查
系统实现后的审查一般归入到系统开发方法中，但后来的系统审查通常只有在建立了定期审查的正式规程后方能实行。建立定期的系统审查是维护信息系统的最好方法。这些定期审查促使用户和信息服务人员在系统的缺点成为系统有效性的主要问题之前就识别和得到纠正。重新改变公司的需要比预先考虑到这些需要花钱更多。
图20.5.2 系统审查预定计划表
图20.5.2所示的系统审查预定计划表能够用来计划定期审查和确定开始这些审查的时间。在完成系统审查后，才开始编制系统审查预定计划表，请将图12.5.2各项栏目中圆圈内的数目与下列解释相互参照：
1.系统名称：指应用系统的名称(如工资单、总帐等应用系统)。
2.系统审查周期：指两次审查的时间间隔(例如：一季度一次，半年一次，等等)，审查周期一般不小于三个月，不大于一年。
3.审查日期：指每次审查的开始日期。审查日期应该与第5条一致。它能够为确定信息服务远景规划的周期提供依据。
4.审查协调员：指预定进行审查或实际进行审查的人员。
5.审查的起始日期：指系统审查的开始和结束日期。
6.进行的活动：一般填写“没有”或“修正过”。如果审查协调员建议该系统以某一方式进行修正，则须另加详细说明。这种说明应包括用户和信息服务人员关于适应性、清晰度、可用性、格式、响应时间、来回往返时间、规程、报告、文件等方面的评价和要求。这种说明还应包括根据定期审查结果所建议的活动及从这些活动中可能获得的利益。
