As classificações dos algoritmos de Machine Learning

O machine learning, ou aprendizado de máquina, é um ramo da inteligência artificial que se baseia na ideia de que sistemas podem aprender com dados, identificar padrões e tomar decisões com pouca intervenção humana. De tempos para cá o machine learning se tornou essencial na tecnologia e, consequentemente, nas nossas vidas. Este tipo de conhecimento explora a construção de algoritmos que aprendem com seus erros e fazem previsões sobre dados a partir  de diferentes abordagens. 

Diante de um problema onde a solução esteja num aprendizado de máquina, deve-se escolher, dentro deste universo de técnicas, por qual caminho iniciar. Assim, os algoritmos de aprendizado de máquina podem ser classificados em três grandes grupos: Aprendizado Supervisionado, Aprendizado Não-Supervisionado e Aprendizado por Reforço. Abaixo você vai entender cada uma delas.

Aprendizado supervisionado

Nesta abordagem o modelo aprende a executar uma tarefa a partir de exemplos rotulados, ou seja, a partir das respostas corretas, que de alguma forma devem ser passadas para o modelo. Mas como fazer isso? Vejamos com estes dois exemplos: 

  • No primeiro, poderíamos ter um conjunto de imagens separadas por diferentes tipos de veículos (carros, motos, caminhões, ônibus) mapeados cada um com o nome do tipo que representa; 

  • Num segundo exemplo, poderíamos ter uma tabela com valores históricos de demanda num supermercado para servir de exemplo no aprendizado necessário para generalizar uma demanda futura.

Este aprendizado é iterativo e é realizado até que uma condição seja atingida, geralmente uma porcentagem aceitável de acertos, ou seja, a ideia é sempre de minimizar os erros que a inteligência artificial produz. Essa condição de parada com base na acurácia máxima é possível pois se trata de aprendizado com resultado conhecido.

Neste grupo, se encaixa também o aprendizado semi-supervisionado que é quando se tem alguns exemplos rotulados e muitos não-rotulados. A ideia aqui é encontrar padrões semelhantes entre os exemplos e também fazer uso dos rótulos existentes. O Aprendizado Supervisionado consiste em duas classes de algoritmos: Classificação e Regressão, dos quais falaremos mais adiante.

Aprendizado Não-Supervisionado

Em alguns casos, apesar de existir o objetivo da tarefa desejada, os resultados finais não são conhecidos e, portanto, não se tem os rótulos para passar ao modelo. Por exemplo: dada uma coleção de artigos, deseja-se agrupá-los automaticamente de acordo com a frequência de algumas palavras ou contagem de páginas. Não se sabe quantos grupos serão formados.

É nesse contexto que se apresenta o aprendizado não-supervisionado. Este modelo aprende a executar uma tarefa a partir de dados não-rotulados (sem um resultado conhecido), apenas com base em suas características e padrões semelhantes, ou seja, o modelo deduz estruturas a partir de uma amostra do problema; bem utilizado em situações com muitas observações e muitas features como: áudios, imagens e vídeos.

Para isso, existem algumas técnicas que utilizam regras de associação e clusterização, como veremos um pouco mais adiante. Essas técnicas podem ser aplicadas na fase de pré-processamento (ou mineração de dados), para se encontrar anomalias nos dados (os outliers), realizar redução de dimensionalidade em features, etc. Elas podem ser aplicadas também sobre amostras de um problema durante um processo de agrupamento de instâncias.

Alguns exemplos: um sistema que seleciona candidatos para uma vaga, ou que separa turmas de alunos para um determinado trabalho, através de técnicas de agrupamento baseadas em determinadas características que são semelhantes entre essas pessoas.

Mas para qualquer tipo de algoritmo, vale ressaltar um cuidado especial para que a inteligência artificial não faça predições preconceituosas quando se trata de seleção de pessoas, dependendo das features o sistema pode apresentar um viés racista ou sexista. Um exemplo disso é a seleção apenas de homens para vagas de engenharia, por isso o dataset deve ser cuidadosamente balanceado. 

