HELP TO ENTERPRISE SOLUTION

Transcrição

1 HELP TO ENTERPRISE SOLUTION Mateus Zanatta Dias Vanessa Lindemann - Orientadora Universidade Luterana do Brasil (ULBRA) Curso de Sistemas de Informação Campus Canoas Av. Farroupilha, Bairro São José CEP Canoas RS RESUMO 29 de novembro de 2010 Com a crescente utilização dos recursos de tecnologia da informação em todos os segmentos de negócios, é necessário que as empresas contem com uma consultoria adequada no momento de dimensionar o seu ambiente de hardware. Isso obriga os fornecedores de solução de informática a terem uma estrutura adequada para poder de fato prestar um atendimento ágil e confiável para seu cliente, mas nem sempre é possível acompanhar esse crescimento e dispor dos melhores profissionais e ferramentas para atender toda a demanda do mercado. Baseado neste contexto, o presente artigo descreve um sistema que será utilizado pelos representantes de vendas de uma empresa montadora de hardware, e será capaz de analisar o perfil de uma determinada empresa (cliente) e suas necessidades técnicas para propor a melhor solução possível, informando o modelo ideal de servidor e sua configuração item a item. Palavras-chave: raciocínio baseado em casos; sistema de apoio a decisão. ABSTRACT Title: Help to Enterprise Solution With the growing information technology utilization in all business segments, it is necessary that every company can count on the appropriately consulting when sizing its hardware environment. This forces the solution suppliers to have an appropriate structure in order to actually provide an agile and reliable attendance for their customers, but is not always possible to monitor this growth and to provide professional and appropriate tools to meet the market demand. Based on this background, this article describes a system that will be used by sales representatives of a hardware assembler company and be able to analyze the whole profile of an specific company (client) and their technical needs to propose the best possible solution, informing the ideal model of server and its configuration item by item. Key-words: system of case-based reasoning; decision support system. 1 INTRODUÇÃO O presente trabalho tem como propósito o desenvolvimento de um Sistema de Apoio a Decisão (SAD) para empresas que vendem soluções de TI (Tecnologia da Informação) para o mercado corporativo. Este sistema, denominado Help to Enterprise Solution, utiliza a abordagem de Raciocínio Baseado em Casos (RBC) para dimensionar soluções complexas relacionadas à venda de servidores. Atualmente, quando o cliente liga para o representante de vendas da empresa com a intenção de adquirir um servidor, existe a necessidade de se fazer uma conferência com um consultor técnico para definir a configuração do equipamento. O grande problema é justamente a alocação deste recurso humano, principalmente em horários de maior demanda de ligações. O software Help to Enterprise Solution faz a escolha do servidor adequado para o cliente, considerando as informações sobre o ambiente e as necessidades da empresa, que são obtidas através da interação deste com o usuário (representante de vendas). A motivação para o desenvolvimento deste projeto surgiu, pois a maioria das empresas em funcionamento no Brasil utilizam a informática para otimizar seus processos e desempenhar suas atividades. Nessa estrutura de TI o coração, ou seja, o equipamento mais importante e que não pode parar de trabalhar é o servidor. Por isso a importância de se dimensionar corretamente a configuração e o porte do equipamento que a organização necessita. O porte refere-se ao modelo (chassi), configuração item a item, nível de segurança e garantia mais adequada à organização. Neste ponto, tem-se um nicho muito grande de mercado e consequentemente uma oportunidade, sobretudo para empresas que não possuem uma estrutura de TI dedicada e contam com uma consultoria 1

2 muitas vezes inadequada para apresentar a solução correta. Outros motivos como restrição de orçamento por parte da empresa, ou terceirização do suporte de TI podem influenciar para um retorno não tão qualificado. O software Help to Enterprise Solution visa preencher esta lacuna, analisando as características de cada empresa e considerando soluções bem sucedidas indicadas em situações similares, o sistema efetua a cotação do servidor a ser adquirido pela empresa. Como mencionado anteriormente, o principal objetivo do presente trabalho é o desenvolvimento de um Sistema de Apoio a Decisão para eliminar a obrigatoriedade de alocação de recurso técnico para a cotação de servidores. Desta forma o envio da proposta para o cliente será muito mais ágil e o consultor técnico poderá ser engajado a outros projetos de acordo com o interesse da organização. Alguns pontos são fundamentais para o sucesso do projeto: o sistema deve ser fácil de utilizar, com uma interface limpa e objetiva e que interaja de uma forma prática com o usuário para entender como a empresa trabalha atualmente e o que ela precisa. O usuário deve perceber o sistema como um facilitador e não como mais uma ferramenta para tornar suas ações complexas. Uma das características essenciais do sistema é sua capacidade de visualizar diversos cenários e propor uma solução adequada a cada um deles. A metodologia de desenvolvimento do presente trabalho foi dividida em etapas: (a) pesquisa bibliográfica sobre Sistemas de Apoio à Decisão, mais especificamente a abordagem de Raciocínio Baseado em Casos (RBC); (b) levantamento e estudo das tecnologias utilizadas para o desenvolvimento deste trabalho; (c) desenvolvimento do sistema RBC (definição dos casos, aquisição do conhecimento, indexação, implementação do algoritmo de recuperação); por fim, (d) a validação do sistema criado. A etapa de aquisição do conhecimento foi realizada em uma grande empresa que vende soluções de TI para o mercado corporativo, contando com a participação de representantes de vendas e consultores técnicos. Os casos que formam a base de conhecimento do software Help to Enterprise Solution foram criados a partir dos registros de atendimentos de 30 dias cuja venda do servidor tenha sido efetivada. Esse período é o tempo necessário para o cliente receber o equipamento, instalar e utilizar na sua empresa, de modo que todos os casos que fazem parte da base de conhecimento passaram por uma aprovação, que nada mais é que uma ligação para o cliente com o intuito de identificar se o servidor atendeu às necessidades da empresa, sobretudo com relação à performance e confiabilidade. Com o uso do software Help to Enterprise Solution o representante de vendas deve coletar algumas informações com o cliente que serve para conhecer o ambiente de TI da empresa. Esses dados incluem o parque de máquinas (quantidade total de desktops, notebooks e servidores), as aplicações que serão instaladas no servidor (banco de dados, servidor de arquivos, etc.), quantidade de usuários que acessarão simultaneamente o sistema, etc. Com base nestas informações, o sistema RBC compreende diferentes cenários e apresenta a solução adequada ao perfil da empresa. Essa solução inclui o modelo do equipamento, a definição da configuração item a item deste equipamento (quantidade e modelo do processador, memória, tamanho de disco e modelo SAS ou SATA, fonte única ou redundante, nível de raid,etc.), além do suporte mais aconselhável (no próximo dia útil, 24 horas por dia, atendimento em até 4 horas no local, etc.). Por fim, a etapa de validação contou com a participação dos representantes de vendas e consultores técnicos da empresa que fizeram parte da etapa de aquisição do conhecimento. Esta etapa foi fundamental para medir a eficiência do sistema, tanto no quesito técnico quanto comercial, construindo uma base de casos íntegra e verificando se o sistema apresentou soluções que de fato sejam recomendadas para cada necessidade. O presente artigo está dividido em seis seções. A fundamentação teórica é apresentada na seção 2, onde são abordados temas pertinentes à realização do trabalho. A seção 3 é dedicada à descrição da metodologia adotada, descrevendo as etapas executadas, necessárias para atingir o objetivo a que o trabalho se propôs. Os resultados obtidos são abordados na seção 4, que apresenta o sistema desenvolvido e explica suas principais funcionalidades. As considerações finais são descritas na seção 5, seguidas das referências utilizadas durante o desenvolvimento do trabalho. 2

