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

cloud-computing4 temproario

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.

 
 
 
 
 
 

Mais artigos...

  1. Tecnologia 28/01/2016
  2. Tecnologia 23 a 26/01/2016
  3. Tecnologia 19/01/2016
  4. Tecnologia 15/01/2016
  5. Tecnologia 13/01/2016
  6. Tecnologia 12/01/2016
  7. Tecnologia 09 a 11/01/2016
  8. Tecnologia 08/01/2016
  9. Tecnologia 07/01/2016
  10. Tecnologia 06/01/2016
  11. Tecnologia 05/01/2016
  12. Tecnologia 31/12/2015 a 04/01/2016
  13. Tecnologia 30/12/2015
  14. Tecnologia 29/12/2015
  15. Tecnologia 24 a 28/12/2015
  16. Tecnologia 23/12/2015
  17. Tecnologia 22/12/2015
  18. Tecnologia 19 a 21/12/2015_a
  19. Tecnologia 19 a 21/12/2015
  20. Tecnologia 18/12/2015
  21. Tecnologia 17/12/2015
  22. Tecnologia 16/12/2015
  23. Tecnologia 15/12/2015
  24. Tecnologia 12 a 14/12/2015
  25. Tecnologia 11/12/2015
  26. Tecnologia 10/12/2015
  27. Tecnologia 09/12/2015
  28. Tecnologia 08/12/2015
  29. Tecnologia 05 a 07/12/2015
  30. Tecnologia 04/12/2015
  31. Tecnologia 03/12/2015
  32. Tecnologia 02/12/2015
  33. Tecnologia 01/12/2015
  34. Tecnologia 28 a 30/11/2015
  35. Tecnologia 27/11/2015
  36. Tecnologia 26/11/2015
  37. Tecnologia 25/11/2015
  38. Tecnologia 24/11/2015
  39. Tecnologia 20 a 23/11/2015
  40. Tecnologia 19/11/2015
  41. Tecnologia 18/11/2015
  42. Tecnologia 17/11/2015
  43. Tecnologia 14 a 16/11/2015
  44. Tecnologia 13/11/2015
  45. Tecnologia 12/11/2015
  46. Tecnologia 11/11/2015
  47. Tecnologia 10/11/2015
  48. Tecnologia 07 a 09/11/2015
  49. Tecnologia 06/11/2015
  50. Tecnologia 05/11/2015
  51. Tecnologia 04/11/2015
  52. Tecnologia 30/10 a 03/11/2015
  53. Tecnologia 29/10/2015
  54. Tecnologia 28/10/2015
  55. Tecnologia 27/10/2015
  56. Tecnologia 24 a 26/10/2015
  57. Tecnologia 23/10/2015
  58. Tecnologia 22/10/2015
  59. Tecnologia 21/10/2015
  60. Tecnologia 20/10/2015
  61. Tecnologia 17 a 19/10/2015
  62. Tecnologia 16/10/2015
  63. Tecnologia 15/10/2015
  64. Tecnologia 14/10/2015
  65. Tecnologia 10 a 13/10/2015
  66. Tecnologia 09/10/2015
  67. Tecnologia 08/10/2015
  68. Tecnologia 07/10/2015
  69. Tecnologia 06/10/2015
  70. Tecnologia 03 a 05/10/2015
  71. A sua casa ainda será seu escritório
  72. A sua casa ainda será seu escritório (2)
  73. Tecnologia 01/10/2015
  74. Tecnologia 30/09/2015
  75. Tecnologia 29/09/2015
  76. Tecnologia 26 a 28/09/2015
  77. Tecnologia 25/09/2015
  78. Tecnologia 24/09/2015
  79. Tecnologia 23/09/2015
  80. Tecnologia 22/09/2015
  81. Tecnologia 19 a 21/09/2015
  82. Tecnologia 18/09/2015
  83. Tecnologia 17/09/2015
  84. Tecnologia 16/09/2015
  85. Tecnologia 15/09/2015
  86. Tecnologia 12 a 14/09/2015
  87. Tecnologia 11/09/2015
  88. Tecnologia 10/09/2015
  89. Tecnologia 09/09/2015
  90. Tecnologia 05 a 08/09/2015
  91. Tecnologia 04/09/2015
  92. Tecnologia 03/09/2015
  93. Tecnologia 02/09/2015
  94. Tecnologia 01/09/2015
  95. Tecnologia 29 a 31/08/2015
  96. Tecnologia 28/08/2015
  97. Tecnologia 27/08/2015
  98. Tecnologia 26/08/2015
  99. Tecnologia 25/08/2015
  100. Tecnologia 22 a 24/08/2015
Outras Matérias sobre Tecnologia

 

Mais Lidas