Trabalho de Campo Realizado pela Consulting ‘in loco” na Software Developer

...

• Quando é desenvolvido uma nova correção, os analistas à enviam aos clientes onde a mesma é imediatamente distribuida em ambiente de Produção porém, coincidentemente, vários problemas aconteceram logo após algumas atualizações, deixando o ambiente parado por horas gerando impactos financeiros às Instituições;

• O Suporte Técnico da Software Developer não fornece, a seus clientes que abriram tickets, a devida explicação sobre a causa raiz dos problemas ocorridos. Adicionalmente, a correção/solução encontrada não é aplicada aos demais ambientes;

• Há uma forte resistencia, por parte da Software Developer, em homologar seus sistemas para serem usados em Sistema Operacional Linux por terem receio de que o código-fonte de seus sitemas sejam utilizados por seus concorrentes.

3. ANÁLISE E MELHORIAS PROPOSTAS

O time de consultores internos da Consulting fizeram uma série de análises em cima dos aspectos levantados pelo time de campo e desenvolveram algumas propostas de melhorias, baseadas nas

melhores práticas de mercado, alinhada com os conceitos fundamentados pelas metodologias COBIT, ITIL, CMMI e aderente a Lei Sarbanes-Oxley (SOX).

As melhorias visam um melhor direcionamento nas tomadas de decisões da Software Developer que afetam diretamente seu ambiente de desenvolvimento interno, seus clientes, o modo como seus gerentes gerenciam os recursos financeiros de TI, a metodologia de desenvolvimento da empresa, bem como, tratamento de problemas (tickets), distribuição de patches de correção, disseminação do conhecimento adquirido (Lessons Learned) e equalização de ambientes.

3.1 Padronização dos status dos Tickets segundo sua Criticidade

Seguindo práticas de mercado, foram definidas 4 categorias para classificar a criticidade dos Tickets e estabelecido seus devidos tempos de atendimento (SLA – Service Level Agreement), são eles:

• Severidade 1 – Prioridade Urgente – 4 horas úteis para efetuar o atendimento. Esse tipo de severidade está relacionado à problemas que afetam diretamente a imagem dos clientes da Software Developer, que afetam os clientes dos clientes da Software Developer ou problemas que possam gerar impactos financeiros aos clientes da Software Developer. Normalmente está relacionado à processos que não possuem procedimentos de contingencia ou para os casos em que a contingencia não foi suficiente. Esse tipo de Ticket terá visibilidade da alta gerencia da Software Developer e acarretará ações corretivas no sentido de evitar a recorrencia desse tipo de problema.

• Severidade 2 – Prioridade Alta – 8 horas úteis para efetuar o atendimento. Esse tipo de severidade está relacionado à paradas críticas dos sistemas desenvolvidos pela Software

Developer mas que não afete diretamente os processos de negócio dos clientes porque tais processos possuem procedimentos de contingencia. A parada prolongada de tais processos pode acarretar na promoção da severidade do Ticket para 1. Esse tipo de Ticket também terá visibilidade da alta gerencia da Software Developer e poderá gerar ações corretivas no sentido de evitar a recorrencia desse tipo de problema.

• Severidade 3 – Prioridade Media – 3 dias úteis para efetuar o atendimento. Esse tipo de severidade está relacionado a problemas que não ocasionem a parada dos sistemas desenvolvidos pela Software Developer, nem maiores riscos aos processos de seus clientes. Normalmente ligado à pequenas correções ou pequenos bugs que não comprometam o funcionamento dos sistemas. Esse tipo de Ticket, num primeiro momento, não terá visibilidade da alta gerencia da Software Developer e não acarretará ações mais críticas no sentido de evitar a recorrencia do problema, por se tratar de problemas simples, intermitentes e/ou localizados (particularizado) de determinado cliente.

• Severidade 4 – Prioridade Baixa – 5 dias úteis para efetuar o atendimento. Esse tipo de severidade está relacionado a pequenos ajustes ou personalizações requeridos pelos clientes da Software Developer em seus sistemas. Também pode ser usado para documentar ações de melhorias feitas nos sitemas ou nos processos internos da Software Developer ou ainda em seus clientes. Tickets desse tipo serão utilizados para criação de estatisticas.

3.2 Padronização nos critérios para Classificar os Tickets

Foram elaboradas algumas perguntas, a serem feitas ao solicitante do Ticket, que refinam e selecionam os tipos de problema para

dar-lhes a correta classificação. Com isso, tem-se o correto direcionamento de recursos para o atendimento do Ticket, tem-se a visibilidade adequada, a otimização no tempo de atendimento, padronização na classificação dos Tickets evitando uma serie de problemas decorrentes da má classificação dos mesmos.

• O Sistema está fora do ar?

• Usuários estão impossibilitados de acessar o sistema?

• Quantos usuários afetados?

• Quais módulos do sistema doram afetados?

• O problema afeta usuários externos (clientes)?

• Há risco de Impacto Financeiro?

• Há um processo de contingencia?

• Existem operações críticas pendentes de processamento nas próximas 8 horas úteis?

• O problema afeta a imagem do cliente?

• O problema afeta todo o sistema ou apenas algumas funcionalidades?

• Anexar log do sistema e imagem da tela de erro apresentada ao usuário.

Sempre que possível, os Tickets devem ser solicitados à Software Developer por integrantes de equipes técnicas de infomática dos clientes e, quando possível, na presença do usuário do sistema.

3.3 Padronizar as informações que serão inseridas no fechamento dos Tickets.

Após a resolução do problema, o mesmo deve ser corretamente documentado para que essa informação sirva de base de conhecimento na resolução de futuros problemas, para que seja dada a devida visibilidade do problema e das ações corretivas que foram tomadas.

• Problema Identificado.