Graças à transformação digital, TI é incorporada em todos os processos de negócios. É hora de ouvir o DevOps e repensar a divisão entre TI e negócios

Para ter sucesso na era digital, os projetos de TI devem ser redefinidos para fornecer mudanças corporativas, em vez de apenas entregar tecnologia da informação. Mas por trás disso há uma transformação mais fundamental: as operações de TI devem ser completamente incorporadas nos processos de negócios.

Em muitas organizações, a TI é executada como se fosse uma empresa separada – um provedor de serviços, o que acaba gerando disfunção nas companhias. Parte disso ocorre porque a metáfora de TI como empresa levou a uma prática estranha: acordos de nível de serviço (SLAs) entre as operações de TI e seus clientes internos.

Em termos reais de terceirização de TI, um SLA é uma métrica de duas partes. A primeira parte é o padrão mínimo aceitável de serviço. O segundo enumera com que frequência o contratante deve atingir esse nível de serviço.

Definir a primeira parte da métrica geralmente é trivial. A segunda parte, no entanto, é mais interessante. Por exemplo, um SLA pode definir o padrão máximo aceitável para uma interrupção de uma hora ou menos antes da restauração do serviço. A segunda metade da métrica pode especificar que o terceirizado deve atingir esse nível de serviço para 99% de todas as interrupções.

Se o contratante não cumprir seus SLAs, o contrato especificará soluções, que também são uma questão de negociação. Se a TI interna deve agir como um negócio independente, o que poderia ser mais lógico do que negociar SLAs com seus clientes internos?

Como se vê, a resposta é: muitas alternativas são mais lógicas.

O desafio da inovação

SLAs internos nunca foram uma boa ideia por vários motivos. Primeiro, eles reforçam o modelo errado de relacionamento de TI / negócios. Segundo, porque não criam um clima de confiança entre as equipes. E terceiro, pois, na maioria dos casos, a TI acaba medindo os níveis de serviço, mas não possui métricas de inovação.

As operações de TI bem executadas equilibram constantemente confiabilidade e inovação. Mas a inovação envolve riscos. Como os SLAs olham para trás, eles apenas relatam as consequências negativas da inovação, não seus benefícios.

Pense no início dos discos rígidos de estado sólido. Sua confiabilidade a curto prazo e durabilidade a longo prazo não foram comprovadas para os primeiros usuários. No entanto, eles pagaram generosamente pelas organizações que as experimentaram, oferecendo uma vantagem de desempenho em análise e big data.

Permanecer na vanguarda exige alguns riscos e perspectivas que os SLAs, por natureza, desencorajam.

O caso contra os SLAs

A TI normalmente assume dois tipos de responsabilidade: serviços técnicos e serviços de suporte. Os SLAs para serviços técnicos estão relacionados a questões como disponibilidade e desempenho do sistema. O problema? As arquiteturas de alta disponibilidade eram uma escolha, mas não são mais.

A TI deve continuar acompanhando os níveis de serviços técnicos? Sim, se não estiver indo muito bem, mas apenas como uma ferramenta para chegar onde o rastreamento contínuo seria uma perda de tempo.

Porque, embora um determinado equipamento possa falhar, isso não é mais motivo para os sistemas ficarem fora de serviço. Essa é a natureza das arquiteturas de alta disponibilidade. Se um sistema estiver indisponível, o evento será tão raro, que manter o controle estatístico acabará sendo uma perda de tempo.

O que não será perda de tempo é uma análise de causa raiz, porque cada interrupção significa que sua arquitetura de alta disponibilidade tem uma falha de design que precisa ser corrigida. O que também não é perda de tempo é analisar incidentes relatados para detectar e resolver problemas emergentes de forma ágil, antes que eles se tornem detectáveis ​​para os negócios em geral.

Os serviços de suporte, por outro lado, são o que a equipe de TI faz para ajudar aqueles que trabalham em operações comerciais. Os SLAs dos serviços de suporte estão relacionados a perguntas como quanto tempo alguém deve esperar antes que o suporte técnico responda a sua solicitação e quanto tempo deve esperar até que o problema seja resolvido.

Em qualquer dia, para qualquer chamada, o suporte técnico responde mais rapidamente ou menos rapidamente do que o nível de serviço especificado. Responde mais rapidamente quando a capacidade da equipe de suporte técnico excede o volume de chamadas. E responde menos rapidamente quando o volume de chamadas excede a capacidade da equipe de suporte técnico.

Como tal, o SLA não tem nada a ver com desempenho. É apenas um bastão útil para espancar o gerente de suporte técnico e não muito mais.

O único momento realmente importante é a temporada do orçamento, quando o desempenho do nível de serviço do suporte técnico pode ser usado para justificar a contratação de mais funcionários. Para ser justo, isso não é pouca coisa. Mas justifica a prática de rastrear o desempenho do serviço, e não negociar SLAs.

