Segue a descrição do evento:

Introdução:
Atualmente o Gerenciamento de Serviços de TI tornou-se um fator crítico dentro e fora da TI. Ter conhecimento sobre os diversos frameworks, boas práticas e normas, sobre a aplicabilidade de cada um dentro de uma organização e seus benefícios é de extrema importância para os profissionais desta área. Participe deste Webinar e obtenha uma visão geral sobre os mais conhecidos frameworks e normas utilizadas mundialmente nas organizações.

Objetivo:
Apresentar os frameworks e normas mais utilizados ao redor do mundo como: ITIL®, Cobit, CMMI, Green IT, Cloud Computing, Business Information Management (BIM®), Normas ISO/IEC 20000 e 27000), etc, bem como seus benefícios e área de aplicação dentro das organizações.

Público alvo:
Profissionais de TI e fora de TI que já atuam ou queiram atuar na área de Gerenciamento de Serviços de TI e desejam ter uma visão integrada dos principais frameworks disponíveis no mercado.

Palestrante – Marcos Sabino Gomes
Consultor de Governança de TI da High IT que possui certificações como ITIL Expert, ISO 20000, ISO 27002, BIM®, Cloud Computing, que já atuou em diversos segmentos como finanças, manufatura e serviços, efetuando avaliação, desenho e implementação dos processos e normas relacionadas à TI, aplicando diversos treinamentos relacionados ao tema.

Inscrição gratuita: Para garantir a participação no evento clique em Register do lado esquerdo da tela neste site da Exin –  http://bit.ly/JWIgvW

A necessidade de alinhar objetivos e estratégias da organização à execução de portfólios, programas e projetos não é uma tarefa trivial. Comunicar esta estratégia de forma eficiente e torná-la eficaz é um desafio constante para as organizações.

Alinhada a esta demanda organizacional, a implantação de Escritórios de Gerenciamento de Projetos (PMO – Project Management Office) cria mecanismos que irão permitir acompanhar e monitorar se os projetos executados estão alinhados às estratégias das organizações, por exemplo.

Mas seria só este o papel do PMO na organização?

 Definindo um Escritório de Gerenciamento de Projetos (PMO)

Existem várias definições para o Escritório de Gerenciamento de Projetos, que de certa forma se convergem /complementam, tais como:

• Rad & Raghavan (2000) uma entidade organizacional que provê o foco institucional nos procedimentos de gerenciamento de projetos;
• Crawford (2000), como um provedor de serviços e processos completos para gerenciamento de projetos e que o mesmo também atua como centro de excelência em gestão de projetos dentro da organização;
• Cleland & Ireland (2000) como grupo de suporte que provê serviços para os gerentes de projetos, gestores seniores e gerentes funcionais trabalhando em projetos;
• Kate (2000) define o Escritório de Gerenciamento de Projetos como uma unidade do negócio focada na eficiência do gerenciamento de projetos e programas dentro da organização;
• Kerzner  (1992) diz que o time do projeto é uma combinação do Escritório de Gerenciamento de Projetos e os empregados funcionais.

1. Em projetos ágeis não é necessário fazer uma grande entrega no final do projeto. É possível e desejável que se faça pequenas entregas com a possibilidade do cliente iniciar o uso imediato do que já foi entregue. Isso por si só já leva a uma maximização do ROI dado que o projeto já pode ser usado enquanto novas funcionalidades são criadas. Cada nova entrega pode trazer um pouco de retorno.

2. Como podemos e devemos fazer pequenas entregas, em projetos em que os métodos ágeis são usados, a tendência natural é ignorar os itens que não geram valor. Estudos mostram que somente 20% das funcionalidades são usadas sempre ou frequentemente e 64% das funcionalidades são desperdício.

Isto tudo também faz com que o projeto tenda a ser finalizado antes, liberando os recursos para outras demandas.

3. Em  projetos tradicionais, a mudança de escopo não é bem-vinda, mas em métodos ágeis, as mudanças são bem-vindas, principalmente, quando elas levam a uma melhor adaptação do projeto às necessidades de negócio com definição de prioridades entre elas.

Será que não podemos fazer várias pequenas entregas no lugar de uma grande entrega?

Será que o escopo não pode ser alterado?

Será que as funcionalidades não podem ser reordenadas?

Métodos ágeis representam sim e muito uma quebra de vários paradigmas em relação a forma de como os projetos são conduzidos tradicionalmente e  isso pode ser muito bom se bem utilizado.

Resolvi este pequeno dilema inicial ao ler, mais uma vez, o “Poema em Linha Reta” de Álvaro de Campos (heterônimo de Fernando Pessoa). Se você ainda não leu, leia.

O poema já começa de uma forma instigante:“Nunca conheci quem tivesse levado porrada. Todos os meus conhecidos têm sido campeões em tudo.”

Portanto resolvi me juntar ao Álvaro de Campos e em vez de falar sobre o que poderia ser feito ou sobre um modelo de qualidade ou até um case de sucesso, falarei sobre um fracasso retumbante.

Antes de iniciar, um pouco do que está por trás do meu currículo: sou formado em Engenharia da Computação com Ênfase emEngenharia de Software na UMESP.

Tenho alguns bons anos nesta caminhada junto às boas práticas, modelos de qualidade e frameworks. Já implantei CMM, CMMI, MPS.BR e ISO. Já participei de projetos com o objetivo de implantar processos face ao que prega a biblioteca ITIL e na implantação de Escritório de Projetos. Obtive as certificações ITIL e CObIT Foundation em um período de um mês. Obtive a certificação PMP e depois obtive a certificação ITSM (também chamada, informalmente, de ITIL Master ou apenas ITIL Manager).

Mas nada disso, experiência, background acadêmico e certificações, impediu que eu cometesse os mais básicos dos erros: não definir bem o escopo, não gerenciar os riscos e não gerenciar stakeholders.

Primeiro projeto na empresa (sem datas/nomes), único PMP do PMO e com a missão de gerenciar um projeto de melhorias em sistema existente. Não era um sistema complexo, pois ele não tinha uma montanha de regras de negócio, era muito conhecido (demandante usava o sistema cotidianamente) e o fornecedor escolhido para construir tinha um histórico muito bom em projetos passados. Piece of cake, diriam os americanos.