3 2 FUNDAMENTAÇÃO TEÓRICA Esta seção consiste na apresentação de algumas definições acerca de Sistemas de Apoio a Decisão (SAD) e de Raciocínio Baseado em Casos (RBC), conceitos necessários à compreensão das motivações e dos objetivos da aplicação proposta neste trabalho. 2.1 Sistemas de Apoio à Decisão Resultantes da evolução de hardware e software, no início da década de 70 começaram a surgir os primeiros sistemas de apoio à decisão, com o objetivo de dar um suporte maior ao decisor para que o mesmo faça a escolha correta em uma determinada situação. Para Sprague e Watson (1991, p.98) os sistemas de apoio à decisão são sistemas computacionais desenvolvidos com o objetivo de melhorar a eficiência dos responsáveis pela tomada de decisões na realização de atividades semi-estruturadas. A tomada de decisão está presente na rotina de líderes e/ou diretores de organizações e o SAD pode auxiliar em todas as fases deste processo, nas etapas de desenvolvimento, comparação e classificação dos riscos, além de fornecer subsídios para optar por alternativas adequadas. O SAD é utilizado principalmente para resolução de problemas mais complexos e menos estruturados, combina técnicas analíticas com acesso e recuperação de informações, deve ser dinâmico e interagir com o usuário e possuir uma interface amigável. Além disso, deve se adaptar a mudanças no ambiente. Figura 1: Componentes de um SAD (LAUDON, 2004) A Figura 1 apresenta os principais componentes de um SAD. O banco de dados é uma coletânia de dados gerada do processamento utilizado pela empresa, e é composto de informações internas (objetivos, metas, estratégias) e informações externas. O software gerenciador contém as várias formas de ferramentas empregadas para análise de dados, e a interface deve prover a interação entre o usuário do sistema e as ferramentas disponíveis no SAD. Segundo Binder (1994, p.41) um SAD não é um sistema simples e também não são simples as tarefas as quais ele se propõe a resolver. A empresa deve, portanto, estar preparada para o advento desses sistemas, visando uma utilização ótima e sem trauma. Para atingir esse objetivo, o autor salienta que é fundamental a organização possuir os seguintes processos: suporte eficaz da equipe de TI: planejar e organizar as atividades referentes ao SAD, promover o uso do SAD, avaliar hardware e software para o SAD, realizar treinamentos, etc; 3

4 sistemas de informação eficientes e eficazes: sistemas flexíveis e preparados para mudança, execução rápida e cumprimento dos objetivos desejados; sistemas de informação integrados: saber quais são as informações necessárias, como gerá-las e quem necessita delas. Existem diversas técnicas para desenvolvimento de SADs, cada uma delas com um propósito e uma metodologia. Uma das abordagens mais utilizadas é o Raciocínio Baseado em Casos. 2.2 Raciocínio Baseado em Casos O Raciocínio Baseado em Casos (RBC) é uma abordagem da Inteligência Artificial baseada no modelo de cognição e comportamento humano, e tem como objetivo propor a solução de novos problemas, relembrando situações anteriores que foram semelhantes e adaptá-las para a situação atual. Através da similaridade, é realizada a comparação do novo caso com os casos previamente cadastrados pelo especialista da área, para então oferecer a solução mais adequada. Wangenheim e Wangenheim definem um caso como uma peça de conhecimento contextualizado representando uma experiência ou episódio concretos. Contém a lição passada, que é o conteúdo do caso e o contexto em que a lição pode ser usada. (2003, p.63) O conteúdo de cada caso depende do domínio de sua aplicação e o objetivo do raciocínio, então possuem diferentes formas e representações, mas todos são compostos de dois componentes principais: problema e solução. O problema contém exatamente a sua descrição e a situação que foi resolvida. Já a solução pode ser uma ação ou plano útil para o usuário descrever como um determinado problema foi resolvido. Além disso, pode-se ter um terceiro componente chamado avaliação, onde de fato a eficácia da solução é avaliada. Em um diagnóstico médico, por exemplo, o problema são as informações sobre o paciente (peso, idade, sexo, doenças prévias, sintomas, etc.) e a solução é a descrição da doença descoberta e o tratamento aplicado. Outro exemplo de caso é ilustrado na Figura 2, cujo domínio é a computação. Figura 2: Exemplo de um caso O modelo clássico para entendimento do processo de RBC é o ciclo elaborado por Aamondt e Plaza (1994), composto de quatro tarefas principais conforme destacado na Figura 3. 4

5 Figura 3: Ciclo do Raciocínio Baseado em Casos (AAMODT, 1994) O processo de recuperação inicia mesmo que não exista uma combinação perfeita, este mecanismo permite recuperar os casos mais similares na base de dados. Neste caso se os valores das características do novo caso forem semelhantes aos valores das características dos casos anteriores, são aplicadas as medidas de similaridade. Então a etapa chamada reuso reutiliza e se for necessário ajusta a solução recuperada para se adaptar ao novo problema. Normalmente é utilizada a adaptação estrutural, cujas regras são aplicadas diretamente na solução dos casos armazenados. Na revisão é realizada a avaliação da solução e, se necessário, a solução proposta é revisada. Por fim, a retenção salva o novo caso na base de dados e consequentemente a experiência é armazenada para reutilização futura. Os processos principais do ciclo de um sistema RBC, apresentados na Figura 3, são descritos por Wangenheim e Wangenheim (2003): Medida de similaridade: através da descrição do problema atual é realizada uma busca nos casos cadastrados na base de dados. Para isto, utiliza-se a indexação e aplica-se o cálculo da similaridade entre a descrição do problema atual e a descrição de cada caso na base de dados, com o objetivo de ordenar os casos de acordo com o seu valor de similaridade para indicar possíveis soluções para o problema presente. Adaptação: após transferir para a situação atual a solução dos casos recuperados, a mesma é adaptada para que atenda todas as necessidades da situação presente. Define-se por isso uma reutilização com adaptações, em que diversos tipos de alterações podem ser implementadas através de diferentes técnicas, desde as mais simples como uma cópia da solução, até as mais complexas com diversos tipos de regras e condições. Revisão: com a solução já adaptada, a mesma é validada e se for preciso é corrigida. Para isso são utilizados critérios que vão desde a qualidade da solução e a facilidade de entendimento da solução pelo usuário, à complexidade para implementar determinada solução. Aprendizado e integração do conhecimento: quando um novo problema é solucionado, a nova experiência pode ser armazenada na base de dados para ajudar na resolução de problemas futuros. Então o conhecimento representado pelo caso é renovado, e também outras informações como processo de recuperação e adaptação pode ser inserido na base de dados para ajudar a medir o desempenho do sistema de RBC. A recuperação de casos adequados é uma etapa crucial para o sucesso de um sistema RBC. O algoritmo do vizinho-mais-próximo (MICHIE, 1994), utilizado para a recuperação de casos, é indicado para problemas com base de dados relativamente pequena e com poucos atributos indexados, devido ao volume 5

