TI Corporativa

Ξ 2 comentários

TI é o negócio, mas é necessário pensamento estratégico

publicado por Cezar Taurion

TI é o negócio mas é necessário pensamento estratégicoTI é o negócio. Mas para isso ser verdade, é necessário pensamento estratégico. A atual TI está diante de dois cenários e ela terá que optar: se tornar irrelevante, à medida que deixa de ter o monopólio de fornecer infraestrutura e apps para a empresa, com o usuário buscando outras fontes, ou se tornar parte integral do negócio. A decisão que tomarmos hoje é que vai fazer a TI de amanhã. Conto aqui uma história hipotética, através de diálogos imaginários, de um CIO que tomou esta decisão.

Ele decidiu que queria liderar uma TI importante para sua empresa e então partiu para pensar estratégico e não mais como executivo de um setor chamado TI, mas como executivo de negócios, aproveitando seu amplo domínio de TI.

Seu primeiro passo: entender o contexto atual do negócio, saindo da caixinha…Como ele disse: “levantei a cabeça da mesa e olhei ao redor”. O que ele viu acontecendo na sua empresa? Mais e mais opções tecnológicas amplamente disponíveis aos usuários no mercado. Só ir lá e comprar, e os seus usuários já faziam isso… BYOD, BYOA, e outros acrônimos mostram que cada vez mais o fenômeno da consumerização tem influência estratégica nas decisões de como adotar tecnologia nas empresas. Ele observou também que os usuários estão também cada vez mais desenvolvendo tarefas que envolvem conhecimento (knowledge workers), estão (como ele) sujeitos à frequentes mudanças organizacionais (expansões e retrações de mercado, compra e venda de empresas e mudanças de foco estratégico ou de modelos de negócio, e na sua empresa isso era tão frequente que gerava stress) e demandando um grau de colaboração e interdependência muito maior que há dez anos atrás. Segundo ele, hoje cada funcionário colabora com pelo menos dez outros indivíduos, de dentro ou fora da empresa, para exercer sua tarefa. Ele descobriu também que as decisões cada vez mais passam por um número maior de pessoas e demandam um volume muito maior de informações a serem analisadas. Foi fácil de validar. Bastou analisar o trabalho efetuado em algumas funções como marketing, operações (com grande interação com parceiros) e supply chain, que interage e colabora com uma complexa rede de relacionamentos. As frequentes mudanças organizacionais que sua empresa tem passado demandam forte pressão em áreas como RH, qualidade e jurídico. E esta mesma volatilidade também aumenta a demanda por mais knowledge workers, pois cresce significativamente as exceções às regras tradicionais da operação, exigindo maior autonomia e informações para execução das decisões e das próprias tarefas. Além disso, no seu tour pela organização ele viu que algumas funções estão se tornando cada vez mais sofisticadas, demandando muito mais informações para serem efetuadas como marketing (engajamento com clientes), vendas (maior conhecimento do perfil do comprador) e finanças (cada vez mais demandando algoritmos preditivos para validação de cenários). Esta mudança no contexto de como a empresa opera, mudou, segundo ele, totalmente as demandas pela TI. E ele não havia observado antes…

Como sua decisão foi não deixar TI se tornar irrelevante, partiu para ação próativa, e criou uma estratégia de se antecipar às demandas dos usuários. Sentiu que se continuasse em standby, aguardando as decisões dos negócios, para então agir, eles, usuários, simplesmente optariam por buscar soluções no mercado, em nuvens e lojas de apps, bypassando sua área de TI. Afinal, ele nunca teria recursos suficientes para atender a todos…Fez algumas mudanças em seu modelo mental, a que estava tão acostumado e segundo ele, difíceis de fazer. Afinal, estavam arraigadas em sua mente e hábitos, Como disse, “é realmente difícil sair da zona de conforto”. Para isso ele conversou com o CEO e demais C-level e deixou de lado os planos de longo prazo, para se tornar mais flexível e iterativo nos processos de planejamento e desenvolvimento de iniciativas tecnológicas. Mostrou aos seus pares na empresa que um PDTI de 3 a 5 anos à frente não faz mais sentido. É jogar tempo, energia e dinheiro fora. Conseguiu que o CEO apoiasse sua estratégia da TI passar a assumir um papel cada vez mais de advisor e menos de fornecedor monopolista de soluções.

Olhando o contexto à sua volta, identificou que TI deveria prover o mais rapidamente possível a empresa de plataformas de soluções que permitissem uma maior colaboração interna e externa, possibilitando que os usuários criassem suas próprias soluções. Foi o primeiro olhar com ótica outside-in, ou seja, olhou a empresa pelos olhos da empresa e não pelo ponto de vista da TI, como sempre fizera. Que isso significa? Uma mudança e tanto…ao invés de fornecer uma solução completa como acostumado a fazer na época do ERP, ele criaria um ambiente que separasse os dados funcionais dos interfaces, através de uma arquitetura de serviços, APIs e apps store interna. Os sistemas tradicionais e o próprio ERP deveriam ser desconectados dos interfaces atuais (que hoje são pouco intuitivos e inflexíveis), passando a ser acessados por apps front-end. A estratégia de TI passaria a de ser o responsável por manter a integração entre os sistemas que conectam os dados funcionais, mas os usuários passariam a ser responsáveis por criarem suas próprias apps (ou terceirizando o trabalho com a própria TI ou com fornecedores externos).

