BRPI0901505A2 - dados de aplicativo de central de atendimento (call center) e arquitetura de interoperação para uma central de serviços de telecomunicação - Google Patents

Abstract

DADOS DE APLICATIVO DE CENTRAL DE ATENDIMENTO (CALL CENTER) E ARQUITETURA DE INTEROPERAçãO PARAUMA CENTRAL DE SERVIçOS DE TELECOMUNICAçãO. A presente invenção refere-se a uma arquitetura de dados de aplicativo de central de atendimento e interoperação provê um projeto centralizado para gerenciamento de aplicativos provendo uma funcionalidade decentral de atendimento. A arquitetura integra um fluxo de informação usando um depósito de dados mestres para todos os aplicativos para todos os aspectos de uma operação de central de atendimento. A arquitetura provê uma informação de empregado em níveis definidos através do ciclo de vida deemprego completo, incluindo a contratação inicial e a rescisão. A arquitetur provê a informação de empregado pela integração de uma informação de recursos humanos com aplicativos de central de atendimento, tais como comparecimento de empregado e gerenciamento de leave, gerenciamento de ID, gerenciamento de transporte, registros de compromisso e gerenciamento demovimento, ou qualquer outro aplicativo.

Description

Relatório Descritivo da Patente de Invenção para "DADOS DEAPLICATIVO DE CENTRAL DE ATENDIMENTO (CALL CENTER) E ARQUI-TETURA DE INTEROPERAÇÃO PARA UMA CENTRAL DE SERVIÇOSDE TELECOMUNICAÇÃO".

ANTECEDENTES

1. Referência Cruzada a Pedidos Relacionados

Este pedido reivindica o benefício de prioridade para o Pedidode Patente Indiano Ng de Série 73/MUM/2008, depositado em 9 de janeirode 2008.

2. Campo Técnico

Este pedido se refere a sistemas de processamento de dados e,em particular, a uma arquitetura de sistema de central de atendimento.

3. Técnica Relacionada

O crescimento rápido da tecnologia de informação levou a pro-dutos e serviços crescentemente complexos. Em um esforço para proverassistência significativa a consumidores, as companhias fizeram investimen-tos significativos em centrais de atendimento. As metas primárias de umacentral de atendimento incluem trabalhar com consumidores para resoluçãode questões, responder a perguntas e prover um suporte contínuo para pro-dutos e serviços.

Apesar do nível geral de sofisticação de uma central de atendi-mento moderna, os desafios ainda persistem. Em particular, muitas áreasainda estão propensas a erros e sofrem da necessidade de realização detrabalho manual repetitivo para a realização de tarefas. Além disso, os dadosde central de atendimento freqüentemente eram gerenciados de maneiracaótica, levando a redundância de dados e perda de dados. Ao mesmo tem-po, uma manipulação de dados for frenética e requerida a um nível alto dehabilidade mesmo para uma manutenção de rotina. Estes inconvenienteslimitaram a capacidade da central de atendimento prover relatórios tempesti-vos, acurados e automatizados; tornar seguros os dados; e prover um ras-treamento de dados em tempo real.

Existe uma necessidade de uma arquitetura melhorada de pedidode central de atendimento.

SUMÁRIO

-Uma-arquitetura de dados de aplicativo de central de atendimen-to e interoperação ("arquitetura") provê um projeto centralizado para o ge-renciamento de muitos aplicativos que cooperam para a provisão de umafuncionalidade de central de atendimento. A arquitetura coordena um fluxode informação através de um depósito de dados de aplicativo mestres e pro-vê um suporte talhado para aplicativos que lidam com todos os aspectos deuma funcionalidade de central de atendimento. A arquitetura de forma hábillida com um fluxo de informação para todos os aplicativos de central de a-tendimento e para os empregados que usam os aplicativos, incluindo geren-tes, supervisores e operadores de chamada.

Os aplicativos implementam uma funcionalidade aplicável atra-vés do vão completo do ciclo de emprego a partir da contratação até a resci-são, e bem como outras funções de suporte. Os aplicativos podem imple-mentar uma funcionalidade incluindo funções de recursos humanos, acom-panhamento de presença de empregado e gerenciamento de redução deefetivo de empregado. Outros exemplos de funcionalidade de aplicativo in-cluem gerenciamento de Ieave de empregado, registro de compromisso deempregado e gerenciamento de identificação. Os aplicativos não estão limi-tados a aplicativos específicos de voz (por exemplo, resolução de problemabaseada em teleconferência), mas também envolvem processos não de voz(por exemplo, processamento de pedido baseado em e-mail ou Internet).

A arquitetura pode ser implementada em uma ferramenta base-ada em rede que provê melhoramentos significativos com respeito a proces-sos de trabalho intenso e desafios de integridade de dados descritos acima.

A rede pode incluir redes locais e remotas, ou interconexões de redes, sejamprivadas e internas ou acessíveis publicamente. A rede pode incluir uma co-nectividade baseada em Internet para acesso local ou remoto aos aplicativose aos dados armazenados no depósito de dados de aplicativo mestres. Alémdisso, a arquitetura provê visibilidade e colaboração através da central deatendimento e seus aplicativos.O ambiente dinâmico de uma central de atendimento significaque recursos, tais como empregados ou um equipamento de central de a-tendimentorsão movidos-através de processos muito-frequentemente. Umprocesso pode ser qualquer instância de uma funcionalidade de central deatendimento, tais como questionários técnicos de campo de partes chaman-do sobre produtos específicos, ativação de produtos e serviços, ou feitura econfirmação de pedidos por produtos ou serviços. A variedade ampla deprocessos e movimento de recurso freqüente através de processos dá ori-gem a uma necessidade de acompanhamento dos recursos de uma maneirasistemática. Nesse sentido, a arquitetura facilita, por exemplo, o acompa-nhamento de processos nos quais qualquer operador de chamada ou super-visor trabalhou durante sua permanência junto à central de atendimento. Aarquitetura também pode acompanhar outros detalhes relevantes, tal como aduração do operador de chamada em cada processo, supervisores subse-quentes e dados de desempenho e outros detalhes.

Além disso, a arquitetura acompanha uma informação sobre ca-da empregado no sistema. A arquitetura pode acompanhar uma informaçãosobre cada empregado em todo nível de hierarquia definido. A hierarquiapode refletir a posição relativa ou posto, tal como gerente -> supervisor ->operador de chamada, com a arquitetura mantendo uma informação sobrecada empregado em cada nível da hierarquia. A arquitetura também suporta,em cada nível definido na hierarquia, direitos de acesso individuais específi-cos para todos os empregados. Os direitos de acesso podem ser reguladosdependendo do nível de empregado na hierarquia, do processo ao qual oempregado pertence e de outros fatores.

Conforme citado acima, a arquitetura inclui um depósito de da-dos de aplicativo mestres. Em uma implementação, o depósito de dados deaplicativo mestres adere a um esquema de organização de dados mestres.O esquema de organização de dados mestres é unificado através de múlti-pias exigências de conjunto de dados de aplicativo de central de atendimen-to pelo fato de o esquema de dados mestres lidar com todo o fluxo de infor-mação gerado pelos aplicativos de central de atendimento. O esquema deorganização de dados mestres é dividido ao longo de uma subdivisão deesquema que define múltiplos esquemas de dados de aplicativo que sãoespecíficos para exigências de um conjunto de dados de aplicativo individualpara diferentes aplicativos de central de atendimento.

Uma interface de comunicação recebe requisições de dados deaplicativo de central de atendimento a partir dos aplicativos de central deatendimento. Um processador e um software de suporte (por exemplo, umsoftware de gerenciamento de banco de dados) processam as requisiçõesde dados de aplicativo de central de atendimento. Em particular, o processa-dor realiza uma manipulação de dados em resposta às requisições de dadosde aplicativo de central de atendimento, enquanto trabalha com o esquemade dados de aplicativo específico no depósito de dados de aplicativo mes-tres. A manipulação de dados pode incluir a adição, o apagamento ou a mu-dança de campos de dados em uma base por aplicativo, tal como a adiçãode registros de presença de empregado em uma base diária, a mudança deprocessos para os quais um empregado é atribuído, ou o apagamento decompromissos completados a partir de uma lista de exigências de compro-misso, quando o empregado tiver cumprido o compromisso. A arquiteturadesse modo libera os aplicativos de central de atendimento de um tempopara execução de banco de dados local e de processamento.

Outros sistemas, métodos, recursos e vantagens serão ou setornarão evidentes para alguém versado na técnica, mediante um examedas figuras a seguir e da descrição detalhada. Pretende-se que todos essessistemas, métodos, recursos e vantagens adicionais sejam incluídos nestadescrição, estejam no escopo da invenção e sejam protegidos pelas reivindi-cações a seguir.

BREVE DESCRIÇÃO DOS DESENHOS

A inovação será mais bem entendida com referência aos dese-nhos e à descrição a seguir. Os componentes nas figuras não estão neces-sariamente em escala, a ênfase sendo imposta, ao invés disso, na ilustraçãodos princípios da invenção. Além disso, nas figuras, números referenciadosiguais designam as partes correspondentes por todas as várias vistas.A figura 1 mostra uma arquitetura de dados de aplicativo e deinteroperação de central de atendimento.

A figura-2-mostra uma arquitetura de dados de aplicativo e deinteroperação de central de atendimento incluindo uma subdivisão de es-quema definindo múltiplos esquemas de dados de aplicativo individuais paraaplicativos específicos.

A figura 3 mostra uma porção de um esquema de dados de apli-cativo que implementa uma exigência de conjunto de dados compartilhadoscomum a múltiplos aplicativos de central de atendimento.

A figura 4 mostra um esquema de dados de aplicativo de CaseManagement (Gerenciamento de Caso).

A figura 5 mostra um esquema de dados de aplicativo de CaseManagement.

A figura 6 mostra um esquema de dados de aplicativo de CaseManagement.

A figura 7 mostra um esquema de dados de aplicativo de CaseManagement.

A figura 8 mostra um esquema de dados de aplicativo de Leave(Leave).

A figura 9 mostra um esquema de dados de aplicativo de Leave.

A figura 10 mostra um esquema de dados de aplicativo deCommitment Log (Registro de Compromisso).

A figura 11 mostra um esquema de dados de aplicativo de At-tendance (Presença).

A figura 12 mostra um esquema de dados de aplicativo de Mo-vement (Movimento).

A figura 13 mostra um esquema de dados de aplicativo de Attri-tion (Redução de Efetivo).

As figuras 14 a 34 mostram exemplos de interfaces gráficas deusuário (GUIs) e relatórios que um aplicativo de recursos humanos pode im-plementar.

As figuras 35 a 48 mostram exemplos de GUIs e relatórios que oaplicativo de redução de efetivo pode implementar.

As figuras 49 a 56 mostram exemplos de GUIs e relatórios que oaplicativo de registro de compromisso pode implementar.

As figuras 57 a 65 mostram exemplos de GUIs e relatórios que oaplicativo de Ieave pode implementar.

As figuras 66 a 71 mostram exemplos de GUIs e relatórios que oaplicativo de presença pode implementar.

As figuras 72 a 87 mostram exemplos de GUIs e relatórios que oaplicativo My OneView pode implementar.

As figuras 88 a 95 mostram exemplos de GUIs e relatórios que oaplicativo de transporte pode implementar.

As figuras 96 a 109 mostram exemplos de GUIs e relatórios queo aplicativo de gerenciamento de caso pode implementar.

As figuras 110 a 112 mostram exemplos de GUIs e relatóriosque o aplicativo de gerenciamento de ID pode implementar.

As figuras 113 a 117 mostram exemplos de GUIs e relatóriosque o aplicativo de movimento pode implementar.

A figura 118 mostra um exemplo de fluxo lógico para coordena-ção da operação de múltiplos aplicativos de central de atendimento em umaarquitetura de central de atendimento.

A figura 119 mostra um exemplo de fluxo lógico para a autenti-cação de um usuário.

A figura 120 mostra um exemplo de interface gráfica de usuárioque exibe uma lista de verificação para um usuário enquanto o usuário estáfazendo uma chamada.

DESCRIÇÃO DETALHADA

A figura 1 mostra uma arquitetura de aplicativo de central de a-tendimento e interoperação 100 ("arquitetura 100"). A arquitetura 100 provêuma visão consistente e tempestiva de registros chaves e melhora o desem-penho individual ao fortalecer os agentes com sua própria informação. A ar-quitetura 100 também provê a capacidade de treinar a partir de painéis emrelatórios analíticos e detalhados, históricos e em tempo real, para uma aná-lise de causa primária. Um depósito central de todos os eventos na organi-zação provê um armazenamento de dados acurado, tempestivo e seguro.

Em particular o depósito central pode ser implementado comoum depósito de dados de aplicativo mestres 102. No depósito de dados deaplicativo mestres 102, os dados são organizados de acordo com um es-quema de organização de dados mestres 104. O esquema de organizaçãode dados mestres 104 será descrito em maiores detalhes abaixo.

A arquitetura 100 coordena o processamento de múltiplos aplica-tivos de central de atendimento e suas interações com o depósito de dadosde aplicativo mestres 102. Os exemplos de aplicativos mostrados na figura 1incluem um aplicativo de Case Management application, tendo três parteslógicas: um aplicativo de Accounts Integrity Management (Gerenciamento deIntegridade de Contas) ("AIM") 106, um aplicativo de processamento de pe-dido on-line ("ΚΑΝΑ") 108, e um aplicativo de Sales Order Entry (Entrada dePedido de Vendas) (SOE) application 110. O aplicativo de AIM 106 podeprover, por exemplo, uma GUI e uma lógica de processamento para proces-samento de pedidos pela web on-line. O aplicativo de SOE 110 pode proveruma GUI e uma lógica de processamento para processamento de pedidos portelefone. Assim, uma vez que um consumidor assine por telefone, a equipe deSOE carrega o pedido no sistema através do aplicativo de SOE 110.

Outros exemplos de aplicativos incluem o aplicativo de Commit-ment Log 112, o aplicativo de Attrition 114, o aplicativo de Identification Ma-nagement 116, o aplicativo de Employee Details 118, e o aplicativo de Leave120. Os exemplos adicionais de aplicativos incluem o aplicativo de Atten-dance 122, o aplicativo de Transport 124, o aplicativo de Movement Mana-gement 126, o aplicativo de recursos humanos (HRIS) 128.