6 de cálculos necessário para determinar cada um dos atributos indexados e cada um dos casos. Ele se baseia na comparação entre um novo caso e aqueles armazenados no banco utilizando uma soma ponderada de suas características, conforme ilustra a Figura 4. Figura 4: Fórmula do algoritmo do vizinho-mais-próximo (MICHIE, 1994) Analisando a Figura 4, considera-se n um novo caso e x os casos já existentes na base de dados. O número total de características é identificado por Ʃf, e w é o peso do atributo f. Por fim, sim é a função de similaridade para os atributos f nos casos x e n. Dois aspectos são cruciais para garantir a recuperação precisa e eficiente de casos, utilizando o algoritmo do vizinho-mais-próximo: a definição de pesos, vinculados às características que compõe os casos; e a indexação dos casos, que apontam as características que devem ser comparadas, determinando o que é útil para encontrar soluções adequadas Estado da Arte em Raciocínio Baseado em Casos Existem diversos projetos que foram implementados utilizando Raciocínio Baseado em Casos (RBC). Um exemplo clássico é o Judge (BAIN, 1984 apud LEE, 1998), que cria sentenças para crimes de assassinatos praticados por delinquentes adolescentes a partir de situações de brigas. A sentença é construída com base em características do crime (quem iniciou a luta, grau de violência e quais as chances do acusado repetir o crime) e em adaptações realizadas sobre uma situação similar. Em 1986, Christian Hammond desenvolveu o sistema Chef (apud CAMARGO, 1999), que tem como domínio o planejamento de receitas. Através de lembranças de receitas que foram utilizadas com sucesso em situações similares, o sistema planeja e modifica as receitas de acordo com as novas condições impostas pelo problema de entrada, que é um conjunto de objetivos que devem ser atendidos. A solução por sua vez, é composta por sugestões de receitas. Outro projeto conhecido neste mesmo domínio de aplicação chama-se Camp. Desenvolvido por Marling em 1996 (apud CAMARGO, 1999), o sistema elabora cardápios diários através da combinação entre os ingredientes, recomendações de um especialista em nutrição e preferências pessoais do indivíduo referente ao tipo de refeição e quantidade diária Tecnologias de Desenvolvimento de Sistemas RBC Esta seção é dedicada à apresentação de algumas ferramentas utilizadas para o desenvolvimento de sistemas RBC. CBR Works: desenvolvido pela empresa TecInno/Empolis (WANGENHEIM E WANGENHEIM, 2003), é a ferramenta mais conhecida para RBC. O software é homologado para diferentes plataformas de sistemas operacionais e suas principais características são medidas de similaridade padrão pré-definidas, pesos associáveis a atributos para definir a importância de características de conceitos, assistentes de modelagem para tipos e conceitos, editores gráficos para modelos de conhecimento complexos. Além disso, possui uma interface web que torna o ambiente amigável para o usuário. Case-1: desenvolvido pela Astea Internacional (WATSON, 1994), os casos são representados em texto, de forma livre, que descreve um problema e um conjunto de questões ponderadas que podem confirmar ou rejeitar determinadas soluções. Os casos são armazenados em um banco de dados relacional e a interface é desenvolvida utilizando o Visual Basic. Pode ser utilizado por pessoas que não possuem experiência nenhuma em programação. 6

7 Recall: da companhia Isoft (WATSON, 1994), oferece uma combinação do algoritmo do vizinhomais-próximo e caso indutivo de recuperação. É desenvolvido na linguagem C++ e oferece diferentes métodos para analisar automaticamente a base de dados que prevê a seleção de índices, embora desenvolvedores experientes também possam impor sua própria organização. 3 METODOLOGIA A metodologia, como o próprio significado da palavra diz, é o estudo dos métodos, e deve explicar de forma detalhada cada etapa do trabalho desenvolvido. Serão apresentadas com uma descrição minuciosa as características do projeto, como cada etapa foi realizada, a interação do usuário com o sistema, criação da base de dados, e demais processos que foram fundamentais para a implementação do sistema. 3.1 Análise de requisitos O software Help to Enterprise Solution descrito neste artigo tem como objetivo escolher o modelo de servidor apropriado a uma empresa, bem como definir suas configurações e o nível de suporte aconselhável para a situação apresentada. Para isso, o sistema avalia o cenário em que o equipamento será utilizado e a necessidade de cada empresa. O representante de vendas, usuário que interage com o sistema, é responsável por coletar as informações junto ao cliente. Figura 5: Diagrama de atividades (processo atual) O diagrama de atividades representado na Figura 5 demonstra como é realizado o processo atual de envio de uma proposta para o cliente. O representante de vendas inicia o atendimento, faz a coleta de dados junto ao cliente e como pode-se perceber é necessário fazer uma conferência entre o representante de vendas, consultor técnico e o cliente para a elaboração da proposta. Este é o grande gargalo que deve ser eliminado no processo uma vez que dificilmente encontra-se um consultor técnico livre para participar imediatamente na ligação. 7

8 O projeto desenvolvido implantou um sistema que analisa toda a entrada de dados realizada pelo representante de vendas; compara a situação atual com situações anteriores e recupera soluções adotadas em situações similares; e, por fim gera o descritivo da solução para que possa ser criada a proposta para envio ao cliente. Com isso o consultor técnico será alocado somente para soluções que envolvam uma complexidade maior, terá tempo para investir em outros projetos de interesse da organização, e estará disponível sempre que necessário para eventuais dúvidas que outras áreas possam ter. Figura 6: Diagrama de casos de uso A Figura 6 apresenta o diagrama de casos de uso, onde o processo para a definição da solução e envio da proposta sofre alteração e elimina o problema de alocação de recurso humano. Primeiramente o usuário informa ao sistema qual será a utilização do servidor. Para cada tipo de utilização será definido um modelo, ou seja, um chassi que tenha capacidade de receber as configurações ideais para aquele determinado uso, levando em consideração o formato do servidor que a empresa pretende adquirir: torre ou rack. As opções de equipamentos e os níveis de suporte disponíveis no sistema são baseados no portfólio atual de servidores comercializados no Brasil pela Dell Computadores, conforme os Quadros1 e 2. Utilização / aplicação Quadro 1: Portfólio de equipamentos Modelo indicado no formato Torre Modelo informado no formato Rack Servidor de arquivos Dell PowerEdge T410 Dell PowerEdge R410 Servidor de aplicação Dell PowerEdge T610 Dell PowerEdge R610 Servidor de banco de dados Dell PowerEdge T710 Dell PowerEdge R710 Servidor de arquivos e aplicação Dell PowerEdge T610 Dell PowerEdge R610 Servidor de arquivos e banco de dados Dell PowerEdge T710 Dell PowerEdge R710 Servidor de aplicação e banco de dados Dell PowerEdge T710 Dell PowerEdge R710 Servidor de aquivos, aplicação e banco de dados Dell PowerEdge T710 Dell PowerEdge R710 8