Aprendizado por Reforço

No Aprendizado por Reforço o modelo aprende executando ações e avaliando recompensas. Em resumo, este tipo de algoritmo funciona da seguinte maneira: O agente realiza uma ação num dado ambiente, alterando seu estado inicial, o que gera uma recompensa ao agente. De forma cíclica, o agente avalia esta recompensa (que pode ser positiva ou negativa) e age novamente no ambiente, gerando o aprendizado.

Neste tipo de aprendizado muda-se um pouco o paradigma com relação aos outros dois. Geralmente é aplicada quando se conhece as regras, mas não se sabe a melhor sequência de ações que devem ser executadas, elas são iterativamente aprendidas, como num jogo de xadrez ou num videogame, onde o fundamental são as ações tomadas pelo jogador (ou pela máquina). A robótica é outro campo onde se aplica este aprendizado. Alguns algoritmos: Multi-Armed Bandits, Contextual Bandits e k-Armed Bandits.

Bem, a partir do problema em questão, podemos identificar agora qual o tipo de aprendizado utilizar. Em seguida devemos escolher uma classe de algoritmo para este tipo de aprendizado.

Se for Aprendizado Supervisionado, temos basicamente duas classes de algoritmos:

  •  Classificação;

  • Regressão

Na classificação, o objetivo é identificar a qual categoria pertence uma determinada amostra do problema. Se um e-mail é SPAM ou não; se uma mensagem tem um sentimento positivo, negativo ou neutro; se um vídeo possui conteúdo adulto; ou quais são os animais que aparecem numa determinada imagem, assim por diante.

Exemplos de técnicas de classificação são: Árvores de Decisão (onde os nós internos são rotulados com uma feature de entrada, e os nós folhas são rotulados com a classe a ser preterida), Algoritmo de Naïve Bayes (que é um classificador que trabalha com probabilidades de ocorrência de cada classe para cada valor de atributo, supondo que as variáveis são independentes), temos as Redes Neurais (baseadas em redes de neurônios artificiais interconectados – os perceptrons, onde os pesos das camadas ocultas são ajustados a cada iteração), dentre outros.

Diferentemente da classificação, na regressão, a ideia é prever um valor numérico; ou em outros termos: identificar uma categoria em escala contínua (pode ser até uma probabilidade). Neste caso, o modelo pode aprender uma função para prever o preço de um imóvel, uma demanda de venda, probabilidade de superlotação de um estoque, o tempo que levará para uma máquina apresentar defeito, uma nota de um cliente para aumentar seu limite de crédito, ou qualquer outro valor quantitativo.

Alguns exemplos de técnicas de regressão são: regressão linear, regressão logística e as redes neurais (que também podem resultar valores contínuos).

Agora, no Aprendizado Não-Supervisionado, destacam-se duas técnicas:

  •  Associação;

  • Clusterização.

A associação: permite o descobrimento de regras e correlações, identificando conjuntos de itens que frequentemente ocorrem juntos. Os varejistas costumam usar esta análise em carrinhos de compras, para descobrir itens frequentemente comprados em conjunto, desenvolvendo assim estratégias mais eficazes de marketing e merchandising.

Na clusterização (ou agrupamento): o conjunto todo em análise sofre segmentações em vários grupos, com base nas semelhanças encontradas. É uma técnica que permite dividir automaticamente um conjunto de dados em grupos de acordo com medidas de similaridade ou de distância. Existem diversas fórmulas para se obter medidas de similaridade, dentre elas podemos destacar o método do cosseno e a correlação de Pearson.

Dentre os métodos de clusterização podemos citar: o baseado em particionamento, baseado em densidade, o hierárquico aglomerativo e hierárquico divisório.

Para o Aprendizado por Reforço podemos citar os algoritmos:

  • Q-Learning;

  • Aproximação por função com atualização por gradiente; 

  • Multi-Armed Bandits;

  • Contextual Bandits;

  • k-Armed Bandits