A única métrica de operações de TI que importa

Para a maioria das pessoas em gestão, o sucesso aumenta sua visibilidade, o que pode levar a promoção, elogios e melhores salários. A única vez que as operações de TI são vistas é quando algo dá errado.

Todas as boas métricas são representações numéricas de objetivos qualitativos. Portanto, a métrica de operações de TI que melhor reflete seus objetivos é uma medida de sua invisibilidade. Esse “índice de invisibilidade” deve ser uma métrica composta que engloba a disponibilidade e o desempenho do aplicativo, o número de chamadas para o suporte técnico – menos chamadas significa mais invisibilidade – e alguma medida que reflete a frequência com que o desempenho das operações de TI acaba servindo como gargalo nos demais processos e atividades.

As equipes típicas de TI são divididas em aplicativos e operações, grupos que tradicionalmente têm desconfianças entre si por dois motivos principais. Primeiro, os aplicativos conseguem fazer alterações, mas cada mudança cria um risco de maior visibilidade para as operações. Segundo, os aplicativos precisam de operações para criar e manter ambientes de desenvolvimento e teste. Para o time de aplicativos, isso significa que as operações são um obstáculo. Para as operações, é trabalho adicional e muitas vezes não programado.

As equipes de desenvolvimento incluem um ou mais times de operações de TI para lidar com as responsabilidades dos processos de forma colaborativa no cronograma do projeto, e não através de uma fila de solicitações. Tudo isso é para dizer que, quando há atrito ou desconfiança entre dois grupos que precisam trabalhar juntos, criar uma mistura colaborativa de pessoal e processos sob a proveniência de cada grupo é uma solução que vale a pena.

Transformação digital e o advento do BusOps

Para a maioria das organizações, a transformação digital é centrada no gerenciamento. Mas já houve uma moda de gerenciamento mais confusa e ambígua do que a própria transformação digital?

Por trás de toda a ambiguidade, há tecnologias digitais específicas que criam novos recursos. As empresas podem tirar proveito delas para criar vantagem competitiva. Ou podem ignorá-las, permitindo que os concorrentes se destaquem.

Por trás dos detalhes está a realidade digital central: a tecnologia da informação não é mais opcional. Ela está profundamente incorporada a todos os processos de negócios. Sua eficácia (e consequente invisibilidade) depende da colaboração contínua de vários especialistas tecnicamente proficientes – praticantes de disciplinas maduras e bem desenvolvidas.

O gerenciamento dos processos e práticas pelas quais a TI é responsável ​​depende, por sua vez, dos gerentes que entendem seu funcionamento interno. Liderá-los depende de pessoas que possam simpatizar com esses profissionais ao lidar com suas obrigações.

Também vale a pena reconhecer que as reorganizações raramente consertam algo. No geral, elas removem barreiras ao colocar grupos que antes não funcionavam bem juntos sob gerenciamento comum, o que também significa que a maioria das reorganizações acaba gerando barreiras entre grupos que costumavam ter o mesmo gerenciamento.

Mover as operações de TI no organograma para que a equipe se reporte ao COO não é mais nem menos lógico do que deixá-la onde está. Quanto à reestruturação das operações de TI, dividir as suas responsabilidades nos negócios simplesmente não funcionará. Ainda existe valor no pessoal técnico trabalhando juntos em problemas comuns.

O que precisa mudar? DevOps aponta o caminho. A cultura da colaboração de DevOps deve se estender ao relacionamento entre as operações de TI e o restante dos negócios, assim como entre gerentes corporativos que desejam executar melhor as tarefas e aplicativos de TI.

Portanto, libere sua equipe de suporte técnico. Sem SLAs para prendê-los em suas cadeiras, você pode incentivá-los a se levantar e visitar alguém com um problema, aprender sobre quais são seus desafios e oferecer ideias sobre como eles podem tirar proveito das tecnologias à sua disposição.

Enquanto isso, no lado das operações da equipe de TI, o ágil precisa ser consertado, também porque não existe um projeto de TI: o Agile, como praticado atualmente, ainda se concentra no fornecimento de um produto e não na colaboração para gerar mudanças intencionais nos negócios. À medida que você ajusta o Agile, corrija-o ainda mais, adicionando a dimensão DevOps de incluir administradores de sistema e segurança nas equipes de projetos de mudança de negócios. Seus projetos terão melhores resultados, e o conhecimento adicional do que é importante nas áreas de negócios tornará as operações de TI mais eficazes na tomada de decisões do dia a dia.

Então, vamos introduzir um novo termo para torná-lo oficial. Assim como o DevOps é a mistura e colaboração de aplicativos e operações de TI, vamos começar a falar sobre o BusOps como a mistura e colaboração de operações de TI e operações de negócios.

Para saber mais sobre essa solução, acesse o nosso site ou entre em contato conosco! Nós estamos a postos para ajudar!

Fonte: Bob Lewis, CIO (EUA)