9 Quadro 2: Níveis de suporte e garantia Nível de suporte e Garantia Garantia onsite com atendimento no local no próximo dia útil Garantia onsite com prosupport e atendimento via telefone 24 horas por dia Garantia com missão crítica e suporte no local em até 4 horas Após o sistema definir o modelo do servidor, serão realizadas diversas perguntas para o usuário, com o intuito de conhecer a estrutura de TI da empresa e também obter mais informações sobre as necessidades do cliente. Com isso, o sistema poderá visualizar o cenário apresentado com maior precisão e, consequentemente, propor a solução ideal, identificando o porte da empresa e sua possibilidade de crescimento para oferecer uma solução que atenda às necessidades atuais e também esteja preparada para a demanda futura. Os questionamentos sobre o parque de TI da organização, bem como a criticidade do servidor na empresa, utilizada para definir o tempo de resposta que o suporte precisa ter em caso de problema na máquina, devem ser semelhantes, ou até mesmo iguais, entre os diferentes modelos de servidores. Mas o sistema também possui perguntas distintas para investigar os detalhes sobre a utilização específica do equipamento, ou seja, as interações entre o usuário e o software variam de acordo com o uso do servidor que será configurado. Na prática significa dizer que as perguntas para definir a configuração do servidor de arquivos são diferentes das perguntas utilizadas para definir a configuração do servidor de banco de dados, por exemplo. Com o término da coleta de informações, o sistema considera todos os pontos apresentados, sendo que cada resposta terá um peso associado a ela, e executa o algoritmo do vizinho-mais-próximo que calcula o grau de similaridade entre o problema a ser resolvido e os casos já armazenados na base de casos, recuperando todos os casos cuja distância calculada seja inferior ou igual ao limiar de similaridade definido previamente. 3.2 Desenvolvimento O desenvolvimento do sistema baseou-se no ciclo de sistema RBC proposto por Aamodt (1994). Antes do início das etapas do ciclo propriamente dito, foi preciso definir a estrutura dos casos que compõem a base de conhecimento do sistema proposto, bem como a forma como seria realizada a aquisição deste conhecimento. Cada caso é composto da descrição do problema e da solução. A descrição do problema refere-se às necessidades de uma determinada empresa em relação ao servidor, bem como ao contexto desta empresa, de forma que cada característica terá um determinado peso. Já a solução do problema, será composta do modelo do servidor, a sua configuração completa e a opção de suporte. A aquisição do conhecimento tem como objetivo extrair o conhecimento utilizado pelo especialista humano na solução de problemas, descrevendo sua perícia no formalismo computacional. O especialista humano selecionado para fazer parte do presente projeto foi um profissional que possui mais de três anos de experiência na empresa, e atualmente é um dos responsáveis por elaborar as propostas técnicas de servidores. Através de seu conhecimento e experiência, foi construída uma base de casos, registrando no sistema inúmeros casos que atenderam diferentes necessidades, todos baseados em atendimentos reais e que foram exemplos de sucesso, tendo aprovação do próprio cliente. Além disso, a empresa possuiu registro de todos os atendimentos já realizados, então cada atendimento pôde ser avaliado. Para a formação da base de dados inicial, foram considerados 30 casos em que a venda foi concretizada junto ao cliente e não houve nenhum histórico de reclamação ou contato com o pós-venda, e para a criação completa da base de dados o especialista esteve disponível para reuniões semanais que foram pré-agendadas conforme necessidade. O especialista também analisou cada caso cadastrado na base de dados e se certificou que todos possuem características diferentes para poder atender uma quantidade significativa de cenários apresentados. Formar a 9

10 base de casos é uma etapa fundamental para o sucesso de um sistema de RBC. Cada característica apresentada precisa ser avaliada para que a solução proposta esteja de acordo, sendo o mais indicado para aquela situação. Os itens que compõem a descrição do problema referem-se às características do servidor, obtidas através de perguntas que são executadas pelo sistema RBC ao usuário, e variam conforme a utilização do servidor. As perguntas foram divididas por níveis de importância, quanto maior for o nível, maior será também sua importância. Conforme o Quadro 3, as três primeiras perguntas tem um nível alto (nível 3) pois definem o uso do equipamento (cenário) e os demais questionamentos a serem feitos ao usuário. A quarta pergunta possui nível mais alto (nível 4), pois define o chassi do equipamento, e o sistema precisa evitar que o usuário solicite por exemplo um servidor no formato torre e seja retornado para ele a solução de um servidor no formato rack. Portanto o nível refere-se ao peso atribuído a cada pergunta. Os níveis 1 e 2 configuram a quantidade e modelo de processador, memória RAM, tipo e tamanho de disco rígido, fonte redundante, e suporte adequado para o equipamento. Ainda analisando o Quadro 3, pode-se observar que os casos são divididos pelo tipo de uso do servidor e cada grupo de casos tem um determinado número de características. Depois de ter realizado todas as perguntas, o sistema aplica o cálculo de similaridade para obter o resultado e indicar as soluções cadastradas já utilizadas anteriormente em situações similares, que são menores ou iguais ao limiar de similaridade definido. Quadro 3: Exemplo de perguntas para usos diferentes de servidores Peso Perguntas para servidor de arquivos Objetivo Perguntas para servidor de banco de dados Objetivo Nível 3 O equipamento será utilizado para servidor de arquivos? Definir uso e chassi do equipamento O equipamento será utilizado para servidor de arquivos? Nível 3 O equipamento será utilizado para servidor de aplicação? Definir uso e chassi do equipamento O equipamento será utilizado para servidor de aplicação? Nível 3 O equipamento será utilizado para servidor de banco de dados? Definir uso e chassi do equipamento O equipamento será utilizado para servidor de banco de dados? Nível 4 O formato do servidor deve ser torre ou rack? Definir chassi torre ou rack O formato do servidor deve ser torre ou rack? Definir chassi torre ou rack Nível 1 Quantos usuários acessarão o servidor simultaneamente? Selecionar modelo e número de processadores Quantos usuários acessarão o servidor simultaneamente? Selecionar modelo e número de processadores Nível 1 Qual é o número total de equipamentos no parque de TI atual da empresa? Selecionar modelo e número de processadores Qual é o número total de equipamentos no parque de TI atual da empresa? Selecionar modelo e número de processadores Nível 1 Quantos funcionários a empresa possui? Selecionar modelo e número de processadores e memória RAM Quantos funcionários a empresa possui? Selecionar modelo e número de processadores e memória RAM Nível 1 Número de filiais que a empresa possui? Definir Memória RAM Número de filiais que a empresa possui? Definir Memória RAM 10