Quer saber mais sobre algoritmos de Machine Learning? Entre em contato com a Viceri. Nós temos um time de especialistas sempre prontos para te ajudar!

Como reduzir custos com a AWS

Veja como a nuvem pode deixar sua infraestrutura mais enxuta e fazer você economizar

Reduzir custo na infraestrutura de um sistema é essencial, sobretudo em um momento como este em que qualquer corte de gastos é muito bem-vindo. Neste cenário, a nuvem entra como uma forma de deixar a sua infraestrutura mais enxuta, desde mecanismos de monitoramento, passando pela possibilidade de desligar o equipamento em momentos ociosos, até reservar máquinas para conseguir descontos. 

A AWS, Amazon Web Services, oferece uma infraestrutura sob demanda, para  que você pague apenas pelo que consumir. Isso quer dizer que você tem uma redução de custos a longo prazo e economiza uma quantidade dinheiro que pode ser usado para investimento em inovação e novas oportunidades.

Pague apenas o que usar

A AWS oferece algumas modalidades de virtualização de máquina. Dentre essas modalidades existe on-demand  que, como o próprio nome já diz, é a modalidade sobre demanda. Isso significa que você vai pagar somente o que tiver utilizando efetivamente. 

Se a sua aplicação precisar de uma visita apenas durante os dias de semana, você pode deixar a sua máquina parada durante o final de semana. Considerando um mês de trinta dias e quatro finais de semana, teríamos oito dias com a máquina parada sem gerar custo. Isso equivaleria a uma economia de aproximadamente 25%. Agora, imagine se sua aplicação ficar online apenas em horário comercial, o desconto seria muito maior e poderia chegar a 70%.

Tabela de redução segundo a AWS. Fonte: aws.amazon.com/pt/economics

Calculadoras de custo total de propriedade da AWS

A calculadora de TCO, Custo Total de Propriedade, da AWS permite que você faça uma estimativa sobre a redução de custo ao usar a plataforma. A AWS oferece relatórios detalhados inclusive para apresentações executivas. A calculadora permite modificações e suposições de acordo com suas necessidades da sua empresa. Neste ambiente você pode comparar o custo da execução das aplicações ou de hospedagem tradicional com o custo da execução na AWS. 

Processo automatizado 

É possível realizar o agendamento de parada e inicialização de recursos automaticamente, sem a necessidade de intervenção manual para realizar o procedimento todos os dias, evitando mão de obra e dando garantias de sempre acontecer, removendo os riscos de possíveis esquecimentos humanos. 

Uma das possibilidades é utilizar o CloudWatch como gatilho, criando uma regra em determinado horário para uma função lambda. Essa função lambda, por sua vez, consome SDK da AWS e oferece todos os comandos para você desligar o EC2 ou RDS. É uma solução bem utilizada e fácil de implementar.

Outra forma, ainda mais fácil, é utilizar uma solução já existente: o AWS Instance Scheduler. Ela facilita as paradas tanto das máquinas EC2 quanto RDS. Internamente o uso não é diferente da função anterior, ele usa o CloudWatch e a lambda, além disso, para armazenar alguns valores ele utiliza o DynamoDB. É uma boa solução caso você não queira fazer sua própria função lambda. Porém, vale ressaltar que você é responsável pelo pagamento de cada serviço utilizado na solução, então haverá aumento de consumo nos serviços mencionados acima.

Uma terceira possibilidade é configurar a instância na hora de criar a máquina dentro de um auto scaling group. Isso dará a possibilidade de configurar a quantidade de instância desejável em um determinado horário. Na hora de configurar você pode usar uma fórmula de cronograma como os usados no gatilho do CloudWatch e determinar dia e horário.

Cuidado para não perder seus dados! 

Alguns cuidados precisam ser tomados ao utilizar um processo automático de desligamento de máquinas EC2. Podem surgir problemas quando aplicações críticas estão rodando algum processo long-running em background e são paradas abruptamente. Se a sua aplicação mantém algum tipo de estado não persistido (deixado em memória, por exemplo), você fatalmente perderá essas informações. Se a sua aplicação não estiver tratando operações como atômicas, ou seja, transacionando no banco de dados, pode acabar gerando inconsistência na base.

