Por Sergio Lozinsky
Não dá tempo de planejar o futuro – o dia se esgota no apagar de incêndio e na resposta rápida à próxima emergência. Quem nunca se sentiu assim? Afinal, esse é um dos maiores problemas enfrentados por gestores em geral, o que não é diferente com os líderes de tecnologia. Pelo contrário, eu vejo essa constatação na prática, com uma frequência preocupante, ao lidar diariamente com CIOs e ouvir suas dores.
Esse desafio é amparado por números. Segundo o estudo Jornada CIO, que busca entender e analisar a presença da TI no negócio pelas lentes do líder da área, o envolvimento com as questões operacionais é um grande problema para 60% dos entrevistados. Note que estou me referindo a uma amostra composta em mais de 50% por empresas que faturam acima de R$ 1 bilhão – ou seja, organizações em que a TI deveria possuir um grau significativo de sofisticação.
O número assusta, mas não surpreende.
Uma emergência operacional não pode ser ignorada pela TI e ninguém deixará um problema para amanhã só porque, neste momento, está planejando o futuro. Isso seria ingenuidade. Afinal, o primeiro objetivo da TI é garantir a continuidade e a eficiência das operações. Por outro lado, a ocorrência frequente de incidentes operacionais é um claro indicativo de problemas mais estruturais, geralmente relacionados a processos e soluções em atividade que, com o tempo, deixaram de ter a aderência funcional e/ou passaram a apresentar algum tipo de obsolescência tecnológica.Adivinhe por qual razão isso acontece? Porque os profissionais estão envolvidos demais com demandas operacionais urgentes para cuidar, em tempo hábil, da evolução da arquitetura tecnológica da empresa. Forma-se, assim, um ciclo de emergências que se retroalimenta, atrapalha qualquer planejamento e dificulta a melhoria contínua.
Para quebrar o ciclo de emergências e conseguir pensar adiante, é preciso maturidade na gestão. E, como ocorre com todo problema complexo, a resolução de tal impasse envolve um conjunto de cuidados e ações.
Primeiramente, é importante entender que muitos dos problemas têm origem na implantação de soluções e que não foram mapeados por uma série de razões ligadas à gestão de projetos – são indicativos de que esse tipo de iniciativa precisa melhorar ou amadurecer. Por exemplo, se a solução foi escolhida via uma seleção de produtos de mercado, talvez os requisitos funcionais e não-funcionais não tenham sido explorados, ou mesmo identificados adequadamente. Já se a definição foi por uma solução proprietária, é bem provável que o tempo dedicado a especificar objetivos, abrangência, processos críticos, peculiaridades e complexidades tenha sido insuficiente, ou o conhecimento, ainda, superestimado.
Durante o projeto de implementação – da solução de mercado ou do sistema proprietário – será que a fase de aprovação das especificações de processo foi adequadamente analisada com os usuários, no sentido de entenderem os impactos que o novo sistema trará para as suas atividades? Será que eles perceberam que os processos serão atendidos satisfatoriamente? Tais questões acabam surgindo durante testes e treinamentos, muitas vezes exigindo um adiamento do golive. Mas a pressa em entregar o projeto acaba criando problemas para a futura operação.
Ainda que as coisas ocorram razoavelmente bem funcionalmente falando, as questões de infraestrutura e serviços de tecnologia – testes de stress, perfis de acesso bem definidos, segurança da informação, recuperação de desastres, latência, contingências – foram endereçadas? Um sistema “lento” ou que “cai” dificilmente será percebido como uma boa solução.
Os cuidados não terminam por aí: as integrações também podem exigir a construção de soluções específicas – ou, mais provavelmente, hoje em dia, o uso de barramentos de integração, APIs e outros. Esse é um assunto ainda razoavelmente subestimado, porque é visto como aspecto técnico, embora tenha total conexão com a automação dos processos de negócios e, portanto, deva ser discutido nos workshops de especificação funcional da solução. Tais questões aparecerão nos testes, se houver atenção a elas, ou depois da implantação, dificultando as operações.
Considere, ainda, a questão pura e simples da resistência à mudança, que está presente na maior parte das empresas, apesar de vivermos uma época de transformação de quase tudo à nossa volta. Identificar que será preciso tratar os impactos organizacionais como parte do projeto de implantação pode evitar vários problemas operacionais, ou mesmo a proliferação de planilhas depois do golive.
Ainda poderíamos discorrer sobre a integração do ecossistema de prestadores de serviços, parceiros e outros terceiros às operações, o que é fundamental para obter a estabilidade técnica e funcional da nova solução. Isso requer planejamento, boa definição dos termos contratuais e das penalidades, e uma distribuição de papéis e responsabilidades compreendida por todos os envolvidos.
Por fim, se a pressa é uma explicação para as emergências, certamente ela não é a única. O excesso de problemas operacionais também pode ser sintoma de dificuldades do negócio, que eventualmente precisa investir em mais planejamento e governança. Se a meta é excelência operacional e redução de custos, a TI talvez tenha como maior desafio a automação e a melhoria de sistemas. A prioridade é expandir? Lançar produtos e serviços? Alcançar novas geografias e até internacionalizar a operação? Então, a tecnologia precisa estar voltada a melhorar os sistemas que suportam esses movimentos.
Não faz sentido orgulhar-se de viver resolvendo problemas. Para que um negócio cresça, é preciso tempo e, também, alguma tranquilidade. E o grande benefício de reduzir as questões operacionais de TI para um nível satisfatório é que sobra tempo. Tempo que pode ser investido em pensar adiante, em melhorar a experiência do cliente, em desenvolver indicadores de eficiência que vão ajudar a tomar decisões mais assertivas e permitir que uma empresa seja mais competitiva no mercado.