许多公司实体努力从事集中为下游的客户群提供服务或者供应货物。向下游客户提 供服务或者供应货物的公司实体被称作主要SLA提供方，下游接受货物或者服务的客户 被称作SLA客户。在一些情况下，服务/货物的提供通过常规的维护或质量保证协议进行 后勤管理。在另外的一些情况下，主要SLA提供方支持的基础设施是有风险的，并且不 被常规的维护和质量保证协议所支持，因为额外的故障时间有可能让SLA客户造成惨重 的损失，比如，可能发生计算机系统、通讯网络，或者生产线出现的故障。在这些有风 险的情况下，主要SLA提供方和SLA客户通常使用服务水平协议(SLA)来管理服务条 款。
过去，SLA供应主要是由提供服务或者货物的主要SLA提供方本身完成的，在这种 模式下，主要SLA提供方可以在功能方面控制所有的SLA业务。SLA业务功能有可能 包括，比如物流、合同管理、采购、人力资源配置、交付管理，以及财务数据处理。目 前，现代商业环境已经发生了戏剧性的转变，许多SLA业务功能外包给了以专门提供服 务为核心业务的提供方。这些供应者被称作二级SLA提供方。尽管这样的商业模式让一 些商业实体拓宽了服务面，提高了收入和利润，但是引入新的供给层经常导致失控，而 且对于主要SLA提供方来说，该失控带来的影响多半是毫无利润。
尽管在很小的范围内已经有了一些改进的尝试，但是一些SLA的商业功能和大部分 的实施方法都是优先考虑内部管理的。因此，在考虑把SLA外包时，以前的改进办法还 没有解决重要的交互、物流、数据处理和管理的问题。所以，需要发明一个新的系统和 方法，使得主要SLA提供方能够更好的控制SLA的业务功能，同时利用有资格的二级 SLA提供方提供SLA服务给SLA客户提供方。

一种外包式服务水平协议(SLA)交付管理方法包括：为SLA客户和二级SLA提供 方配置主数据，获得二级SLA提供方所提供的服务网络，管理二级SLA提供方的人力资 源网络，处理SLA客户供应请求，处理SLA提供服务的凭证，以及处理SLA提供的工 作订单支付。
一种为服务水平协议(SLA)客户和二级SLA提供方配置主数据的方法包括：配置 SLA提供方供应的物流控制库，配置SLA客户的主数据记录，配置SLA客户的订购记 录，以及使二级SLA提供方连接到网络。
一种获取二级服务水平协议(SLA)提供方所提供的服务网络的方法包括：根据至 少一个SLA客户的供应详细记录生成一个RFx格式的报价，把该RFx报价发到之前已 经建好的二级SLA提供方列表上，使二级SLA提供方对接收到的RFx报价生成一个相 应的RFx报价响应，处理至少一个二级SLA提供方的RFx报价响应，处理至少一个二 级SLA提供方接收到RFx报价响应验证后的购买请求，处理至少一个二级SLA提供方 接收到一个完整的购买请求后生成的订单。
一种管理二级服务水平协议(SLA)提供方的人力资源网络的方法包括：选择至少 一个附在二级SLA提供方订购单中的人力资源表，指定至少一个人力资源表中的供应人 员，为至少一个该人力资源表中的供应人员处理默认的工作日程信息设置，启动人力资 源供应表中非默认的可用日程管理，以及处理非默认的工作可用日程信息设置。
一种处理服务水平协议(SLA)客户供应请求的方法包括：处理SLA客户的服务供 应要求，处理服务供应的发送要求，处理供应人力资源表的发送通知记录，以及处理接 收到的供应人力资源表的发送通知记录。
一种处理服务水平协议(SLA)供应服务凭证的方法包括：根据供应人力资源表的 输入生成并且存储SLA供应服务的凭证，由适当的二级SLA供应方用户处理存储的SLA 供应服务凭证，根据适当的主要SLA供应方用户的输入处理通过认可的二级SLA提供方 的供应服务凭证，以及根据适当的SLA客户方用户的输入，处理通过认可的主要SLA 提供方的供应服务凭证。
一种处理服务水平协议(SLA)供应的工作订单支付的方法包括：提取出SLA客户 认可的供应服务凭证，生成帐单发票文件，处理SLA客户的帐单发票文件，处理来自SLA 客户的支付，以及签发向二级SLA提供方的支付。
上述发明摘要不涵盖本发明的每个实施例或所有方面。
附图说明
参照以下图和图表的细节描述，可以对本发明的方法和装置有更完整的理解：
图1是物理通信/数据网络的高级示意图。
图2A-B是一种外包式服务水平协议(SLA)和非SLA交付的管理系统和方法的高 级示意图。
图3是主要SLA提供方用户使用的网络主页说明图。
图4是SLA客户主数据高级功能性流程图。
图5是创建并且库存储SLA人力概要描述的流程图。
图6是创建并且库存储SLA供应材料的流程图。
图7是关于SLA供应记录的创建和存储流程图。
图8是关于SLA客户订货单的创建和存储流程图。
图9是支持主数据功能的数据库示意图。
图10是二级SLA提供方系统启动流程图。
图11是一个输出的SLA详细记录报告示例，与至少一个二级SLA提供方订货单无 关。
图12A-B是获取外包式二级SLA服务供应的高级过程的流程图。
图13是支持采购功能的数据库示意图。
图14A-B是人力资源服务供应管理的高级过程的流程图。
图15是人力资源日程配置的流程图。
图16是支持人力资源服务供应管理功能的数据库示意图。
图17A是物流供给和管理功能的流程图。
图17B描述了一个用于连接图17A流程的嵌有活动控制器的接口。
图17C描述了一个用于连接图17A流程的嵌有活动控制器的接口。
图18是支持物流供应和管理功能的数据库示意图。
图19A-19B描述了SLA供应工作确认和质量保证的流程。
图20是支持SLA供应工作确认和质量保证的数据库示意图。
图21是用于帐单功能的流程图。
图22是支持帐单支付功能的数据库示意图。
图23是信息管理和决策支持功能的宏观示意图。
表格1是放置主SLA提供方的标识和常规业务数据的示例性存储表。
表格2是放置SLA主提供方相关用户的标识和常规信息的示例性存储表。
表格3是放置各种SLA供应类型标识的示例性存储表。
表格4是放置各种SLA供应人工类型标识的示例性存储表。
表格5是放置各种SLA供应响应时间测量值的示例性存储表。
表格6是放置SLA材料标识和属性的示例性存储表。
表格7是放置SLA材料和位置之间映射关系的示例性存储表。
表格8是放置物理位置标识和属性的示例性存储表。
表格9是放置图8中物理位置类型标识的示例性存储表。
表格10-13是放置在系统中存储的地理位置标识和关系的示例性等级/关联存储表。
表格14-22是放置系统中劳动技术/属性概要数据的示例性等级/关联存储表。
表格23-25是存储由主要SLA提供方创建的SLA工作概要和相关技能/属性标识的 示例性存储表。
表格26是存储SLA劳动概要和SLA材料主记录之间映射关系和熟练程度要求的示 例性存储表。
表格27是存储关于SLA客户的常规业务信息的示例性存储表。
表格28是存储关于SLA客户合同相关细节的示例性存储表。
表格29是存储关于SLA客户端用户相关细节的示例性存储表。
表格30是存储SLA客户端服务供应记录相关细节的示例性存储表。
表格31是存储SLA客户端供应材料记录及其与表格30中服务记录映射关系的示例 性存储表。
表格32是存储SLA客户端服务供应记录和SLA供应劳动概要系统之间映射关系的 示例性存储表。
表格33是存储SLA详细记录和物理位置之间映射关系的示例性存储表。
表格34-36是存储主要SLA提供方和SLA客户之间定购单相关细节的示例性存储 表。
表格37-38是存储主要SLA提供方的RFx报价相关细节的示例性存储表。
表格39是存储SLA客户详细记录和主SLA提供方RFx报价之间映射关系的示例性 存储表。
表格40是存储二级SLA提供方的标识和常规业务信息的示例性存储表。
表格41是存储二级SLA供应方用户的标识和常规信息的示例性存储表。
表格42-46是存储二级SLA提供方提供的SLA人力供应情况业务系的标识和相同 应用范围的覆盖区域的示例性存储表。
表格47是存储发送给二级SLA提供方的RFx报价相关细节的示例性存储表。
表格48-49是存储适用于二级SLA提供方RFx报价响应的示例性存储表。
表格50是存储二级SLA提供方在RFx报价响应过程中提交的候选人力资源相关细 节的示例性存储表。
表格51-52是主要SLA提供方和二级SLA提供方之间定购单细节的示例性存储表。
表格53是存储适用于供应人力资源服务的标识和细节的示例性存储表。
表格54是存储适用于供应人力资源个人服务的分配细节的示例性存储表。
表格55-57是存储人力资源可用日程/时间服务信息的示例性存储表。
表格58-63是存储日程系统使用的基础源数据的示例性存储表。
表格64-66是存储适用于SLA供应服务请求标识和细节的示例性存储表。
表格67是存储能够和SLA供应服务请求一同使用的状态代码的示例性存储表。
表格68是存储供应分发请求的标识和相关基础细节的示例性主存储表。
表格69是存储与SLA供应服务请求相关联的SLA可用资源相关细节的示例性存储 表。
表格70是存储在运作过程中，可利用于主要SLA供应方用户的SLA资源优先选项 的示例性存储表，取值存储在表格68中。
表格71是存储在其生命周期中，可利用于SLA供应服务请求的潜在状态代码的示 例性存储表，取值存储在表格68中。
表格72是存储与供应分发请求相关的特殊细节的示例性存储表。
表格73是存储关于SLA供应凭证的标识和基础细节的示例性存储表。
表格74是存储用于SLA供应凭证的服务细节的示例性存储表。
表格75是存储用于SLA供应凭证的材料细节的示例性存储表。
表格76是存储用于SLA供应凭证线项的潜在供应结果配置类型的示例性存储表。
表格77是存储用于SLA整个生命周期内供应凭证的潜在状态代码的示例性存储表。
表格78是存储用于SLA供应凭证线项的潜在质量性能配置代码的示例性存储表。
表格79是存储用于SLA供应凭证线项的潜在管理性能配置代码的示例性存储表。
表格80是存储SLA客户在浏览SLA供应凭证时使用的主要偏差代码标识的示例性 存储表。
表格81是存储有偏差的SLA凭证相关细节的示例性存储表。
表格82是存储被认可的SLA凭证的解压批处理文件标识和基础信息的示例性存储 表。
表格83是存储与被认可的SLA凭证解压批处理文件相关的特殊记录的标识和基础 信息的示例性存储表。
表格84是存储SLA客户发票-帐单文件相关标识和基础信息的示例性存储表。
表格85是存储与SLA客户发票-帐单文件相关的特殊记录标识和信息的示例性存 储表。
表格86是存储与二级SLA提供方发票-帐单文件相关的标识和基础信息示例性存 储表。
表格87是存储与二级SLA提供方发票-帐单文件相关的特殊记录的标识和信息的 示例性存储表。
表格88是存储各种“SLA客户服务覆盖期间”标识的示例性存储表。
表格89是存储各种能够被人力资源向SLA客户提供服务时获得的SLA费用类型标 识的示例性存储表。
表格90是存储用于特殊SLA客户服务覆盖期间的二级SLA提供方报价响应记录速 度值的示例性存储表。
表格91是存储用于特殊SLA供应费用类型的二级SLA提供方报价响应记录速度值 的示例性存储表。
对该技术了解的人会知道，示例性表格1-91的条目没有穷举所有可能的数据值。 额外的其它数据值可以通过对数据库进行简单的改动来实现，具有普通技术的人就可以 做到。