A arquitetura 100 implementa um projeto de centro de conexão eraios. Os aplicativos 106 a 120 trocam dados com o depósito de dados deaplicativo mestres 102, o qual libera cada aplicativo individual de exigênciasde tempo de processamento de banco de dados e de processamento. Apli-cativos adicionais, diferentes ou a menos podem estar rodando na arquitetu-ra 100.A figura 1 também mostra que a arquitetura 100 provê um aces-so administrativo para a equipe de administração 130. A equipe de adminis--tração-130 pode-interagir com a arquitetura 100 através de uma interface deusuário através da qual os usuários autorizados podem atualizar dados depessoal mantidos pelo módulo de lista de plantão semanal 132, ou pode fa-zer outras mudanças em dados armazenados no depósito de dados de apli-cativo mestres 102. Além disso, uma equipe de programação 134 pode pro-ver uma entrada para o módulo de lista de plantão semanal 132. Assim sen-do, o módulo de lista de plantão semanal 132 mantém uma visão atualizadados empregados e suas programações atribuídas a qualquer processo emparticular para uma semana em particular. Além disso, um processo detransferência (via upload) 136 pode ser estabelecido para se transferirem(via upload) de forma manual ou automática os dados de presença para oaplicativo de presença 122.

As centrais de atendimento trabalham em turnos, e qualquerempregado pode ser programado para trabalhar em qualquer turno. A pro-gramação inclui seus dias de trabalho e dias livres semanais (seu tempo li-vre). A equipe de programação 134 prepara listas de plantão de empregadosem turnos com base em muitos parâmetros diferentes. A arquitetura 100 tor-na a lista de plantão disponível toda semana (por exemplo, em um formatode planilha do Excel (TM)). A equipe de administração 130 ou a equipe deprogramação 134 introduz semanalmente as listas de plantão de empregadona arquitetura 100 (por exemplo, no módulo de presença) através do pro-cesso de transferência (via upload) 136.

O processamento na arquitetura 100 pode ser alojado em umservidor da web de informação de internet (IIS). O processamento pode serimplementado, como exemplos, em C# e usando-se ASP.NET, com os da-dos armazenados em um banco de dados SQL 2000. Por exemplo, os ban-cos de dados e os esquemas de dados descritos acima podem ser imple-mentados com Microsoft® SQL Server 2000, Microsoft SQL Server versão7.0, ou outra tecnologia de servidor de banco de dados. O agente de bancode dados relacionai pode retornar dados tais como documentos em Lingua-gem de Marcação Extensível (XML). Adicionalmente, XML também pode serusada para a inserção, a atualização e o apagamento de valores no bancode dados.

Além disso, a arquitetura pode rodar múltiplas instâncias do a-gente de banco de dados relacionai na mesma máquina ou em uma diferen-te. Cada instância pode ter seu próprio conjunto de bancos de dados de sis-tema e de usuário. Os aplicativos podem conectar cada instância em umaúnica máquina similar à forma que eles se conectam a instâncias rodandoem máquinas diferentes.

Uma outra tecnologia que pode ser usada para a implementaçãoda arquitetura inclui JavaScript Assíncrona e XML (AJAX) para a criação deaplicativos da web interativos, XHMTL, para a transformação mais estrita,mais limpa de HTML em XML, Folhas de Estilo em Cascata (CSS) para mar-cação e adição de estilos, Modelo de Objeto de Documento em JavaScript(DOM) para a provisão de conteúdo, estrutura e estilo de um documento aser acessado e atualizado dinamicamente, e um objeto XMLHttpRequest, oqual troca dados de forma assíncrona com o servidor da web e reduz a ne-cessidade de se buscarem continuamente recursos a partir do servidor.

Uma vez que dados podem ser enviados e recuperados sem serequerer que o usuário recarregue uma página da web inteira, pequenasquantidades de dados podem ser transferidas como e quando requerido.Além disso, os elementos de página podem ser dinamicamente atualizadosem qualquer nível de granularidade para refletirem isto. Uma informação nãomudada não precisa ser enviada através da rede. A implementação pode serpadronizada em torno de 'Document Object Model (DOM) Levei 3 Load andSave Specification' do W3C ou de uma outra especificação.

Além dos aplicativos descritos acima, a arquitetura 100 podeprover uma funcionalidade adicional. Por exemplo, a arquitetura 100 podeprover um-aplicativo de acesso de informação de empregado 136 ("My One-View"). O aplicativo My OneView 136 pode ser acessado por qualquer em-pregado para rever o balanço de leave, as programações, as listas de feria-dos, e outros aspectos de emprego associado ao empregado. Os exemplosadicionais são descritos em maiores detalhes abaixo.

A figura 2 mostra uma outra vista dos dados de aplicativo decentral de atendimento e interoperação 100 incluindo uma subdivisão de es-quema 202 definindo múltiplos esquemas de dados de aplicativo individuais204 a 218 para aplicativos específicos. A subdivisão de esquema 202 podeser uma divisão lógica ou física de tabelas de banco de dados, campos eoutras estruturas em conjuntos de tabelas, campos ou outra informação es-pecífica para aplicativos de central de atendimento. Além disso, o esquemade organização de dados mestres 104 define um esquema de dados de apli-cativo comum 220. O esquema de dados de aplicativo comum 220 pode in-cluir campos, tabelas ou outras estruturas que múltiplos aplicativos usampara compartilhamento de dados ou ter acesso comum de modo a suporta-rem seus papéis de processamento.

Os exemplos de esquemas de dados de aplicativo individuais nafigura 2 incluem: um esquema de dados de AIM de Case Management 204,um esquema de dados de Commitment Log 206, um esquema de dados deKANA de Case Management 208 e um esquema de dados de Attrition 210.

Os exemplos adicionais incluem: um esquema de dados de Ieave 212, umesquema de dados de movimento 214, um esquema de dados de SOE de

Case Management 216 e um esquema de dados de presença 218. Os es-quemas de dados 204 a 218 mantêm os dados específicos para um aplicati-vo em particular. Mais especificamente, cada esquema de dados 204 a 218suporta uma exigência de conjunto de dados de aplicativo específica. Porexemplo, o esquema de dados de Attrition 210 inclui tabelas e campos paraa manutenção de quaisquer dados que o aplicativo de Attrition 114 manipula,envia, recebe, exibe ou processa de outra forma na realização de seu ge-renciamento de redução de efetivo, acompanhamento e relatório de papel. Asubdivisão 202 assegura uma separação limpa entre as exigências de con-junto de dados de cada um dos aplicativos de central de atendimento, aoinvés de espalhar todas as exigências de conjunto de dados através de umconjunto de tabelas e campos comuns a múltiplos aplicativos.

Os aplicativos individuais podem se comunicar com o restanteda arquitetura 10O por uma ou mais redes locais ou remotas ou pela interco-nexão dessas redes. Os aplicativos individuais podem submeter requisiçõesde dados, e receber respostas de dados da arquitetura 100, conforme elesrealizarem seu processamento. Para essa finalidade, a arquitetura 100 im-plementa uma interface de comunicação 222 e inclui um processador 224que pode receber as requisições de dados, processar as requisições de da-dos e retornar respostas de dados para os aplicativos individuais. Mais es-pecificamente, uma memória 226 pode armazenar uma lógica de processa-mento de requisição de dados 228, tal como um aplicativo de gerenciamentode banco de dados. A lógica de processamento de requisição de dados 228recebe requisições de dados (tal como a requisição de dados de presença230 e as requisições de dados de redução de efetivo 232). Em resposta, alógica de processamento de requisição de dados 228 processa as requisi-ções de dados pela realização de uma manipulação de dados (por exemplo,consultas em bancos de dados, ou leituras, escritas ou atualizações de ban-co de dados) em resposta às requisições de dados. A lógica de processa-mento de requisição de dados 228 adere aos esquemas de dados de aplica-tivo no depósito de dados de aplicativo mestres 102, de modo que esque-mas de dados de aplicativo específicos suportem um aplicativo de central deatendimento específico. Um resultado é que a arquitetura 100 libera os aplicati-vos de central de atendimento 106 a 128 de um tempo de processamento debanco de dados local, e provê um armazenamento e um controle centraliza-dos pelos dados de central de atendimento através de múltiplos aplicativos.

Os exemplos específicos de esquemas de dados de aplicativode central de atendimento são dados nas tabelas abaixo.As Tabelas 1 a 4 a seguir mostram um esquema de dados de apli-cativo de transporte que pode suportar o aplicativo de Transportation 124.

Tabela 1: ADHOCJbLRequestAction Esta tabela armazena informações sobre requisições de transporte adhoc.

<table>table see original document page 13</column></row><table>Tabela 2: ADHOC_tbl_RequestDetails Esta tabela descreve a ação feita em relação às requisições de transporte ad hoc. <table>table see original document page 14</column></row><table>Tabela 3: ADHOC_tbl_RequestHead A tabela armazena a informação quando um transporte ad hoc é requerido pelo emDreaado e auando é aprovado.

<table>table see original document page 15</column></row><table>Tabela 4: ADHOC_tbl_RequestMst A tabela contém o número de bilhete e uma outra informação relacionada sobre o empregado. <table>table see original document page 16</column></row><table>

As Tabelas 5 a 11 a seguir mostram um esquema de dados deCommitment Log 206 que pode suportar o aplicativo de Commitment Log112. A Figura 5 provê detalhes adicionais. Os níveis de carreira / organiza-cionais ali podem ser definidos de A a H, com A sendo o nível de topo. Porexemplo, as pessoas no nível E podem ser líderes de equipe, F pode ser deEspecialistas no Assunto e G & H podem ser membro de equipe / represen-tantes de atendimento ao consumidor tendo perfis e compromissos de traba-lho semelhantes.

Tabela 5: AGMJbLCommitmentLogMst (Tabela 1002) A tabela descreve o compromisso que o Líder de Equipe ("TL") e o Sub-gerente ΓϋΜΊ têm aue realizar.

<table>table see original document page 17</column></row><table>Tabela 6: AGM_tbl_CommitmentLogTarget (Tabela 1006) Meta a ser atinaida Delo supervisor.

<table>table see original document page 18</column></row><table>

Tabela 7: AGM_tbl_CommitmentLogTarget_History (Tabela 1008) A tabela descreve o histórico de metas de compromisso que foram feitas.

<table>table see original document page 18</column></row><table><table>table see original document page 19</column></row><table>

Tabela 8: AGM .CommitmentLogType (Tabela 1010) A tabela descreve o compromisso de TL e de DM.

<table>table see original document page 19</column></row><table><table>table see original document page 20</column></row><table>

Tabela 9: AGM_UserCommitment_Achieved (Tabela 1004) Fsta tahela descreve comDromissos atingidos.

<table>table see original document page 20</column></row><table>Tabela 10: AGM_tbl_UserCommitment_Schedule (Tabela 1014) A tabela descreve os compromissos que são programados para a semana.

<table>table see original document page 21</column></row><table>Tabela 11: AGM tbl_UserCommitment_Target (Tabela 1012) A tabela descreve as metas que devem ser atingidas

<table>table see original document page 22</column></row><table>

A Tabela 12 a seguir mostra os recursos humanos IS (HRIS) quepodem suportar a funcionalidade de lista de plantão de aplicativo de HRIS 128.

Tabela 12: HRIS_RPT_ViewRoster Esta tabela descreve o usuário que viu os dados.

<table>table see original document page 22</column></row><table><table>table see original document page 23</column></row><table>

As Tabelas 13 a 16 a seguir mostram o esquema de dados deAttendance 218 que pode suportar o aplicativo de presença 122. A Figura 11provê detalhes adicionais.

<table>table see original document page 23</column></row><table><table>table see original document page 24</column></row><table>

Tabela 14: HRIS_tbl_Attendance_Head (Tabela 1102) Esta tabela tem a informação sobre o Status de Empregado.

<table>table see original document page 24</column></row><table><table>table see original document page 25</column></row><table>

Tabela 15: HRIS_tbl_AttendanceJHistory Fsta tahela mntém o histórico da Dresenca do empregado.

<table>table see original document page 25</column></row><table><table>table see original document page 26</column></row><table>

Tabela 16: HRIS_tbl_AttendanceParameter (Tabela 1110) Esta tabela contém o parâmetro sobre o status de empregado, como presente, de leave.

<table>table see original document page 26</column></row><table><table>table see original document page 27</column></row><table>

As Tabelas 17 a 20 a seguir mostram um esquema de dados deAttrition 210 que pode suportar o aplicativo de Attrition 114. A Figura 13 pro-ve detalhes adicionais.

Tabela 17: HRIS_tbl_AttritionJHistory (Tabela 1302) A tabela contém o histórico de empregados reduzidos do efetivo.

<table>table see original document page 27</column></row><table><table>table see original document page 28</column></row><table>Tabela 18: HRIS_tbl_Attrition_Mst (Tabela 1304) A tahela contém o status de Redução de efetivo, por exemplo, liberada.

<table>table see original document page 29</column></row><table><table>table see original document page 30</column></row><table>

Tabela 19: HRIS_tbl_Attrition_PerformanceFeedback (Tabela 1306) FRta tabela descreve o feedback do empregado durante seu exercício de cargo.

<table>table see original document page 30</column></row><table>Tabela 20: HRIS_tbl_Attrition_Staus (Tabela 1308) Esta tabela tem o status de redução de efetivo (Aprovada / Liberada).

<table>table see original document page 31</column></row><table>

As Tabelas 21 a 22 a seguir mostram tabelas adicionais para oesquema de dados de HRIS.

<table>table see original document page 31</column></row><table>Tabela 22: HRIS_tbl_daylnterval

<table>table see original document page 32</column></row><table>

As Tabelas 23 a 26 a seguir mostram tabelas para o esquema de da-dos de movimento 214 que suporta o aplicativo de Movement 126. A Figura 12 pro-vâdetalhes adicionais.

Tabela 23: HRIS_tbl_Movement_Details (Tabela 1202) Aiabela descreve o movimento do empregado de um processo para um outro.

<table>table see original document page 32</column></row><table>Tabela 24: HRIS_tbl_Movement_Head (Tabela 1204) Fsta tabela descreve o movimento de um empregado de processo em processo.

<table>table see original document page 33</column></row><table><table>table see original document page 34</column></row><table>

Tabela 25: HRIS_tbl_Movement_History (Tabela 1208)