A coisa começou a desandar quando o fornecedor perdeu um dos seus líderes técnicos, restando outro, competente, mas que se viu com vários projetos na mão. Depois a organização perdeu um líder técnico e que desenvolvia também, responsável por outro projeto no mesmo sistema. O meu projeto incorporou os requisitos que faltavam serem desenvolvidos do dele.

Foi quando caí na armadilha mais básica de todas: fui resolvendo os problemas entrando em acordo com os stakeholders sem documentar nada e fui descobrindo que a área que deveria conhecer o sistema, pois era usuária principal, tinha acabado de mudar de comando. Portanto o gestor e o seu time não conheciam tão bem assim. Já o fornecedor, corresponsável pela documentação, estava equilibrando vários pratos e acabou não documentando nada também.

O resultado disso foram as constantes discussões para estabelecer as regras, defini-las corretamente, ou corrigi-las. Tudo isso sem documentação sendo atualizada. Os impactos não foram avaliados corretamente, tínhamos uma dependência de um sistema externo de uma empres apública, que entrou em greve, tivemos constantes trocas de requisitos e tudo isso só na palavra, o que para mim era o suficiente.

Para mim. Para alguns outros não é, portanto um stakeholder começou a pedir mais coisas do que havíamos combinado e sempre perguntava, quando eu dizia que não fazia parte do escopo, onde isso estava escrito.

O projeto simples virou um bicho-de-sete-cabeças. Atrasou muito, o fornecedor teve estresses e “sujou” seu passado, pois acabou atrasando outros projetos também, eu me estressei com o projeto e com a área demandante, não tive o apoio necessário da alta gerência e ainda me vi obrigado a ouvir “ué, você não é PMP?”. Sim, sou, mas não sou perfeito e nem mágico.

Eu poderia jurar que já sabia estas lições aprendidas, mas pelo visto ainda não havia absorvido. Não adianta você ser um ás da negociação se não documentar tudo, não adianta pular etapas só porque você julga que o projeto será simples, entenda bem os stakeholders para saber gerenciá-los, fechar e defender o escopo é uma arte necessária e gerenciar riscos é fundamental. No mínimo é isso que precisamos tirar do fracasso. Uma lição para não repeti-lo mais.

Depois deste projeto eu aprendi e absorvi: o projeto seguinte foi um sucesso.

Ele incomodado, levantou com disposição, livre do cochilo, permitindo-se investigar o que estava a atormentar o seu colega, que nunca foi de gritar para ninguém.

- Calma gajo, o que aconteceu? –  Perguntou ele,  mas, ofegante, seu colega não conseguiu falar.

- Toma essa água, disse ele.

Foi então que regressaram as choraminhices, como se houvesse se deitado mais etanol na fogueira. Ele impaciente e arrependido por haver perdido um cochilo indagou:

- Diga lá pa, antes que derramo sobre vós um balde de água! – Naquele momento, o gato saiu correndo miando desesperadamente.  O Tigre intrigado foi informado que um Elefante malicioso descarregou no Gato miador, toda água de sua tromba. Porque atendia pausadamente, e sem disposição a solicitação do Elefante.

O Elefante, superintendente da floresta, se achou no direito de criticar o ritmo com que o Gato executava as suas atividades. O Tigre que era o chefe direto do Gato foi conversar com o Elefante, pois achava que ele não deveria ter ordenado o Gato.

- Chefe, quem manda lá só eu, não cabendo reclamação de sua parte.

O Elefante ouviu atentamente a reclamação e ficou tão triste e cabisbaixo que demitiu imediatamente o Tigre alegando que a queixa deveria ter sido apresentada pelo Leão, chefe imediato do Tigre.

Ele saiu, segurando sua  própria cauda, que parecia muito pesada, andava com dificuldade, quase errando os passos. Quando comunicou a equipe sobre o seu desligamento, ouviam-se vozes em coro de manifestação de descontentamento. Afinal ele era muito querido e sua liderança era exemplar, mesmo com os tiques de cochilo que o visitavam inesperadamente. Todos pediram demissão deixando o departamento como uma cabeçada desprovida de cabelo.

Essa atitude fez com que o Leão agisse bruscamente, colocou as mãos no rosto. “Quem ficar terá aumento salarial”, disse depois de pouco pensar, ação repetida por pescador que arremesse anzol na água para ver o que acontece. O apelo foi ignorado.

A avalanche atingiu outros departamentos que já apresentavam fisionomias de arrebentação. Todos os dias apareciam anúncios de oferecimento de oportunidade de emprego na terra do Elefante. A notícia chegou muito rapidamente aos ouvidos do Rinoceronte, concorrente imediato do Elefante, que não hesitou em apresentar uma proposta comercial para incorporar a floresta decadente.

Vejo que aproveitando a onda de palestras motivacionais, devamos divulgar uma nova era no mercado profissional.

Ao invés de motivar o funcionário a “gostar” de seu ambiente de trabalho, fazendo-o se adequar á empresa, porque não divulgarmos essa nova filosofia, onde a empresa respeitando o profissional busca ela a se adequar à novas tendências procurando melhor recolocação e melhores metodologias afim de obter melhores resultados, tanto para a empresa quanto para o funcionário.

Muito se fala em cuidar do funcionário, em empresas de pessoas não de máquinas, mas pouco se faz para mudar esse conceito. As palavras não saem das cartilhas para a vivência do profissional, gerando muita contradição, descrédito e infelicidade aos profissionais.

Na busca pela contratação de um profissional, as empresas procuram os melhores profissionais, os que melhor se adequem aos dogmas da empresa, onde muitas vezes para atrair o profissional, promessas infundadas são feitas, castelos de areia são criados, mas ao notar a verdade o profissional se afasta e retoma a busca por recolocação no mercado, ocorrendo um ciclo sem fim, com alto custo administrativo para re-treinar e realocar pessoas, gerando conflitos inclusive nos profissionais que permanecem e antes estavam felizes com seu ambiente.

A troca constante de profissionais, de cargos e de estrutura é um meio de stress que já torna-se comum aos profissionais, mas que tem grande carga negativa sobre suas vidas, podendo ser comparada com a separação dos pais, que por mais cotidiano que seja, deixa marcas.