本发明的各种技术方案提供了一种全面的、网络驱动的计算机系统和方法，以启 动和管理主要业务功能，该主要业务功能用于在主要SLA提供方，二级SLA提供方和 SLA客户之间的外包式服务水平协议(SLA)的提供。该主要业务功能包括：合同管理， 采购，人力资源配置，SLA物流，SLA交付管理，财务数据处理，企业内部系统合作， 以及报表/信息管理。根据本专利申请的应用目标，术语“业务功能”是指最佳实用SLA 管理系统中多个核心商业行为中的任何一个，包括主数据功能，采购功能，人力资源服 务供应管理功能，供应管理功能，SLA工作确认和质量保证功能，帐单/支付功能，以 及信息管理/报表功能。
从高级别的视角来看，增强的业务功能性是指，在一个通常的具体应用中，结合 一个协作式的网络驱动数据处理环境，该协作式网络驱动数据处理环境由专门设计用来 获取、处理和管理外包式SLA提供方品数据的数据库支持。该数据处理环境，是指一 个SLA供应管理环境，通常包括主数据功能，采购功能，人力资源服务供应功能，供 应管理功能，SLA工作确认和质量保证功能，帐单/支付功能，以及信息管理/报表功能。
主数据功能存储SLA客户的主数据，这些主数据应用于，比如，常规商业信息， 物流控制信息，SLA合同信息，SLA供给的详细信息，以及购买订单信息。主数据功 能也可以存储一个SLA供应的技术概要和工作描述源信息库，一个SLA供应的技术概 要库，以及一个SLA供应细节乃至SLA供应技术概要矩阵。
采购功能通常包括运行多个功能来启动主要SLA提供方以获取和存储用于二级 SLA提供方的业务信息，使主要SLA提供方按照SLA技术水平和地理覆盖能力对二级 提供方进行分类，使主要SLA提供方按照主数据功能的细节描述来系统地识别和量化 SLA客户的覆盖要求，使主要SLA提供方从SLA客户的覆盖记录中生成系统的RFx 报价，使主要SLA提供方系统和逻辑地为每个生成的RFx报价创建二级SLA提供方的 报价请求列表，使二级SLA提供方系统地生成RFx报价响应并且在需要的时候随响应 附加提交可用的人力资产资源，使主要SLA提供方系统地检查被提交的报价请求/提议 请求/报价(RFx)报价响应请求，以及使主要SLA提供方系统地接收/授予RFx报价响 应并且通过参照RFx报价响应细节为二级SLA提供方生成订购单。
人力资源服务供应管理功能通常执行多种功能以使主要SLA提供方检查和批准 被提交的候选RFx报价响应的配置，使系统的主要SLA提供方针对被提交的RFx报价 响应后选项提供方将配置/状态通知发送给二级SLA，使SLA供应资源记录通过一个主 要SLA提供方针对已提交的RFx报价响应候选项的批准/认可而生成提供方，使二级 SLA提供方可以访问人力资源系统，使二级SLA提供方的人力资源可以执行系统协议， 使二级SLA提供方和被确认的人力资源进行工作有效性日程管理/配置，使保证主要 SLA提供方评估物流时间范围以及使主要SLA提供方在服务中断期间对前摄的人力资 源进行调解。
供应管理功能通常执行多种功能，实现服务供应功能请求功能，从而使SLA客 户通过此功能可以向一个主要SLA提供方创建和提交服务供应请求，提供方并使主要 SLA提供方系统具备询问功能，此功能可以用于对配置的二级SLA提供方清单的输出 及其可应用的价格和为服务供应分配而设计的相关人力资本资源的实用性提供方。询问 标准能够通过选择性用户输入或者系统输入而生成，类似一个明确的SLA客户服务供 应请求接收的情况。
供应管理功能还通常执行多个功能，使主要SLA提供方系统地提交一个服务供 应分配请求记录给一个二级SLA提供方，使一个二级SLA提供方确认资源的可用性以 及向主要SLA提供方并发的资源分配提供方，以及使一个主要SLA提供方向一个SLA 客户确认资源分配。
SLA工作确认和质量保证功能通常执行多个功能，使二级SLA提供方可以对配 置凭证功能进行资源访问，通过其细节关于，比如，执行的工作，配置的材料，以及时 间是响应服务供应分配请求的输入，使一个二级SLA提供方向一个SLA客户提交一个 服务配置凭证以进行检查和认可配置，使一个SLA客户处理一个二级SLA提供方的服 务配置凭证并且提供质量确认评估信息，并使一个SLA客户向一个主要SLA提供方提 交一个已经处理的二级SLA提供方的服务配置凭证。
帐单/支付功能通常执行财务数据处理功能，使被认可的SLA客户的配置系统摘 录获得认可的服务配置凭证，主要SLA提供方对SLA客户的帐单-发票文件的系统生 成，使二级SLA提供方对主要SLA提供方的帐单发票文件的系统生成，主要SLA提 供方根据SLA客户的支付上传支付接收数据，主要SLA提供方在SLA客户已经支付 的前提下向二级SLA提供方进行支付。
信息管理/报表功能通常执行一个常规的信息输出功能。该功能把获取的系统数据 生成报告或者进行分析。
现在开始介绍附图。图1是物理通信/数据网络的高级示意图。计算机网络节点的 五个主要类型如图1所示，即，浏览器或其它用户接口(UI)，通信/网络服务器，应用 服务器，应用模块，数据库服务器和数据库。尽管通常的环境包括了主机网络激活的解 决方案，但是各种实施例还是有可能在使用内部局域网时占用广域网(WAN)。只要对 硬件和应用程序进行很小的改动，本发明描述的各种不同原理的应用就不会受到计算机 环境视角的限制。
参照图1，一个计算机系统100包括一个采购/SLA管理系统150，可被系统用户 110(a)-(e)通过系统浏览器115(a)-(e)操作的用户系统101-105，一个因特网/局域网通信 网络120，一个应用服务器155包括数据处理模块160-180和一个数据库系统185。用 户系统101-105是系统入口和访问入口，通常表现为最小限度的登录/安全功能和图形 用户接口(GUI)。
数据处理模块160-180包括一个管理模块160，一个主要SLA提供方模块165， 一个二级SLA提供方模块170，工作人员模块175，以及，例如，一个SLA客户模块。 如果主要SLA提供方计划进行采购或者总体授权一个方案并且把系统100放置在自己 内部的基础设施中，管理模块160在某些实施例中则会被省略。
主要SLA提供方模块165功能是作为计算机系统100的业务管理者，并且在通 常的实施例中，控制SLA客户、二级SLA提供方、应用用户和SLA人力资源中工作 人员的上传。本领域的技术人员会认同，主要SLA提供方是具有SLA客户的业务实体， 它通过合同来提供SLA和其它服务，还与二级SLA提供方之间有子合同，并且为SLA 的提供人员和SLA提供工作执行质量负最终责任。
二级SLA提供方模块170向与主要SLA提供方有子合同的业务实体提供通信和业 务处理支持以提供SLA提供覆盖。SLA工作人员模块175为具有子合同的二级SLA提 供方的单个SLA提供人员提供通信和业务处理支持。SLA客户模块180为请求并且签 署了SLA提供合同的单个SLA客户提供通信和业务处理支持。
在各种实施例中，在可控的实时数据处理设置中，协作通信和业务处理能力将被演 示为计算机系统100一部分的不同实体联系在一起。相比而言，在许多的先前系统中， 多个系统通常被应用于目的是管理这些业务活动。在过去，客户数据和行为通常在客户 关系管理(CRM)或者其它的客户应用软件中被管理，，当物流在一些项目管理应用软 件类型中被管理；同时，即使实在要用，提供方和人力资源管理功能和细节通常在附加 的应用软件中被管理。
本系统100是一个完整的采购周期，物流管理和管理方案，把主要SLA提供方， 二级SLA提供方和SLA客户结合到一个协同工作环境中。系统100为主要SLA提供 方可以对以下部分进行控制提供服务：SLA提供物流计划，提供人力资源水平/熟练度， 提供资源可用性/能力，SLA提供资源分配，SLA提供进程通信，SLA提供质量保证和 投资管理收益。另外，系统100结合了所有的核心功能业务处理，比如但不限于，在一 个应用环境中进行卖方管理，采购，帐目，财务和风险管理，避免了使用多重全异的而 且高成本的应用软件。
图2A-B中描述了一种外包式服务水平协议(SLA)和非SLA交付管理的高级点 到点的系统和方法。在表格2A中，流程200从步骤202开始。在步骤202，主要SLA 提供方已经和一个或多个物理地点的一个或者多个SLA客户一起定义或者预定了特定 业务通话可交付物。在步骤204，对与SLA客户和二级SLA提供方对应的主数据进行 配置。在步骤210，RFx报价从SLA请求记录中产生，来明确可能的二级SLA提供方 的定价和资源能力。在步骤212中，RFx响应被检查，并且根据服务提供能力和定价确 定出价金额。在步骤214，与可适用的服务提供方协商最终定价和服务的可交付项。
在步骤216，可适用的二级SLA提供方建立总括订购单。在步骤218，SLA提供矩 阵被配置，而且二级SLA提供方的总括订购单和SLA主数据记录系统地联系起来。主 要SLA提供方维护矩阵的编辑控制，并能够手工建立联系，比如在二级SLA提供方通 过非竞争报价流程被识别的情况下。在步骤220，可适用的二级SLA提供方为主要SLA 提供方提交资源候选。被确认的人力资源与相应的二级SLA提供方总括订购单进行关 联。在步骤222，二级SLA提供方被通知人力资源(HR)的确认情况。在步骤224对二 级SLA提供方的资源库进行填充，并且配置系统提供的人力资源的日期/小时可用时间 安排表。
在步骤226，二级SLA提供方人力资源被颁发系统访问证书。在步骤228，二级 SLA提供方人力资源对系统100进行访问，执行协议，并且确认客户SLA设施的访问 要求/规则。在步骤230，主要SLA提供方准备好对SLA客户的请求进行管理。
现在参照图2B，执行过程从步骤230开始到步骤240。在步骤240，SLA客户端 的用户创建一个服务提供请求并且提交给主要SLA提供方。在步骤242，主要SLA提 供方用户进入SLA管理模块160。在步骤244，系统100被询问并且返回一个所有被配 置用来为SLA客户需求提供服务的二级SLA提供方列表。在步骤246，服务提供方列 表显示出来，比如，被认可的服务提供方资源，资源的可用性，总括订购单参考，和合 同服务费用以及可适用的过去的性能传递矩阵。在步骤248，二级SLA提供方的记录 被选定。在步骤250，主要SLA提供方用户把服务提供分配要求提交给二级SLA提供 方。在步骤252，二级SLA提供方确认分配能力。
在步骤254，主要SLA提供方发送确认消息给SLA客户端用户。在步骤256，二 级SLA提供方分配可用的资源给SLA客户端。在步骤260，提供方资源在SLA客户端 执行工作。在步骤270，提供方资源把配置后的数据需求加入到SLA的计时/交付模块。 在步骤272，二级SLA提供方的资源交付凭证被提交到SLA客户端用户。在步骤274， SLA客户端用户处理已经提交的凭证并且完成交付率。在步骤276，凭证被提交给主要 SLA提供方并且被确认。在步骤278，对经过系统配置和确认的凭证进行细节提取，并 且为SLA客户生成一个帐单文件。在步骤282，所述帐单文件被传递给SLA客户。在 步骤284，SLA客户向主要SLA提供方付费。在步骤286，主要SLA提供方向二级SLA 提供方付费。
图3是主要SLA提供方用户的网络主页说明图。在图3中，用户接口300已经被 分成两个主要的段，一个用户导航栏/菜单310和一个动态操作板320。导航栏/菜单310 是根据需要激活应用功能的主要用户接口方式，而动态操作板320为用户服务突出/提 示特定的需要关注的业务活动。用户能够通过用户导航栏/菜单310或者动态操作板320 使用相同的应用功能和形式。
主数据功能的通常信息方面是常规业务信息，物流控制信息，SLA合同信息以及 SLA提供的细节信息。常规业务信息包括关于主要SLA提供方和SLA客户的信息。用 来存储常规业务信息的示例性数据库表包括表格1-2，8-9，27和29。通常业务信息的 例子包括：关于商业实体类型的业务信息要素，公司标识，运作地点，公司规模，雇员 数目以及用户信息。实际地理位置按照所示数据库设置被定义，例如，在表格10-13中。 该地理性信息，能够被扩展到公司邮编或者其它的唯一性设置，比如商业区域，使一个 具体位置按照国家，地区，县，和城市/人口中心的被定义。
物流控制信息表现了主要SLA提供方在SLA提供方面的商业模式的基础定义。被 定义的信息类型有多种，其中一组信息处理提供服务类型，提供劳动类型，提供时间框 架，提供材料和提供材料存放设施。用于存储物流控制信息的示例性数据库表包括表格 3-7和88-89。
用于特定主要SLA提供方的数据值是优先处理的，并且会经常随着产业和公司的 不同而有很大不同。上述存储表格是可以被主要SLA提供方使用的基础数据，同时管 理特定的业务记录。因此，配置数据会被当作一个资源库，主要SLA提供方通过所述 资源库按照提供服务类型和提供SLA响应时间框架定义可能的数据值。被定义为物流 控制信息源的其它信息组分别是：一个SLA工作描述源库，一个SLA提供技术概要库， 以及一个SLA提供细节至SLA提供技能概要矩阵。
该信息(比如SLA工作描述源库，SLA提供技术概要库，以及SLA提供细节至 SLA提供技能概要矩阵)通常包括业务或者技术能力相关的细节，所述业务或者技术 能力适用于主要SLA提供方资源为集体SLA客户所提供的服务。同时上述讨论过的物 流控制信息元素处理业务如何进行，该控制数据定义了提供活动的领域。用于存储SLA 提供资源技术概要信息的示例性数据库表包括表格23-26。这些表格存储了由主要SLA 提供方创建的特定SLA资源提供技能/特征概要的标识以及所述概要用到的细节。
表格26在被认为必要的情况下，明确地映射任意可适用的材料主记录到提供材料 概要。一个典型恰当的例子是燃气发电机的制造商。在这个例子中，一个特定的SLA 提供概要有可能是为维修或者安装技术人员创建的。而且，制造商也许想要指派仅仅特 定的发电机单元模型组和SLA提供的概要联系起来，进一步来说，SLA提供的概要必 须对与之有关的特定单元部分具有服务的技术熟练性。
如表格23-25所示，所述表格中包含的大部分数据元素都是整数，而不是文本，因 为系统100和用于SLA资源提供技术/特征概要表的分等级数据库源一起被明确的定 义。所述资源库的数据被包含在表格14-22中。表格14-22包含了技术设定概要的源数 据，而表格23-25包含了相关于特定的被配置和储存的SLA提供资源概要的信息。尽 管没有明确描述，关于技术设定概要的源数据能够被引导到数据环境中，用于满足主要 SLA提供方的需要。
以上示例的主数据功能一般位于步骤202-204，为所有的SLA提供行为的管理提供 坚实基础。参照上述说明，一个主要SLA提供方定义了，比如，业务的目的，如何管 理业务，为客户提供服务所用到的业务/技术资源类型，以及通常在哪里开展业务。图 4-9和表格1-36提供了关于主数据功能的进一步信息。
图4是SLA客户主数据功能的高级功能性流程图。数据记录类型的产生在图4中 被描述为一个线形过程。所述的过程并不一定是一个要求或者限制，而仅仅是为了常规 理解的目的展示。本领域的技术人员了解，某个数据记录的类型逻辑上取决于主数据记 录的先决条件。例如，如果没有对SLA客户商业实体记录的关联，就不可能装载SLA 客户端用户信息。
再回到图4，流程400从步骤402开始。在步骤402，SLA客户记录被手工或者通 过实时数据更新进行创建。在步骤404，通过手工或者实时数据更新载入SLA客户业 务数据。在步骤404，SLA客户端用户数据通过手工或者实时数据更新被载入。在步骤 408，SLA客户位置通过手工或者实时数据更新被载入。在步骤410，SLA客户合同被 载入。在步骤412，SLA客户的提供记录被创建。在步骤414，可适用的SLA客户提供 材料记录被创建。在步骤416，SLA客户订购单记录被创建。在步骤418，SLA客户的 提供记录和订购单关联起来，用来创建订购单排列项。
图5是创建并且库存储SLA提供人力概要描述的流程图。通常解释为，所述概 要表现了人力资源劳动力执行与主要SLA提供方产品或系统相关联的提供服务所必须 的技能特征。在图5中，流程500从步骤502开始。在步骤502中，主要SLA提供方 用户导航由主页进入SLA服务提供技术概要控制。在步骤504，用户选择创建新的提 供技能概要选项。在步骤506，用户从下拉单中选择业务类别。在步骤508，用户从强 制下拉单中选择业务平台。在步骤510，用户从强制下拉单中选择业务属。
在步骤512，用户从强制下拉单中选择常规功能。在步骤514，用户从强制下拉单 中选择技术/特征。在步骤516，用户添加客户证书，特征等等，并不局限于一个源数 据库中。在步骤518，用户把服务概要和材料主记录进行关联，并且指定必需的熟练度。 在步骤520，用户添加工作名称和可选的系统描述。在步骤522，用户把创建的记录进 行保存。在步骤524，判断出所述工作名称是否唯一。如果唯一，转到步骤526执行， 在该步骤中，记录被存储在SLA提供人力概要库中。如果在步骤524，所述工作名称 被判断不是唯一的，转回到步骤520执行。在优化的环境中，主要SLA提供方创建能 够满足所有提供任务的完整的服务概要。
图6是创建并且库存储SLA提供材料的流程图。在图6中，流程600开始于步骤 602，在该步骤中主要SLA提供方用户导航进入SLA提供材料模块。在步骤604，用户 选择创建新的材料主记录。在步骤606，用户指定一个短的材料名称。在步骤608，用 户指定对材料的描述。在步骤610，用户指定所述材料是一个功能还是最终产品。在步 骤612，用户指定所述材料是否有库存。在步骤614，用户指定材料的生产商。在步骤 616，用户指定材料的上次成本。在步骤618，用户设置材料所述上次成本的日期。在 步骤620，用户指定现有材料清单数目。在步骤622，用户指定材料的补给存储点。在 步骤624，用户指定材料的补给存储量。在步骤626，用户保存这些设置。
在步骤628，查明材料是否有库存。如果在步骤628中查明有库存，则转到步骤630 执行。在步骤630中，为用户提供一个图形用户接口(GUI)，使得用户可以选择地点记 录。在步骤632，用户选择地点并且定义现有的存储量。在步骤634，用户存储上述设 置。在步骤636，被存储的设置保存到SLA提供材料库中。如果在步骤628中，查明 材料没有存储，则转到执行步骤636。
工作描述的各种方面都有可能被定义，例如，不成文的描述或者数据库条目。简单 的工作描述概要也是可行的，如果这是主要SLA提供方选择的商业模式。在这样的情 况下，可以不使用技术概要工具，而是使用上传或者人工的方式创建向SLA客户服务 提供所需的技术相关的工作名称和描述。图5和图6是这些概念的实例。
物流控制信息的定义是由主要SLA提供方的核心能力决定的；因此，在特定用户 提供需求的关联之外，对能够考虑到人工、质保、时限、设备等等的提供服务范围进行 定义和记录是合理的，所述定义在信息管理工作中进行。
所述系统100通过使主要SLA提供方上传或者输入与SLA客户合同相关的基本细 节启动一个参考周期。表格28提供了一个关于特定合同的高级信息示例图。大多数据 是基础业务信息，然而，表格28也存储了一些用于合同记录的特定不同提供服务的数 量。提供计数的一个原因是确保流程执行时提供网络中没有漏洞而且所有合同中的服务 都可以提供和解决。在访问基本合同数据之后，主要SLA提供方能够使用一个特定的 SLA合同记录作为参考点来创建更多精确的SLA提供细节记录。参照例如，表格30-33。
图7是关于SLA提供记录的创建和存储流程图。在图7中，流程700从步骤702 开始执行，在该步骤中，主要SLA提供方装载合同数据域，并且在tblSLAclientContract 中创建一条记录(如表格28所示)。流程700举例来说可以是一个从访问基本合同数据 信息开始的线形流程，或者用户可以被提供一个GUI来使其从多个由SLA客户或者其 它变量筛选过的SLA合同记录列表中选择一个特定的SLA合同记录。
步骤704-708是关于创建一个SLA提供细节记录。在步骤704中，系统接口试图 提示用户创建相关的SLA提供细节记录。在步骤706，用户激活一个创建的SLA提供 细节控制。在步骤708，系统100在新纪录中填充来自SLA客户合同记录的默认数据。
步骤710-712是关于特定提供类型的选择，所述类型可能已经通过带有已被存储的 可能取值的应用程序配置所创建，例如在表格3中。在步骤710中，系统100提醒用户 选择一个提供类型。在步骤712，用户选择一个提供类型并且对输入进行存储。
步骤714-716是关于一个特定的提供工作类型的选择，所述类型可能已经通过带有 已被存储的可能取值的应用程序配置所创建，例如在表格4中。在步骤714中，系统 100提醒用户选择一个提供工作类型。在步骤716，用户选择一个提供工作类型并且对 输入进行存储。
步骤718-720是关于SLA行为计费或者不计费特性的用户详细说明。一个不计 费的行为发生在，如果合同是，例如，质保服务的情况下。在步骤718中，系统100 提示用户明确计费或者不计费提供。在步骤720，用户指定计费或者不计费并且对输入 进行存储。程序从步骤720转到步骤722执行。
步骤722-724是关于对于该记录时间限制适用性的用户详细说明，其中被示例的选 择由路径724＝yes开始。在步骤722中，系统100提醒用户指定是否需要响应时间。 在步骤724中，用户指定是否需要响应时间并且对输入进行存储。
步骤726-728是关于一个特定的提供服务响应时间的选择，所述时间可能已经通过 带有已被存储的可能取值的应用程序配置所创建，例如在表格5中。所述SLA服务响 应时间不同于在各方之间所建立的并且通常记录在可适用的SLA合同中的SLA提供方 对于服务开始所发送的SLA客户问题通知的时间。在步骤726，系统100提醒用户指 定响应时间衡量标准，如果需要使用的话。在步骤728，用户指定需要的响应时间或者 衡量标准，并且对输入进行存储。
步骤730-732是关于用户特殊细节、合同信息或者所需常规信息的描述性注释输 入。在步骤730，系统100提示用户完成提供细节性描述。在步骤732，用户完成细节 描述并且对输入进行存储。
步骤734-736是关于主要SLA提供费用的用户说明/评估。在步骤734，系统100 提醒用户提供供应费用信息。在步骤736，用户完成供应费用信息并且对输入进行存储。
步骤738-740是关于可能使用的SLA提供服务事件数目的用户说明/评估。基础物 流计划通常需要这样的一个方案。这样的信息对随之发生的RFx报价过程具有直接影 响。通过所述信息包含的数目，服务提供方对资源可用性进行计划，并且平衡报价过程， 以确定最佳协议价格。在步骤738，系统100提示用户明确预期的或计划的服务提供频 率。在步骤740，用户完成提交所述预期频率并且对输入进行存储。
在步骤742-746描述的执行过程中，用户被提醒选择一个特定的SLA提供技术概 要来和SLA提供细节记录进行关联。如果主要SLA提供方选择使用这种模式，用户可 以选择一个SLA提供技术概要或者按照之前所述的一个存储的工作名称，。尽管所述过 程描述了对之前存储记录的选择，系统100要能够支持可变地创建一个工作名称/或者 创建SLA提供技术概况描述。要达到最好的使用情况，需要之前创建和存储SLA资源 提供概要记录，前提是主要SLA提供方的业务动态性。之前存储的资源概要记录细节 被存储在例如表格23-25中。在步骤742，系统100提醒用户指定可适用的SLA服务提 供技术概要或者工作名称。在步骤744，用户从下拉菜单中选择一个概要/工作名称。 在步骤746，系统100提示用户存储一个可选的细节工作概要关联，并且用户把所述关 联进行存储。
在步骤748-750描述的流程中，用户被提醒选择并且联合可适用的SLA客户提供 服务设施/地点。在步骤748，用户被提示指定可适用的客户SLA服务地点。在步骤750， 用户从下拉菜单中选择客户SLA服务地点，并且对输入进行存储。
在步骤752-760描述的流程中，用户被提示选择任意的可能存在关于SLA提供细 节记录的材料关系。步骤752只是通常的是/否提示；在步骤752，示例性的选择是“是”。 在步骤752，系统100提示用户指定任意的SLA提供材料需求。在步骤754，用户从下 拉菜单中选择材料。因为之前在SLA提供技术概要和存储的材料主记录之间建立的联 系，一个默认的材料(组)列表被提供，例如，在表格26中。这样的列表可能被提供 做为一个可选业务进程模式，但是不需要作为约束，这就意味着如果需要的话用户可能 可以使用全部的材料主列表。
在步骤756-758描述的流程中，用户被提示建立可用于任意被选择的材料主记录的 配置设置。用户指明，例如，材料是否付费/免费，质保物品，有库存商品，存储要求 等等。本领域的技术人员了解，表格31所示的配置特征并不是限制性的，并且额外特 征可以被加入到应用软件和数据库中。在步骤756，用户被提示配置SLA材料需求， 比如库存要求，质保指示等等。在步骤758中，用户配置材料记录。在步骤760中，用 户存储设置和材料关联。
在步骤762-768描述的流程中，用户被提示保存和命名SLA提供细节记录。尽管 流程没有明确描述这个功能，主要SLA提供方用户能够在临时状态中存储所述记录， 以在其它时间完成。在这样的例子中，数据库将通过完成或未完成的代码状态和动态或 非动态的记录来维护路径。在步骤762中，系统100提示用户存储提供细节记录并且用 户存储该记录。在步骤766，用户完成提供细节命名并且存储输入。在步骤768，SLA 提供细节记录被创建和存储。
如果SLA客户从未产生过任何需求，主要SLA提供方在通常情况下不会使用SLA 合同信息能力。通常，服务水平协议通过合同管理。将提供活动与被执行的合同连接和 参考存在明确的业务需要，因为SLA合同细节通常属于单独的合同管理应用，具有限 制或非交叉功能的应用能力，可以进行企业采购，项目管理或者财务数据处理应用。在 很多情况下，合同细节只存在于纸上。所以，把基础合同细节输入将真正管理具体SLA 活动的应用中是比标准业务程序的一种改进。将这些基本合同细节输入到管理应用中使 下游的SLA和管理数据处理活动按照商业思路维持原来的SLA合同的形式发生。
图8是关于SLA客户订货单的创建和存储流程图。在图8中描述的订购单信息和 SLA提供外包式采购过程明显不同。许多商业实体倾向于在可控财务系统的支持下操 纵财务交易。不幸的是，因为SLA提供工作的复杂特点，许多控制细节不能从SLA合 同中导出/传送到财务系统中，这是因为大部分财务/采购系统在一个过分简单的描述- 数量-价格的模式下被配置。这通常导致一种情况，就是真正的细节存在于合同中，并 且财务系统有效地存储财务交易认证记录。
各种实施例允许从那些SLA合同细节中为众多用户提取信息，其中的一个就是建 立一个最优方法的订购单流程。最终，许多SLA提供活动将会导致付费交易。所以， 预测业务需要并在指定SLA提供细节记录和为SLA客户创建的订购单之间建立关系， 以及主要SLA提供方操纵财务交易是具有逻辑意义的。
再次参看图8，流程800从步骤802开始，在这个步骤中，主要SLA提供方完成 提供细节记录的配置。步骤802表示在之前SLA提供细节信息讨论中描述的先决活动。 执行从步骤802转到步骤804继续执行。
步骤804-808所示流程示例了主要SLA提供方用户获得与各个SLA客户订购单无 关联的SLA提供细节记录的使用权，并且为所需关联选择特定的记录。SLA提供细节 记录为了特定的没有财务系统支付授权记录的SLA客户而标识。在所述流程中，用户 能够使用数据库过滤，比如，SLA客户名称，日期，主要SLA客户端用户来控制记录 组的输出。系统100提示主要SLA提供方用户建立一个财务交易流程机制。在步骤804 中，系统100提示主要SLA提供方用户把提供细节记录和订购单联系起来。在步骤806， 用户在订购单报告中使用一个未关联的提供细节。在步骤808中，用户通过GUI选择 限制的提供细节记录。
在步骤810中，用户激活创建SLA客户订购单控制。在步骤812中，系统100在 未决状态下生成一个新的订购单。在步骤814，订购单从SLA提供细节记录中列出继 承细节。步骤810-814并不表示只有新的订购单可以在流程800中被创建。尽管没有清 晰描述，一个存在的SLA客户订购单记录能够被列出和选择，比如在SLA客户喜欢的 模式需要使用主总括订购单的情况下就是如此。为了不使步骤810-814中描述流程的突 出特征难以理解，流程通过创建一个新的订购单记录来表示。步骤810-814描述的流程 中，某种配置后的SLA提供细节记录元素通常自动填充订购单行。在相同的情况下，某 种SLA合同细节，根据配置，来填充订购单页眉。
步骤816-826表示了主要SLA提供方用户完成传统的应用于订购单的财务信息的 流程。所描述的示例信息元素包括订购单最大支出，服务工作率以及材料率。在步骤 816中，系统100提示用户指定订购单最大支出额。在步骤818中，用户指定最大支出 额并且保存输入。在步骤820中，系统100提示用户指定服务劳动支付率。在步骤822 中，用户指定服务劳动支付率并且保存输入。在步骤824中，系统100提示用户指定材 料支付率。在步骤826中，用户指定材料支付率并且保存输入。
步骤828-830是存储订购单的基础步骤。在流程800的这个阶段，订购单还不是动 态的。在步骤828中，系统100提示用户存储完成的订购单。在步骤830中，用户存储 完成的订购单。
步骤832-840表示了SLA客户订购单处理和确认流程。在步骤832中，系统100 发送完成的订购单给配置好的触发SLA客户端用户，例如，通过联系到步骤830中记 录的状态代码。签署通知，例如通过电子邮件和系统操作板更新。在步骤834中，SLA 客户端用户通过GUI访问未决的订购单。在步骤836中，SLA客户端用户确认订购单 数据。在步骤838中，系统100指示SLA客户确认订购单并且为SLA客户分配订购单 号码。在步骤840中，SLA客户端用户确认订购单并且为SLA客户分配订购单号码。 步骤836-840没有明确描述假定用户在没有确认订购单数据的情况下。然而，系统100 在需要纠错或者对数据元素有争议的情况下提供了往复功能。在并发的数据处理活动过 程中，促进和保证正确数据的系统100中包含有协作验证和确认过程。
步骤842-848表示了在系统100中主要SLA提供方用户完成SLA客户订购单流程 和使订购单被激活采取的活动。在步骤842中，系统100发回确认的SLA客户订购单 给主要SLA提供方。通知被签署，例如通过电子邮件和系统操作板更新。在步骤844 中，主要SLA提供方用户通过GUI访问被认可的订购单。在步骤846中，系统100提 示主要SLA提供方用户激活订购单。在步骤848中，主要SLA提供方用户激活订购单。
所述的支持数据库模式的主数据在图9中表示。本领域的技术人员了解，该支持模 式和应用模块基本上是作为操作SLA服务提供的框架。完整的数据模式总结了在描述 业务信息内在关系时采用优化的方式操纵业务所需要的主要和基础的业务信息方面。就 像之前提到的，这些内在联系的业务信息方面已经按照惯例存在于通常之间不互相通信 的全异数据处理系统中。因为这个应用模块和支持数据库计划，主要SLA提供方现在 能够在一个数据处理系统中定义和存储它们的SLA提供需求，所采用的方式真正反映 了必须考虑的其业务动态，例如：合同，和员工的联系，实体位置，需要的提供工作特 征，逻辑参数，非执行处罚以及财务处理授权。
采购功能处理由主要SLA提供方和二级SLA提供方承担的资源，报价和订购单生 成活动。这些活动通常需要：1)使主要SLA提供方获取和存储适用于二级SLA提供 方的业务信息；2)使主要SLA提供方按照SLA技术提供和物理覆盖能力对二级SLA 提供方进行划分；3)使主要SLA提供方系统地把SLA客户服务覆盖需求识别和量化 为主数据功能中的详细信息；4)使主要SLA提供方从SLA客户服务覆盖记录中生成 系统的RFx报价；5)使主要SLA提供方系统地生成二级SLA提供方报价列表，为已 创建的RFx报价要向报价响应流程公布；6)使二级SLA提供方系统地生成RFx报价 响应并且根据需要提交可用和所述响应有关的人力资源；7)使主要SLA提供方系统地 检查被提交的RFx报价响应；以及8)使主要SLA提供方系统地接受/授予RFx报价响 应并且参照RFx报价响应细节创建二级SLA提供方订购单。表格37-52以及图10-13 是特别关于这些活动的。上述描述的关于主数据功能的逻辑系统方法论使一个主要SLA 提供方定义其潜在的SLA提供服务，定义的方面是根据互相无关联的员工提供技能要 求、材料/部件能力、实体位置/地理作为二级SLA提供方被分类和提供资源的基础信息 平台。
图10是二级SLA提供方系统启动的流程实例图。在图10中，流程1000包括步骤 1005-1080。步骤1005-1025表示了获取被确认的二级SLA提供方和进入系统100的基 础步骤。流程1000开始于步骤1005，在该步骤中，主要SLA提供方配置业务信息域 和关于二级SLA提供方的任何可用的使其具有资格的参数数据。在步骤1010，为二级 SLA提供方赋予资格的基础业务信息配置完成之后，潜在的二级SLA提供方从主要 SLA提供方处得到临时系统访问证书。所述证书能够通过以下多个模式传递，比如， 电话，加密信息等。
所述证书使二级SLA提供方用户可以使用系统100。通过一个展示给二级SLA提 供方用户的和图3所示类似的GUI，通过该基础导航技术被用于访问主要SLA提供方 的信息输入表格。在步骤1015，二级SLA提供方完成常规授权业务信息的输入以及提 交相同的信息给主要SLA提供方进行检查。
步骤1020-1025描述了主要SLA提供方检查和部署由二级SLA提供方提交的合格 的信息。这个工作流被示例为仅仅和正确的结果有关，通过所述正确的结果二级SLA 提供方被授权/确认操纵业务。在步骤1020中，如果二级SLA提供方被认为已经被主 要SLA提供方确认合格，则主要SLA提供方对二级SLA提供方进行确认。在步骤1025， 二级SLA提供方被通知确认和特定常规的系统登录证书，并且被指示完成提供概要矩 阵。在步骤1005-1025中，主要SLA提供方配置他们希望可见并且可以识别系统100 之前定义的作为授权参数所需数值的信息功能。示例性基础业务信息元素包含在表格 40-41中。主要SLA提供方事实上对于他们希望在系统100中产生功能的授权参数没有 配置限制。
步骤1030-1055示例了二级SLA提供方在活动和地理域内容中记录他们服务提供 能力的基础步骤。二级SLA提供方通过被提供的GUI来访问一个业务概要工具。所述 业务概要工具提示用户导航一个部门-平台-类别的分等级可关联钻取工具。在步骤 1030，二级SLA提供方的一个用户访问提供概要功能。在步骤1035，按照之前配置的 规则，二级SLA提供方查看提供商业类别或者被限定的所述主要SLA提供方子集的完 整列表。使用该工具，二级SLA提供方能够指定哪个特定功能/专业技术领域代表了他 们的核心竞争力。在步骤1040，二级SLA提供方选择可用于二级SLA提供方资源供应 能力的商业类别记录。
基于商业类别的选择，二级SLA提供方可能使用地理描述工具(比如国家-地区- 县-城市)和被选择的商业类别相关的地域覆盖区域。在步骤1050，二级SLA提供方使 用地理关联数据库用户接口指定服务区域。国家、地区，县或者人口集中覆盖区都有分 别的描述。在典型的实施例中，用户接口支持把商业类别在地理区域映射中聚集或者区 分。通过存储需要的选择，例如，在表格42-46中，二级SLA提供方可能提交选项给 主要SLA提供方以进行检查和部署。在步骤1055，二级SLA提供方保存和提交商业类 别给地理区域覆盖矩阵。
如果需要的话，主要SLA提供方能够限制二级SLA提供方的服务提供矩阵描述于 那些只有在主数据功能中定义的提供技术概要和地理描述。为了实例的目的，没有对这 些限制进行细节描述；本领域的相关技术人员了解，使用这些限制通常可以使二级SLA 提供方的随行过程更加容易，但是通常不会被认为是最佳的实施操作模式，假设二级 SLA提供方提供能力的巨大数据检查在考虑改变业务需求时被优化。
步骤1060-1080描述了流程1000的完成。如上所述，只有二级SLA提供方提交的 正确部署被细节描述。流程1000的网络结果是二级SLA提供方到商业类型和地理领域 覆盖区域的映射。在步骤1060，主要SLA提供方检查已提交的二级SLA提供方创建的 商业类型到地理领域覆盖矩阵。在步骤1065，主要SLA提供方对商业类型到地理领域 覆盖矩阵进行确认。在步骤1070，二级SLA提供方的商业信息到地理领域覆盖矩阵状 态被修改为已确认和动态的。在步骤1075，二级SLA提供方被通知提交确认和矩阵状 态变化，例如，通过网络和电子邮件通知。在步骤1080，使二级SLA提供方可以接收 已提供商业类型和地理区域证书为前提的系统RFx报价。
在流程1000结束时，主要SLA提供方已经获取并且存储了关于潜在SLA客户提 供需要和潜在二级SLA提供方服务覆盖能力的信息。全部流程200中的下一个步骤是 关于RFx报价需求识别、RFx报价生成和RFx报价请求。
图11是一个关于至少与一个二级SLA提供方订购单无关的SLA提供细节记录的 详细输出报告的例子。为主要SLA提供方输出的系统报告1100详细记录了与动态RFx 报价或者动态二级SLA提供方订购单无关的所有动态SLA客户提供细节记录。
所采用的策略是用来记录潜在SLA客户需求在形式化的数据库方法论中说明每个 和全部的需求，把每个和全部需求关联到一个特定的记录，映射每个记录到SLA提供 技术概要以及指派地理覆盖点与需求进行关联。所述方法论的一个结果是输出报告 1100，所述的输出报告为创建RFx报价设置阶段，所述RFx报价为了接收报价单而被 签署给二级SLA提供方。
控制1115，1120和1125表示了对主要SLA提供方用户的可变检查控制，使用户 可以在更宽的地理段对记录设置进行分组和检查。控制1115，1120和1125是典型的方 便方法和业务实施参考。
控制1105使用户可以洞察SLA工作描述的细节。这个路径可以提供加强的可视程 度。如果这个域没有被主要SLA提供方使用，则连接没有被激活或者备份，从而防止 了用户得知细节。
控制1110使用户可以洞察可用的SLA提供技术概要细节。所述路径可以提供加强 的可视程度。而且，如果这个域没有被主要SLA提供方使用，则连接没有被激活或者 备份，从而阻止了用户获知细节。
控制1101，1130和1135分别是用来选择特定记录或者记录组的主要控制，目的是 为了把新的RFx报价包含进来以及指明如果被选定的记录(组)是否被组合为一个单 独的RFx报价或者如果每个选定的记录是否和一个单独的RFx报价进行关联。控制 1135直到至少两个记录被选定才会被激活。
通过控制1101和指定多个或单个RFx包含参考(控制1130或者控制1135)来选 择需要的记录之后，用户则激活一个创建RFx控制(控制1140)来开始该RFx开发流 程。业务目标不会让任何记录出现在无关联SLA提供细节记录报告中，因为这会意味 着没有为可用的SLA客户提供外包或者子合同提供服务覆盖。
图12A-B是示例可用于采购外包二级SLA服务提供的高级流程的流程图。现在参 考图12A，流程1200用于示例RFx报价开发和二级SLA提供方RFx报价选择和请求。 流程1200开始于步骤1202。在步骤1202中，主要SLA提供方运行一个系统提供的和 SLA客户无关联的提供细节报告。在步骤1204，系统100为主要SLA提供方用户提供 一个从选定的报告记录中产生RFx报价的功能。在步骤1206中，系统100按照步骤1204 的配置创建RFx报价记录。在系统1208中，为主要SLA提供方用户开始一个RFx报 价创建会话。本领域的相关技术人员显然会了解，步骤1208的启动可能独立于GUI菜 单控制，这意味着主要SLA提供方用户不是必须被要求通过运行之前在步骤1202-1206 中描述的报告输出来创建RFx报价。在这样的情况下，系统100可以向用户显示所有 的已经被认定RFx包含但是因为某些原因没有完成的记录。然而，为了示意的目的， 流程1200描述一个流程，使与图11的输出报告例子相关的用户行为来直接运行RFx 创建报价会话。
如示例所示，主要SLA提供方用户在步骤1208开始RFx报价会话创建，并且和 可用的记录设置一起表现。在步骤1210，用户选择特定的需要的关于提供细节记录的 RFx报价。多个提供细节记录能够集合到一个RFx报价中。
在步骤1212，可用于提供细节记录的提前配置好的数据库元素被使用于填充RFx 报价的元素。RFx报价中包含有来自SLA提供记录设定的信息细节，包括，例如，SLA 提供技术概要，服务地点细节，SLA提供需求以及参与的服务频率。步骤1212通常与 表现出的GUI形式无差别，使用户可以通过标准的导航技术访问各个记录。对于本领 域相关技术人员公知，提供给用户的管理减轻了该流程，同时还了解数据输入错误在实 际上被消除。用于物理提供服务和物流的相关细节被直接从SLA提供细节记录中获取， 该记录直接和SLA客户合同记录链接在一起。
一旦核心记录设置是基于RFx建立的，主要SLA提供方用户就可以访问步骤1215 进行编辑/配置。在步骤1215中，主要SLA提供方用户配置，例如，劳动类型选项， SLA处罚条款和最大比率。
尽管用户可能选择不采取行动，但是用户可能被提供选项来使得业务工作可以被加 强。比如支付劳动类型，最大支付率，SLA处罚条款和服务提供响应次数等数据元素 能够被配置，例如，来保证收益性和服务提供质量目标能够在报价的过程中被建立。一 个例子是支付率。从主要SLA提供方的角度来说，最佳的是二级SLA提供方的支付率 等于或者小于可适用的SLA客户最终的所支付的支付率。另外一个例子是服务提供响 应次数。再一次，从性能的角度来说，最佳的是如果服务提供响应次数被配置为一个比 主要SLA提供方可用的合同时间帧更短的时间帧。可编辑的用户接口使主要SLA提供 方可以在系统架构中保护自己的利益。
步骤1218是步骤1215中的配置完成后的保存流程。决定支持特征可以在该步骤中 被设计到系统100中，该步骤检查和确认任何可能为主要SLA提供方造成潜在问题的 用户配置。例如收益性或者质量保证分析等确认可能被用于提示用户可能造成业务工作 风险增加的用于特定报价条目的参数。
在这个方面，需要发送RFx报价给二级SLA提供方的主要细节已经完成；然而， 各种管理细节还有待完成。通常，一个RFx报价会需要特定的元素，例如，报价页眉 部分，报价细节部分以及报价回应部分。RFx报价通常伴随有定义好的一组提供方协议， 该协议在报价响应流程中执行。另外，RFx报价的性质是那么多关于大部分已签署的报 价的信息是多余的并且在格式上是标准的以及在内容上涉及到业务公司。所以，报价模 板工具被用于管理关于RFx报价内容和格式的条目。
关于RFx报价模板，特定的数据库表存储有默认的RFx报价信息元素，例如，问 题和陈述。主要SLA提供方能够配置用于默认RFx报价信息元素的标准默认内容。因 此，该信息元素可能提前被定义和要求不被用户编辑。而且，系统100可能存储特定的 可配置信息元素，这就意味着用户可能创建报价条目，分配这个条目为一个陈述，问题 等等，以及如果信息元素需要一个提供方响应则进一步分配，并且如果所述响应被限制 到一个特定的数据类型中，例如，数字，文本，日期或者货币则进行分配。
在各种实施例中，服务提供架构包括RFx报价条目。RFx报价条目的结合能够被 设为逻辑默认RFx报价种类和部分。每个报价条目能够被指定到一个逻辑组或者种类 以及每个种类的一列能够被逻辑地组合为一个部分。所以，RFx报价内容是可以被分组 的。
上述的报价内容分组是一个更复杂的RFx报价模板层，它可以使主要SLA提供方 建立各个部分的UI显示指令、各个部分中的分类以及各分类中的RFx报价条目。所以， 各种RFx报价条目可能被创建并存储在结构化的内容和布局格式中。因此RFx报价模 板表示了业务内容控制机制，当该机制与提供细节RFx数据结合时，则为快速和详细 的RFx报价生成形成基础。
所述RFx报价模板存储在系统100中，在步骤1220，主要SLA提供方用户被提示 选择一个他们选择的之前配置好的RFx报价模板。主要SLA提供方用户被提示把RFx 报价设置和之前定义的内容报价模板结合起来，该模板定义了剩余的未提供的详细RFx 报价数据域。所述报价模板数据域能够被默认完成或者要求特定用户的输入。系统100 可能提供给用户选项(如果公司配置了的话)来使用户根据他们的具体需要使特定的报 价条目有效或者失效。例如，用户可以和已经建立的著名提供方基础进行交易。在这样 的例子中，用户可以选择关于二级SLA提供方特定信息要求的某种报价条目无效，例 如关于历史和质量保证的询问。相反的，主要SLA提供方也具有权利通过配置来锁定 特定报价条目，使其在RFx报价开发流程中不能被用户设置失效。
通过选择适当的RFx报价条目，用户在可适用的部分输入需要的信息来适应于步 骤1222正在处理的具体RFx报价。关于该输入的简单的例子是主要SLA提供方描述 的报价管理人员以及必须的报价响应到期日。通过完成必须的输入，用户在步骤1224 保存修改的数据。尽管流程1200中没有描述，但是用户可以具有编辑的能力。所述系 统100可以使用状态代码管理技术进行临时存储，使数据处理可以在其它时间进行或被 其它用户使用。
一旦所有的关于RFx报价的信息完成，RFx报价请求列表在1226-1232被建立。 步骤1226成为可以在完成后被主要SLA提供方使用并且存储必须的报价条目输入。在 这一点上，系统100提供了一个之前未激活的提交RFx报价控制。该控制在步骤1228 被激活，在步骤1230用户被提供所有与被授权的RFx报价有关的确认的二级SLA提 供方的显示列表，例如提供业务类别和领域覆盖。系统联系通常是一个按照之前步骤 1070描述建立的提供技术业务类别和地理参数的数据库映射。
在步骤1232中，主要SLA提供方用户选择所有的或者包含在潜在RFx报价请求 列表中的二级SLA提供方的子集。通常有一些决定支持工具帮助用户完成选择流程， 该流程提供给用户关于二级SLA提供方相关的有用信息，例如，可跟踪的质量保证， 价格以及SLA提供处罚机制。
通过用户在步骤1234选择和存储必须的二级SLA提供方，系统100提示用户提交 RFx报价给那些被选定的二级SLA提供方。在步骤1236，用户激活提交的RFx报价控 制，这会使RFx报价在步骤1238中被发布，并且通知给二级SLA提供方，例如通过 电子邮件和步骤1240中的操作板的更新。用户建立的提交列表被存储在比如表格47 中。会被用于RFx报价流程的主要SLA提供细节记录信息被存储在例如表格37-39中。
现在参考图12B，在步骤1244中，二级SLA提供方访问RFx报价并且执行任意的 被模板定义的报价流程协议。步骤1244通常通过应用GUI实现。供应方协议的执行， 例如，但不仅限于，有之前公开的保密协议(NDA)和知识产权(IP)协议；所以， 特定的控制能够由二级SLA提供方用户访问，通过此访问所述的协议可以在线或者离 线执行。为了流程1200的需要，之前的假定是二级SLA提供方会确实执行任何的被主 要SLA提供方建立的配置后的协议。
在步骤1246中，二级SLA提供方提供输入给所有的需要响应的应用RFx报价功 能。系统100通常使用一个简单的报价条目响应计数器，该计数器直到所有必须的报价 响应元素被完成后才允许提交报价响应。而且，按照通常配置的系统100允许数据确认 功能，在这个功能中报价响应条目能够仅在如之前描述的正确的数据对象和格式中被完 成。RFx报价响应细节被存储在例如表格48-49和90-91中。
在步骤1248中，二级SLA提供方创建用于SLA提供工作概要的人力资源提交报 告。尽管步骤1248通常在步骤1246中作为支流程发生，SLA资源提交流程为了清楚 表示的目的被突出为独立的流程步骤。在步骤1248中，二级SLA提供方通常使用被提 供的GUI来获知任意可用的包含在RFx报价中的SLA资源概要，以及创建关于SLA 资源概要的资源提交。提交信息被包含在例如表格50中。系统100能够适用于容纳常 规的二级SLA提供方工作资源库，该资源库将会被用于一个关联模式，通过该模式资 源以宏模式被映射到SLA提供技术概要，而不是这里描述过的微模式(之前描述的单 个的RFx)。这种模式可能在特定的主要SLA提供方没有兴趣操作竞争性的RFx报价 并且乐于使用主协议和二级SLA提供方一同工作的情况下有帮助。
在另外一种模式中，资源的提交发生在RFx报价响应流程之后，而不是在RFx报 价响应中。当RFx报价被请求覆盖未来几个月的提供服务时也许是这样的情况。在这 样的情况下，在实际的报价流程中的特定劳动资源的提交也许是无关的。本领域的相关 技术人员认同，所描述的示例性流程不是把二级SLA提供方资源关联到SLA客户需求 的唯一模式。
在步骤1250中，二级SLA提供方保存信息设置并且提交报价响应给主要SLA提 供方。步骤1250表示了必须报价响应信息的完成，因此使得二级SLA提供方可以提交 他们完成的RFx报价响应。步骤1250导致的是在步骤1252中的记录更新和触发系统 应用通知给任意的提前配置过的用户。
步骤1254-1258表示了主要SLA提供方报价响应部署流程。在步骤1254中，主要 SLA提供方检查从二级SLA提供方发来的报价响应。在步骤1256，主要SLA提供方 接受被要求的报价响应。在步骤1258，二级SLA提供方，通过例如系统更新和电子邮 件被通知报价反馈。
假定至少一个二级SLA提供方报价响应应获得报价反馈，主要SLA提供方指定至 少一个报价响应记录的反馈。主要SLA提供方能够反馈多个报价响应，并且为所有或 部分的报价提供细节响应条目签署反馈。例如，二级SLA提供方可能被指定可用于某 一个报价而不是其它的一个服务覆盖区域。在另一个例子中，二级SLA提供方可能被 指定一个特定的而不是其它的SLA提供覆盖时间。在这样的例子中，比如，如果报价 响应指示出一个过高的价格，则工作时间外和周末的提供报价会启动。报价响应的回应 部署可以是多样的和灵活的，使得主要SLA提供方在该流程中采用最好的实用采购实 践。
步骤1260-1270描述了主要SLA提供方从反馈的二级SLA提供方报价响应中创建 订购的要求。在步骤1260中，主要SLA提供方被提示创建二级SLA提供方订购要求。 在步骤1262中，主要SLA提供方激活一个创建的订购单要求控制。在步骤1264中， 系统100使用内在的报价响应数据创建订购要求。在步骤1266中，系统100提供一个 所有已经接收到用于RFx报价订购单回馈的二级SLA提供方显示列表。在步骤1268 中，主要SLA提供方为准确性检查创建的订购要求，在需要的情况下进行修改。在步 骤1270中，主要SLA提供方保存订购要求并且提交相同的要求给二级SLA提供方进 行检查/确认。
和非关联的SLA提供详细报告类似，系统100使用数据库驱动的状态代码，它能 够提供把报告输出所有需要处理进订购单的报价响应给主要SLA提供方。示例的流程 是一个线形的，从反馈跳转到为了简单化和便于描述为目的的订购要求处理的流程。在 一些实施例中，该流程可能与发生在不同时间和可能不同的人员操作的流程无关。
所述订购需求流程模块被激活并且如果示例流程在独立的模式下被执行，主要SLA 提供方用户被提供一个所有等待处理的未决报价响应回馈显示列表。该流程示例了一个 如所述的线形模式，所以用户可以不需要选择未决反馈的报价响应。因为该流程假设要 求流程从特殊的RFx报价记录设置发出，系统100根据要被包含在继承自反馈报价响 应记录的要求中的信息来创建该订购要求。订购要求，根据默认的模式，每个二级SLA 提供方被创建一个，而且可能包含多个需要的排列项。如果可用的RFx报价反馈被关 联到多个SLA提供细节记录时，这种情况有可能发生。
一旦订购要求被创建，系统100使主要SLA提供方，例如，检查或者增加注释。 一旦对包含在订购要求中的信息满意，主要SLA提供方用户保存并且确认订购要求。 这个动作触发状态代码在系统100中更新，和保证给适用于二级SLA提供方基于系统 的通知。
步骤1272-1278表示了二级SLA提供方处理主要SLA提供方创建的订购要求。系 统100支持不同的二级SLA提供方确认工作流程。这里没有详细描述的是流程中可能 遇到的适用于数据或信息不一致的一种工作流程。
在步骤1272-1278中，二级SLA提供方检查，确认并且预提交给主要SLA提供方 已经完成的订购要求。在步骤1272中，二级SLA提供方被通知未决的订购要求。在步 骤1274中，二级SLA提供方检查订购要求细节并且确认订购要求。在步骤1276中， 系统100提交认可的订购要求给主要SLA提供方。在步骤1278中，主要SLA提供方 被通知确认的订购。
在步骤1280中，主要SLA提供方访问被确认的订购要求。在步骤1282中，主要 SLA提供方激活一个创建的订购单控制。在步骤1284中，系统100创建订购单。在步 骤1286中，主要SLA提供方定义一个内部订购单号码并且确认该订购单。在步骤1288 中，二级SLA提供方被通知确认的订购单。在步骤1290中，使订购单可用于二级SLA 提供方。为了示例性的目的，一个简单的数据库表结构被示例，它使用相同的表格51 和52以存储订购要求和订购单数据。
图13是支持采购功能的数据库计划。一个数据库计划1300表示了支持在最近的局 部部署中描述的数据处理功能的高级示例性数据库计划。本领域的相关技术人会员认 同，无缝的信息线程继续贯穿展开的下流数据处理会话，导致采购模块业务信息连通回 到主数据功能。在不同的实施例中，一个内在信息设计减少了用户的输入，降低了数据 登录错误，并且提供了优化的审计能力。
下一个步骤是人力资源服务提供管理功能的整体方法论，它包括：1)使主要SLA 提供方检查和确认提交的RFx报价响应候选的部署；2)使系统的主要SLA提供方将 关于已提交的RFx报价响应候选的部署/状态通知发给二级SLA提供方；3)使主要SLA 提供方基于确认/接受已提交的RFx报价响应候选而创建SLA的提供资源记录；4)使 二级SLA提供方人力资源系统可以被访问；5)使系统协议被二级SLA提供方人力资 源执行；6)使二级SLA提供方和被确认的人力资源进行工作可用日程管理/配置；7) 使主要SLA提供方的逻辑时间覆盖可以被评估；以及8)使主要SLA提供方前摄的人 力资源具有中断期调解功能。中断期是指特定人力资源或者一组资源不可获得的服务提 供时期。
通常，SLA提供外包被执行的模式是指在特定的行政管理的特殊性，其中主要SLA 提供方和二级SLA提供方的业务实体管理或者销售人员在SLA提供劳动资源层所进行 的最小或者不真实的业务分析来达成协议。这并不表示所有应当由二级SLA提供方进 行的努力或者历史性工作评估可以被忽略，但是关于业务管理在哪个层的事件通常状况 被执行。最终，客户SLA提供的质量/成功是SLA提供劳动质量，能力，以及与充分 的物流管理和通信相关的可用性的结果。
图14A-B是表示可用于人力资源服务提供管理流程的示例高级流程图。在图14A 中，流程1400开始于步骤1402。步骤1402-1406示例了主要SLA提供方被系统地通知 所有存在的至少和一个SLA提供资源分配记录无关的二级SLA提供方订购单的流程。 在步骤1402中，主要SLA提供方用户访问人力资源工作管理模块。在步骤1404中， 主要SLA提供方导航菜单驱动的GUI来选择未分配的二级SLA提供方订购单。在步 骤1406，系统100提供一个按照二级SLA提供方和订购单分组的显示列表报告。尽管 没有详细描述，在劳动分配关联已经存在的情况下，将可以进行对记录管理的访问。在 必要的人员变动的情况下，记录的修改在逻辑上可以表示这样的功能。
步骤1408-1416表示了主要SLA提供方用户对必需的SLA提供工作资源的选择， 该流程描述了二级SLA提供方之前在RFx报价流程中提交的资源记录的一种模式。该 流程可以变化，尽管没有详细说明，功能性是可以使二级SLA提供方在检查流程中的 任何进行检查以传送资源记录。在提交的资源记录不满意或者因为种种原因不再用于分 配时，上述情况就会发生。在步骤1408中，用户选择可用的二级SLA提供方记录并且 激活一个管理人力资源控制。在步骤1410，系统100提供给用户一个所有二级SLA提 供方可用于相关资源RFx报价响应的资源提交列表。在步骤1412中，系统100提供一 个用于用户连接资源提供细节的控制。在步骤1414中，用户通过GUI选择提供SLA 覆盖必需的特定人力资源。在步骤1416中，用户保存确认的资源记录设置并且系统100 发送相同的通知给二级SLA提供方。
这个流程使主要SLA提供方用户检查提交内容的细节，并且相应的做出选择。尽 管其它很多可能的特征没有在这里描述，本领域的相关技术人员认同，检查和选择流程 将导致主要SLA提供方对最终会代表他们提供服务的资源进行控制。表格53包含了关 于劳动资源系统驱动的细节，同时分配细节包含在表格54中。
通过选择需要的资源，系统100在步骤1418-1424执行一个相反的肯定流程，通过 这个流程二级SLA提供方能够确认资源可用性以及他们对联合资源和可用提供分配的 持续需要。在步骤1418中，系统100为未决状态的确认资源创建人员资本工作的分配 记录。在步骤1420中，二级SLA提供方通过GUI确认资源分配确认。在步骤1422中， 主要SLA提供方被通知分配认可，例如通过系统通知。在步骤1424中，二级SLA提 供方被提供可用资源的系统访问证书。
步骤1426-1430表示了SLA提供工作资源的管理系统启用。各种保护的工作资源 协议能够被主要SLA提供方通过例如NDA，IP保护和临时工作协议确认的系统访问来 进行配置。该流程描述了劳动资源的正面行为。其他劳动资源协议中可能发生的结果没 有通过即使的模式，或者甚至在争论之外执行。在步骤1426中，二级SLA提供方资源 通过提供证书访问系统100。在步骤1428中，二级SLA提供方资源执行配置的在线协 议。在步骤1430中，系统通知发送给主要和二级SLA提供方。
假设一切劳动资源协议运行正常，下一步流程需要在步骤1430-1442中配置劳动资 源可用日程表。在步骤1432中，二级SLA提供方被提示访问和配置人力资源日程。在 步骤1434中，二级SLA提供方访问人力资源日程模块。在步骤1436中，二级SLA提 供方访问特定的人力资源记录。在步骤1438中，二级SLA提供方提供标准的人力资源 中断期和通常的可用期。在步骤1440中，二级SLA提供方为和各个二级SLA提供方 相关联的所有的可适用的分配好的人力资源重复步骤1434-1438。在步骤1442中，通 过完成所有的资源日程配置后，二级SLA提供方提交定购单分配日程配置给主要SLA 提供方。
在流程1400的这个阶段，需要的劳动资源已经被指派给各个SLA提供服务行为。 流程1400包括有经验或者有效的物流方法，通过该方法劳动资源覆盖时段能够被输入 到系统100中，并且被分析用来作为计划支持。在一个更高的层面，在不同实施例的人 力资源服务提供管理中，二级SLA提供方被提示输入分配的SLA提供工作资源的基本 时间表。基本的配置通常包括制定标准的休息时段例如周末或晚上或者特定的休假或假 期。劳动资源不应该每天24小时处于待命状态；相反的，二级SLA提供方很可能提供 24小时服务覆盖。
通常，RFX报价包括关于协议的覆盖时间帧信息；从另一方面来讲，在大多数情 况下，完整的工作时段通常包括多个工作资源和时常的多个二级SLA提供方的使用。 因此，在下一个流程中，由步骤1445-1456示例，主要SLA提供方定义任意潜在服务 提供间隙。在理想的情况下，主要SLA提供方建立：1)每个二级SLA提供方的完整 的物流时间；2)多个二级SLA提供方完整的总和时间。系统100使主要SLA提供方 通过输入/上载劳动资源日程可用行数据和对数据地分析静态地确认上述假定。这个静 态地确认是步骤1445-1456的核心。
从步骤1442，执行继续进行到图14B中的步骤1445。在步骤1445中，主要SLA 提供方用户访问人力资源劳动协议模块中的订购单资源分配列表。在步骤1448中，主 要SLA提供方用户激活和评估服务时间控制。在步骤1450中，系统100为主要SLA 提供方提供一个识别所有潜在非服务时间或中断时间的报告。在步骤1452中，系统100 提供给主要SLA提供方用户选项来评估所有二级SLA提供方为特定的SLA客户提供 细节记录的可适用时间的总和时间。在步骤1454中，主要SLA提供方用户运行综合时 间评估报告。在步骤1456中，系统100提供给主要SLA提供方一个识别任意潜在综合 非服务时间或中断时间的报告。
因为系统100在逻辑分段的数据库个体中量化时间，提供一个SLA劳动资源工作 时段报告是很简单的。工作时段分析能够在单独的或者整体二级SLA提供方层被执行。 因此，单独的二级SLA提供方工作时段分析能够被检查或者多个二级SLA提供方资源 时段，和单个的SLA客户提供细节记录关联起来能够被集体浏览。主要SLA提供方被 提供需要的数据来定义工作时段是否是充足的。而且，所有的特定二级SLA提供方能 够被识别，这些二级SLA提供方的数据输入和RFx报价流程中引用的覆盖时段不一直 或者主要SLA提供方描述的覆盖范围太有限制性。在其他的实施例中，更有经验的数 据库管理系统能够被使用，用来锁定RFx报价响应覆盖时段以及强制可用的二级SLA 提供方相应地完成资源工作日程记录。
步骤1458-1466是关于提供给主要SLA提供方用户的接口，通过这个接口单个的 二级SLA提供方中断覆盖时段能够被选择并且连同主要SLA提供方期望的时间表修改 建议一同转发给适当的二级SLA提供方。正确的结果包括存在的日程记录覆盖修改或 者附加的用于填充潜在服务间隙的附加劳动资源的提交。在新的提交中，上述提交浏览 流程被实施。分析和发现并修理故障的过程也许被创始许多次，当主要SLA提供方视 为必要确保充分SLA供应覆盖面。
参考图14B，在步骤1458中，系统100提供给主要SLA提供方选项来签署覆盖修 改请求给二级SLA提供方来选择。在步骤1460，主要SLA提供方用户选择适用的二级 SLA提供方。在步骤1462，主要SLA提供方用户选择特定的中断时段，该时段在每个 已识别的二级SLA提供方需要查看时可以识别。在步骤1464中，存在的分配好的人力 资源的日程更改来减小中断服务时间或者附加的人力资源提交能够用来支持覆盖范围， 或者附加的二级SLA提供方能够通过RFx报价被请求。在步骤1466中，不考虑和必 要的中断时间有关的修改，各个二级SLA提供方管理他们自己的人力资源时间表，使 得资源可用被实时使用。用来和人力资源日程表功能相关联的数据库被存储在附表中， 例如表格58-63。实际的适用于单个劳动资源的日程表数据细节被存储在附表中，例如 表格55-57。
图15是人力资源日程配置的流程图。建立在流程1500中的三个主要配置模式是： 1)标准工作时间表模式；2)非标准工作时间表模式；以及3)日常行为模式。标准工 作时间表是标准预期时间表。在这种模式中，二级SLA提供方为特定的与订购单分配 相关的劳动资源建立基础时间表。这种模式的输入建立标准的工作日和工人可用的标准 小时。
参考图15。流程1500开始于步骤1502，在这个步骤中二级SLA提供方用户访问 人力资源劳动管理模块。在步骤1505中，二级SLA提供方用户操纵菜单驱动GUI来 选择被标记的人力资源记录。在步骤1508中，系统100提供所有分配的人力资源报告 的列表显示报告。在步骤1510中，用户选择必须的人力资源记录。在步骤1512中，系 统100提供相关细节的列表显示报告和适用的日程表的链接。在步骤1515中，用户激 活日程表控制。在步骤1518中，系统100提供的选项菜单可能包括：1)配置标准时间 表；2)配置其它中断服务时间表；3)维护日常行为。在步骤1520中，用户激活配置 标准时间表控制。在步骤1522中，用户被提示浏览周日程表，比如一周的所有七天。 在步骤1525中，用户提供输入并且保存输入。在步骤1528中，用户激活配置其它中断 服务时间表控制。
在通常的实施例中，用户仅需要激活中断无线电发射按钮用来代表标准休息日的所 有节日并保存设置。尽管这个标准配置如果需要的话能够被修改到分钟。每半小时增加 了休息时间的非中断日也向用户显示出来。每个增加的休息时间通过两个控制完成：1) 开始；以及2)结束。用户通过建立开始时间和结束时间为每天进行配置。通过总结， 用户可以保存设置，标准的日程设置被保存在用于可用的SLA提供资源的数据库中。 非标准工作时间表输入需要其它预定的中断期间的指定。这种类型的预定中断期间的一 个例子是休假时间或者标准公司假期。这些时期在道理上可变的，所以非标准的。
在步骤1530中，系统100提示用户：1)定义劳动认可假期；以及2)定义预定的 休假日。在步骤1532中，用户进行输入并且原样保存。用户被提示配置预定的假期和 休假/个人休息日。用户激活控制并且被显示，例如分段为不同的12个月的每年日程浏 览。用户选择可用的月份，之后开始浏览被分段为日的月份。然后用户选择可用的日子 并且保存输入。用户被提示指定选项作为假期或者个人休假。用户保存输入继续操作， 直到配置完成。
在步骤1535中，系统100提供给用户服务提供资源日程动态的通知。在步骤1538 中，系统100通知主要SLA提供方和二级SLA提供方人力资源用户服务提供资源日程 是动态的。在步骤1540中，二级SLA提供方用户激活维护日常行为控制。在步骤1542， 做出决定是否特定的资源具有已经被计划的服务提供编号。如果对步骤1542中决定的 答复是肯定的，则继续执行到步骤1545。
日常行为时间安排表示了可用于各个劳动资源的正在进行/持续的日程可用性输 入。外包劳动使用的特性意味着通常没有劳动人员在等待一个特殊的客户来提出问题。 所以通常特定的劳动资源被用于提供资源给多个SLA客户和多个主要SLA提供方。日 程模式使得当前资源劳动跟踪机制可以使用，通过这种机制特定的中断服务时段能够在 系统100中被管理用来提供实时可用性报告。
在步骤1545-1555中，用户导航到日常中断服务管理能够被访问的地方。在步骤 1545，系统100提示用户选择工作周和工作日。在步骤1548，系统100提示用户选择 中断时段的开始。在步骤1550，系统100提示用户输入期望的和人力资源相关联的服 务请求期间。在步骤1552，系统100提示用户完成附加细节域。在步骤1555，系统100 保存步骤1545-1552的输入。可用的SLA提供资源被二级SLA提供方用户指定，并且 通过默认的当前日常日程向用户显示；通常半小时增加一次浏览。用户选择日程行为开 始时间和结束时间并且保存设置。输入被存储，并且SLA提供资源显示为不可用于间 断时段帧的分配。日程细节记录被存储在表格中，例如表格55-57。表格55是存储识 别工作资源和可用PO分配的控制表格。一个劳动资源能够存在多个分配覆盖时段。表 格56存储基本的工作表格，而表格57按照二级SLA提供方的管理存储非标准中断时 段细节和日常中断细节。
图16是支持人力资源服务管理功能的数据库示意图。本领域技术人员会认同，各 种实施例提供给主要SLA提供方劳动强制物流可见性，以及满足它们的客户的SLA需 求的计划功能性。尽管没有详细描述，为一个或多个SLA客户提供细节记录的工作中 断事件中，给主要SLA提供方的系统逐渐减弱通知配置是一个自然的提供特性。在各 种实施例中，高级的配置可以被执行，使得系统行为和可用的通知能够被发起来为SLA 客户服务中断漏洞计数。
先前的行为是作为准备SLA服务提供物流管理/处理和可用的SLA客户质量保证的先 决条件。关于SLA提供分配的主题包括：1)通过服务提供请求功能，SLA客户能够创建 和提交服务请求给主要SLA提供方；2)主要SLA提供方系统询问特征，该特征能够被用 于输出已配置的二级SLA提供方列表，并且输出可适用的报价以及指定的用于服务提供 分配的有关的人力资本源的可用性；3)使主要SLA提供方选择特定的进行潜在分配的可 用SLA提供资源；4)使主要SLA提供方系统地提交服务提供分派请求记录给二级SLA 提供方；5)使二级SLA提供方确认资源可用性和随后地给主要SLA提供方的资源分派；6) 使主要SLA提供方确认给SLA客户的资源分派。
图17A是适用于物流供给和管理功能的流程图。该流程从步骤1702开始。步骤 1702-1720描述了SLA客户提交服务提供请求给主要SLA提供方的流程。在步骤1702 中，SLA客户方用户访问系统100。导航可适用的菜单并且激活创建提供请求控制。步 骤1702没有详细说明所有用户限制或者特定授权权利的使用；然而，如果SLA客户需 要的话，不同的本发明的具体实施例可能结合了用户角色和特定的数据处理权限/授权。 在步骤1705，系统100提示用户指定SLA客户位置和标识符。步骤1705指示SLA客 户方用户选择一个位置来开始询问流程。这仅仅是一个示例性模式而不是内在限制。例 如，询问流程可能开始于合同参考或者对特定提供细节记录的查找。在步骤1708中， 系统100提供给用户合同的列表和适当的SLA协议提供服务。步骤1708在图17B中 被增加，图17B描述了一个嵌入在被激活的控制中使SLA客户方用户访问关键的SLA 提供信息的简单GUI接口。SLA客户方用户立即识别出适当的SLA提供细节记录或者 使用嵌入的控制通过与相关SLA提供细节记录需要的信息浏览来进行确定。在图17B 中，控制使所有的用来提供给用户附加信息浏览的相关行为是潜在激活的。然而， 1708-A9是未激活/备份的，直到当至少一个记录在1708-A1中被选定。每个嵌入的链 接可能提供给用户新的UI来表示用于栏目头信息。SLA客户方用户使用所提供的复选 框来指定哪个SLA提供细节记录和SLA服务提供请求关联起来。步骤1710中特定记 录的选择触发一个附加的UI输入形式，通过这个UI输入SLA客户方用户如果需要的 话可以在步骤1712增加注释。
在步骤1710，用户选择需要的SLA提供服务记录并且保存选择。在步骤1712，系 统GUI提供给用户附加的输入域。用户完成附加的输入并且保存。本领域的相关技术 人员公认，尽管通过浏览表格64-66，在一个具体实施例中，步骤1702-1712描述的流 程中，SLA客户方用户仅仅可以提供输入到最小的域，因为剩余的都是默认数据。如 果提供服务工作的性质认可了这样地数据元素附加，则附加输入域选项能够简单地加到 数据库中。
[00237]在步骤1715，系统100提示用户提交SLA提供服务请求给SLA提供方。尽管 在步骤1715没有详细描述，在不同的实施例中，SLA客户方用户能够用不同的路径发 送服务提供请求给指定的主要SLA提供方用户，例如技术帐户管理人员，如果业务要 求指示了这样一个情况。适用于步骤1702-1715的细节存储在表格中，例如表格64-67。 在步骤1720，用户提交SLA提供服务请求给SLA提供方。
步骤1721-1728描述了主要SLA提供方获取二级SLA提供方与SLA客户服务提供 要求相关细节的系统访问流程。在步骤1721，系统100通知主要SLA提供方一个新提 交的SLA提供服务请求。虽然在步骤1721中没有详细描述，服务提供请求响应通常被 在系统100中被管理和操作，这意味着表格30中的dispatchresponseTimeID域是被激 活的而且由适用方在服务提供请求处理时创建派遣通知，而不处理之前配置的预期/时 间计划。而且，在不同实施例中，扩展的用户角色功能被用于派遣通知特定的主要SLA 提供方用户各种路径/指派。从另一方面来讲，SLA客户方用户按照服务提供请求处理 状态而被通知。
在步骤1723，主要SLA提供方用户访问新的SLA提供服务请求，例如，通过GUI。 在步骤1725，主要SLA提供方用户激活显示提供服务时段控制。在步骤1728，系统 100提供给用户已授权的二级SLA提供方和可适用的被授权为各个提供细节记录提供 服务的已确认人力资源显示列表。所述显示通常有，例如，可用性，价格，服务衡量标 准。步骤1728提供给可适用的主要SLA客户方用户关于图17C中与二级提供方相关 的输出浏览摘要。
在图17C中，1728-A1是给主要SLA提供方用户的简单的复选框选项。然而，在 1728-A5中可用资源计数为零时，所述选项通常是未激活/备份给用户的。当用户开始 使用1728-A5中的激活控制时，各个可用人力资源和它们的日程表摘要显示列表被提 供。可用于主要SLA提供方用户的业务信息不仅会导致潜在分配的资源可见，还会提 供重要的财务和质量保证业务信息窗口来使得类别确定流程最好的执行。
步骤1730-1732描述了主要SLA提供方在必要情况下的选择流程，优选特定的将 被分配给可适用的SLA客户地点的可用SLA提供资源。在步骤1730中，如果多个资 源是可用的，主要SLA提供方用户选择优选的二级SLA提供方记录和人力资源参考。 在步骤1732中，主要SLA提供方用户保存选择。尽管步骤1730描述了仅仅一个二级 SLA提供方记录被选择的示例性流程，然而可以选择多个记录。主要SLA提供方用户 可能选择多个二级SLA提供方来接收分配请求记录。在这样的情况下，系统100在通 常的实施例中，用先进先出的模式处理工作流程。在另外一种假定中，不考虑二级SLA 提供方的关联情况，情况可能会变得很严重，并且命令分配所有的可用资源。本发明不 同的具体实施例可能有来自多个二级SLA提供方的多个SLA提供资源分配请求。
通过选择二级SLA提供方记录，随后的应用功能可以使用户获知更多的细节，并 且在需要的情况下，主要SLA提供方用户可能指派一个优选的SLA提供资源或所需资 源列表以进行提供启动。特殊资源可能因为多个原因可能是必须的。原因包括，例如， 满意的历史质量衡量标准或者SLA客户的优先选择。信息存储在表格里，例如表格68 和69。存储在表格例如70-71中的数据被看作表格68一个域的源数据。任意用来分配 的优选的SLA提供资源标识被存储在，例如，表格69中。
步骤1735-1738描述了主要SLA提供方签署服务提供分配请求的流程。在步骤1735 中，主要SLA提供方用户被提示发送服务提供分配请求。在步骤1738中，主要SLA 提供方用户提交服务提供分配请求给可适用的二级SLA提供方。
步骤1740-1755描述了二级SLA提供方系统地确认资源可用性和资源分配给可适 用的主要SLA提供方的流程。在步骤1740中，系统100通知二级SLA提供方新的服 务提供分配请求。在步骤1742中，二级SLA提供方用户访问新的服务提供分配请求。 步骤1740-1742，尽管没有描述，但是可以在系统100中按照步骤1721的描述被更加 紧密地管理/操作。
在步骤1745中，二级SLA提供方用户确认人力资源的可用性。步骤1745描述的 仅仅是关于资源可用性的正面结果。本领域的相关技术人员共知，不会只存在这样的情 况；然而，为了不模糊本发明在多种具体实施例下的特征，反面结果的交易被省略。在 反面资源可用性的情况中，和管理日程数据相反，在典型的实施例中，系统100为质量 衡量标准跟踪这样的二级SLA提供方的不足情况，并且计算二级SLA提供方关于资源 能力和可用性的低效率的因素。通过资源可用性确认，系统100通常提示二级SLA提 供方发送分配确认给可适用的主要SLA提供方。在把新的记录上传到表格72保存的数 据库的流程中，附加的细节被输入和存储。
在步骤1748中，系统100提示二级SLA提供方发送人力资源分配通知给主要SLA 提供方。在步骤1750中，二级SLA提供方用户激活提交分配确认控制。在步骤1752 中，二级SLA提供方完成附加域并且保存输入。在步骤1755中，二级SLA提供方提 交所述分配记录。
在步骤1740-1755中，二级SLA提供方被要求建立SLA提供资源的识别身份，时 间分配和在步骤1745中保存输入的到达时间评估，例如，在表格72中。另外，关于设 施的访问，方向等等的地点信息，被提供并且在这个流程中被二级SLA提供方确认。 步骤1740-1755命令二级SLA提供方提交关于物流工作分配，这些步骤还提供给二级 SLA提供方重要的SLA客户正常提供分配的物流信息。
步骤1758-1768描述了主要SLA提供方系统地通知SLA客户SLA提供资源分配到 提供地点的流程。在步骤1758中，系统100通知主要SLA提供方分配记录。在步骤 1760中，主要SLA提供方访问分配确认记录并且确认接收。在步骤1762中，系统100 提示主要SLA提供方发送分配确认通知给SLA客户。在步骤1765中，主要SLA提供 方用户激活发送分配确认控制。在步骤1768中，系统100发送通知给SLA客户并且使 分配记录在线可用。步骤1758-1760在需要的情况下能够通过派遣配置被及时管理和操 作。步骤1758-1768的流程完成了从SLA客户问题开始到SLA客户方用户被通知提供 资源到达评估时间结束的周期。
图18是支持物流提供和管理功能的数据库示意图。本领域的相关技术人员共知， 本发明的多种具体实施例中，本发明使用支持数据表和应用流程不仅仅把最需要的可见 性和物流控制导入到提供工作中，而且把必要的人员和通信结合到单个平台上。尽管没 有详细描述，配置可能在不同的具体实施例中被建立，通过这个配置增加自动操作能够 被导入来进行系统提供请求和工作分配。在可适用的主要SLA提供方人员不能响应 SLA客户提供服务请求时，这样的假设经常时有用的。
图19A-19B描述了适用于SLA提供工作确认和质量保证的流程。关于图19A-B 的描述重点是关于服务提供分配中的提供行为的跟踪和记录。假设二级SLA提供方或 者SLA客户联系主要SLA提供方以通知其已经分配的提供资源没有到达提供地点，系 统100可能包括处理这样假定的功能性。所述功能性可能被提供给SLA客户方用户来 初始化没有出现的工作流或者直接和主要SLA提供方用户通信，比如通过电话，一个 工作流流程可能会重启，步骤1725的可用资源浏览(参看图17C)参考了已经存在数 据库中的适用于即将提供工作的记录。
关于图19A-B的描述重点是：1)使二级SLA提供方资源通过细节相关访问服务 部署凭证功能，例如，访问工作操作，材料配置以及响应服务提供分配请求输入到系统 100的时间选择；2)使二级SLA提供方提交服务部署凭证给主要SLA提供方来浏览和 确认部署；3)使主要SLA提供方浏览和确认来自二级SLA提供方的服务部署凭证；4) 使主要SLA提供方参考来自二级SLA提供方的服务部署凭证创建主要SLA提供方的 服务配置凭证，并且同样提交给SLA客户进行浏览和部署；5)使SLA客户处理主要 SLA提供方服务部署凭证并且提供质量确认评估信息；以及6)通过SLA客户服务部 署凭证处理，向主要SLA和二级SLA提供方用户发送系统通知。
再参考图19A，流程1900开始于步骤1902，在这个步骤中，二级SLA提供方资 源完成一个服务提供呼出。步骤1904-1918描述了SLA提供资源服务部署凭证处理流 程。在步骤1904，二级SLA提供方资源导航一个菜单驱动的GUI来选择工作凭证功能。 在步骤1906，系统100提供开放状态的所有提供分配记录的显示列表记录。所述显示 列表通常可以处理多个分配(例如，公开派遣记录较多时的多个分配)。
在步骤1908中，用户选择需要的提供记录。步骤1908中的行为会导致系统100 在步骤1910中提供服务部署凭证UI。该UI通常包括所有和提供派遣记录设置相关联 的细节。因此，SLA提供资源可能通常仅需要完成用于服务提供工作执行的数据输入， 该输入在步骤1912中完成。通过保存步骤1914中的输入存储，系统100存储处理细节， 例如在表格73-77中。
一旦凭证记录被存储，SLA提供资源被提示以提交凭证给之前配置好的二级SLA 提供方用户来浏览，以及后续流程在步骤1916和1918中处理。步骤1918中的行为触 发了在步骤1920中发送通知给之前配置好的二级SLA提供方用户。
在步骤1922中，用户访问来自菜单或者提供链接的新提供凭证。步骤1922描述了 二级SLA提供方用户导航到特定的能够处理服务部署凭证的功能应用模块的流程。所 述访问通过标准的菜单导航或者通过激活特定的用于凭证处理的操作板通知链接来完 成。
步骤1924-1934描述了二级SLA提供方服务部署凭证处理。在步骤1924中，系统 100提供给用户凭证接口GUI。所述凭证包括二级SLA提供方订购单中建立的价格。 系统100为二级SLA提供方用户显示SLA提供资源提交的凭证信息以及来自适当的二 级SLA提供方订购单和适当的PO排列项结合的信息。步骤1924是提供给二级SLA 提供方注意完成的提供工作和浏览包含在凭证中的订购单细节的主要确认步骤。
在步骤1926中，用户通过系统输入凭证细节和保存进行确认。步骤1926是对二级 SLA提供方用户存储在数据库中的信息的物理确认。该确认行为会导致系统中提示二 级SLA提供方用户在步骤1928完成所有可适用的征税评估输入。完成征税数据输入或 者确认后，如果该征税评估提前被配置了，二级SLA提供方用户在步骤1930中保存数 据设置。
步骤1932-1934会使工作确认凭证提交给配置后的主要SLA提供方用户。在步骤 1932中，系统100提示用户提交该凭证给主要SLA提供方。在步骤1934中，用户提 交凭证给主要SLA提供方检查/确认。
步骤1936-1944描述了主要SLA提供方检查和部署已提交的二级SLA提供方服务 部署凭证的流程。步骤1936-1938使配置后的主要SLA提供方用户访问已提交的二级 SLA提供方服务部署凭证。在步骤1936中，系统100通知主要SLA提供方新的提供凭 证。在步骤1938中，主要SLA提供方用户从菜单或通过的链接访问新的提供凭证。
在步骤1940中，系统100提供用户凭证接口GUI。该凭证包括二级SLA提供方定 购单中建立的价格。主要SLA提供方用户通常被提供一个接口，该接口具有适用于服 务提供行为以及二级SLA提供方定购单相关细节的显示记录。在步骤1942中，用户可 以选择确认或者不确认被提供的详细信息。正面的行为被描述，通过这个行为提交的服 务部署凭证在步骤1944被确认。步骤1944之后，二级SLA提供方用户被系统地提示 确认已提交的服务部署凭证。
步骤1946-1954描述了主要SLA提供方能够把确认的二级SLA提供方服务部署凭 证的细节结合到明确的主要SLA提供方服务部署凭证中的流程，所述主要SLA提供方 服务部署凭证将会包含适当的SLA客户定购单数据。一旦步骤1944中凭证的确认产生， 主要SLA提供方用户被提示在步骤1946中创建一个新的服务部署凭证，例如，通过激 活UI的提供控制。被描述的流程为了示例的需要是线性特征的。新的服务部署凭证的 创建如果是根据主要SLA提供方来配置的，则能够在不同的时间被不同的人员产生。 用户在步骤1948中创建新的服务部署凭证，这会触发一个和步骤1908-1910中二级SLA 提供方处理服务部署凭证类似的流程和数据结合。
参考图19B，在步骤1950中，系统100提供给用户凭证接口GUI。该凭证包括SLA 客户定购单中建立的价格。系统100创建一个主要SLA提供方服务部署凭证，该凭证 包含用于物理服务部署工作和关于SLA客户方定购单相关的财务信息的细节。
[00263]SLA客户没有必要的业务原因去查看任何适用于二级SLA提供方除数据输入外 的由SLA提供资源输入的关于服务提供工作的相关细节。因此，新的主要SLA提供方 服务部署凭证被创建包含关于SLA客户和主要SLA提供方之间关系的细节。
步骤1952-1954描述了主要SLA提供方用户确认和提交完成的主要SLA提供方服 务部署凭证给SLA客户的行为。尽管系统100创建了一个新的主要SLA提供方服务部 署凭证，数据实际上是包含在表格73-77中的次要设置数据。本领域的相关技术人员公 知，一个简单的数据库结构变化能够通过使用指示性数据库关系使该数据存储在明确的 表格中。
步骤1956-1988描述了SLA客户处理提交的主要SLA提供方服务配置凭证使采用 的步骤。在步骤1956中，系统100通知SLA客户有新的提供凭证。在步骤1958中， 系统100提供给用户一个凭证接口GUI。该凭证包括SLA客户定购单中建立的价格。
在步骤1960，SLA客户方用户被提示确认或者拒绝该服务部署凭证。尽管没有详 细描述，在各种实施例中，SLA客户方可能合并增强的用户规则和工作流，并且使确 认配置更加复杂和强健。假设SLA客户方用户对信息的确认包括在步骤1960的服务部 署凭证中，用户在步骤1964由系统100提示激活控制，该控制在步骤1964-1966进行 质量保证评估会话。在步骤1964中，系统100提示用户完成QA评估。在步骤1966， 用户激活QA会话控制。一旦Q/A会话开始，在步骤1968的系统100提供给用户GUI 形式来使SLA客户去访问服务提供工作的质量和合时性，以及先前物理服务提供的可 提供物流的合时性和管理的减轻。
通过评估的完成，SLA客户被提示在步骤1970中保存他们的输入。该行为触发在 步骤1972的系统100的更新，并且随后在步骤1974中对可适用的主要和二级SLA提 供方发送确认的系统通知。
如果在步骤1960中，SLA客户方用户拒绝了服务部署凭证，则继续到步骤1978 执行。在步骤1978中，由于有关于提供服务方面及时的讨论，SLA客户方用户被提示 完成拒绝评估。
在步骤1980中，系统100提供给SLA客户方用户一个GUI使其可以指派特定的 信息对象，并且输入注释来证明任何这样的对象是正当的。在步骤1982中，SLA客户 方用户完成他们的评估并且保存输入。这个行为触发了系统100在步骤1984进行保存 记录，随后在步骤1986对可适用的主要和SLA提供方发送拒绝通知。步骤1988表示 了一个可能被指定的开始，应用处理的目的是通过从多个部分干涉流程被导入和输入获 取和存储来形成一个永久循环。关于凭证拒绝的相关细节被存储在表格中就像，例如， 表格81当偏差代码自身被储存到表格中，就像，例如，表格80。
图20表示一个支持SLA提供工作确认和质量保证的数据库示意图。
SLA处罚评估是数据库比较事件，假设提供故障通常是一种事件是：1)分派不合 时，2)提供到达合时错误或者3)提供错误。在假设1)和2)的情况中，状态代码管 理的系统使用，数据/时间记录标记以及用户确认充分地监控这些提供方面。假设情况 3)，处罚评估是SLA客户凭证部署的一个功能。帐单/支付功能的讨论集中在系统100 的财务数据处理功能上。随后的信息线程如下：
绑定的SLA客户合同信息
绑定的提供细节记录
绑定的SLA客户PO记录
绑定的主要SLA提供方RFx报价
绑定的二级SLA提供方RFx报价响应
绑定的RFx报价金额
绑定的二级SLA提供方PO记录
上述信息线程完成导致SLA提供覆盖的管理建立
持续的信息线程如下：
绑定的SLA客户服务提供请求(参考提供细节记录产生)
绑定的主要SLA提供方服务提供分派需要
绑定的二级SLA提供方服务提供分派
绑定的提供资源服务部署凭证
绑定的二级SLA提供方服务部署凭证
绑定的主要SLA提供方服务部署凭证
SLA客户服务部署凭证处理
被覆盖的各种元素包括：1)配置确认的SLA客户确认的服务部署凭证的系统摘要； 2)主要SLA提供方为SLA客户帐单发票文件的系统生成；3)二级SLA提供方为主 要SLA提供方帐单发票文件的系统生成；4)主要SLA提供方基于SLA客户支付的支 付接收数据上传特征；以及5)主要SLA提供方基于SLA客户支付的对二级SLA提供 方特征的支付释放。
图21是表示可适用于帐单功能的流程图。步骤2102-2105描述了SLA客户确认服 务部署凭证的基础摘要。该摘要在程序建立时是可配置的，并且必需摘要循环周期的指 派。该摘要记录设置信息被存储在表格中，例如，表格82-83。表格83包括各个服务 部署凭证条目的识别；因此，摘要流程确认记录在表格中作为数据摘要资格不存在，这 意味着记录不会在错误中多余的被提取。尽管没有详细描述，记录提取能够在更强健的 方式中被配置，通过这种方式，各种的因素比如支付条款和计算周期能够被导入实现特 定的记录设置摘要。
步骤2108-2110描述了从基础摘要中产生的帐单发票文件处理。在步骤2108中， 系统100为每个SLA客户生成配置的帐单发票文件。在步骤2110中，系统100为每个 二级SLA客户生成配置的帐单发票文件。因为系统100是完整的生活周期处理和业务 实体中心，帐单发票文件不仅为向代表主要SLA提供方的SLA客户的支付而产生，而 且也为了向代表二级SLA提供方的主要SLA客户支付而产生。如果摘要周期中为多于 一个SLA客户和多于一个二级SLA提供方有多种处理，所述帐单发票文件是多样的。
步骤2112-2118共同地表示主要SLA提供方帐单发票文件处理。这些步骤描述了 一个控制流程，该控制流程由指派的主要SLA提供方用户(群)能够访问和检查编译 后的文件。该流程是可配置的，并且如果主要SLA提供方选择不执行浏览和释放流程， 该流程可以在多个实施例中被省略。在步骤2112，系统100通知授权的主要SLA提供 方用户新的帐单发票文件是可用于流程的。在步骤2115中，主要SLA提供方用户访问 财务管理模块。在步骤2118中，主要SLA提供方访问帐单发票文件。在步骤2120中， 主要SLA提供方选择新的帐单发票文件。在步骤2122中，系统100显示给用户帐单发 票摘要浏览。在步骤2125中，系统100提示用户释放帐单发票文件。在步骤2128中， 用户释放帐单发票文件。在步骤2130中，系统100生成各种SLA客户帐单发票文件。
经过在步骤2128释放帐单发票文件，系统100在步骤2130-2132生成分列的SLA 客户和二级SLA提供方帐单发票文件浏览。在步骤2135中，指派的系统用户被通知帐 单发票文件已经制成可用于检查。该文件在系统100中仅仅可以被授权配置的用户浏 览。只有关于特定业务实体的记录通常被该业务实体的用户浏览(例如SLA客户或者 二级SLA提供方)。如果需要的帐单发票文件可以被附加地提交，例如通过EDI，如果 业务方法授权了这样的处理模式。
步骤2138-2148描述了二级SLA提供方和SLA客户确认文件接收的流程。SLA客 户的确认是未连接于或独立于二级SLA提供方文件接收确认的。使用EDI和EFT技术， 这个处理流程是一个沉默小处理流程，通过这个流程资金可以基于服务部署凭证确认进 行转移。之后，财务处理可以被限制到可能已通过多个确认流程执行的资源数据元素中。
在步骤2138中，授权的SLA用户访问财务管理模块。在步骤2140中，SLA客户 访问帐单发票文件。在步骤2142中，系统100通知主要SLA提供方帐单发票接收确认。 在步骤2145中，系统100提示SLA客户方用户确认帐单发票文件接收。在步骤2148 中，SLA客户方用户确认帐单发票文件。
在步骤2150中，SLA客户根据契约条目和状况对主要SLA提供方进行支付。在步 骤2152中，主要SLA提供方上传现金接收文件数据进入系统100或者人工更新要支付 的帐单发票记录状态。在步骤2155中，主要SLA提供方运行二级SLA提供方发票未 决的报告。在步骤2158中，系统100提示用户授权支付。在步骤2160中，用户授权支 付。在步骤2162中，二级SLA提供方被通知支付授权。在步骤2165中，主要SLA提 供方按照契约条目和状况支付给二级SLA提供方。在步骤2168中，主要SLA提供方 上传现金支付文件数据进入系统100或者人工更新要支付的二级SLA提供方帐单发票 记录状态。在步骤2170中，支付数据可为授权用户在线利用。
图22表示支持帐单支付功能的数据库示意图。
图23是信息管理和决策支持功能的宏观层次示意图。在图23中，系统2300包括 SLA提供管理应用数据库2350来接收作为输入的主数据处理流量2310，采购处理流量 2320，SLA提供处理流量2330，以及财务处理流量2340。
从SLA提供管理应用数据库2350的输出包括SLA客户提供请求计划&战略覆盖 分析输出2355，SLA提供方执行度量&正在进行的决策支持需要提供输出2360，契约 的SLA支持分析输出2365，授权&材料执行分析输出2370，以及SLA提供收益性&财 务分析输出2375。参考输出2355，主要SLA提供方使用外包模式来满足SLA服务提 供需要，为了避免SLA客户在提供服务网络初始设置不充分的情况下遇到不必要的风 险错误。
不同的流程使得在输出2355中内在的决策支持功能。这些包括：1)合同信息转换 为提供细节记录；2)人力资源提供技术概要；2)SLA客户位置映射到提供细节记录； 3)二级SLA提供方RFx报价和SLA提供资源提交响应流程；4)SLA提供资源分配； 以及5)SLA提供资源日程配置/管理。通过提供给主要SLA提供方的方法，SLA提供 网络间隙或者失效能够被在契约的SLA提供覆盖初始化之前被识别。如果主要SLA提 供方为了分析的目的具有零历史数据，可以采用方法来促使识别潜在的SLA提供缺陷， 例如，该方法基于：1)地理覆盖；2)技术熟练读覆盖；3)时间帧覆盖。从另一方面 来看，如果主要SLA提供方具有关于进行分析时SLA服务提供频率的数据，更多的细 节浏览能够被生成来扩展提供服务中断识别的范围。
风险识别决策支持模式的值在网络建立期间超出它实际使用时的值。一旦提供网络 被配置，报警监视可能在所有关于特定提供细节记录/PO的已分配资源中断使用时，被 配置来系统地通知主要SLA提供方。
现在转到输出2360，不同的流程使得SLA提供性能分析。该流程包括：1)关于 提供细节记录的SLA提供响应时间帧规范；2)关于提供细节记录的在线SLA客户服 务提供请求处理；3)跟踪的主要SLA提供方服务提供请求处理；4)跟踪的二级SLA 提供方服务提供分派请求处理；5)跟踪的二级SLA提供方服务提供分派处理；6)SLA 提供资源服务部署凭证处理；7)二级SLA提供方服务部署凭证处理；8)主要SLA提 供方服务部署凭证处理；以及9)SLA客户服务部署凭证处理。这些流程提供了一个获 取充分跟踪和管理SLA提供性能必须的细节的方法。本领域的技术人员会认同，SLA 服务提供的生命周期从SLA客户服务请求开始，在对提供服务质量做出评估时达到顶 点。对前后文进行浏览时，生命周期可能被打破进入能够被测量和分析的支功能中。多 个实施例允许相应的量化和分析，不限制于：1)主要SLA提供方影响SLA提供时间 帧对象；2)二级SLA提供方影响SLA提供时间帧对象；3)SLA提供资源影响SLA 提供时间帧对象；4)SLA提供资源影响SLA提供服务对象；以及5)SLA客户的满意 /不满意度。可以分析关于二级SLA提供方的宏性能(例如作为业务实体)，或者微性 能(例如，说明单个提供资源性能)。
转到输出2365，多个进程来完成契约的SLA提供分析。和重点在于提供方性能的 输出2360相反，输出2365重点在于SLA性能合同的反面检查，例如，SLA未提供惩 罚和SLA提供对象衡量标准。SLA提供性能能够从多角度被检查，例如多合同SLA客 户提供性能综合或者对特定产品或者服务的多SLA客户合同的SLA性能综合检查，或 者内部业务组织。
另外，多个实施例使得一个主要SLA提供方以一种单一的方式浏览合同。因为技 术概要功能和数据库驱动的SLA响应时间帧代码，使得合同比较浏览来容易指出有关 的SLA客户合同的相同和不同，SLA客户合同特别地包含相似产品和/或服务。SLA合 同经常根据客户的不同而不同。一些不一致性很小，而一些很显著。不同的实施例提供 了在适合检查和分析的方式中发现这些不一致性的方法。
用于特殊地理区域或者在特殊行业的SLA客户，例如电信等行业的SLA合同，包 含提供响应时间帧，该提供响应时间帧是所有其它可适用的SLA合同的一半。例如， 这个主要的不一致能够被潜在地关联到一个特定的销售组织或者下拉合同提供条款。而 且，不同的实施例提供属于这些不一致造成的影响的直接衡量标准输出。一个系统对象 会提供给主要SLA提供方所有的必要的浏览而不仅仅是识别SLA合同提供。
转到步骤2370的输出，用类似的方式进行合同参数分析，使得可以跟踪和授权特 定的服务和材料授权参数。转到步骤2375，例如，SLA提供收益性&财务分析输出适 于合同价格，二级SLA价格，SLA提供惩罚和衡量标准成本。通过分析可以最终实现 提高底线财务业务性能。
本发明的实施例可能在被实施，例如硬件，软件(例如被执行计算机可读指令的流 程完成)，或者两者的结合。计算机可读指令可能被加载在内存里，例如只读存储 (ROM)。例如，处理器可能被操作来按照适合本发明的原则来执行一系列步骤。软件 可能存储在计算机可读的介质中，例如闪存卡，EEROM存储，磁泡存储，或者ROM 存储。按照适合本发明的原则来执行的软件可能存储在全部或者部分介质中，在静态或 者动态的主存或处理器的固件(例如在微控制器，微处理器或者微型计算机内置存储器) 中。
示例性表格1-91如下：
1-设计

