基于发送方和接收方关系的消息转发的制作方法

专利名称：基于发送方和接收方关系的消息转发的制作方法
技术领域：
本发明一般涉及数据处理。更具体地，本发明涉及基于发送方和接收方 关系的呼叫转发。
背景技术：
当某个区域的客户通过访问公共电话号码(例如，区号为800的电话号 码)向呼叫中心发出呼叫时，该呼叫应该被负责该区域的专用服务台工作人 员接受。不负责该专用区域服务的其他人，不应该接收该呼叫和看到与该专 用区域相关联地客户的附件数据。传统方法和系统没有有效地处理这些问题。

发明内容
这里描述了用于基于发送方和接收方之间的关系转发消息(该消息可以 是呼叫或任何通信请求及其相关上下文)的技术。在一种实施方式中，过程 包括但不局限于，响应于经由网络来自发送方的消息，考虑发送方，基于候 选接收方在组织内的角色，识别(identify)处理该消息的候选接收方的列表； 和将消息转发给从该候选接收方列表中选择的接收方，以使得所选择的接收 方能够处理该消息。
根据附图和接下来的详细描述，本发明的其它特征将会显而易见。


在附图中以示例的方式而非限定的方式图示了本发明，其中相似的参考 标记指示类似的元素。
图1为框图，示出了根据一种实施方式的用于基于责任管理框架对呼叫 进行路由的系统配置。
图2为流程图，示出了根据本发明的一种实施方式的用于将呼叫路由到 适当用户的过程。
图3为流程图，示出了根据本发明的一种实施方式的用于基于来自EIS
的信息对呼叫进行路由的过程。
图4为流程图，示出了根据本发明的一种实施方式的用于将呼叫路由到 适当用户的积无述过程。
图5为流程图，示出了根据本发明的一种实施方式的用于将呼叫路由到
适当联系人的初始判断(justification)过程。
图6为流程图，示出了根据本发明的一种实施方式的将呼叫路由到适当 联系人的联系人搜索过程。
图7为流程图，示出了根据本发明的一种实施方式的用于将呼叫路由到 适当用户的呼叫历史搜索过程。
图8为流程图，示出了根据本发明的一种实施方式的用于将呼叫路由到 适当联系人的最终选择过程。
图9为数字处理系统的框图，该数字处理系统可以与本发明的一种实施 方式一起4吏用。
图10为示出ERP系统的结构单元和业务特性的示例的图。
图11为示出ERP系统的关系、层级(Hierarchy)和职位(Position)的
示例的图。
图12为示出ERP系统的特定示例和模板的图。 具4本实施方式
这里描迷了用于基于发送方和接收方之间关系转发消息的技术。在下面 的说明中，阐明许多细节来提供对本发明实施方式更全面的解释。然而，对 于本领域技术人员来说显而易见，无需这些特别的细节也可以实践本发明的 实施方式。在其它实例中，为人熟知的结构和器件以框图形式示出而非详细 示出，以避免模糊本发明的实施方式。
在i兌明书中4是及的"一种实施方式"或"实施方式"意思为与该实施方 式关联描述的特定特征、结构或特性包括在本发明的至少一种实施方式中。 短语"在一种实施方式中"在说明书各种地方的出现并非一定都是指相同的 实施方式。
因此，引入特定技术，用以考虑由企业信息系统(EIS)(例如与企业实 体或組织相关联的企业资源计划(ERP)) ^是供的信息，来处理到来的呼叫或 消息，包括生成与呼叫方或发送方相关联的适当上下文(context)，识别适当
的用户或接收方来处理到来的呼叫或消息，以及提供建议或预测可能执行的 某些进一步行动。
根据特定实施方式，作为到来呼叫路由管理集线器的呼叫路由控制器用 于基于企业信息系统(EIS)的责任管理框架，把到来的呼叫自动转发给正确
的联系人。它是一种集成了 EIS的责任管理、组织结构和/或客户支持功能的
现有的呼叫路由方法基于接收方存在/用户可用(availability)状态。
图1为框图，示出了根据一种实施方式的用于基于责任管理框架对呼叫 进行路由的系统配置。在一种实施方式中，系统100包括但不局限于搜索引 擎，其响应于经由网络来自发送方的消息，考虑发送方，基于候选接收方在 的组织内的角色，识别对该消息进行处理的候选接收方的列表；系统100还 包括连接到搜索引擎的转发引擎，其将消息转发给从候选接收方列表中选出 的接收方，以使被选接收方能够处理该消息。
参考图1，系统100包括经由网络104可通信地连接到服务器103的一 个或更多客户端101-102。为了说明的目的，客户端101-102为可通信地连接 到通信中心103的呼叫方，通信中心103可以是呼叫中心或与组织或企业实 4本相关联的企业IP电话网络。例如，呼叫方101-102可以是拥有和/或运营通 信中心103的企业实体的客户。 一个或更多用户106可以是企业实体的员工 或客户代表。用户106可以经由网络104从呼叫方101-102接收呼叫，网络 104可以是PSTN (公共交换电话网)、PBX或数据网络(例如，例如^f吏用基 于IP的话音传输技术，或VOIP技术的因特网)。
在一种实施方式中，通信中心103可以可通信地连接到与企业实体相关 联的企业信息系统(EIS) 105。再次参照图1，在一种实施方式中，服务器 103可以包括连接到搜索引擎107的呼叫路由控制器或单元111，其响应于通 过网络从呼叫方(例如呼叫方101 — 102) ^妻收的到来的呼叫，识别处理该到 来的呼叫的潜在用户106 (例如接收方)。另外，通信中心103进一步包括上 下文生成器112，其用以生成具有与呼叫和/或特定相关事务相关的信息的通 信上下文，该通信上下文可以和呼叫一起转发给用户106。结果，当呼叫4皮 路由并由用户接收时，用户106具有关于呼叫方的充分信息(例如，呼叫方 的身份证明和/或先前的相关事务等)。
在一种实施方式中，响应于到来的呼叫，搜索引擎107在用来存储与呼
叫方和/或潜在用户相关联的关于业务事务的信息的 一 个或更多数据库(例如
数据库115-118)中执行搜索。例如，搜索引擎可以基于与该呼叫方和/或用 户相关联的特定因素，搜索和识別可能适合于处理特定呼叫方的到来呼叫的 一个或更多用户。
在一种实施方式中，可以基于从EIS 105的身份和访问管理(IAM，identity and access management)系统得到的信息识別将接收呼叫的潜在用户。在具铺、 的实施方式中，可以经由IAM系统的责任管理框架识别潜在用户。例如，可 以基于由IAM提供和管理的企业实体内的用户职责来识別用户。
例如，如果接收到来自位于东部区域的客户的呼叫，则可以识别和选择 负责该区域的用户来处理呼叫。进一步，作为另一个示例，如果4妄收到来自 具有特定类型产品的客户的呼叫，则可以识别和选择负责向该类型产品提供 服务的用户来处理这样的呼叫。用户职责可以在EIS的责任管理系统内预先 定义或分配，这样的信息可以用来将呼叫路由到适当的用户以进行应答。
图2为流程图，示出了根据本发明的一种实施方式的用于将呼叫路由到 适当的用户的过程。注意，过程200可以通过可以包括软件、硬件或这两者 组合的处理逻辑来执行。例如，过程200可以通过图1的系统100来执行。 在一种实施方式中，过程200包括但不局限于，响应于经由网络来自发送方 的消息，考虑发送方，基于候选接收方在的组织内的角色，识别处理该消息 的候选接收方的列表，并把消息转发给从候选接收方列表中选出的接收方， 以使被选接收方能够处理该消息。
参考图2，在方框201，当经由网络从呼叫方接收到消息或呼叫时，处理 逻辑在方框202基于该消息确定发送方的简档(profile)。在方框203，处理 逻辑考虑发送方的简档，基于用户的角色、责任或职责，识别可以处理对发 送方消息的响应的一个或更多用户的列表。在方框204，处理逻辑从列表中 选择用户来处理对消息或呼叫的响应，并生成与呼叫或发送方相关联的上下 文。在方框205，消息和上下文被转发给用户，以便使用上下文对消息做出 响应。
在特定的实施方式中，当接收到客户的到来呼叫时(例如，位于东部区 域的客户)，基于地址簿或合同目录提取客户的呼叫方ID (电话号码；如果 呼叫通过IP电话进行，则提取SIP (会话初始协议)地址)。根据职责矩阵和 /或责任管理框架搜索负责人，以基于呼叫方的简档识别用户。如果只找到一
个用户，则将呼叫转发给该用户。然后与识别的用户简档相连接的呼叫在该 用户的计算机用户接口出现。
如果找到多于一个用户，则在呼叫方通信交互历史数据库中进行搜索， 并且根据默认规则选择用户(例如，选择最频繁联系人的规则，选择最近联 系人的规则，或者其它默认规则)。
如果由于没有接收到来自用户的响应而使呼叫连接失败，则可以根据默 认规则将呼叫转发给下一用户。如果仍然没有用户响应，则将呼叫转发给接 线员或公用号码以手动转接呼叫，或者可替换地，可以根据公司职责结构或 組织模型，将呼叫转接到更上级、更高层联系人或者直接经理。
图3为流程图，示出了根据本发明的一种实施方式的用于基于来自EIS 的信息对呼叫进行路由的过程。注意，过程300可以通过可能包括软件、硬 件或两者组合的处理逻辑来执行。例如，过程300可以通过图1的系统IOO
来执行。
参考图3，当在方框301接收到到来的呼叫时，提取呼叫方的身份，例 如，呼叫方ID或SIP地址(如果是IP电话的话)。在一种实施方式中，这样 的呼叫方身份经由电话应用302提取。基于呼叫方的身份，在方框303实施 搜索以确定呼叫方相对于企业实体的业务伙伴关系类型，例如呼叫方是企业 实体的客户、供应商还是代理。
另外，基于呼叫方的身份，在方框304可以例如经由上文所述的EIS的 IAM (Identity and Access Management,身4分和访问管理)框架识别处理该呼 叫的用户的角色。例如，如果接收到来自东部区域呼叫，则可以识别负责东 部区域的一个或更多用户。在方框305，将识别的用户角色与在方框303识 别的业务伙伴关系类型进行匹配。如果存在匹配的用户，则在方框306,将 呼叫转发给识别的用户，并且将用户简档向识别的用户开放以用于处理呼叫。 否则，在方框307,用户简档将被冻结(例如，在该点不能被任何用户查看)。
如果没有用户匹配，则在方框308,提取呼叫方的业务伙伴详细说明 (specification),以作为在方框303所执行操作的结果。业务伙伴详细说明的 示例包括但不局限于业务伙伴的类型、区域、电话号码、电子邮件地址和/或 其它联系信息。在方框309,基于呼叫方的业务伙伴详细说明执行搜索以识 别可能与呼叫方相关的任何最终用户。在一种实施方式中，经由EIS的身份 和访问管理执行这样的搜索。作为搜索的结果，在方框310，生成根据覆盖
率的负责人员列表。
如果该列表只包含一个用户，则在方框313,生成与识別的用户相关联 的用户简档信息，并且在方框314，将呼叫和用户简档信息转发给该用户。 如果列表包含多于一个用户，则在方框311,基于呼叫记录312执行搜索以 识別呼叫方以前耳关系过的4壬何用户。如果至少有一个用户以前联系过，则在 方框315，可以选择最频繁联系的用户。如果没有用户以前联系过，则在方 框316，选择工作成绩(jobgrade)更高或最高的用户。其后，在方框313生 成用户简档，并且在方框314，将呼叫以及用户简档转发给被选用户。
另外，根据某些实施方式，执行用户存在检查操作318-320以确保接收 方的电话服务当时可用。用户存在检查操作318-320可以由用户存在检测器 317控制或操作(也称为接收方电话服务可用性检测)。用户存在检测器317 被配置为集中检测用户存在检查单元318-320的电话服务可用性状态。也可 以执行其它操作。
图4为流程图，示出了根据本发明的一种实施方式的用于将呼叫路由到 适当联系人的概述过程。当接收到呼叫时，根据一种实施方式，在方框401 处理逻辑识别呼叫方的身4分。呼叫可以由4妄收到该呼叫的相关企业实4本的业 务《火伴，例如供应商或客户，通过电话应用发出。可以通过将呼叫和与以前 在企业实体的EIS中注册的呼叫方相关联的通信交互历史数据库进行匹配来 识别呼叫方。呼叫的呼叫身份可以是电话号码、与业务相关联的名称、人名 或者仅仅是EIS中的注册id。如果无法识别呼叫方，则在方框409，处理逻 辑可以从通信交互历史数据库中搜索呼叫记录。
在一种实施方式中，在方框403，处理逻辑执行对识别出的呼叫方与目 标联系人的初始判断检查。典型地，可以基于与呼叫相关联的目标电话号码 确定目标联系人。在一种实施方式中，基于EIS的IAM系统判断呼叫的联系 人。IAM系统可以验证呼叫方身份与联系人访问权限之间的匹配。当判断联 系人时，在方框407，处理逻辑可以为连接呼叫的联系人打开呼叫方的用户 简档信息。用户简档信息可以与识别出的呼叫方的注册业务记录相关联。
在一种实施方式中，如果在方框403判断呼叫方和目标联系人失败，则 在方框405处理逻辑继续搜索正确的联系人。可以基于EIS的IAM系统用相 应的呼叫方判断正确的联系人。在一种实施方式中，处理逻辑在EIS内搜索 与呼叫方身4分相关的所有联系人。处理逻辑可以确定一组联系人以4妄收呼叫，
所述一 组联系人具有对与呼叫方相关联的业务信息的预定访问权限。如果找
到单个联系人，根据一种实施方式，处理逻辑进行到方框407并且连接呼叫。 如果处理逻辑在方框405为呼叫找到多于一个联系人或不能找到任何联系 人，则根据一种实施方式，在方框409，处理逻辑搜索与呼叫方相关的呼叫 历史以确定正确的联系人。否则，在方框407，处理逻辑可以将呼叫连接到 根据呼叫历史确定的联系人。在一种实施方式中，如果基于呼叫历史不能找 到正确的联系人，则在方框411,处理逻辑基于一组预定的3见则执行最终的 联系人选择。这组预定规则可以保证至少 一个联系人可以接收呼叫。
图5为流程图，示出了根据本发明的一种实施方式的用于将呼叫路由到 适当联系人的初始判断过程。过程500可以执行与图4的方框403类似的功 能。在一种实施方式中，在方框501，处理逻辑从到来的呼叫提取呼叫号码 或SIP地址。呼叫可以通过指向与企业实体相关的目标电话号码的电话应用 发出。在方框503，在一种实施方式中，处理逻辑根据呼叫的目标电话号码 在企业实体内识别联系人。可以在企业实体的EIS中指定对于与业务伙伴相 关的信息具有一 定访问权限的每个联系人，所述信息例如身份和访问管理系 统中组织模型和职责设置的主数据。例如，特定联系人可以仅仅具有对国家 东部区域的那些业务伙伴的访问权限和/或仅仅具有对业务伙伴的供应商相 关业务信息的访问权限。
在方框505，根据一种实施方式，处理逻辑继续根据在方框501获得的 呼叫号码或SIP地址识别呼叫方。处理逻辑可以调用EIS的身份评估管理函 数以检索与呼叫方相关联的用户简档。用户的简档信息可以包括关于业务伙 伴的业务相关信息，例如业务名称、所有者名称和相关业务关系，如客户或 供应商等。在一种实施方式中，用户筒档在业务伙伴识别设置中指定。在一 种实施方式中，在方框507，处理逻辑基于EIS中的IAM系统匹配识别的呼 叫方和联系人两者。如果4艮据EIS中MOM&职责和业务伙伴识别中的设置， 联系人具有对关于与呼叫方相关的业务信息的访问权，则匹配可能成功。在 一种实施方式中，如果处理逻辑不能识别呼叫方或联系人，则在方框507的 匹配失败。
图6为流程图，示出了根据本发明的一种实施方式的将呼叫路由到适当 联系人的联系人搜索过程。过程600可以执行与图4的方框405类似的功能。 在一种实施方式中，在方框601,处理逻辑在EIS中;l臾索与呼叫方所关联的
目标电话号码相关的业务联系人。企业实体中的电话号码可以与 一个或更多 联系人相关联。例如，呼叫中心中多于一个的客户服务代表可能与分配给呼 叫中心的一个电话号码相关。在一种实施方式中，处理逻辑在方框601基于
接收到的呼叫的SIP地址而非电话号码执行搜索。在方框603，根据一种实施 方式，处理逻辑从在方框601找到的那些业务联系人中识别具有对呼叫方的 用户简档信息的访问权限的联系人的子集。识别可以基于EIS中的IAM系统， 例如用于访问管理的MOM&职责的设置。在一种实施方式中，识别可以包括 基于EIS检查联系人的业务存在状态，以确定联系人当前是否可以接收任何 呼叫，这已经是如同到来呼叫路由技术一样的标准功能。在一种实施方式中， 如果处理逻辑在方框603只找到一个匹配呼叫方的具有访问4又限的可用联系 人，则处理逻辑在方框407继续连接该联系人和呼叫方。否则，根据一种实 施方式，如果在方框603找到多于一个可用联系人或没有识别出联系人，则 处理逻辑执行如同图4的方框409的搜索。
图7为流程图，示出了根据本发明的一种实施方式的用于将呼叫路由到 适当的用户的呼叫历史搜索过程。过程700可以执行与图4的方框409类似 的功能。在一种实施方式中，处理逻辑检索与在方框701接收到的呼叫的电 话号码或SIP地址相关联的呼叫历史。处理逻辑可以向转发该呼叫的电话应 用发送请求以检索呼叫历史。呼叫历史可以包括多于一个与呼叫相关联的呼 叫记录。被检索呼叫记录中的呼叫方或被叫方可以基于电话号码或SIP地址 与该呼叫相关联。呼叫记录可以包括相应呼叫的开始时间和/或持续时间。
在一种实施方式中，在方框703，处理逻辑搜索检索的呼叫历史以识别 企业实体中的可用联系人，所述可用联系人与来自通信交互历史数据库的至 少一个呼叫记录相关联。如果在方框703只找到一个匹配的联系人，则处理 逻辑可以继续连接呼叫方与在图4的方框407 #:匹配的单个耳关系人。如果该 联系人与通信交互历史数据库中的至少 一个呼叫记录相关联，该联系人基于 EIS具有对呼叫方的用户简档的访问权限，和/或根据EIS的业务存在该联系 人当前可以接收呼叫，则联系人可以#1匹配。如果在方框703匹配得到多于 一个联系人或者没有匹配的联系人，则根据一种实施方式，处理逻辑继续在 方框411执行最终联系人选择。
图8为流程图，示出了根据本发明的一种实施方式的用于将呼叫路由到 适当的联系人的最终选择过程。过程800可以执行与图4的方框411类似的
功能。在一种实施方式中，处理逻辑根据在图7的方框703的搜索对匹配的 联系人的数量进行计数。在一种实施方式中，该数量可以大于1。在另一种 实施方式中，该数量可以为零，例如当没有识别出联系人时。如果识别出多 于 一 个联系人，处理逻辑在方框805可以从识别出的联系人中选择一 个耳关系 人。在一种实施方式中，选择可以基于EIS中预定义规则中的一組标准。与 联系人相关联的标准可以包括基于呼叫历史在呼叫方和联系人之间发起/接 收呼叫的频率，在呼叫方和联系人之间上一次进行呼叫的时间，或者与耳关系 人相关联的当前服务队列的参数，例如当天应答呼叫的个数，等待应答的呼 叫个数，和/或从完成前一个呼叫以来的时间长度。在一种实施方式中，预定 义的规则组包括选择在联系人和呼叫方之间发起/接收呼叫频率最高的联系 人。在另一种实施方式中，预定义的规则组包括选择与呼叫方具有最近呼叫 的联系人。重新定义的规则之一可以确定与最短当前呼叫等待队列相关联的 耳关系人。在图4的方框407，在一种实施方式中，处理逻辑连4妄呼叫方与在 方框805选才奪的联系人。
在一种实施方式中，如果在图3的方框703的搜索过程中没有找到联系 人，则处理逻辑在方框803根据一组默认选择规则选择联系人来接收呼叫。 在一种实施方式中，由于在EIS中缺少呼叫方的身份，因此处理逻辑在方框 803不能找到任何联系人来接收呼叫。在另一种实施方式中，由于缺少联系 人访问权限与呼叫方的用户简档信息之间的匹配，因而处理逻辑无法在方框 803找到任何联系人来接收呼叫。在一种实施方式中，所述一组默认选择规 则基于默认的选择标准，例如与联系人相关联的业务角色。根据EIS中IAM 框架的MOM&职责，业务角色可以与企业实体内联系人所关联的职位相关， 例如接线员或经理等。在一种实施方式中，默认选择规则包括指定一个接线 员作为联系人来接收呼叫。在另一种实施方式中，默认选择规则包括指定一 个负责所有业务伙伴服务的经理来接收呼叫。在一种实施方式中，在图4的 方框407,处理还辑将呼叫方与在方框803选择的联系人相连接。
图9是数字处理系统的框图，该数字处理系统可以与本发明的一种实施 方式一起4吏用。例如，系统900可以用作以上参照图1描述的客户端和/或月良 务器。注意，尽管图9示出了计算机系统的不同組件，但是其并不是想要代 表互连所述组件的任何具体体系结构或方式；因为这些细节与本发明并非密 切相关。应当会理解到，网络计算机、手持计算机、蜂窝电话和其它具有较
少或可能更多组件的数据处理系统都可以与本发明 一起使用。
如图9所示，作为数据处理系统的一种形式的系统900包括总线或互连 线卯2，其连接到 一个或多个微处理器903和ROM 907、易失性RAM 905和 非易失性存储器906。微处理器903可以是例如PowerPC微处理器或Intel兼 容处理器，如图9的例子所示，其连接到高速緩冲存储器904。总线902将 这些不同的组件相互连_|妄在一起，并且还将这些组件903、 907、 905和906 与显示控制器和显示设备908、以及输入/输出(I/O)设备910相互连接，所 述I/O设备910可以是鼠标、键盘、调制解调器、网络接口、打印机和本领 域公知的其它设备。
典型地，输入/输出设备910通过输入/输出控制器909连接到系统。易失 性RAM 905 ^皮典型地实现为动态RAM (DRAM)，其要求持续的电源，以便 刷新或维持存储器中的数据。非易失性存储器卯6典型地为磁性硬盘驱动器， 磁光驱动器、光驱动器或DVD RAM或即使在从系统去除电源之后仍能维持 数据的其它类型的存储器系统。典型地，非易失性存储器也可以是随机存取 存储器，尽管并不要求如此。
尽管图9示出了非易失性存储器为直接连接到数据处理系统中的其它组 件的本地设备，但是，本发明也可以利用远离系统的非易失性存储器。例如， 通过诸如调制解调器或以太网口的网络接口连接到数据处理系统的网络存储 设备。总线902可以包括通过各种桥、控制器和/或适配器彼此连接的一个或 多个总线，如本领域中公知的那样。在一种实施方式中，1/0控制器卯9包括 用于控制USB (通用串行总线)外围设备的USB适配器。或者，1/0控制器 909可以包括用于控制Fire Wire设备的IEEE-1394适配器，其也称为Fire Wire 适配器。
EIS和ERP系统概述
可以用于上文描述的本发明的实施方式的EIS —般指任何类型的"企业 级"的计算系统。这意味着典型地提供高质量的服务，处理大量数据(例如， 能够支持一些相对大型的組织，也称为"企业")。
EIS系统提供技术平台，使得组织能够整合和协调其业务处理。它们在 逻辑上提供对组织来说是中枢的单个系统，并且确保信息能够在所有功能级 和管理层次之间共享。通过创建标准的数据结构，企业系统在消除由组织中 多个信息系统引起的信息碎片化问题方面的价值无法估量。
典型地，EIS会由专业的系统管理员操作，并且部署在专用的服务器上。
它典型地提供网络连接，并提供服务，以支持企业所执行的操作。例如，EIS 可以包括企业资源规划(ERP)系统。ERP系统将组织的大多数或所有数据 和处理整合(或试图整合)成逻辑上统一的系统。典型的ERP系统使用计算 机软件和/或硬件的多个组件来实现整合。大多数ERP系统的关键要素是使用 逻辑上单一的、统一的数据库来保存各种系统模块的数据，尽管该数据库或 数据可以本地管理或通过网络远程管理。
术语ERP最初是指被设计成规划企业范围的资源利用的系统。尽管首字 母缩写词ERP起源于制造界，但今天术语ERP系统具有宽得多的使用范围。 ERP系统典型地试图覆盖組织的所有基本功能，而不管组织的业务或规章如 何。商业、非营利組织、非政府组织、政府和其它大型实体都使用ERP系统。
另外，可能会注意到，在被视为ERP系统时，包(package)(可以包括 软件、硬件或两者的组合) 一般只需要在单个包中提供功能性，而这通常由 两个或更多系统覆盖。技术上，认为^是供工资单和帐目管理这两项功能的包 是ERP包。
然而，该术语一般被保留给更大、基础更广的应用。引入ERP系统以取 代两个或更多个独立应用消除或减少了对于以前系统之间要求的外部^妻口的 需要，并且提供了额外的好处，其范围从标准化和低成本维护(一个系统而 非两个或更多)到更容易和/或更强大的报告能力(因为所有数据典型地在逻 辑上保存在一个数据库中)。
ERP中的以前曾经是孤立应用的模块的示例包括但不局限于制造、供应 链、财务、CRM (客户关系管理)、人力资源和仓库管理等。ERP是交叉功 能和企业范围的。操作或生产中涉及的所有部门整合在一个系统中(逻辑上)。 除了制造、仓储、后勤和信息技术(IT)以外，它还包括财会、人力资源、 营销和战略管理。
最佳方法(best practice)也是实现ERP系统的好处。当实现ERP系统 时，组织本质上要进行选择，即，定制软件，或者将其业务处理修改成软件 普通版中提供的"最佳方法"功能。 一些人将最佳方法当作商业时髦用语， 用来描述开发和遵循做事情的标准方式的处理，所述标准方式多个组织都可 以使用以用于管理、策略、特别是软件系统。
MOM企业模型包含扩展的企业的所有组织结构，即，与組织公司本身
及其合作伙伴相关的所有内部结构，这些都被无缝地整合到业务处理中。
MOM企业模型还根据企业需要提供根据那些组织结构的示图(view) 。 MOM 企业结构是特定公司中MOM企业模型的实例。
MOM企业模型的主要組成部分为(i)具有其业务特性的结构单元，(ii) 形成层级的关系，(iii)职位，(iv)属性和继承，(v)区域，(vi)职责，(vii) 模板和示图，以及(viii)业务约束。所有这些实体和特性都可以依赖于时间 (time-dependently) 进行维护。
(i) 结构单元，如图10所示，为MOM企业模型的基本构造块。在法 律结构中它们代表不同的法律实体，在货币相关结构中它们是利润中心或成 本中心层中的节点，在汇报线结构中它们代表区域(division)、部门、团队 等。
取决于结构单元在公司中代表什么而具有一定的业务特性，例如"汇报 线单元"、"成本中心"、"利润中心"或"位置"。我们预期结构单元常常具有 多于一个业务特性。
(ii) 结构单元通过不同类型的关系链4^以形成組织结构的可选层级，如 图11所示。 一种标准关系类型形成公司的标准层级，尽管还存在专门的关系 类型，例如"法律上属于"、"财务上属于"和"汇报给"。所有评价的关键逻 辑是遵循标准关系类型，除非存在被维护的专门关系类型以用于与讨论中的 评价相关的层次。
(iii) 为了能够在结构单元上进行规划，人员不是直接连接到结构单元。 而是将代表计划的或现有的所有人的职位链接到结构单元。这使用不同的关 系类型实现，例如，"为……工作"指其所有人为结构单元工作的职位，"汇 报给"指其所有人向结构单元的经理汇报的职位。所有人代表占有一个职位的人。
(iv) 结构单元和职位具有属性，它包含各实体的性质。是否允许一个 结构单元具有特定的属性取决于该结构单元具有的业务特性。职位和人员也 有其它的属性組。属性可以继承。对于每个属性，定义了是否和如何继承以 及哪个关系类型用于继承。
(v) 区域可以被看作结构单元组，用来在层级结构范围内对实体分組。 例如，采购条件和过程可以在公司组内相同，尽管在结构单元之间没有直接 的层级关系。(vi) 职责描述由一个职位或结构单元通过要执行的行为和执行行为的 上下文必须完成的工作。典型地，所述上下文包含对象，例如结构单元(例 如，负责采购团队的领班)、产品(例如，负责某个产品的销售团队)和业务 伙伴(例如，负责所有供应商的某个子集的采购团队)。
(vii) 当设置MOM企业结构时，公司遵循模式。为了支持这一点，客 户可以通过选择指定的业务特性和默认属性值列表来为他们企业中的典型结 构单元定义模板。然后，他们可以基于这些模板创建结构单元。
作为一个示例，如图12所示，分支机构可以典型地具有下列业务特性 利润中心、汇报线单元、位置和装运点。
企业结构的维护通过示图(views)实现。所述示图根据公司的要求和维 护企业结构的用户角色提供企业结构的规划。
(viii) 应用必须能够限制在MOM企业模型中允许用户进入哪些以及允 许他们改变哪些。为了这个目的，MOM企业模型包含业务约束的积无念，其 中各应用可以检查企业结构中的变化是否一致以及是否符合它们的业务规 则。典型的约束可以是陈述每个成本中心必须分配给一个法律实体、已经使 用的对象不允许删除(例如，已经在会计凭证中使用的成本中心)、或者过去 的重要属性或关系不能改变(例如，改变去年l月的通货)的规则。
人力资源是最佳方法的一个好示例，如在大多数MOM系统中所证明的 那样。在管理組织的雇员、志愿者和合同工中涉及无数的方式和大量的处理。 通过选择组织和执行处理的"最佳方法"或标准方式，MOM系统或HRMS (人力资源管理系统)软件的制作者能够创造可以由多个组织使用的系统。
在本上下文中，最佳方法实现方式的好处往往在于，为流程设计(或者 更恰当的说是演进)欠佳的组织提供以下选择对其系统进行(一般来说) 昂贵的修改，或者选择遵循最佳方法。最佳方法随时间的变化是ERP系统生 命周期的主要动力。许多主要软件的发布都是在业内最佳方法的变化或引入 下推进的。上世纪巨大的技术变化速度推动了快速适应和多样的最佳方法。
上文所描述的 一部分可以通过诸如专用逻辑电路的逻辑电路，或通过微 控制器或执行程序代码指令的其它形式的处理核来实现。因而，上述讨论所 教导的处理可以通过程序代码来执行，所述程序代码例如机器可执行指令， 其导致执行这些指令的机器来执行特定的功能。在本上下文中，"机器"可以 是把中间形式(或"抽象")指令转换成处理器特定指令(例如，诸如"虛拟
机"(例如，Java虚拟机)的抽象执行环境、翻^奪器、Common Language Runtime、高级语言虚拟机等)的机器，和/或布置在半导体芯片(例如，用 晶体管实现的"逻辑电路")上用于执行指令的电子电路，例如通用处理器和 /或专用处理器。上述讨论教导的处理也可以由设计成执行处理(或其一部分) 而不执行程序代码的电子电路(替代机器或与机器结合)来执行。
相信，上文的讨论教导的处理也可以用由各种软件开发框架(例如，微 软公司的.NET、 Mono、 Java、甲骨文公司的Fusion等)支持的各种面向对象 或非面向对象的计算机编程i吾言(例如，Java、 C#、 VB、 Python、 C、 C++、 J#、 APL、 Cobol、 ABAP、 Fortran、 Pascal、 Perl等)的源程序代码来描述。 源程序代码可以转换成抽象执行环境(例如，Java虚拟机、Common Language Runtime、高级语言虚拟机、翻i奪器等)可以理解的中间形式程序代码(例如 Java字节代码、微软中间语言等)，或者针对特定处理器的更特定形式的程序 代码。
前面详细描述中的 一 些部分以对计算机存储器内数据比特操作的算法和 符号表现形式呈现。这些算法的描述和表现形式是数据处理领域的技术人员
式。在这里， 一般来讲，算法被认为是带来期望结果的前后一致的操作序列。 操作是指那些要求对物理量的物理处理的操作。通常，尽管不是必须的，这 些量采用能够被保存、传输、組合、比较以及以其它方式处理的电或磁信号 的形式。已经证明，有时称这些信号为比特、值、元素、符号、字符、术语、 数字等很方便，主要是由于通用的原因。
然而，应该记住，所有这些和类似术语都与适当的物理量相关联，并且 只是适用于这些量的方便标志。除非特别说明，否则如才艮据上文的讨论显而 易见地，应当理解，贯穿说明书，使用诸如"处理"或"计算"或"确定" 或"显示"等术语的讨论，是指计算机系统和类似的电子计算设备的动作和 处理，所述计算机系统或类似的电子设备将计算机系统的寄存器和存储器内 表示为物理(电子)量的数据处理和转换成计算机系统存储器或寄存器或其 它这样的信息存储、传输或显示设备内类似地表示为物理量的其它数据。
这里，本发明的实施方式还涉及一种用于执行操作的装置。该装置可以 为要求的目的特殊构造，或者它可以包括由保存在计算机中的计算机程序选 择性激活或重配置的通用计算机。这样的计算机程序可以保存在计算机可读
存储介质中，例如但不局限于任何类型的盘，包括软盘、光盘、CD-ROM、 磁光盘、只读存储器(ROM)、随机存取存储器(RAM)、可擦除可编程ROM (EPROM)、电可擦除可编程ROM (EEPROM)、磁或光卡或适于保存电子 指令并且分别连接到计算机系统总线的任何类型的介质。
这里提供的算法和显示并非固有地与任何特定计算机或其它装置相关。 根据这里的教导，各种通用系统都可以与程序一起使用，或者可以证明构建 更专门的设备来执行要求的方法操作很便利。从以下的描述中将出现这些各 种系统所要求的结构。另外，本发明的实施方式并非参考任何特定的编程语 言来描述的。可以理解，各种编程语言都可以用来实现这里描述的本发明实 施方式的教导。
机器可读介质可以包括用于以机器(例如计算机)可读的形式保存或传 输信息的任何介质。例如，机器可读介质包括只读存储器("ROM");随机 存取存储器("RAM");磁盘存储介质；光存储介质；闪存设备；电、光、 声或其它形式的传播信号(例如，载波、红外信号、数字信号等)等。
施例进行了描述。4艮显然，可以对本发明实施方式进行各种修改，而不会脱 离所附权利要求书中阐述的本发明的更宽的精神和范围。因此，说明书和附 图仅仅被认为是示例性的，而不是限制性的。
权利要求
1、一种机器实现的方法，包括响应于经由网络来自发送方的消息，考虑发送方，基于候选接收方在组织内的角色，识别处理该消息的候选接收方的列表；和将消息转发给从该候选接收方列表中选择的接收方，以使得所选择的接收方能够处理该消息。
2、 权利要求l中的方法，还包括基于消息确定发送方简档，其中进一步 基于发送方简档识别候选接收方。
3、 权利要求2中的方法，还包括基于发送方简档生成与发送方相关联的 上下文，该上下文将与所述消息一起转发给接收方。
4、 权利要求3中的方法，还包括基于发送方和组织之间的、由候选接收 方处理的一个或更多以前的事务，确定发送方和候选接收方之间的关系。
5、 权利要求4中的方法，还包括考虑组织和从发送方简档中提取的发送 方信息之间的关系，创建表示候选接收方的角色的角色地图，其中所选择的 接收方是基于该角色地图所表示的优先级选择的。
6、 权利要求5中的方法，还包括根据基于不同区域服务覆盖的候选接收 方在组织内的职责，从候选接收方中识别一个或更多负责用户。
7、 权利要求6中的方法，还包括如果存在多于一个的识别出的负责用户， 则基于以前与发送方的联系，从识别出的负责用户中选择一个或更多用户。
8、 权利要求7中的方法，还包括从识别出的以前与发送方有联系的负责 用户中选择一个用户作为最终接收方，其中所选择的用户是与发送方联系最 频繁的用户。
9、 权利要求7中的方法，还包括如果不存在以前与发送方有联系的负责 用户，则从识别出的负责用户中选择一个用户作为最终接收方，该最终接收 方具有最高等级的工作成绩。
10、 一种机器可读介质，其中具有指令，当指令由机器执行时，使机器 执4亍一种方法，该方法包括响应于经由网络来自发送方的消息，考虑发送方，基于候选接收方在组 织内的角色，识别处理该消息的候选接收方的列表；和将消息转发给从该候选接收方列表中选择的接收方，以使得所选择的接收方能够处理该消息。
11、 权利要求io中的机器可读介质，其中所述方法还包括基于所述消息 确定发送方简档，其中进一步基于该发送方简档识别候选接收方。
12、 权利要求ll中的机器可读介质，其中所述方法还包括基于发送方简 档生成与发送方相关联的上下文，该上下文将与消息一起转发给接收方。
13、 权利要求12中的机器可读介质，其中所述方法还包括基于发送方和 组织之间的、由候选接收方处理的一个或更多以前的事务，确定发送方和候 选接收方之间的关系。
14、 权利要求13中的机器可读介质，其中所述方法还包括考虑组织和从 发送方简档中提取的发送方信息之间的关系，创建表示候选接收方角色的角 色地图，其中所选择的接收方是基于该角色地图所表示的优先级来选择的。
15、 权利要求14中的机器可读介质，其中所述方法还包括根据基于不同 区域服务覆盖的、候选接收方在组织内的职责，从候选接收方中识别出一个 或更多负责用户。
16、 权利要求15中的机器可读介质，其中所述方法还包括如果存在多于 一个的识别出的负责用户，则基于以前与发送方的联系，从识别出的负责用 户中选4奪一个或更多用户。
17、 权利要求16中的机器可读介质，其中所述方法还包括从所识别出的 以前与发送方有联系的负责用户中选择一个用户作为最终接收方，其中所选 择的用户是与发送方联系最频繁的用户。
18、 权利要求17中的机器可读介质，其中所述方法还包括如果不存在以 前与发送方有联系的负责用户，则从识别出的负责用户中选择一个用户作为 最终接收方，该最终接收方具有最高等级的工作成绩。
19、 一种数据处理系统，包括搜索引擎，其响应于经由网络来自发送方的消息，考虑发送方，基于候 选接收方在組织内的角色，识别处理该消息的候选接收方的列表；和转发引擎，其连接到搜索引擎，用以将消息转发给从该候选接收方列表 中选择的接收方，从而使;波选择的接收方能够处理该消息。
20、 权利要求19中的系统，还包括连接到所述搜索引擎的面向发送方的 数据库，其中该搜索引擎被配置成访问该面向发送方的数据库，以基于所述 消息确定发送方简档，其中进一 步基于发送方简档来识别所述候选接收方。
全文摘要
这里描述了用于基于发送方和接收方之间的关系转发消息的技术。在一种实施方式中，过程包括但不局限于，响应于经由网络来自发送方的消息，考虑发送方，基于候选接收方在组织内的角色，识别处理该消息的候选接收方的列表；和将消息转发给从该候选接收方列表中选择的接收方，以使得所选择的接收方能够处理该消息。还描述了其它方法和装置。
文档编号H04Q3/00GK101207838SQ200710196769
公开日2008年6月25日 申请日期2007年12月6日 优先权日2006年12月6日
发明者埃克哈德·法伦科普夫, 安德烈·艾科霍斯特, 天 徐, 德克·萨格尔 申请人:Sap股份公司