Porque então ao invés de “vender” a imagem da empresa aos profissionais, não é efetuado um acordo de forma transparente entre Contratante x Contratado?

Porque ao invés de ao fim de 90 dias, se a empresa não se adaptar ao profissional, o mesmo é demitido? Onde fica o receio da empresa em, ao fim de noventa dias, não perdê-lo e permanecer buscando o melhor para manter o profissional?

Porque a empresa contratar o profissional e não o profissional contratar a empresa ao qual trabalhará?

Muitas empresas que se adaptaram a essa nova era, já obtiveram sucesso e tornaram-se as mais rentáveis, então porque não mudar?

A exemplo da Área da Saúde, muito é gasto para corrigir problemas de saúde, enquanto pouco é investido em sua prevenção!!!

O ANS descreve o Serviço, documenta Metas de Nível de Serviço (MNS) e especifica as responsabilidades do Provedor e de seus Clientes. Um único ANS pode cobrir múltiplos Serviços ou múltiplos Clientes.

ANS são suportados por ANO (Acordos de Nível Operacional), os quais são documentos intra-organizacionais que definem os acordos entre as áreas do Provedor. Estes são estruturados de forma a garantir que os objetivos definidos no ANS sejam devidamente entregues.

ANS também são suportados por CA (Contratos de Apoio), os quais são documentos estabelecidos com os respectivos Fornecedores, que contribuem significantemente para a entrega dos Serviços de acordo com os objetivos definidos no ANS.

ANS devem ser revistos regularmente, a fim de garantir um desempenho em conformidade com os Níveis de Serviço acordados, e estão totalmente sujeitos ao Processo de Gerenciamento de Mudanças/Liberações.

Desta forma, fica sob responsabilidade do Gerente de Nível de Serviço, com o apoio dos respectivos Analistas (inclui-se Gerente de Fornecedores e Contratos quanto aos CA), que o nível de suporte e os objetivos de desempenho acordados nos ANS sejam suportados e atingidos. Tais papéis devem identificar falhas para que os ANS sejam prontamente renegociados, se necessário.

Objetivos

• Formalizar Níveis de Serviço acordados entre Provedor e Cliente, possibilitando que os Serviços sejam entregues com excelência;
• Definir papéis e responsabilidades das partes para que suportem todo o Processo;
• Melhorar a comunicação e relacionamento entre as partes;
• Definir e monitorar o desempenho contra as MNS definidas, medindo a conformidade dos objetivos acordados, bem como o desenvolvimento contínuo de Programas de Melhoria de Serviço (PMS);
• Fornecer um mecanismo de revisão dos Serviços, o qual deve ser utilizado para definir ações de melhoria, sempre que necessárias;
• Alinhar e definir a expectativa do Cliente quanto ao Serviço provisionado, buscando melhorar continuamente a respectiva satisfação. Note-se que a “SATISFAÇÃO DO CLIENTE = PERCEPÇÃO – EXPECTATIVA (onde a pontuação positiva ou zero indica CLIENTE SATISFEITO)”.

Informações que poderiam estar contidas nos SLA / ANS (should)

1) Informações Básicas
ID
Identificação do ANS.

Nome / Título
Nome / Título do ANS.

Data
Data do acordo / atualização do ANS.

Versão
Versão do ANS.

Prazo
Prazo do ANS.

Descrição do Serviço
Descrever com detalhes o Serviço acordado.

Escopo do Serviço
Descrever com detalhes o escopo e funcionalidades acordadas.

Objetivos
Objetivos detalhados do ANS.

Comunicação
Descrição de todos os meios e pontos de contato entre o Provedor e o Cliente (Nomes e Funções, Números de Telefone, Endereços de e-mail, Dias/horários de disponibilidade dos contatos).

Horário do Serviço
Horário de disponibilidade do Serviço.

Horário de Suporte, Especiais e Críticos
Horário em que o suporte ao Serviço está disponível, bem como eventuais horários especiais e críticos.

Níveis de Suporte e Escalação
Onde os níveis de Serviço, procedimentos de escalação e qualidade do Serviço são detalhados.

Este também deve incluir os meios possíveis para formalizar queixas/reclamações quanto ao Serviço provisionado, bem como quais são os procedimentos para gerenciá-las.

Papéis e Responsabilidades
Papéis e Responsabilidades detalhados quanto às duas partes, os quais devem ser seguidos conforme estabelecido (Provedor e Cliente).

Obrigações
Descrição de todas as obrigações de ambas as partes. O Provedor e o Cliente devem estar totalmente comprometidos com tais atividades.

Pré-requisitos
Pré-requisitos que devem ser preenchidos por ambas às partes.

Restrições
Qualquer limitação ou restrição do ANS.

Análise Crítica do ANS
O ANS deve mostrar como o acordo é revisado. Ambas as partes devem estar de acordo com o proposto. Ex: Talvez seja necessária uma revisão de 04 a 06 meses ou deve ser revisado pelo menos anualmente. (Selecionar de acordo com o Tipo do Cliente: Quadrimestral, Semestral ou Anual).

Análise de Desempenho do Serviço (Relatórios)
O que será medido, como isso será medido, e como os relatórios devem ser gerados, distribuídos e analisados. Ambas as partes devem estar de acordo com o proposto. (Selecionar de acordo com o Tipo do Cliente: Quadrimestral, Semestral ou Anual).

Plano de Ação
É necessário incluir o que o Provedor fará no caso do não cumprimento do ANS por um determinado período. Ex: 02 meses consecutivos.

Programa de Melhoria de Serviço (PMS)
Procedimentos utilizados para ajustes e melhoria contínua dos Serviços provisionados.

Termos de Pagamento (Cobrança)
Fórmula e método de pagamento (Cobrança).

Reajustes
Informações detalhadas quanto aos reajustes do Serviço (índice de correção, prazo de aplicação etc.).

Preço
Informações detalhadas quanto ao preço do Serviço.

Descontos
Informações detalhadas quanto aos descontos do Serviço.

Penalidades
Penalidades as quais devem ser exercidas em eventual quebra de nível de Serviço.

