Why are Cloud services so important in digital strategy?

Voltando ao contexto da transformação digital, onde os modelos de negócio (business agility, inovação, etc.) e tecnologias são utilizados para alavancar o desempenho da empresa e a experiência do cliente, um enabler imprescindível nessa jornada (a ser abordado nesse post) é Cloud e por isso, tem sido a “fundação” que habilita a transformação do negócio e o foco estratégico (cloud-first) de muitas organização -avançar o uso de Cloud Services.

A estratégia cloud-first deve ser compreendida pela organização toda (não somente TI) e assim, buscar a obtenção dos benefícios de negócio, tais como redução do custo operacional, time to market e melhora na escalabilidade e segurança das aplicações. O objetivo das empresas pode variar, onde algumas buscam a migração completa de seus data centers, já outras apenas alguns subsets de aplicações para Cloud pública. Por isso, cloud-first não significa cloud-always.

Uma boa vantagem em utilizar Cloud Services é o uso sob demanda (otimização de recursos, sem grandes investimentos para começar a usar e sem desperdícios), escalabilidade e segurança, pois os recursos são gerenciados pelo provedor.  O desenho abaixo representa os principais Cloud Services que a AWS oferece:

aws-services

Inovação – Build, Buy e Borrow

Em geral, continuar com o recursos que você já domina, ampliando o uso da tecnologia existente é uma das opções consideradas. Evite a armadilha do resume-driven development, deixando as pessoas escolherem as tecnologias boas para o seu próprio currículo, e não para o problema.

Caso não seja possível ampliar o uso da tecnologia existente, então utilize os serviços do tipo pay-as-you-go. Esses serviços gerenciados (ou SaaS) reduzem a carga de trabalho em configuração e gestão de itens de infraestrutura, dedicando mais tempo a inovação e publicação de novas releases. A decisão build para novas tecnologias in-house pode gerar desperdício de custo, tempo e oportunidade. Avalie bem, pois o produto criado, em geral, é o diferencial competitivo, e não a tecnologia construída.

buy-build-borrow

Alguns elementos críticos para a inovação: cultura e pessoas, processos e organização, produtos e tecnologia. A estratégia Build, Buy or Borrow pode ser utilizada nesse contexto, e resumida da seguinte forma:

  • Build: quando já possui a expertise na empresa, core business, propriedade intelectual / patente ou pioneira no segmento.
  • Buy: quando é atividade core ao negócio, tem relação estratégia de mercado ou tempo crítico para lançamento.
  • Borrow: reduzir o risco, aumentar o time to market e customização em mercados específicos.

buy-build-borrow-matrix

Ao decidir a migração para Cloud Services, alguns benefícios comumente obtidos são:

  • Redução de riscos: capacidade de adaptar-se rapidamente as mudanças (por permitir testar com frequência e efetuar correções rápidas).
  • Escalabilidade: redimensionar seus recursos conforme necessário.
  • Confiabilidade: capacidade do sistema se recuperar de falhas de infraestrutura ou serviço ou adquirir recursos para atender à demanda e mitigar interrupções.
  • Segurança dos dados: propriedade total sobre seus dados.

cloud-benefits

 

Estratégias de migração Cloud

Uma das estratégias mais recomendadas para migração de aplicações em Cloud é o 6R’s da AWS, baseada no 5R’s de Gartner. Essa discussão, em geral, ocorre na segunda fase (Portfolio Discovery and Planning) do processo de migração, onde são determinados os ambientes, interdependências e o que será priorizado na migração.

A complexidade de migração varia, dependendo muito da arquitetura e do licenciamento existente. Enquanto uma arquitetura orientada a serviços possui baixa complexidade, um mainframe monolítico certamente trará uma alta complexidade. A figura abaixo resume os 6R’s:

6Rs-migration
Figura: AWS

  • Rehosting (“lift-and-shift”): não há mudanças na arquitetura. É a reimplantação do aplicativo em um ambiente de hardware diferente (em cloud). Isso altera a configuração da infraestrutura do aplicativo.
  • Replatforming: a arquitetura ainda não sofre alterações, mas há otimizações em Cloud para obter benefícios. Por exemplo, a migração do banco de dados para uma plataforma de banco de dados como serviço, como Amazon RDS.
  • Repurchasing : mudança para um produto diferente (geralmente em SaaS), tal como um CRM para SFDC.
  • Refactoring / Re-architecting: alterações nas práticas de desenvolvimento e arquitetura, usando recursos nativos em Cloud, que provê a infraestrutura para a execução do seu aplicativo.
  • Retire: descobrir o que não é mais utilizado em seu ambiente e que pode ser desativado, e assim, focar a atenção da equipe em aplicações que trazem benefícios ao negócio.
  • Revisit: não fazer nada (por enquanto). Isso acontece em aplicativos que foram atualizados recentemente ou que não fazem sentido migrar por enquanto.

 