<table>table see original document page 34</column></row><table>

Tabela 26: HRIS_tbl_Movement_Status (Tabela 1206)

<table>table see original document page 34</column></row><table><table>table see original document page 35</column></row><table>

As Tabelas 27 a 33 mostram tabelas adicionais para o esquemade dados de HRIS que suportam a funcionalidade de lista de plantão de apli-cativo de HRIS 128. Alternativamente, a funcionalidade de lista de plantãopode ser implementada em um aplicativo separado e as tabelas de lista deplantão podem ser organizadas em um esquema de dados de aplicativo delista de plantão em separado que suporte as exigências de conjunto de dados delista de plantão.

Tabela 27: HRIS_tbl_Roster_Details (Tabela 1112) FRta tahfila contém o horário de comeco e de fim do turno do empregado. <table>table see original document page 35</column></row><table><table>table see original document page 36</column></row><table>

Tabela 28: HRIS_tbl_RosterHead (Tabela 1116) . Esta tabela contém o número de bilhete de cada lista de plantão que é transferida ívia UDloadV

<table>table see original document page 36</column></row><table><table>table see original document page 37</column></row><table>

Tabela 29: HRIS_tbl_RosterParameter (Tabela 1118)

<table>table see original document page 37</column></row><table>Tabela 30: HRIS_tbl_RosterSheet Fita tabela nnntém o status que foi transferido (via upload).

<table>table see original document page 38</column></row><table>

Tabela 31: HRIS_tbl_RosterSheet_Error Fsta tabela acomnanha o erro aue ocorre durante uma transferência (via upload). <table>table see original document page 38</column></row><table><table>table see original document page 39</column></row><table>

Tabela 32: HRIS_tbl_RosterSheet_Legends

<table>table see original document page 39</column></row><table>

Tabela 33: HRIS tbl_RosterSheet_Temp

<table>table see original document page 39</column></row><table><table>table see original document page 40</column></row><table>

As Tabelas 34 a 37 a seguir mostram tabelas adicionais para oesquema de dados de HRIS.

<table>table see original document page 40</column></row><table><table>table see original document page 41</column></row><table>

Tabela 35: HRISJJp

<table>table see original document page 41</column></row><table><table>table see original document page 42</column></row><table>Tabela 36: HRIS_Userlnfo_Sheet Fsta tflhpla rnntém a informação de empreqado que foi transferida (via upload). <table>table see original document page 43</column></row><table><table>table see original document page 44</column></row><table>