Como ele mesmo confessou, este cenário é imensamente desafiador para a TI de hoje. Quebra paradigmas. Mas é necessário, pois como a vantagem competitiva das empresas passa a ser a informação sobre os processos e não mais apenas os processos, o papel de TI muda, de provedor dos sistemas focados em processos como ERP, para o de criação de plataformas para apps analíticas. Assim, ele lembra, TI antes concentrava seus esforços em atender as demandas de finanças, produção, supply chain e RH. Agora, “a nova TI”, como ele diz, passará a atender mais fortemente marketing e vendas, serviço ao cliente e inovação em produtos e serviços. “Teremos o desafio de sair da era do ERP para a era dos sistemas de analytics e apps com interfaces contextuais”. Neste momento, respirou fundo e disse “cara, é como participar de uma competição de Ironman, você simplesmente não sai correndo sem se preparar exaustivamente antes. Tem que treinar muito. Planejar, ver onde tem que mudar e corrigir os erros à medida que os for encontrando. Um dia, você estará preparado para competir”. Em resumo, sua mensagem foi: pense grande no longo prazo, comece pequeno e aja rápido.

Curiosamente, ele descobriu que o atendimento à estas funções de negócio é que iria definir se a sua TI seria relevante ou não para a empresa. Diferentemente do ERP onde os usuários não tinham alternativa, o acesso a ferramentas de analytics e apps não obrigam que os usuários dependam que seja feita via TI. Existem cada vez mais alternativas fora da TI e ele sentiu era realmente este o momento único de TI ter tomado a decisão de ser importante ou ser deixado na periferia do negócio. Já pipocavam aqui e ali várias iniciativas isoladas conduzidas pelos usuários, sem que ele soubesse que estavam acontecendo.

Definiu algumas prioridades. Uma delas é que mobilidade seria a regra e não exceção. E que apps móveis tem dinâmica diferente da que sua área de desenvolvimento estava acostumada. Teria que adotar uma nova arquitetura, baseada em serviços e APIs, e mudar o processo de desenvolvimento e entrega à produção, para um conceito de entrega contínua. Os modelos de governança que ele adotava e tinha orgulho, como ITIL, funcionam muito bem para o mundo dos ERPs mas não se aplicam ao dinamismo das apps móveis. Outra prioridade: dados. Deveriam ser armazenados para serem usados após sua utilização básica. Na prática, segundo ele, “comecei a estabelecer as bases para criação de Big data/analytics na empresa”.

Voltando a área de desenvolvimento, sua decisão foi de separar os interfaces dos dados funcionais. Ele observou que diversos segmentos de usuários tinham necessidades diferentes para uso dos processos e dados, e que os obrigar a usar o mesmo interface, como os sistema tradicionais fazem, era contraprodutivo. Como TI jamais conseguiria fazer tantos interfaces diferentes optou por criar uma arquitetura que permitisse que os usuários desenvolvessem suas próprias apps, mas ele, como TI, manteria o controle da segurança. Foi a decisão de usar APIs e a arquitetura baseada em serviços. Para isso precisou desenhar estratégia, ainda nos passos iniciais, de criar maior engajamento com usuários, criar novos skills em TI (user experience designer, por exemplo), criar novas formas de disponibilizar apps (uma apps store interna) e implementar tecnologias adequadas para gestão, entre outras ações. Não é um processo que se faz em um dia…

Perguntei então quais suas diretrizes…Muito simples, respondeu. São somente sete:

  1. Ser rápido e antecipar-se ao invés de esperar pelas demandas dos usuários. Liderar o processo de disseminação da inovação na empresa. Muitas das inovações surgem naturalmente dos usuários e TI criará mecanismos para incentivar e disseminar estas inovações.
  2. Mobilidade em primeiro lugar. Mobilidade será regra e não exceção.
  3. Interfaces democráticos ou seja em vez de cada aplicação oferecer um único interface para todos os usuários, as aplicações terão agora seus interfaces desconectados dos dados e funcionalidades. Cada segmento de usuário pode desenhar e implementar seu próprio interface, geralmente via app.
  4. TI apenas gerenciará a loja de apps. E estes serão desenvolvidos pelos usuários, por terceiros ou pela própria TI.
  5. TI será responsável pela integração e segurança do ambiente. Claro, também manterá o ambiente legado que continuará importantissimo, pois estes sistemas constituem a “praça das máquinas” da empresa.
  6. TI não será mais monopolista. Isto significa que os usuários poderão escolher suas fontes de provisionamento de tecnologias. TI passará a assumir papel de advisor.
  7. Ser ágil não apenas na metodologia de projetos, mas em todo o ciclo. Adotar o modelo de entrega contínua. A sua fonte de inspiração foi este texto “How the Software industry Redefines Product Management”, que compara duas grandes empresas Staples e Amazon e as diferenças entre elas no ciclo de entrega de produtos de software.

Bem, é uma história hipotética, mas poderia muito bem ser verídica…Por que não?

[Crédito da Imagem: Pensamento Estratégico – ShutterStock]

Autor

Cezar Taurion é head de Digital Transformation da Kick Ventures e autor de nove livros sobre Transformação Digital, Inovação, Open Source, Cloud Computing e Big Data.

Cezar Taurion

Comentários

2 Comments

  • Bem colocado Cezar.
    Hoje ainda estava falando sobre esses pontos durante uma sessão de mentoring. Toquei no assunto do bypass que, principalmente as equipes de desenvolvimento de software, vem fazendo na gerência de TI e infraestrutura.
    Empresas consolidadas e de regras rígidas em relação à segurança estão com aplicações sendo escritas em repositórios de código em contas pessoais dos desenvolvedores, testes rodando em servidores pessoais digital Ocean pois o desenv consegue fazer o deploy lá mais rápido e entregar mais cedo o trabalho do que tivesse que esperar a TI entregar aquela VM que ele solicitou.
    Um risco para a empresa.

You must be logged in to post a comment.

Busca

Patrocínio

Publicidade



Siga-nos!

Newsletter: Inscreva-se

Para se inscrever em nossa newsletter preencha o formulário.

Artigos Recentes