Estágios de adoção

A AWS possui um conjunto de estágios que descrevem a postura associada as organizações na adoção Cloud. São quatro estágios:

  • Stage 1 – Project: inicia com alguns projetos para entender como a nuvem vai atender as necessidades do negócio. Utiliza experimentação em projetos early cloud, POCs, análise TCO/ROI e preparação a riscos/segurança.
  • Stage 2 – Foundation: com a percepção dos benefícios iniciais, a empresa pode escalar a adoção em toda a organização. A recomendação é criar um CCoE (Cloud Center of Excellence), responsável pelo treinamento/capacitação dos colaboradores, gestão de custos e ativos, estratégia de arquitetura híbrida, arquitetura de referência, entre outros.
  • Stage 3 – Migration: define-se então a estratégia de migração, geralmente iniciada com o processo de descoberta de aplicativos e um business case, seguido por migrações individuais (em várias estratégias de migração diferentes).
  • Stage 4 – Optimization: muitas empresas acham mais fácil otimizar seus aplicativos depois de migrá-los para a nuvem. Nesse estágio há infraestrutura automatizada e gestão própria do stack de soluções.

Targeted Business Outcomes - AWS Prescriptive GuidanceFigura: AWS

Processo de migração

A preparação e o planejamento para migração envolve work streams que atuam nas áreas de Landing Zone, Modelo Operacional, Governança, Security & Compliance, Pessoas (skills), Application Portfolio, Processo de Migração e Business Case.

Com o uso de metodologia, processos, ferramentas e recursos, define-se um objetivo de migração, geralmente avaliado em 3 à 4 meses de trabalho (estruturado em Sprints). Durante essa fase, as equipes realizam migrações iniciais para criar experiência e confiança através de quick wins. Os principais deliverables de preparação a migração são:

  • Landing Zones: configuração de ambiente seguro de várias contas.
  • CCoE (Cloud Center of Excellence) / Cloud Operations Model: treinamento e capacitação adequada aos times. Determinar as práticas operacionais para maximizar os benefícios de negócio.
  • Security and Compliance: resolução de gaps e implementação de práticas de segurança e compliance.
  • Portfolio Discovery and Migration: sequenciamento e planejamento das migrações.

 

Conclusão

Como vimos acima, a utilização de Cloud Services é um enabler muito estratégico a ser considerado no seu plano de transformação digital ou estratégia digital. Há diversas estratégias de migração, pois sabemos da dificuldade em manter os serviços core (nem sempre criados com as melhores práticas) em funcionamento e o custo que essa decisão pode acarretar na criação de novos produtos para a empresa.

A escolha de um bom parceiro é essencial para apoiar a jornada de adoção Cloud. Essa jornada exige skills especializados, tanto no conhecimento do negócio e aplicações da própria empresa, quanto em tecnologias Cloud. Além disso, uma boa governança é fundamental para habilitar o plano de migração e readiness e garantir em conjunto com a equipe que os objetivos serão atingidos.

Por fim, verifique os benefícios e aplicabilidade real em seu ambiente. As análises financeiras, tal como o TCO (Total cost of ownership), também são importantes para apoiar suas decisões. Quais são os custos de oportunidade e operacionais em manter aplicações ou serviços no ambiente atual? É possível ser inovador nesse cenário? Já avaliou alguma PoC? As features que mais geram receita para o negócio estão bem dimensionadas (custo x retorno)? Há insights com o uso de dados coletados? E o monitoramento e segurança das aplicações?

VSM (Value Stream Mapping) – do current ao future state

Após a introdução do Value Streams Mapping e seus benefícios, veremos aqui as etapas de criação, sequenciando as atividades que a empresa realiza para atender as demandas do cliente. O fluxo de valor percorre todas as áreas da organização, rompendo silos (entre áreas), em busca de oportunidades de melhoria e redução de desperdícios.

O mapeamento, em geral, envolve colaboradores experientes (e de áreas chaves) por ser um processo complexo e multifuncional. O cliente é a principal razão de acontecer o VSM. Por isso, verifique os benefícios e melhorias que podem ser feitas para os clientes. Quais os problemas que estamos resolvendo? Estamos melhorando a nossa capacidade de entregar valor e remover desperdícios?