Término / Rescisão
Informações detalhadas quanto ao termino / rescisão do ANS.

2) Informações Adicionais
Contrato Jurídico
Descrever os Contratos Jurídicos que suportam este ANS.

CA que o Suporta
Descrever os CA (Contratos de apoio) que suportam este ANS.

ANO que o Suporta
Descrever os ANO (Acordos de nível operacional) que suportam este ANS.

Demais ANS Suportados
Descrever os demais ANS (Acordos de nível de Serviço) que são suportados por este ANS.

 Treinamento
Qualquer tipo de treinamento necessário ao Cliente ou ao Provedor.

Incidentes
Descrição de que forma eventuais Incidentes devem ser resolvidos, o mais rapidamente possível.

Problemas
Descrição de que forma eventuais Problemas devem ser investigados e solucionados.

Mudanças
Descrição de que forma eventuais Mudanças devem ser conduzidas, vide janelas acordadas entre as partes.

Segurança
Os requisitos de segurança física e lógica para o Serviço.

Confidencialidade e Integridade
Definição do que é considerada confidencialidade e integridade do Serviço.

Disponibilidade e Confiabilidade
Definição do que é considerada disponibilidade e confiabilidade do Serviço, incluindo conceitos como MTRS, MTBF, MTBSI.

Desempenho
Detalhes do desempenho do Serviço e tempos de resposta.

Capacidade
Detalhes dos requisitos de capacidade do Serviço.

Continuidade
Detalhes dos níveis mínimos e qualidade do Serviço em caso de desastres / incidentes gravíssimos, e como o plano de continuidade é abordado.

Glossário
Explicação de quaisquer abreviações ou terminologias utilizadas, para ajudar no entendimento dos termos contidos no ANS.

Controle de Alterações e Melhorias
Registro detalhado de todas as alterações acordadas, datas e signatários. Deve conter também detalhes sobre o histórico do documento e suas revisões.

Concluindo…
Você acredita ser viável este detalhamento com “N informações”, de acordo com a cultura das empresas brasileiras?

Como esta estrutura atua como o primeiro nível de suporte e tem forte interação com os usuários, seu desempenho define a percepção que as áreas de negócio têm do serviço de TI. É como se o Service Desk fosse a “vitrine da TI” exercendo um papel significante e que irá moldar a reputação da organização de TI por inteiro. A expectativa dos usuários vai além da resolução de suas questões e esperam que estas questões sejam resolvidas de forma rápida e eficaz, buscando maximizar a sua satisfação no serviço. Para gerenciar estas expectativas de forma equilibrada e a custos justificáveis, você deve operar um Service Desk buscando melhorar as taxas de resolução no primeiro contato e minimizar os escalonamentos para segundo e terceiro níveis de suporte. Para tanto, o Service Desk deve estar bem capacitado e munido de ferramentas apropriadas que proporcionem agilidade e precisão no atendimento. Vamos a algumas questões-chave relacionadas a pessoas, processos e investimentos em tecnologia que os gestores de TI precisam fazer para melhorar a eficácia do Service Desk.

1. Discipline os usuários a utilizarem o Service Desk como canal de suporte. É muito comum que os usuários, por conveniência ou por conhecer o especialista que pode resolver seu problema com mais rapidez, acaba não acionando o suporte através do Service Desk. Nesta situação também é muito comum que este atendimento, digamos fora do processo, não seja registrado e portanto perde-se uma informação histórica dos acionamentos de TI. Além disso, a questão endereçada ao especialista muitas vezes poderia ter sido resolvida pelo Service Desk por ser algo simples e tira o foco de atividades que poderiam agregar mais valor ao serviço, como a identificação da causa-raiz de problemas. Segundo pesquisa do Forrester Research o custo de um chamado ao Service Desk fica entre 18 e 23 dólares. Quando um chamado é transferido para o segundo nível o custo passa a 35 dólares ou mais. Caso ainda seja necessário escalar para o terceiro nível o custo do ticket pode chegar a 100 dólares. Além do custo, a escalação aumenta o tempo de atendimento e diminui a satisfação do usuário. Por isso, os líderes de TI devem entender os custos por chamado de todos os níveis de suporte e criar a cultura de que todos os acionamentos devem ser realizados ao Service Desk.

2. Aumente as taxas de resolução no primeiro contato (FCR – First Call Resolution). A taxa de resolução no primeiro contato é um importante indicador da eficiência de um Service Desk, pois quanto maior o percentual, maior sua capacidade de resolver as questões. Com a equipe capacitada, habilidades e ferramentas apropriadas para dar suporte ao processo, podemos aumentar a resolução dos chamados no primeiro contato e,  consequentemente, contribuir para aumentar a satisfação. Pesquisas de mercado apontam que uma boa taxa esteja entre 65% e 75%, contudo, esse indicador deve ser interpretado dentro do cenário e realidade da TI, principalmente com relação à tecnologia utilizada, tipo de indústria e cultura organizacional. Para o aumento desta taxa, algumas ações podem ser consideradas para o aumento desta taxa tais como: capacitação continuada, estruturação de bases de conhecimento (scripts de atendimento, manuais, checklists etc.) e ferramentas que permitam acessar remotamente a estação de trabalho do usuário. Também vale considerar dar mais autonomia ao Service Desk nas ferramentas administrativas de infraestrutura.

3. Tenha no Service Desk pessoas especialistas em atender pessoas, não em tecnologia. A maior parte dos chamados realizados ao Service Desk é de baixa complexidade técnica e portanto não exige conhecimento especializado do profissional que irá atuar na equipe. Busque ter no grupo pessoas que tenham habilidades interpessoais e foco no atendimento ao cliente. Estes profissionais precisam ter a capacidade de se relacionar com os usuários sem utilizar jargões nebulosos, termos complicados e acrônimos como VPN, DBA, SaaS, LAN, WAN, VoiP, IP e outros que as vezes sem a ajuda do Google fica difícil saber o que é. Outros aspectos relevantes são: empatia com o usuário, observando as questões sob a perspectiva dele; entendimento e aceitação de que o problema do usuário afeta o negócio; consciência de que sem o usuário não haveria Service Desk; entender que o usuário é especialista em sua área de atuação, não em TI.

