Tecnologia 29/01/2016

Cloud Computing renova as estratégias de conectividade das empresas

A computação em nuvem não só ocupará uma posição importante nas empresas, mas se transformará em opção imprescindível para os departamentos de TI, uma vez que será a plataforma essencial para acessar serviços e soluções de tecnologia que permitam às organizações suportar o imenso volume de dados com o qual convivem e continuarão a conviver diariamente

David Iacobucci (*)

O Cloud Computing está entre as soluções mais inovadoras de TI, não apenas para os data centers, mas também na própria indústria da tecnologia. Hoje a nuvem é sinônimo, para as empresas, de maior agilidade, menores custos e da possibilidade de acessar soluções e serviços avançados em software, infraestrutura, processamento e armazenamento de dados.

A IDC, além de considerar o Cloud Computing como uma das principais tendências no universo da TI, prevê que IaaS (Infrastructure as a Service), PaaS (Platform as a Service) e SaaS (Software as a Service) concentrarão o crescimento dos serviços com base na nuvem, os quais, em conjunto, totalizarão cerca de 118 bilhões de dólares em gastos globais, sendo IaaS o serviço cloud que terá o maior crescimento no próximo ano, com 36% de expansão.

Isso porque o Cloud Computing é a plataforma facilitadora da inovação por excelência, a partir da qual a própria indústria de TI vem tomando forma com tecnologias baseadas na virtualização, campo em que se destaca uma série de novas arquiteturas de soluções, as quais têm sido englobadas dentro da tendência conhecida como SDE (Software Defined Everything). As soluções SDE são as tecnologias que se baseiam em uma arquitetura que separa o hardware do software, ou seja, que colocam a inteligência nesta camada, o que faz com que as organizações não fiquem amarradas a determinados provedores para que a infraestrutura de TI suporte as reais exigências do negócio.

Em nível de rede, a SDE tem a contrapartida em duas tendências de crescente importância para data centers, provedores de serviços e empresas: Software Defined Networks (SDN) e Network Functions Virtualization (NFV). A primeira delas aproveita a inteligência do software para centralizar as funções das diferentes camadas da rede, enquanto que a segunda se refere a uma arquitetura que usa funções de máquinas virtuais sobre a infraestrutura de rede, ou sobre a infraestrutura de computação em nuvem.

Dados e mais dados
O auge do Cloud Computing se relaciona com outras duas tendências predominantes de TI: o Big Data e a Internet das Coisas (IoT) que, em conjunto, são conhecidos como a “Terceira Plataforma”. O elemento comum destas tendências é que nos falam de um volume gigantesco de dados digitais que necessariamente transitará na nuvem. Para isso, as empresas terão que adaptar a arquitetura das redes e data centers para fornecer a capacidade necessária e flexibilidade exigidas para o novo cenário.

Por outro lado, esse conjunto de fatores irá demandar, cada vez mais, dos provedores de serviços em nuvem. No caso da IoT, a IDC estima que mais de 90% destes dados serão alojados em plataformas deste tipo nos próximos cinco anos. Isso porque a nuvem reduz a complexidade associada à fusão de dados provenientes de fontes diversas e dispersas.

A necessidade cada vez maior de redes
O volume de dados gerados pela IoT será tanto que obrigará, em curto prazo, as empresas a repensar até suas estratégias de conectividade. Em três anos, como afirma a IDC, a metade das redes terá algum tipo de problema pelo fluxo de dados gerado por dispositivos da IoT. Estima-se, inclusive, que 10% das redes poderão ficar saturadas neste período.

Quando uma organização decide levar seus dados e aplicações para a nuvem, deve definir uma arquitetura em nuvem apta para suas necessidades – privada, pública ou híbrida – e, em seguida, selecionar o provedor de serviços que garanta a maior flexibilidade possível.

A partir daí, é preciso se preocupar para que a conectividade tenha o melhor desempenho, onde os níveis de uptime e segurança sejam garantidos por contrato, considerando uma largura de banda dinâmica, que dê à rede escalabilidade máxima.

Os serviços de conectividade no ambiente de negócios atual se tornarão cada vez mais críticos. Com o Big Data e a IoT como catalizadores, o desempenho das redes será chave para o negócio, pois se processará um volume de dados cada vez maior, muitos dos quais serão provenientes de fontes que se encontram em outras cidades ou países.