2-设计

3-设计

3-数据
tbISLAProvisionTypes(数据视图)
  SLAProvisionTypeID   SLAProvisionTypeDesc   状态   1   Purchase_Warranty_Repair   Active   2   Extended_Warranty_Repair   Active   3   Service_Warranty_Repair   Active   4   Preventive_Provisioning   Inactive   5   Non-Contracted_Provisioning   Inactive
4-设计

4-数据
tbISLAProvisionLaborTypes(数据视图)
 SLAProvisionLaborTypeID   SLAProvisionLaborTypeDesc   状态  1   Time_Only   Inactive  2   Time_and_Expense   Inactive  3   Time_and_Material   Active  4   Time_and_Expense_and_Material   Active  5   Fixed_Price   Inactive  6   Labor_Differential   Inactive
5-设计

5-数据
tbISLAProvisionTimes(数据视图)
  SLAResponseTimeID   SLAResponseTimeDesc   1   Half Hour   2   Hour   3   End_Of_Business_Day   4   Caiendar_Day   5   Next_Busines_day
6-设计

7-设计

8-设计

9-设计

10-设计

11-设计

12-设计

13-设计

14-设计

15-设计

16-设计

17-设计

18-设计

19-设计

20-设计

21-设计

22-设计

23-设计

24-设计