O VSM é mais aplicável a processos repetíveis, especialmente quando houver handoffs (tempo de espera) entre os times, que é onde a maioria das demoras e desperdícios se encontram. O mapeamento possui três principais etapas: current state (estado atual; identificar os processos core business), future state (onde devemos estar em alguns dias com os recursos atuais) e next future state (visão estratégica “ideal” de onde poderia estar com recursos e automações ainda não disponíveis).

Um exemplo clássico, representado no desenho abaixo, demonstra todas as etapas de um processo para concluir a entrega do cliente. O value added time é tempo gasto em atividades que agregam valor ao produto. E o Lead Time é a soma de todos os tempos, do início ao fim do processo (inclui os tempos de espera entre as etapas). Percebe-se então a presença de gargalos no fluxo, devido a somente 15 minutos em atividades que agregam valor ao produto, e 68 dias para concluir o processo.VSM

Entre as principais métricas consideradas no VSM que ajudam a compreender os fluxos de entrega ao cliente estão: 

  • Lead Time: tempo decorrido entre o pedido e a entrega, medindo seu processo de produção da perspectiva do cliente.
  • Cycle Time: considera entre o tempo de inicio do trabalho e termina quando está pronto para entrega.
  • Takt Time: é a taxa de demanda do mercado (o ritmo do mercado), ou seja, o que precisa ser cumprido para atender à demanda do cliente.

lead-time-cycle-time

Current state
O desenho abaixo é um exemplo real de como era o ciclo de desenvolvimento em uma empresa, onde o Lead Time era de 19 horas – tempo médio entre o recebimento de uma demanda (via abertura de ticket) e o deploy em produção. Por questões de compliance, a empresa precisava de algumas aprovações e documentos durante o processo.

ALM-analise

Foram identificados alguns gargalos nesse fluxo:

  • Tempo de espera alto para validação do usuário e aprovação da mudança (change management). Causa: documentos preenchidos manualmente durante o processo geravam um checklist demorado.
  • Deploy manual demandava tempo de preenchimento do documento de publicação e do publicador em seguir as etapas.
  • A fase inicial (planning design) exigia a preparação de documentos que seriam utilizados no decorrer das etapas.


Future state

Ao reunir os colaboradores para discutir o future state do fluxo de valor, lembre-se de seguir alguns princípios Lean, tais como a criação do Flow (fluxo), processos vinculados aos clientes, eliminar os desperdícios, evitar super produção (seguir o takt time) e lotes grandes.

Existem diversas ferramentas que ajudam a mapear o fluxo de valor. O desenho abaixo é somente para ilustrar o fluxo to be com as principais mudanças (sem o uso de uma ferramenta específica para VSM), automatizando o deploy e simplificando o registro das informações das RDMs. Essas ações reduziram significativamente os tempos de espera entre trabalhos e o tempo que era gasto com preenchimento manual de documentos (documento de teste técnico, homologação e publicação).

change-management-process

VSM Symbols
Para conhecer melhor os símbolos que podem ser utilizados no VSM, recomendo assistir esse vídeo abaixo:


Playbook
Após ver todos esses conceitos importantes no VSM, como você planeja reunir as pessoas e conseguir mapear os fluxos de valor da sua organização? Um Workshop de VSM (2-3 dias) seria muito apropriado para isso, desde que considere alguns pontos:

  • Identificar um facilitador com experiência em VSM.
  • Identificar e priorizar Value Streams que tenham impacto no cliente e na estratégia organizacional. Escolha a que mais atenda a necessidade da empresa.
  • Envolver um Sponsor (ou champions) comprometido com o future state.
  • Empoderamento do time para realização das mudanças.
  • Na dinâmica, considerar o uso de Charter para discutir escopo, declaração do problema, objetivos e métricas.
  • Considerar a visão ideal future state (de longo prazo) com tecnologias e automações que ainda não estão disponíveis, mas que a visão estratégica deseja ter.
  • Levantar oportunidades e atribuir owners para as implementações.
  • Governança para acompanhamento das ações e planejamento de melhorias.

Também acordar uma reunião com o Sponsor e stakeholders para revisar os objetivos do Workshop, treinamentos (caso seja necessário), atividades Pre Workshop, facilities e a logística dos colaboradores.

VSM-agenda


Outcomes
Os resultados esperados com o VSM incluem melhorias nos tempos de entrega e percepção do cliente (lead time e cycle time), da qualidade e experiência de uso, além da redução de desperdícios no processo. Após a execução da agenda citada acima, os outcomes gerados são:

  • Mapa do fluxo current state
  • Mapa do fluxo future state (e ideal future state)
  • Métricas de performance
  • Plano de transformação para atingir o future state

VSM-outcomes