- Não vendo mais, disse ele e imediatamente começou a construir galpões para depositar as sementes.

Foi então que a comunidade percebeu a importância de guardar para o plantio. Chovia regularmente e estavam diante do dilema da falta do que semear.

- Esse cara é chato mesmo, nunca gostei dele, comentou o Jacaré.

- Sabe duma? Perguntou a gazela.

- Que carestia é essa, meu Deus, Acrescentou a búfala.

- Pois é, dizem que o senhor elefante está a esconder abóbora para elevar o preço.

Os comentários sobre a ausência de abóbora começaram a ocupar a população animal. Só se falava de abóbora e sua ausência. Enquanto isso o elefante construía mais galpões para esconder as abóboras.

- Vamos organizar uma greve, sugeriu o Leopardo, que estava assustado ao ver seu pagamento virar pó. Já que começou a se praticar uma espécie de candonga. Todos estavam dependentes da abóbora. Ninguém conseguia viver sem. Recorriam ao mercado alternativo que se aproveitava dessa carestia para faturar alto.

- Ferrou! Comentava o tigre.

- Deixa disso, é possível viver sem abóbora.

- A nossa força é igual a do vento, disse o sapo.

- Eh, vamos cruzar os braços, comentou o tamanduá.

Os animais da floresta se reuniram para cruzarem os braços. Não queriam trabalhar para o Elefante Cinzano sonegador de abóbara. Mas o Elefante não deu ouvido. Começou a fazer lista dos grevistas e a demiti-los.

- Por que só o elefante guarda as sementes? – Perguntou o filhote de Leopardo que andava de um lado a outro.

- Eh, detesto esses monopolistas, concluiu o tamanduá.

Mas alguém os lembrou de que as sementes estavam para todos os que decidiram guardar para aquela época, que ninguém se importava em guarda na abundância.

- Essas sementes pertencem aos trabalhadores.

- Pertencem a todos nós, trabalhador ou não.

Os elefantes ao perceberem a concentração de animais, encheram as trombas com água e saíram a dispararem jatos de água.

Vendo os problemas que cada dia surgiam os animais contratam o hipopótamo para intermediar na negociação. Assim, o Elefante estabeleceu o contrato de comercialização a um custo exorbitante e todos os interessados passaram a comprá-los do hipopótamo. A partir de então, começaram a guardar as sementes.

Quando falamos em BPM tentamos traduzir os processos de uma empresa em fluxos de informação, e não simplesmente modelados por sistemas.

Nessa filosofia os processos são pensados e definidos independentes da construção do sistema, desta forma é possível interagir produtivamente com todos os envolvidos nas rotinas e processos levando em conta a contribuição de cada profissional, e os processos a partir de então definidos podem quebrar paradigmas e conceitos ultrapassados ou mesmo modernos de mais para a realidade da empresa em questão, criando um conceito de colaboração produtiva e mútua muito eficiente, sendo possível utilizar sistemas prontos internos em um segundo momento, que já possuem seu ciclo de vida bem definido, para automatizar processos agora definidos do ponto de vista da gestão do negócio da companhia.  Um gancho para uma implantação de Workflow será montado com base em processos bem definidos, a própria possibilidade e viabilidade de uma implantação de automação dos fluxos de informação e processos, já coloca a organização em uma situação privilegiada e diferenciada no mercado, auxiliando definitivamente ao processo produtivo em conjunto das mais variadas culturas e geração que possam existir na empresa. Importante lembrar que não são as implantações dessas metodologias ou ferramentas que contribuem para essa homogeneidade e sim o processo de implantação delas.

Obviamente que um processo desse tipo deve ser implantado com orientação profissional específica, empresas com esse perfil de conflitos, dificilmente vai possuir em seu quadro atual de colaboradores esses especialistas, principalmente se for de pequeno porte, esse apoio poderá ser um consultor externo, ou mesmo uma nova contratação. Antes de tudo é preciso avaliar dentro da empresa se existe alguém com perfil e comprometido para atuar nesse papel. Mesmo quando a função for liderada internamente é bom auxilio técnico externo, mesmo que pontual, pois é princípio da gestão de conhecimento eficaz.

Forte abraço, até a próxima.

Na maior parte dos artigos que publiquei neste espaço busquei mostrar formas de agilizar processos, implementar projetos com qualidade e indicar os caminhos mais adequados a implementação de um sistema ou a operação em TI como um todo.

Nos últimos textos falei muito sobre o dia a dia das áreas de TI em que um gestores sem conhecimento e competência parecem estar se proliferando.

E hoje, não volto a falar sobre eles, mas, de uma forma diferente. Até eles podem ter um final não tão feliz como se imagina.

O fato é que, pra tudo nessa vida, se precisa de competência…até para ser incompetente.

Vamos, como de costume, ilustrar uma historinha:

Era uma vez um pseudo gestor de TI, que até a pouco tempo era do ramo de artes plásticas.

Esse pseudo gestor receberá a alcunha de “Senhor X”.

Um belo dia, um amigo muito próximo do Sr. X lhe chama pra trabalhar em uma grande empresa de TI (que hoje já nem é tão grande assim) num cargo em que não será mais que um assistente de luxo, mas que, com uma pitada de papo, faz o Sr. X pensar que irá mandar e desmandar.

Esse grande amigo iremos chamar de “Senhor Y”.

Nesta empresa, os Senhores X e Y são amigos pessoais de um diretor de TI muito influente.

Esse diretor (e também grande amigo), chamaremos de “Senhor Z”.

O Sr. X começa suas funções, mostrando não ter a menor condição de fazer aquilo a que foi contratado, mas, tem cobertura dos Senhores Y e Z.

O tempo passa, a fama de incompetente do Sr. X corre a empresa toda. Sua maior virtude é fazer o papel de “catraca”, verificando os horários de quem entra e quem sai, mas, aquilo a que foi contratado continua bem abaixo da média.

Lembrando que, sua incompetência, ainda que latente, é encoberta pelos Senhores Y e Z.

Um belo dia o diretor (Sr. Z) resolve mudar toda estrutura das equipes. Designa alguns nomes para o cargo de Supervisão de TI, estando entre eles, o Sr. X.