(*) É Gerente Comercial da Level 3 Communications, Chile.

Gerente de Projeto: como esse profissional se tornou o capanga do mafioso

Marcelo Lombardo (*)

Há algum tempo eu comecei uma saga de desconstrução do castelo de cartas que é o mundo dos ERPs tradicionais – aqueles velhos conhecidos, grandes, caros e que nunca funcionam direito

Um negócio que se arrasta às custas da falta de opção do cliente somado a um conformismo trágico. Um negócio onde vender carne de terceira ao preço de filet mignon se tornou o esporte predileto dos executivos de software da velha guarda, e onde um projeto que deu “apenas” 30% errado é encarado como uma grande vitória pelos magníficos gestores de TI.
Sei que toda a generalização é burra por natureza e que existem exceções para tudo, mas não vou perder tempo sendo politicamente correto a cada frase. Então, tenha certeza de que eu sei que o que escrevo não se aplica a todos (só a quase todos) os Gerentes de Projeto de ERP. A gestão de projetos formal, com planejamento Waterfall, MS Project e tudo mais, parece ser um negócio que funciona cada vez menos – e a presença de um PMO (do inglês Project Manager Officer) certificado (podendo até ser daqueles com um cronograma numa mão e um bastão de baseball na outra) raramente modifica o resultado, seja para o bem ou para o mal.
Para provar o meu ponto, basta olhar os resultados do Chaos Report: pela estatística global publicada, mais de 70% dos projetos falham, e na última década esse número gigantesco de insucesso praticamente não se modificou, variando poucos pontos para lá ou para cá, ano a ano. Por outro lado, no mesmo tempo, o PMI – Project Management Institute, órgão que certifica os PMOs, ou gerentes de projeto, despejou no mercado incontáveis gerentes de projeto certificados, e a metodologia PMBok impactou milhões de profissionais em todo o mundo. Fomos inundados por uma cultura de gestão de projetos que na prática falhou miseravelmente em reverter qualquer estatística de insucesso.
Olhando mais a fundo é até pior: aproximadamente 40% dos projetos estudados no Chaos Report dos últimos anos são projetos ágeis, que não seguem nem de longe a teoria maçônica do PMI, mas que tiveram cerca de 50% de taxa de sucesso – salvando assim o índice final da estatística. Em outras palavras, se levássemos em conta apenas os projetos tradicionais com toda a carga de metodologia e com os caríssimos profissionais de gerenciamento de projeto, o índice de fracasso seria algo bem próximo a 100%.
Mas por que isso importa no nosso caso? Porque metodologias ágeis são normalmente utilizadas apenas em projetos de desenvolvimento de software, e praticamente todos os projetos de implantação de ERP seguem até hoje o tradicional modelo Waterfall/PMBok.
Ok, então concordamos que a metodologia utilizada mostra sinais claros de fadiga. Mas atribuir toda a culpa a uma metodologia é o mesmo que punir o mensageiro por uma mensagem ruim, ou ainda condenar o carro pelo acidente. A pergunta deveria ser: onde está o nosso motorista bêbado? Bem aqui, conhecido como GP (Gerente de Projeto).
Tudo começa com a formação do GP. Ele aprendeu – e acredita nisso – que não é preciso entender nada do assunto do qual o projeto trata. Ele foi convencido por um exaustivo treinamento (que mais parece uma lavagem cerebral), que aplicando as práticas do PMBok ganha-se o poder de gerenciar qualquer tipo de projeto, de software a foguete espacial, mesmo sem entender nada sobre nenhuma dessas coisas.
Consequentemente temos um GP de um projeto de ERP que não conhece ERP ou gestão empresarial, e que usualmente odeia falar de imposto, de nota fiscal e de contabilidade. Esse motorista bêbado nos causa previsivelmente dois acidentes com vítimas fatais e ferimentos graves:
1 – Equipe desmotivada: como o GP não tem paixão alguma pelo assunto, ele não “saca” o propósito do projeto. Então ele assume o papel arcaico de um chefe que apenas segue o manual e cobra tarefas e prazos dos seus “recursos” (pois é, depois de décadas de dedicação obstinada, aquele consultor heroico, que carrega o piano, ganha o “maravilhoso” nome de recurso, que soa no ouvido como “ferramenta”, “coisa”…). Que esteja claro: não existe líder que não é apaixonado pelo assunto. Se não há paixão, o GP é no máximo um chefe, e chefe jamais, em hipótese alguma, extrai o melhor que uma equipe poderia dar.
2 – Tudo sai errado ou diferente do planejado: o GP que não conhece profundamente ERP se apoia em especialistas para tomar as suas decisões, mas esses especialistas normalmente são também “recursos” (já falei que odeio esse nome?) e possuem interesses pessoais conflitantes com os objetivos do projeto. O GP embarca hora na conversa de um, hora na conversa de outro, e quando descobre o caminho certo já é tarde. E quem paga a conta do tempo gasto com as cabeçadas? Isso é o que vem a seguir.
Independente do GP ser alvo de constante manipulação pela sua falta de conhecimento específico, de longe o problema mais cruel que ele tem que digerir é esse: assim como qualquer motorista sabe que se beber vai provavelmente causar acidentes, o GP sabe que sua principal missão nunca foi a de entregar o projeto. A missão real sempre foi, em português claro, “disfarçar e faturar”.
Para entender o “disfarçar e faturar”, “Mister M” vai precisar contar o segredo de três mágicas:
– A mágica do “quer rir, então me faz rir”: existem dois tipos de horas aplicadas a um projeto: as pagas pelo cliente e as glosadas, que o cliente não aceita pagar. Em praticamente todas as velhas empresas de ERP tradicional, o rendimento variável ou bônus do GP é calculado em razão do percentual de horas cobradas de seus projetos. E se o projeto foi entregue e o cliente ficou satisfeito? Isso, se acontecer algum dia, vale um troféu e um aplauso, mas grana que é bom depende dele conseguir arrancar mais dinheiro do cliente. E como o GP faz isso? Com as duas outras mágicas abaixo:
– A mágica da formalização: a burocracia é sem dúvida o paraíso dos incompetentes, pois fica fácil ocultar erros em meio a milhares de documentos e, principalmente, transferir a culpa para quem não se documentou formalmente – geralmente o cliente. Portanto, o overhead de custo de gestão é, na prática, usado pelo GP nas atividades de “cover your ass”, ou seja, o cliente paga o custo do GP fundamentalmente para o fornecedor provar que a culpa de qualquer desvio é sempre do próprio cliente.
– A mágica do contrato: todo o contrato de implantação de ERP (desses velhos, tradicionais, grandes e complicados) possui um parágrafo em letras pequenas mais ou menos assim: “os valores e quantidades de horas desse documento são estimados com base nas informações prestadas pelo cliente até o presente momento”, ou seja, na hora da venda o cliente pergunta: o sistema faz isso e aquilo de tal jeito? O vendedor responde: sim, claro!
Como ninguém gravou, quando o problema vem à tona basta o GP dizer: “bem, eu não estava lá, existe alguma evidência documentada no contrato? “ – o cliente responde gritando: “não, mas chama o cara que me vendeu aqui!”. Então basta o GP dar a resposta padrão: “putz, infelizmente ele não está mais na empresa (ou está de férias / licença paternidade / morto / internado / desaparecido)”.
Concluindo, como o cliente já gastou um caminhão de dinheiro, provavelmente não vai por tudo a perder – e o que era dele por direito vai ser entregue com mais um pacote de horas adicionais, lindamente cobradas pelo fornecedor. O GP, que no começo da profissão costumava a ficar horrorizado, depois de meia dúzia de projetos acaba achando isso normal e até mesmo correto, pulando de cabeça nesse jogo sujo e repartindo o escalpo arrancado do cliente.
Moral da história: projeto bom é projeto que deu errado, ao menos na visão do cliente, pois é isso que dá muito mais dinheiro para o fornecedor. E o GP assume o papel de principal orquestrador desse jogo sujo, seguindo as “boas práticas” descritas em “metodologias internacionalmente reconhecidas”. Se alguém já viu um ERP desses famosos e tradicionais implantado no prazo, na qualidade e no custo previstos, me avise.

(*) É idealizador do produto Omie e CEO da Omiexperience.