11 Nível 1 Que tipo de arquivos serão armazenados (texto, imagens, vídeos)? Definir tipo do disco (Sata ou SAS) Número de servidores que a empresa possui em funcionamento na rede? Definir memória RAM Nível 3 Tamanho livre que será necessário de espaço em disco no total (em GB)? Definir tamanho do disco Tamanho livre que será necessário de espaço em disco no total (em GB)? Definir tamanho do disco Nível 2 Os arquivos que serão armazenados no servidor são importantes para o funcionamento da empresa? Definir tipo de raid e se terá fonte redundante Os arquivos que serão armazenados no servidor são importantes para o funcionamento da empresa? Definir tipo de raid e se terá fonte redundante Nível 2 Qual será a criticidade para a empresa no caso do servidor parar de funcionar? Definir tipo de suporte Qual será a criticidade para a empresa no caso do servidor parar de funcionar? Definir tipo de suporte Nível 1 Qual banco de dados será utilizado no servidor? Definir tipo do disco (Sas ou Sata) Nível 2 Será realizado cluster no servidor? Definir upgrade de processador e memória A indexação permite a localização de casos similares na base de dados a partir de um problema dado, para isso foi preciso definir quais atributos são usados para comparar o caso com a situação atual. Os casos que formam a base de casos deste sistema foram indexados manualmente, e os casos são analisados individualmente para construir a solução. A indexação foi realizada no momento da geração do caso, quando foi criada uma estrutura somente com as características relevantes à decisão. Após todos os casos serem homologados pelo especialista, os mesmos foram agrupados por cenários (tipos de utilização do servidor) para serem cadastrados na base de casos de uma forma sequencial, criando assim uma indexação correta através de uma tabela organizada. Além disso, conforme demonstrado no Quadro 3, cada pergunta possui um determinado peso que será considerado no algoritmo do vizinho-maispróximo para localizar os casos que possivelmente possam formar a solução. Um exemplo claro de indexação na base de casos deste projeto é que cada tipo de utilização do equipamento tem um modelo de chassi de servidor pré-definido para ser configurado, demonstrado no Quadro1. Portanto, conforme mencionado anteriormente, a indexação permitirá uma rápida localização de casos similares, considerando as características mais relevantes para decisão. Neste exemplo da definição do chassi do equipamento, a indexação é realizada através das perguntas iniciais efetuadas pelo sistema, buscando imediatamente o grupo de casos que possuem o chassi adequado para a utilização, e selecionando um ou mais casos de acordo com o valor do limiar de similaridade que foi definido. Com os casos definidos e os valores atribuídos a eles, pôde-se iniciar a etapa de recuperação, que consulta a base de dados validada e cadastrada pelo especialista para então aplicar as medidas de similaridade e recuperar o caso mais próximo do cenário que está sendo apresentado. Esse processo é realizado através da aplicação do algoritmo do vizinho-mais-próximo. A etapa de reuso reutiliza a solução do caso armazenado que foi selecionado para resolver o problema atual. As adaptações no caso são realizadas pelo especialista técnico e, caso a adaptação seja aprovada, o novo caso é inserido na base de casos. Dando sequência ao ciclo, a fase de revisão é constituída da validação da solução proposta para garantir que a mesma atenda às necessidades apresentadas no momento. 11

12 A última etapa presente no projeto é a de retenção, que é fundamental para o sucesso permanente do sistema. Como a área de TI evolui constantemente, os casos iniciais armazenados na base de dados podem a médio prazo já não serem os ideais para a solução de problemas atuais. Ou podem surgir novos problemas que necessitem de soluções diferentes das cadastradas inicialmente. Portanto, o armazenamento constante de novos casos fará com que o sistema possua sempre uma base de soluções atualizada, capaz de resolver problemas atuais. A retenção de novos casos é realizada mediante a intervenção do especialista. Ele avalia a solução proposta e se a mesma tiver sido satisfatória para o cliente deve ser inserida na base de dados. 3.3 Testes Para comprovar a eficácia do software Help to Enterprise Solution, foi necessária a etapa de validação, realizada pelo especialista técnico e o representante de vendas, que avaliaram as soluções propostas pelo sistema a partir de situações reais escolhidas aleatoriamente para a fase de testes. A questão técnica foi verificada pelo especialista, que analisou se a configuração do servidor estava de acordo com o necessário para atender aos requisitos do problema. E a verificação comercial da solução foi de responsabilidade do representante de vendas, que validou se o modelo e configuração do servidor estão bem dimensionados para o porte da empresa. Ou seja, será considerado um erro se o sistema oferecer o modelo mais avançado de servidor com uma configuração excelente, para uma empresa que deseja adquirir um servidor básico de arquivos, por exemplo. Mesmo que atenda a necessidade técnica, a solução apresentada pelo sistema RBC precisa estar de acordo com o restante do cenário apresentado e tornar viável a venda da solução para o cliente. Como a alocação de recurso de um profissional da área técnica para elaboração das propostas de servidores tem sido um problema constante na empresa, os responsáveis pelos testes foram os maiores beneficiados pela implantação do sistema, logo a colaboração e motivação para esta etapa não foi um problema. Também precisou ser considerada toda a análise referente à interface do sistema, testes foram aplicados para mensurar a satisfação e aceitação do sistema pelo usuário, ou as dificuldades encontradas durante a execução da tarefa. Os testes iniciaram logo após o desenvolvimento do protótipo e a criação da base de dados, e além da solução propriamente dita, foram avaliadas se as interações do sistema com o usuário foram úteis para a descoberta da solução ideal, a praticidade do sistema, tempo de reposta e processamento do sistema. Para obter a avaliação mais correta possível sobre os resultados obtidos no sistema, a etapa de testes foi realizada através de situações reais. Durante algumas semanas o representante de vendas coletou as informações necessárias sobre as empresas, conforme novas cotações eram solicitadas, e enviou um template por para o especialista técnico. Além disso, o vendedor teve acesso ao protótipo e utilizou as informações obtidas junto às empresas para responder as perguntas efetuadas pelo sistema e enviou também por o descritivo (print screen da tela) das soluções sugeridas pelo sistema. Com posse do template e das soluções, o especialista técnico avaliou se o sistema estava recomendando o equipamento correto para a necessidade do cliente, e em alguns casos o especialista também entrou em contato com o cliente para verificar se a coleta de informações foi realizada corretamente por parte do representante de vendas. Também foram realizadas reuniões semanais entre o consultor técnico e o representante de vendas para discutir sobre os resultados obtidos e se a taxa de conversão em vendas estava mantendo a média normal, ou seja, se a solução proposta pelo sistema atendeu tecnicamente e comercialmente o cliente. Portanto os feedbacks dos usuários, e todos os pontos que influenciarem para o sucesso do sistema ou sua aceitação, precisaram ser testados e validados nessa etapa. 3.4 Tecnologias A aplicação apresentada no presente artigo trata-se de um protótipo e foi desenvolvida utilizando-se apenas tecnologias da Microsoft, sem a necessidade de grandes investimentos financeiros em software, além do pacote Office e um compilador para desenvolvimento. O sistema gerenciador de banco de dados escolhido foi o Access, que utiliza uma sintaxe muito parecida com o SQL podendo ser facilmente adaptado, e é um dos aplicativos disponíveis no pacote Office Professional. 12