Muitos ficam indignados e chegam até a dizer que “o crime compensa”.

O Sr X assume o cargo e em pouco tempo forma uma legião de inimigos…dentro e fora de seu time.

A fama de incompetente aumenta a passos largos.

Começa então o turn over. O entra e sai de funcionários que parece não ter fim.

A alta direção não questiona porque nela estão os Senhores Y e Z…amigos do Sr X.

O Sr X se transforma! Trata as pessoas com altivez, assedia moralmente alguns que ele elegeu como alvos.

Dois funcionários estratégicos que estavam totalmente desgastados com a empresa e a gestão pedem demissão e o caos começa a tomar conta da equipe.

Nada que cause problemas ao Sr X. Ele tem uma cobertura eficaz e parece que vai ficar ali por muito tempo…ou o tempo em que os Senhores Y e Z estiverem ali.

Quando tudo parece acabar assim, vem a noticia que a grande empresa de TI (que hoje já não é mais tão grande assim) será vendida e absorvida por outra empresa em total decadência.

O processo é visto por todos como duas empresas decadentes se unindo para “morrerem abraçadas”.

No processo de integração novos diretores chegam, novos gestores também. As normas mudam, os processos também.

Cargos de alto escalão são extintos, funcionários que tinham uma “republica própria” estabelecida são demitidos.

Nesse período transitório os Senhores Y e Z são alocados em novos departamentos e vão seguir suas vidas em novas realidades.

O detalhe mais importante nisso tudo é que, a partir de agora, o Sr. X está por sua própria conta. Não tem mais a cobertura de seus grandes amigos.

Apesar de tudo, continua suas funções da mesma forma, tratando funcionários do mesmo jeito.

Um belo dia, um novo diretor aparece e o Sr. X fica sabendo que ele será seu novo chefe. Um mix de medo e dúvida tomam conta de seus pensamentos.

Como será a partir de agora?

No dia a dia que segue o novo diretor percebe que o Sr X está na área errada. Se pergunta como o individuo chegou até ali…afinal de contas “este ser é muito fraco”.

O desespero toma conta do Sr X. Ele separa duas horas de seu dia sentado na mesa do Sr Z e mais  40 minutos na sala do café se lamentando com o Sr Y.

Estes tentam orientar seu “pupilo” em como agir na nova realidade, mas, as tentativas são inúteis. É o mesmo que tentar fazer um gato latir ou um porco relinchar.

As “saias justas” que o Sr. X entra são inúmeras. Broncas diárias do novo chefe, falta de respeito e companheirismo de seus funcionários que, fazem apostas de quanto tempo o individuo aguenta a pressão.

O novo diretor fala com os funcionários, um por um. Vai pegando referências e vendo que o Sr. X não é a pessoa indicada ao cargo. Aliás, o Sr. X deveria voltar ao ramo de artes plásticas.

Quando bons funcionários começam a sair da empresa por causa do Sr. X, o novo diretor finalmente muda a estrutura de seu departamento, tirando os poderes que o Sr. X tinha e os delegando a outro funcionário, infinitamente melhor preparado.

O Sr. X agora atua em uma função a qual não prejudica mais ninguém, muito pelo contrário. Os problemas que a nova atribuição lhe trará não são mais que uma forma que o novo diretor encontrou de fazê-lo pedir demissão, afinal, seu muitos anos de casa trariam um alto custo no processo de desligamento.

Nosso personagem tenta suportar com firmeza, pois, não quer pedir demissão e aí uma hora ou outra, um dos lados irá ceder.

O nome desse novo diretor é “Senhor Progresso”. Quando ele chega na empresa, muitos pensam que o nome não lhe cai bem, mas, com o decorrer do tempo começam a entender seus métodos.

Esta história é muito comum não só nas áreas de TI, mas, também em todas as áreas em que as pessoas acoitam incompetentes pelo fato de serem amigos e não pensar nas consequências.

Reflitam na história que foi contada, porque ela é real e nos faz entender que mesmo sem méritos para galgar degraus em uma corporação, a pessoa precisa firmar suas bases e se cercar de cuidados.

O mundo dá voltas e nada mais é que uma via de mão dupla. Tudo que  fazemos, cedo ou tarde vai voltar a nós. E aí a forma como isso volta, depende da forma como foi.

Prometo que o próximo texto enfocará fatos de TI e minha labuta contra os gestores incompetentes acaba aqui.

Abraços

Uilson

Devemos também entender a diferença entre “risco” e “exposição ao risco”. Medir o risco mede simplesmente a variância dos possíveis resultados de um evento, enquanto exposição ao risco mede as consequências dos diversos resultados possíveis do evento. Um evento pode ter um resultado muito incerto (alto risco) porém suas consequências são de baixo impacto para a empresa (baixa exposição ao risco). Mitigar o risco não é tão importante nas decisões de investimento quanto mitigar a exposição ao risco.

Normalmente a minimização do risco traz custos elevadíssimos para as empresas. Portanto, não é possível analisar somente o aspecto de minimização do risco, mas qual é o investimento necessário para cada nível de exposição ao risco. Assim estamos introduzindo mais uma variável ao modelo. Há um trade-off entre menor exposição ao risco e investimentos necessários.

Risco e retorno andam juntos. Quanto maior o risco, maior o retorno exigido pelos investidores. Se um investidor não quisesse correr riscos, ele aplicaria seus recursos em ativos livres de risco e não nas empresas. Risco faz parte do negócio de qualquer empresa. A questão então é qual é o retorno esperado para cada nível de risco. Dizemos que há uma “clientela” para qualquer nível de risco. Há quem invista em uma empresa de prospecção de petróleo. Embora seja de altíssimo risco, o retorno esperado também é elevado. Há empresas que têm níveis mínimos de riscos, porém oferecem baixo retorno para seus investidores. Há clientelas para todos os níveis de risco/retorno. O histórico da empresa é o melhor indicador de qual é a clientela de investidores dela. Não se deve esquecer, contudo, que nenhum investidor está propenso a correr riscos que não tragam o correspondente retorno.