Se a sua aplicação usa algum meio de persistência local como o próprio EBS, é importante que você apenas pare a aplicação e não a finalize. Quando você finaliza, acaba perdendo todas as informações do disco local. 

◼️ Leia também: O manual da segurança de dados na AWS e as responsabilidades compartilhadas

Atenção ao limite de dias para parar sua instância RDS

Atualmente existe um limite máximo de sete dias que você pode manter seu banco de dados parado, depois disso ele automaticamente irá iniciar novamente. Como já falamos, quando ele está parado não há cobrança, mas há limitações: no banco de dados postgres, ao usar um banco read replica não é possível parar o banco primário até que seja excluído o banco de réplica. Isso significa um aumento expressivo no tempo de inicialização nestes casos.

Apesar do tempo de inicialização ser maior, financeiramente pode valer a pena. O tempo de inicialização irá aumentar porque será preciso recriar o banco sempre que iniciá-lo novamente. Pode levar dez, vinte minutos, mas caso seu banco fique ocioso durante um longo período, financeiramente pode ser muito vantajoso

Outras formas de reduzir custos com a AWS também são possíveis. Vamos considerar um serviço que roda em background e que a cada 5 horas realização uma operação no banco de dados. Isso significa que ele ficará ocioso por 5 horas, depois irá trabalhar durante alguns segundos, para ficar ocioso novamente durante outras 5 horas.

Considerando a atividade descrita acima, é válida a criação de uma AWS lambda, onde você será cobrado apenas pelo tempo que executar o processamento da rotina.Uma solução bem interessante quando se tem vários serviços que rodam de tempos em tempos.

Presença global por um preço acessível ao bolso

A AWS tem uma presença global que permite repassar a economia para quem compra esse serviço de maneira contínua. São diversas opções de pacotes e serviços que podem oferecer economia de 75% a 90% das taxas sob demanda se for escolhida a capacidade pré-adquirida ou capacidade reserva.

Como já falamos anteriormente, na AWS não é preciso fazer compromissos com gastos mínimos ou contratos de longa duração. Você pode substituir as despesas iniciais por pagamentos que se aplicam apenas àquilo que você necessita. Nada de contratos ou modelos complexos que dificultam seu dia a dia. 

Ficou interessado? A Viceri tem uma equipe pronta para fazer a migração do seu banco e colaborar em tudo que você precisar durante o processo. Fale com a gente!

Como transformar seu monolito em microsserviço

Transformar uma aplicação monolítica em microsserviços poder ser uma tarefa muito complexa. Conheça alguns caminhos possíveis de se seguir quando estiver refatorando sua aplicação monolítica

Transformar uma aplicação monolítica em microsserviços é uma forma de modernizar a aplicação.

E se você trabalha com tecnologia, deve saber que o processo de transformar uma aplicação monolítica em microsserviços é uma tarefa muito complexa e delicada. Exige tempo e paciência de todos os envolvidos. 

A arquitetura monolítica é uma arquitetura tradicional de desenvolvimento de sistema de software.

Ela se baseia no princípio de que todos os processos dentro de uma mesma solução estão ligados. Isso quer dizer que são acoplados, que estão dentro de uma base de dados similar e executam seus processos como um único serviço. 

Já a arquitetura de microsserviços veio para solucionar problemas enfrentados pela arquitetura monolítica.

É um modelo que desenvolve pequenos serviços que realizam funções independentes.

Por serem independentes, podem atender demandas específicas em uma solução maior. É um processo menos tradicional que a arquitetura monolítica. 

Primeiros passos para refatorar uma aplicação 

Para que a migração de uma para a outra se torne uma tarefa mais simplificada, existem alguns caminhos possíveis de se seguir quando estiver refatorando sua aplicação monolítica.

