É o momento de automatizar parte de seu monitoramento de indicadores? Convertemos as vulnerabilidades levantadas na parte 2 desse artigo num formato de requisitos para RFP (Request for Proposal), documento para processos de seleção de softwares. E como sempre, seguindo a numeração do diagrama, não exaustivo e nem definitivo, respeitando as particularidades de cada instalação e considerando sempre a melhoria contínua.
Breve comparativo entre uso de planilha e sistema
Apesar dos bons recursos das planilhas (parte 1 desse artigo), um volume maior de dados e usuários envolvidos pode exigir uma solução por software. Ambas variáveis exigirão uma melhor documentação e evidenciação do processo praticado de coleta e consolidação de indicadores. O artigo 51 dessa resolução presume que a alta diretoria se baseia, mas também “conhece as limitações das informações constantes dos relatórios”. Mas isso não a isenta de “assegurar a correção tempestiva das deficiências… e assegurar recursos adequados e suficientes para o exercício das atividades de gerenciamento de riscos e de gerenciamento de capital”, conforme o artigo 48, sugerindo ao menos planos de melhoria. Segue um breve comparativo entre os cenários:
| Item | Uso de planilha, citado na parte 1 | Tela de um sistema |
| Manutenção | · Edição por célula. | · Edição para cada campo da tela. |
| Abertura | · Aplicativo Excel por exemplo. | · Sistema específico. |
| Formato | · Qualquer planilha desenvolvida pelo usuário. | · Específico tratado pelo sistema. |
| Restrição de acesso | · Restrição de abertura do arquivo todo com senha atribuída pelo desenvolvedor da planilha. | · Pela tela inicial de ‘login’ do sistema. |
| Restrição de funcionalidades | · Nenhuma, no modo padrão.
· Restrita pelos critérios do aplicativo no caso de planilha compartilhada. |
· Por tela e/ou por funcionalidade dentro da tela, se implementado (1). |
| Restrição aos dados | · Restrição configurável pelo desenvolvedor da planilha (bloqueio ou ocultamento de células).
· Mas uma vez autorizado a abrir o arquivo, todos usuários terão os mesmos direitos de manutenção sobre as células desbloqueadas. |
· Por perfil ou grupo de usuários (2);
· Por visibilidade hierárquica (5). · Ambos dependem de terem sido planejados para implementação. |
| Forma de gravação dos dados | · Salva o arquivo todo, independentemente de quantas e quais células foram alteradas, exceto pelo recurso de compartilhamento do Excel com algumas restrições de uso. | · Salva conforme a implementação da tela: pode ser apenas de uma informação editada, todas informações de uma linha ou um bloco de linhas (4). |
| Compartilha-
mento e efeito da ‘foto do passado’ |
· Gravação feita por arquivo.
· Usuário A poderá ver uma ‘foto do passado’, caso outro usuário B já o tenha editado simultaneamente. · O alerta de conteúdo alterado só é dado ao usuário A no momento que ele for salvar a planilha aberta em seu computador. |
· Gravação feita por unidades menores de informação, reduzindo o efeito de visualização da ‘foto do passado’ (4).
· Atualizações em bloco geralmente são feitas em processamentos em horários anteriores ao uso compartilhado mais intenso. |
| Registro da evolução | · Gravação de controle de mudanças por célula, cujo prazo é previamente parametrizado.
· A ‘trilha’ de controle de alterações presumimos ficar gravado dentro do mesmo arquivo da planilha. |
· (3) Abordagem do log, isto é, registrar data, hora e usuário que incluiu ou alterou uma informação.
· (6) Abordagem da evolução do fluxo do processo, gravando a delegação de responsabilidade entre áreas ou usuários. Sistema poderia enviar e-mail de notificação ao colaborador da próxima etapa. · Abordagem de histórico de evolução dos parâmetros armazenando vigência para extrações futuras com a ‘foto do passado’. · Todos os casos dependem dessa implementação ter sido prevista. |
| Volume | · Dados guardados no próprio arquivo da planilha são carregados na memória do computador, exigindo esse recurso proporcional ao volume de seus dados.
· O recurso de ‘outras fontes de dados’ permite acessar e gravar em banco de dados. |
· (7) Banco de dados é a forma de armazenamento mais utilizada na implementação de sistemas, já projetado para suportar maiores volumes de dados.
· Próprio para procedimentos ‘em massa’ com atualização de blocos de linhas simultaneamente. |
| Documentação do processo | · O processo de cálculo utilizado são as fórmulas e ‘macros’.
· Essa facilidade, por outro lado, desestimula documentação em língua corrida textual. Seus substitutos ou avaliadores teriam de interpretar as fórmulas e ‘macros’. · O fluxo ‘extra planilha’ depende da forma de comunicação entre os colaboradores envolvidos no processo: e-mails e telefonemas. |
· (8) Em geral, sistemas são desenvolvidos considerando um fluxo da sequência de agregação de dados até sua maturidade numa informação.
· Seu roteiro ou manual de usuário é uma rica fonte do processo a ser seguido. · Esse fluxo pode ser fixo ou parametrizável, dependendo do requisito previsto na implementação. |
| Controle no processo | · No formato mais simplificado, a manutenção das células desbloqueadas é livre para quaisquer usuários autorizados a abrirem os arquivos, sem segregar ou sequenciar seus acessos e manutenções.
· É possível incluir recursos para minimizar erro de preenchimento como listas ou programação de ‘macros’ VBA. |
· (8) O usuário não tem acesso direto ao banco de dados, tendo de obrigatoriamente interagir com telas implementadas com recursos de validação, garantindo maior integridade dos dados gravados.
· O sistema força uma sequência lógica de coleta e tratamento da informação, alinhado com o registro de evolução do processo. |
| Manutenção | · Com amplas possibilidades de manutenção pelo próprio usuário, é adequado para novas modelagens. | · Dependendo da estratégia de manutenção implementada, terá maior ou menor tempo de resposta. Ideal para processos já maduros e cálculos estabilizados. |
1-Restrição de acesso às telas e seus recursos
- Acesso de usuário ou grupo de usuários apenas às telas sob sua responsabilidade de execução ou disponibilidade de consulta.
- Segregar funcionalidades específicas dentro de cada tela para cada perfil de usuário.
- Por exemplo, uma mesma tela disponível a 2 usuários, pode fazer sentido a apenas um deles acionar um botão e outro não.
- Outra possibilidade é criar 2 telas diferentes, o que soluciona, mas encarece futuras manutenções em função do código em grande parte duplicado. Numa manutenção, seriam dois códigos a serem alterados, mas cujos testes são diferentes por conta das peculiaridades de cada um na parte ‘diferente’. Outro agravante: com 10 diferentes combinações, seria inviável dar manutenção em 10 telas ‘quase iguais’.
2-Restrição de acesso aos dados
Numa mesma tela, dependendo do usuário ou seu perfil, terem acesso apenas aos dados de sua responsabilidade. Por exemplo, a mesma tela de manutenção utilizada pelo RH e pelo setor de contas a pagar de fornecedores não pode disponibilizar todas informações a ambos setores. Cada um deve visualizar apenas as informações pertinentes ao seu setor.
3-Log
Capacidade de guardar a ‘trilha’ da sequência de manutenções que uma informação sofreu ao longo do tempo. Exigirá capacidade de armazenamento proporcional à frequência de manutenção e volume total de dados (7).
4-Multiusuário
Costuma ser requisito padrão nos sistemas especializados. Como a gravação de um sistema é feita por informação ou por linha, a possibilidade de consulta mais atualizada possível é maior que planilhas compartilhadas, que são gravadas em bloco por arquivo. Um exemplo: o primeiro usuário dando manutenção em 100 linhas de cadastro da planilha, confiando no bom recurso de salvamento automático, está alterando a 100ª linha e vai salvar em definitivo apenas quando terminar essa última linha. Simultaneamente, outro usuário abrindo essa mesma planilha compartilhada verá a ‘foto do passado’ ainda com as 99 linhas anteriores desatualizadas. Já num sistema, esse segundo usuário consultaria 99 linhas já atualizadas e apenas a 100ª ainda desatualizada, até porque o primeiro usuário não teria terminado ainda sua manutenção.
5-Visibilidade hierárquica
Requisito não obrigatório, mas bem útil. Além do usuário ou grupo de usuários terem acesso aos dados de sua responsabilidade, permitir que seus superiores também tenham esse acesso. Além da função de acompanhamento das tarefas, esses superiores poderiam executar tarefas na ausência não programada de algum deles como um plano de contingência.
6-Histórico (processo e parametrizações)
As abordagens nesse item são diferentes do log. Enquanto o log é um registro histórico para ‘trilha’ de quem, quando e o que sofreu manutenção, o histórico de parametrizações pode ser útil no caso de manter a evolução de critérios para justificar decisões e cálculos passados. Pode reproduzir ‘fotos do passado’ com os critérios e dados do passado, bem como critérios do passado com dados atuais para comparação da qualidade dos critérios anteriores com os atuais, ou para exercitar alguma variação de ‘backtesting’ (nesse contexto, teste de modelos matemáticos utilizando dados históricos).
Já a abordagem do histórico do processo é a evidenciação do fluxo de trabalho efetivamente executado dentre diferentes usuários ou áreas: quando a etapa foi encerrada, responsável por sua execução e/ou controle, contribuindo para identificar pontos de gargalo, atrasos e retrabalhos parciais ou totais de um processo.
7-Volume
A estrutura de um banco de dados possui como um dos requisitos suportar alto volume de dados. A combinação de gravação de log, do histórico de evolução do processo e das parametrizações exigirão alta capacidade de armazenamento. Houve época em que armazenávamos anos com 2 dígitos (era pré-histórica, quero dizer pré-bug do Milênio) para economizar espaço em disco e reduzir o custo de armazenamento. Atuais níveis de custo de armazenamento permitem, dentro do bom senso, manter históricos necessários para evidenciação futura.
8-Controle e documentação
A resolução estimula que todos processos passem a ser mapeados e seus riscos e controles mensurados. Se o próprio processo de consolidação de indicadores para a RAS não estiver mapeado, suas possíveis melhorias e conhecimento de melhorias necessárias ficarão desconhecidas. Baseado em planilhas, esse processo certamente envolverá telefonemas ou troca de e-mails como um fluxo de trabalho, agravado pela ausência de documentação das exceções previstas e ocorridas como ausência ou substituição de colaborador (programada ou não), reexecução de uma ou várias etapas de trabalho, não cumprimento de prazos, etc.
Curva de aprendizagem
Sempre haverá espaço no uso de planilhas para atender o estudo e levantamento de novos indicadores. Mas após sua estabilização e atingindo o ponto máximo da curva de aprendizagem com sua alta produtividade, pode ocorrer um ponto de inflexão na qualidade de sua execução. Seu uso repetitivo, monótono e rotineiro passa a ser feito mecanicamente, por exemplo a coleta por meio de digitação manual. Esse pode ser o momento de automatizá-lo num processo repetitivo mais robusto por meio de software.
Software não substitui apenas a planilha
Enfim, os itens acima não são novidade alguma para profissionais de TI, mas cabe uma reflexão pelas áreas da organização de que um software não substitui apenas a planilha. Ele substitui a troca de e-mails, telefonemas e duplicação de arquivos. Ele determina um processo de trabalho, que se bem documentado e fundamentado, será parte do próprio manual de procedimentos. Ele busca retirar tarefas repetitivas feitas manualmente e abrir espaço para que esses colaboradores se dediquem a tarefas de conferência com análise crítica da informação gerada e busca de novos indicadores, inclusive utilizando as planilhas para novas modelagens de indicadores.
Software deveria contribuir com melhoria de processo
É essencial, portanto, mapear o processo executado atualmente, elaborar seu fluxo com eventuais melhorias, para aí então avaliar a ‘caixa preta’ de softwares por meio de prova de conceito ‘POC’ (Proof of Concept), conforme citamos em nosso artigo da berinjela e o software. Há softwares com fluxos mais genéricos (BPM) num extremo e softwares especializados no outro extremo. Softwares focados em cálculo estatístico e mineração de dados, BI, etc. Vai depender das prioridades e orçamentos de cada um para solucionar seus específicos desafios.
Yoshio Hada
Fontes
Resolução 4.557/17
Artigo – parte 1
Artigo – parte 2
http://b3bee.com.br/site/2018/04/05/resolucao-4-557-indicadores-para-a-ras-com-planilhas-parte-2/
Artigo – O software e a berinjela
https://www.linkedin.com/pulse/o-software-e-berinjela-reduzindo-incerteza-na-compra-yoshio-hada/