Quem mantém os fluxos depois do go-live: autonomia ou execução assistida

Em toda negociação de plataforma de risco, TI e Compliance acabam fazendo a mesma pergunta: quem customiza os fluxos e quem cuida deles depois do go-live?

A TI pergunta porque não quer herdar mais um sistema. O time já cuida de integrações com birôs, da esteira de onboarding e de regras espalhadas pelo código, e tem medo de que a configuração na mão da área de negócio vire sobrecarga para a tecnologia. Por isso muita TI acaba segurando essa demanda mesmo sem querer, e a fila vira uma forma de proteção.

Para o Compliance, essa mesma fila é um bloqueio, porque cada ajuste de regra que depende de chamado é uma semana de exposição e menos controle sobre um processo pelo qual ele responde ao regulador.

Cada um quer ouvir uma resposta diferente, mas a dor é a mesma: depender de uma área que tem outra prioridade. A seguir explicamos os dois modelos possíveis, o que cada um pede de cada área e o que precisa existir para que os dois sejam seguros.

Em resumo

Na prática são dois caminhos: ou o compliance mantém as regras direto na plataforma, sem código e sem chamado, ou a VAAS faz os ajustes a partir da política que vocês definem. Nos dois, a TI fica só com as integrações, a VAAS cuida da plataforma e qualquer ajuste é testado antes de ir para produção, com a opção de voltar atrás.

Os dois modelos de sustentação

Modelo 1: o cliente mantém, em low-code 

Regras, cenários e matrizes de risco ficam com o compliance no Workflow Builder, o editor da plataforma, e criar ou ajustar uma regra não pede código nem chamado.

O que exige do time: alguém que conheça a política de risco, assuma a manutenção das regras e entenda por que cada critério existe, sem precisar ser técnico. Essa pessoa também precisa saber quando não mexer, porque fontes demais, regras complexas demais ou testes com poucos casos são o jeito mais comum de uma boa intenção piorar a operação. O resultado aparece em mais tempo de processamento, mais alertas para analisar e decisões mais difíceis de explicar na auditoria.

Quando a pessoa que sabe sai: é o ponto que decide o modelo e quase ninguém pergunta. Com as regras no editor, quem chega vê o que existe, quem alterou e quando, mas se o raciocínio estava só na cabeça de quem configurou, ele vai embora junto. A plataforma guarda o registro, só não substitui uma política documentada.

Resposta a incidente: no mesmo dia e sem fila. Se aparece uma tipologia nova, quem entende do risco ajusta, testa e publica.

Para a TI: as regras saem do backlog e o medo de sobrecarga passa a ser resolvido com controle em vez de fila. Toda mudança é testada antes de publicar, o processamento roda na nuvem da VAAS e a TI segue dona das integrações, não do conteúdo da política.

Para o compliance: controle total, junto com a responsabilidade.

Modelo 2: a VAAS assume a configuração 

 A instituição define a política e o fornecedor cuida da implementação, dos ajustes e da manutenção. 

O que exige do time: saber explicar o que precisa e validar o resultado com casos reais. Esse aceite não pode ser formalidade, porque é nele que vocês confirmam que o que foi configurado é o que vocês quiseram dizer.

Quando a pessoa que sabe sai:  o risco muda de lugar. A configuração continua registrada e a execução não depende de ninguém de dentro, mas aparece outro risco, o de a especificação ser entendida de outro jeito e a regra ir para produção com esse desvio. A proteção é ter a política bem documentada e validar antes de publicar, e é essa documentação que evita que o próximo pedido de ajuste parta de uma interpretação. 

Resposta a incidente: de algumas horas ao mesmo dia, dependendo da complexidade. A velocidade passa a ser a da fila do fornecedor, que é curta mas existe, então vale combinar um prazo para urgências já na implantação.

Para a TI:  nada além das integrações que já estavam planejadas, e sustentação e performance ficam com o fornecedor. 

Para o compliance: a decisão continua sendo sua, mas a execução não, e isso pesa se a política muda toda semana.

O que a VAAS assume em qualquer cenário 

Seja qual for o modelo, a VAAS cuida da performance e da estabilidade da plataforma, faz a implantação inicial com fluxos, matriz de risco e integrações e, em geral, assume os ajustes estruturais, como incluir uma fonte de dados nova ou redesenhar um fluxo. Como esses ajustes são os que mais mexem com desempenho e volume, eles pedem a participação da VAAS mesmo no modelo interno. No modelo assistido os ajustes do dia a dia também ficam com a gente, e a única coisa que nunca sai da instituição é a definição da política de risco.

Dá ainda para combinar os dois modelos. O que funciona é dividir por frequência, e não por complexidade: o que muda toda semana fica com quem decide e o que muda uma vez por trimestre pode ficar com o fornecedor.

O que torna a manutenção segura 

Antes de decidir quem mantém, vale responder outra pergunta: mexer na configuração pode quebrar o que está em produção? Se puder, nenhum dos modelos é seguro, e são quatro mecanismos que evitam isso.

Teste antes da publicação: Um comprador contou que, no sistema que usava, cada deploy apagava os rascunhos de regra do compliance sem aviso e sem como recuperar, porque não havia separação entre o que estava em construção e o que estava em produção. Na plataforma, regras e workflows são testados antes e a produção só muda quando alguém publica. O teste só protege se for bem dimensionado, já que poucos casos não mostram como a regra se comporta no volume real.

