Construindo uma TI eficaz: os 3 processos de TI que os CIOs mais precisam

O princípio nº 7 do Manifesto Keep the Joint Running diz que antes de ser estratégico você tem que ser competente. Os processos e práticas de TI são como o trabalho de TI é feito. Eles estão onde a competência, ou sua ausência, acontece.

O artigo anterior desta série falou sobre as verdades duras do que significa “melhorar” os processos e práticas de TI. A questão agora é em qual deles você, como CIO, precisa concentrar sua atenção pessoal.

A resposta começa com este princípio básico: Os gerentes nunca devem patrocinar pessoalmente mais de três iniciativas de mudança. Exceda esse número mágico e você perderá sua capacidade de se concentrar e, portanto, de liderar.

Mas qual dos três os CIOs devem escolher? Aquele que não se concentrar em: operações de TI. O candidato mais óbvio para organizar seu programa de melhoria de processos é a conhecida estrutura ITIL. Mas isso seria um erro.

Não que a adoção da estrutura ITIL seja um erro. É uma estrutura perfeitamente fina com décadas de maturação por trás dela. É que o foco da ITIL está nas operações de TI. E as operações de TI só são notadas quando algo dá errado. Como CIO, você deseja ser notado quando algo der certo.

Portanto, se sua organização de TI precisa ser melhor em gerenciamento de disponibilidade, gerenciamento de capacidade, gerenciamento de desempenho, gerenciamento de ciclo de vida de infraestrutura, administração de sistemas e, especialmente, gerenciamento de mudança, certifique-se de ter a pessoa certa no comando das operações de TI e deixe claro que você vai medir seu sucesso pela única métrica de operações de TI que importa – o índice de invisibilidade – o que significa que você deve ser o único a perceber quando as operações de TI não são notadas.

Como CIO, você deve reconhecer que, embora as operações de TI sejam extremamente importantes, não são de todo estratégicas, exceto que, conforme observado, se não for bem feito, você não pode ser estratégico.

Delegue e certifique-se de que o gerente a quem você delegou tenha todas as ferramentas e suporte de que precisa.

Prioridade de processo nº 1: o help desk

Consertar o help desk deve ser sua principal prioridade se a reputação de TI – isto é tudo sobre a reputação de TI – for menos do que estelar.

O relacionamento da TI com o resto da empresa vive e morre no help desk. Então, se você ouvir isso ser chamado de “helpless desk” ou se seus colegas de negócios perguntarem por que a TI não sabe que um sistema está inativo até que liguem para a central de suporte para informá-los, ou se você ouvir uma troca do pessoal do help desk sobre histórias de usuário idiotas, ou se, quando alguém liga para o help desk para algo rápido e simples e o help desk fornece um número de tíquete em vez da resposta de 10 segundos de que eles precisam no momento – escolha seu sintoma e se o help desk o exibir, dê atenção pessoal ao conserto disso.

O suporte de negócios de que você precisa para fazer o resto da sua organização de TI brilhar depende disso.

Prioridade de processo nº 2: suporte de aplicativo

Regra 1: se suas equipes de suporte a aplicativos ainda estão imersas em metodologias em cascata, o que você está esperando? Comece a movê-los para o Agile imediatamente e supervisione a estratégia de adoção do Agile e sua execução pessoalmente.

Regra 2: Agile é mais do que Scrum. Escolha as variantes ágeis certas para o trabalho que a TI realmente faz, não Scrum, porque “é isso que todos estão usando”.

Regra 3: a maioria das variantes ágeis são projetadas para gerenciar o desenvolvimento de aplicativos. A maioria “compra quando pode e só constrói quando precisa”. Se for você este o caso, ignore o Scrum completamente. Em vez disso, faça com que suas equipes de aplicação adotem o CRP (piloto de sala de conferências) ou seu primo próximo, ATDD (desenvolvimento orientado a testes de aceitação).

Regra 4: A maioria das variantes ágeis concentra-se na entrega de software como um produto. A maioria das empresas precisa de TI para colaborar na obtenção de mudanças intencionais nos negócios. Modifique todas as variantes ágeis que você adotar para que elas façam isso.

Prioridade de processo nº 3: gerenciamento de arquitetura de TI

Abordaremos como avaliar a qualidade e excelência da própria arquitetura de TI na próxima edição desta série. Se for ruim, isso é um sintoma de uma prática incorreta de gerenciamento de arquitetura de TI, é claro.

Quais são alguns outros sinais de que sua prática de gerenciamento de arquitetura de TI precisa de ajuda?

“Não podemos dizer o quão boa é a nossa arquitetura”, é um sintoma comum surpreendente e deprimente. Por falar nisso, “Não sabemos o que temos” não é tão incomum.

O que mais? Não tem:

• Publicou e divulgou uma curta (e curta significa não mais do que uma dezena) lista de princípios de arquitetura que norteiam todo o resto. E além de serem curtos, os princípios devem ser escritos em uma linguagem simples e sem jargões.
• Publicou e divulgou uma lista de padrões que são: enraizados nos princípios; mantidos atualizados com base em uma prática bem documentada; e atualizados em uma programação regular (trimestralmente faz sentido).
• Gerenciamento do ciclo de vida estabelecido como prática padrão, integrando-o ao planejamento e orçamento de TI.
• Desenvolveu uma estratégia de nuvem construída em torno dos princípios e padrões de arquitetura e em torno do entendimento de que a nuvem é uma arquitetura, não um local de armazenamento e processamento.

