Anti-padrões organizacionais na cloud
Os clientes experimentam frequentemente anti-padrões de adoção da cloud na estrutura organizacional. Muitos fatores podem causar estes problemas:
- Conjuntos de ferramentas
- Parceiros
- Engenheiros
- Departamentos de TI desalinhados
É importante compreender a função destes fatores num cenário de adoção bem-sucedida da cloud.
Antipasta: Tratar as TI como um centro de custos
Muitas empresas tratam os departamentos de TI como centros de custos. Esta abordagem pode levar à percepção de que as TI não acrescentam valor à empresa. Quando os colaboradores vêem as TI como um fornecedor e não como um ativador, podem ficar desencorajados. Também é difícil para a empresa atrair o talento certo. Resultado da motivação reduzida e dos tempos de ciclo de vida longos. A qualidade do trabalho das TI pode sofrer e os silos e os feudos podem desenvolver-se.
Exemplo: Tratar as TI como um centro de custos
Uma empresa gere o seu departamento de TI como um centro de custos responsável pelo diretor financeiro (CFO). O conselho de administração vê as TI como um fornecedor de serviços lento que é um dos maiores impulsionadores de custos da empresa. O conselho de administração não percebe que a unidade de negócio de mobilidade está a consumir a maioria dos recursos que o departamento de TI encomendou. As TI compram um datacenter para todas as unidades de negócio utilizarem, mas a unidade de negócio de mobilidade obtém este recurso de grandes dimensões. O quadro não vê as TI como um ativador ou um parceiro.
Resultado preferencial: Ver TI como um ativador
Em vez de gerir o seu departamento de TI como centro de custos, considere uma destas abordagens:
- Estorno: as unidades de negócio tratam os custos de TI como despesas operacionais nos seus orçamentos.
- Showback ou awareness-back: as TI funcionam como um agente. Nos relatórios de volta à empresa, as TI atribuem quaisquer custos diretos a unidades de negócio relevantes.
Utilize a cloud como uma ferramenta para aumentar os custos e a transparência empresarial. Por exemplo, implemente uma disciplina do Cost Management para aumentar a transparência dos custos. Em seguida, estará mais ciente do custo de diferentes unidades de negócio. Verá o departamento de TI como um ativador para essas unidades.
Para melhorar a transparência, concentre-se na visibilidade, responsabilidade e otimização ao mudar para a cloud. Para obter mais informações, veja Criar uma organização consciente dos custos.
Antipasta: Investir em novas tecnologias sem envolver o negócio
Os departamentos de TI investem frequentemente recursos humanos e financeiros significativos na criação e implementação de plataformas e conjuntos de ferramentas robustos. No entanto, por vezes, as TI não consideram as unidades de negócio e as suas necessidades durante as fases de design e desenvolvimento. Esta omissão leva a novas plataformas com relevância mínima para unidades empresariais. Os colaboradores hesitam em aceitar a nova tecnologia. A adoção fraca ou lenta pode resultar. A frustração também aumenta nas TI quando as unidades de negócio não utilizam as suas plataformas.
Exemplo: Configurar uma plataforma sem envolver unidades de negócio
O departamento de TI de uma empresa de análise de dados configura e personaliza uma plataforma do Azure sem envolver unidades empresariais. Ao utilizar a plataforma, os programadores de unidades de negócio:
- Tenha em atenção que não têm as permissões necessárias para a implementação.
- Só é possível utilizar um número restrito de serviços.
- Emita pedidos de suporte, o que aumenta os ciclos de aprovação.
- Comece a duvidar da nova plataforma.
No final, alguns programadores compram uma subscrição do Azure sozinhos para evitar o incómodo das regras e regulamentos de TI. É apresentada a opção TI sombra. Uma vez que a empresa tem pouco controlo sobre a ti sombra, surgem riscos de segurança elevados.
Resultado preferencial: Envolver unidades empresariais na tomada de decisões
Evite criar silos de TI ao implementar uma plataforma de cloud pronta para empresas. Envolva programadores e decisores técnicos (TDMs) de unidades de negócio em processos de conceção e desenvolvimento. Para melhorar a adoção da plataforma, ouça a entrada da unidade de negócio.
Veja Começar com Cloud Adoption Framework zonas de destino à escala empresarial para melhores práticas e princípios de conceção do Azure que aumentam a velocidade de adoção e são adaptados aos programadores. Encontrar o equilíbrio certo entre conformidade e flexibilidade. Por exemplo, encontre formas de satisfazer as políticas de governação e segurança, mantendo os ambientes de desenvolvimento ágeis.
Antipasta: Funções empresariais principais de origem
Os parceiros de consultoria e os fornecedores de serviços geridos (MSPs) podem desempenhar um papel importante num percurso na cloud. No entanto, as empresas devem ter em conta que o trabalho dos parceiros e dos MSPs não fornece o maior valor no seu negócio. As empresas que subcontratam responsabilidades a MSPs ou consultores de cloud não devem ficar dependentes destes fornecedores.
Exemplo: Adoção e migração da cloud de origem
Um instituto de investigação tem um projeto de migração para a cloud crítico para o tempo. Para encurtar o percurso de adoção da cloud, contrata um MSP para criar a base do Azure e implementar a migração. Em vez de aprender sobre a fase de adoção da cloud e criar competências, o instituto opta por entregar toda a responsabilidade do Azure ao MSP. Uma vez que o instituto não tem conhecimentos da cloud ou do Azure, o MSP assume a liderança em todas as decisões, tornando o instituto dependente do MSP.
Resultado preferencial: Tornar áreas de design críticas da responsabilidade da empresa
Tenha em mente o outsourcing como uma boa estratégia de redução de custos. Contudo, tome decisões na sua empresa quando envolvem estas áreas de design críticas:
- Governação
- Risco
- Conformidade
- Identidade
Mantenha a responsabilidade dentro da empresa por estas e outras áreas que são fundamentais para o seu património de segurança. Utilize parceiros externos para acelerar o percurso de adoção. No entanto, para evitar tornar-se dependente de fornecedores, não subcontrata tudo.
Antipasta: Contratar decisores técnicos em vez de desenvolver engenheiros da cloud
As empresas dão importância à procura do pessoal certo. Como resultado, muitas vezes contratam ou acumulam TDMs durante as fases iniciais de adoção da cloud. Os percursos com êxito na cloud dependem de TDMs. Mas, mais importante ainda, as adoções da cloud precisam de engenheiros com mentalidades práticas e competências técnicas profundas.
Exemplo: Contratar apenas TDMs
Um instituto de investigação contrata vários TDMs para liderar o seu percurso na cloud. Após o fim da fase inicial de conceito de alto nível, a fase de implementação é iniciada. Em seguida, o instituto percebe que as implementações na cloud se comportam de forma diferente das implementações no local. Precisa de um esforço adicional de engenharia na cloud para implementar corretamente conceitos de infraestrutura como código (IaC) e governação orientada por políticas.
Resultado preferencial: Utilizar engenheiros da cloud para a fase de implementação
Lembre-se de que os engenheiros são essenciais para implementar corretamente a automatização da cloud e os conceitos de zona de destino. As responsabilidades e as tarefas podem mudar significativamente quando adota modelos de serviço. Ao transferir as responsabilidades para um fornecedor de cloud, pode entrar na produção mais rapidamente. Também pode utilizar TDMs para a tomada de decisões, mas utilizar engenheiros de cloud capazes para tarefas que requerem conhecimentos de engenharia profundos. Em seguida, irá perceber as vantagens que a cloud proporciona.