13 E a linguagem de programação definida foi o Visual Basic, que é uma das plataformas de desenvolvimento oferecidas no compilador Microsoft Visual Studio. Visual Basic é um aperfeiçoamento do Basic, e a linguagem é dirigida a eventos (event driven), e possui também um ambiente de desenvolvimento integrado (IDE - Integrated Development Environment) totalmente gráfico, facilitando a construção da interface das aplicações. Além disso diferentemente das primeiras versões criadas, o Visual Basic permite a conexão com bancos de dados, necessária para o funcionamento do sistema. 4 RESULTADOS Conforme foi exposto na introdução deste artigo, o crescimento na utilização dos recursos de informática, principalmente nas organizações de pequeno e médio porte que não possuem uma estrutura adequada de TI, criam uma quantidade alta de solicitação de cotação e definição da melhor solução para a necessidade específica de cada empresa. Isso causa para os fornecedores de hardware uma demanda complicada de gerenciar e, por fim, uma dificuldade de alocação de consultor técnico para participar do atendimento e auxiliar o representante comercial na definição da solução, e obviamente na venda. Visando solucionar este problema, o presente trabalho propôs o sistema Help to Enterprise Solution que visa eliminar a obrigatoriedade de um técnico para o dimensionamento da solução, deixando-os focados em projetos que possuam complexidade ainda maior. O nome do sistema originou-se justamente pensando em soluções para empresas, onde o servidor geralmente acaba sendo o equipamento mais crítico para a disponibilização de arquivos, aplicações, armazenamento de banco de dados, etc. O objetivo do sistema não é simplesmente informar o modelo ou alguma característica individual do equipamento que será necessário, mas sim apresentar a solução completa para a necessidade de cada organização. Para atender inúmeras possibilidades, o sistema foi desenvolvido para trabalhar em sete cenários diferentes, em que cada um representa uma utilização para o equipamento. O representante de vendas poderá optar por configurar um servidor que seja apenas para um uso específico (arquivos ou aplicação ou banco de dados), ou poderá selecionar um equipamento que terá mais de uma função, como por exemplo, um único servidor que será utilizado para armazenamento de arquivos e disponibilização de banco de dados. A interface do sistema cuja tela inicial é ilustrada na Figura 7 foi desenvolvida com a intenção de ser simples e funcional, possibilitando que o usuário obtenha a solução final rapidamente e com poucos cliques no mouse. A interação com o sistema é realizada através de perguntas e respostas sobre o ambiente da empresa e características que o servidor deve atender. As perguntas apresentadas pelo sistema são objetivas, portanto o usuário responderá através de um grupo de alternativas, devendo selecionar uma única opção para cada pergunta. Em seguida, o algoritmo do vizinho-mais-próximo é executado, recuperando todos os casos cuja distância do caso atual seja menor ou igual ao limiar de similaridade previamente definido. Figura 7: Perguntas iniciais do sistema 13

14 Conforme demonstrado na Figura 7, a tela inicial do software faz as primeiras perguntas que são responsáveis por verificar qual será a utilização do servidor. Essa etapa define qual dos cenários será considerado pelo sistema, sendo que cada cenário possui um conjunto já pré-determinado de outras perguntas que serão realizadas na sequência para o usuário. É importante salientar que os usuários do sistema são os representantes de vendas e os mesmos possuem uma vasta experiência comercial, além de um pequeno conhecimento técnico, porque para o retorno correto da solução é necessário que a coleta de informações sobre o cliente seja feita com extrema atenção, pois qualquer pergunta respondida de forma incorreta pode ocasionar a sugestão de uma solução não indicada para a necessidade do cliente em questão. As perguntas iniciais são importantíssimas para a recuperação de casos com soluções adequadas ao problema atual já que possuem os maiores pesos, e através delas é realizada a indexação na base de casos para definir o modelo do chassi do equipamento que será configurado e também o formato do mesmo (torre ou rack). Portanto, se o valor do limiar de similaridade estiver setado de forma correta para a base de casos utilizada, não se correrá o risco de, por exemplo, o usuário selecionar um chassi no formato torre e o sistema recuperar um caso com o chassi no formato rack. Ao clicar no botão continuar, que aparece logo abaixo das perguntas iniciais ilustradas na Figura 7, o sistema apresentará as próximas perguntas. Nesta mesma tela das perguntas iniciais (Figura 7), no menu superior, o usuário tem acesso ao módulo de configuração do sistema, cuja tela é apresentada na Figura 8. Figura 8: Tela de configuração do sistema A Figura 8 apresenta a tela de configuração do sistema. Para as perguntas que possuem alternativas de resposta que podem variar constantemente devido à evolução da tecnologia, será possível excluir as opções existentes e adicionar novas opções. No caso da exclusão, o registro no banco de dados não será removido fisicamente, o sistema apenas executa uma exclusão lógica, mantendo a opção excluída vinculada aos casos em que ela fora utilizada anteriormente, mas impedindo a sua utilização em casos novos. A 14

15 exclusão lógica é necessária para evitar erros de cálculo do algoritmo do vizinho-mais-próximo para todos os casos já cadastrados na base de conhecimento do sistema que possuam em suas características o registro da alternativa excluída, nestes casos essa alternativa continuará sendo considerada no cálculo. Quando o usuário digita um valor, caso ele já exista, é realizada apenas uma atualização no registro e o valor volta a ficar disponível para a pergunta, caso contrário, é realizada de fato a inserção do novo valor. Para as demais perguntas do sistema que são referentes ao perfil da organização, como por exemplo número de funcionários e quantidade de filiais da empresa, não será permitido a alteração das alternativas pois não existe necessidade. A outra função do ambiente de configuração é definir o limiar de similaridade. Isso é extremamente importante para a recuperação dos casos, uma vez que o sistema apresentará todos os casos cuja distância do caso novo for menor ou igual ao valor do limiar de similaridade. O usuário pode definir o limiar adequado para a base de casos que está sendo utilizada, de modo que recupere somente os casos que realmente forem muito semelhantes ao novo caso. No banco de dados são armazenadas todas as alterações efetuadas no valor do limiar de similaridade para manter um histórico. Após responder às perguntas iniciais, o sistema verificará qual dos cenários foi o escolhido e imediatamente mostrará as perguntas respectivas a esse cenário para que o representante de vendas informe os demais dados coletados junto ao cliente. A quantidade e sequência das perguntas variam de acordo com o cenário que está sendo utilizado. Esta etapa pode ser realizada adquirindo-se previamente todas as informações necessárias sobre a empresa, ou então durante a ligação telefônica do representante de vendas com o cliente. Depois de todas as perguntas terem sido respondidas, o usuário clicará no botão concluir para que seja realizado o cálculo do algoritmo de similaridade. Basicamente será verificado o valor total da diferença das características do novo caso com cada um dos casos registrados na base de casos, e todos aqueles cuja distância for menor ou igual ao limiar de similaridade definido na tela de configurações serão recuperados pelo sistema. Os Quadros a seguir demonstram um teste-de-mesa para visualizar o cálculo do algoritmo do vizinho-mais-próximo. O Quadro 4 apresenta valores para um novo caso, representando o usuário utilizando o sistema, e o Quadro 5 apresenta os valores do caso recuperado, representando a base de casos. Quadro 4: Estrutura do caso de entrada Quadro 5: Estrutura do caso recuperado Característica Valor Descrição Característica Valor Descrição P1 2 O equipamento será utilizado para servidor de arquivos? P2 1 O equipamento será utilizado para servidor de aplicação? P3 2 O equipamento será utilizado para servidor de banco de dados? P4 1 O formato do servidor deve ser torre ou rack? P5 3 Quantos usuários acessarão o servidor simultaneamente? P6 4 Qual é o número total de equipamentos no parque de TI atual da empresa? P7 4 Quantos funcionários a empresa possuí? 15 P1 2 O equipamento será utilizado para servidor de arquivos? P2 1 O equipamento será utilizado para servidor de aplicação? P3 2 O equipamento será utilizado para servidor de banco de dados? P4 1 O formato do servidor deve ser torre ou rack? P5 1 Quantos usuários acessarão o servidor simultaneamente? P6 4 Qual é o número total de equipamentos no parque de TI atual da empresa? P7 5 Quantos funcionários a empresa possuí? P8 2 Número de filiais que a P8 3 Número de filiais que a