25-设计

26-设计

27-设计

28-设计

29-设计

30-设计

31-设计

32-设计

33-设计

34-设计

35-设计

36-设计

88-设计

88-数据

89-设计

89-数据

37-设计

38-设计

39-设计

40-设计

41-设计

42-设计

43-设计

44-设计

45-设计

46-设计

47-设计

48-设计

49-设计

50-设计

51-设计

52-设计

90-设计

91-设计

53-设计

54-设计

55-设计

56-设计

57-设计

58-设计

59-设计

60-设计

61-设计

62-设计

63-设计

64-设计

65-设计

66-设计

67-设计

67-数据
tbISLAProvisionRequestStatus(数据视图)
  ServiceRequestStatusID   ServiceRequestStatusDesc   1   Temporary_Save   2   New_Submission   3   SLAPP_Acknowledged   4   SLAPP_Nonprocessed   5   Svc_Dispatch_Request   6   Dispatched   7   Awaiting_Voucher   8   Voucher_Pending   9   Voucher_Disposition
68-设计

69-设计

70-设计

70-数据
tbISLAResourceDispatchPreference(数据视图)
  ResourceSelectionPreferenceID   ResourceSelectionPreferenceDesc   1   Any_Avallable_Resource   2   Specific_Resource_Request
71-设计

