Suporte Okai

Aplica-se a: Projetos regulatórios vinculados a normas, obrigações, mudanças regulatórias, análises de impacto, planos de adequação, tarefas, responsáveis, prazos, decisões e evidências no workspace.

Projeto regulatório começa pela origem

Um projeto regulatório existe para transformar uma exigência em trabalho acompanhável. A norma, obrigação ou mudança regulatória explica por que o projeto foi aberto; o projeto organiza o que será feito, por quem, até quando e com qual comprovação.

Na Okai, o melhor projeto regulatório não é uma pasta genérica de tarefas. Ele preserva a causa da demanda e reúne as decisões que mostram como a equipe interpretou a obrigação. Essa ligação é importante porque, meses depois, alguém pode precisar reconstruir a linha do tempo: qual norma disparou a análise, qual escopo foi aceito, quais áreas foram envolvidas, quais entregas foram concluídas e quais evidências sustentam a conclusão.

Sempre que a demanda nasceu de uma norma disponível no Compliance Hub ou no Explorer, prefira criar o projeto a partir desse contexto ou vincular a origem antes de avançar. Se a referência regulatória ficar apenas no texto da descrição, a rastreabilidade depende de leitura manual e a equipe perde parte do valor operacional do produto.

A pergunta central: Antes de criar qualquer tarefa, responda: qual exigência, risco regulatório ou decisão de adequação este projeto precisa controlar? Se essa resposta não está clara, o projeto ainda não está pronto para ser aberto.

Quando abrir um projeto

Use projeto regulatório quando a resposta à norma precisa de coordenação. Isso normalmente acontece quando existem várias etapas, responsáveis diferentes, análise de aplicabilidade, dependências entre áreas, aprovação formal, prazo relevante ou necessidade de evidência final consolidada.

• Abra projeto quando uma norma exige plano de adequação, revisão de política, criação de controle, alteração de processo, comunicação interna ou comprovação de atendimento.
• Abra projeto quando a análise precisa separar frente jurídica, operacional, tecnologia, riscos, controles, atendimento, produtos ou outras áreas executoras.
• Abra projeto quando a gestão precisa acompanhar andamento por status, pendências, responsáveis e prazos, em vez de depender de conversas fora da plataforma.
• Abra projeto quando haverá evidências distribuídas, como atas, pareceres, planilhas, respostas de áreas, documentos revisados, comprovantes de comunicação e aprovações.
• Abra projeto quando uma decisão de não aplicabilidade também precisa ser registrada com justificativa, revisão e evidência suficiente.

Nem toda demanda vira projeto: Se a ação é pontual, como confirmar leitura, anexar um arquivo, revisar um metadado ou pedir uma resposta simples a uma área, uma tarefa vinculada à norma pode ser suficiente. Criar projeto para tudo aumenta ruído e dificulta enxergar as iniciativas que realmente exigem gestão.

Defina escopo antes de distribuir trabalho

O escopo é o limite operacional do projeto. Ele deve explicar o que será analisado, o que será entregue, quais áreas entram no plano e quais assuntos ficam fora. Sem esse limite, o projeto tende a absorver toda conversa relacionada ao tema regulatório e deixa de ser acompanhável.

1. Identifique a obrigação ou mudança: Leia a norma de origem e destaque obrigações, prazos, exceções, vigência, público afetado e evidências esperadas. Se a norma altera outra norma, confira se o conjunto normativo necessário está relacionado.
2. Escreva o resultado esperado: Descreva o que deve existir ao final: parecer de aplicabilidade, política atualizada, controle implementado, comunicação enviada, plano aprovado, evidência anexada ou decisão registrada.
3. Separe o que fica fora: Registre exclusões relevantes, como produtos não afetados, unidades fora do escopo, obrigações que serão tratadas em outro projeto ou temas que dependem de análise posterior.
4. Escolha um responsável principal: Defina quem responde pelo andamento do projeto como um todo. As tarefas podem ter outros donos, mas o projeto precisa de uma pessoa ou área capaz de coordenar prioridade, cobrança e encerramento.

