3 processos de TI que CIOs mais precisam.
Construindo uma TI 101 eficaz: Os processos são importantes, mas alguns são mais importantes do que outros. É aqui que você deve colocar seus esforços como um líder de TI.
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 é realizado. Eles são onde a competência, ou sua ausência, acontece.
O capítulo anterior desta série falou-se sobre as duras verdades 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 perderá a capacidade de se concentrar e, portanto, de liderar.
Mas quais três os CIOs devem escolher?
O 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 do framework 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. Conheça o GoAnywhere que ajudará a automação de transferência de arquivos com segurança totalmente gerenciada.
Como CIO, você deve reconhecer que, embora as operações de TI sejam extremamente importantes, elas não são estratégicas, exceto que, conforme observado, se não for bem feito, você não pode ser estratégico.
Delegue-o 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
Ajustar o help desk deve ser sua principal prioridade se a reputação de TI – toda a reputação de TI – for menos do que estelar.
O help desk é o enteado da TI, o que é lamentável, porque um fator-chave na integração bem-sucedida de TI com o resto da empresa é a qualidade do relacionamento entre negócios e TI.
O relacionamento da TI com o resto da empresa vive e expira no help desk. Portanto, se você ouvir isso como “mesa indefesa” 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 do pessoal da central de suporte, histórias de usuário sem discernimento, 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 agora – escolha seu sintoma e se o help desk o exibir, dê atenção pessoal ao conserto do help desk.
O suporte de negócios de que você precisa para fazer o resto de sua organização de TI brilhar depende disso. Conheça o Automate da Helpsystems ou o Power Automate da Microsoft.
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 das compras de TI “compra quando pode e só constrói quando precisa”. Se for você, ignore o Scrum completamente. Em vez disso, faça com que suas equipes de aplicação adotem o CRP (piloto de sala de conferência) ou seu primo próximo, ATDD (desenvolvimento orientado a teste 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 isso seja o que elas devem fazer.
Prioridade de processo nº 3: gerenciamento de arquitetura de TI
Abordaremos como avaliar a qualidade e excelência da própria arquitetura de TI no próximo capítulo desta série. Se for ruim, é um sintoma de uma prática de gerenciamento de arquitetura de TI falha, é 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:
- Publicar e divulgar uma lista 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;
- Publicar e divulgar uma lista de padrões que são: enraizados nos princípios; mantido e atualizado com base em uma prática bem documentada; e atualizado 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;
- Desenvolver uma estratégia de nuvem baseada nos princípios e padrões de arquitetura e no 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.
A prática de arquitetura de TI integrada aos negócios, ou seja, a prática de arquitetura corporativa – está em risco constante em 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 anti burocrá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 médio 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 diferença.
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 que ela fragmente ainda mais sua atenção.
Abordando a inovação de TI (também conhecido como ‘digital’)
Observe onde as oportunidades de negócios para inovação estão acontecendo e você descobrirá que a tecnologia da informação está, se não a principal candidata, certamente entre as três primeiras.
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. Além disso, dividiria a liderança de TI em dois, com o CDO se tornando o Capitão We Oughta, enquanto você se torna o Dr. Não. E assim, “CIO” se tornaria uma declaração de seu plano de aposentadoria (“A Carreira Acabou”).
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 não fragmentar 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. Afinal, você não deseja que as inovações de TI se tornem futuras ilhas de automação.
Como lidar com ‘DIY IT’
Faça você mesmo, também conhecido como “shadow IT”, “rogue IT” e “PARE! Você está me dando enxaqueca! TI ”, é algo que muitos CIOs fazem o melhor que podem para superar.
Nisso, eles se parecem com o *Rei Canuto ordenando que a maré não suba.
E, de qualquer forma, DIY IT é 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 da TI DIY 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 esteja 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 DIY IT se torne uma TI secreta.
O que torna o suporte para DIY IT mais uma prática de TI que pode se encaixar confortavelmente na função de arquitetura de TI.
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 todos eles, mas, na prática, não podem guiar pessoalmente uma transformação em número superior a 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 o help desk, o suporte a aplicativos e o gerenciamento da arquitetura de TI. Dê brilho a eles e a TI terá sucesso – e visivelmente.
Isso só acontece se as operações de TI também brilharem, e é por isso que, paradoxalmente,
os CIOs devem certificar-se de delegar essa responsabilidade. Deixar de fazer isso, você não terá largura de banda suficiente para polir os três grandes domínios para o sucesso.
Legendas
*Manifesto Keep the Joint Running = Um Manifesto para a Tecnologia da Informação do Século 21 (também conhecido como o Manifesto KJR) redefine radicalmente como a TI deve operar, em 13 capítulos altamente práticos e diretos.
*Rei Canuto = Rei Cnut (também conhecido como Rei Canute ou Rei Canuto) foi uma das figuras mais proeminentes do período anglo-saxão. Nascido na Dinamarca, entre 985 e 995 dC, filho do príncipe dinamarquês Sweyn Forkbeard, Cnut tornou-se um feroz rei guerreiro dinamarquês, quem conquistou vastas faixas do norte da Europa e governou a Inglaterra entre 1016 e 1035.