16 empresa possuí? P9 0 Que tipo de arquivos será armazenado no servidor? P10 1 Tamanho livre que será necessário de espaço em disco no total (em GB)? P11 2 Os arquivos e/ou aplicações e/ou banco de dados que serão armazenados no servidor são importantes para o funcionamento da empresa? P12 3 Qual será a criticidade para a empresa no caso do servidor parar de funcionar? P13 2 Quantas aplicações serão instaladas no servidor? P14 2 Qual é a principal aplicação instalada no servidor? P15 0 Número de servidores que a empresa possuí em funcionamento na rede? P16 0 Qual banco de dados será utilizado no servidor? P17 0 Será realizado cluster no servidor? empresa possuí? P9 0 Que tipo de arquivos será armazenado no servidor? P10 1 Tamanho livre que será necessário de espaço em disco no total (em GB)? P11 3 Os arquivos e/ou aplicações e/ou banco de dados que serão armazenados no servidor são importantes para o funcionamento da empresa? P12 4 Qual será a criticidade para a empresa no caso do servidor parar de funcionar? P13 4 Quantas aplicações serão instaladas no servidor? P14 2 Qual é a principal aplicação instalada no servidor? P15 0 Número de servidores que a empresa possuí em funcionamento na rede? P16 0 Qual banco de dados será utilizado no servidor? P17 0 Será realizado cluster no servidor? distância ( X, N ) = [ p * ( P1-P1 )² + p * ( P2-P2 )² + p * ( P3-P3 )² + p * ( P4-P4 )² + p * ( P5-P5 )² + p * ( P6-P6 )² + p * ( P7-P7 )² + p * ( P8-P8 )² + p * ( P9-P9 )² + p * ( P10-P10 )² + p * ( P11-P11 )² + p * ( P12-P12 )² + p * ( P13-P13 )² + p * ( P14-P14 )² + p * ( P15-P15 )² + p * ( P16-P16 )² + p * ( P17-P17 )² ]½ distância ( X, N ) = [ 3 * ( 2-2 )² + 3 * ( 1-1 )² + 3 * ( 2-2 )² + 4 * ( 1-1 )² + 1 * ( 3-1 )² + 1 * ( 4-4 )² + 1 * ( 4-5 )² + 1 * ( 2-3 )² + 1 * ( 0-0 )² + 3 * ( 1-1 )² + 2 * ( 2-3 )² + 2 * ( 3-4 )² + 1 * ( 2-4 )² + 1 * ( 2-2 )² + 1 * ( 0-0 )² + 1 * ( 0-0 )² + 2 * ( 0-0 )² ]½ distância ( X, N ) = ( ) ½ distância ( X, N ) = (14) ½ distância ( X, N ) = 3,74 A equação acima demonstra um exemplo de como é efetuado o cálculo do algoritmo do vizinhomais-próximo, verificando a diferença das características entre o novo caso e o caso recuperado, conforme valores mostrados respectivamente nos Quadros 4 e 5. O valor absoluto resultante da diferença entre os tipos é elevado ao quadrado e multiplicado por um peso. Os pesos são atribuídos de acordo com os valores da estrutura do caso de entrada, sendo que o valor mais alto tem peso 4, o segundo mais alto 3, o terceiro 2 e os demais 1. Depois, somam-se os resultados obtidos e eleva-se a potência. Assim, os casos com distância menor ou igual ao limiar de similaridade são recuperados. A recuperação de casos trará diversas informações para o representante de vendas. Primeiro será mostrada uma mensagem informando quantos casos foram recuperados, inclusive pode acontecer de nenhum caso ser encontrado, dependendo do valor de similaridade que está gravado e das características do novo caso. Para os casos recuperados, será informado o número de identificação do caso que nada mais é que a 16

17 linha em que este caso está armazenado na tabela da base de casos, e a descrição completa da solução escolhida para que então seja posteriormente efetuada a cotação e a venda. Alguns casos possuem informações adicionais que são cadastradas pelo especialista, e podem conter diversas especificações sobre a solução, inclusive sua recomendação ou não. Essas informações, assim como a quantidade de vezes que o caso foi recuperado também são mostradas para o usuário, conforme ilustra a Figura 9. Figura 9: Recuperação dos casos Além de tudo isso, o sistema trará mais uma informação para o usuário. Sempre será gerada uma tabela de valores em ordem crescente mostrando qual foi à distância entre o novo caso e todos os casos da base. Esta tabela contém duas colunas, uma mostrando a identificação do caso e a outra a distância calculada pelo algoritmo, e serve como um ranking mostrando primeiro todas as soluções mais próximas, e depois as que não foram recuperadas devido ao limiar de similaridade. No caso de não recuperar nenhum caso, a tabela pode ser útil também para verificar qual valor deve ser setado para o limiar de similaridade disponível na configuração do sistema, para que o sistema possa recuperar o caso mais próximo. 4.1 Base de casos Para qualquer sistema baseado em conhecimento, como é o caso do sistema RBC, independente do algoritmo utilizado na etapa de recuperação, o ponto crítico para o sucesso ou fracasso do projeto é a base de casos. E o principal desafio do sistema Help to Enterprise Solution foi justamente construir uma base de casos sólida, realmente homologada pelo especialista, com diferentes casos que possam servir de solução para inúmeras necessidades distintas. Enquanto o desenvolvimento do sistema e a construção da interface eram realizados, o especialista técnico validou soluções que efetivamente foram vendidas e que não tiveram nenhum tipo de reclamação por 17

