Sistemas de informação para um controle de operações

Podendo Sistemas de Informação ser definido como conjunto de recursos, pessoas, máquinas e métodos a serem utilizados, tais como processamento de dados etc. Falaremos então de Sistemas de Informação para um Controle de Operações, ou seja, como este “sistema” controlaria uma atividade operacional para chegarmos a conclusões. Um grande exemplo seria a tentativa de um Gerente de TI identificar quais são os maiores problemas em seu Help Desk. Onde na maioria dos casos a identificação deste problema leva quase 1(um) mês. Acredito que a base dessa informação provinda de uma arquitetura correta da informação a ser repassada, por exemplo, o meio que será analisado em seus tópicos. Vamos entender melhor, o Gerente de TI requer informações de quais foram os maiores problemas nesta semana para realizar uma preventiva de caso, ou tentar reduzir os problemas.

A lógica conduziria este relatório sem um Sistema para controle real de uma seguinte forma, em uma velha e boa planilha: Análise

1ª Ponto – Gerente de TI -> Busca Informação provinda do sistema ->Relatório.

2ª Ponto – Gerente de TI -> Analisa o número de chamados (ocorrência) e o número de chamados atendidos.

3ª Ponto – Gerente de TI -> Procura saber se o número de ocorrência foi grande em software, hardware ou em ambas. 4ª – Se software o suporte corrige (nem sempre), se hardware o laboratório corrige.

5ª Ponto – Resolução do problema.

Dentro desta análise também pode ser analisado o trabalho dos analistas de sistemas, suporte, supervisão e coordenação, claro, para saber como eles estão atuando à frente de suas equipes. Este tipo de análise é comum dentro de uma empresa em que recentemente trocou sua gerência, que geralmente este profissional tende a levantar todo o tipo de informação para sua nova gestão. Às vezes a maioria dos casos é de uma fila de chamados imensa pela causa da dependência de setor para setor, que por fim é sempre esperada uma reunião para ouvirmos o seguinte caso: “Senhores, o setor X, trabalhou mais que o setor P, que trabalhou menos que o setor T, mas não fora tão bem supervisionados e por fim coordenados pelos seus responsáveis.”

Mesmo contando com um sistema que retorna este tipo de informação, na maioria dos casos a arquitetura deste sistema faz com que o gerente retorne ao velho e bom Excel como uma forma de controle melhor de uma pesquisa elaborada por ele para apresentação de erros e melhorias.

No caso do relatório, a base da arquitetura de um analista de sistemas, como este software está atendendo, onde este profissional estaria sendo analisado, o número de chamados atendidos seria de importância do suporte e a supervisão e coordenação analisada de como estão distribuindo a equipe para realizar a demanda de trabalho, ou seja, tempo de solução, setores prioritários, etc.

Como tempo é dinheiro e hoje em dia tempo é produção, poderíamos dizer que uma das soluções seria entender o que este sistema de informação está gerando de verdade a ponto de não termos de recorrer a uma segunda opção. Entendesse então que, com sistemas para gerar informações e armazenamento de informações para relatórios, balanços, e conclusões. Entendemos também que o ponto de partida deveria ser na construção de retorno desta informação, ou seja, se primeiro é gerado um relatório para analisar os pontos que estão acontecendo, devemos trabalhar em cima do sistema, e em sua construção e retorno.

Para melhor entendermos e focarmos no que estamos debatendo, vamos criar um caso onde é aberto um chamado para que o suporte resolva um problema do tipo “computador travando”. O setor com problemas liga no Service Desk, ele tenta resolver remotamente, digamos que não conseguiu logar na máquina que apresenta problema, sem êxito, ele encaminha um Analista de Suporte ao local.

Nesse caso o primeiro chamado foi aberto, com um número fictício de chamado 2013/1234 que por esta abertura é entendido que o gerente em um relatório poderia acompanhar perfeitamente se o Service Desk está trabalhando, e sabe que o analista de suporte também estará. Mas se os colaboradores atuam dentro do mesmo chamado, então deveria dentro do chamado fictício 2013/1234 ser criada uma tarefa ao analista de suporte.

