Faculdade de Engenharia da Universidade do Porto Licenciatura em Engenharia Informática e Computação na Infineon Technologies Relatório do Estágio Curricular da LEIC 2003 Miguel Pereira Torcato David Orientadora na FEUP: Engenheira Ana Paiva Orientador na Infineon Technologies: Engenheiro Josué Vilas Boas Setembro de 2003
O conteúdo deste relatório é de carácter reservado para a Infineon Technologies AG, pelo que não deverá ser feita qualquer cópia ou divulgação do mesmo durante um período de 3 anos, sem autorização prévia da entidade acima referida. Relatório de estágio de Miguel David ii
Resumo O presente relatório documenta o projecto de estágio denominado, realizado no âmbito do Estágio Curricular da Licenciatura em Engenharia Informática e Computação da Faculdade de Engenharia da Universidade do Porto, que decorreu na Infineon Technologies, Fabrico de Semicondutores, S.A. O estágio divide-se em três partes: acesso via Web, integração e adaptação às necessidades da empresa. A primeira parte consiste na elaboração de um conjunto de páginas Web que permita aos trabalhadores da Infineon Porto (IFPT) ver o estado dos seus tickets (pedidos / problemas colocados ao Helpdesk). A segunda parte consiste na integração da ferramenta utilizada no Helpdesk o Action Request System (ARS) para o registo directo de problemas, com a ferramenta utilizada para a gestão do processo de pedidos e Customer Requests Management (CRM) o Lotus Notes, uma vez que um pedido autorizado se transforma numa tarefa a executar. A terceira parte consiste na adaptação do ARS às necessidades da IFPT, nomeadamente a separação entre problemas e pedidos, a automatização de relatórios, etc. As duas primeiras partes do projecto foram realizadas dentro do calendário previsto e estão hoje em produção na fábrica. A terceira parte foi parcialmente substituída por um estudo comparativo dos sistemas de Workflow em uso na empresa e por um módulo de geração de gráficos para relatórios, por impossibilidade de concretizar as condições necessárias à respectiva execução, alheias ao autor. Relatório de estágio de Miguel David iii
Agradecimentos Agradeço a ambos os meus orientadores, o Eng.º Josué Vilas Boas pela Infineon e a Eng.ª Ana Paiva pela FEUP por me terem ajudado a manter o caminho certo. Agradeço aos colegas que trabalharam na sala comigo por me aturarem, chatearem, ajudarem e basicamente estarem lá todos os dias: Tiago Silva, João Campos, Nuno Ferreira e Albano Araújo. Agradeço a todos os colaboradores do departamento de IT da Infineon e da HP Tecnidata (Helpdesk) pela ajuda que me deram e hospitalidade que mostraram, em particular aos que acompanharam o meu trabalho mais de perto, nomeadamente a Sandra Borges e o Sérgio Sousa. Agradeço a todos os que comentaram este relatório, por terem posto à vista inconsistências que o autor nunca é capaz de ver. Agradeço finalmente à minha família mais próxima por me ter aturado nos dias mais esgotantes. Relatório de estágio de Miguel David iv
Índice de Conteúdos 1. Introdução...1 1.1. Apresentação da Infineon... 1 O site do Porto... 2 O departamento de IT... 3 1.2. Projecto na Infineon... 3 Contexto... 3 Objectivos... 4 1.3. Organização e estruturação do documento...4 2. Análise do problema global do projecto...6 2.1. O departamento de IT e a importância de um Helpdesk... 6 2.2. O funcionamento do Helpdesk... 6 2.3. Action Request System... 7 Arquitectura do ARS... 8 Componentes do ARS... 9 Classificação de problemas no ARS...10 Classes de Utilizadores do ARS... 10 Características da Base de Dados do ARS... 11 Licenças do ARS... 11 2.4. Lotus Notes... 12 2.5. Groupware e Workflow, uma comparação entre o Lotus Notes e o ARS... 13 2.6. IT Requests Workflow... 16 2.7. Sistema de estudo e ambiente de desenvolvimento... 18 2.8. Características do projecto... 19 3. Colocação de dados dos tickets na Web (Fase I)...20 3.1. Análise do problema... 20 Problema... 20 Pedido... 22 3.2. Revisão tecnológica... 23 Remedy Web... 23 ARWeb... 24 Interface desenvolvida dentro da organização... 25 Comparação das soluções... 25 3.3. Especificação... 25 Requisitos para esta fase do projecto... 25 Utilizadores... 26 Notação... 26 3.4. Implementação... 27 Arquitectura da solução... 27 Interface gráfica... 28 Optimização das perguntas SQL... 32 Usabilidade... 33 Relatório de estágio de Miguel David v
3.5. Avaliação de resultados, melhorias e evoluções... 35 4. Integração entre o ARS e o Lotus Notes (Fase II)...36 4.1. Análise do problema... 36 4.2. Revisão tecnológica... 37 4.3. Especificação... 39 Requisitos para esta fase do projecto... 39 4.4. Implementação... 40 Arquitectura da solução... 41 Metodologia... 44 Formatos dos e-mails... 45 Segurança... 46 4.5. Avaliação de resultados, melhorias e evoluções... 47 5. Adaptação do ARS às necessidades da empresa (Fase III)...48 5.1. Análise do problema... 48 5.2. Implementação... 48 5.3. Avaliação de resultados, melhorias e evoluções... 48 6. Módulo de geração de gráficos (substituição da Fase III)...50 6.1. Análise do problema... 50 6.2. Revisão tecnológica... 50 6.3. Especificação... 51 Requisitos para esta fase do projecto... 51 6.4. Implementação... 51 Arquitectura da solução... 51 Interface gráfica... 52 6.5. Avaliação de resultados, melhorias e evoluções... 53 7. Conclusões...54 7.1. Conclusões do projecto... 54 7.2. Conclusões do estágio... 55 8. Terminologia e acrónimos...56 9. Referências e Bibliografia...59 A. Cronologia do site do Porto...63 Relatório de estágio de Miguel David vi
Índice de Figuras Figura 1 Mapa das fábricas Infineon... 2 Figura 2 Localização da Fábrica de Vila Conde... 2 Figura 3 Exemplo de um formulário do ARS... 8 Figura 4 Arquitectura do ARS... 8 Figura 5 Diagrama de classes de problemas... 10 Figura 6 Processo de pedidos e problemas... 17 Figura 7 Contexto do projecto... 18 Figura 8 Diagrama de sequência de um problema... 20 Figura 9 Diagrama de estados de um Problema (ticket)... 21 Figura 10 Diagrama de sequência de um Pedido... 22 Figura 11 Diagrama de estados de um Pedido... 23 Figura 12 Arquitectura do ARWeb... 24 Figura 13 Arquitectura da solução com o módulo HelpDesk Tickets... 27 Figura 14 Estrutura das páginas do módulo HelpDesk Tickets... 27 Figura 15 Página Inicial... 28 Figura 16 Barra de navegação e tickets abertos... 29 Figura 17 Tickets em vários estados... 29 Figura 18 Ticket... 30 Figura 19 Pesquisa avançada... 30 Figura 20 Pesquisa avançada do administrador... 31 Figura 21 Estatísticas... 32 Figura 22 Hipótese ODBC... 38 Figura 23 Arquitectura da solução com E-mail Templates... 41 Figura 24 Arquitectura da solução de integração do lado do Lotus Notes... 42 Figura 25 Diagrama de sequência de e-mails na integração (fase testes)... 43 Figura 26 Diagrama de sequência de e-mails na integração (fase produtiva)...44 Figura 27 Template de e-mail de uma pergunta ao ARS... 45 Figura 28 Template de e-mail para a submissão de um ticket no ARS... 46 Figura 29 Caso de uso da geração de relatórios... 50 Figura 30 Caso de uso após a implementação do módulo de geração de gráficos... 51 Relatório de estágio de Miguel David vii
Figura 31 Página inicial dos relatórios... 52 Figura 32 Exemplo de um gráfico gerado pelo módulo... 52 Figura 33 Inauguração oficial da fábrica... 64 Relatório de estágio de Miguel David viii
Índice de Tabelas Tabela 1 Exemplos de sistemas colaborativos agrupados por tempo e espaço [22]... 14 Tabela 2 Comparação entre o ARS e o Lotus Notes... 16 Tabela 3 Lista de prefixos de código e tipos... 26 Tabela 4 Mapeamento entre pedidos e tickets... 40 Relatório de estágio de Miguel David ix
1. Introdução 1.1. Apresentação da Infineon The name Infineon Technologies AG is derived from infinity and eon (ancient Greek for eternity), conjuring up the concepts of endless possibility, permanence, innovation and reliability characteristics that are true of a dynamic and future-oriented semiconductor company such as Infineon Technologies. [24] A Infineon Technologies AG foi fundada a 1 de Abril de 1999 como empresa do grupo Siemens que abrangia toda a área de semicondutores. Isto foi uma preparação para a oferta pública de uma parte significativa da Infineon em 13 de Março de 2000 nas bolsas de Frankfurt e Nova Iorque. No fim de 2001, a Siemens reduziu a sua participação económica nas acções da Infineon para 41,3 %. Ter-se separado da Siemens permitiu à Infineon avançar de uma forma mais dinâmica e rápida no mercado de semicondutores. Como empresa independente, a Infineon é mais flexível e pode, por isso, responder de uma forma mais eficaz a variações de mercado. Para além disso, encontra-se numa posição favorável para poder obter clientes junto dos concorrentes da empresa-mãe (Siemens). A sede da Infineon está onde a Infineon nasceu, na Alemanha, mais precisamente em Munique onde o CEO (Chief Executive Officer) da Infineon, o Dr. Ulrich Schumacher, chefia a empresa. Dividida em quatro áreas de negócio - Comunicações, Soluções Móveis Seguras, Automóveis & Electrónica Industrial e Memórias - a Infineon oferece soluções para um largo espectro de produtos semicondutores e, para tal, conta com alguns parceiros estratégicos de renome mundial: IBM, Toshiba, Nanya, Nokia, Ericsson, Cisco Systems, Alcatel e Sony. Hoje, a Infineon é uma das dez maiores empresas mundiais de semicondutores e ocupa o segundo lugar na Europa. Espalhada um pouco por todo o mundo em países como a Alemanha, Áustria, França, Inglaterra, Portugal, Estados Unidos da América, Taiwan e Malásia esta empresa tem ao todo 16 locais de manufactura e 27 centros de I&D, empregando actualmente cerca de 30 000 pessoas em três continentes. Relatório de estágio de Miguel David 1
Figura 1 Mapa das fábricas Infineon A estrutura simplificada da empresa consiste em dois tipos de fábricas: Front-End (fase inicial da produção do chip de memória) e Back-End (fase final da qual resulta o produto acabado). O site do Porto A fábrica de Vila do Conde entra nesta estrutura como um Back-End na área das memórias para computadores, isto é, recebe wafers (bolachas de circuitos integrados) das fábricas de White Oak (EUA) e Dresden (Alemanha), processa-as e envia o produto acabado (chips DRAM de 64, 128 e 256MB) para os centros de distribuição da Infineon AG, de onde vai para os clientes finais. 1 Figura 2 Localização da Fábrica de Vila Conde 1 Para mais informações sobre o site do Porto ver o anexo A. Cronologia do site do Porto Relatório de estágio de Miguel David 2
O departamento de IT O departamento de IT (Information Technologies) tem como objectivo suportar os processos centrais de negócio da Infineon Portugal. As principais áreas suportadas são: infra-estruturas informáticas, sistemas de informação, sistemas de produção, segurança e protecção de dados e administração geral. Seguindo as tendências actuais, o departamento tem uma hierarquia muito horizontal de forma a desempenhar as suas funções com flexibilidade e qualidade. No entanto, como já tem um número razoável de pessoas, está divido nalgumas áreas de actuação: IFR (Infrastructures): grupo com responsabilidades a nível das infra-estruturas informáticas; MES (Manufacturing Execution Systems): grupo que tem como objectivo fornecer soluções que aumentem a eficiência dos processos de produção; MEI (Manufacturing Equipment Integration): grupo que tem responsabilidades a nível da integração dos equipamentos de fabrico entre si e os restantes sistemas; SAP (Systems, Applications and Products): grupo que é responsável pela gestão, suporte e desenvolvimento de todas as aplicações e módulos baseados no ERP SAP R/3 (Sistema de Informação utilizado na Infineon); MDA (Manufacturing Data Analysis): grupo que trata da análise dos dados provenientes da fábrica. Existem outros grupos responsáveis por outras áreas. O projecto desenvolvido no estágio foi no âmbito do grupo de IFR. 1.2. Projecto na Infineon Contexto O projecto surgiu na IFPT a partir de uma necessidade do departamento de IT. O IT, não sendo o negócio central da empresa, serve de suporte à mesma. Assim, entre as suas principais actividades, está a manutenção de todo o material informático (software e hardware). Parte desta actividade está directamente relacionada com o Helpdesk. Isto é, todos os problemas que os colaboradores da IFPT tiverem (por ex.: rato avariado, aplicação que deixou de funcionar, máquina que não responde, etc.), assim como os seus pedidos (por ex.: instalação de programas que não constem da instalação standard do PC, requisição de portáteis, instalação de telefones, etc.) são direccionados de uma forma ou outra para o Helpdesk que trata de os resolver. Os problemas e os pedidos são designados genericamente por tickets. A necessidade geral que surgiu foi a de um melhor funcionamento do Helpdesk, uma vez que a fábrica tem aumentado nos últimos tempos e o Helpdesk deve ter todos os seus processos afinados de modo a não perder tempo útil com tarefas sem valor acrescentado. Esta necessidade geral pode ser repartida em três necessidades mais específicas. A primeira consiste na possibilidade dos colaboradores da IFPT poderem ver o estado dos seus pedidos / problemas sem terem que se deslocar junto do Helpdesk. Esta necessidade deu Relatório de estágio de Miguel David 3
origem à primeira fase do projecto: a colocação na intranet de informação sobre os tickets, em particular o estado em que eles se encontram. Para além da ferramenta utilizada pelo Helpdesk (o ARS da Remedy), existe uma ferramenta construída sobre Lotus Notes (o IT Requests Workflow) que faz a gestão dos pedidos da IFPT. A segunda necessidade consiste então na interligação dessas duas ferramentas de modo a que, mal o pedido seja autorizado na aplicação construída sobre Lotus Notes, seja automaticamente criado um ticket no ARS. Esse processo é, neste momento manual, uma vez que o Responsável pelas Operações IT, quando autoriza o pedido, tem que o imprimir e entregar em mão ao Helpdesk que, por sua vez, tem que o inserir no ARS. No fundo, esta é uma necessidade de automatização de um processo que neste momento é feito manualmente. Por fim, a terceira necessidade é a de uma adaptação do ARS às necessidades actuais da empresa. Esta necessidade surgiu porque não existe a distinção clara entre pedidos e problemas; existem campos que não são utilizados e outros que são mal utilizados; existem bugs na interface; a geração de relatórios de actividade do Helpdesk é apenas semi-automática, etc. Objectivos O projecto tem assim como objectivos principais: estabelecer um processo de gestão do Helpdesk de uma forma eficaz e alinhada com o negócio; permitir uma maior facilidade na verificação do estado dos pedidos por parte dos colaboradores da IFPT; integrar a ferramenta do Helpdesk (o ARS) no processo actual, nomeadamente com o Lotus Notes; eliminar tarefas administrativas sem valor acrescentado; reduzir o papel; adaptar e optimizar o Action Request System do Helpdesk. 1.3. Organização e estruturação do documento Este documento está dividido em oito capítulos. O primeiro é, naturalmente, a introdução. Na introdução podem encontrar-se: a apresentação da Infineon, do site do Porto e do departamento de IT assim como o projecto, os seus objectivos e contexto em que está inserido. No segundo capítulo é feita uma análise global do projecto, focando o contexto mais em pormenor. Esta análise passa por uma descrição do funcionamento do Helpdesk, uma introdução às duas ferramentas sobre as quais o projecto incide (o ARS e o Lotus Notes) assim uma comparação entre as duas. É também feita uma descrição da aplicação IT Requests Workflow e do ambiente de desenvolvimento. Os três capítulos seguintes (terceiro, quarto e quinto) correspondem às três grandes partes do projecto. Relatório de estágio de Miguel David 4
O terceiro capítulo descreve o desenvolvimento de um módulo Web denominado HelpDesk Tickets de uma aplicação já existente na fábrica chamada IT Requests Workflow. Este módulo consiste num conjunto de páginas ASP (Active Server Pages) com VBScript e JavaScript que fazem a ligação entre a base de dados utilizada pelo Helpdesk e os colaboradores da fábrica. Deste modo, os colaboradores podem ver o estado dos seus tickets. No quarto capítulo está o estudo e desenvolvimento de uma solução para a integração de duas ferramentas utilizadas no IT, o Lotus Notes (responsável pela gestão do processo de pedidos) e o ARS (responsável pela gestão de tickets no Helpdesk). O quinto capítulo refere-se à adaptação do ARS, de forma a melhorá-lo e consequentemente a melhorar a prestação do Helpdesk. O sexto capítulo diz respeito à substituição da fase de adaptação do ARS por um módulo de geração de gráficos na Web. Os capítulos terceiro, quarto, quinto e sexto apresentam uma estrutura semelhante. A primeira secção consiste na análise do problema, uma abordagem teórico-histórica de forma a introduzir o leitor no contexto do problema. A segunda secção consiste na revisão tecnológica. Esta está dividida na análise das alternativas para solucionar o problema e na escolha fundamentada de um delas. A terceira secção trata da especificação do problema, nomeadamente dos seus requisitos. A quarta secção detalha a implementação dessa solução. Finalmente, a quinta secção consiste na avaliação de resultados, melhorias e evoluções do sistema. No sétimo, oitavo e nono capítulos encontram-se, respectivamente, as conclusões do projecto, a terminologia utilizada no documento e as referências e bibliografia utilizadas. Finalmente, existe o anexo A que contém a linha temporal da fábrica do Porto desde a primeira pedra até hoje e clarifica o contexto em que decorreu o estágio. Relatório de estágio de Miguel David 5
2. Análise do problema global do projecto 2.1. O departamento de IT e a importância de um Helpdesk O IFPT IT tem como principal função ser o suporte do negócio central da empresa - o fabrico de chips de memória - sendo a sua face mais visível o Helpdesk. Como o Helpdesk é uma das principais interfaces com o resto da fábrica é importante mantê-lo com uma boa produtividade de modo a assegurar um serviço de qualidade (ver [12]). A importância da eficiência de um Helpdesk foi demonstrada através de um estudo 2 que diz que a imagem que 92% dos clientes norte-americanos têm de uma empresa é resultado da sua experiência com o Helpdesk. Para além disso, hoje em dia, graças à Web, os clientes esperam informação actualizada ao segundo, querem saber o que se está a passar no momento que estiver a decorrer. Simultaneamente, as empresas querem aproveitar dados em tempo real sobre os seus clientes, de modo a poderem prever as suas necessidades futuras. Para além de todas estas exigências, muitos Helpdesks têm ainda uma luta constante por estarem presos a tecnologia desactualizada com muito poucas capacidades de integração. Enquanto o resto das organizações de IT compram soluções mais viradas para a Web, os Helpdesks são deixados com tecnologias desactualizadas. Muitas dessas tecnologias introduzem processos desorganizados, tempos de resposta elevados, pedidos de informação repetidos que frustram os clientes e operações ineficientes que não acompanham os processos de negócio circundantes. No entanto, retirar as tecnologias desactualizadas e inserir novas não é apenas uma operação superficial, mas uma operação de grande dimensão envolvendo alteração de processos de negócio, custos de desenvolvimento e treino, e tempo de implementação. Nestes termos, é complexo gerir a introdução de melhoramentos ou até novas tecnologias nos Helpdesks sem perturbar o contínuo funcionamento dos mesmos. 2.2. O funcionamento do Helpdesk No mundo do trabalho, as condições são raramente ideais. A actividade é constantemente interrompida por telefonemas, colegas ou clientes que chegam e saem, etc. No caso de um Helpdesk (em particular o de uma fábrica com cerca de 800 pessoas durante o dia), esta situação é levada ao extremo. Casos como: dois telefones a tocar simultaneamente, vinte tarefas à espera de serem realizadas com maior e menor prioridade, colegas de fábrica a chegar para reportar ou ver o estado de um ticket são o dia-a-dia no Helpdesk. Existindo todos estes requisitos, uma boa ferramenta é crucial para o trabalho dos operadores do Helpdesk. Esta ferramenta tem que ser altamente flexível e eficaz de modo a ajudar os operadores, em vez de atrasar (e atrapalhar) ainda mais o seu trabalho. 2 Estudo realizado pela Kelly Services e o Centro da Universidade de Purdue para Qualidade Dirigida ao Cliente [18] Relatório de estágio de Miguel David 6
A inserção dos dados de um problema proveniente de uma chamada tem que ser muito rápida e a resolução de problemas típicos deve ser facilitada de modo a ser mais eficiente. Há também o problema da passagem de informação entre operadores. O Helpdesk é constituído por uma equipa de nove elementos mais um supervisor. Desta equipa há sempre dois elementos a trabalhar na fábrica a qualquer altura do dia ou da noite e pelo menos um deles deve estar na secretária pronto para receber chamadas. A existência de três turnos em cada dia torna a rotação de pessoas muito elevada, o que implica um esforço constante de passagem de informação (problemas que passam para o turno seguinte resolver). Além disso, o Helpdesk funciona como uma equipa, atribuindo problemas ou partes de problemas (tarefas) uns aos outros constantemente, o que torna a passagem de informação sobre um determinado ticket ainda mais importante. Existe também o problema da rotação dos elementos do Helpdesk na própria fábrica. Dos nove elementos, alguns têm menos de seis meses de experiência na fábrica, o que significa que a ferramenta utilizada por eles, mais concretamente a sua interface, tem de ter uma curva de aprendizagem muito rápida e fornecer soluções para os diferentes casos sempre que o problema estiver tipificado. 2.3. Action Request System Quando a Remedy Inc. introduziu o Action Request System (ARS) no mercado em 1991, este rapidamente ganhou aceitação como líder na área do Helpdesk. À medida que as empresas, maiores e menores, começaram a utilizar o ARS, aperceberam-se que o ARS podia ser muito mais que um sistema de Helpdesk. Podia ser usado para automatizar, acompanhar e gerir qualquer processo. Hoje em dia, o ARS é usado em empresas inteiras com soluções não só de Helpdesk, mas também de Gestão de Recursos e Gestão Integrada de Sistemas. O ARS foi desenvolvido a pensar em Helpdesks, Call Centers e na Gestão de Recursos tendo ao mesmo tempo em conta que os processos de negócio definidos em cada empresa são diferentes de empresa para empresa. Assim, foi criado de raiz de uma forma a que o cliente pudesse configurar o sistema na sua empresa de acordo com as suas próprias regras de negócio. Relatório de estágio de Miguel David 7
Figura 3 Exemplo de um formulário do ARS Arquitectura do ARS Figura 4 Arquitectura do ARS Relatório de estágio de Miguel David 8
A arquitectura do Action Request System (Figura 4) é baseada no modelo cliente / servidor, de três camadas. Assim, o sistema é constituído por uma base de dados, um servidor e vários clientes: uma ferramenta de administração, uma ferramenta de utilizador e uma ferramenta de notificação (ver [2], [3] e [7]). A base de dados sobre a qual o servidor do ARS assenta é Oracle e serve não só como armazenamento mas também como motor de pesquisa. O servidor de ARS controla todos os processos de Workflow e acessos à base de dados. A ferramenta de administração, por sua vez, é a interface através da qual o administrador desenvolve e modifica as aplicações. A ferramenta de utilizador é a interface para o acesso diário ao sistema e consiste num conjunto de formulários que servem de interface com os utilizadores finais. Esta ferramenta é usada para gerar relatórios, inserir, pesquisar e modificar tickets. Finalmente, a ferramenta de notificação é uma pequena aplicação que corre em segundo plano no computador do utilizador e o alerta para eventos, como por exemplo a atribuição de um ticket. Componentes do ARS A componente principal do ARS é o formulário. Este agrega, na sua definição, um conjunto de campos que, por sua vez contém a informação dos tickets. Estes campos podem ser caracteres simples, datas, diary (campos equivalentes a áreas de texto), numéricos, botões de rádio (radio buttons), caixas de selecção (comboboxes), tabelas, botões, etc. Outro componente é o menu. Este pode ser sensível ao contexto e variar conforme o mesmo. O terceiro componente é o active link, uma acção (ou grupo de acções) realizada(s) do lado do cliente cuja função é, tipicamente, a verificação de dados e o preenchimento automático de campos do formulário. O quarto componente é o filtro. Pode-se considerar o filtro como o complemento do active link, uma vez que tem como função disparar acções, mas do lado do servidor. As suas funções são normalmente assegurar a integridade do sistema e dos dados. Pelas suas funções, pode-se comparar um filtro a um gatilho num sistema de gestão de base de dados. O quinto componente é o escalamento. De uma forma semelhante aos dois componentes anteriores, um escalamento é um conjunto de acções disparadas dependendo do estado de certos tickets, mas desta feita a intervalos regulares de tempo. Relatório de estágio de Miguel David 9
Classificação de problemas no ARS Figura 5 Diagrama de classes de problemas Cada problema é classificado de acordo com uma classe de problema (por ex.: OS: NT ou Hicom: Configuration ). Uma vez classificado de uma forma genérica, o problema pode ser típico ou não. Se não o for, fica apenas classificado pela classe a que pertence. Se o for, escolhe-se o tipo específico de problema em questão (por ex.: Verificar Serviços Servidor ou Hicom Access, respectivamente para os exemplos das classes acima mencionadas) e alguns dos campos do formulário são automaticamente preenchidos. Simultaneamente há uma sequência de tarefas que é automaticamente aberta. Para resolver e fechar esse problema, o operador tem que cumprir todas as tarefas. Deste modo, evita-se que o operador se esqueça de um passo ao resolver o ticket. Classes de Utilizadores do ARS O ARS tem seis classes de utilizadores directos: o administrador, o administrador de conteúdos 3, os operadores do Helpdesk, a equipa de Backline (equipa de administração de sistemas), a equipa IT, o suporte externo e os restantes colaboradores da IFPT. O administrador é um utilizador especialista no sistema, em todas as suas vertentes: ferramentas de administração, de utilização, base de dados do sistema e e-mail do sistema, entre outras: alterar interfaces, acrescentar / modificar / retirar categorias, alterar permissões dos utilizadores ao sistema e alterar a lógica de negócio. O administrador de conteúdos é um utilizador conhecedor da ferramenta de administração. Este pode: acrescentar / modificar / retirar categorias, alterar a lógica de negócio, determinar quão crítico é um ticket e atribuir tickets (uma vez que o Helpdesk acumula a função de Helpdesk e Call Center onde a triagem seria feita). Os operadores do Helpdesk são utilizadores conhecedores da ferramenta de utilizador (User Tool) do ARS. Têm como tarefas: criar tickets, resolver / alterar tickets, atribuir tickets e fechar tickets. 3 Neste momento o administrador e os operadores do Helpdesk acumulam também parte da função de administrador de conteúdos. Relatório de estágio de Miguel David 10
A equipa de Backline isto é, a equipa de administração de sistemas (de bases de dados, de sistemas NT e Unix, etc.) é um grupo de utilizadores conhecedor da ferramenta de utilizador (User Tool) do ARS. Pode resolver / alterar e atribuir tickets. A equipa IT é constituída por um grupo de utilizadores conhecedor da ferramenta de utilizador (User Tool) do ARS. Pode resolver / alterar e atribuir tickets. O suporte externo consiste num conjunto de utilizadores externos sem qualquer conhecimento do sistema (por vezes com sistemas equivalentes próprios da sua empresa). O seu papel é receber tickets, resolvê-los e passar o controlo de novo ao Helpdesk, sem qualquer interacção directa com o sistema Action Request. Por fim existem os restantes colaboradores da IFPT. Estes não têm qualquer interacção directa com o sistema, porém podem pedir ao Helpdesk para criar tickets e podem não aceitar a resolução de um ticket pedindo ao Helpdesk para voltar a colocar o ticket no estado inicial. Características da Base de Dados do ARS Para tornar o ARS num sistema totalmente flexível, permitindo aos administradores o mapeamento das suas regras de negócio e processos de uma forma fácil, a base de dados do sistema é gerada automaticamente e não criada. Isto quer dizer que a criação de um campo num formulário pelo administrador do sistema corresponde à criação de (pelo menos) um campo numa tabela da base de dados. O resultado tem um lado positivo e um lado negativo. O resultado positivo advém de se ter um sistema totalmente adaptável às necessidades do cliente, não preso à partida por um esquema de uma base de dados subjacente ao mesmo sistema. O resultado negativo advém de se ter uma base de dados com um modelo não utilizável directamente pelos programadores de aplicações, e que é constituída por um conjunto de tabelas sem chaves externas a estabelecer ligação entre elas, com índices quase apenas nas suas chaves primárias e nomes imperceptíveis, tanto para as tabelas como para os campos uma vez que existem restrições 4. Esta situação não é alterável, uma vez que a interacção com os programadores de aplicações só pode ser feita a um nível mais abstracto, na configuração do ARS. Licenças do ARS O modelo de comercialização do ARS por parte da Remedy é baseado na venda de licenças para utilizar o seu software. Quando um utilizador se liga no ARS, ocupa uma licença. Existem três tipos de licenças: Fixa Flutuante Esta licença garante que sempre que o sistema estiver operacional, o utilizador pode ligar-se. É o equivalente a uma garagem onde se estaciona o carro. Esta licença garante que, se o sistema estiver operacional e existirem licenças 4 Restrições: o intervalo de números [1, 99] está reservado para campos chave (core fields), o intervalo [100, 536870911] está reservado para campos registados pela Remedy, apenas se pode utilizar o intervalo [536870913, 2147483647] Relatório de estágio de Miguel David 11