Tabela 37: HRlSJJserInfoSheet_Detail Esta tabela contém o caminho de arquivo a partir de onde foi transferido (via u- nlnadV

<table>table see original document page 44</column></row><table>

As Tabelas 38 a 44 a seguir mostram tabelas para o esquemade dados de gerenciamento de ID que suporta o aplicativo de gerenciamentode ID 116.Tabela 38: IDM_tbl_Businessids_Mst

<table>table see original document page 45</column></row><table>Tabela 39: IDM_tbl_Businesslds_User Nesta tabela. IDs comerciais diferentes de usuários são salvas.

<table>table see original document page 46</column></row><table>

<table>table see original document page 46</column></row><table><table>table see original document page 47</column></row><table>

Tabela 41: IDM_tbLWorkFlow_Status

<table>table see original document page 47</column></row><table><table>table see original document page 48</column></row><table>

Tabela 42: IDMJJploadedSheets

<table>table see original document page 48</column></row><table><table>table see original document page 49</column></row><table> Tabela 43: IDM UDloadedSheets Details Esta é uma tabela filha ou de detalhes da tabe- la IDMJJploadedSheets. <table>table see original document page 49</column></row><table> Tabela 44: IDM UoIoadedSheets Errors Durante uma transferência (via upload) de IDs1 se qualquer erro ocorrer, os deta- lhes de cada registro de erro são salvos.

<table>table see original document page 49</column></row><table><table>table see original document page 50</column></row><table>

As Tabelas 45 a 49 mostram as tabelas para o esquema de da-dos de KANA de Case Management 208 que suporta o aplicativo de KANAde Case Management 108. A Figura 6 provê detalhes adicionais.

Tabela 45: Kana tbl AqentIdDetc

<table>table see original document page 50</column></row><table><formula>formula see original document page 51</formula>

Tabela 46: Kana tbl CaseFIow Action (Tabela 604) Todas as ações possíveis que podem ser feitas em um caso em particular.

<table>table see original document page 51</column></row><table><table>table see original document page 52</column></row><table>

Tabela 47: Kana tbl CaseFlow_Details (Tabela 602)

<table>table see original document page 52</column></row><table>Tabela 48: Kana tbl CaseFIow Head (Tabela 608) Esta tabela mantém o status final de um caso. Dirá se um caso está fechado ou não.

<table>table see original document page 53</column></row><table>

Tabela 49: Kana tbl CaseFIow Mst (Tabela 606) As informações de caso são armazenadas nesta tabela.

<table>table see original document page 53</column></row><table><table>table see original document page 54</column></row><table>

As Tabelas 50 a 58 a seguir mostram tabelas para o esquemade dados de Leave 212 que suporta o aplicativo de Leave 120. As Figuras 8e 9 provêem detalhes adicionais.

Tabela 50: Leave tbl Allocation (Tabela 802)

<table>table see original document page 54</column></row><table><table>table see original document page 55</column></row><table>Tabela 51: Leave tbl Allocation_Historv (Tabela 806)

<table>table see original document page 56</column></row><table><table>table see original document page 57</column></row><table>

Tabela 52: Leave. tbLAppIiedLeave (Tabela 902) Os detalhes principais de leave são salvos nesta tabela.

<table>table see original document page 57</column></row><table><table>table see original document page 58</column></row><table>

Tabela 53: Leave íbl AopIiedLeave Details (Tabela 904)

<table>table see original document page 58</column></row><table><table>table see original document page 59</column></row><table>

Tabela 54: Leave tbl AppIiedLeave WorkFIow (Tabela 904) O fluxo de trabalho do processo de pedido de Ieave é mantido e capturado nesta tabela.

<table>table see original document page 59</column></row><table>Tabela 55: Leave tbl AppliedLeave_WorkFlowStatus (Tabela 908)

<table>table see original document page 60</column></row><table>

Tabela 56: Leave tbl BaIanceLeave (Tabela 804)

<table>table see original document page 60</column></row><table><table>table see original document page 61</column></row><table>

Tabela 57: Leave tbl BaIanceLeave Historv Nesta tabela um histórico de balanço de Ieave dos usuários é salvo. Sempre que qualquer registro de balanço de Ieave for atualizado, o histórico prévio do mesmo registro será salvo nesta tabela. <table>table see original document page 61</column></row><table><table>table see original document page 62</column></row><table>

Tabela 58: Leave tbl Special Quota

<table>table see original document page 62</column></row><table><table>table see original document page 63</column></row><table>

As Tabelas 59 a 66 mostram tabelas para o AIM de esquema dedados de Case Management 204 que suporta o aplicativo de AIM de CaseManagement 106. As Figuras 4 e 5 provêem detalhes adicionais.

<table>table see original document page 63</column></row><table><table>table see original document page 64</column></row><table><table>table see original document page 65</column></row><table>

Tabela 60: MAPLE tbl CaseFIow Details (Tabela 502) Esta tabela é usada para a captura das possíveis ações realizadas nos casos em particular. <table>table see original document page 65</column></row><table><table>table see original document page 66</column></row><table>

Tabela 61: MAPLE tbl CaseFlow.Head (Tabela 504)

<table>table see original document page 66</column></row><table><table>table see original document page 67</column></row><table>

Tabela 62: Maole tbl CaseFIow. Action (Tabela 508) Usada para o gerenciamento de possíveis ações realizadas em casos registra- dos.

<table>table see original document page 67</column></row><table><table>table see original document page 68</column></row><table>

Tabela 63: MaDle tbl CaseFIowError (Tabela 406)

<table>table see original document page 68</column></row><table><table>table see original document page 69</column></row><table>

Tabela 64: Maple CaseFIow Franchise (Tabela 402) Esta tabela é usada para o gerenciamento de franquia para o caso. <table>table see original document page 69</column></row><table>

Tabela 65: MaDle tbl BatchMst (Tabela 404) Esta tabela é usada para o gerenciamento de detalhes de lote <table>table see original document page 69</column></row><table><table>table see original document page 70</column></row><table>Tabela 66: Maole tbl CommentMst (Tabela 408)

<table>table see original document page 71</column></row><table>

As tabelas 67 a 69 mostram tabelas para o SOE de esquema de da-dos de Case Management 216 que suporta o aplicativo de SOE de Case Manage-ment 110. A Figura 7 provê detalhes adicionais.Tabela 67: Maple tbl CaIITvP Esta tabela armazena os deta eMst (Tabela 704) hes com respeito ao tipo de chamada.

<table>table see original document page 72</column></row><table> Tabela 68: Maole tbl CaIITvoe .Detail (Tabela 702) Esta armazena os detalhes de uma chamada registrada.

<table>table see original document page 72</column></row><table><table>table see original document page 73</column></row><table>

Tabela 69: Maole tbl CallTvoe_Head (Tabela 706)

<table>table see original document page 73</column></row><table>

A Tabela 70 a seguir mostra um modelo de dados de empregado.

Tabela 70: Emolovee Upload Temolate

<table>table see original document page 73</column></row><table><table>table see original document page 74</column></row><table>

As Tabelas 71 a 109 a seguir mostram tabelas de sistema definalidade geral para a arquitetura 100. As Tabelas 71 a 109 podem ser im-plementadas em um esquema de dados de aplicativo comum 220 para aprovisão, como um exemplo, de uma informação geral de empregado, talcomo prenome, sobrenome e endereço de e-mail. A Figura 3 provê detalhesadicionais.

Tabela 71: Svs ApDSettinqCateqories

<table>table see original document page 74</column></row><table>

Tabela 72: Svs ADoSettinas

<table>table see original document page 74</column></row><table><table>table see original document page 75</column></row><table>

Tabela 73: Svs tbl Announcements Esta tabela armazena uma informação relacionada aos anúncios a serem feitos. <table>table see original document page 75</column></row><table> Tabela 74: Svs tbl. Apolicationlssue A tabela contém a informação relacionada a questões de sistema.

<table>table see original document page 75</column></row><table><table>table see original document page 76</column></row><table>

Tabela 75: Svs tbl_Applicationlssue_Details

<table>table see original document page 76</column></row><table><table>table see original document page 77</column></row><table> Tabela 76: Svs tbl ApplicationIssueJHead A tabela contém a data na qual a questão é travada e em que data ela foi fechada. <table>table see original document page 77</column></row><table>Tabela 77: Svs tbl ApplicationlssuesStatus

<table>table see original document page 78</column></row><table>

Tabela 78: Svs tbl Documents

<table>table see original document page 78</column></row><table><table>table see original document page 79</column></row><table>

Tabela 79: Svs t A tabela contém EnumerationMst odas as enumerações feitas.

<table>table see original document page 79</column></row><table>

Tabela 80: Svs tbl EnumerationVaIue A tabela contém a informação de detalhe sobre todas as enumerações. <table>table see original document page 79</column></row><table><table>table see original document page 80</column></row><table>

Tabela 81: Svs tbl Favourates Links

<table>table see original document page 80</column></row><table><table>table see original document page 81</column></row><table>

Tabela 82: Svs tbl Franchíse List Esta tabela contém a informação sobre a franquia da Accenture.

<table>table see original document page 81</column></row><table>

Tabela 83: Svs tbl GeoaraDhicDetaiIs A tabela contém os detalhes de localização geográfica com seu nome. <table>table see original document page 81</column></row><table>Tabela 84: Svs tbl HoIidavMst

<table>table see original document page 82</column></row><table>

Tabela 85: Svs tbl Leveis

<table>table see original document page 82</column></row><table><table>table see original document page 83</column></row><table>

Tabela 86: Svs tbl MaiIFormat

<table>table see original document page 83</column></row><table>Tabela 87: Svs tbl MaiIFormatM. Esta tabela contém informação reap acionada ao mapeamento de correio.

<table>table see original document page 84</column></row><table>Tabela 88: Sys_tbl MaiIinqGroup

<table>table see original document page 85</column></row><table>

Tabela 89: Svs tbl l

<table>table see original document page 85</column></row><table><table>table see original document page 86</column></row><table>Tabela 90: Svs tbl ModuIeMst

<table>table see original document page 87</column></row><table>

Tabela 91: Svs tbl OrqanizationaIHierarchv

<table>table see original document page 87</column></row><table>Tabela 92: Svs tbl. OrqanizationalHierarchv__Historv Esta tabela contém o histórico de hierarquia organizacional. <table>table see original document page 88</column></row><table>Tabela 93: Svs tbl ProcessMst (Tabela 1106) A tabela contém o nome de todos os processos.

<table>table see original document page 89</column></row><table>Tabela 94: Svs tbl ProcessTeams (Tabela 302)

<table>table see original document page 90</column></row><table>Tabela 95: Svs. tbl ReasonsMst Esta é a tabela mestra para todas as razões relacionadas a ad hoc, movimento, saída e horas extras.

<table>table see original document page 91</column></row><table> Tabela 96: Svs tbl User Notes Esta tabela contém uma informação de armazenamento de notas de usuário. <table>table see original document page 91</column></row><table>Tabela 97: Svs tbl UserContactInfo (Tabela 310) A tabela contém os detalhes de endereço (Permanente / Correspondência) de empregados. <table>table see original document page 92</column></row><table><table>table see original document page 93</column></row><table>

Tabela 98: Svs tbl UserContactlnfo_Historv

<table>table see original document page 93</column></row><table><table>table see original document page 94</column></row><table>

Tabela 99: Svs tbl UserContactInfo Transaction A tabela contém os detalhes de endereço (Permanente / Correspondência) de empregados.

<table>table see original document page 94</column></row><table><table>table see original document page 95</column></row><table>

Tabela 100: Svs tbl UserContactlnformationHistorv

<table>table see original document page 95</column></row><table><table>table see original document page 96</column></row><table>

Tabela 101: Svs tbl UserGrouDs (Tabela 312) Esta tabela contém os direitos de grupo de usuário os quais são proporcionados ao empregado, dependendo de seus Processos.

<table>table see original document page 96</column></row><table><table>table see original document page 97</column></row><table>

Tabela 102: Svs tbl UserLoainCredentiaI (Tabela 304)

<table>table see original document page 97</column></row><table><table>table see original document page 98</column></row><table>

Tabela 103: Svs tbl UserLoqioHistorv

<table>table see original document page 98</column></row><table><table>table see original document page 99</column></row><table>

Tabela 104: Svs tbl UserMst (Tabela 308) A tabela contém os detalhes da informação geral de empregado.

<table>table see original document page 99</column></row><table><table>table see original document page 100</column></row><table>

Tabela 105: Svs tbl UserOraanizationaIHierarchv (Tabela 306) Esta contém uma informação sobre a hierarquia de organização do usuário

<table>table see original document page 100</column></row><table><table>table see original document page 101</column></row><table>

Tabela 106: Svs tbl_ UserOrganizationaIInfo (Tabela 314)

<table>table see original document page 101</column></row><table><table>table see original document page 102</column></row><table>

Tabela 107: Svs tbl UserSpeciaICredentiaI Esta tabela armazena informações sobre as credenciais especiais de Iogin do usuário <table>table see original document page 102</column></row><table>Tabela 108: Svs User tbl ContactLocaIitv Esta tabela contém a informação sobre a Iocalidad e.

<table>table see original document page 103</column></row><table>

O aplicativo de HRIS 128 facilita o gerenciamento de uma infor-mação de organização por um administrador. O aplicativo de HRIS 128 tam-bém gerencia vários processos, questões, detalhes de usuário, detalhes decorreio e gerencia um quadro de avisos. O aplicativo de HRIS 128 pode in-cluir um módulo de gerenciamento de processo que implementa a criação, aativação e a desativação de processos. O módulo também pode implemen-tar um quadro de processo e um gerenciamento de equipe de processo euma edição de informação de processo para todos os processos na organi-zação.

O módulo de gerenciamento de processo pode gerenciar qua-dros de processo e uma informação de relatório sobre os vários níveis degerenciamento no processo. O módulo de gerenciamento de processo tam-bém pode gerenciar equipes de processo e reportar a informação das váriasequipes do processo e sua hierarquia. O módulo de gerenciamento de pro-cesso ainda pode editar uma informação de processo para a provisão deedição para funções de um processo. As figuras 14 a 20 mostram exemplosde telas de interface gráfica de usuário (GUI), relatório e processamento queo aplicativo de HRIS 128 pode implementar para o módulo de gerenciamentode processo.

Em particular, a figura 14 mostra uma interface gráfica de usuá-rio 1402 que exibe uma porção de exibição 1404 e vários controles 1408 a1414 para controle da interface gráfica de usuário 1402. A interface gráficade usuário 1402 também pode incluir um título de exibição 1420 que exibeum título associado à interface gráfica de usuário 1402.

Os controles 1408 a 1414 da interface gráfica de usuário 1402podem ser variados e numerosos. Em uma implementação, os controles dainterface gráfica de usuário 1402 incluem um controle de menu suspenso1406, um controle de caixa de verificação 1408, um controle de item de exi-bição selecionável 1410, um controle de botão 1412, um controle de impres-são 1414 e um controle de exportação 1416 e um controle de porção de exi-bição 1418.

O controle de menu suspenso 1406 é operativo para a exibiçãode itens de menu suspenso a partir de um menu suspenso, quando o contro-le de menu suspenso 1406 for ativado.

O controle de caixa de verificação 1408 é operativo para sele-cionar um item de exibição associado ao controle de caixa de verificação1408. A interface gráfica de usuário 1402 pode incluir múltiplos controles decaixa de verificação e qualquer controle de caixa de verificação pode serativado independentemente de outros controles de caixa de verificação.

O controle de item de exibição selecionável 1410 é operativopara transferir o usuário para uma outra interface gráfica de usuário associa-da ao item de exibição do controle de item de exibição selecionável 1410.Por exemplo, o controle de item de exibição selecionável 1410 pode ser umhiperlink que exibe uma nova janela para o usuário, quando o controle deitem de exibição selecionável 1410 for ativado.

O controle de botão 1412 é operativo para transmitir uma men-sagem de ação, quando ativada. Por exemplo, o controle de botão 1412 po-de transmitir uma mensagem de ação associada à criação de um novo pro-cesso ou a desativação de processos previamente selecionados. O controlede botão 1412 também pode estar associado a controles de caixa de verifi-cação.

O controle de impressão 1414 é operativo para a transmissão deuma instrução para a impressão da interface gráfica de usuário exibida 1402.

O controle de exportação 1416 é operativo para a exportaçãodos itens exibidos da porção de exibição 1404 para um outro aplicativo, talcomo um aplicativo de planilha.

O controle de porção de exibição 1418 é operativo para o contro-le da exibição dos itens de exibição na porção de exibição 1404. Por exem-plo, a ativação do controle de caixa de verificação 1408 pode transmitir umainstrução para que itens de exibição adicionais sejam exibidos na porção deexibição 1418. A interface gráfica de usuário 1402 pode implementar o con-trole de porção de exibição 1418 como um hiperlink ou um outro controlegráfico.

Os controles 1406 a 1418 e a porção de exibição 1404 são me-ramente representativos e não exaustivos. Por exemplo, a interface gráficade usuário 1402 pode implementar controles a menos ou adicionais. Outrostipos de controles, tais como barras de rolagem, campos de entrada, botõesde rádio, também são possíveis.

A figura 15 mostra um exemplo de uma interface gráfica de usu-ário 1502 com um arranjo alternativo de um título de exibição 1420, umaporção de exibição 1404 e controles de interface gráfica de usuário 1406,1408, 1412 e 1414. A interface gráfica de usuário 1502 também implementacontroles adicionais 1504 e 1506. O controle 1504 é um exemplo de um con-trole de entrada de campo de texto. O controle 1504 é operativo para rece-ber uma entrada a partir de um usuário na forma de caracteres alfanuméri-cos. O controle 1506 é um exemplo de um controle de entrada de data decalendário. O controle de entrada de data de calendário 1506 é operativopara receber uma seleção de uma data de calendário a partir de um usuário.

As figuras 14 e 15 mostram vários controles de interface gráficade usuário. As figuras 16 a 117 também mostram interfaces gráficas de usu-ário tendo controles de interface gráfica de usuário. Contudo, as interfacesgráficas de usuário mostradas nas figuras 16 a 117 também implementammais ou menos do que os controles mostrados nas figuras 14 e 15. Alémdisso, as figuras 16 a 117 podem implementar vários tipos de controles deinterface gráfica de usuário. Daí, muitos arranjos diferentes de interfacesgráficas de usuário são possíveis.O aplicativo de HRIS 128 também pode incluir um módulo degerenciamento de grupo de usuário. O módulo de gerenciamento de grupode usuário pode gerenciar os grupos de usuário, e facilitar uma atribuição,uma visualização e um gerenciamento de outra forma de direitos de acessode usuário. As figuras 21 a 23 mostram exemplos de telas de GUI, relatório eprocessamento que o módulo de gerenciamento de grupo de usuário podeimplementar.

O aplicativo de HRIS 128 também pode incluir um módulo degerenciamento de feriado. O módulo de gerenciamento de feriado pode ge-renciar feriados de empregado e prover uma edição de lista de feriados. Osferiados podem ser de múltiplos tipos, tais como Fixo ou Opcional. Os feria-dos podem ser atualizados no começo de cada ano calendário, e podemvariar por localização também. A figura 24 mostra um exemplo de uma telade GUI, relatório e processamento que o módulo de gerenciamento de feria-do pode implementar. Em todas as telas de GUI para qualquer um dos apli-cativos, os dados podem ser exportados ao se clicar no ícone de planilha.

O aplicativo de HRIS 128 também pode incluir um módulo degerenciamento de informação organizacional que facilita a entrada e o ge-renciamento de uma informação de organização de usuário. Múltiplos tiposde informação podem ser salvos, incluindo detalhes de empregado, tais co-mo nome de equipe, nome de representante de RH, data de nascimento,DOJ (Data de Admissão), nível e localização. Outra informação que pode sergerenciada inclui identificadores, tais como identificadores de rede, domínioe empresa. A figura 25 mostra um exemplo de uma tela de GUI, relatório eprocessamento que o módulo de gerenciamento de informação organizacio-nal pode implementar.

O aplicativo de HRIS 128 também pode incluir um módulo degerenciamento de quadro de aviso e um módulo de gerenciamento de ques-tão. O módulo de gerenciamento de quadro de aviso provê interfaces para atransferência (via upload) de boletins ou outras mensagens que aparecemna tela, quando um usuário fizer um login. O módulo de gerenciamento dequestão gerencia questões criadas por usuários. As figuras 26 e 27 a 28mostram exemplos de telas de GUI para o gerenciamento de quadro de avi-so e gerenciamento de questão, respectivamente.

O aplicativo de HRIS 128 também pode incluir um módulo degerenciamento de lista de plantão. O módulo de gerenciamento de lista deplantão provê interfaces para a transferência (via upload) e o gerenciamentode listas de plantão. As figuras 29 e 30 mostram exemplos de telas de GUIpara gerenciamento de lista de plantão. Note que uma lista de plantão podecomeçar como um arquivo de planilha para um processo em particular que étransferido (via upload) para o sistema em uma faixa de dada selecionada.

O aplicativo de HRIS 128 também pode incluir um módulo derelatório de efetivo. O módulo de relatório de efetivo provê interfaces para orelatório de efetivo bem como os detalhes de movimento para um processoselecionado e uma faixa de data. O módulo de relatório de efetivo tambémprovê um filtro de tipo de movimento. As figuras 31 e 32 mostram exemplosde telas de GUI para um gerenciamento de lista de plantão.

O aplicativo de HRIS 128 também pode incluir um módulo derelatório de sumário de exercício de cargo. O módulo de relatório de sumáriode exercício de cargo também pode prover filtros nas opções a seguir: faixade data, nome de processo, localização, tipo de exercício de cargo, e faixade exercício de cargo (por número de dias). Um módulo de relatório de exer-cício de cargo pode prover detalhes de empregados em uma faixa de exer-cício de cargo selecionada. Os dados podem ser segregados pelos filtros aseguir: faixa de data, nome de processo, localização, tipo de localização, tipode exercício de cargo, e faixa de exercício de cargo (número de dias). Asfiguras 33 e 34 mostram exemplos de telas de GUI para sumário de exercí-cio de cargo e relatório.

Este aplicativo de redução de efetivo 114 acompanha reduçõesde efetivo ocorrendo na organização. Esta informação é utilizada pelas pes-soas de Recursos Humanos para visualização de reduções de efetivo emum processo em particular. As reduções de efetivo podem ser de três tipos:gerenciadas, não gerenciadas e de evasão. Pode haver várias razões parareduções de efetivo, tais como estudos ou educação adicionais, questões defamília, questões em perspectivas de crescimento, interessado em outroscampos, quer sair do centro de contato / BPO, lidar com questões de geren-ciamento, recebeu melhores perspectivas, certificado fraudulento, razões desaúde, evasão, razões pessoais, falecimento ou por outras razões. As figu-ras 35 a 38 mostram exemplos de telas de GUI para acompanhamento erelatório de redução de efetivo. O aplicativo de redução de efetivo 114 tam-bém pode prover interfaces de aprovação e rejeição de redução de efetivo efuncionalidade, conforme mostrado nas figuras 39 e 40.

A figura 41 mostra um fluxograma de dados para o aplicativo deredução de efetivo 114. Com base no código de empregado (4102), um tipode redução de efetivo é atribuído (4104). Um supervisor intermediário sub-mete o relatório (4104) e uma aprovação de gerente é obtida (4106). Se ogerente não aprovar, o registro de redução de efetivo será liberado de voltapara o sistema (4108), caso contrário, a informação de saída será comuni-cada para os departamentos organizacionais, o status de empregado se tor-nará inativo, e o empregado será removido da hierarquia de empregado(4106). O depósito de dados de aplicativo mestres 102 armazena o resultadoda ação de redução de efetivo.

O aplicativo de redução de efetivo 114 também pode incluir ummódulo de relatório de redução de efetivo que provê uma interface atravésda qual os detalhes de redução de efetivo podem ser obtidos. O módulo derelatório de redução de efetivo pode prover filtros para: código de emprega-do, faixa de data, nome de processo, localização e nome de equipe. A figura42 mostra uma GUI de exemplo para o módulo de relatório de redução deefetivo.

O aplicativo de redução de efetivo 114 também pode incluir ummódulo de sumário de redução de efetivo. O sumário de redução de efetivopode prover um relatório de sumário de redução de efetivo como um relató-rio interativo. As contagens de redução de efetivo de nível de processo paranível de agente podem ser vistas e uma representação gráfica de contagemde redução de efetivo e sumário de redução de efetivo pode ser obtida ao seclicar em um link de visualização gráfica. As figuras 43 e 47 proveem exem-pios de telas de GUI para relatório e processamento de dados de sumário deredução de efetivo. A figura 48 provê um exemplo de um relatório de saídaque o aplicativo de redução de efetivo 114 pode gerar.

O aplicativo de registro de compromisso 112 acompanha oscompromissos que supervisores e gerentes regulam no começo do mês, etambém acompanha atendimento dos mesmos compromissos. O aplicativode registro de compromisso 112 pode incluir um módulo de gerenciamentode registro que gerencia os registros de compromisso de acordo com as de-signações de atividade de TL (Líder de Equipe), atividade de DM (Subgeren-te), atividade de OM (Gerente Operacional) e outra atividade. Os compro-missos podem ser regulados em combinações de critérios, tais como desig-nações e níveis. A figura 49 mostra um exemplo de uma tela de GUI para omódulo de gerenciamento de registro.

O aplicativo de registro de compromisso 112 pode incluir ummódulo de gerenciamento de meta de compromisso que facilita o relatório ea regulagem de metas de compromisso. A figura 50 mostra uma tela de GUIpara o módulo de gerenciamento de registro.

O aplicativo de registro de compromisso 112 pode incluir ummódulo de gerenciamento de programação que é baseado em uma hierar-quia para uma flexibilidade adicionada. As figuras 51 e 52 mostram exem-plos de uma tela de GUI para o módulo de gerenciamento de programação.

Ao clicar no link 'View My Commitment Target' (Ver Minha Meta de Com-promisso), os usuários podem ver suas metas de compromisso individuais eas metas atingidas, tal como na tela de relatório mostrada na figura 52.

O aplicativo de registro de compromisso 112 pode incluir ummódulo de gerenciamento de compromisso para a regulagem e o gerencia-mento de metas de compromisso. As figuras 53 e 54 mostram os exemplosde telas de GUI para o módulo de gerenciamento de compromisso.

A figura 55 mostra o fluxo de dados para o aplicativo de registrode compromisso 112. Após as atividades de central de atendimento para umnegócio serem definidas, atividades no sentido de processo são formalmentedefinidas (5502). Então, as metas de compromisso de atividade são estabe-lecidas (5504), tal como em uma base mensal. Conforme os empregadoscumprem os compromissos, a informação de meta de compromisso é atuali-zada (5506). Os supervisores então podem rodar relatórios para checaremse as metas de compromisso são atingidas por empregado individuais(5508). Os dados de compromisso comandam relatórios de índice de de-sempenho, ou outros tipos de relatório (5510). Todos os dados de compro-misso, incluindo metas e cumprimentos, podem ser salvos no banco de da-dos mestres 102, tal como no esquema de dados específico para o aplicativode registro de compromisso 112.

O aplicativo de registro de compromisso 112 pode incluir ummódulo de sumário de compromisso para relatório de compromissos atingi-dos e regulados. A figura 56 mostra um exemplo de uma tela de GUI para omódulo de sumário de compromisso.

O aplicativo de Ieave 120 pode incluir uma lógica e interfacesque implementam a aplicação, a aprovação, o encaminhamento e o cance-lamento de requisições de leave. O aplicativo de Ieave 120 inclui um módulode Vacation Planner (Planejador de Férias), um módulo de Leave Allocation(Alocação de Leave), um módulo de Approve Leaves (Aprovar Licenças), ummódulo de My Applied Leaves (Minhas Licenças Pedidas) e um módulo deLeave Summary (Sumário de Leave). Cada módulo é descrito abaixo.Vacation Planner

Os empregados podem usar o planejador de férias para pediruma leave ao selecionarem uma faixa de data específica. A figura 57 mostraum exemplo da GUI de planejador de férias. Os supervisores e acima tam-bém podem pedir uma leave em nome de seus membros de equipe ao intro-duzirem um código de empregado e clicarem no botão 1On behalf of (Emnome de) 5802 mostrado na figura 58. Enquanto pedindo uma leave em no-me de um outro usuário, o supervisor pode checar se o nome de usuárioexibido no campo de empregado 5804 está correto para a pessoa paraquem se pede a leave.

Uma vez que uma faixa de data seja selecionada, o empregadoclica no botão 'Planned Leave' (Leave Planejada) 5702. O planejador de fé-rias então pode exibir uma interface conforme mostrado na figura 58, inclu-indo uma lista de datas, e checar este balanço de Ieave pessoal, bem comouma cota disponível para o dia. O empregado também pode regular o tipo deIeave e a razão nos campos providos.

Leave Allocation

O módulo de alocação de Ieave pode atualizar efetivos no senti-do de processo e percentagem de alocação de Ieave para uma faixa de da-da específica. Uma GUI de exemplo é mostrada na figura 59. Ao clicar nolink de ver alocação 5902, o módulo de alocação de Ieave permite atualiza-ções na cota de Ieave no sentido de nível para o processo e a faixa de dataespecíficos, conforme mostrado na figura 60.

Approve Leaves

O módulo de aprovar licenças implementa interfaces através dasquais bilhetes de Ieave podem ser aprovados por supervisores e acima paraseus respectivos membros de equipe, conforme mostrado na figura 61. Paraaprovação da leave, o supervisor clica no link Ticket Number (Número deBilhete) 6102. Os dados podem ser filtrados através de critérios de busca,tais como código de empregado, nome de processo e nome de equipe. Aoclicar no botão Action Select Items (Itens de Seleção de Ação) 6104, a pró-xima tela, Leave Details (Detalhes de Leave) aparecerá, conforme mostradona figura 62. O supervisor pode selecionar qualquer uma das opções a partirda lista suspensa de ações para cancelar uma leave, aprovar uma leave,encaminhar a requisição para uma outra ação, ou outra opção.

My Applied Leaves

Os empregados podem usar o módulo My Applied Leaves parachecarem o status de bilhetes de leave que eles submeteram. Uma GUI deexemplo é mostrada na figura 63. Ao clicar no link Cancel Leave (CancelarLeave) 6302, o empregado pode cancelar a leave pedida.

Leave Summary

Os detalhes de pedido de leave são obtidos a partir do módulode sumário de leave. O módulo pode implementar uma GUI, conforme mos-trado na figura 64, incluindo filtros para faixa de data, nome de processo,localização, ou outras características.

A figura 65 mostra um fluxograma de dados para o aplicativo deIeave ΐ20. O aplicativo-de Ieave 120 pode determinar a alocação de Ieaveatual (6502) e determinar se é para aprovar a leave, dependendo da cotadisponível. Por exemplo, se uma cota não estiver disponível para o dia(6504) e o gerente não tiver uma cota especial remanescente (6506), então,a leave será negada. Caso contrário (6506), o aplicativo de leave 120 podedeterminar se qualquer balanço de leave pessoal está disponível (6508).

Se uma leave estiver disponível, o aplicativo de leave 120 pode-rá aprovar a leave (6512); caso contrário, o empregado poderá selecionartentar ter uma leave sem vencimentos aprovada (6510). O empregado podecancelar a leave, conforme desejado (6514). Caso contrário, a leave podeser aprovada (6516). Os dados de leave relacionados são armazenados noesquema de dados específico para o aplicativo de leave 120.

O aplicativo de Attendance 122 implementa uma lógica e interfa-ces que gerenciam a presença, verificam a presença e reportam a presença.Para gerenciamento de presença, a interface mostrada na figura 66 mostraos nomes de equipe programados para o processo selecionado e a data. Ossupervisores podem marcar a presença ao clicarem no link Mark Attendance(Marcar Presença) 6602. Ao clicarem no link Graphical View (VisualizaçãoGráfica) 6604, os usuários podem obter uma representação gráfica dos da-dos de status de presença para a data e o processo selecionados, por e-xemplo, como um gráfico de torta 3D 6606. Os dados podem ser filtrados porlocalização.

Para verificação de presença, a interface mostrada na figura 67permite que os supervisores marquem a presença de seus respectivosmembros de equipe. A interface também provê a marcação de presença emtempo real pela equipe, na ausência do supervisor / supervisor alternativo.Além disso, balanços de leave pessoal, de referência e por doença dos usu-ários são ajustados através de uma presença diariamente.

A figura 68 mostra um fluxo de dados para o aplicativo de pre-sença 122. Em particular, o status de presença de vários tipos é acompa-nhado e armazenado no esquema de dados específico para o aplicativo depresença 122. Por exemplo, se o empregado estiver presente (6802), aquelestatus poderá ser armazenado. Se o empregado não estiver presente, então,o aplicativo de presença 122 poderá determinar se o empregado tem umaIeave planejada. Se assim for, o empregado tem um balanço de Ieave rema-nescente (6804), então, o balanço de Ieave planejado é reduzido de modoconforme (6806). Se o empregado estiver em uma Ieave por doença, o ba-lanço de Ieave por doença remanescente será reduzido de modo conformetambém. Se nenhuma Ieave por doença restar (6808), então, o aplicativo depresença 122 poderá deduzir da Ieave planejada, se qualquer estiver dispo-nível. Se um empregado estiver ausente, mas nenhum balanço de Ieave res-tar, um supervisor poderá ser notificado, ou a matéria poderá ser escaladapara revisão. Por outro lado, se um empregado for programado para umaleave de referência, mas estiver trabalhando, então, o balanço de Ieave po-derá ser aumentado de modo conforme (6810).

O módulo de relatório de presença pode implementar interfacesque reportem efetivo de processo, com filtros tais como: faixa de data, nomede processo, fuso-horário e localização. A figura 69 mostra uma GUI de e-xemplo para relatório de presença. A figura 70 mostra uma GUI de sumáriode processo e a figura 71 mostra uma GUI de sumário de equipe.My OneView

O aplicativo de acesso de informação de empregado 136 ("MyOneView") é projetado para empregados da organização. Cada empregadona organização pode ter acesso a este aplicativo. Em uma implementação, oMy OneView inclui os módulos a seguir: My Oneview lssues, My ContactDetails, My Leave Balance, My Favorite Links, My Notes, My Attendance,Change Password, My Team Hierarchy, Search Employee, My Schedule, MyBusiness IDs, View Holiday List, My Team Contact Detail, e Manage TeamContact. Módulos funcionais adicionais, a menos ou diferentes podem serimplementados.

O módulo My Oneview Issues (Questões de My OneView) regis-tra questões que o empregado encontrou usando o sistema. A figura 72mostra um exemplo de uma GUI para o módulo. Quando o empregado elemesmo está criando uma questão, então, suas credenciais são mostradasnas respectivas caixas de texto. A GUI provê uma entrada / seleção de loca-lização, o sumário de problema e a descrição detalhada de questão.

O módulo também facilita a criação de uma questão em nomede qualquer outro empregado. Quando a caixa de texto 7202 ('on behalf of')é marcada, então, uma caixa de texto é exibida. Na caixa de texto, o empre-gado pode introduzir um Código de empregado do empregado em nome dequem ele está criando esta questão. Quando o código de empregado é in-troduzido, a GUI mostrada na figura 72 se atualiza para mostrar as credenci-ais do empregado em nome de quem a questão foi criada, ao invés de oempregado registrado no módulo.

O módulo My Contact Details (Meus Detalhes de Contato) permi-te que um empregado mantenha e atualize detalhes de contato. O emprega-do pode selecionar o tipo de contato, tal como endereço para Correspon-dência ou endereço Permanente. O empregado pode introduzir seu respecti-vo endereço na caixa de texto e, então, fazer seleções quanto a Cidade, Es-tado, País e Área. O empregado também pode introduzir um Código Postal eum Número de Telefone Fixo, um número de Telefone Celular, um númerode Fax, e se ele requer transporte (por exemplo, para ou do local de traba-lho) ou não. Após se completarem, os detalhes de contato são enviados pa-ra aprovação pelo supervisor e armazenados no banco de dados 102. O a-plicativo de transporte 124, o departamento de RH ou outra área pode pro-cessar esta informação para determinar, por exemplo, arranjos de caronacoletiva para empregado. A figura 73 mostra um exemplo da GUI para a in-trodução de detalhes de contato.

O módulo My Leave Balance (Meu Balanço de Leave) exibe umaGUI (conforme mostrado, por exemplo, na figura 74) que pode ser apenasde leitura e que descreve o balanço de leave do empregado. A GUI podemostrar o tipo de Leave (por exemplo, de Referência, Opcional e Fixa) e obalanço de leave para o tipo de leave em particular. A informação de empre-gado detalhada (por exemplo, nome, nome de processo, nome de supervi-sor, nome de equipe, e similares) também é exibida para a qual o balanço deleave está sendo mostrado.

O módulo My Favorite Links (Meus Links Favoritos) acompanhaos links favoritos de um empregado. O empregado pode introduzir o URL, otítulo e comentários para o link. O conteúdo dos campos mencionados acimapode ser editado ou apagado a partir dos links Edit (Editar) e Delete (Apa-gar), respectivamente, conforme mostrado na GUI na figura 75.

O módulo My Notes (Minhas Notas) acompanha as notas de umempregado. O empregado pode escrever o título da nota, e introduzir a notadetalhada em si. A GUI pode prover a edição da nota também. Uma GUI deexemplo é mostrada na figura 76.

O módulo My Attendance (Minha Presença) aceita uma entradade empregado para marcar sua presença. A informação detalhada de em-pregado também é exibida juntamente com os detalhes de turno. Uma GUIde exemplo é mostrada na figura 77.

O módulo Change Password (Mudar Senha) facilita a troca dasenha de um usuário convidado, tal como um não empregado ou um empre-gado contratado. Uma GUI de exemplo é mostrada na figura 78.

O módulo My Team Hierarchy (Minha Hierarquia de Equipe) ge-ra uma visualização de hierarquia de equipe com base no Nome de Equipe(Team Name). O módulo também classifica com base em critérios tais comoLocalização, Nome de Processo e nome de Equipe. Outros critérios de clas-sificação incluem exercício de cargo na companhia (por exemplo, em meses)e a disposição dos registros em ordem ascendente ou descendente. Ao en-contrar os detalhes de membro de equipe, o módulo aceita uma seleção denome de membro de equipe e, então, recupera a hierarquia de membro deequipe e os detalhes de rede. A figura 79 mostra uma GUI de exemplo.

O módulo Search Employee (Buscar Empregado) busca um em-pregado na organização. O módulo pode buscar com base em um código deempregado para o empregado cujos detalhes estão sendo buscados. O mó-dulo então pode apresentar os detalhes de empregado, tais como Detalhesde Hierarquia, detalhes de Rede e Informação de Versão. O módulo podeusar GUIs tais como aquelas mostradas na figura 80.

O módulo My Schedule (Minha Programação) exibe vistas depresença, repousos semanais e outra informação de programação do em-pregado com base na lista de plantão. O módulo também pode exibir a in-formação detalhada de empregado para a programação. A figura 81 mostrauma GUI de exemplo para o módulo.

O módulo My Business IDs (Minhas IDs Comerciais) exibe vistasdas diferentes IDs comerciais do empregado. O módulo classifica as IDscom base no nome de processo e também com base em IDs comerciais, eem ordem ascendente e descendente. O módulo também exibe a informa-ção de empregado detalhada, bem como a senha para várias IDs comerci-ais. A figura 82 mostra uma GUI de exemplo para o módulo.

O módulo View Holiday List (Ver Lista de Feriados) apresentavistas da lista de feriados. O módulo classifica com base no tipo de feriado, oqual pode ser de tipos fixos ou opcionais. O módulo também classifica combase na localização e no ano calendário. O módulo também mostra a infor-mação detalhada para o feriado, tais como data, nome de feriado e tipo deferiado. A figura 83 mostra uma GUI de exemplo para o módulo.

O módulo My Team Contact Detail (Meu Detalhe de Contato deEquipe) exibe os detalhes de contato de uma equipe. O módulo pode classi-ficar com base no nome de processo e no nome de equipe, ou outros crité-rios. O módulo também pode classificar com base no tipo de contato, o qualpode ser correspondências temporárias ou contatos permanentes. O móduloresponde a um clique no nome de empregado com uma janela instantâneamostrando o endereço de contato do empregado, com base nos critérios declassificação. A figura 84 mostra uma GUI de exemplo para o módulo.

O módulo Manage Team Contact (Gerenciar Contato de Equipe)facilita o gerenciamento de contatos de equipe. Em particular, um supervisorpode empregar o módulo para a atualização de uma informação de contatopara membros de sua equipe. O módulo pode aceitar uma seleção de tipode contato, tal como endereço para Correspondência ou endereço Perma-nente. O supervisor então pode introduzir a informação de endereço na cai-xa de texto e, então, fazer várias seleções para Cidade, Estado, País e Área.O supervisor também pode introduzir o Código Postal, o Número de Telefo-ne Fixo, o número de Telefone Celular, o número de Fax, e se o empregadorequer transporte ou não. A informação completada pode ser enviada para osupervisor para aprovação, e pode ser usada pelo aplicativo de transporte,ou por outros aplicativos para determinação de programações de caronacoletiva ou outras decisões de transporte. A figura 85 mostra uma GUI deexemplo para o módulo.

O módulo também permite o gerenciamento de um contato deequipe em nome de qualquer outro membro de equipe. Quando a caixa deverificação ('on behalf of) é marcada, o módulo pode exibir uma caixa detexto que aceite um código e empregado. Em resposta, a GUI mostrada nafigura 86 pode ser apresentada, a qual mostra os detalhes de contato doempregado para edição.

A figura 87 mostra um fluxograma de dados para My OneView.Em particular, o empregado pode selecionar qualquer um dos módulos ex-plicados acima (8702). Os dados fluem de volta através da arquitetura 10para o banco de dados mestres 102. Como um exemplo, se o empregadoatualizar um endereço (8704) ou um empregador atualizar um endereço(8706), a atualização poderá ser aprovada (8708) e armazenada no bancode dados mestre 102.

O aplicativo de Transport 124 gerencia e relata questões rela-cionadas a transporte ("ad hoc") para o empregado. O aplicativo de transpor-te 124 pode aprovar ou negar requisições ad hoc, e pode ser dividido emtarefas de gerenciamento lidadas por um módulo de requisições ad hoc, ummódulo de requisição ad hoc em volume, e uma aprovação / rejeição de mó-dulo de requisição ad hoc; e relatar tarefas lidadas por um módulo de relató-rio ad hoc, um módulo de lista de plantão de transporte, e um módulo de lis-tas de plantão de informação de contato.

O módulo Adhoc Request (Requisição Ad hoc) submete umarequisição ad hoc. Um empregado pode fazer uma requisição ad hoc por simesmo ou fazer uma requisição para um outro empregado. O módulo pre-enche os detalhes de empregado para a pessoal para quem a requisição adhoc é criada. O módulo pode aceitar parâmetros ad hoc, tais como o tipo dead hoc, data de pegar / deixar, razão de ad hoc e Comentários. O módulopode preencher o horário de começo de Turno e o horário de fim de Turno apartir da lista de plantão mantida no banco de dados 102. A figura 88 mostraum exemplo da GUI de módulo. Como com outros módulos descritos acima,a GUI para este módulo pode incluir um seletor 'on behalf of que permiteque um indivíduo faça uma requisição ad hoc para um outro empregado.

O módulo Bulk Adhoc Request (Requisição Ad hoc em Volume)cria requisições ad hoc em volume. As requisições ad hoc em volume podemresultar da feitura de requisições para múltiplos empregados. Para essa fina-lidade, a GUI de módulo, mostrada na figura 89, pode aceitar uma lista sepa-rada por vírgulas de códigos de empregado, juntamente com uma outra in-formação, tais como nome de processo, tipo de ad hoc, razão, horário decomeço de Turno e o horário de fim de Turno.

O módulo Approve / Deny (Aprovar / Rejeitar) facilita a aprova-ção e a rejeição pelo supervisor de uma requisição ad hoc gerada por ummembro de equipe. Após a requisição ser aprovada pelo supervisor, o módu-lo pode exibir uma janela de pop-up que pergunta se é para enviar a requisi-ção para o departamento de transporte, bem como uma janela de pop-upmostrando detalhes ad hoc com uma opção para impressão da requisição adhoc. As figuras 90 e 91 mostram exemplos da GUI de módulo.

Com respeito ao relatório, o módulo Adhoc Report (Relatório Adhoc) acompanha a requisição ad hoc gerada. O departamento de transportepode usar a informação acompanhada para a obtenção dos detalhes de re-quisições ad hoc, tais como nome de empregado, tipo de ad hoc, data, ra-zão, horário e data de aprovação. Um exemplo da GUI de relatório ad hoc émostrado na figura 92, a qual permite buscar e reportar por código de em-pregado, a partir de uma data, até uma data, nome de processo, localização,nome de equipe e outros parâmetros.

O módulo Transport Roster (Lista de Plantão de Transporte) exi-be a lista de plantão de transporte para uma faixa de data em particular cias-sificada por processo e localização para os usuários que requeiram transpor-te. O módulo Transport Roster pode ser usado por um departamento deTransporte para a construção de um plano de rota de transporte para umasemana por vir. A figura 93 mostra um exemplo da GUI de transporte.

O módulo Contact Info Report (Relatório de Informação de Con-tato) recupera e exibe uma informação detalhada de contato de um empre-gado que requeira transporte. Este relatório pode ser gerado ao se introduzirum código de empregado e selecionar Search (Buscar), e o relatório podeser classificado com base no processo e na localização. O módulo respondeao se clicar no nome de empregado com uma janela de pop-up que contémo endereço detalhado do empregado. A figura 94 mostra um exemplo daGUI de modelo.

A figura 95 mostra um fluxograma para processamento de trans-porte. O aplicativo de transporte 124 aceita as requisições ad hoc (9502) ouas requisições ad hoc em volume (9504). As requisições são aprovadas ourejeitadas (9506), e as requisições são comunicadas para o departamentode transporte (9508) e armazenadas no banco de dados mestre 102.

A arquitetura 100 inclui um aplicativo de gerenciamento de casoque pode ter três partes lógicas: um aplicativo de Accounts Integrity Mana-gement (Gerenciamento de Integridade de Contas) ("AIM") 106, um aplicati-vo de processamento de pedido on-line ("ΚΑΝΑ") 108, e um aplicativo deSales Order Entry (Entrada de Pedido de Vendas) (SOE) 110. Como umavisão geral, o aplicativo de gerenciamento de caso captura o tempo de ma-nipulação médio (AHT) em qualquer processo não de voz. O aplicativo degerenciamento de caso pode ser dividido logicamente ou de modo físico nasinterfaces a seguir: My cases, Manage cases, Manage Batch, Manage Errortype, Manage Franchise, e Edit Account Information.

A interface My cases (Meus casos) suporta as tarefas a seguir:Registrar novos casos, Trabalhar em casos registrados, Ver casos com baseem datas selecionadas, Buscar casos usando filtros diferentes, e Realizar asações a seguir nos casos: 'Yes', 'No', 'Stuck' e 'Refer' ('Sim', 'Não', 'Preso' e'Recomendar'). A figura 96 mostra exemplos da GUI My Cases 9602 e dainterface de GUI de Informação de Conta de suporte 9604. Um usuário poderegistrar um caso novo ao clicar no botão 'Add New Case' ('Adicionar NovoCaso'). Ao selecionar o número de lote e o número de conta, outros detalhes,tais como a linha de comércio, o tipo de erro e franquia, podem ser recupera-dos a partir do banco de dados mestres 102 e preenchidos na interface.

O aplicativo de gerenciamento de caso suporta cálculos de AHT/ ACW / Tempo de resposta. Para essa finalidade, o aplicativo de gerencia-mento de caso captura várias estampas de tempo, conforme se segue:Tempo de Começo:

Quando um usuário clica em 'Add New Case' (no link ou no bo-tão mostrado na figura 96, interface 9602), o aplicativo captura o tempo atualcomo o "Tempo de Começo".Tempo de Início:

Quando o usuário clica na opção 'Save Account Details' (SalvarDetalhes de Conta) na GUI de informação de Conta 9604, o aplicativo captu-ra o tempo atual como o "Tempo de Início".Tempo de Fim:

Quando um usuário clica na opção 'Save' (Salvar) na interfacede Case Action (Ação de Caso) (um exemplo é mostrado na figura 97), oaplicativo captura o tempo atual como o "Tempo de Fim". Em outras palavras,quando a ação tiver sido feita em um caso, o Tempo de Fim é capturado.

O aplicativo de gerenciamento de caso determina as medidas aseguir:

AHT (Tempo de Manipulação Médio) = (Tempo de Começo - Tempo de Fim);

ACW (Após Trabalhar na Chamada, ou Tempo de Finalização) = (Tempo deInício - Tempo de Começo). Este é o tempo gasto na regulagem do registro.

TAT (Tempo de resposta) = (Tempo de Fim - Tempo de Início).

A interface Manage cases (Gerenciamento de Casos) exibe, pa-ra supervisores / gerentes, os casos registrados e casos trabalhados queforam recomendados para eles por seus respectivos membros de equipe. Afigura 98 mostra um exemplo da interface Manage cases. A interface podeser uma exibição em tempo real. A interface pode suportar uma filtração dedados quanto aos critérios a seguir: Empregado, Data, N9 de Conta, Nome eEquipe, Status de Caso, Auditoria de Casos ou outros critérios. A interfacepode mostrar uma informação de caso incluindo um número de caso, umnúmero de lote, um número de conta, criado por nome, status liberado ou deauditoria, tempo de resposta, recomendação ou uma outra informação. Ainterface responde a links embutidos no número de caso pela exibição deuma informação de conta do caso selecionado individual.

A interface Manage Batch (Gerenciamento de Lote) pode serusada, por exemplo, por supervisores ou gerentes para a adição ou a ediçãode detalhes de lote e para se tornarem ativos ou inativos os detalhes de lote.Cada lote pode ser mapeado para sua linha de comércio específica e o tipode erro. A figura 99 mostra um exemplo da interface de gerenciamento delote. A interface pode filtrar com base em tipo de lote, e pode exibir uma in-formação de definição e lote, tais como número de lote, tipo de lote, númerode casos no lote, recebido em data, criado por nome, e status ativo / inativo.

A interface Manage Error type (Gerenciamento de Tipo de Erro)pode ser usada para a adição ou a edição de tipos de erro, por exemplo, deacordo com uma linha de comércio específica e para se tornar um tipo deerro ativo / inativo. A figura 100 mostra um exemplo da interface de gerenci-amento de tipo de erro.

A interface Manage Franchise (Gerenciamento de Franquia) po-de ser usada para a adição / edição de detalhes de franquia e para se tornaruma franquia em particular ativa ou inativa. A figura 101 mostra um exemploda interface de gerenciamento de franquia.

A interface Manage AIM Comments (Gerenciamento de Comen-tários de AIM) pode ser usada para a adição ou a edição dos detalhes deComentários de AIM e para se tornarem comentários em particular ativos ouinativos. A figura 102 mostra um exemplo da interface de gerenciamento decomentários de AIM.

A interface SOE Call Type Tracker (Rastreador de Tipo de Cha-mada de SOE) acompanha o tipo de chamadas recebidas pelos agentes deSOE de gerenciamento de caso. O tipo de vendas também é acompanhadopor esta interface. A figura 103 mostra um exemplo da interface de rastrea-dor de chamada de SOE. Conforme mostrado na figura 103, múltiplos tipospodem ser atribuídos a qualquer chamada (por exemplo, Checar Serviço eCancelar Pedido).

A interface AIM Case Report (Relatório de Caso de AIM) podeaceitar parâmetros de busca e exibir os casos combinando. A interface podefiltrar por a partir de data, até data, número de lote, status de caso, tipo decomentário, ou outros critérios. A figura 104 mostra um exemplo da interfacede relatório de caso de AIM.

O aplicativo de processamento de pedido online 108 pode proveruma GUI de detalhe de tipo de chamada de SOE, tal como aquela mostradana figura 105. A interface pode filtrar dados de acordo com faixa de data,código de empregado ou outros critérios.

A figura 106 mostra uma GUI de SOE Call Type Report (Relató-rio de Tipo de Chamada de SOE). A GUI de SOE Call Type Report pode e-xibir uma informação de entrada de pedido de vendas, tal como um códigode empregado, um nome de empregado, um tipo de vendas, um tipo de sis-tema, um tipo de chamada e criado em data. A GUI pode filtrar dados porcódigo de empregado, faixa de data ou outros critérios.

A figura 107 mostra um fluxograma de dados para acompanha-mento de manipulação de caso. O empregado introduz um número de lote(10702) e o aplicativo de gerenciamento de caso checa se o lote está ativo(10704) e torna o lote ativo (10706), se não for. O empregado então podesalvar os detalhes de casos atribuídos àquele lote (10708). Uma decisãopode ser tomada quanto aos casos em uma base individual (10710). Se ocaso for difícil e for atribuído o status Preso, o empregado pode ser reatribu-ído a um outro caso (10712). Se o caso não puder ser resolvido, ao casopoderá ser atribuído o status Não e o caso poderá ser fechado (10714). Umcaso recomendado pode ser transferido para um supervisor para manipulação(10716). A um caso que é resolvido é atribuído o Status 'Sim', e os dados decaso relacionados são armazenados no banco de dados mestres 102.A figura 108 mostra um fluxograma de dados similar àquele dafigura 107. Contudo, a figura 108 mostra que o aplicativo de gerenciamentode-caso-pode funcionar com lotes de casos os quais são transferidos (viaupload) para o sistema (10802). O sistema pode alocar automaticamentecasos para indivíduos para resolução, ou o sistema pode aceitar uma entra-da manual para direcionamento dos casos para empregados em particular(10804).

A figura 109 mostra um fluxograma de dados para acompanha-mento de chamada de SOE. O empregado regula o tipo de sistema (10902),o tipo de vendas (10904), o tipo de chamada (10906) e quaisquer outros da-dos capturados para o pedido de vendas. O aplicativo de gerenciamento decaso salva os dados no banco de dados mestre 102.

O aplicativo de ID Management 116 cria, gerencia e relata nú-meros de identificação de empregado. A figura 110 mostra uma GUI de e-xemplo para criação de ID para o aplicativo de gerenciamento de ID 116. AGUI pode capturar a informação a seguir para a criação de um número deidentificação: Nome, Descrição, Tempo de Resposta para a criação em Ho-ras, Status, ID de Organização / ID especificada de Cliente, Tipo de Requisi-ção, ou qualquer outro dado relevante.

A figura 111 mostra uma GUI de exemplo para gerenciamentode IDs comerciais de empregado. A GUI facilita a criação e o gerenciamentode IDs relacionadas a processo e comerciais de empregado. A GUI filtra da-dos de acordo com: Código de Empregado, Nome de Processo e classificapor IDs Comerciais e pedido, ou outros critérios.

A figura 112 mostra um fluxograma de dados para gerenciamen-to de ID. O empregado seleciona o nome de processo (11202) e, opcional-mente, seleciona um arquivo (11204), o qual pode conter IDs comerciais(11206) ou senhas de IDs comerciais (11208). A arquitetura 100 determinase as IDs já existem (11210) e sobrescreve as IDs e senhas existentes(11214), ou armazena novas IDs e senhas (11212). Os dados de ID são ar-mazenados no banco de dados mestre 102.

O aplicativo de Movement Management 126 gerencia um movi-mento de empregado ou membro de equipe entre engajamentos ou proces-sos. O movimento de empregado ou de membro de equipe pode incluir ummovimento para dentro, um movimento para fora e um movimento dentro doprocesso para um empregado ou um membro de equipe. O aplicativo de ge-renciamento de movimento 126 pode incluir um módulo de gerenciamentoque facilita um movimento de equipe usando, por exemplo, a GUI mostradana figura 113. Um novo movimento pode ser programado ao se clicar no bo-tão 'create new movement' (criar novo movimento) 11302. Os detalhes deum bilhete de movimento existente podem ser vistos ao se clicar nos links11304 embutidos no campo de dados na GUI.

Um exemplo da interface de criação de movimento é mostradona figura 114. A interface de criação de movimento inclui os campos de en-trada de critério de movimento par movimento de e para: funções, processose/ou equipes diferentes, e aceita entrada de uma razão, data de programação erevisor de requisição. Outras opções de movimento podem ser providas.

Em uma implementação, o movimento pode ser de 3 tipos:

Movimento para Dentro (novos empregados se movem para aprodução

Movimento para Fora (os empregados saem do negócio atual); eMovimento no processo.

Ao clicar no botão Get Team Hierarchy (Obter Hierarquia de Ti-me) 11402, a interface recupera uma lista de hierarquia / nomes de membrode equipe para seleção, conforme mostrado na interface sob "Team MemberName" (Nome de Membro de Equipe). Após os empregados serem empre-gados, o usuário pode selecionar o botão "Schedule Movement" (ProgramarMovimento) 11404 para avisar ao sistema como proceder. O aplicativo degerenciamento de ID 126 pode enviar uma notificação (por exemplo, umamensagem de e-mail) para os empregados, supervisores ou outros indiví-duos afetados pelo movimento.

O módulo Approve Movement (Aprovar Movimento) no aplicativode gerenciamento de ID 126 provê uma interface através da qual as requisi-ções de movimento são aprovadas pelos respectivos gerentes. Uma GUI deexemplo é mostrada ria figura 115. O GUI pode prover links 11502 nos cam-pos de dados. Os links resultam na exibição da GUI de aprovação mostradana figura 116. A GUI de aprovação aceita uma seleção de ação (por exem-plo, aprovação, cancelada ou encaminhada para um outro), e permite que osupervisor salve a disposição.

A figura 117 mostra um fluxograma de dados para gerenciamen-to de movimento. O movimento pode correr com um processo (11702), forade um processo (11704) ou em um processo (11706). O supervisor introduza informação a partir de / para, razão de movimento, data de movimentoprogramado e quaisquer outros parâmetros (11708). Quando o supervisorseleciona a hierarquia de time, o aplicativo de gerenciamento de movimento126 recupera a lista de empregados (11710). O supervisor seleciona um oumais empregados a partir da lista (11712), programa o movimento (11714) esubmete a requisição de movimento a um gerente para aprovação (11716).Se o movimento for aprovado, o processo de movimento se completa e éprogramado (11718). Em qualquer evento, os dados de movimento aprovadoou cancelado são armazenados no banco de dados mestre 102.

A figura 118 mostra um exemplo de fluxo lógico 11800 para co-ordenação das operações de múltiplos aplicativos de central de atendimentoem uma arquitetura de central de atendimento. O fluxo lógico 11800 inicial-mente inclui o estabelecimento de um depósito de dados de aplicativo mes-tres de acordo com um esquema de organização de dados mestres unificadoatravés de múltiplas exigências de conjunto de dados de aplicativo de centralde atendimento (11802). O fluxo lógico 11800 então pode incluir a subdivi-são do esquema de dados de organização de dados mestres (11804). Emuma implementação, a subdivisão do esquema de dados de organização dedados mestres inclui a subdivisão do esquema de dados de organização dedados mestres em um primeiro esquema de dados de aplicativo que suportauma primeira exigência de conjunto de dados de aplicativo para um primeiroaplicativo de central de atendimento e um segundo esquema de dados deaplicativo que suporta uma segunda exigência de conjunto de dados de apli-cativo para um segundo aplicativo de central de atendimento. Além disso, oualternativamente, o fluxo lógico 11800 pode incluir o estabelecimento de umesquema de dados de aplicativo comum no esquema de dados de organiza-ção de dados mestres que implementa uma exigência de conjunto de dadoscompartilhada comum ao primeiro aplicativo de central de atendimento e osegundo aplicativo de central de atendimento (11806).

Após a subdivisão do esquema de dados de organização de da-dos mestres (11804) e/ou o estabelecimento do esquema de dados de apli-cativo comum (11806), o fluxo lógico 11800 então prossegue para o estabe-lecimento de uma interface de comunicação de aplicativo de central de aten-dimento (11808). A interface de comunicação de aplicativo de central de a-tendimento mais tarde pode ser usada para o recebimento das requisiçõesde dados a partir de aplicativos de central de atendimento.

O fluxo lógico 11800 então pode prosseguir para a iniciação daexecução de múltiplos aplicativos de central de atendimento. Por exemplo, ofluxo lógico 11800 pode prosseguir para a iniciação da execução de um apli-cativo de gerenciamento de caso (11810), iniciação da execução de um apli-cativo de gerenciamento de redução de efetivo (11812), iniciação da execu-ção de um aplicativo de gerenciamento de Ieave (11814), e iniciação da exe-cução de um aplicativo de gerenciamento de movimento (11816). Em umaimplementação alternativa, o fluxo lógico 11800 pode incluir a iniciação daexecução de aplicativos de central de atendimento a menos ou adicionais.Além disso, o fluxo lógico 11800 pode incluir a inicialmente da execução deoutros aplicativos de central de atendimento, tal como um aplicativo de re-cursos humanos ou outro aplicativo de central de atendimento.

A interface de comunicação de aplicativo de central de atendi-mento então pode receber requisições de dados de central de atendimento apartir dos aplicativos de central de atendimento (11818). Por exemplo, a in-terface de comunicação de aplicativo de central de atendimento pode rece-ber uma requisição de dados de central de atendimento a partir do aplicativode gerenciamento de caso, do aplicativo de gerenciamento de redução deefetivo, do aplicativo de gerenciamento de Ieave e do aplicativo de gerenci-amento de movimento. Contudo, a interface de comunicação de antena pola-rizada dupla e central de atendimento pode não receber requisições dequalquer um dos aplicativos de central de atendimento, ou a interface decomunicação de aplicativo de central de atendimento pode receber uma re-quisição de dados de central de atendimento apenas a partir de um pedidode central de chamada. Outras con figura ções também são possíveis.

O fluxo lógico 11800 então prossegue para processamento dasrequisições de dados de aplicativo de central de atendimento recebidas(11820). O fluxo lógico 11800 pode incluir muitos tipos diferentes de proces-samento, incluindo um processamento de primeiro a entrar / primeiro a sair,processamento de primeiro a entrar / último a sair, processamento simultâ-neo, processamento de "round robin", ou qualquer outro tipo de processa-mento, recebimento de uma primeira requisição de dados de aplicativo decentral de atendimento a partir do primeiro aplicativo de central de atendi-mento através da interface de comunicação de aplicativo de central de aten-dimento.

A figura 119 mostra um exemplo de fluxo lógico 11900 para au-tenticação de um usuário. Inicialmente, a um usuário pode ser apresentadauma tela de Iogin ou outra interface gráfica de usuário (11902). A tela de Io-gin ou outra interface gráfica de usuário pode ser con figura da para o rece-bimento de credenciais de autenticação, tais como um nome de usuário euma senha, a partir do usuário. Contudo, em algumas implementações, ascredenciais de autenticação podem ser apenas um nome de usuário ou ape-nas uma senha.

Em geral, um usuário pode ser qualquer tipo de usuário. Emuma implementação, o fluxo lógico 11900 reconhece dois tipos de usuários:um usuário empregado permanente e um usuário empregado contratado,também conhecido como usuário convidado (11904 a 11908). Os mecanis-mos de autenticação (11904 a 11908) podem ser con figura dos para a au-tenticação do usuário com base no tipo de usuário.

Um primeiro mecanismo de autenticação autentica o usuário u-sando um banco de dados de servidor de domínio 11918 em que o usuárioprove um conjunto de credenciais de autenticação identificando que o usuá-rio é um usuário empregado permanente (11904). Em uma implementação,o primeiro mecanismo de autenticação recebe o nome de um servidor denome de domínio além das credenciais de autenticação providas pelo usuá-rio. O primeiro mecanismo de autenticação pode usar o banco de dados deservidor de nome de domínio 11918 e o depósito de dados de aplicativomestres 102 para autenticação de um usuário.

Um segundo mecanismo de autenticação autentica um usuáriousando o depósito de dados de aplicativo mestres 102, onde o usuário provêum conjunto de credenciais de autenticação identificando o usuário como umempregado contratado ou um usuário convidado (11906). No segundo me-canismo de autenticação, o fluxo lógico 11900 pode prosseguir para o apli-cativo de Ieave 120 para determinar se o usuário proveu um conjunto aceitá-vel de credenciais de autenticação para um empregado contratado ou umusuário convidado.

Finalmente, um terceiro mecanismo de autenticação autenticaum usuário usando uma conta atual local, tal como uma ID de domínio, enão usa uma senha para validação do usuário (11908). O terceiro mecanis-mo de autenticação também usa o depósito de dados de aplicativo mestres102 para a autenticação do usuário.

Após o recebimento das credenciais de autenticação, o fluxológico 11900 então prossegue para a autenticação do usuário (11910). Aautenticação do usuário pode envolver o fluxo lógico 11900 tomar uma deci-são quanto a se o usuário é autenticado (11912). Quando um mecanismo deautenticação identifica que o usuário é um usuário autenticado, o fluxo lógico11900 identifica o usuário como um usuário autorizado (11916). De modosimilar, quando um mecanismo de autenticação identifica que o usuário é umusuário não autorizado, o fluxo lógico 11900 identifica o usuário como umusuário não autorizado (11914). Embora o fluxo lógico 11900 possa envolverum mecanismo de autenticação, o fluxo lógico 11900 pode usar um ou maismecanismos de autenticação para autenticação de um usuário. Outros me-canismos de autenticação também são possíveis.

A Figura 120 mostra um exemplo de uma interface gráfica deusuário 12000 que exibe uma lista de verificação para um usuário, enquantoo usuário está tomando uma chamada. A lista de verificação exibida na inter-face gráfica de usuário 12000 pode ser associada a um processo. A lista deverificação pode listar várias ações, itens ou outras exigências que se refe-rem ao processo associado. Por exemplo, uma das ações na lista de verifi-cação pode ler "Apologized and Empathised" (Desculpado e Empatia Cria-da), o que indica para o usuário que o usuário deve se desculpar e criar umaempatia em uma chamada ou em um processo. A interface gráfica de usuá-rio 12000 também pode exibir controles, tais como uma caixa de verificação,um botão de rádio, ou um outro controle que um usuário pode ativar ao indi-car que o usuário completou um item, ação ou outra exibição na lista de veri-ficação.

Os elementos ilustrados nas figuras interoperam conforme expli-cado em detalhes acima. Toda a discussão, independentemente da imple-mentação em particular descrita, é da natureza de exemplo, ao invés de Iimi-tante. Por exemplo, embora aspectos selecionados, recursos ou componen-tes das implementações sejam descritos conforme sendo armazenados emmemórias, todos ou parte dos sistemas e métodos consistentes com as ino-vações podem ser armazenados em, distribuídos através de ou lidos a partirde outros meios que podem ser lidos em máquina, por exemplo, dispositivosde armazenamento secundário, tais como discos rígidos, discos flexíveis, eCD-ROMs; um sinal recebido a partir de uma rede; ou outras formas deROM ou RAM atualmente conhecidas ou desenvolvidas mais tarde.

Além disso, embora componentes específicos de inovações tenhamsido descritos, métodos, sistemas e artigos de fabricação consistentes com ainovação podem incluir componentes adicionais ou diferentes. Por exemplo,um processador pode ser implementado como um microprocessador, ummicrocontrolador, um circuito integrado específico de aplicação (ASIC), umalógica discreta ou uma combinação de outro tipo de circuitos ou lógica. Demodo similar, as memórias podem ser DRAM, SRAM, Flash ou qualquer ou-tro tipo de memória. Flags, dados, bancos de dados, tabelas, entidades ououtras estruturas de dados podem ser distribuídos, ou podem ser lógica efisicamente organizados de muitas formas diferentes. Os programas podem serpartes de um programa único, programas em separado ou várias memóriasdistribuídas através e processadores.

Embora várias modalidades da inovação tenham sido descritas,será evidente para aqueles de conhecimento comum na técnica que muitasmodalidades e implementações são possíveis no escopo da inovação. Assimsendo, a inovação não é para estar restrita, exceto à luz das reivindicaçõesem anexo e seus equivalentes.

Claims (23)

1. Dados de aplicativo de central de atendimento e interoperaçãode arquitetura, a arquitetura compreendendo:um depósito de dados de aplicativo mestres compreendendo umesquema de organização de dados mestres unificado através de múltiplasexigências de conjunto de dados de aplicativo de central de atendimento, oesquema de organização de dados mestres compreendendo uma subdivisãode esquema que define:um primeiro esquema de dados de aplicativo dentro do esquemade organização de dados mestres que é específico para uma primeira exi-gência de conjunto de dados de aplicativo para um primeiro aplicativo decentral de atendimento;um segundo esquema de dados de aplicativo dentro do esque-ma de organização de dados mestres que é específico para uma segundaexigência de conjunto de dados de aplicativo para um segundo aplicativo decentral de atendimento;uma interface de comunicação de aplicativo de central de aten-dimento operável para:receber uma primeira requisição de dados de aplicativo de cen-tral de atendimento em comunicação com a interface de comunicação deaplicativo de central de atendimento;receber uma segunda requisição de dados de aplicativo de cen-tral de atendimento em comunicação com a interface de comunicação deaplicativo de central de atendimento; eum processador acoplado à interface de conexão de aplicativode central de atendimento e ao depósito de dados de aplicativo mestres eoperável para:processar a primeira requisição de dados de aplicativo de centralde atendimento pela realização de uma primeira manipulação de dados emresposta à primeira requisição de dados de aplicativo de central de atendi-mento no primeiro esquema de dados de aplicativo no depósito de dados deaplicativo mestres, por meio do que se alivia o primeiro aplicativo de centralde atendimento do primeiro tempo de processamento de banco de dadoslocal de aplicativo; eprocessar a segunda requisição de dados de aplicativo de cen-tral de atendimento pela realização de uma segunda manipulação de dadosem resposta à segunda requisição de dados de aplicativo de central de a-tendimento no segundo esquema de dados de aplicativo no depósito de da-dos de aplicativo mestres; desse modo se aliviando o segundo tempo deprocessamento de banco de dados local de aplicativo.

2. Arquitetura, de acordo com a reivindicação 1, onde a subdivi-são de esquema ainda define um esquema de dados de aplicativo comumque implementa uma exibição de conjunto de dados compartilhado comumao primeiro aplicativo de central de atendimento e ao segundo aplicativo decentral de atendimento.

3. Arquitetura, de acordo com a reivindicação 1, onde a exigên-cia de conjunto de dados compartilhado compreende uma exigência de con-junto de dados de empregado compreendendo grupos de conjunto de dadosmúltiplos inter-relacionados, incluindo:um grupo de conjunto de dados de detalhe de equipe;um grupo de conjunto de dados de informação geral de empregado;um grupo de conjunto de dados de informação de endereço deempregado;um grupo de conjunto de dados de detalhe de organização deempregado;um grupo de conjunto de dados de credencial de Iogin de usuário;um grupo de conjunto de dados de hierarquia de empregado; eum grupo de conjunto de dados de detalhes de direitos de grupode usuário.

4. Arquitetura, de acordo com a reivindicação 1, onde a primeirarequisição de dados de aplicativo de central de atendimento compreende umcomponente de requisição de dados de caso de gerenciamento de supervi-são.

5. Arquitetura, de acordo com a reivindicação 1, onde a primeirarequisição de dados de aplicativo de central de atendimento compreende umcomponente de requisição de dados de alocação de caso.

6. Arquitetura, de acordo com a reivindicação 1, onde a primeirarequisição de dados de aplicativo de central de atendimento compreende umcomponente de requisição de dados de acompanhamento de chamada deSOE.

7. Arquitetura, de acordo com a reivindicação 1, onde:o primeiro esquema de dados de aplicativo divide a primeira re-quisição conjunto de dados de aplicativo em subexigências de conjunto dedados, as subexigências de conjunto de dados compreendendo:uma primeira subexigência de conjunto de dados que inclui:um grupo de conjunto de dados de franquia de caso;um grupo de conjunto de dados de detalhe de lote;um grupo de conjunto de dados de erro de caso;um grupo de conjunto de dados de comentário de caso;um grupo de conjunto de dados de ação de caso;um grupo de conjunto de dados de status atual de caso;um grupo de conjunto de dados de informação de caso; eum grupo de conjunto de dados de ação de caso registrada;uma segunda subexigência de conjunto de dados que inclui:um grupo de conjunto de dados de histórico de ação de caso dekana;um grupo de conjunto de dados de status final de caso de kana;um grupo de conjunto de dados de ação de caso registrada dekana; eum grupo de conjunto de dados de informação de caso de kana; euma terceira subexigência de conjunto de dados que inclui:um grupo de conjunto de dados de detalhe de chamada registrado;um grupo de conjunto de dados de detalhe de tipo de chamada; eum grupo de conjunto de dados de detalhe de chamada de usu-ário.

8. Arquitetura, de acordo com a reivindicação 1, onde a primeirarequisição de dados de aplicativo de central de atendimento compreende umcomponente de requisição de dados de alvo de compromisso de estabeleci-mento de supervisão.

9. Arquitetura, de acordo com a reivindicação 1, onde a primeirarequisição de dados de aplicativo de central de atendimento compreende umcomponente de requisição de dados de programação de compromisso degerenciamento de supervisão.

10. Arquitetura, de acordo com a reivindicação 1, onde:o primeiro esquema de dados de aplicativo divide a primeira re-quisição de conjunto de dados de aplicativo em grupos de conjunto de dadosmúltiplos inter-relacionados, os grupos de conjunto de dados múltiplos rela-cionados incluindo:um grupo de conjunto de dados de descrição de compromissode supervisor;um grupo de conjunto de dados de descrição de alvo de supervisor;um grupo de conjunto de dados de histórico de alvo;um grupo de conjunto de dados de alvo de atividade de registrode compromisso de supervisor;um grupo de conjunto de dados de compromisso obtido;um grupo de conjunto de dados de programação de compromisso; eum grupo de conjunto de dados de descrição de alvo.

11. Arquitetura, de acordo com a reivindicação 1, onde:o primeiro esquema de dados de aplicativo divide a primeira re-quisição de conjunto de dados de aplicativo em grupos de conjunto de dadosmúltiplos inter-relacionados, que são atribuídos, cada um, a um subconjuntoda primeira requisição de conjunto de dados de aplicativo; eo segundo esquema de dados de aplicativo divide a segundarequisição de conjunto de dados de aplicativo em grupos de conjunto de da-dos múltiplos inter-relacionados, que são atribuídos, cada um, a um subcon-junto da segunda requisição de conjunto de dados de aplicativo.

12. Método de coordenação da operação de múltiplos aplicativosde central de atendimento em uma arquitetura de central de atendimento, ométodo compreendendo:o estabelecimento de um depósito de dados de aplicativo mes-tres de acordo com um esquema de organização de dados mestres unificadoatravés de múltiplas exigências de conjunto de dados de aplicativo de centralde atendimento;a subdivisão do esquema de dados de organização de dadosmestres em:um primeiro esquema de dados de aplicativo que suporta umaprimeira requisição de conjunto de dados de aplicativo para um primeiro a -plicativo de central de atendimento;um segundo esquema de dados de aplicativo que suporta umasegunda requisição de conjunto de dados de aplicativo para um segundoaplicativo de central de atendimento;o estabelecimento de uma interface de comunicação de aplicati-vo de central de atendimento;o recebimento da primeira requisição de dados de aplicativo decentral de atendimento a partir do primeiro aplicativo de central de atendi-mento através da interface de comunicação de aplicativo de central de aten-dimento;o recebimento de uma segunda requisição de dados de aplicati-vo de central de atendimento a partir do segundo aplicativo de central deatendimento através da interface de comunicação de aplicativo de central deatendimento; eo processamento da primeira requisição de dados de aplicativode central de atendimento pela realização de uma primeira manipulação dedados no primeiro esquema de dados de aplicativo no depósito de dados deaplicativo mestres, desse modo se aliviando o primeiro aplicativo de centralde atendimento do primeiro tempo de processamento de banco de dadoslocal de aplicativo; eo processamento da segunda requisição de dados de aplicativode central de atendimento pela realização de uma segunda manipulação dedadosno segundo esquema de dados de aplicativo no depósito de dados deaplicativo mestres, desse modo se aliviando o segundo aplicativo de centralde atendimento do segundo tempo de processamento de banco de dadoslocal de aplicativo.

13. Método, de acordo com a reivindicação 12, que ainda com-preende:o estabelecimento de um esquema de dados de aplicativo comumno esquema de organização de dados mestres que implementa uma exi-gência de conjunto de dados compartilhado comum ao primeiro aplicativo decentral de atendimento e ao segundo aplicativo de central de atendimento.

14. Método, de acordo com a reivindicação 12, que ainda com-preende:a iniciação da execução de um aplicativo de gerenciamento decaso como o primeiro aplicativo de central de atendimento; e onde:o primeiro esquema de dados de aplicativo compreende um es-quema de dados de aplicativo de gerenciamento de caso e a primeira requi-sição de conjunto de dados de aplicativo compreende um conjunto de dadosde gerenciamento de caso para o aplicativo de gerenciamento de caso.

15. Método, de acordo com a reivindicação 12, que ainda com-preende:a iniciação de um aplicativo de gerenciamento de redução deefetivo como o primeiro aplicativo de central de atendimento; e onde:o primeiro esquema de dados de aplicativo compreende um es-quema de dados de aplicativo de redução de efetivo e a primeira requisiçãode conjunto de dados de aplicativo compreende uma exigência de conjuntode dados de redução de efetivo para o aplicativo de redução de efetivo.

16. Método, de acordo com a reivindicação 12, que ainda compreende:a iniciação da execução de um aplicativo de gerenciamento deIeave como o primeiro aplicativo de central de atendimento; e onde:o primeiro esquema de dados de aplicativo compreende um es-quema de dados de aplicativo de gerenciamento de Ieave e a primeira requi-sição de conjunto de dados de aplicativo compreende uma exigência de con-junto de dados de gerenciamento de Ieave para o aplicativo de gerenciamen-to de leave.

17. Método, de acordo com a reivindicação 13, que ainda compreende:a iniciação da execução de um aplicativo de gerenciamento demovimento como o primeiro aplicativo de central de atendimento; e onde:o primeiro esquema de dados de aplicativo compreende um es-quema de dados de aplicativo de gerenciamento de movimento e a primeirarequisição de conjunto de dados de aplicativo compreende uma exigência deconjunto de dados de gerenciamento de movimento para o aplicativo de ge-renciamento de movimento.

18. Produto, que compreende:um meio que pode ser lido em máquina; euma lógica armazenada no meio operável para:o estabelecimento de um depósito de dados de aplicativo mes-tres de acordo com um esquema de organização de dados mestres unificadoatravés de múltiplas exigências de conjunto de dados de central de atendi-mento;a subdivisão do esquema de dados de organização de dadosmestres em:um primeiro esquema de dados de aplicativo que suporta umaprimeira requisição de conjunto de dados de aplicativo para um primeiro a-plicativo de central de atendimento;um segundo esquema de dados de aplicativo que suporta umasegunda requisição de conjunto de dados de aplicativo para um segundoaplicativo de central de atendimento;o estabelecimento de uma interface de comunicação de aplicati-vo de central de atendimento;o recebimento de uma primeira requisição de dados de aplicativode central de atendimento a partir do primeiro aplicativo de central de aten-dimento através da interface de comunicação de aplicativo de central de a -tendimento;o recebimento de uma segunda requisição de dados de aplicati-vo de central de atendimento a partir do segundo aplicativo de central deatendimento através da interface de comunicação de aplicativo de central deatendimento; eo processamento da primeira requisição de dados de aplicativode central de atendimento pela realização de uma primeira manipulação dedados no primeiro esquema de dados de aplicativo no depósito de dados deaplicativo mestres, desse modo se aliviando o primeiro aplicativo de centralde atendimento do primeiro tempo de processamento de banco de dadoslocal de aplicativo; eo processamento da segunda requisição de dados de aplicativode central de atendimento pela realização de uma segunda manipulação dedados no segundo esquema de dados de aplicativo no depósito de dados deaplicativo mestres, desse modo se aliviando o segundo aplicativo de centralde atendimento do segundo tempo de processamento de banco de dadoslocal de aplicativo.

19. Produto, de acordo com a reivindicação 18, onde a lógicaainda é operável para:o estabelecimento de um esquema de dados de aplicativo comumno esquema de organização de dados mestres que implementa uma exigên-cia de conjunto de dados compartilhado comum ao primeiro aplicativo decentral de atendimento e ao segundo aplicativo de central de atendimento.

20. Produto, de acordo com a reivindicação 18, onde a lógicaainda é operável para:a iniciação da execução de um aplicativo de gerenciamento decaso como o primeiro aplicativo de central de atendimento; e onde:o primeiro esquema de dados de aplicativo compreende um es-quema de dados de aplicativo de gerenciamento de caso e a primeira requi-sição de conjunto de dados de aplicativo compreende um conjunto de dadosde gerenciamento de caso para o aplicativo de gerenciamento de caso.

21. Produto, de acordo com a reivindicação 18, onde a lógicaainda é operável para:a iniciação de um aplicativo de gerenciamento de redução deefetivo como o primeiro aplicativo de central de atendimento; e onde:o primeiro esquema de dados de aplicativo compreende um es-quema de dados de aplicativo de redução de efetivo e a primeira requisiçãode conjunto de dados de aplicativo compreende uma exigência de conjuntode dados de redução de efetivo para o aplicativo de redução de efetivo.

22. Produto, de acordo com a reivindicação 18, onde a lógicaainda é operável para:a iniciação da execução de um aplicativo de gerenciamento deleave como o primeiro aplicativo de central de atendimento; e onde:o primeiro esquema de dados de aplicativo compreende um es-quema de dados de aplicativo de gerenciamento de Ieave e a primeira requi-sição de conjunto de dados de aplicativo compreende uma exigência de con-junto de dados de gerenciamento de Ieave para o aplicativo de gerenciamen-to de leave.

23. Produto, de acordo com a reivindicação 18, onde a lógicaainda é operável para:a iniciação da execução de um aplicativo de gerenciamento demovimento como o primeiro aplicativo de central de atendimento; e onde:o primeiro esquema de dados de aplicativo compreende um es-quema de dados de aplicativo de gerenciamento de movimento e a primeirarequisição de conjunto de dados de aplicativo compreende uma exigência deconjunto de dados de gerenciamento de movimento para o aplicativo de ge-renciamento de movimento.