Versionamento: Toda versão publicada fica registrada e cada decisão guarda a versão da regra que a gerou, então dá para saber qual regra estava no ar em qualquer data, uma pergunta comum em auditoria.

Usuário administrador e acessos nominais: Cada pessoa entra com o próprio usuário e um perfil administrador define quem pode alterar e publicar. Assim fica a trilha de quem mudou o quê, e a TI participa da definição de quem publica sem ter que executar cada alteração.

Reversão: Dá para voltar à versão anterior sem reconstruir nada, e é isso que faz um erro de configuração durar minutos em vez do tempo de refazer tudo do zero.

Com esses mecanismos, os riscos de cada modelo ficam sob controle e a escolha passa a ser uma questão de operação. Teste e reversão protegem tanto contra a regra mal calibrada pelo time quanto contra a regra mal traduzida pelo fornecedor.

“Não temos braço para implementar” e “vamos precisar de um recurso dedicado”  

Essas duas objeções costumam aparecer juntas e são as que mais adiam a decisão. A resposta está em separar o esforço de começar do esforço de manter.

A VAAS faz a implantação e os ajustes: Fluxos, matriz de risco e integrações são configurados pela VAAS, e a instituição só define a política e valida o resultado com casos reais. Se depois do go-live ninguém assumir a manutenção, os ajustes continuam no modelo assistido.

Dá para começar antes de integrar: O compliance já usa a plataforma direto, e a integração com os sistemas internos entra quando couber no roadmap de tecnologia. Isso tira o projeto da fila de desenvolvimento, que é o que normalmente empurra a decisão para o trimestre seguinte, e a plataforma não entra no backlog da TI logo no primeiro dia.

Recurso dedicado não é pré-requisito: Analisar casos e revisar alertas é o que o time já faz hoje, só que agora numa tela só. Um responsável dedicado só faz sentido se vocês mantiverem as regras e a política mudar com muita frequência, e mesmo assim costuma ser alguém do time atual, não uma contratação nova.

Três perguntas para decidir o modelo

Vale fazer estas perguntas com TI e Compliance na mesma sala.

1. Quem vai ser dono da política configurada? Se a resposta tem nome, manter internamente é viável. Se não tem, o caminho honesto é começar no modelo assistido e fazer a transição depois.
2. Com que frequência a política de risco muda? Se muda toda semana, vale ter autonomia. Se muda a cada trimestre, não precisa.
3. O que fica registrado se quem configurou sair? Faça essa pergunta a qualquer fornecedor. A resposta que interessa fala de histórico, versionamento e documentação, e não de reter pessoas.

Autonomia, aqui, é ter o controle à mão sem precisar carregar tudo sozinho.

Perguntas frequentes

Quem customiza a plataforma: nós ou vocês?

Na implantação somos nós. Depois do go-live, isso pode ficar com o seu time no Workflow Builder ou continuar com a gente, dependendo de ter alguém interno disposto a ser dono das regras.

Como mantenho os fluxos depois da implantação?

Ou o seu time ajusta, testa e publica direto no editor, ou a gente faz os ajustes a partir da política de vocês. Em qualquer caso, toda alteração fica versionada e pode ser revertida.

E se precisarmos alterar uma política com urgência?

Pode acontecer por causa de uma norma com vigência imediata, uma fraude em curso ou um apontamento de auditoria. No modelo interno o seu time resolve no mesmo dia, e no assistido vale o prazo combinado na implantação. O ideal é deixar claro desde o começo o que conta como urgente, quem pode pedir e em quanto tempo a mudança entra em produção. Se urgência é algo frequente na operação, o modelo híbrido costuma funcionar melhor, com o seu time ajustando as regras e a gente cuidando do que é estrutural.

Não temos equipe para implementar. Isso inviabiliza?

Não. Quem faz a implantação somos nós, e a plataforma pode ser usada antes de qualquer integração, então o seu time só precisa definir a política e validar o resultado.

Precisamos de um recurso dedicado para operar a plataforma?

Para começar, não. Só faz sentido se vocês decidirem manter as regras internamente e a política mudar com muita frequência.

Se alguém alterar uma regra, a produção pode quebrar?

Pode, se a mudança for mal calibrada, e é justamente por isso que a regra é testada antes, só entra em produção quando alguém publica e pode voltar para a versão anterior. O que nenhuma ferramenta resolve é um teste feito com poucos casos.

Se o compliance configurar sozinho, isso sobrecarrega a TI?

O medo da TI costuma ser uma mudança ir direto para produção e o problema aparecer depois. Como a regra é testada antes de publicar, o processamento roda na nossa nuvem e as integrações continuam com a TI, esse risco fica sob controle. O recomendado é combinar entre as duas áreas, já na implantação, quem pode publicar e quais mudanças passam por avaliação técnica.

E se a pessoa que configurou os fluxos sair da empresa?

As regras continuam no editor, com o histórico de quem alterou o quê e quando. O que a plataforma não substitui é a política de risco documentada, que segue sendo responsabilidade de vocês.

Sustentação faz parte do produto

Na VAAS, a sustentação faz parte do produto: a implantação é conduzida pelo nosso time, a performance da plataforma é responsabilidade nossa e o modelo de manutenção é escolha de vocês, podendo mudar conforme o time amadurece. Assim a TI não herda mais um sistema, o compliance para de depender de chamado para mudar uma regra e cada alteração fica registrada para quando a auditoria perguntar.

Ainda não sabe qual modelo cabe na sua operação?

Traga TI e Compliance para essa conversa, fale com a gente ou acesse nosso site.