Construindo uma função bancária de tíge de ponta

O banco está revisando agressivamente sua função de TI, com o objetivo de fornecer mudanças de etapas na eficiência, qualidade da produção e atratividade da função. O CIO da empresa, Ron Van Kemenade, conversou recentemente com o parceiro sênior do BCG, Hanno Ketterer, sobre o Genesis do esforço, as tecnologias e metodologias empregadas e os desafios até o momento. Os trechos editados da discussão a seguir. O que o estimulou a iniciar essa transformação? Mas, mais provavelmente, eles sofreriam de falta de consistência, financiamento, apoio e comprometimento. Também determinamos que precisávamos tomar medidas significativas para apoiar a estratégia "Pensar adiante" do banco. É por isso que criamos o Programa de TI Power.

ING Bank is undertaking a massive technology transformation, which you’ve termed “Power IT.” What spurred you to initiate that transformation?

In 2013, we came to the conclusion that any separate initiatives we might undertake to improve our quality, cost, and engineering capabilities might indeed lead to substantial impact. But more likely, they would suffer from lack of consistency, funding, support, and commitment. We also determined that we needed to take significant steps to support the bank’s “Think Forward” strategy. This is why we created the Power IT program.

Lançamos o programa com três objetivos gerais. Primeiro, queríamos criar uma melhor organização de TI da categoria em relação aos nossos colegas, que nos tornaria o empregador preferido de talento na Holanda. Segundo, queríamos melhorar substancialmente nossa qualidade. Terceiro, queríamos reduzir nossos custos. Na época do lançamento, estávamos longe de onde queríamos estar nessas frentes. Não éramos o empregador de TI mais preferido no mercado, por isso basicamente lutamos para contratar engenheiros altamente qualificados. Nossa qualidade, medida em tempo de mercado, também ficou aquém - não éramos ágeis o suficiente. E nossos custos estavam bem acima de nossos benchmarks.

Muitos bancos europeus lançaram iniciativas projetadas para reduzir custos. Como você convenceu o conselho da Ing a apoiar um programa tão abrangente, que também implica investir em talentos e novas tecnologias?

A pergunta "como" não é fácil de responder. Mas deixe -me explicar um pouco do raciocínio por trás do design do programa. Existem custos associados a tudo o que você faz, seja comprando uma máquina cara, contratando um engenheiro interno ou fazendo as coisas de uma maneira específica. Também existem benefícios associados. Nosso objetivo não era simplesmente reduzir os custos, mas garantir que o dinheiro que gastamos ofereça o máximo valor. Sempre poderíamos reduzir os custos, digamos, adquirindo mais trabalho para a Índia. Mas isso não abordaria o fato de que nossos engenheiros não são tão produtivos quanto precisamos deles. Também poderíamos cortar custos terceirizando nossos data centers ou espremendo o último dólar de nossos fornecedores. Mas essas etapas não abordariam as causas subjacentes de nossa ineficiência. Eles também não nos tornariam um lugar melhor para trabalhar. Eles também não reduziriam a complexidade de nossa paisagem ou melhorariam nossos processos. Sabíamos, porém, que abordar essas causas principais também proporcionaria benefícios relacionados substanciais. Nossa qualidade melhoraria, assim como nossa atratividade como empregador. Se você possui uma pilha de tecnologia simplificada, processos totalmente automatizados e uma maneira ágil de trabalhar - e se novos contratados começarem a trabalhar com colegas altamente qualificados - sua empresa se tornará um lugar atraente para trabalhar. Se você aumentar a qualidade, reduzirá o custo. Se você automatizar e tornar seus processos mais ágeis, evitará o desperdício e se tornará mais eficiente. Se você contratar engenheiros altamente qualificados, se tornará mais produtivo. 

Ultimately, we determined that the root causes of our costs were the complexity of our technology stack, the degree of automation of our processes, and the productivity (read: knowledge and skills) of our engineers. We knew, though, that addressing these root causes would also deliver substantial related benefits. Our quality would improve, as would our attractiveness as an employer. If you have a simplified technology stack, fully automated processes, and an agile way of working—and if new hires get to work with highly skilled peers—your company becomes an attractive place to work.

So we actually took the root causes of cost and made them the purpose of our program, since they go hand in hand. If you increase quality, you reduce cost. If you automate and make your processes more agile, you avoid waste and become more efficient. If you hire highly skilled engineers, you become more productive.