Escopo bom é verificável: Evite descrições como adequar à nova norma. Prefira algo que permita conferência: avaliar impacto da Resolução X nos processos Y e Z, atualizar procedimento A, obter aprovação da área B e anexar evidências de implantação.

Como criar no contexto certo

A criação deve preservar o caminho de auditoria. Quando você começa pela norma, o projeto já nasce com uma referência mais clara ao conteúdo regulatório. Quando começa pela área de Projetos, confirme manualmente se a origem normativa, o workspace e os responsáveis estão corretos antes de salvar.

1. Confirme o workspace ativo: Projetos, tarefas e evidências pertencem ao workspace em que são criados. Antes de abrir o formulário, confirme se você está na organização, unidade, cliente ou ambiente operacional correto.
2. Abra a norma ou obrigação de origem: Quando possível, localize a norma no Compliance Hub ou no Explorer e use a ação de criação disponível naquele contexto. Isso reduz risco de projeto solto e facilita a navegação futura.
3. Preencha título, objetivo e prazo geral: O título deve indicar a norma ou tema regulatório e o objetivo prático. O prazo geral deve refletir a data de resposta, vigência, implantação ou marco interno que governa o plano.
4. Inclua responsáveis e participantes iniciais: Adicione quem coordena, quem executa etapas principais e quem precisa revisar ou aprovar. Se uma área ainda não tem dono definido, registre isso como pendência em vez de deixar a responsabilidade implícita.
5. Salve e revise o detalhe: Depois de criar, abra o detalhe do projeto e confira vínculo normativo, descrição, datas, responsáveis e abas relacionadas. A correção mais barata é feita antes de o projeto virar rotina da equipe.

Lista e Kanban têm papéis diferentes: Use a lista para pesquisar, filtrar, comparar registros e localizar projetos por atributos. Use o Kanban, quando disponível, para acompanhar fluxo por status e perceber gargalos de execução. Uma visão não substitui a outra.

Transforme escopo em tarefas úteis

As tarefas são a parte executável do projeto. Elas devem representar entregas verificáveis, não lembretes vagos. Uma boa tarefa permite saber quem precisa agir, qual resultado deve entregar, qual prazo controla a ação e que evidência comprova a conclusão.

• Crie uma tarefa para análise de aplicabilidade quando ainda é necessário decidir se a norma afeta a operação.
• Crie tarefas separadas para áreas executoras quando cada área tem entrega, prazo ou evidência própria.
• Use tarefas de revisão ou aprovação quando a conclusão depende de validação formal de compliance, jurídico, risco, controles ou gestão.
• Separe comunicação, treinamento, alteração de documento, implantação de controle e coleta de evidência quando esses passos têm donos diferentes.
• Evite uma única tarefa chamada executar adequação se ela esconde várias entregas que precisam ser cobradas separadamente.

Dependências também precisam aparecer. Se tecnologia só pode iniciar depois de uma decisão jurídica, ou se uma comunicação depende de política aprovada, registre essa relação no histórico e organize prazos coerentes. Isso evita que atrasos pareçam falta de ação quando, na verdade, existe bloqueio de etapa anterior.

Tarefa boa deixa rastro: Ao concluir uma tarefa, deve ser possível entender a entrega sem reunião de explicação. Comentário, anexo, formulário ou documento relacionado precisam sustentar o status usado.

Status, prazos e governança

O status do projeto deve refletir a realidade do trabalho, não a intenção da equipe. Um projeto em andamento com tarefas vencidas, evidências ausentes ou aprovações pendentes precisa mostrar esse risco no acompanhamento. Atualizar status sem resolver a causa apenas transfere o problema para a próxima revisão.