Isso não significa que, se a arquitetura de TI estiver livre dessas falhas, a prática estará em boas mãos.

Uma prática de arquitetura de TI – junto com sua prima integrada aos negócios, a prática de arquitetura corporativa – está em risco constante de deixar de adicionar e manter valor e se tornar um atoleiro burocrático.

A propósito, esse perigo não é exclusivo da arquitetura. Qualquer organização encarregada de revisar e criticar o trabalho criativo de outras equipes compartilha o mesmo risco.

Uma arquitetura de alto nível requer uma mentalidade antiburocrática. Ele também precisa de financiamento, porque os projetos que fornecem aplicativos com recursos e funcionalidade satisfatórios custam menos do que aplicativos com recursos e funcionalidades satisfatórios que atendem aos padrões arquitetônicos.

Como é improvável que seu patrocinador executivo esteja disposto a pagar a diferença, os projetos que entregam ou modificam a funcionalidade do aplicativo precisarão de um subsídio de arquitetura para cobrir a propagação.

Uma função de gerenciamento de arquitetura de TI deve encontrar maneiras de obter uma arquitetura saudável e, ao mesmo tempo, minimizar o uso da aplicação como sua tática primária. Também deve persuadir a liderança executiva de que uma boa arquitetura é um investimento empresarial inteligente. Por causa dessas duas preocupações vitais, é difícil escapar da conclusão de que, mesmo nas melhores circunstâncias, como CIO, você deve supervisionar pessoalmente a equipe de arquitetura de TI.

Mas e quanto à segurança da informação?

Nos dias de hoje, onde as ameaças relacionadas à TI para os negócios são cada vez mais patrocinadas pelo crime organizado e agentes estatais mal-intencionados, e onde o dano potencial de invasões há muito cresceu de “agravamento” para “enorme”, a segurança da informação tem que ser uma das principais prioridades de TI. Mas, semelhante às operações de TI, a eficácia da segurança da informação é medida por seu próprio Índice de Invisibilidade.

Só que é pior, porque para ser eficaz, a segurança da informação tem que ser intrusiva, então algum nível de visibilidade desagradável acompanha o território.

Mais um ponto: a segurança da informação que não está estreitamente associada a uma arquitetura de TI de alta qualidade é a segurança da informação com brechas.

Portanto, inclua a segurança da informação em sua prática de arquitetura de TI, onde você, como CIO, pode ficar de olho nela também, sem fragmentar ainda mais sua atenção.

Abordar a inovação de TI (também conhecida como “digital”)

Observe onde as oportunidades de negócios para inovação estão acontecendo e você descobrirá que a tecnologia da informação, se não é o principal candidato, certamente está entre os três primeiros.

Como CIO, suas escolhas aqui são assumir o controle da inovação de TI ou abraçar a ideia de adicionar um diretor digital à equipe de liderança executiva.

Mas isso constituiria uma proclamação de inadequação de sua parte. Não vamos fazer isso.

Em vez disso, inclua a inovação de TI na prática de arquitetura de TI também. Fazer isso não apenas dá à inovação um lar organizacional para que ela não fragmente sua atenção, mas também coloca a responsabilidade pela inovação no mesmo lugar que a necessidade de longo prazo de integrar inovações de TI ao resto da arquitetura de TI. Afinal, você não quer que as inovações de TI se tornem futuras ilhas de automação.

Como lidar com “TI Faça Você Mesmo”

Faça você mesmo, também conhecido como “shadow IT” é algo que muitos CIOs fazem o possível para superar. E, de qualquer forma, TI DIY é mais oportunidade do que problema, pois aumenta drasticamente a largura de banda de TI da empresa sem aumentar seus gastos com TI – ou pelo menos seus gastos visíveis com TI.

As desvantagens são, em sua maioria, evitáveis. Principalmente, é necessário que a TI forneça um mínimo de suporte em termos de consultoria técnica para garantir que está em conformidade com os padrões de arquitetura de TI, em troca da função de arquitetura de TI obter a documentação necessária para evitar que o TI DIY se torne uma TI secreta.

Para concluir

Para que a TI seja competente, ela deve realizar seu trabalho usando processos e práticas bem projetadas, definidas e documentadas. Os CIOs são responsáveis por todas elas, mas na prática não podem guiar pessoalmente uma transformação de mais de três.

Na maioria das organizações de TI, os três domínios de processo que mais precisam da liderança pessoal dos CIOs são help desk, suporte a aplicativos e gerenciamento de arquitetura de TI. Dê brilho a eles e a TI terá sucesso – visivelmente.

Isso só se as operações de TI brilharem também, e é por isso que, paradoxalmente, os CIOs devem certificar-se de delegar essa responsabilidade. Deixar de fazer isso implica em você não ter largura de banda suficiente para polir os três grandes domínios de processo.