ING’s transformation has involved the use of cutting-edge technologies and approaches, such as using private clouds, switching to APIs, and implementing  ¹ 1 "API" significa interface do programa de aplicativos. "DevOps" é a prática de fazer com que os engenheiros de desenvolvimento e operações trabalhem juntos durante todo o ciclo de vida de uma aplicação. Você pode elaborar algumas delas e explicar por que você acha que elas podem tomar o Int para o próximo nível? Poderíamos ter decidido consolidar em apenas uma plataforma e garantir que ela seja virtualizada, o que nos daria o benefício do hardware otimizado. Ou poderíamos ter ficado com nossa arquitetura baseada em SOA, mas não expor imediatamente a funcionalidade através do

We’ve made some bold choices. We could have decided to consolidate on just one platform and make sure that it’s virtualized, which would have given us the benefit of optimized hardware. Or we could have stayed with our SOA-based architecture but not immediately expose functionality through the Uso de APIs. ² 2 "SOA" significa arquitetura orientada a serviços. Ou poderíamos ter mantido nossa arquitetura atual para os vários canais e não construir em escala na Web. Mas decidimos que, uma vez que estávamos investindo muito na simplificação de nosso cenário e na consolidação de data centers, plataformas, sistemas operacionais e middleware-e desde que estávamos analisando uma viagem de três ou quatro anos de qualquer maneira-devemos fazer tudo o que é acima: construir uma nova plataforma digital que era baseada em nuvem e na Web e na mesma época. Obviamente, isso adicionou complexidade, bem como risco, ao programa. Mas acreditávamos que poderíamos lidar com isso e queríamos oferecer aos negócios os benefícios de uma pilha moderna em escala na Web o mais rápido possível. Considere, por exemplo, o descomissionamento do mainframe, que é provavelmente o melhor exemplo em que consigo pensar e um facilitador crítico de nós perceber nossa ambição. A descomissionamento é algo que basicamente todo mundo no mercado gostaria de fazer, embora eu não conheça muitas empresas, incluindo o ING, que o perceberam totalmente até o momento. Para descomissionar o mainframe, você precisa de um roteiro totalmente funcional. Isso não é fácil de criar, e certamente não foi para nós, já que tivemos um número significativo de aplicativos de negócios residentes em nosso mainframe. Para cada componente funcional, você precisa ter uma plataforma alternativa: se não houver destino, não existe uma estratégia de migração. E compensando um mainframe significa migrar todas as funcionalidades e interfaces. Portanto, você precisa ter suas melhores pessoas, aquelas com conhecimento de toda a organização, alocadas para construir esses roteiros funcionais, criar metas de migração e garantir que esses alvos estejam nos roteiros do negócio. Você precisa dividir a tarefa em etapas, com alvos específicos atribuídos a cada estágio. Todo mundo precisa saber que, digamos, o estágio três, que pode ocorrer na segunda metade do ano, o objetivo é migrar funcionalmente um número específico de aplicativos. No nosso caso, optamos por acelerar o descomissionamento de nosso mainframe, usando um ambiente de renovação que permite que o código COBOL resida em um mainframe seja executado em uma tecnologia de contêineres. O uso dessa tecnologia nos permitiu evitar aplicações totalmente refatoradas quando não havia plataforma de destino disponível para migrar. Esses elementos mostraram -nos igualmente valiosos para realizar outros marcos em nossa jornada.

Have there been specific tools, approaches, or methodologies that have helped you to achieve that end state, and which you would recommend to other CIOs undertaking similar journeys?

Moving toward this state has taken a combination of skills, methodologies, and sometimes technologies. Consider, for example, the decommissioning of the mainframe, which is probably the best example I can think of and a critical enabler of us realizing our ambition. Decommissioning is something that basically everybody in the market would like to do, though I don’t know of many companies, including ING, that have fully realized it to date. To decommission the mainframe, you need a fully functional roadmap. This is not easy to create, and it certainly wasn’t for us, given that we had a significant number of business applications residing on our mainframe. For every single functional component, you need to have an alternative platform: if there is no target, there is no migration strategy. And off-loading a mainframe means migrating all of the functionality and interfaces. So you need to have your best people, those with knowledge of the entire organization, allocated to building these functional roadmaps, creating migration targets, and making sure that those targets are on the roadmaps of the business.

A second necessary element for successful decommissioning is rigorous program management. You need to break down the task into stages, with specific targets assigned to each stage. Everyone needs to know that in, say, stage three, which might take place in the second half of the year, the goal is to functionally migrate a specific number of applications.

A third key element is the use of the right supporting technologies where necessary. In our case, we have chosen to accelerate the decommissioning of our mainframe by using a rehosting environment that allows COBOL code residing on a mainframe to run in a container technology. The use of this technology allowed us to avoid fully refactoring applications when there was no target platform available to migrate to.

