Acredito que o conhecimento se multiplica quando é dividido. Por isso, criei este espaço para retribuir à comunidade e crescermos JUNTOS,  trazendo algo além de somente textos estáticos, mas também laboratórios interativos. ... View more

Desafio de Volume: Gestão de 7TB de Dados na ServiceNow para Evitar Multas Contratuais e Cumprir a Retenção de 5, 7, 10 Anos       A Crise do Excesso de Dados e a Pressão da Auditoria O ServiceNow, como core de processos empresariais, acumula dados em um ritmo acelerado. Quando o volume de dados ativos atinge patamares elevados (normalmente mais de 7TB utilizados), as organizações enfrentam dois problemas urgentes: Risco Contratual e Financeiro: O consumo de dados ultrapassa os limites contratuais, resultando em multas ou custos altos para a aquisição de aditivos à licença. Conflito de Conformidade: A Auditoria exige que dados históricos sejam mantidos por até X anos para fins regulatórios, enquanto a performance da plataforma exige que o volume ativo seja drasticamente reduzido. Essa situação demanda uma estratégia de Gestão de Volume de Dados (DVM) que equilibre o desempenho da instância com a retenção obrigatória.   O Arquivamento (Data Archiving) como Solução de Equilíbrio O módulo nativo de Data Archiving é a ferramenta essencial para resolver esse conflito. Sua função é mover registros inativos (como Incidents e Tasks fechados há anos) de tabelas primárias para tabelas de arquivamento separadas, mas dentro do mesmo banco de dados. Benefícios Imediatos do Arquivamento: Otimização de Performance: Ao remover milhões de registros inativos, as consultas (GlideRecord) e os reports se tornam drasticamente mais rápidos. Controle de Volume Ativo: Reduz o volume na camada de dados de produção, ajudando a voltar para dentro dos limites contratuais e mitigando multas. Acessibilidade para Auditoria: Os dados arquivados permanecem na instância e podem ser facilmente acessados para cumprir o requisito de retenção de X anos.   Conformidade Regulatória: O Roteiro para a Retenção de Dados A definição da política de arquivamento e descarte na ServiceNow não é técnica, mas sim um requisito de governança imposto por normas globais e nacionais. 🇪🇺 GDPR / 🇧🇷 LGPD (Lei Geral de Proteção de Dados): Foca no Princípio da Necessidade e Finalidade, exigindo que dados pessoais sejam mantidos apenas pelo tempo estritamente necessário para o propósito inicial. A retenção além desse período é permitida somente se houver uma obrigação legal ou regulatória, o que justifica a retenção de logs e registros de auditoria por longos períodos, mas exige a exclusão ou anonimização de dados pessoais de tickets resolvidos. 🇧🇷 BACEN (Banco Central do Brasil) e Setor Financeiro: Impõem requisitos rigorosos de rastreabilidade e auditoria para a segurança cibernética (Circular nº 3.901/2018). Requer a manutenção de logs de eventos de segurança e acessos privilegiados por um período robusto (frequentemente 5 anos ou mais) para fins de investigação e compliance financeiro. ITIL (Information Technology Infrastructure Library): Embora não seja uma lei, o framework ITIL endossa o Arquivamento como uma boa prática de Gestão do Ciclo de Vida do Serviço. Justifica o arquivamento com foco em eficiência e performance, pois o excesso de dados prejudica a velocidade das operações de serviço.     Processo de Gestão do Ciclo de Vida do Dado na ServiceNow (DVM) Para lidar com um excesso significativo, a estratégia deve ser rigorosa: Análise de Retenção e Destruição: Identificar rigorosamente quais dados não são necessários para a retenção de 7 anos e podem ser destruídos de forma segura. Exportação Programada (Off-Boarding😞 Para dados brutos muito antigos cuja retenção legal é obrigatória, mas cujo custo na instância é proibitivo, pode-se exportar o dado bruto via Table API ou Exportação Programada para FTP para um repositório de dados externo de baixo custo. Decisão de Custo: A gestão precisa ponderar se o custo da governança (limpeza, arquivamento e possível exportação) é menor do que o custo de pagar o aditivo à ServiceNow por esse volume excedente.   A estratégia de DVM (Data Volume Management) deve envolver dois caminhos técnicos distintos, que são o arquivamento nativo e a destruição/exportação: A) Arquivamento Nativo (Retenção Interna e Performance) Esta é a abordagem padrão e mais segura para manter os dados acessíveis para auditoria e reporting interno, ao mesmo tempo que desonera as tabelas de produção. Criação de Regra de Arquivamento: O administrador define uma regra específica para uma tabela (ex: incident) e a configura para mover registros que atendam a critérios como: Status = Fechado e Data de Fechamento > 365 dias. Execução do Arquivamento: O sistema move os dados da tabela original para uma tabela espelho (ar_incident, por exemplo). Acesso Auditável: Os usuários ainda podem consultar os dados arquivados através de módulos e relatórios específicos, garantindo o requisito de retenção de 7 anos para auditoria. B) Estratégias de Destruição e Exportação (Off-Boarding) Quando a retenção por 7 anos exige que o dado seja mantido, mas o custo para mantê-lo ativo na instância ServiceNow é proibitivo (como a situação de 7TB), a estratégia é o off-boarding para um sistema externo de baixo custo. Método Propósito Como é Feito na ServiceNow Risco/Cuidado 1. Exportação Programada Mover dados históricos para um Data Warehouse ou Repositório (Ex: Nuvem, FTP) para retenção de 7 anos. Uso de Exportação Programada (Scheduled Exports) ou consumo via Table API por um sistema externo. O repositório de destino deve ter seus próprios controles de segurança e auditoria rigorosos. 2. Destruição de Dados Remover permanentemente dados que não possuem mais valor de negócio ou obrigação legal (ex: logs de debug antigos). Uso de Regras de Destruição de Dados (Data Destruction) no módulo de Arquivamento, configurando um prazo final de vida para o registro arquivado. Deve ser usado apenas após confirmação legal de que o dado não é mais exigido pela LGPD/Auditoria.     Conclusão: A Governança de Dados como Prioridade Financeira e Legal O problema de volume de dados é, no fundo, um problema de governança de custo e conformidade. A solução de Data Archiving e a definição de uma política de retenção clara baseada em regulamentações (LGPD, BACEN) são os únicos caminhos para: Garantir a performance da instância. Proteger-se contra multas contratuais por excesso de uso. Manter a conformidade com as regras de auditoria que exigem a retenção de dados por longos períodos. Um inventário de dados e uma gestão rigorosa são indispensáveis para manter as instâncias saudáveis e financeiramente viáveis.           ServiceNow Releases. ServiceNow History. Summary. ServiceNow Comece por aqui. SSC — O Guia Definitivo para Blindar Sua Instância e Atingir a Conformidade. / Medium. Disable SQL Error Messages. doc oficial.         https://www.youtube.com/@servicenowbr/ https://www.facebook.com/groups/servicenowbrasil https://www.servicenow.com/community/brazil-snug/tkb-p/snug-br-brazil-tkb-board https://www.linkedin.com/groups/5134493/ https://www.servicenow.com/community/user/viewprofilepage/user-id/73505 https://github.com/Tiagomacul/ https://www.tiktok.com/@servicenowbr https://open.spotify.com/show/1Qa4xVz7xXnKM9y9wggfT9 https://www.linkedin.com/in/tiagomacul/ https://circle.nowbridge.com.br/home https://www.linkedin.com/company/now-bridge/         ... View more