A primeira dica é não fazer uma reescrita total da sua aplicação. Ou seja, esqueça a ideia de direcionar todos os esforços do time para reescrever a aplicação do zero.

Isso é extremamente arriscado e geralmente resulta em problemas que acabam levando mais tempo que o planejado. 

Vá devagar! O mais recomendado é refatorar aos poucos sua aplicação monolítica. Construa uma aplicação de forma incremental, rodando cada novo microsserviço em conjunto da aplicação original.

Com o passar do tempo, a quantidade de funcionalidades implementadas em microsserviços vai mostrar que o monolito encolheu tanto que em algum momento ele deixará de existir.

Quando sua aplicação monolítica se tornar ingerenciável, deve-se parar de tornar seu monolito maior.

Se você tiver de implementar uma nova funcionalidade, não adicione esse código ao monolito. Ao invés disso, a melhor estratégia é colocar o novo código em um microsserviço próprio para isso.

Glue Code

É neste cenário que surge o Glue Code, que são as dependências responsáveis pelo acesso aos dados.

Geralmente o serviço usará bibliotecas e componentes de acesso a dados da sua aplicação original.

O glue code  é chamado também de camada anti-corrupção, já evita que o microsserviço seja poluído com problemas da aplicação legada.

Desenvolver uma camada anti-corrupção não é algo muito comum, mas é essencial quando se quer manter uma aplicação confiável.

Com isso em mente, esse Glue Code pode seguir três estratégias:

– Invocar uma API remota, fornecida pelo monolito;

– Acessar a base de dados do monolito diretamente;

– Manter sua própria cópia da base com parte dos dados necessários para o microsserviço, que estará sincronizada com a base do monolito. 

E o que acontece ao implementarmos novas estratégias? 

Implementar novas funcionalidades como um microsserviço tem uma série de benefícios.

Essa estratégia impede que seu monolito se torne cada vez mais ingerenciável, ao mesmo tempo que permite que o serviço possa ser desenvolvido, implantado e escalado de maneira independente do monolito.

A cada novo serviço criado, será experimentado um pouco mais dos benefícios desta arquitetura.

Entretanto, essa abordagem não acaba com todos os problemas do monolito. Para tentar consertar esses problemas, é necessário quebrar o monolito em partes cada vez menores.

Outra estratégia que ajuda a encolher a aplicação monolítica é separar a sua camada de apresentação da lógica de negócio e do acesso a dados.

Geralmente existe uma separação muito clara entre a camada de apresentação e as camadas de regras de negócio e dados.  E isto é o que permite fazer a separação do seu monolito em duas aplicações menores.

Uma aplicação será o frontend, e a outra o backend. Uma vez separados, o frontend fará chamadas independentes ao backend.

Separar um monolito dessa maneira permite que o time desenvolva, implante e escale duas aplicações de maneira independente.

Essa estratégia, no entanto, é somente uma solução parcial. É bem comum que você troque um problema enorme por dois problemas menores, mas que no contexto geral ainda são um problemão a ser resolvido.

Você terá de usar uma outra estratégia para eliminar os monolitos restantes.

Essa outra estratégia é transformar os módulos existentes dentro de um monolito em microsserviços.

Cada vez que você extrai um módulo e o transforma em um serviço, o monolito encolhe. Uma vez que tenha sido convertido muitos módulos, o monolito deixará de ser um problema. Ou ele irá sumir ou vai acabar virando um microsserviço.

Converter um módulo em microsserviço requer tempo e paciência 

Uma aplicação monolítica grande geralmente terá dezenas ou centenas de módulos, todos dispostos a serem extraídos.

Saber quais módulos converter primeiro pode ser desafiador. Uma boa abordagem é começar com alguns módulos que são fáceis de extrair.

Converter um módulo em um microsserviço é algo que requer tempo. Uma dica é priorizar módulos que mudam com frequência.

Isto trará experiência com arquitetura de microsserviços e com o processo de extração.

Depois que você extrair esses módulos mais fáceis, poderá partir para os mais complexos.