• Mantenha o prazo geral alinhado ao marco regulatório mais importante: vigência, resposta ao regulador, auditoria, implantação interna ou compromisso de governança.
• Revise tarefas vencidas antes de marcar o projeto como saudável. Atraso sem comentário costuma indicar falta de acompanhamento ou dependência não registrada.
• Use comentários para registrar mudança de prazo, bloqueio, decisão de escopo, troca de responsável e motivo de replanejamento.
• Acompanhe projetos críticos com frequência maior quando envolvem regulador, data legal, impacto em cliente, obrigação recorrente ou risco operacional relevante.
• Quando um tema cresce além do escopo original, crie fase, tarefa relacionada ou novo projeto, em vez de transformar o projeto atual em depósito permanente.

Não encerre para limpar painel: Encerrar projeto com tarefa pendente, evidência faltante ou decisão não registrada cria uma falsa conclusão. Se o trabalho deixou de ser necessário, cancele ou replaneje com justificativa; se foi concluído, deixe a comprovação disponível.

Evidências e decisões ficam onde explicam melhor

Projetos regulatórios costumam ser revisados por pessoas que não participaram da execução. Por isso, evidências e decisões precisam contar a história do trabalho. O projeto deve concentrar decisões gerais, premissas, aprovações e materiais que afetam várias tarefas. A tarefa deve guardar a comprovação específica da entrega que ela representa.

1. Registre a decisão no momento em que ela acontece: Se a equipe concluiu que a norma se aplica parcialmente, que uma área está fora do escopo ou que um prazo interno precisa mudar, escreva a decisão no projeto ou na tarefa relacionada.
2. Anexe evidência no item mais próximo da entrega: Comprovante de revisão de política pertence à tarefa de revisão. Ata de comitê que aprova o plano inteiro pode ficar no projeto. A regra prática é anexar onde o item ficaria incompleto sem aquele arquivo.
3. Explique versões e substituições: Quando um documento novo substitui uma minuta, um parecer ou uma planilha anterior, registre qual versão passou a valer e por quê. Sem essa explicação, anexos parecidos geram dúvida na auditoria.
4. Faça uma revisão antes de concluir: Verifique se as tarefas relevantes foram encerradas, se prazos finais fazem sentido, se decisões importantes estão registradas e se as evidências abrem corretamente.

Conclusão precisa ser defensável: Um projeto regulatório bem encerrado responde três perguntas: qual obrigação foi tratada, qual decisão ou entrega foi produzida e onde está a comprovação.

Diagnóstico quando algo saiu torto

Quando o projeto não ajuda a acompanhar a adequação, investigue a raiz antes de corrigir apenas título, status ou texto de apresentação. O problema costuma estar na origem, no escopo, no vínculo, na quebra de tarefas ou na evidência.

• Projeto sem norma vinculada: confirme se era realmente um projeto livre. Se nasceu de obrigação regulatória, registre a origem correta antes de usar o projeto como referência de auditoria.
• Projeto amplo demais: procure temas que deveriam virar fases, projetos relacionados ou tarefas com entregas próprias. Escopo indefinido reduz a confiança no status.
• Tarefas sem dono: volte ao plano de execução e atribua responsabilidade real. Participante informado no projeto não substitui responsável por entrega.
• Status positivo com pendências vencidas: revise tarefas, bloqueios e evidências. O painel deve refletir o trabalho, não esconder o atraso.
• Evidências espalhadas: escolha o item principal de cada comprovação e use comentários para explicar referências cruzadas. Duplicar arquivos em todos os lugares cria conflito de versão.
• Projeto concluído sem decisão final: registre a conclusão, a justificativa e a evidência que sustentam o encerramento. Sem isso, a última tarefa fechada não explica necessariamente o resultado do projeto.
• Responsável não encontra o projeto: confirme workspace ativo, permissões, filtros de lista, visão de Kanban e status do registro antes de criar duplicidade.

O melhor ajuste preserva a história: Se precisar corrigir um projeto já usado, mantenha o histórico compreensível. Explique o que foi ajustado, por que a mudança era necessária e qual passa a ser a referência correta.