Existem metodologias que permitem estas avaliações para a correta avaliação de retornos sobre os investimentos, entre elas a “Programação Linear”, “Método por Opções Reais” e “Simulação de Monte Carlo”. Assim, avaliar riscos não é simplesmente minimizar ou eliminar o risco ou a exposição ao risco e sim adequar o retorno sobre o investimento para o nível de risco do projeto.

Aquele dia foi atípico para o tigre, que já cedo perdeu a hora, o despertador se recusou a tocar na hora marcada, mas ele acabou acordando. Não abriu os olhos, sentia sono pesado. Curtiu o sono. Dormiu novamente, foi então que viu a imagem do seu pai sonâmbulo a conversar sobre os bons costumes, como nos velhos tempos: “Sim, quem madruga tem apoio celestial”.

O discurso do velho era a carícia que ele desejava, sentiu-se confortado. Dormiu profundamente, até que foi despertado pela empregada. Levantou depois de muito lamento e tentou, em vão, lembrar do sono e visitação do pai. A única coisa que se lembrava era a figura do seu pai. Começou a pensar nos bons exemplos que recebeu e isso ocupou o seu pensamento, enquanto se preparava para mais um dia de labuta. “Oh, meu velho ainda me lembro de tudo, seus ensinamentos são o farol que ilumina o meu caminho, sem eles eu caminharia nas trevas. Nos domingos ainda ouço a tua voz acordando a todos para participar da missa, eu me trocava com dificuldade, louquinho para não ir e ficar mais um pouco na cama. Não havia jeito. Mamãe vinha em seguida e ficava a contar história enquanto eu levantava. Na volta da igreja, ficávamos na biblioteca a ler poemas. Pai,  queria que soubesse o quanto me sinto orgulhoso por seres meu pai e por tudo que me ensinou.”

Com muito custo deixou a casa para labutar, ao chegar encontrou a gaiola aberta, sem o canarinho.

- Quem fez isso?  – Perguntou.

- Sei lá, – respondeu o Colega Leopardo.

O Tigre começou com chorinho, chorou e terminou com choraminhices quando  o Leopardo o consolou,  aconselhou-o a buscar outros hábitos.

- Que prazer háem aprisionar Pássaros? – Perguntou o Leopardo, curioso.

- Gostava quando ele cantava para mim.

- Que gosto esquisito.  Por que não compra músicas com cantares de Pássaro?

O Leopardo comentou da necessidade de liberdade a todos, licenças para manter o canarinho engaiolado, alimentação e cuidados de higiene.

O Tigre não sabia que a empresa onde trabalhava não permitia aprisionamento de passarinho, peixes e animais.

Assim estava ele debruçado sobre a mesa a pensar sobre a zebra do dia e da imagem das Zebras do Quênia, foi nesse momento que se lembrou do que seu pai disse no sonho, gritou:

- É isso, é isso, é isso!

O Tigre saiu correndo sem nada dizer.

Mas como vamos atender a estes requisitos se temos sistemas cada vez mais complexos, que se comunicam através de vários protocolos e serviços de mensageria e interagem com diversas tecnologias e sistemas?!

Esta demanda empresarial está forçando as equipes de desenvolvimento a fornecer aplicações em um menor período de tempo, levando uma necessidade de mudança ao mundo dos testes. Melhorar a qualidade do software e a agilidade do desenvolvimento se tornaram normas para o sucesso neste mundo em constante mudança.

Um dos fatores importantes para garantir a qualidade do software é assegurar que os testes reflitam todas as funcionalidades do sistema em produção e também a interoperabilidade com os demais sistemas. Neste sentido, e pensando no modelo de desenvolvimento ágil, quanto mais cedo o sistema for testado no ciclo de desenvolvimento maior a garantia da qualidade.

Tecnologias avançadas, como a virtualização e a “nuvem” permitem o teste de integração contínua em todo o ciclo de vida do sistema. Além disso, é possível realizar os testes de integração de aplicações compostas, em ambientes heterogêneos complexos, muito mais cedo no ciclo de desenvolvimento.

Desta forma, a solução Green Hat VIE (Virtual Integration Environment) tem o objetivo de endereçar os questionamentos deste artigo, ou seja, aumentar a qualidade do software, diminuir o custo de construção do laboratório de testes e entregar o produto com maior agilidade para o mercado.

Com a solução GH VIE a equipe de desenvolvimento e/ou testes pode virtualizar componentes (HTTP, WebSphere MQ, SAP, web services, BPM, bancos de dados, HL7, SOAP, SWIFT, XML, mainframe) e assim realizar testes que muitas vezes seriam de alto custo, seja devido ao alto valor a ser pago quando da necessidade de acesso a sistemas de terceiros ou por causa da “janela” de disponibilidade de um sistema crítico.

O processo de virtualização é muito simples, não é necessário codificação e os serviços virtualizados ficam armazenados em um repositório central o qual pode ser acessado por todos os desenvolvedores e analistas de testes, que podem configurar seus cenários de teste independente da plataforma de desenvolvimento que estejam usando, como Eclipse ou .NET, pois tudo que é necessário é um navegador web.

A solução GH VIE é parte da suíte GH Tester e fornece um espectro completo de recursos de virtualização.

Quando o GH Tester começa um teste, ele pode iniciar automaticamente os serviços virtualizados que são necessários para garantir que dependências “não resolvidas” possam ser satisfeitas. O analista de teste tem a visibilidade de quais aplicações virtualizadas são utilizadas, o que permite que uma grande variedade de situações diferentes possa ser modelada, dependendo do cenário de teste.

A figura abaixo mostra a arquitetura do GH VIE:

1. Trigger – o testador envia uma mensagem para o sistema em teste o qual precisa interagir com outros sistemas.

2. A aplicação virtualizada recebe o pedido do sistema em teste e confirmar que a mensagem foi recebida conforme esperado.

3. A aplicação virtualizada decide como vai responder à mensagem (por exemplo: erro, esperando um argumento, timeout).

4. O sistema responde ao pedido original e o GH Tester pode validar se a resposta enviada como retorno está correta.

O GH VIE pode ser usado em vários cenários. O uso de aplicativos virtualizados não se restringe a testes executados através do GH Tester: analistas de testes e desenvolvedores também podem usufruir dos benefícios da virtualização já que o GH VIE pode ser utilizado em qualquer cenário de teste ou em ambiente de desenvolvimento.