18 parte do cliente após um mês da finalização da venda. Portanto a base de casos demorou em torno de três meses para ser validada e concluída, e toda ela constituída de casos reais. Figura 10: Base de casos Ao total foram inseridos 450 casos ilustrados na Figura 10, que representa uma pequena parte da base de casos. Cada caso é formado por um código de identificação, os índices referentes a cada característica (pergunta), a descrição da solução, o campo opcional para comentários e o contador que informa quantas vezes o caso foi recuperado. De todos os casos inseridos, em torno de 95 representam soluções totalmente diferentes umas das outras, e os demais casos foram derivados a partir destes primeiros que foram validados, porém mudando apenas uma característica, como capacidade de disco rígido ou tipo de suporte. Isso foi importante para tornar a base de casos mais completa e diminuir a distância de um caso para o outro, tornando o caso recuperado o mais próximo possível da necessidade do cliente. Dessa forma cada configuração diferente terá disponível todas às opções de tamanho de disco rígido, e para garantir que o sistema recupere o tamanho correto de disco, foi realizada a indexação na base de casos, atribuindo um peso maior na pergunta que define o seu tamanho. De qualquer forma como cada solução possui inúmeras variáveis, em diversos casos será necessário a adaptação do caso, mediante análise do especialista técnico. Se a venda for bem sucedida e a solução tiver a aprovação por parte do cliente, pode ser cadastrada como um novo caso na base de casos, realizando a retenção do caso Validação e testes Inicialmente o especialista técnico disponibilizou 30 casos com características bem diferentes para testar o algoritmo de similaridade, e através de inúmeros testes-de-mesa e análise dos resultados obtidos, foram detectados alguns erros na implementação do algoritmo de recuperação, que posteriormente foi corrigido. Os casos utilizados para os testes iniciais não possuem nenhum tipo de chamado no pós-venda, mas não necessariamente tiveram a etapa de validação junto ao cliente, que consiste na ligação telefônica após 30 dias para verificar se a solução atendeu satisfatoriamente as necessidades da empresa. Esses 30 casos foram utilizados apenas para o ambiente de testes, e logo depois foram descartados. Conforme comentando anteriormente, foi dedicado bastante tempo para o especialista técnico homologar os casos que foram inseridos na base de casos. Para cada venda cuja configuração do servidor foi sugerida pelo especialista, aguardou-se o prazo médio de 30 dias para efetuar uma ligação para o cliente e verificar se o equipamento estava tendo uma boa performance, principalmente referente a velocidade de processamento e segurança. Este prazo de um mês é o tempo necessário para o cliente receber o produto, instalar, e mensurar o seu desempenho. Todas as vendas que tiveram um retorno positivo do cliente foram consideradas boas recomendações, e as informações sobre a empresa e necessidade do cliente, assim como a configuração do servidor foram sendo armazenadas pelo especialista para que depois fossem utilizadas na construção da base de casos. Após validar todos os casos, os mesmos foram divididos e separados por cenários. Para uma melhor indexação e organização na tabela de base de casos, a inserção dos casos ocorreu de forma sequencial, cadastrando um grupo de casos para atender às configurações do servidor de arquivos, outro grupo para servidor de aplicações, etc. Os testes foram realizados em paralelo à criação da base de casos. Assim que o conjunto de casos que formavam as soluções disponíveis para cada cenário era inserido na base, o representante de vendas e o especialista técnico submetiam o sistema a uma bateria de testes. Essa ação foi fundamental para detectar alguns erros, corrigi-los rapidamente e prosseguir com a inserção correta dos casos para os demais cenários. 18

19 Uma vez que já se tinha a certeza do funcionamento do algoritmo de recuperação com a realização dos testes iniciais, o objetivo principal dos testes nesse momento era verificar se as soluções recomendadas pelo sistema para o cliente estavam próximas ou totalmente de acordo com a recomendação normal que o especialista técnico faria, e também em conformidade com o histórico de vendas que o representante de vendas possui, de acordo com o perfil do seu cliente. 5 CONCLUSÃO Atualmente a TI está presente em praticamente todos os segmentos de negócios, e o uso correto desse recurso é fundamental para um melhor desempenho da empresa. A necessidade por profissionais de TI que possam gerenciar todo esse cenário aumenta constantemente, mas a formação de novos profissionais aptos a exercerem esta função ainda é insuficiente. Uma das alternativas encontradas pelas empresas para acompanhar o crescimento tecnológico do país é solicitar cada vez mais a orientação e consultoria dos próprios fabricantes ou montadores de hardware para a definição de soluções mais complexas. Para oferecer esse serviço é fundamental que os fabricantes possuam uma estrutura sólida e que ofereçam confiabilidade e velocidade no retorno para o seu cliente. Este problema não é novidade e já foi diagnosticado há bastante tempo, existem inúmeros congressos e fóruns de discussão para tratar do assunto, porém ainda não se tem uma solução imediata. Este crescimento acentuado da tecnologia e acima das expectativas de mercado gera também uma dificuldade enorme para a empresa fabricante de hardware, principalmente para as líderes de mercado que passam a absorver boa parte da demanda gerada e que para gerenciar tudo isso também necessita de mão-deobra qualificada e um planejamento adequado. Com base nesta constatação, o presente artigo apresentou um sistema que visa justamente solucionar uma dificuldade específica que os fabricantes de hardware passam no momento, proporcionando um retorno mais rápido e preciso para o cliente, através de uma solução capaz de atender um nicho que está cada vez mais carente de mão-de-obra qualificada e desta forma suprir de forma qualificada toda a demanda gerada pelo crescimento do mercado de TI. Os principais objetivos traçados no início do desenvolvimento do sistema foram alcançados com sucesso, e isso pode-se perceber através do uso do protótipo que testou todas as funcionalidades do sistema. Durante a fase de testes que, conforme mencionando anteriormente, foi realizado com casos reais, o sistema se mostrou bem intuitivo, com uma interface simples e fazendo com que o consultor técnico e o representante de vendas não tivessem dificuldade em utilizá-lo. Além disso, em pouco tempo o sistema permite que o usuário obtenha a solução para o problema. Todas as soluções foram muito próximas ou em alguns casos idênticas ao que o consultor técnico indicaria normalmente. A aceitação do sistema foi considerada ótima, porém o mesmo apresenta limitações que devem ser trabalhadas nas próximas versões. Este protótipo pode trabalhar com 7 cenários, portanto o planejamento é de evoluir o sistema e permitir que o mesmo esteja apto a dimensionar outros cenários, como virtualização e cloud computing por exemplo. Além disso, para as futuras versões o objetivo é que o sistema informe a solução já com valor estimado para a compra, e integre também a parte de software na solução. REFERÊNCIAS AAMODT, Andre. A Knowledge-Intensive Approach to Problem Solving and Sustained Learning. Stockholm: AICom, BINDER, Fábio Vinícius. Sistemas de Apoio a Decisão. São Paulo: Érica, CAMARGO, Katia. Dissertação de mestrado UFSC. Santa Catarina, Disponível em: < Acesso em: abr HAMMOND, Kristian. Chef: A Modelo f Case based Planning. Disponível em: < Acesso em : abr LEE, Rosina. Tese de Pós Graduação UFSC. Santa Catarina, Disponível em: < Acesso em : abr

20 MICHIE, D.; Spiegelhalter, D.J.; Taylor. Machine Learning, neural and statistical classification. New York: Ellis Horwood, SPRAGUE, Ralph H.; HUGH, J.Watson, Sistemas de Apoio à Decisão. Rio de Janeiro: Campus WANGENHEIM, Christiane Gresse Von; WANGENHEIM, Aldo Von. Raciocínio Baseado em Casos. São Paulo: Manole, WATSON, Ian. Case-Based Reasoning: A Review. Disponível em : < IAS/artigos/cbr_tools.pdf.gz>. Acesso em : abr