Há uma conversa que se repete nas implementações e começa sempre de forma parecida. Do outro lado está alguém que acabou de herdar um programa de sensibilização, pede acesso a uma plataforma que não configurou e descobre que a conta de administrador está em nome de uma pessoa que já não trabalha na organização.
O cenário de fundo é conhecido. Saiu quem sustentava o programa, a procura do substituto vai demorar alguns meses e, pelo meio, alguém tem de decidir o que acontece ao plano. Ninguém decide suspendê-lo. Simplesmente deixa de aparecer na lista de tarefas de alguém.
O custo vê-se mais tarde. Quando chega a auditoria e é pedida a atividade do período, há um trecho sem nada. Esse vazio não se explica com um organograma, e é exatamente o que quem audita vai assinalar.
A continuidade do programa de sensibilização é a capacidade de continuar a atribuir atividade e a deixar registo mesmo quando ninguém o está a empurrar. Uma vaga em aberto durante três meses é a prova mais honesta que existe de saber se o teu programa a tem.
O que cai realmente quando sai a pessoa que geria o programa?
Convém separar três camadas, porque rompem em momentos diferentes e resolvem-se de maneiras diferentes.
A primeira é a operação. Alguém monta as campanhas, verifica quem não concluiu, responde ao email da área que pede um prolongamento. É a camada mais visível e aquela que todos assumem que se resolve distribuindo o trabalho entre quem fica.
A segunda é a titularidade técnica. A conta de administrador, o token que a integração com o painel da direção usa, a aplicação registada no fornecedor de identidade, o endereço a partir do qual saem os emails do programa, os destinatários dos relatórios automáticos. Tudo isso ficou ligado a uma pessoa em algum momento da implementação e ninguém o revisitou desde então.
A terceira é a série de evidência. Cada mês em que o programa atribuiu algo deixa um registo, e cada mês em que não atribuiu nada deixa um também, por ausência. Essa série é a única coisa que um terceiro consegue ler sem ouvir a explicação.
Distribuir a operação pela equipa, que é a primeira coisa que se tenta, cobre a primeira camada. A segunda não se nota até algo falhar. E quando falha, a terceira já tem o seu vazio.
Porque é que distribuir a tarefa pela equipa dura duas semanas?
A distribuição informal funciona enquanto o tema continua fresco. Depois começa a competir com trabalho que tem dono, e perde sempre.
Um incidente de segurança tem quem o reclame. Um requisito de auditoria tem data. Uma campanha de sensibilização que não foi enviada este mês não gera nenhuma chamada. Ninguém do negócio nota a diferença, a área que a ia receber agradece em silêncio e o indicador só se move dois trimestres depois. É a única tarefa da área cujo incumprimento não faz ruído no curto prazo.
O que se perde com a distribuição não é apenas atividade. É o critério. A pessoa que saiu sabia porque é que aquele grupo tinha uma campanha diferente, o que tinha acordado com a área de operações para não colidir com o fecho do mês e porque é que havia uma exceção em vigor. Quem chega para cobrir o cargo encontra um período sem atividade e, sobretudo, sem as razões. Reconstruir isso leva mais tempo do que executar o plano original.
O plano não cai por uma decisão. Cai porque deixou de estar na lista de alguém.
Que parte do programa de sensibilização pode continuar sem ninguém atrás?
A que já estava automatizada antes da vaga. Um programa automático de sensibilização é um conjunto de campanhas já sequenciadas que se atribuem sozinhas a um público durante um período de um a três anos, com configurações gerais e específicas que se definem uma vez. Enquanto houver público, continua a atribuir, com ou sem alguém a olhar para a consola.
Aí está a diferença prática face a um calendário montado à mão. O calendário manual precisa que alguém o execute todos os meses. O programa automático precisa que alguém o tenha decidido uma vez. Quando essa decisão já foi tomada, a vaga afeta a supervisão, não a entrega. Na SMARTFENSE esse é também o mecanismo por trás do plano de cumprimento que se executa sozinho todos os dias, que responde à mesma pergunta pelo lado da norma.
Há uma dependência que convém olhar, e é de onde sai o público. Um programa que se atribui sozinho sobre uma lista que alguém atualizava à mão torna-se, em poucas semanas, um programa que corre impecável sobre a organização do trimestre passado. Quem entrou durante a vaga não aparece em nenhuma atribuição, e o indicador continua verde porque o denominador também ficou velho.
Se a importação de utilizadores está automatizada contra o diretório corporativo, esse risco vai-se com a vaga. Se dependia de um ficheiro que alguém carregava todos os meses, a continuidade dura o que durar esse ficheiro. É o mesmo mecanismo pelo qual as novas admissões movem o cumprimento durante todo o ano, agravado por não haver quem olhe.
Convém dizer o que isto não resolve, porque apresentá-lo como uma resposta completa seria vender fumo. A automatização não negoceia com uma área que pede para adiar uma atividade, não interpreta um resultado estranho, não decide mudar a abordagem quando o contexto mudou e não trata a exceção da pessoa que esteve seis meses de licença. Tudo isso volta quando chega o substituto. O que a automatização garante é que volte a uma série contínua e não a um vazio.
O que ficou em nome de uma pessoa e não da organização?
Esta é a camada que quase ninguém revisita antes de precisar dela, e a que, como CTO, vejo falhar com mais frequência. Durante uma implementação as coisas criam-se depressa, com a conta que estava à mão, e essa conta é normalmente a de quem leva o projeto.
O que convém revisitar, idealmente antes de haver uma carta de saída em cima da mesa:
- A conta administrativa e a sua caixa de correio. Se o acesso está associado a um endereço nominal que os Recursos Humanos desativam no dia da saída, o programa perde o seu administrador no mesmo dia em que perde a pessoa.
- Os tokens das integrações. Um token criado por alguém não deixa de funcionar quando essa pessoa sai, e esse é o problema. Continua a andar quando já não devia, até alguém o rodar. Vale a pena revisitar com que credencial se autoriza cada integração e que âmbito tem, que é a parte que desenvolvi em o que deixa de se fazer à mão quando o programa tem API.
- A aplicação registada no fornecedor de identidade. O certificado de assinatura tem data de validade e alguém tem de estar a olhar para ela. Se essa data vive no calendário pessoal de quem montou a integração SSO, no dia em que expirar ninguém vai conseguir entrar e ninguém vai saber porquê.
- A entrega dos emails do programa. O endereço remetente e as regras que a equipa de correio configurou para que as mensagens cheguem estão normalmente documentadas no ticket de uma pessoa. Quando essas regras são tocadas por outro motivo, não fica ninguém que explique para que serviam.
- Os destinatários dos relatórios e das notificações. Se o relatório mensal chegava a uma caixa pessoal, deixa de chegar e ninguém reclama, porque quem o reclamava era o seu único leitor.
- O contacto técnico junto do fornecedor. Quem recebe os avisos de manutenção e quem pode pedir uma alteração tem de ser um papel declarado, não um nome herdado.
A regra prática é simples. Nada do programa deveria depender de uma caixa de correio pessoal, e cada integração deveria ter um dono declarado que seja um cargo e não uma pessoa. Sobre os dados, essa titularidade já está resolvida por contrato, porque a organização é a responsável pelo tratamento e conserva os seus direitos sobre a informação mesmo quando muda quem a administra, conforme o que deixámos escrito sobre conservação e residência. O que não está resolvido por contrato são os acessos, e esses revisitam-se à mão.
O que se mede?
Meses consecutivos com atividade atribuída. É o indicador que responde à pergunta real do trimestre, que não é quanto melhorou o programa mas se o programa continuou a existir.
Lê-se de seguida sobre o calendário do ano. Uma série sem cortes diz que a atribuição não dependia de ninguém em particular. Um corte de três meses que coincide com uma vaga diz o contrário, e di-lo com uma precisão incómoda.
Este indicador precisa de um acompanhante para não se tornar trivial. Junto aos meses consecutivos há que olhar para a percentagem do efetivo alcançada em cada um desses meses. Sem esse segundo número, a continuidade pode sustentar-se atribuindo algo simbólico a um grupo pequeno, que tecnicamente preenche a casa e não cobre ninguém. É o mesmo vício que faz com que uma percentagem de conformidade marque 100% enquanto meia organização fica sem formação.
Um corte não é sempre uma falha, e o indicador sozinho não faz a distinção. Se em março não foi atribuído nada porque se acordou com a área financeira adiar a atividade para fora do fecho, isso é uma decisão e explica-se numa linha. O problema aparece quando o corte não tem nenhuma decisão por trás e quem poderia explicá-lo já não trabalha na organização.
Diante do comité, a declaração que cabe é que o plano não caiu durante a transição. É uma frase modesta e é exatamente o que o trimestre tinha para dar.
O que encontra quem chega ao cargo?
A transferência real não é um documento que alguém consegue escrever na sua última semana. É o estado em que o sistema ficou.
A plataforma regista três coisas distintas e as três importam aqui. As ações dos utilizadores finais, com data e tópico do que concluíram. As ações dos utilizadores administrativos, como a criação ou a eliminação de uma campanha. E as ações da própria plataforma, como o envio de emails, a importação de utilizadores ou a exportação de dados. Todas as atividades realizadas por utilizadores finais, administrativos ou pelo sistema ficam registadas nos registos de auditoria da plataforma, em logs detalhados e inalteráveis.
Para quem chega, isso muda o primeiro mês de trabalho. Em vez de reconstruir de memória alheia o que foi feito, pode ler o que foi atribuído, quando e a quem, e o que alguém alterou na configuração antes de sair. E quando chegar a auditoria, tem a resposta às perguntas que uma folha de cálculo não responde sem ter estado presente quando os factos ocorreram.
A continuidade não se resolve no dia da saída. Resolve-se antes, quando se decide que parte do programa depende de uma pessoa e que parte depende da organização. Se quiseres ver como se sustenta essa série na prática, como se demonstra o cumprimento em sensibilização mostra o que fica registado e com que nível de detalhe.
Deixe um comentário