Uma vez que você tenha convertido um módulo desses para um serviço, você pode desenvolver e implantar ele de maneira independente do monolito, o que vai acelerar o desenvolvimento.

Outra abordagem interessante é extrair os módulos que possuem requisitos diferentes do resto da aplicação.

Por exemplo, pegar aquele módulo que utiliza recursos específicos do servidor como muita memória ou CPU. Conforme você vai extraindo estes módulos específicos, você vai ver como se tornará mais fácil escalar os microsserviços.

O primeiro passo ao extrair um módulo é definir a interface entre o módulo e o monolito.

Geralmente será um contrato bidirecional, pois é comum o monolito precisar de dados do microsserviço e vice-versa.

Se a lógica de negócio do monolito estiver muito acoplada, talvez seja difícil de extrair apenas o necessário para o microsserviço, então é possível que uma refatoração interna no monolito seja necessária para continuar avançando com essa extração.

Uma vez que você tenha extraído um módulo, é mais um serviço que permite ao time desenvolver, implantar e escalar mais facilmente do restante do monolito.

Sendo possível, inclusive, reescrever este serviço do zero mais tarde, uma vez que o módulo já foi isolado.

Cada vez que você extrair um novo serviço, estará um passo mais perto de ter uma aplicação 100% em microsserviços.

Com o passar do tempo, seu monolito encolherá e a virada de chave entre as arquiteturas se tornará algo natural.

Quer saber mais como sua empresa pode aplicar isso na prática? A Viceri conta com especialistas que podem te ajudar. Fale com a gente!

Outsourcing de TI: como a Transformação Digital está mudando a relação entre CIOs e fornecedores de tecnologia

Tempos de crise são momentos em que aparecem soluções disruptivas e inovadoras, afinal, a necessidade é a mãe da criatividade e da adaptação. Falar de Covid-19 é chover no molhado, mas este momento é mais do que oportuno para refletir sobre as formas de trabalho que utilizamos até então.

Falando especificamente da área de TI, de uma hora para outra, ela foi obrigada a rever toda sua infraestrutura e os recursos disponíveis para deslocar a força de trabalho do escritória para a casa, executando as atividades em home office. Muitas empresas não estavam preparadas para o trabalho remoto, não tinham aprendido como fazer isso, nem estabelecido políticas corporativas para esse caso, tampouco processos e procedimentos adequados para essa prática.

Nesse cenário, alguns questionamentos são inevitáveis para os CIOs: “E se talvez eu tivesse terceirizado meu setor de desenvolvimento? Hoje teria apenas que administrar contratos com meus provedores, sem a preocupação com uma equipe própria tão grande, trabalhando remotamente, fornecendo infraestrutura para tal e pensando em ações para manter a saúde física e emocional de cada um deles. Tudo isso seria um problema do meu provedor, e assim estaria focado em resolver problemas do negócio, em como superar a crise e o que fazer quando ela passar.”

Neste sentido, fazemos aqui uma provocação quanto a pensar na possibilidade de outsourcing de TI em algumas das atividades de tecnologia da sua empresa. Antes tarde do que nunca.

Para tal, CIOs precisam refletir sobre o seu relacionamento com seus atuais fornecedores de TI. Nessa linha de raciocínio, questões importantes estão surgindo sobre o papel dos provedores de TI, que têm sido um dos pilares do cenário tecnológico nas últimas duas décadas. Eles estão mesmo colaborando com a inovação da sua organização? Eles oferecem as economias de custo prometidas? Eles estão gerando resultados estratégicos ou estão apenas cumprindo metas? Essas questões são cruciais para garantir que a sua corporação acompanhe a inovação e, ainda, mantenham seus sistemas legados.

No mundo digital, a tecnologia não é mais um facilitador, mas um ativo estratégico e uma vantagem competitiva. Empresas que não a priorizarem não sobreviverão. Os CIOs estão no comando dessa jornada de transformação digital e estão sob crescente pressão para fornecer os recursos de tecnologia que permitam às empresas gerar valor.

