GR TIPS

Da leitura do segundo livro da nova versão do ITIL – Desenho de Serviço – um tópico me chamou bastante atenção dada sua complexidade e a extrema dificuldade de sua ampla compreensão (por parte do quadro executivo das organizações) e conseqüente implementação em organizações com um acentuado tom político de gestão: a composição de um serviço.

Muitos são os aspectos que precisam ser observados durante todo o ciclo de vida de um serviço:

• As necessidades funcionais associadas à provisão do serviço, ou seja, a dependência e o relacionamento entre o serviço e os demais processos de negócio já consolidados no ambiente organizacional;
• Os contratos de nível de serviço que especificam e, em tese, garantem junto aos usuários o nível, escopo e qualidade do serviço disponibilizado;
• A infra-estrutura e o ambiente necessários à operação do serviço;
• Os dados necessários ao suporte deste serviço e à provisão de informações exigidas pelos demais processos de negócio;
• As demais aplicações que possuem interface com o novo serviço e que se interagem através do intercâmbio de dados entre si;
• Os serviços e equipes de suporte necessários para garantir a operação do serviço disponibilizado;
• Os contratos e acordos de nível operacional que visam asseverar a qualidade demandada ao serviço;
• Os fornecedores de insumos e/ou componentes indispensáveis à provisão do serviço.

Mas como traduzir toda a inter-relação entre o serviço e os componentes relacionados acima? Como demonstrar as relações entre cada componente, suas interações e dependências junto a outros componentes e serviços em um ambiente decisório extremamente politizado? Como justificar, ou não, o desenvolvimento de um novo serviço após a efetiva análise de todos os componentes afetados pelo mesmo?

Neste tipo de organização com acentuada segmentação decisória, onde são constantes as alterações de prioridades e onde restrições orçamentárias são impostas por exigências legais para a realização de investimentos e aquisições, é facilmente percebível, mas não igualmente justificável, onde residem os fracassos nas implementações de serviços.

A falta de ferramentas, automatizadas ou não, voltadas à consolidação e demonstração de toda esta intricada rede de relacionamentos entre serviços e seus componentes e a já conhecida e habitual forma de atuação no estilo “apaga incêndio” (acentuando a falta de planejamento que deve preceder a fase de desenho de um novo serviço) restringem e limitam a aplicação das melhores práticas relacionadas à gestão da Tecnologia da Informação para o cenário apresentado.

E você? Já viveu ou vive estes mesmos problemas durante a execução de suas atividades? Como conseguiu contorná-los e desenvolver um novo serviço considerando todos os seus aspectos relevantes e minimizando as chances de fracasso de sua implementação?

Contribua com sua experiência e colabore com o blog no sentido de disseminar como as melhores práticas de gestão podem REALMENTE agregar valor ao negócio.

O prazo de retorno de uma aplicação é um importante indicador de risco. Quanto menor este prazo, menor também é a chance da solução desenvolvida tornar-se obsoleta e mais flexível se torna a organização na adoção de novas tecnologias. Além disto, prazos de retornos menores possibilitam o desenvolvimento de soluções intermediárias que vão substituindo ao longo do tempo as soluções deficientes evitando o longo prazo de espera de uma substituição integral.

Decisões relativas ao desenvolvimento de software são permanentes? Conhecidos os prazos e esforços associados a decisões deste tipo gostaríamos de acreditar que sim. O problema é que tecnologias evoluem e novas soluções rapidamente tornam ultrapassadas as soluções existentes. Como exemplo, posso citar decisões recentes vividas ao longo de minha carreira: organizações que decidiram por soluções centralizadas baseadas em mainframes e terminais burros a menos de 12 anos atrás se viram obrigadas a rever suas opções e direcionar suas estratégias para o desenvolvimento de sistemas baseados na web. Infelizmente, se a organização não conseguiu obter retorno suficiente do sistema antigo para cobrir seus custos de desenvolvimento, todos os seus esforços resultaram em um ROI negativo. Para estes casos, o prazo de retorno de uma solução - o ponto no tempo após o seu desenvolvimento onde seus benefícios equivalem-se aos seus custos - é uma medida crítica de seus riscos e deveria ser encarada também como uma importante medida a respeito da flexibilidade da organização.

RISCOS

Para a avaliação de riscos, quanto maior o prazo de retorno de uma aplicação, maiores as chances de ocorrência de dois tipos de riscos: tecnológicos ou financeiros.

Riscos tecnológicos são os riscos de uma nova tecnologia tornar as soluções existentes obsoletas. O surgimento da internet apresentou numerosos exemplos de aplicações clientes-servidores bem projetadas e desenvolvidas mas que tornaram-se obsoletas praticamente de um dia para o outro. Diversas organizações que investiram em projetos clientes-servidores de longo prazo se viram forçadas a abandonar estas aplicações e partir para o desenvolvimento de aplicações baseadas na web. Aquelas que optaram por projetos com prazos de retorno menores provavelmente conseguiram recuperar seus custos antes de descartar a aplicação integralmente.

Os riscos financeiros são aqueles onde um fator não-tecnológico influencia a aplicação. Fusões, aquisições, mudanças no quadro gestor e pressões competitivas influenciam a infra-estrutura corporativa tecnológica e pode reduzir a chance de se obter o ROI esperado.

FLEXIBILIDADE

Você pode não desejar mudar para uma nova tecnologia - mas seu competidor pode. No atual ambiente extremamente competitivo do mercado, adotar aplicações com logos prazos de retorno influencia de forma negativa a habilidade corporativa de reação rápida às oportunidades trazidas pela nova tecnologia. Organizações tradicionais estabelecidas apenas no mundo físico apresentaram grandes dificuldades em se estabelecer no mundo virtual. Elas gastaram um tempo considerável integrando seus processos existentes e soluções legadas enquanto organizações “virtuais” estabeleceram-se muito rapidamente. Seus sistemas de groupware alcançaram seus fornecedores e clientes? Organizações com sistemas de mensagens legados vêm reagindo vagarosamente aos benefícios de uma extranet e estão se distanciando de iniciativas mais flexíveis. Estas organizações estão sobrecarregadas com os custos de decisões tomadas anos atrás.

Uma vez alcançado o prazo de retorno é necessária a contínua avaliação dos benefícios de todas as soluções existentes e o rápido descarte  daquelas tornadas obsoletas por qualquer nova tecnologia.

DESENVOLVER E SUBSTITUIR

A flexibilidade alcançada pela adoção de curtos prazos de retorno oferece uma oportunidade para avaliar soluções de software de curto prazo ou descartáveis. Você pode decidir que uma solução perfeita leve três anos para ser desenvolvida, mas uma solução temporária pode prover benefícios reais à corporação neste interim. O cálculo do prazo de retorno permite o desenvolvimento rápido de uma solução, sabendo-se que mesmo incompleta, sua intenção é de ser substituída em um futuro de curto prazo.

Seguir uma estratégia de desenvolvimento e substituição pode ser uma forma mais efetiva de se maximizar o ROI para a corporação. Implementar imediatamente uma boa solução enquanto se planeja uma solução futura melhor ou mais completa, possibilita o aumento do retorno imediato do ROI enquanto oferece a flexibilidade de mudança de direção futura no caso do estabelecimento de uma nova tecnologia.