71-数据
tbISLADispatchRequestStatus(数据视图)
 ResourceSelectionPreferenceID   ResourceSelectionPreferenceDesc  1   Temporary_Save  2   New_Submission  3   SLASP_Acknowledged  4   SLA_Client_Notified  5   SLASP_Declined  5   Open
72-设计

73-设计

74-设计

75-设计

76-设计

76-数据
tbISLAVoucherProvisionOutcomeStatus(数据视图)

77-设计

77-数据
tbISLAVoucherStatus(数据视图)
  VoucherStatusID   VoucherStatusDesc   1   Submitted_To_SLAPP   2   Submitted_To_SLAClient   3   Approved   4   Declined_SLAClient   5   Declined_SLAPP   6   On_Hold   7   Contested_SLAPP   8   Contested_SLACllent   9   Contested_Declination_SP
78-设计

78-数据
tbISLAVoucherProvisionPerformance(数据视图)
  Provision_Performance_ID   Provision_Performance_Desc   1   Poor   2   Fair   3   Good   4   Excellent   5   Outstanding
79-设计

79-数据
tbISLAVoucherLogisticPerformance(数据视图)
  Provision_Performance_ID   Provision_Performance_Desc   1   Poor   2   Fair   3   Good   4   Excellent   5   Outstanding
80-设计

80-数据
tbISLAVoucherDecinationCodes(数据视图)
  Provision_Performance_ID   Provision_Performance_Desc   1   Incorrect_PO_Data   2   Incorrect_Provision_Data   3   Service_Provision_Failure
81-设计

82-设计

83-设计

84-设计

85-设计

86-设计

87-设计

前面的具体描述是本发明的实施例。本发明的范围不应被该描述必然的限制。，本 发明的范围是可代替的被下述权利要求和它的等同形式所定义。
相关专利参考
本专利已经要求美国优先权，具体参考美国临时专利申请文件，申请号为No.60/704， 352，申请日为2005年8月1日。本专利申请参考了以下专利：美国专利申请号为No. 10/262487，申请日为2002年9月30日(67737-532USPT)；美国专利申请号为No. 10/412096，申请日为2003年4月10日(67737-532USP1)；美国专利申请号为No. 10/797556，申请日为2004年3月10日(67737-532USP2)；美国专利申请号为No. 10/141801，申请日为2002年5月9日(67737-542USPT)；美国专利申请号为No. 10/128751，申请日为2002年4月24日(67737-543USPT)；美国专利申请号为No. 11/071831，申请日为2005年3月2日(67737-1002USPT)。