Continue acompanhado a série “Green Hat: conhecendo esta aquisição da IBM que revolucionará o mercado de testes” pois serão expostos alguns casos referência e detalhes sobre as soluções.

Para mais informações, contate arodacki@br.ibm.com

Sempre que é proposto um novo projeto em qualquer empresa duas das primeiras questões que surgem são:

• Quanto vamos ganhar com isto?
• Onde está o ROI?

E neste momento se inicia o calvário de quem sabe que este projeto é bom e será útil para a empresa, pois ou o ROI é óbvio e muito simples de se obter a partir da coleta de algumas poucas informações facilmente acessíveis e ninguém teria feito as perguntas acima, ou é praticamente impossível mensurá-lo, quer por estar ligado a aspectos abstratos e/ou intangíveis, quer por estar ligado a processos complexos e não documentados da empresa, que normalmente perpassam diversas áreas pouco afeitas à divulgação de seus métodos, processos e informações. Vamos iniciar nossa análise pelo segundo caso, o dos processos complexos e não documentados.

Muito se fala em termos de BPM (Business Process Management), e algumas empresas adquirem ferramentas de BPM e seus gestores deitam tranquilamente a cabeça em seus travesseiros à noite certos de que possuem BPM, embora não tenham certeza das razões que os leva a possuí-lo. Entretanto, posso afirmar categoricamente que a quase totalidade das empresas não possui seus processos de negócio devidamente documentados, que é o alicerce do BPM. Devidamente documentados significa, em primeiro lugar, possuir o fluxo das atividades atualizado e graficamente demonstrado, onde a granularidade destas atividades atenda às necessidades da empresa e da(s) área(s) especificamente envolvida(s), isto é, de nada adianta existir uma atividade denominada “Contas a Pagar”, por exemplo, ela deve estar detalhada a ponto de se saber quais são as atividades que compõe o “Contas a Pagar”. Devidamente documentados inclui, também, uma rápida e atualizada descrição de cada uma das atividades descritas graficamente, bem como os riscos envolvidos em cada atividade e como mitiga-los, e ainda o que fazer em caso de serem observados erros na execução da atividade. Devidamente documentados significa, ainda, a apresentação do custo atualizado de execução de cada atividade, algo que, se alguma empresa possuir, é a exceção. E, a partir deste quadro, lhes pergunto: “Sem esta documentação, como é possível fazer o Gerenciamento dos Processos de Negócio da empresa?”

A falta destes processos, devidamente documentados conforme descrito acima, dificulta, quando não impede, a correta previsão do ROI dos projetos e/ou a observação de oportunidades de aumentar a eficiência destes processos (melhoria contínua), ou até a substituição dos processos atuais por outros mais adequados às necessidades de negócio da empresa (inovação).

Assim, antes de buscar as informações apenas para demonstrar o ROI de cada projeto específico, o que demanda grande esforço e tempo (que se traduzem por custo) e que muitas vezes passa pelos mesmos processos de negócio e fontes de informação inúmeras vezes, conclamo as empresas a documentar devidamente todos seus processos de negócio, e a manter esta documentação atualizada, de modo que o investimento envolvido na análise de cada projeto proposto será minimizado e o calvário descrito anteriormente para o caso dos processos complexos e não documentados simplesmente deixa de existir.

Mas alguns me perguntarão depois do exposto: “Só é possível prever o ROI baseado na redução dos custos?”.

A resposta é NÃO, podemos e devemos prever o ROI também com o incremento do faturamento de forma percentualmente maior que o incremento correspondente no custo envolvido, ou seja, o aumento da rentabilidade/lucro, o que, de qualquer forma, envolve o conhecimento e documentação devida dos processos envolvidos, caso contrário, se pode basear o ROI na previsão de incremento do faturamento, mas sem se atentar para o consequente incremento nos custos do processo, o que, finalmente resultada em redução da rentabilidade/lucro.

Mas aí se inicia a discussão do primeiro caso levantado no início deste artigo, os aspectos abstratos e/ou intangíveis, pois “Quem garante que o faturamento será incrementado?”, uma vez que o faturamento depende de uma importantíssima variável externa muitíssimo sensível e, na maior parte dos casos, fora de nosso controle: o Cliente. Pois:

• Quem garante que os Clientes comprarão a produção extra que estaremos colocando no mercado com nosso ganho de produtividade?
• Quem garante que os Clientes aceitarão pagar mais por um produto/serviço similar ao anterior em função das novidades apresentadas?
• Quem garante que os Clientes trocarão seus fornecedores atuais por sua empresa em função de sua oferta?
• Quem garante…?

Resposta: NINGUÉM GARANTE NADA!

E aí reside o risco inerente a qualquer projeto de inovação, pois a inovação se baseia em fazer algo que não foi feito ainda, portanto que não possui histórico registrado, apenas expectativa de resultado. E, sendo avesso ao risco, muitos “gestores” encerram o projeto proposto antes mesmo de inicia-lo.

Neste momento formulo nova questão: “Qual o custo de não desenvolver o projeto?”

A resposta simples, para não dizer simplória (ops, já disse…), é que “não há custo uma vez que o projeto não será desenvolvido!”.

Daí surgem algumas questões relacionadas à variável externa fora de nosso controle citada anteriormente:

• Quem garante que os Clientes se manterão fiéis ao nosso produto/serviço se nossos concorrentes apresentarem preço menor por um produto/serviço equivalente ao nosso devido ganho de produtividade que eles conseguiram?
• Quem garante que os Clientes se manterão fiéis ao nosso produto/serviço se nossos concorrentes apresentarem um produto/serviço similar ao nosso com alguns diferenciais ou melhorias?
• Quem garante que os Clientes se manterão fiéis ao nosso produto/serviço se nossos concorrentes apresentarem uma oferta similar?
• Quem garante…?

E a resposta, novamente, é: NINGUÉM GARANTE NADA!

O que resulta na questão final: “Você prefere correr o risco de investir em inovação, ou o risco de perder seus Clientes?”

Ou, simplificando: “Você está pronto a contabilizar o custo de não fazer nada?”