Esse desafio está levando os CIOs a redefinirem como se envolvem, e o que esperam de seus fornecedores de TI. Em um estudo recente realizado pela McKinsey com 250 CIOs globais e tomadores de decisão em tecnologia, chama a atenção uma definição trazida por um dos entrevistados: “Dada a escassez de talentos capazes internamente, nossos recursos estão focados em trabalhar com os provedores de TI para definir o problema e, em seguida, fazer parceria com eles para executar”, comenta.

Esse relacionamento em evolução com os provedores de TI aparece em outros pontos da pesquisa. Mais da metade dos líderes de TI acredita que “não há outra maneira” de atingir suas metas de transformação digital sem uma estreita relação com seus provedores de TI. A pesquisa e as entrevistas apontam para um papel ativo dos fornecedores de tecnologia ao longo da jornada de transformação digital de muitas empresas. No entanto, o foco, expectativas, e os atores que moldam esse papel, diferem significativamente daqueles que foram considerados o padrão no passado.

Conforme o estudo, o gráfico abaixo demonstra os principais motivos que levam os líderes de tecnologia a pensar num outsourcing de TI para as atividades de suas empres. Confira:

(Fonte: McKinsey)

Embora o custo seja uma das principais razões pelas quais a maioria das empresas está ou irá trabalhar com fornecedores de TI, outros fatores estão ganhando importância agora. Acesso ao talento e inovação são fatores cruciais para influenciar nessa decisão. Além disso, a capacidade de se engajar com a empresa contratante é citado com um fator-chave para a escolha do provedor de TI por 60% dos CIOs entrevistados.

Em resumo, você precisa de provedores que tragam valor ao negócio, ou seja:

  • Apoiem e executem a transformação digital;
  • Permitam redução de custos globais da sua empresa (talentos, infraestrutura, espaço físico, etc);

  • Impulsionem a inovação para o negócio de sua empresa como um todo;

  • Proporcionem essa inovação para a própria área de TI;

  • Entreguem resultados para o seu negócio;

  • Tragam talentos e know-how uptodate para a sua organização.

Frente ao aumento do escopo e das responsabilidades envolvidas, cada vez mais os CIOs estão compartilhando a decisão e a escolha de provedores de TI com seus líderes das áreas de negócios. Pesquisas mostram que, atualmente, mais da metade das decisões em relação ao tema são tomadas conjuntamente ou diretamente pelo líder da área de negócios.

Conforme outro estudo da McKinsey, as lideranças de TI precisam estabelecer uma relação de parceria com as áreas de negócios, compartilhando metas, responsabilidades e prestação de contas. De acordo com a pesquisa, empresas que estabelecem esse tipo de alinhamento estratégico têm mais chances de sucesso na Transformação Digital e mais capacidade de gerar impacto no mundo dos negócios.

Assim, cabe às áreas de negócios incluir a tecnologia e a escolha de seus fornecedores como um dos pilares estratégicos da organização, bem como cabe ao CIO se posicionar como líder estratégico para se relacionar com um provedor de TI que realmente criará impacto na sua corporação.

E quem escolher? Atualmente, fornecedores de “nicho” vem conseguindo mais espaço nas grandes empresas, se comparado aos grandes integradores de TI do passado. Embora trabalhar com esse tipo de serviço talvez seja mais complexo, tanto na escolha quanto no gerenciamento, os resultados geralmente justificam.

Então, se você ainda não pensou em ter um parceiro de Outsourcing de TI na sua área de tecnologia, aproveite o momento para planejar como faria isso após a retomada normal das atividades.

**Washington Fray é Diretor de Vendas e Marketing da Viceri, empresa de tecnologia com mais de 29 anos de mercado que atua para estabelecer alianças duradouras e provocar grandes transformações através da inovação e da tecnologia. Em seu portfólio, a instituição tem como clientes algumas das maiores empresas do Brasil como a Mapfre Seguros, Brinks, Brasilprev e Instituto Unibanco.