No local o analista percebe que se trata de um problema de hardware e passa o problema ao laboratório que por fim finaliza o chamado efetuando digamos que uma limpeza interna nos componentes do equipamento. Mas Fabiano entende que a construção do software está ok, certo? Não… Com essa arquitetura ele simplesmente de tarefa em tarefa, sempre chegará à conclusão de que X setor trabalhou mais que setor P, e T menos que O, ou que o problema real de toda a empresa seja hardware. Pois o laboratório é o último recurso.

Se o Gerente de TI entender que o chamado não poderá ser resolvido dentro do chamado inicial e sim agregado ao chamado inicial, a fonte de pesquisa mudará, pois no caso citado o Service Desk atende, não resolve, finaliza encaminhando ao Analista de Suporte, porém com suas explicações de não sucesso a solução do caso, por exemplo: Problema não resolvido devido falha de acesso remoto. Direciona um analista que agora possui o chamado de número 2013/12345 que atende, não resolve e descreve: Problema não resolvido mediante tentativa de otimização do sistema, encaminhando ao laboratório para identificação. O mesmo finaliza e abre o chamado para o laboratório de número 2013/123456 que por fim após seu trabalho conclui: Limpeza de componentes de hardware efetuada, com testes realizados e sistema funcionando perfeitamente. Equipamento pronto para uso.

Se o analista de suporte mais de que 3 (três) vezes por semana encaminha um problema ao laboratório para solução do caso e outros analistas encaminham 1 vez por semana ou talvez nenhuma vez durante 10 dias, onde estaria o problema? Não é fácil identificar? Agora o nosso gerente saberia identificar se de verdade a equipe está qualificada, descrevendo seu atendimento claro e de forma limpa, e o tempo de realização de solução da equipe como um todo.

Com esta análise, percebemos que em menos de 1 (uma) semana talvez poderiam existir uma preventiva baseada nos problemas ora apresentados como comuns, caso aconteçam em setores críticos ou VIP’s como costumamos ouvir sempre dentro de uma empresa. Mas, se TI é sempre uma equipe, porque não deixar a tarefa sobre tarefa para analisarmos todo um setor de TI e passarmos a analisar colaborador a colaborador? Simples pela sobrecarga de setor. Se um analista de suporte não é qualificado, ou prefere passar o problema adiante, talvez nem software e nem hardware estejam com problemas e sim o colaborador.

Falha de acesso, encaminhando um analista. Mas o Service Desk também mesmo com chamado de tarefa sobre tarefa não poderia descrever o problema? Sim pode, mas a tarefa sobre tarefa demora a finalização de um problema, pois cada setor alegaria um diferente, como em alguns casos existem tarefas que levam uma semana para serem finalizadas devido a dependências.

Quem ainda não viu um supervisor questionar um analista de suporte, por exemplo, como está a situação da máquina X, ele responde que levou para o laboratório e o supervisor tem que ligar no laboratório para saber se o chamado será finalizado em até qual data. Mas se estivermos dentro de tarefas finalizadas por encaminhamento, ele (supervisor) irá direto ao ponto.

Se um analista de suporte sabe que perfeitamente o Service Desk conseguiria acessar remotamente a máquina, mas repassou o problema ao analista ele descreveria no chamado aberto por ele, e com isso a gerência estaria observando a troca de informações entre os mesmos.

Se ficarmos de tarefa em tarefa sempre, como parte das empresas, e neste caso citado, e tendo um responsável para instalação de software como é o laboratório quando prepara o equipamento para uso interno, chegaríamos à conclusão de que o laboratório não instala os softwares corretamente, e que sempre se faz necessário um analista ao local, porque o Service Desk não consegue acessar, então sempre temos 3 setores trabalhando em um único problema.

Por fim entendo que se temos um sistema para informação ele nos deve retornar a informação, então a base para sabermos se tudo o ocorre de uma forma justa e perfeita, deverá ser sempre iniciada no sistema.

[Crédito da Imagem: Sistemas de Informação – ShutterStock]