Tem uma coisa que eu aprendi nos projetos de ServiceNow: entregar não é suficiente. E por mais que isso soe estranho — principalmente pra quem veio de uma pegada mais técnica —, a real é que não adianta o time bater escopo, prazo e custo se o cliente não enxerga valor naquilo. E é aí que entra o papel do EM de verdade. Não o que só atualiza cronograma ou faz reunião de status. Mas aquele que entende o que tá em jogo pro cliente, traduz a demanda de negócio e conecta o que o time entrega com o que a empresa precisa resolver. Esse tipo de valor não aparece no board do Jira. Ele aparece quando o cliente fala “agora faz sentido pra mim”, ou quando o sponsor volta pra mesa porque viu que tem algo estratégico acontecendo ali. Isso começa desde o kickoff. É na conversa inicial que você mostra que não veio só “implantar uma plataforma”, mas resolver um problema real, com impacto pra área de negócio. E isso exige escuta, contexto, repertório — e muita resiliência também, porque às vezes o cliente nem sabe direito o que quer. Cabe a você puxar isso com maturidade. Ser EM é isso: saber quando ficar quieta e quando bater na mesa. É proteger o time sem perder o vínculo com o cliente. É garantir entrega sem perder o valor no meio do caminho. E no fim do dia, é isso que fica. A entrega é o de menos — o que conta é o quanto ela gerou de valor pra quem tava do outro lado. Se você também vive esse desafio em projetos ServiceNow, comenta aqui. Bora trocar ideia de verdade. ... View more

  Para o profissional que trabalha com a estruturação de dados organizacionais no ServiceNow, a tabela cmn_department é um dos pilares da CMDB e do gerenciamento de usuários. O seu propósito vai além de simplesmente listar os departamentos; ela é projetada para modelar a estrutura hierárquica de uma organização, o que é fundamental para a governança, a automação e a geração de relatórios. A seguir, será detalhado como essa hierarquia funciona e quais são as suas principais aplicações.   A tabela cmn_department       O Mecanismo de Hierarquia: O Campo parent   A chave para a hierarquia na tabela cmn_department é o campo parent . Este campo é uma referência para outro registro na mesma tabela cmn_department . É por meio dessa autorreferência que o ServiceNow consegue estabelecer uma relação pai-filho entre os departamentos. Um departamento pai, como "TI", é um registro que não aponta para nenhum outro no campo parent . Um departamento filho, como "Infraestrutura", é um registro cujo campo parent referencia o registro do departamento "TI". Essa relação pode se estender por múltiplos níveis, criando uma estrutura de árvore completa que espelha a organização real da empresa (por exemplo: TI -> Infraestrutura -> Equipe de Servidores).   Aplicações Práticas da Hierarquia   A capacidade de modelar essa hierarquia traz benefícios significativos para a plataforma: Geração de Relatórios e Dashboards: A hierarquia permite a criação de relatórios agregados. Por exemplo, é possível gerar um relatório que mostra todos os incidentes abertos para o departamento "Infraestrutura" e para todos os seus sub-departamentos (como a "Equipe de Servidores") em uma única consulta, sem a necessidade de múltiplos filtros manuais. Controle de Acesso e Permissões: Em cenários de segurança, a hierarquia pode ser utilizada para aplicar regras de acesso. É possível criar lógicas que permitem que um gerente de um departamento pai tenha visibilidade ou permissão sobre os registros de todos os departamentos filhos, simplificando o gerenciamento de acesso. Automação e Roteamento de Fluxos de Trabalho: A hierarquia pode ser usada em Flows ou Business Rules para direcionar tarefas. Por exemplo, uma tarefa pode ser roteada para o gerente do departamento pai do solicitante, garantindo que a requisição seja escalada corretamente.   Considerações e Boas Práticas   Ao trabalhar com a hierarquia da tabela cmn_department , algumas boas práticas devem ser observadas: Evite Referências Circulares: Embora o ServiceNow geralmente previna isso, é crucial garantir que a estrutura não forme ciclos (A é pai de B, e B é pai de A), o que poderia causar problemas em scripts. Impacto na Performance: Para hierarquias muito profundas, consultas que buscam dados em múltiplos níveis podem ter um impacto na performance. É recomendado otimizar as consultas sempre que possível. Manutenção: A hierarquia departamental deve ser mantida atualizada. A automação da sincronização com um sistema de RH (como o Workday ou o SAP) pode ser uma excelente estratégia para garantir a precisão dos dados. A tabela cmn_department é muito mais do que uma lista simples. Ao aproveitar sua capacidade de modelagem hierárquica, o profissional pode construir uma base de dados mais robusta e inteligente, que beneficia a automação, a governança e a tomada de decisões em toda a plataforma.                 Summary Artigos-publicados Explorando a Estrutura Hierárquica no ServiceNow: O Papel do Campo ‘Manager’ em Sys_User.   Participe, entre nas comunidades, acompanhem os posts: https://www.youtube.com/@servicenowbr/ https://www.facebook.com/groups/servicenowbrasil https://www.servicenow.com/community/brazil-snug/tkb-p/snug-br-brazil-tkb-board https://www.linkedin.com/groups/5134493/ https://www.servicenow.com/community/user/viewprofilepage/user-id/73505 https://github.com/Tiagomacul/ https://www.tiktok.com/@servicenowbr https://www.instagram.com/br.servicenow/ https://open.spotify.com/show/1Qa4xVz7xXnKM9y9wggfT9 https://join.slack.com/t/servicenowbrasil/shared_invite/zt-2sooa78s7-MWwcMxEdbktNjjIYRZfqHg https://www.servicenow.com/community/user/viewprofilepage/user-id/73505 https://www.linkedin.com/in/tiagomacul/     ... View more

  Não adianta fugir: em algum momento da sua jornada como EM ou BPC, você vai encontrar um stakeholder difícil. Às vezes, é aquele gestor que exige tudo pra ontem e nunca aparece nas reuniões. Às vezes, é alguém do time técnico do cliente que vive dizendo “isso não vai funcionar aqui”. E às vezes, é aquele sponsor que muda de ideia toda semana, mas quer que o escopo continue o mesmo. Então a pergunta não é se vai acontecer — mas como você vai reagir quando acontecer. E é sobre isso que a gente vai conversar aqui. Sem receita de bolo, mas com muita vivência prática. Porque se tem uma coisa que projeto ServiceNow ensina, é a lidar com gente. Entendendo o "difícil": é sobre postura, não sobre pessoa Primeiro ponto: stakeholder difícil não é inimigo. Ele é alguém com dor, pressão, expectativas e histórico. O que parece resistência pode ser só medo. O que parece grosseria pode ser só frustração acumulada. Se você assume uma postura reativa, vai transformar qualquer atrito em guerra. A primeira habilidade aqui é ler além da fala. Se o cara tá te ignorando no Slack, pode não ser desrespeito – pode ser sobrecarga. Se ele tá exigindo algo absurdo, pode ser porque ninguém explicou o roadmap da plataforma. Então, antes de retrucar, respira. Pergunta. Escuta. Muda a chave de “como eu convenço essa pessoa” pra “o que essa pessoa realmente precisa resolver”. Tipos clássicos de stakeholders difíceis (e como lidar) Sem querer rotular ninguém, mas a real é que certos perfis aparecem direto nos projetos ServiceNow. Vamos falar de alguns: 1. O sumido que aparece só pra cobrar Esse é clássico. Fica semanas sem participar, ignora os e-mails, não dá input nas decisões... e quando aparece, quer mudar tudo. Nesse caso, a palavra-chave é rastro documentado. Mantenha atas curtas e visuais após cada reunião. Registre decisões no Confluence, Jira ou onde for. Envie follow-ups com clareza: “Conforme alinhado na reunião do dia X, seguimos com Y...”. Se ele tentar contestar, você não confronta – você mostra. Sem agressividade. Só fatos. 2. O técnico gatekeeper Esse é o dev sênior do cliente que quer aprovar cada linha de código, mesmo que não seja arquiteto do projeto. Às vezes ele tem trauma de projeto mal feito, às vezes é ego mesmo. Aqui, a chave é incluir sem dar controle total. Convide para os ritos técnicos, mas defina o papel dele com clareza. Peça validação de critérios, não de soluções. Use frases como: “Sua visão técnica é essencial pra garantir que não vamos quebrar nada em produção. Como você vê essa abordagem?” Ele precisa se sentir respeitado. E você precisa manter a governança. 3. O sponsor volátil Hoje quer o catálogo inteiro automatizado. Amanhã quer tirar tudo do escopo. Semana que vem quer dashboard com IA. Se você não tiver estrutura, vai virar joguete. O segredo aqui é trazer impacto com visual. Use dashboards pra mostrar progresso. Apresente escopo com desenho (roadmap visual ajuda muito). Mostre trade-offs: “Se entrarmos com isso agora, vamos adiar a entrega em duas semanas. Qual sua prioridade?” Ele precisa ver pra crer. E você precisa ser o adulto da sala. Técnicas de escuta ativa que salvam projeto Reformule o que ouviu: “Então o que você está dizendo é que...” Dê nomes às emoções: “Entendo que essa situação pode estar te frustrando...” Pergunte com empatia: “O que está te preocupando em relação a essa entrega?” Isso não é papo de coaching. É gestão de projeto aplicada. Quem escuta bem, antecipa conflito. Como manter a autoridade sem ser autoritário Você é o facilitador. Não é o chefe do stakeholder. Então sua força não vem do cargo, vem da clareza. Traga dados. “Nos últimos 3 sprints, entregamos 90% do que foi planejado. Pra manter isso, precisamos definir essa priorização até amanhã.” Use o tempo a seu favor. “A gente pode discutir essa alteração, mas ela vai impactar a entrega prevista pro dia 12. Você quer que a gente reavalie juntos?” Você não impõe. Você convida para decidir com responsabilidade. Quando subir o problema? Às vezes, sim, é necessário escalar. Mas só depois de tentar todos os caminhos do diálogo. E, quando for escalar: Seja objetivo: “Tentamos alinhar nas reuniões dos dias X, Y e Z. Ainda não tivemos retorno. Isso está travando a entrega da funcionalidade W.” Escale com contexto: não exponha, não dramatize. Informe. Escalar não é vingança. É parte da governança. Como se proteger (e proteger o time) Stakeholder difícil pode gerar desgaste emocional. Você, como EM ou BPC, precisa se blindar: Tenha momentos de descompressão fora do projeto. Compartilhe decisões com o time – não leve tudo nas costas. Mantenha documentação simples, mas rigorosa. Você não é psicólogo nem herói. Você é gestor. E seu maior ativo é sua constância. Conclusão Lidar com stakeholder difícil é quase um batismo de fogo em qualquer projeto. Mas é também onde você mais cresce como EM ou BPC. Cada conversa difícil bem conduzida é uma entrega. Cada alinhamento tenso que vira confiança é uma vitória. Você não precisa vencer argumentos. Precisa gerar acordos. E isso, meu amigo, minha amiga, é o que separa o profissional que sobrevive do que lidera.     ... View more