We have combined these three elements—roadmapping, rigorous program management, and use of supporting technologies—and hope that they will do the trick. These elements have proved equally valuable to us in realizing other milestones on our journey.

Vamos passar da tecnologia para as pessoas. Usando o Spotify como inspiração, o ING também embarcou em um grande esforço de transformação para trazer uma maneira ágil de trabalhar para a organização de TI e os negócios. Qual foi a motivação para isso?

O objetivo final de criar um ambiente ágil é aumentar a capacidade de resposta aos clientes. O Agile certamente pode ser útil para redução de custos e para criar um processo melhor, no qual os engenheiros se sentem mais em casa. Mas, no final, você faz isso para seus clientes, sejam eles usuários externos ou internos. As necessidades e desejos desses clientes mudam de maneira regular e rápida em resposta a uma série de fatores, incluindo novas tendências, novos requisitos regulatórios e mudanças em outros setores. E os clientes exigem que você responda. Nossa antiga maneira de trabalhar não facilitou a capacidade de resposta necessária. Por isso, começamos a adotar metodologias ágeis em 2010, aplicando práticas "scrum" ao nosso processo de desenvolvimento. Esses primeiros passos de bebê envolveram apenas três equipes. Em 2011, lançamos ágeis em todo o desenvolvimento. Mas descobrimos que trabalhar de maneira ágil apenas em desenvolvimento não fazia muita diferença. As operações de TI também precisavam ser incluídas, pois é basicamente onde o Buck para antes de você entrar em produção. Por isso, também aplicamos ágil às operações e formamos nossas primeiras equipes de DevOps.

também envolvemos nossos colegas de negócios, pois consideramos o envolvimento deles crítico para realizar todos os benefícios que o Agile pode oferecer, dado o foco no cliente. Os negócios tiveram a oportunidade de liderar as equipes, decidir sobre prioridades e pedidos de atraso, fornecer feedback de ciclo curto e interagir com frequência-geralmente diariamente-com os engenheiros. O negócio então se encarregou de reorganizar de maneiras que quebraram silos e promoveram a propriedade e responsabilidade de ponta a ponta necessárias. Fazer essa transição-usando o Spotify e sua abordagem de equipes de características, baseada em "esquadrão" como modelo-forneceu altamente desafiadora para nossos colegas de negócios, especialmente culturalmente. Mas eu tiro meu chapéu para eles. Eles tinham coragem de fazê -lo. E o benefício para a empresa como um todo tem sido considerável, pois o banco agora é único na Holanda em comparação com muitos outros jogadores de serviços financeiros. Com base no que você aprendeu até agora, que conselho você daria a um CIO que planeja uma transformação semelhante?

The business recognized and appreciated the benefits of agile but was not organized optimally to take full advantage of what it could deliver. The business then took it upon itself to reorganize in ways that broke down silos and fostered the necessary end-to-end ownership and accountability. Making this transition—using Spotify and its “squad”-based, feature-team approach as a model—proved highly challenging for our business colleagues, especially culturally. But I tip my hat to them. They had the guts to do it. And the benefit to the company as a whole has been sizable, as the bank is now unique in the Netherlands compared with a lot of other financial-services players.

The Power IT transformation has been underway for roughly 21 months now. Based on what you’ve learned so far, what advice would you give a CIO who plans a similar transformation?

A maior lição que aprendemos até agora é que obter o alinhamento necessário na empresa pode ser um desafio; No nosso caso, isso se mostrou muito mais difícil do que esperávamos. As prioridades das equipes mudariam em resposta às demandas diárias e de curto prazo do trabalho, com o resultado que às vezes os projetos necessários para levar a transformação adiante-um descomissionamento de algo ou uma mudança de plataforma-desapareceriam ou seriam empurrados para baixo, os pedidos de atraso das equipes e, portanto, não foram feitos no tempo. Em resposta a isso, fizemos a mudança de ter o esforço liderado por uma equipe do programa, uma abordagem que apenas facilitou o gerenciamento de linha, para o gerenciamento de programas mais central. Agora, no caso de haver disputas sobre as prioridades das equipes, nosso grupo de CIOs, juntamente com nossos colegas de negócios, faz a chamada final. Esperamos que a energia se desenrolará dentro do cronograma como resultado desse ajuste.

, mas essa foi uma lição enorme para nós. Nós assumimos que o alinhamento ocorreria naturalmente porque as equipes veriam coisas de uma perspectiva em toda a empresa, em vez de apenas através das lentes de sua própria equipe. Mas aprendemos que isso só acontece em uma organização madura, que ainda estamos em processo de realização. 人材戦略