Melhoria dos processos de gestão da informação de suporte às atividades de gestão de crise

Universidade do Minho Escola de Engenharia Manuel Vieira Fernandes Macedo Melhoria dos processos de gestão da informação de suporte às atividades de gestão de crise Abril de 2025 Universidade do Minho Escola de Engenharia Manuel Vieira Fernandes Macedo Melhoria dos processos de gestão da informação de suporte às atividades de gestão de crise Dissertação de Mestrado em Engenharia e Gestão Industrial Trabalho efetuado sob a orientação de Professora Carina Pimentel Professor Jorge Oliveira Sá Abril de 2025 ii DIREITOS DE AUTOR E CONDIÇÕES DE UTILIZAÇÃO DO TRABALHO POR TERCEIROS Este é um trabalho académico que pode ser utilizado por terceiros desde que respeitadas as regras e boas práticas internacionalmente aceites, no que concerne aos direitos de autor e direitos conexos. Assim, o presente trabalho pode ser utilizado nos termos previstos na licença abaixo indicada. Caso o utilizador necessite de permissão para poder fazer um uso do trabalho em condições não previstas no licenciamento indicado, deverá contactar o autor, através do RepositóriUM da Universidade do Minho. Licença concedida aos utilizadores deste trabalho Atribuição CC BY https://creativecommons.org/licenses/by/4.0/ iii AGRADECIMENTOS Ao concluir o meu percurso académico, gostaria de expressar a minha profunda gratidão a todos aqueles que, direta ou indiretamente, contribuíram para a realização desta dissertação e para o sucesso desta etapa tão importante da minha vida. Em primeiro lugar, agradeço aos meus orientadores, Carina Pimentel e Jorge Sá, pelo acompanhamento, paciência e orientação ao longo de todo o processo. As suas visões críticas e conselhos foram fundamentais para o desenvolvimento deste trabalho e para o meu crescimento académico e pessoal. Gostaria também de agradecer àquela que, hoje em dia, é a minha casa enquanto profissional, a NOS. Deixar uma palavra de apreço a todos os membros do departamento de Auditoria, Risco e Compliance , pelo apoio constante e por todos os momentos partilhados durante os 6 meses em que me acolheram. Um agradecimento especial ao Engenheiro David Silva Rebelo, pelo seu suporte incondicional, por todos os conhecimentos partilhados, pela paciência constante em lidar com as minhas dúvidas e por todas as horas fora do horário de trabalho que esteve a trabalhar comigo neste projeto, sinto que palavras não são sequer suficientes. Aos docentes e investigadores com quem tive o privilégio de contactar ao longo deste percurso, agradeço a partilha de conhecimentos e a inspiração que sempre transmitiram, moldando o meu pensamento crítico e a minha abordagem analítica. Aos meus colegas e amigos, que estiveram sempre ao meu lado, oferecendo palavras de incentivo, apoio e compreensão nos momentos mais desafiantes, o meu sincero obrigado. Cada conversa e cada partilha foram essenciais para ultrapassar os obstáculos deste caminho. À minha família, em especial aos meus pais, irmã e avô agradeço pelo apoio incondicional, pelo amor e pela confiança depositada em mim. A vocês devo esta conquista. Por fim, agradeço a todos aqueles que, de alguma forma, contribuíram para a realização deste trabalho. Cada gesto, cada palavra de apoio e cada momento de partilha fizeram a diferença nesta jornada. A todos, o meu mais sincero agradecimento. iv DECLARAÇÃO DE INTEGRIDADE Declaro ter atuado com integridade na elaboração do presente trabalho académico e confirmo que não recorri à prática de plágio nem a qualquer forma de utilização indevida ou falsificação de informações ou resultados em nenhuma das etapas conducente à sua elaboração. Mais declaro que conheço e que respeitei o Código de Conduta Ética da Universidade do Minho. v Melhoria dos processos de gestão da informação de suporte às atividades de Gestão de Crise RESUMO A gestão eficaz da informação surgiu como um diferenciador crucial para as empresas no atual panorama industrial, caracterizado por uma crescente globalização e competitividade. Esta dissertação surge no sentido de melhorar os processos de gestão de informação no âmbito das operações de Gestão de Crise. O principal propósito do projeto é automatizar e organizar os procedimentos de atualização de dados críticos nos Organigramas de Crise e Listas de Distribuição. Recorrendo ao Power Automate e a diversos ficheiros Excel, a abordagem metodológica seguiu o ciclo PDCA (Plan-Do-Check-Act), permitindo identificar lacunas nos processos existentes e propor alternativas tecnológicas. Os principais objetivos do projeto incluíram o aumento da eficiência operacional, a redução da necessidade de intervenções manuais e a automatização das tarefas relacionadas com a atualização dos organigramas de crise e das listas de distribuição. Entre os principais resultados, destacam-se a diminuição das tarefas manuais associadas à gestão da informação, uma comunicação interdepartamental mais eficaz e um feedback bastante positivo por parte dos utilizadores, resultando isto num valor de índice de satisfação a rondar os 78%. Além disso, a solução implementada reforçou a fiabilidade das informações críticas, garantindo que estas estejam sempre atualizadas e facilmente acessíveis às partes interessadas. Apesar dos avanços alcançados, foram identificadas algumas limitações, como desafios relacionados com a escalabilidade das soluções sugeridas e a dependência de tecnologias específicas. Recomendase que investigações futuras expandam a automatização para outros processos organizacionais críticos e aprofundem a integração com outras plataformas tecnológicas. PALAVRAS-CHAVE Auditoria, Risco e Conformidade, Automatização de processos, Ciclo PDCA, Gestão de Crise, Gestão de informação vi Improvement of information management processes to support Crisis Management activities ABSTRACT Effective information management has emerged as a crucial differentiator for companies in today’s industrial landscape, marked by increasing globalization and competitiveness. This dissertation aims to improve information management processes within the scope of Crisis Management operations. The primary objective of the project is to automate and streamline the procedures for updating critical data in Crisis Organization Charts and Distribution Lists. Focusing on Power Automate and structured databases, the methodological approach followed the PDCA (Plan-Do-Check-Act) cycle, allowing the identification of gaps in existing processes and the proposal of technological alternatives. The main objectives of the project included increasing operational efficiency, reducing the need for manual interventions and automating tasks related to updating crisis organization charts and distribution lists. Among the main outcomes, the most notable are the reduction of manual tasks associated with information management, more effective interdepartmental communication, and highly positive user feedback, reflected in a satisfaction index of approximately 78%. Furthermore, the implemented solution enhanced the reliability of critical information, ensuring it remains consistently up-to-date and readily accessible to all relevant stakeholders. Despite the advances achieved, some limitations were identified, such as challenges related to the scalability of the suggested solutions and the dependence on specific technologies. It is recommended that future investigations expand automation to other critical organizational processes and deepen integration with other technological platforms. KEYWORDS Audit, Risk and Compliance, Crisis Management, Information management, Process automation, PDCA Cycle vii ÍNDICE Agradecimentos.............................................................................................................................iii Resumo .........................................................................................................................................v Índice de Figuras ........................................................................................................................... ix Índice de Tabelas.......................................................................................................................... xii Lista de Abreviaturas, Siglas e Acrónimos ...................................................................................... xiv 1. Introdução ............................................................................................................................. 1 1.1 Contextualização da Empresa ......................................................................................... 1 1.2 Enquadramento e Motivação do Projeto........................................................................... 3 1.3 Objetivos e Resultados Esperados ................................................................................... 4 1.4 Metodologia de Investigação ........................................................................................... 5 2. Enquadramento Teórico .......................................................................................................... 8 2.1 Crises organizacionais.................................................................................................... 8 2.2 Automatização dos fluxos de informação ....................................................................... 13 2.3 Bases de dados ........................................................................................................... 20 2.4 Método de Decisão ...................................................................................................... 21 3. Diagnóstico do Estado Atual na NOS (as-is) ............................................................................ 27 3.1 Modelo de processo do BCM ........................................................................................ 27 3.2 Implementação do PGCrise .......................................................................................... 32 3.3 Oportunidades de Melhoria........................................................................................... 42 4. Propostas de Solução ( to-be) ................................................................................................. 48 4.1 Necessidades e Requisitos do Projeto............................................................................ 48 4.2 Hipóteses de Solução para cada oportunidade de melhoria ............................................. 50 5. Implementação e avaliação ................................................................................................... 76 5.1 Ciclo de Implementação e Ajuste .................................................................................. 76 5.2 Visão Global da Ferramenta .......................................................................................... 76 5.3 Síntese e Avaliação da eficácia da ferramenta ................................................................ 82 6. Conclusão ........................................................................................................................... 85 6.1 Resultados do Projeto .................................................................................................. 85 6.2 Limitações do Projeto................................................................................................... 86 viii 6.3 Trabalhos Futuros........................................................................................................ 86 Referências Bibliográficas ............................................................................................................. 87 Apêndices ................................................................................................................................... 90 Apêndice A – Fluxograma do processo de atualização da informação de Crise .............................. 90 Apêndice B - Fluxo de informação do processo de atualização do PGCrise .................................... 97 Apêndice C – Características variáveis constituintes do novo repositório ....................................... 98 Apêndice D – Matrizes criadas para o método AHP................................................................... 102 Apêndice E – Automatismos desenvolvidos .............................................................................. 106 Apêndice F – Checklist Execução Repositório de Dados............................................................. 133 Apêndice G – Questionário de feedback de utilizadores ............................................................. 135 1 1. INTRODUÇÃO Com o intuito de dar início a este relatório de dissertação, surge este capítulo introdutório em que se dá uma contextualização da empresa, motivações e enquadramento do projeto, uma lista dos principais objetivos e ainda a metodologia de investigação utilizada. O tema do projeto é a melhoria dos processos de gestão de informação de suporte às atividades de Gestão de Crise. Em situações de Crise, por exemplo a falha da rede móvel ou uma situação pandémica como a que foi vivida há 4 anos, existe a necessidade de ativação do Plano de Gestão de Crise, sendo que para tal vão ser seguidos os Organigramas de Crise e não os Organigramas de funcionamento normal. Este projeto tem por base o estudo de toda a informação associada ao Plano de Gestão de Crise, bem como a necessidade de atualização da mesma. 1.1 Contextualização da Empresa Com o intuito de contextualizar a origem deste projeto detalha-se a evolução da empresa, e é feita ainda uma referência às várias empresas e subsidiárias com que o grupo conta. Ademais, elabora-se uma descrição da direção de ARC (Auditoria, Risco e Compliance ), mais concretamente da área de Compliance Corporativa e Manutenção, que passa pelo departamento da empresa no qual surgiu este desafio. 1.1.1 Evolução da Empresa A empresa inerente a este projeto é a NOS SGPS, fundada em 2014, com o propósito de “dar mais vida à vida, expandindo todas as ligações possíveis e imaginárias”. Surge como um dos maiores grupos de comunicação e entretenimento em Portugal, da fusão da Optimus e da ZON. A Optimus entrou no mercado das comunicações em 1998, empenhada em disponibilizar ao consumidor produtos e serviços que, além de inovadores, respondessem às suas necessidades efetivas. Rapidamente se estabeleceu como um sucesso, revolucionando o panorama das telecomunicações em Portugal. Dez anos após a sua estreia, em 2008, surgiu a ZON , uma operadora independente, que rapidamente se afirmou como líder no mercado da televisão por cabo e internet de banda larga. O contexto no sector das comunicações em Portugal, anos mais tarde, proporcionou um terreno fértil para a fusão entre estas duas entidades. Foi assim que surgiu a NOS, ostentando uma nova identidade e com o objetivo de consolidar a sua posição de liderança no sector, focada no compromisso com o cliente, na superação 2 do status quo, assumindo responsabilidades e empenhada em construir um futuro mais promissor, em colaboração com as suas pessoas. Comprometida com a sustentabilidade e a qualidade do seu serviço a todos os interessados, o Grupo tem investido numa governação corporativa, ética, social e ambiental, alcançando as certificações ISO 9001 (Qualidade), ISO 14001 (Ambiente), ISO 45001 (Saúde e Segurança), ISO 27001 (Segurança da Informação) e ISO 20000 (Gestão de Serviços). É importante salientar que em 2024, foram geradas pela NOS receitas operacionais de 1,5 mil milhões de euros, obtendo um resultado líquido na ordem dos 224,6 milhões de euros. O grupo inclui várias empresas e filiais nas áreas tecnológica, de conteúdos, suporte e imobiliária, conforme ilustrado na Figura 1. Figura 1 - Estrutura da NOS SGPS Fonte: NOS (2021) 1.1.2 Compliance Corporativa e Manutenção O projeto delineado neste documento é integrado na área de Auditoria, Risco e Compliance (ARC) da NOS, que tem como finalidade contribuir para a gestão eficaz dos riscos de negócio do Grupo. Esta área engloba os setores especificados na Figura 2, incluindo o departamento de Auditoria Interna, sob a perspetiva de Assurance , e o departamento de Risco e Conformidade, focado na promoção da gestão de risco e na obtenção de conformidade organizacional através de medidas adequadas. O projeto foi 3 desenvolvido especificamente na última área mencionada, na equipa de Compliance Corporativa e Manutenção (CCM). Este estudo acaba por ter um papel fulcral na conectividade da empresa como um todo, uma vez que todas as áreas existentes estão contempladas no Plano de Gestão de Crise da NOS. Figura 2 - Estrutura Organizacional da Direção de ARC Fonte: Adaptado de (NOS, 2021) Com o objetivo de alinhar o nível de risco ao desejado pela Comissão Executiva da NOS, a CCM empenhase em oferecer apoio a todas as áreas da empresa NOS Comunicações, disponibilizando ferramentas e metodologias destinadas à mitigação eficaz do risco. Este esforço inclui a promoção de sensibilização, avaliação e gestão dos riscos ligados a variados processos empresariais. Adicionalmente, a vigilância contínua dos riscos e dos mecanismos de controlo facilita a revisão constante dos processos de negócio. Assim, de maneira preventiva, proativa e adaptável, garante-se a preservação de um nível de risco e controlo considerado aceitável. 1.2 Enquadramento e Motivação do Projeto Segundo Jaques (2010), as crises são eventos que vão afetar a performance da empresa e cujo tratamento se torna ambíguo, sendo que os efeitos podem ser irreversíveis e o método de resolução bastante complexo. Na NOS vão surgindo incidentes, que numa fase inicial, são avaliados consoante o seu nível de gravidade, podendo ser definidos como acontecimentos de crise ou não. Sendo acontecimentos de crise, estes acontecimentos vão ser avaliados consoante o nível de Crise. Esta avaliação é elaborada segundo as diretrizes da matriz de Crise, disponível para visualização na Figura 12, que por sua vez, representa um instrumento de suporte à decisão, sendo nela definidos 4 níveis de crise. É considerada uma crise, qualquer cenário que atinja um nível igual ou superior ao amarelo. É considerado um mero incidente 4 quando o respetivo cenário assume a cor azul. Consoante o nível de Crise implementado, deverá haver um escalamento da informação (de forma vertical) para o nível hierárquico imediatamente superior na hierarquia de Crise, e daí surge a importância de ter Organigramas de Crise bem definidos. No universo industrial atual, caracterizado por uma globalização crescente, a competitividade entre empresas e a concorrência pela preferência dos consumidores são realidades cada vez mais presentes. Por estes motivos, as empresas procuram desenvolver ferramentas para aumentar a produtividade, reduzir os custos, reduzir tempos, minimizar riscos e aumentar a qualidade dos seus processos. A automatização de processos de gestão da informação surge como um recurso cada vez mais utilizado para alcançar estes objetivos. 1.3 Objetivos e Resultados Esperados Este projeto tem então como principal finalidade a automatização dos processos de gestão de informação de suporte às atividades de gestão de crise, mais concretamente, automatizar o processo de gestão de informação aliado ao plano de gestão de crise, permitindo que parte do mesmo seja atualizado consoante a informação que vai chegando à ARC. Para tal, estão então definidos Papéis de Crise, para cada Direção da NOS, assumidos por determinados colaboradores. Consoante esses papéis, estão definidos Organigramas de Crise, e Listas de Distribuição. Toda esta informação está presente em ficheiros Excel e em diversas aplicações corporativas e não corporativas. A verdade é que vão constantemente entrando e saindo colaboradores da empresa, levando a que surja a necessidade constante de atualizar a informação presente nos Organigramas de Crise e nas várias Listas de Distribuição para que, aquando de uma Crise, os mesmos estejam de acordo com o quadro atual de trabalhadores da empresa. Atualmente, este processo manual, torna-se complexo dado que existe a necessidade de atualizar a mesma informação em várias ferramentas utilizadas pela NOS. Posto isto, ao verificarem o que poderia ser uma grande oportunidade de melhoria e de darem mais um passo na digitalização, a equipa de ARC, decidiu propor que este projeto se concentrasse na incorporação da gestão da informação relativa aos colaboradores, de forma automática, nas várias ferramentas utilizadas pela empresa. Assim, o ponto de partida passa pela realização de uma análise de diagnóstico referente à forma como a informação está organizada. Através da mesma, vão ser destacadas algumas oportunidades de melhoria, que, posteriormente, vão ser alvo de estudo de forma que, dentro do possível, sejam implementadas. 5 Como já foi referenciado anteriormente, o objetivo do projeto passa pela automatização das atividades de gestão da informação de Crise, através da criação de uma ferramenta informática. Por outras palavras, reduzir o número de tarefas associadas ao Gestor da Informação de Crise, com a possibilidade de investir o tempo ganho, em tarefas de valor acrescentado. Deste modo, será feita uma gestão mais eficaz desta informação, tornando todo o processo de atualização digital e automático. O projeto vai seguir as seguintes etapas: 1. Analisar a metodologia atual e identificar possíveis oportunidades; 2. Sugerir um conjunto de Hipóteses de Solução para cada Oportunidade encontrada; 3. Criar um artefacto informático que permita a atualização da informação de forma automática, implementando as soluções que dão resposta a cada Oportunidade de Melhoria; 4. Testar o artefacto criado através da implementação da informação proveniente de um input em concreto; 5. Melhorar o artefacto criado, consoante os resultados obtidos do ponto anterior – correlação direta com os possíveis trabalhos futuros associados a este projeto; 6. Implementação do artefacto criado (em produção). Espera-se que, no final do projeto, resulte uma ferramenta que permita a atualização da informação no Plano de Gestão de Crise, de forma automática, com respetivos milestones e artefactos informáticos definidos, obtendo o consenso dos stakeholders. Espera-se também, que sejam criadas guidelines para desenvolvimento de trabalho futuro. 1.4 Metodologia de Investigação A abordagem de investigação seguida para desenvolver o projeto de dissertação foi o ciclo PDCA – Plan, Do, Check, Act, o qual se foca na melhoria contínua, em prol da maximização da produtividade. Caracteriza-se por permitir o controlo e melhoria de processos, levando a que as organizações percebam que não existe um ponto de partida nem um fim de uma atividade, mas sim um ciclo para que ocorra um processo de melhoria contínua. Criado em 1950, este pilar da melhoria contínua, conhecido também por ciclo de Deming (Strotmann et al., 2017), é baseado num método científico que facilita a coesão e o alinhamento dentro de uma organização, quanto à maneira mais correta de atuar perante determinadas situações. De acordo com Jagusiak-Kocik (2017), este ciclo divide-se em quatro diferentes fases, direcionadas para a resolução de problemas e respetivo acompanhamento, como se pode visualizar na Figura 3. 6 Figura 3 - Ciclo PDCA, indicando a fase crítica Fonte: Adaptado de Jagusiak-Kocik (2017) • Planeamento ( Plan ) – O primeiro passo deste ciclo está associado ao reconhecimento da possibilidade de mudanças. Nesta fase são estabelecidas as oportunidades de melhoria existentes e é elaborado o plano de ação que permite atingir os objetivos propostos. Passa então pela identificação das causas do problema, e propõem-se hipóteses de solução para o mesmo; • Fazer ( Do ) – Nesta segunda fase do ciclo, o plano de ação desenvolvido no Planeamento é implementado, tendo em consideração a possibilidade de se darem acontecimentos inesperados; • Verificar ( Check ) – Nesta fase são realizados um conjunto de testes, com o intuito de aferir se as soluções implementadas na fase anterior, resolvem as oportunidades de melhoria levantadas, verificando se os objetivos propostos foram ou não alcançados. Caso os objetivos tenham sido cumpridos, então prosseguir-se-á para a última fase do ciclo, caso contrário deverá regredir-se até à primeira fase; • Agir ( Act ) – Por fim, procura-se desenvolver métodos para uniformizar e implementar a 100% as soluções criadas. Por norma, o ciclo é repetido com o objetivo de obter novos dados para que sejam novamente testadas as melhorias implementadas. Depois desta breve introdução teórica sobre o ciclo PDCA, é agora apresentado um cariz mais prático do mesmo, de forma a dar a compreender como foi organizada cada etapa, com o intuito de desenvolver o projeto em questão. Assim sendo, iniciou-se a primeira fase ( Plan ) com uma abordagem de diagnóstico. A mesma encontrase descrita no capítulo 3 deste documento. É de salientar que nesta primeira fase foi feito um estudo de todos os recursos já existentes e de como se processa a informação nos mesmos. Numa fase inicial recorreu-se à linguagem BPMN para proceder à descrição do processo que é alvo de melhoria. De forma a conduzir este estudo, a base de dados que suporta toda a informação em questão foi analisada, com 7 o intuito de perceber se a mesma tem associadas oportunidades de melhoria. Para tal, foi necessário perceber o modelo de dados que serve de base a esta base de dados. De seguida, foi feita uma análise dos requisitos que a nova ferramenta de automatização deverá integrar, sendo que os mesmos foram criados pelo próprio departamento da ARC. Por último foram levantadas as oportunidades de melhoria, que por sua vez serão o input para a próxima fase do ciclo. A segunda fase do ciclo ( Do ) é caracterizada por uma das etapas mais importantes visto que se vai proceder à realização do protótipo da ferramenta de automatização, estando associada ao capítulo 4 deste documento. O mesmo inicia-se pela sugestão de hipóteses de solução para cada uma das oportunidades de melhoria identificadas, sendo que as mesmas deveriam dar resposta às oportunidades de melhorias apontadas anteriormente, mas também cumprir com os requisitos definidos pela organização. A terceira fase ( Check ), passou pela análise de KPI’s indicados, de acordo com o teor do projeto, de forma a perceber se o artefacto tecnológico criado efetivamente responde às necessidades de melhoria apontadas na primeira fase do projeto. Por último, a quarta fase do projeto ( Act ) caracterizou-se pela implementação da ferramenta desenvolvida na segunda fase, de uma forma normalizada e uniforme, correspondendo ao capítulo 5 desta dissertação. A ideia passou por obter um artefacto tecnológico que dê resposta às várias oportunidades de melhoria identificadas, e que cumpra com os requisitos definidos pela empresa. 8 2. ENQUADRAMENTO TEÓRICO O presente capítulo apresenta e analisa o estado da arte que suporta todo o projeto de dissertação. Primeiramente, é conduzido um enquadramento teórico sobre crises organizacionais. De seguida, aborda-se a automatização dos fluxos de informação, detalhando as etapas do processo e as ferramentas utilizadas. Posteriormente, são explorados os conceitos e modelos relacionados às bases de dados, nomeadamente o modelo relacional. No final, é apresentado o método de decisão utilizado para escolher a ferramenta de automatização que suporta todos os automatismos criados para responder às necessidades deste estudo. 2.1 Crises organizacionais As crises organizacionais são eventos inevitáveis no contexto empresarial, podendo surgir a partir de fatores internos ou externos, impactando a estabilidade e desempenho das organizações. Este subcapítulo inicia-se com a definição das crises organizacionais, através do subcapítulo 2.1.1, explorando as diferentes tipologias de crise e os seus efeitos sobre empresas. Em seguida analisa-se a gestão de crises, no subcapítulo 2.1.2, abordando as principais estratégias adotadas pelas empresas para lidar com eventos críticos e minimizar danos. Por fim, discute-se a comunicação em crise, no subcapítulo 2.1.3, enfatizando a importância de um planeamento comunicacional estruturado e da transparência na relação com Stakeholders . 2.1.1 Definição e Tipos de Crise Este subcapítulo surge com o intuito de explorar o conceito de crise, um termo frequentemente utilizado em contextos de gestão de emergência e administração organizacional. Uma crise pode ser entendida como a perceção de um evento imprevisível que ameaça as expectativas dos stakeholders e pode impactar seriamente o desempenho de uma organização, gerando resultados negativos (Youngblood, 2010). Por sua vez, Bundy et al. (2017) defende que uma crise organizacional é um evento, de grande relevo, inesperado e potencialmente perturbador, podendo comprometer os objetivos de uma organização e ter implicações nas relações com stakeholders . De acordo com Gavra e Akimovich (2022), existem dois tipos de crise, aquelas com danos imediatos e definidos e outras com danos retardados e indefinidos. O primeiro grupo de crises inclui eventos cujas consequências são visíveis, explícitas e mensuráveis. Por sua vez, as crises com danos atrasados e indefinidos são fundamentalmente diferentes na sua natureza. O problema com tal crise, reside no facto 9 de que ela pode trazer consequências diretas e indiretas a médio/longo prazo, cujos danos podem ser bastante maiores. No momento de crise, e num curto período após a mesma, as consequências não são, de todo, óbvias. Assim, o perigo das mesmas reside no facto de, após a ocorrência do evento e a tomada de medidas corretivas pela organização, ser difícil até para os especialistas avaliar inequivocamente as consequências no futuro. Segundo Frandsen and Johansen (2017), é fundamental considerar a categorização de crises organizacionais em clusters ou famílias. Estes clusters facilitam o entendimento e a gestão de situações críticas numa empresa. Os quatro principais tipos incluem: • Crises relacionadas com produtos: Este tipo de crise destaca a importância da qualidade e segurança no desenvolvimento e manufatura de produtos; • Crises relacionadas com o local de trabalho: Estas crises salientam a necessidade de medidas de segurança rigorosas e manutenção eficaz das instalações e equipamentos; • Crises relacionadas com pessoas: Estas situações podem afetar profundamente o capital humano da organização e requerem uma gestão eficiente dos recursos humanos e de tecnologias de informação; • Crises Corporativas: Frequentemente, dão-se como sendo as crises de maior complexidade, requerendo uma gestão estratégica e adaptativa com o intuito de salvaguardar a sustentabilidade e a integridade corporativa a longo prazo. 2.1.2 Gestão de Crises Uma gestão de crise eficiente é um dos principais tópicos no que toca a dar uma resposta eficaz a uma dada emergência. De acordo com Bundy et al. (2017), os fatores que contribuem na prevenção de crises, mais concretamente, a preparação organizacional e positiva relação com stakeholders, podem também facilitar na resposta a um cenário de crise. Por sua vez, a gestão de crises pode ser entendida como um conjunto de abordagens e métodos, utilizados quando os procedimentos habituais da empresa não são suficientes para dar resposta à continuidade de negócio de forma totalmente íntegra, e o seu principal objetivo passa pela minimização dos impactos sofridos devido a uma crise (Vašíčková, 2020). A gestão de crises nem sempre permite evitar a crise, mas as organizações podem geri-la de forma mais eficiente (Mitroff et al., 1988). Ao abordar este conceito é quase imperativo referenciar o facto de ser necessário adotar um estilo de gestão bastante proativo, em que de forma quase diária, são detetados sinais específicos de que se está 10 perante um cenário de emergência. Esse papel na gestão de crises é desempenhado por uma equipa de crise, capaz de responder de forma eficaz e flexível à situação (Mitroff et al., 1988). A gestão de crises pode ser caracterizada por cinco diferentes abordagens, mas o foco está assente em somente duas delas: reativa e proativa. Na Figura 4, encontram-se as abordagens propostas por Sahin et al. (2015). Figura 4 - Abordagens de gestão de crises Fonte: Adaptado de Sahin et al. (2015) A opção por focar apenas nas abordagens reativa e proativa justifica-se pelo facto de estas representarem, respetivamente, os dois polos mais relevantes e contrastantes da gestão de crises. A abordagem reativa reflete a forma tradicional de lidar com crises após a sua ocorrência, sendo ainda muito comum em organizações que não possuem uma cultura de planeamento preventivo. Já a abordagem proativa representa uma mudança de paradigma, centrada na antecipação de riscos e na preparação prévia para cenários adversos. Assim, estas duas abordagens permitem uma análise mais aprofundada e comparativa entre atitudes defensivas e preventivas perante contextos de crise, sendo por isso as mais relevantes para os objetivos do presente trabalho. A abordagem reativa na gestão de crises é geralmente entendida como um conjunto de procedimentos e princípios que auxiliam na resolução da crise e na estabilização do negócio afetado (Sahin et al., 2015). Esta abordagem começa com a identificação da crise, tendo como principal objetivo a sua contenção. Em seguida, a crise é analisada em detalhe, permitindo a identificação das suas causas. Com base nessas análises, são determinadas as ações corretivas. Um elemento essencial deste processo é a aprendizagem organizacional, ou seja, as ilações retiradas das crises, que fornecem à organização insights valiosos para medidas e estratégias futuras (Vasickova, 2020). 17 Tabela 1 - Power Automate: Tipos de fluxos Fonte: Microsoft (2016) Tipo de fluxo Objetivo da automação Casos de utilização Fluxos baseados em eventos Automatizar tarefas acionadas por eventos específicos, como a receção de notificações ou a interação com sistemas externos. Exemplos incluem a chegada de um email de um remetente específico ou uma menção à empresa em redes sociais. Fluxos instantâneos Executar ações repetitivas ou pontuais de forma imediata com o clique de um botão. Exemplos incluem enviar lembretes à equipa ou iniciar ações no Teams ou SharePoint a partir de dispositivos móveis. Fluxos agendados Automatizar tarefas recorrentes com base em horários predefinidos. Exemplos incluem o carregamento diário de dados para uma base de dados ou SharePoint. Visual Basic for Applications O VBA ( Visual Basic for Applications ) é uma linguagem de programação desenvolvida pela Microsoft , integrada ao ambiente do Office (como Excel, Word , Access …). Segundo Hyde & Maier (2006), a sua utilização contribui para a resolução de problemas, permitindo a criação de ferramentas de software para soluções organizacionais. O VBA foi introduzido como parte integrante do Microsoft Excel em 1993, substituindo a linguagem de macros anteriormente utilizada. A comunidade de programadores acolheu esta inovação de forma positiva, consolidando o VBA como um padrão para a automação de tarefas no Excel e motivando a sua incorporação em outras plataformas do Office . A expansão do VBA continuou em 1995, com o lançamento da versão 5.0, que passou a cobrir toda a gama de soluções do Microsoft Office 97. Em 1997, a Microsoft licenciou o VBA para poder ser usado por outros desenvolvedores de software (Lomax, 1998). A programação em VBA no Excel destaca-se como uma ferramenta eficaz para suprir limitações das funcionalidades padrão da aplicação. Para Alexander & Kusleika (2019), a linguagem VBA permite automatizar tarefas, promover um trabalho mais eficiente e aumentar a produtividade. Carvalho (2017), reforça essa perspetiva ao apontar que o VBA possibilita a personalização e a extensão das funcionalidades do Excel através da programação. Neste sentido, a linguagem permite o desenvolvimento de aplicações específicas, como funções e procedimentos que respondem às necessidades da análise de dados. As instruções de código escritas em VBA formam o corpo de uma macro . Uma macro pode ser descrita como um pequeno programa que contém uma lista de instruções a realizar no Excel. Por ser um 18 repositório de operações, uma macro pode executar um conjunto de tarefas através de um único procedimento que pode ser invocado rapidamente. As macros podem ser classificadas em dois tipos: sub-rotinas (ou subprocedimentos) e funções. As sub-rotinas são blocos independentes de código que executam tarefas específicas no Excel, mas não retornam valores. Estas são identificadas pela palavrachave Sub no início do bloco e finalizadas com a instrução End Sub . As funções, por outro lado, também executam ações específicas, mas diferenciam-se por retornar um valor como resultado. Estas são definidas com a palavra-chave Function seguida de um nome e finalizadas com a instrução End Function . Além das macros , o VBA permite o desenvolvimento de UserForms , que são formulários personalizados utilizados para estabelecer uma interface com o utilizador. Os UserForms são compostos por elementos visuais, como botões, caixas de texto, listas suspensas e rótulos, que podem ser configurados para atender a necessidades específicas. A sua criação no VBA é iniciada através da inserção de um formulário no ambiente do editor de VBA, onde os elementos visuais podem ser arrastados e posicionados. Cada UserForm é associado a uma ou mais macros , que definem as ações a serem executadas quando o utilizador interage com os elementos do formulário. Por exemplo, ao clicar num botão, uma macro pode ser invocada para realizar cálculos, transferir dados para uma folha de cálculo ou gerar relatórios automaticamente. Na Tabela 2 encontram-se listadas as funcionalidades dos principais controlos da caixa de ferramentas, conforme descrito por Alexander & Kusleika (2019). 19 Tabela 2 - Principais objetos nos userforms do VBA Fonte: Elaboração Própria Objeto Descrição Label Exibe textos fixos, sendo usado para identificar campos ou instruções para o utilizador. TextBox Permite ao utilizador inserir informações como números, texto ou datas. CommandButton Exibe um botão que pode despoletar a execução de uma macro , quando o utilizador clica no mesmo. ComboBox Oferece uma lista suspensa de opções para o utilizador selecionar. ListBox Exibe uma lista de itens. CheckBox Apresenta uma caixa com a funcionalidade binária. OptionButton Exibe várias opções a partir das quais o usuário pode escolher apenas uma. Frame Permite o agrupamento gráfico ou funcional de um conjunto de controlos. Image Utilizado para apresentar uma imagem decorativa. ToggleButton Botão que alterna entre dois estados, podendo ser ativado ou desativado pelo utilizador. MultiPage Permite a exibição de vários separadores. Microsoft Excel O Microsoft Excel é um software que faz parte de um conjunto de ferramentas do Office , caracterizado por ser uma poderosa folha de cálculo que oferece diversas funcionalidades para o tratamento, simulação, análise, partilha e proteção de dados (Pinto, 2011). Este programa permite a execução rápida de cálculos e recálculos de dados através de funções ou fórmulas existentes no programa (Held & Richardson, 2018). O Microsoft Excel foi lançado em 1985 para computadores Macintosh , representando uma evolução significativa face às folhas de cálculo disponíveis na época, como o Lotus 1-2-3. Devido à sua simplicidade de utilização e interface gráfica, o Microsoft Excel estabeleceu-se rapidamente como uma ferramenta relevante no mercado de softwares para análise de dados. Em 1987, o software foi disponibilizado para o sistema operacional Windows . Desde então, o Microsoft Excel tem recebido várias atualizações, incluindo novas funcionalidades projetadas para atender às necessidades de utilizadores e organizações. Entre as funcionalidades mais recentes, destaca-se o Office Scripts , introduzido como parte da integração com o Microsoft 365. Essa ferramenta permite a automação de tarefas através de scripts escritas em TypeScript , uma extensão da linguagem JavaScript. Ao contrário do VBA, que funciona localmente, as Office Scripts possibilitam a gravação, edição e execução de scripts no Excel Online , ampliando a sua aplicabilidade em cenários baseados na web . Esta funcionalidade é útil no contexto da automatização de 20 processos. Com o Office Scripts , é possível desenvolver fluxos automatizados para processamento de dados, atualizações de relatórios e sincronização de informações entre aplicações do Microsoft 365 . Além disso, a sua integração com o Power Automate permite incorporar os scripts em fluxos de trabalho, o que acabou por ser um dos features que permitiram que este projeto chegasse a bom porto. 2.3 Bases de dados O termo dados pode ser definido como o valor de um atributo de uma entidade. Quando organizados de forma estruturada e sistemática, esses dados constituem uma base de dados (BD), permitindo um uso eficaz e eficiente da informação (Gunjal, 2003). Grant (2004) apresenta os componentes que constituem um sistema de base de dados. A Base de Dados é o local onde se armazenam os dados. O Sistema de Gestão de Base de Dados (SGBD) é o software que possibilita a manipulação e consulta de dados, seja na totalidade ou em subconjuntos específicos. Em alguns softwares , existe também a Aplicação de Base de Dados, um conjunto de programas que atua como intermediário entre o utilizador e o SGBD. Estas podem ser apresentadas no formato de formulários ou relatórios. Por fim, o Utilizador é o responsável por manter o sistema atualizado e funcional, utilizando formulários para ler, inserir e consultar dados, bem como relatórios para apresentar informações processadas. Segundo Coelho (2011), um SGBD disponibiliza linguagens de: • Definição de dados (DDL - Data Definition Language ) - criação e alteração da estrutura da BD; • Consulta de dados (DQL - Data Query Language ) - obter e processar os dados armazenados; • Manipulação de dados (DML - Data Manipulation Language ) - acrescentar dados novos e modificar dados existentes. 2.3.1 Modelo Relacional de base de dados Existem diversos modelos que definem como a informação é organizada internamente numa base de dados, sendo o modelo relacional um dos mais utilizados atualmente. Este modelo foi teorizado por Edgar Frank Codd durante o seu trabalho de pesquisa na IBM. Codd (1990) na sua obra, estabelece algumas regras e definições que caracterizam o modelo relacional. 21 No modelo relacional, toda a informação é armazenada em tabelas, compostas por atributos (colunas) e tuplos (linhas). Cada atributo requer a definição do tipo de dados a ser armazenado, podendo permitir ou não valores nulos. O acesso lógico a qualquer dado na base é feito através da combinação do nome da tabela, da chave primária e do nome do atributo. As associações entre tabelas são definidas pelos relacionamentos, que podem ser classificados em três tipos principais: • Um para Um - Cada valor da chave de uma entidade corresponde a um único valor na outra. Exemplo: relação entre país e presidente. • Um para Muitos - Um valor da chave de uma entidade corresponde a vários valores na outra. Exemplo: relação entre pai e filhos. • Muitos para Muitos - Cada valor da chave de uma entidade pode se associar a vários valores na outra, e vice-versa. Exemplo: funcionários e projetos. A linguagem padrão para sistemas de base de dados relacionais é o SQL ( Structured Query Language ), amplamente utilizada para manipulação, análise e apresentação de dados. Entre os sistemas que utilizam SQL destacam-se Oracle , Sybase , Microsoft SQL Server , PostgreSQL e SQLite (Almeida, 2016). 2.4 Método de Decisão A tomada de decisão é uma componente indispensável da vida humana, presente em todas as etapas e situações do quotidiano (Şahin & Yurdugül, 2018). O processo de decisão requer, como condição essencial, a existência de múltiplas alternativas, em que diversos critérios podem influenciar a escolha. Segundo Saaty (1994), um dos aspetos mais críticos na tomada de decisão consiste na identificação dos critérios mais relevantes para orientar o processo de seleção. Este processo pode basear-se nas perceções e previsões subjetivas do decisor, mas também pode ser estruturado e analisado através de modelos matemáticos. Entre as metodologias analíticas, destaca-se a decisão multicritério, uma abordagem que permite classificar, hierarquizar ou selecionar alternativas com base em critérios previamente definidos (Şahin & Yurdugül, 2018). O método Analytic Hierarchy Process (AHP) é amplamente utilizado para abordar problemas de decisão multicritério. A sua origem remonta à década de 1970, quando Thomas L. Saaty, professor da Universidade da Pensilvânia, desenvolveu este método para auxiliar na tomada de decisões complexas. O método AHP baseia-se na decomposição de problemas em estruturas hierárquicas, permitindo a análise e a priorização de alternativas com base em múltiplos critérios (De Felice et al., 2015). O método 22 permite converter perceções subjetivas em valores numéricos, integrando de forma estruturada avaliações qualitativas e quantitativas (Saaty, 2008). De acordo com Bhushan et al. (2022), o método é particularmente eficaz em ambientes onde os julgamentos humanos, as perceções subjetivas e as consequências a longo prazo desempenham um papel relevante. A sua aplicação estende-se a diversas áreas, desde a logística, educação e resolução de conflitos. 2.4.1 Passos do método de decisão O método AHP organiza-se em quatro passos principais, estruturando o processo de decisão de forma sistemática (Saaty, 2008): 1º Passo – Definição do problema e respetiva estrutura hierárquica O método inicia-se com a definição do problema a ser analisado, seguido da sua decomposição numa estrutura hierárquica de critérios, como ilustrado na Figura 8. Figura 8 - Hierarquia de critérios Fonte: Adaptado de Şahin & Yurdugül (2018) A hierarquia do método AHP organiza-se em vários níveis, começando pelo problema (objetivo) no topo, seguido pelos critérios principais. Abaixo dos critérios, encontram-se os subcritérios, que detalham os fatores avaliados, e, no nível mais baixo, posicionam-se as alternativas de decisão. Utilizando este método, o decisor avalia a importância relativa dos critérios e, em seguida, classifica as alternativas com base nesses critérios. Para tal, são utilizados cálculos matemáticos para sintetizar as preferências e fornecer uma hierarquização final das alternativas (Anderson et al., 2011). Esta estrutura facilita a decomposição de problemas complexos, permitindo visualizar as relações entre os diferentes 23 níveis. Cada critério pode ter um número variável de subcritérios, e todas as ligações entre os níveis garantem a coerência do processo. 2º Passo – Escala de comparação e matrizes comparativas A etapa seguinte foca-se no estabelecimento de prioridades entre os elementos constituintes. Este processo é realizado através de comparações binárias, onde é atribuído um grau de importância relativa entre elementos, utilizando uma escala de 1 a 9 desenvolvida por (Saaty, 1994). Nessa escala, o valor 1 indica que dois elementos têm igual importância, enquanto o valor 9 representa uma preferência extrema de um fator sobre o outro. Saaty (1994) recomenda a utilização de números ímpares para garantir maior consistência e distinção entre os valores atribuídos. A escala de comparação é apresentada na Tabela 3. Tabela 3 - Escala de prioridades de critérios Fonte: Adaptado de Saaty (1994) Escala de prioridades Definição Significado 9 Extremamente importante O critério 𝑖 é absolutamente mais importante que 𝑗. 7 Muito importante O critério 𝑖 é muito mais importante que 𝑗. 5 Importante O critério 𝑖 é mais importante que 𝑗. 3 Moderadamente importante O critério 𝑖 é moderadamente mais importante que 𝑗. 1 De igual importância Os critérios 𝑖 e 𝑗 têm igual importância 2,4,6,8 Valores intermédios Utilizados para representar condições de compromisso entre dois critérios. Valores recíprocos - Se o critério 𝑖 recebe um valor comparado com 𝑗, como reciprocidade, 𝑗 irá receber o recíproco, quando comparado com 𝑖. Sendo C um conjunto de critérios, definido como 𝐶={𝐶𝑗| 𝑗=1,2,…,𝑛}, para 𝑛 critérios, o resultado das comparações de importância é representado por uma matriz 𝐴∈ ℝ𝑛×𝑛, onde cada elemento 𝑎𝑖𝑗 corresponde ao grau de preferência do agente de decisão, como ilustrado na matriz abaixo. 24 (1) A diagonal principal da matriz deve ser sempre preenchida com o valor 1, uma vez que qualquer elemento é igualmente importante em relação a si próprio. Note-se que os valores recíprocos descritos na Tabela 3 estão representados como 1 𝑎𝑖𝑗 . 3º Passo – Síntese dos vetores prioridade Nesta etapa dá-se a síntese dos vetores de prioridade. Esta síntese trata-se de obter os pesos relativos, isto é, o grau de relativa importância entre os critérios constituintes da hierarquia estrutural. O primeiro passo consiste na normalização da matriz (Equação 2): 𝑤𝑖𝑗 = 𝑎𝑖𝑗 ∑ 𝑎𝑖𝑗 𝑛 𝑖=1 (2) Onde: • 𝑤𝑖𝑗 corresponde ao valor normalizado de cada elemento 𝑎𝑖𝑗; • ∑ 𝑎𝑖𝑗 𝑛 𝑖=1 corresponde à soma dos valores de cada coluna. Com a matriz normalizada, calcula-se o vetor de prioridades 𝑤𝑖, que representa o peso relativo de cada critério. O vetor de prioridades é obtido pela média dos valores de cada linha da matriz normalizada, conforme a Equação 3: 𝑤𝑖= ∑ 𝑤𝑖𝑗 𝑛 𝑖=1 𝑛 (3) Note-se que a soma dos pesos deve ser igual a 1 (Equação 4): ∑𝑤𝑖=1 𝑛 𝑖=1 (4) 25 4º Passo – Cálculo da consistência A última etapa do método AHP implica o cálculo da consistência dos valores inseridos na metodologia. O teste da consistência é uma ferramenta útil antes da tomada de decisão pois avalia todo processo realizado e concluí se foi ou não bem realizado, e se os valores inseridos na matriz de comparação são ou não consistentes entre si. Dito isto, o teste da consistência consiste no cálculo numérico do Rácio de Consistência (CR): CR= 𝐶𝐼 𝑅𝐼 (5) O denominador 𝑅𝐼, Random consistency Index , corresponde ao índice de consistência de uma matriz de comparação gerada aleatoriamente. O valor de 𝑅𝐼 depende do número de elementos (𝑛) a serem comparados e é dado pelos valores da Tabela 4: Tabela 4 - Random consistency index Adaptado de Saaty & Vargas (2001) 𝒏 1 2 3 4 5 6 7 8 9 10 𝑹𝑰 0 0 0,52 0,89 1,11 1,25 1,35 1,40 1,45 1,49 O numerador CI, Consistency Index , é o índice de consistência dado por (Equação 6): CI= 𝜆𝑚𝑎𝑥−𝑛 𝑛− 1 (6) O valor 𝜆𝑚𝑎𝑥 corresponde ao maior autovalor da matriz 𝐴, e este é obtido através da Equação 7: 𝜆𝑚𝑎𝑥 = 1 𝑛 ×∑ ∑𝑎𝑖𝑗 ×𝑤𝑗 𝑛 𝑗=1 𝑤𝑖 𝑛 i=1 (7) Se o valor de CR for inferior a 10%, os pesos atribuídos pelo decisor são consistentes. Caso este valor seja superior, o decisor deve rever os pesos que atribuiu aos pares de elementos antes de prosseguir com a análise. Em seguida, é elaborada a matriz global, que consolida os pesos atribuídos aos critérios e as preferências relativas de cada hipótese para cada critério. Com base nesta análise, torna-se possível identificar a alternativa mais adequada para dar resposta ao problema em questão. Neste capítulo, foram abordados os principais fundamentos teóricos que sustentam o presente estudo. Iniciou-se com a clarificação do conceito de crises organizacionais, realçando os seus impactos e a importância de uma resposta estruturada. Em seguida, explorou-se o papel da automatização dos fluxos de informação como suporte à agilidade e eficácia na gestão em momentos críticos. Complementarmente, discutiu-se a relevância dos sistemas de bases de dados, essenciais para a 26 recolha, armazenamento e tratamento da informação que sustenta o processo decisório. Por fim, foi apresentado o método AHP, destacando o seu contributo para a estruturação e hierarquização de critérios na escolha entre alternativas. Esta base conceptual será determinante para a análise desenvolvida nos capítulos seguintes, onde se procura aplicar estas ferramentas e abordagens ao contexto prático da organização em estudo. 33 3.2.2 Definição e Atualização do PGCrise A segunda fase deste processo, destaca-se como sendo a mais crítica na implementação total do PGCrise, e abrange três atividades executadas pela ARC, iniciando-se com a definição dos papéis e responsabilidades e culminando com a gestão de recursos e informação de crise. Definição de papéis e responsabilidades A primeira atividade baseia-se numa framework estruturada, representada na Figura 11 que define os papéis de crise e o fluxo de comunicação entre os mesmos. Figura 11 - Framework de Crise Adaptado de NOS (2024) Como se pode observar, existem 3 áreas distintas: Suporte, Core e Funcionais. As áreas de suporte, como o próprio nome indica, têm como principal objetivo apoiar as atividades centrais do negócio, fornecendo recursos para o funcionamento eficaz da empresa numa situação de crise. Por sua vez, as áreas Core definem o “core business” da empresa, ou seja, estão diretamente relacionadas às atividades essenciais que compõem o propósito principal da organização. Por último, as áreas funcionais são aquelas responsáveis pelo funcionamento operacional diário da empresa, sendo fundamentais para garantir que o trabalho seja realizado com a máxima eficiência possível e dentro dos padrões definidos, aquando de uma crise organizacional. No total, existem sete tipos de papéis distintos, sendo que a maioria conta com substitutos de 1º e 2º nível (1S e 2S). • Gestor de Crise NOS (GC NOS e GC NOS Subs) - Responsável máximo pela gestão de crises, incluindo decisões estratégicas e ajustes na composição das equipas. Este papel deve ser ocupado por um membro da comissão executiva da NOS. 34 • Gestor de Crise NOS Deputy (GC NOS Deputy e GC NOS Deputy Subs) - Assume responsabilidades delegadas pelos Gestores de Crise NOS e também deve pertencer à comissão executiva. • Gestor de Crise (GC, GC1S e GC2S) - Responsável pela gestão de crises nas direções e pela comunicação das ações. Cada direção possui um GC (geralmente o diretor da área), além de GC1S e GC2S (substitutos de 1 e 2º nível). • Supervisor de Incidentes e Crise (SIC, SIC1S e SIC2S) - Monitoriza e controla as informações relacionadas a incidentes. • Gestor de Continuidade de Negócio (GCN, GCN1S e GCN2S) - Gere as atividades específicas para a resolução de crises. Os colaboradores designados devem pertencer à direção associada. • Pivot BCM - Presta suporte especializado às direções sobre metodologias e instrumentos de gestão de crises e continuidade de negócios, além de implementar iniciativas do PGCrise. • Outros - Apoiam, quando necessário, na execução das ações do PGCrise. Com base nessa lógica, a configuração da equipa de gestão de crise pode variar, mas deve seguir três premissas: ✓ As Áreas Core devem estar obrigatoriamente representadas na equipa de gestão de crise; ✓ Algumas Áreas de Suporte devem estar sempre representadas na equipa de gestão de crise, enquanto outras são opcionais, em função do cenário de crise; ✓ As Áreas Funcionais são opcionais, sendo nomeadas para a equipa de gestão de crise apenas quando necessário, consoante o cenário de crise. Durante uma crise, o organigrama de crise prevalece sobre as hierarquias funcionais habituais. Cada papel tem responsabilidades específicas e inalteráveis, independentemente do nível de crise. Através dos organigramas, são definidos, para cada direção, os colaboradores associados às posições, sendo que um colaborador efetivo não deve assumir mais do que um papel simultaneamente nem atuar como substituto de outro. Definir regras e procedimentos A segunda atividade no processo de gestão de crise abrange três conceitos principais: avaliação de uma crise, escalamento e notificação, e comunicação em crise. 35 A avaliação de uma crise é realizada através de uma matriz de avaliação de impactos e níveis de crise, representada na Figura 12, que classifica os cenários em quatro níveis de gravidade. É considerada uma crise qualquer cenário que atinja um nível igual ou superior ao amarelo, e um incidente quando o cenário em questão assume cor azul. Figura 12 - Matriz de avaliação de impactos e níveis de crise Adaptado de (NOS, 2024) O escalamento é um sistema de comunicação vertical destinado à tomada de decisões e à partilha de responsabilidades entre os níveis hierárquicos da gestão de crise. Já a notificação visa informar os stakeholders internos, podendo ocorrer de forma difusa (listas de distribuição) ou ponto-a-ponto (telefone ou SMS). As regras de escalamento estão diretamente associadas ao nível de crise: • Crise Amarela - Escalamento até o gestor de continuidade de negócio da área; • Crise Laranja - Escalamento até o gestor de crise ou coordenador da equipe de crise; • Crise Vermelha - Escalamento até o gestor de crise NOS ou gestor de crise NOS Deputy. As notificações ocorrem em três momentos obrigatórios, como se pode verificar através da Figura 13. Figura 13 - Momentos de Crise Adaptado de (NOS, 2024) As notificações são enviadas simultaneamente por dois canais: email e SMS. Existe ainda a possibilidade de utilização do WhatsApp, sendo que este envio de emails e SMS de notificação (ou WhatsApp) deve ser executado com base nas Listas de Distribuição definidas para o efeito, que se encontram divididas entre várias ferramentas. 36 Esta segunda fase de definição de regras e procedimentos tem três principais objetivos: garantir a gestão eficaz de todos os stakeholders , controlar a informação transmitida e promover a coerência nas comunicações com as diversas partes interessadas. Para tal, é necessário identificar os stakeholders relevantes, designar um interlocutor único para cada um deles, definir os canais de comunicação preferenciais e estabelecer as mensagens e materiais de suporte adequados. As regras gerais de comunicação variam de acordo com o nível de crise definido na avaliação. As crises de nível laranja e vermelho, devido à sua gravidade, são as mais propensas à ativação da comunicação em crise. No caso de uma crise vermelho, a comunicação em crise deve seguir uma framework específica adicional, projetada para facilitar a gestão ao consolidar, num único documento, todas as ações fundamentais, templates de comunicação e contactos necessários. Gerir recursos e informação A terceira atividade, designada como Gestão de Recursos e da Informação de Crise, está relacionada aos recursos de suporte à gestão de crise, que devem ser constantemente atualizados. Esses recursos incluem o Crisis Pocket Guide , o Crisis Conference Bridge juntamente com o WhatsApp, e o Cartão SIM de Contingência. O Crisis Pocket Guide é um documento desdobrável que contém contactos úteis para a gestão de crise. Está disponível para todos os membros envolvidos na gestão de crise e deve estar sempre na posse do colaborador. Existem duas versões do documento: uma executiva e outra não executiva, cada uma com conteúdos específicos adaptados aos diferentes papéis na gestão de crise. O Crisis Conference Bridge e o WhatsApp têm como principal objetivo fornecer um serviço interno de conferência por telefone. Esses recursos permitem que os GCs das diversas áreas comuniquem entre si, com o coordenador da equipa de crise e também com os GCs da NOS. Por fim, o Cartão SIM de Contingência permite realizar e receber comunicações em cenários de falha da rede móvel NOS, utilizando uma rede alternativa. O uso desse cartão é restrito a comunicações em contexto de crise e está limitado a papéis específicos da gestão de crise. 3.2.3 Teste e Melhoria do PGCrise Assim como na primeira fase deste processo de implementação, a terceira envolve a execução de uma única atividade: a simulação do PGCrise criado. Através de um conjunto de testes e simulações, avaliase o plano atualmente implementado, identificando possíveis melhorias que, dependendo da sua viabilidade e benefício, poderão ser implementadas. 37 3.2.4 Processo de Gestão da informação inerente ao PGCrise Quando ocorre uma crise, o PGCrise é automaticamente ativado, resultando na substituição dos Organigramas normais da organização pelos Organigramas de Crise. Para garantir a eficácia dessa transição, é essencial que todas as informações relacionadas direta ou indiretamente aos organigramas estejam constantemente atualizadas. Os Organigramas de Crise estão organizados por áreas específicas da NOS, com cada área abrangendo os vários papéis de crise. Esses papéis, por sua vez, são atribuídos a colaboradores específicos e vinculados a diversas atividades críticas que devem ser realizadas durante uma crise. Seguindo essa lógica, os colaboradores são incluídos em diferentes listas de distribuição, permitindo que sejam devidamente notificados em caso de crise. Por ser uma informação crítica, as listas devem ser atualizadas continuamente para refletir a situação atual dos colaboradores da empresa. Em cenários de emergência, qualquer falha na transição de informações ou na execução das atividades críticas pode comprometer a resposta necessária para a gestão da crise. Parâmetros Gerais do Processo O processo de atualização da informação de crise, é um procedimento bastante robusto, que envolve a atualização de uma série de ferramentas de suporte à informação. Com o intuito de dar uma visão mais pormenorizada daquilo em que consiste este processo apresenta-se a Tabela 6 que enumera os vários parâmetros deste processo e respetivas definições. Tabela 6 - Parâmetros gerais e definição Fonte: Elaboração Própria Parâmetros Gerais do Processo Definição Periodicidade do Processo Este é um processo de bastante relevância devido não só à importância dos conteúdos em questão, mas também à periocidade inerente ao mesmo. Trata-se de um processo cujo início está dependente da entrada de certos e-mails. Assim sendo, não é possível definir com exatidão a periodicidade com que se dá o mesmo, podendo variar de tempo a tempo. No entanto, de forma geral, pode-se afirmar que a necessidade de atualização da informação dá-se uma vez por semana. Inputs e Outputs Tal como qualquer outro processo, existem inputs , que levam à iniciação do processo de atualização de informação, os mesmos são: Alterações a nível dos papéis de gestão de crise (Saída ou Entrada de colaboradores do PGCrise), alteração da estrutura organizacional, solicitações de 2ªvias de cartões de contingência e necessidade de atualização anual. Como outputs do processo tem-se a informação atualizada dos vários recursos e ferramentas de suporte à informação de Crise. 38 Ferramentas e sistemas de suporte O objetivo principal com a execução deste processo é que a informação presente nas ferramentas de suporte à informação de Crise esteja sempre o mais atualizada possível. Para tal, ao longo do processo vão ser então utilizados 8 recursos, sendo estes a Mailbox BCM, Portal BCM (Utilização da aplicação Confluence ), que serve de suporte de informação aos Organigramas de Crise da NOS. Além destas, existem as bases de dados, estruturadas em ficheiros Excel, duas aplicações corporativas, da OutSystems, o GUIA Corporativo (SAP) e o SMSPro, A sexta ferramenta utilizada, é o Google Contacts, seguida do sistema de suporte utilizado, a aplicação WhatsApp. A última ferramenta de suporte de informação é um ficheiro Excel, de nome “Crisis Pocket Guide”. Subprocessos O processo de atualização da informação de crise é um processo enorme, com um número de passos bastante alargado. De forma a ter uma melhor perceção daquilo que está a sofrer atualização e o porquê de isso acontecer, dividiu-se este processo geral em 5 subprocessos diferentes, sendo estes: Identificação da necessidade de atualização; Atualização das bases de dados; Atualização dos Organigramas presentes no Portal BCM; Atualização das listas de distribuição nos respetivos recursos e Gestão dos cartões de contingência. 3.2.5 Descrição Processual A Figura 14 ilustra o fluxo do processo de atualização do PGCrise, detalhando as etapas de manutenção, desde a identificação de necessidades de alteração até a atualização das listas de distribuição. Para acompanhar a explicação apresentada neste subcapítulo, é necessário considerar não apenas a figura anteriormente mencionada, mas também o Apêndice A – Fluxograma do processo de atualização da informação de Crise, que permite a visualização deste mesmo fluxograma, mas num nível micro, deixando claras as ações associadas a cada subprocesso. Figura 14 - Processo em BPMN representativo do Processo Geral Fonte: Elaboração Própria O processo inicia-se com a identificação das necessidades de alteração, que pode ocorrer por iniciativa da área de ARC (Auditoria, Risco e Compliance ), ou das restantes áreas de negócio da NOS. Este 39 subprocesso, denominado “Identificação de Necessidades de Alteração”, inclui as atividades que marcam o início do processo, seja pela entrada e saída de colaboradores, que exige alterações na estrutura de crise de uma ou mais direções, seja pela atualização geral anual conduzida pela ARC. A necessidade de atualização constante é evidente, dado a frequência de mudanças na equipa. Paralelamente, a atualização anual, conduzida pela ARC, funciona como uma validação das informações e estruturas de crise, garantindo a sua conformidade com a organização. Para responder a essas necessidades, o gestor da informação que consta no PGCrise acede diariamente a uma mailbox específica ([email protected]), onde são centralizadas as solicitações relacionadas ao PGCrise. No caso da atualização anual, a ARC contacta elementos-chave de cada área para assegurar que a informação de crise esteja alinhada com a estrutura organizacional da empresa. O segundo subprocesso, denominado “Atualizar o Portal BCM”, consiste na atualização da informação armazenada no Portal BCM, localizado na aplicação Confluence . Esta atualização é necessária quando ocorrem alterações nos papéis que compõem o PGCrise. Como resultado, o Portal BCM é ajustado para refletir as mudanças estruturais realizadas nos organigramas de crise. A este subprocesso segue-se a atualização das bases de dados. Este é um subprocesso crucial, pois o repositório de dados “Organigramas”, criado em Excel, armazena as características de crise de cada colaborador presente no PGCrise, bem como as listas de crise a que estes devem pertencer. Além disso, mantém um registo dos colaboradores que já fizeram parte do plano, mas que atualmente não o integram. Este subprocesso é desencadeado por alterações na estrutura de crise, como a entrada ou saída de colaboradores, a perda de um cartão de contingência ou a troca de papéis de crise. O resultado é um repositório de dados atualizado que reflete o panorama atual do PGCrise, com colaboradores da NOS e listas de distribuição correspondentes. O subprocesso subsequente refere-se à solicitação dos cartões de contingência, que, como o próprio nome indica, são utilizados exclusivamente em situações de falha da rede NOS. Estes cartões são solicitados quando não existem unidades suplentes em stock . Nesse caso, o gestor da informação de crise é responsável por solicitar novos cartões a uma área de negócio denominada “Regulação”, que atua como intermediária com uma operadora externa. Após a receção dos cartões pela NOS, estes são encaminhados para a ARC, que os distribui aos colaboradores previamente incluídos no PGCrise. Este processo requer uma troca constante de emails, bem como a atualização contínua das bases de dados, devido às alterações nos contactos telefónicos dos colaboradores envolvidos. É importante referir que 40 nem todos os papeis de Crise têm direito a cartão de contingência, pelo que esta atividade nem sempre se dá. O último subprocesso, denominado “Atualizar Listas de Distribuição”, consiste na revisão e atualização das listas de colaboradores em duas aplicações corporativas (GUIA e SMSPro), das listas de contactos de crise e, por fim, do Crisis Pocket Guide . 3.2.6 Fluxo de Informação O fluxo de informação refere-se à troca de dados, entre diferentes recursos, departamentos e sistemas dentro da própria organização. No contexto deste projeto, o fluxo engloba o processo de atualização da informação de crise, e está detalhado no Apêndice B - Fluxo de informação do processo de atualização do PGCrise. Recomenda-se que a leitura deste subcapítulo seja acompanhada pelo fluxograma presente no apêndice referido, visto que o mesmo, ilustra o fluxo de informação mencionado. O processo inicia-se com a verificação da mailbox BCM, utilizada para identificar triggers que possam desencadear a atualização da informação de crise. Estes triggers incluem entradas ou saídas de colaboradores, alterações no número de contingência ou mudanças nas características das funções de crise desempenhadas. As informações provenientes dos emails são refletidas no Portal BCM, gerido na aplicação Confluence , onde estão armazenados os Organigramas de Crise da empresa. Quando a necessidade de atualização é identificada pela ARC, durante a revisão anual proativa, esta é responsável por contactar as áreas de negócio relevantes e realizar as alterações necessárias diretamente no Portal BCM. Posteriormente, as informações do Portal BCM são transmitidas para o repositório de dados principal, BD_RecursosPorPapel , que centraliza toda a informação de crise, incluindo o tipo de alteração realizada, o nome do colaborador envolvido, o seu papel no PGCrise, e a direção a que pertence. Para complementar esses dados, é consultado o guia corporativo (SAP), que fornece informações adicionais, como o username e o telefone corporativo do colaborador. Por fim, para garantir a atualização de todos os recursos envolvidos, o repositório de dados é utilizado como fonte de informação, alimentando os sistemas correspondentes com conteúdos específicos, conforme detalhado na . 41 3.2.7 Modelo de dados A Tabela 7 representa um esquema representativo do modelo de dados atual. A compreensão deste modelo é fundamental para avaliar o estado atual do sistema, identificando as suas limitações. Tabela 7 - Inputs e outputs de cada recurso Fonte: Elaboração Própria Recurso Input Output Descrição Mailbox [email protected] Email Informação sobre alteração da estrutura de crise, e sobre os colaboradores afetados Caixa de e-mail utilizada para tratar todo o topo de informações associadas ao PGCrise Portal BCM Informação sobre alteração da estrutura de crise, e sobre os colaboradores afetados Nome Colaborador, Papel de Crise e Direção do mesmo Ferramenta alojada na aplicação Confluence , sendo utilizada por toda a empresa para consulta da informação de Crise GUIA Corporativo (SAP) - Username , Telefone Corporativo Ferramenta própria da organização, que contem algumas das listas de distribuição. BD_RecursosPorPapel Nome Colaborador, Username , Telefone Corporativo, Papel de Crise e Direção a que pertence Número BCM, Listas de distribuição a que o colaborador em questão pertence Ficheiro Excel que disponibiliza uma lista de todos os colaboradores com papel ativo e inativo no PGCrise CartoesBCM_NvCartoes&2vias Nome, Username , Estado do Cartão, Número BCM Cartões BCM_NvCartoes&2vias atualizada Ficheiro Excel que disponibiliza uma lista com os cartões SIM atribuídos a cada colaborador Listas GUIA Corporativo Nome, Username , Lista a que pertence Listas de GUIA atualizadas Lista de contactos de Crise disponível na aplicação GUIA Corporativo Listas SMSPro Nome, Número Profissional, Número BCM, Lista a que pertence Listas de SMSPro atualizadas Lista de contactos de Crise disponível na aplicação SMSPro Activity Director Nome, Username , Endereço de Email Profissional, Número BCM, Estado do Pedido Activity Director atualizado Lista de colaboradores ativos no PGCrise, atualizada pelo departamento de IT Lista Contactos Google Nome, Endereço de Email Profissional, Número Profissional, Número BCM Lista de Contactos Google atualizada Lista dos contactos de Crise, na interface Google Contacts Listas WhatsApp Nome, Número Profissional, Número BCM Grupo de Crise de WhatsApp atualizado Grupos de WhatsApp, onde estão inseridos todos os contactos de Crise. Recurso alternativo para quando a rede NOS estiver em baixo Crisis Pocket Guide Nome, Número Profissional, Número BCM, Papel de Crise e Direção Crisis Pocket Guide atualizado Documento Excel que disponibiliza todos os elementos do PGCrise das áreas Core da NOS 42 Figura 15 - Modelo de dados atual Fonte: Elaboração Própria O modelo de dados é constituído por dois ficheiros: Cartões BCM e Organigramas. Cada objeto deste sistema possui atributos, que são características intrínsecas e específicas de cada um. O modelo conceptual de dados até à data pode ser considerado rudimentar, uma vez que utiliza apenas dois objetos de dados, cada um com diversos atributos associados. Atualmente, existem apenas dois ficheiros que funcionam como repositórios de informação de crise. O ficheiro principal, denominado “BD_RecursosPorPapel” ou “Organigramas”, armazena toda a informação de crise relacionada aos colaboradores incluídos no PGCrise, definindo os organigramas de crise da empresa. Além deste, existe um outro ficheiro adicional “Cartões BCM” que armazena informações sobre os cartões BCM, os quais são atribuídos aos colaboradores que desempenham papéis de crise que exigem o uso desses cartões de contingência. 3.3 Oportunidades de Melhoria Com base em toda a informação até aqui referenciada, foram identificadas diversas oportunidades de melhoria, seja por identificação direta ou pela colaboração com processos de automatização associados ao projeto. As oportunidades de melhoria foram agrupadas em quatro categorias: • Centralização da informação de crise; • Estruturação da informação de crise; 49 que cada papel de crise corresponde a uma linha. Cada linha deve incluir variáveis específicas associadas ao colaborador correspondente: • Direção; • Papel de crise; • Nome do colaborador; • Username ; • Email de trabalho; • Estado do papel de crise; • Estado de atividade do colaborador; • Data de início e fim do papel; • Número de telemóvel profissional; • Direito a cartão BCM; • Número de telemóvel BCM (se aplicável); • Direito a eSIM; • Listas de distribuição. Uma análise inicial ao repositório de dados revelou uma insuficiência clara de informação. Não existem restrições quanto à adição de novas variáveis, desde que sejam relevantes no contexto de gestão de crise e contribuam para o processo de automatização, sendo este um ponto a considerar em fases mais avançadas do projeto. Para além do ficheiro “BD_RecursosPorPapel”, são utilizados outros dois ficheiros Excel: “BD_CartoesContingencia” e “BCM_PedidosDeCartão”. Estes ficheiros auxiliam o gestor da informação de crise da NOS no controlo dos cartões BCM atribuídos aos colaboradores dos organigramas de crise. Contudo, a utilização de dois ficheiros resulta em redundância na informação sobre os cartões BCM, tornando necessário consolidar essa informação num único repositório. 4.1.2 Estruturação na troca de informação entre áreas O processo de atualização de informação é realizado manualmente, não havendo qualquer tipo de estruturação na troca de conteúdo entre as direções da NOS. Conforme mencionado no capítulo anterior, uma das melhorias propostas é a criação de uma estrutura base para essa troca de informações, facilitando a automatização do processo. Para que a informação seja facilmente trabalhada através de automatismos, a empresa definiu como requisito a adoção de um sistema tabelar no corpo dos emails, quando houver necessidade de comunicação com as áreas sobre um ou mais colaboradores. Essa 50 abordagem oferece aos diferentes departamentos uma visualização clara das características dos colaboradores envolvidos. Adicionalmente, é necessário identificar de forma única os colaboradores em processo de saída da empresa. Na entrada de emails na mailbox de crise, cada colaborador deve ser inequivocamente identificado. A organização determinou que o email de trabalho será a característica usada para essa identificação, devendo estar obrigatoriamente presente em todas as comunicações que sinalizem a saída de um colaborador. 4.1.3 Alteração Processual No que concerne à atualização da informação de crise, concluiu-se previamente que esta apresenta várias limitações. A ordem implementada não garante que todos os recursos sejam atualizados de forma consistente com o repositório de dados master . Além disso, algumas ações não são realizadas de forma sistematizada e, por fim, existe a utilização de recursos com baixa integração com as aplicações Microsoft , o que pode ser prejudicial, dado que a empresa utiliza exclusivamente ferramentas do Office 365 . Nesse contexto, a equipa da ARC definiu dois requisitos fundamentais para a reformulação do processo: a manutenção de todas as atividades atualmente realizadas e a obrigatoriedade de que o repositório de dados master seja a referência principal para a atualização de todos os recursos. 4.1.4 Automatização das tarefas de gestão da informação de suporte ao PGCrise Por último, em relação à automatização das tarefas que envolvem a atualização da informação de crise, a única necessidade denotada pela organização foi proceder à automatização com base no ficheiro Excel que armazena o repositório de dados master . O único requisito estabelecido para a automatização deste processo é que os triggers (botões) necessários estejam presentes no ficheiro Excel, devidamente identificados e nomeados para garantir a execução correta de cada etapa do processo. 4.2 Hipóteses de Solução para cada oportunidade de melhoria Este subcapítulo surge com o intuito de apresentar as hipóteses de solução propostas para cada uma das oportunidades de melhoria, identificadas anteriormente. Além disso, será feita a identificação e justificação das escolhas efetuadas para cada alternativa, detalhando os motivos que fundamentaram essas decisões. A seleção da hipótese de solução para cada oportunidade de melhoria será realizada 51 através de uma comparação cuidadosa entre vantagens e desvantagens de cada alternativa, assegurando a escolha mais adequada às necessidades específicas do contexto em análise. 4.2.1 Centralização da informação de crise num repositório de dados OM 1 - Informação redundante entre repositórios de dados Como já foi anunciado previamente, o facto de existirem três ficheiros com informação redundante entre eles, é visto como um ponto negativo, uma vez que, proporciona uma ineficiência de grau elevado no que toca à atualização da informação presente em cada um deles. O facto de ser necessário atualizar, manualmente, mais do que uma vez a mesma informação, acaba por tornar esta operação passível a incongruências de conteúdo. A solução passa por criar um sistema que contenha informação base de cada tema como referenciação de dados, estando estes disponíveis para visualização na Tabela 8. Tabela 8 - Temas trabalhados nos ficheiros de RefData Fonte: Elaboração Própria Temas abordados nas RefDatas Informação pessoal relativamente aos colaboradores da NOS Informação sobre os cartões BCM, atribuídos a alguns colaboradores da NOS Informação sobre as direções que constituem a NOS Informação sobre os organigramas de crise existentes Informação em relação aos papeis que compõem o Plano de Gestão de Crise Informação relativamente às diversas Mission Critical Activities Informação relativamente às listas de crise, onde os vários colaboradores são inseridos Todos os temas referidos anteriormente, são vistos como documentos de referenciação de dados, que por sua vez, vão ser o suporte, para “alimentar” o repositório de dados master que agrupa toda esta informação num único ficheiro. Para resolver este problema, foram consideradas três hipóteses de solução: A primeira passava pela criação de um único ficheiro Excel com várias worksheets que suportassem toda a informação. Como vantagens, destaca-se a centralização total do conteúdo e o fácil acesso às informações. No entanto, o tamanho do arquivo dificultaria o processo de atualização, além de tornar a recuperação complexa em caso de corrupção do ficheiro. A segunda hipótese propunha a criação de oito ficheiros distintos: “RefPessoas”, “RefCartoes”, “RefDirecoes”, “RefOGCs”, “RefPapeis”, “RefMCAs”, “RefListas”, e um ficheiro agregador, denominado 52 “Organigramas”. Esta abordagem apresenta maior robustez organizacional e reduz os impactos da corrupção de ficheiros, mas aumenta a dificuldade de integração, dado que os ficheiros de referência sustentam o ficheiro principal (“Organigramas.xlsm”). Por fim, a terceira alternativa propunha a criação de um repositório de dados relacional em SQL, baseada no modelo de organização anteriormente referido. Esta solução oferece alta integração, maior proteção dos dados e facilidade de manipulação. No entanto, não cumpre o requisito de manter a estrutura já utilizada pela organização. A solução mais eficiente a nível de integridade e atualização dos dados seria a base de dados relacional, contudo, visto que não cumpre com um dos requisitos impostos pela organização, optou-se por excluir esta alternativa. Entre as outras duas opções, optou-se pela segunda, que divide a informação em diferentes ficheiros. Essa escolha simplifica a automatização, reduz a confusão no processo e evita riscos associados à corrupção de ficheiros, já identificados no departamento. OM 2 - Insuficiência de informação no repositório de dados master Ainda em relação ao tema – “Centralização da informação de crise num repositório de dados” – identificou-se uma segunda oportunidade de melhoria relacionada com o conteúdo do repositório de dados. Os Organigramas de crise não são retratados com exatidão, devido à insuficiência de informações no ficheiro master . Uma análise preliminar revelou a ausência de um número significativo de colaboradores, bem como informações sobre papéis de crise, listas de distribuição associadas e Mission Critical Activities (MCAs), sendo estas últimas particularmente críticas, pois não possuem qualquer registo no repositório de dados atual. Este problema impacta a organização ao tornar a pesquisa de informações de crise excessivamente manual, exigindo o uso de múltiplas plataformas para obter os dados necessários. Para abordar essa oportunidade de melhoria, foram consideradas duas hipóteses de solução: 1. Comparação entre o ficheiro master atual e o portal BCM: Essa abordagem limita-se a duas fontes de informação, simplificando a recolha de dados e aumentando a eficiência. Contudo, essa limitação reduz a abrangência, podendo deixar lacunas no repositório de dados criado. 2. Comparação entre o ficheiro master atual, o Portal BCM, o GUIA Corporativo (SAP) e BIA: Essa abordagem amplia a diversidade das fontes de informação, permitindo uma verificação cruzada mais robusta. No entanto, aumenta a complexidade do processo de automatização devido à necessidade de integração de múltiplos recursos. 53 A solução escolhida foi a segunda hipótese, dada a sua maior riqueza de dados e a possibilidade de atualização contínua com base nas ferramentas corporativas. Embora a inserção inicial das informações no ficheiro “Organigramas” seja predominantemente manual, essa abordagem permite testar exaustivamente o repositório de dados criado. Para informações dinâmicas, como o ficheiro “RefPessoas”, será possível programar o envio automático de ficheiros atualizados diariamente, enquanto temas mais estáticos, como papéis de crise e MCAs, poderão ser atualizados manualmente conforme necessário. Por fim, para facilitar a compreensão do sistema implementado, a Figura 17 apresenta um esquema representativo do sistema como um todo. Figura 17 - Esquema Representativo do Sistema Fonte: Elaboração Própria Como foi referenciado anteriormente, existem sete ficheiros distintos de referenciação de dados. Estes ficheiros servem de suporte ao ficheiro “Organigramas”, sendo utilizados para preencher informações relacionadas aos colaboradores que fazem parte dos organigramas de crise da organização. Por sua vez, estes ficheiros de referenciação de dados têm de ser suportados por outros, de forma a estarem sempre atualizados ao longo do tempo. Para tal, são utilizadas três ferramentas: GUIA Corporativo (SAP), Portal BCM e BIA. Com o intuito de proporcionar uma visão mais clara das variáveis que compõem estes ficheiros, surge então o Apêndice C – Características variáveis constituintes do novo , que faz referência aos atributos utilizados nestes 8 ficheiros. Na mesma, encontra-se disponível o nome de cada atributo, a descrição do mesmo e ainda os ficheiros a que os mesmos pertencem. 54 4.2.2 Estruturação na troca da informação de crise entre áreas Neste subcapítulo surgem as hipóteses de solução equacionadas para dar resposta às oportunidades de melhoria 3, 4 e 5. OM 3 - Falta de estruturação da informação que dá entrada na mailbox BCM Destacou-se anteriormente como uma oportunidade de melhoria a ausência de estruturação na informação que dá entrada na caixa de correio da mailbox BCM. Esta mailbox serve de apoio a alguns temas relacionados com o PGCrise, que por sua vez, é um dos inputs necessários para desencadear o processo de atualização da informação. A falta de estruturação nos emails recebidos obriga à atualização manual dos dados, resultando em ineficiências no repositório de dados e nos recursos associados. Para tornar este processo mais automatizado, identificou-se a necessidade de criar uma estrutura base para cada tema abordado através da mailbox . O objetivo é padronizar os emails, garantindo que a informação recebida possa ser integrada diretamente nos automatismos previstos. Duas hipóteses de solução foram consideradas para resolver esta questão. A primeira propôs a criação de templates de email específicos para cada tipo de mensagem, ajustados às informações necessárias para cada tema. A principal vantagem desta abordagem é a padronização, que assegura um formato consistente e facilita a identificação das informações cruciais. No entanto, apresenta desvantagens, como a rigidez na apresentação das mensagens, dificultando adaptações a situações excecionais. A segunda hipótese consistiu na utilização da aplicação Forms para criar questionários específicos para cada tema. Essa abordagem permitiria ao departamento de ARC definir exatamente as informações necessárias, garantindo um controlo maior sobre os dados enviados pelas áreas de negócio. Contudo, essa solução limita a comunicação direta, dificultando ajustes ou correções quando certos erros ocorrem na transmissão de informações. Ambas as soluções abordam os impactos negativos identificados, mas a limitação de comunicação na utilização de questionários via Forms inviabiliza esta alternativa. Por esta razão, optou-se pela implementação da primeira hipótese, com a criação de templates de email. OM 4 - Falta de informação nos emails que dão entrada na mailbox BCM Relativamente aos emails recebidos na mailbox de crise, foi identificada uma limitação no conteúdo, nomeadamente a ausência de uma chave única que identificasse cada colaborador em processo de entrada ou saída. Essa lacuna gerava a necessidade de pesquisas adicionais em diferentes ferramentas de suporte para obter as informações necessárias à atualização completa do ficheiro “Organigramas ” . 55 Para solucionar este problema, foram consideradas duas hipóteses de solução, semelhantes às apresentadas para a oportunidade de melhoria OM 3. Em alinhamento com a escolha anterior, a solução adotada foi a criação de templates de email específicos para cada input abordado, garantindo consistência no processo. OM 5 - Falta de estruturação da informação que dá saída da mailbox BCM Em relação à oportunidade de melhoria OM 5, identificou-se a falta de estruturação na informação enviada da mailbox BCM pela ARC para outras áreas da empresa. Como tal, adotou-se, mais uma vez, a solução utilizada nas oportunidades de melhoria OMs 3 e 4. Como se pode verificar, a solução encontrada para as oportunidades de melhoria associadas a este subcapítulo é a mesma, isto é, a criação de templates de email específicos, com o auxílio de um layout tabelar de forma a dar uma visão mais fácil da informação em questão. Na Figura 18 , encontra-se o template de email proposto para tratar a saída de um colaborador do Plano de Gestão de Crise. Neste exemplo, percebe-se que a tabela em questão deverá ser preenchida pelo Pivot BCM a quem é direcionado o email em questão. Figura 18 - Proposta de template de email Fonte: Elaboração Própria 4.2.3 Alteração Processual OM 6 - Incongruência de informação entre o Portal BCM e o Repositório de Dados Master O Portal BCM, que contém uma representação gráfica dos organigramas de crise da NOS, é atualizado antes do repositório de dados Organigramas. Este fluxo impossibilita a automatização do processo e pode resultar em inconsistências entre os dois recursos. A solução identificada consiste em priorizar a atualização do repositório de dados, seguida pela transição da informação para o Portal BCM. Esta abordagem garante que toda a informação se baseia numa única fonte, facilitando o rastreamento de eventuais erros e assegurando a conformidade entre ambos os 56 recursos. Além disso, a estruturação da informação ocorre apenas uma vez, quando o repositório de dados é alimentado, tornando o processo mais eficiente. Embora esta solução proporcione uma única fonte de verdade para a informação de crise, ela não elimina completamente a necessidade de verificações humanas periódicas para garantir a consistência entre os dois recursos. Adicionalmente, como o Portal BCM é amplamente utilizado pelos colaboradores para consulta dos organigramas de crise, é imperativo que este esteja sempre atualizado, o que pode levar alguns minutos devido à necessidade de transição da informação do repositório de dados para o Portal. Apesar das limitações inerentes à mesma, essa solução será implementada, visto que atualmente, é a única maneira de garantir que a informação disponível no Portal BCM seja fidedigna. OM 7 - Inexistência de uma atividade sistematizada e estruturada de identificação de substituto, aquando da saída de um colaborador da organização No capítulo 3.3.3 destacou-se a OM 7 que relata a inexistência de uma atividade sistematizada e estruturada de identificação de um substituto, aquando da saída de um colaborador da organização. Para mitigar os impactos deste problema, propôs-se notificar o Pivot BCM da área de negócio afetada pela saída de um colaborador, informando-o sobre as características de crise associadas ao colaborador em questão, incluindo papel de crise, atividade desempenhada e informações pessoais (nome, e-mail, número de telefone profissional e número de telefone de crise, se aplicável). A mensagem deve ainda conter um espaço destinado à resposta do Pivot BCM, onde será inserida a informação sobre o colaborador que assumirá o papel em falta. Surgiram então duas hipóteses de solução. A primeira propunha a criação de um template de mensagem a ser enviado via Teams ao Pivot BCM sempre que ocorresse a saída de um colaborador do PGCrise. A segunda alternativa consistia na criação de um template de email, a ser enviado via Outlook . Ambas as opções permitem obter as informações necessárias sobre o colaborador substituto para atualizar o repositório de dados e os restantes recursos de forma eficiente. No entanto, a segunda hipótese foi considerada mais adequada, pois o registo histórico das trocas de emails é mais facilmente acedido via Outlook , do que por mensagens enviadas via Teams , dado o elevado volume de utilização da aplicação na empresa. OM 8 - Baixa integração da aplicação Google Contacts com o ambiente computacional da empresa, dadas as diferenças entre Google e Microsoft 57 Todo o sistema tecnológico da NOS assenta na utilização de aplicações Microsoft ou criadas pela própria organização. Por essa razão, existem dúvidas acerca da fiabilidade de utilização dos Google Contacts para armazenar todos os contactos de crise. Além disso, o facto de todos os colaboradores inseridos no PGCrise terem acesso às credenciais desta conta, gera transtornos relacionados ao login , devido a questões de segurança levantadas pela própria Google. Para resolver este problema, foram consideradas duas alternativas. A primeira consiste na utilização dos Microsoft Contacts vinculados a uma conta de email específica a ser criada, configurada como uma mailbox partilhada. Essa configuração permitiria controlar quais os colaboradores que têm acesso à conta. A segunda alternativa propõe o uso da aplicação “Contacts PEA”, desenvolvida exclusivamente para armazenar listas de contactos. Ambas as opções apresentam a vantagem de eliminar a dependência dos Google Contacts , oferecendo soluções mais fiáveis. No entanto, dado que o objetivo é permitir que os colaboradores do PGCrise acedam a estas listas diretamente nos seus dispositivos móveis, com sincronização automática para os contactos, apenas a primeira alternativa satisfaz plenamente este requisito. Assim, concluiu-se que a utilização dos Microsoft Contacts , através de uma conta de email partilhada, é a solução mais adequada para garantir a eficiência na gestão dos contactos de crise. 4.2.4 Automatização das tarefas de gestão da informação de suporte ao PGCrise OM 9 - Grau de manualidade associado ao processo de atualização da informação de Crise O processo de atualização da informação de crise exige, além da atualização do repositório de dados, a integração com diferentes recursos e ferramentas, atualmente realizado com um elevado grau de manualidade. O principal objetivo deste projeto é automatizar este processo. Assim, a proposta baseia-se em tornar o repositório de dados a fonte central de todas as informações, com atualizações iniciadas a partir de inputs dados pelo repositório de dados master “Organigramas.xlsm ” , através de macros em ambiente Excel. Atualmente, o processo engloba a atualização de oito recursos distintos: BD master , GUIA Corporativo (SAP), SMSPro, Activity Director , lista de contactos de crise, grupos de WhatsApp , Crisis Pocket Guide e Portal BCM ( Confluence ). Dada a necessidade de integração desses recursos, foram analisadas as seguintes ferramentas de automatização: • Microsoft Power Automate - Integra-se totalmente com produtos Microsoft , tornando-o ideal para o ambiente computacional da NOS. É uma ferramenta low-code e acessível para novos 58 utilizadores. No entanto, pode ser dispendiosa em cenários complexos que exijam conectores premium e apresenta limitações na integração com aplicações não Microsoft . • UiPath - Oferece uma ampla compatibilidade com diversas aplicações e recursos avançados de AI. Contudo, apresenta uma curva de aprendizagem elevada e custos significativos, especialmente para projetos de curta duração. • Node-Red - Plataforma open-source com elevado grau de personalização. Apesar disso, exige conhecimento de JavaScript e possui limitações em suporte técnico. • Automation Sucess - Destaca-se pela segurança no tratamento de dados sensíveis e recursos avançados. Porém, os custos associados e a complexidade do setup tornam a sua implementação menos viável. • Zapier - Ferramenta user-friendly com ampla integração entre aplicações. Contudo, depende de APIs de terceiros e apresenta custos elevados à medida que a complexidade dos fluxos aumenta. • Python - Linguagem extremamente versátil, que conta com um suporte robusto da comunidade e inúmeras bibliotecas. No entanto, exige conhecimentos técnicos avançados e apresenta uma curva de aprendizagem difícil. Embora cada ferramenta tenha pontos positivos e limitações, nenhuma se destacou como a melhor opção para a automatização do processo. Para tomar uma decisão mais fundamentada, optou-se por aplicar o método AHP ( Analytic Hierarchy Process ), permitindo avaliar as alternativas com base em critérios definidos. Método de Decisão AHP Conforme já referido anteriormente, o método de decisão AHP baseia-se numa metodologia estruturada para suportar a tomada de decisão com múltiplos critérios. O AHP organiza o processo de decisão ao avaliar as alternativas disponíveis, que, neste caso, são as seis ferramentas de automatização mencionadas no capítulo anterior e disponíveis para consulta através da Tabela 10Tabela 9. Para fundamentar a escolha dos critérios de comparação, foi realizado um estudo detalhado das características consideradas mais relevantes pelo departamento de Auditoria, Risco e Compliance , resultando na definição dos critérios apresentados na Tabela 10. Esta definição de critérios teve por base os elementos mais prioritários segundo do estudo anteriormente referido. 65 execução da script , foi implementada uma ação que notifica a equipa BCM via email. A Figura 21 ilustra a estrutura gráfica deste automatismo. Figura 21 - Automatismo 4 (Update RefDirecoes) Fonte: Elaboração Própria Com a implementação dos quatro automatismos mencionados, foi possível garantir a atualização diária e precisa da informação presente no repositório de dados. Este avanço permitiu ter os dados necessários atualizados diariamente, prosseguindo então para a etapa seguinte desta hipótese de solução, que consiste na execução do processo de eliminação e inserção de colaboradores no ficheiro “Organigramas.xlsm”, elemento central de suporte ao PGCrise. Só faz sentido analisar o processo de eliminação e inserção de colaboradores no ficheiro master , considerando três cenários chave: Saída do colaborador do PGCrise, devido a saída da empresa, saída de colaborador do PGCrise por troca com outro colaborador e por último, entrada do colaborador no PGCrise por troca com outro colaborador. Neste sentido, dá-se o primeiro cenário. Cenário I – Saídas de colaborador do PGCrise (saída da empresa) Quando um colaborador da NOS deixa a organização, o departamento de Recursos Humanos envia uma notificação por email informando sobre a saída. O início do automatismo 5 “Envio de email ao Pivot BCM (Saída DP&O)” depende da receção de um email na mailbox BCM, enviado pelo departamento de Pessoas e Organização, com o assunto “Saída Colaborador NOS ” . Este flow inicia-se com a ação “ When a new email arrives in a shared mailbox ”. 66 Em seguida, um conjunto de conectores é utilizado para manipular o texto contido no email, extraindo o endereço eletrónico do colaborador em questão. Este endereço serve como input para a Office Script utilizada , que realiza as seguintes ações caso encontre o mesmo no repositório de dados: • Atualiza o estado do colaborador para “Inativo” no ficheiro “Organigramas”; • Recolhe as informações necessárias sobre o colaborador; • Organiza esses dados em formato JSON para posterior utilização no Power Automate . Após esta etapa, a ação “ Parse JSON ” processa as informações resultantes da script . Por fim, é utilizado o conector “ Send an email from a shared mailbox ” para enviar um email ao Pivot BCM responsável pela área do colaborador em processo de saída, solicitando a indicação de um substituto. Esse email é também enviado para a mailbox BCM ( [email protected] ), garantindo o registo da solicitação. Ao longo do flow , as ações de notificação são configuradas com o conector “ Send an email from a shared mailbox ” , ativadas apenas em caso de falha em etapas específicas. Esses emails são enviados para a equipa BCM, informando o ponto exato onde se deu o erro. A Figura 22 e Figura 23 ilustram a representação gráfica do automatismo 5. Figura 22 - Automatismo 5 - Envio de email ao Pivot BCM (SaídaDPO) I 67 Fonte: Elaboração Própria Figura 23 - Automatismo 5 - Envio de email ao Pivot BCM (SaídaDPO) II Fonte: Elaboração Própria Existe ainda um automatismo configurado para ser executado diariamente às 10h, com o objetivo de validar o trabalho realizado no processo de eliminação de colaboradores que deixaram a empresa, abordado no automatismo 5. Este mecanismo visa mitigar potenciais falhas, sejam estas relacionadas ao departamento de Recursos Humanos (não informando a saída de determinado colaborador) ou à ARC (não atualizando a informação de forma atempada). Este flow inicia-se com a ação “Run Script from SharePoint library” que executa uma Office Script no ficheiro “Organigramas.xlsm”. A script utiliza três worksheets distintas: “Sheet1”, “Identidades Inativas Ontem” e “RefOGC’s”. O objetivo principal desta script é comparar os usernames presentes na worksheet “Identidades Inativas Ontem” com os da “Sheet1”. Caso encontre usernames coincidentes cujo estado esteja ativo, são recolhidas automaticamente as informações associadas ao colaborador, como o nome, username , OGC, MCA, email do Pivot BCM responsável e o link do OGC no Portal BCM. Todas essas informações são convertidas em formato JSON, facilitando o processamento subsequente no Power Automate . Além disso, os colaboradores identificados terão automaticamente o seu estado de papel alterado para “Inativo”. Na sequência, a ação “Parse JSON” processa os dados provenientes da script , preparando-os para utilização nas ações seguintes. A informação trabalhada é então usada na ação “Send an email from a shared mailbox” que envia um email da mailbox BCM para a própria e para o Pivot BCM da área à qual o colaborador pertence. O email contém os dados relevantes apresentados em formato tabelar, 68 solicitando a indicação de um substituto e fornecendo o link do OGC correspondente, permitindo uma rápida visualização do problema em questão. A Figura 24 apresenta uma ilustração gráfica do automatismo desenvolvido. Figura 24 - Automatismo 6 - Envio de email ao Pivot BCM (Saída RefPessoas) Fonte: Elaboração Própria Cenário II – Saídas de colaborador do PGCrise (troca entre colaboradores) Além do cenário anteriormente mencionado, a saída de colaboradores do PGCrise pode ocorrer também devido a trocas entre colaboradores, e não apenas por saídas da empresa. Esses casos geralmente surgem de trocas informais de informação entre áreas, como conversas diretas entre o Gestor de Crise e o Pivot BCM da área envolvida. Por consequência, a automatização completa desse processo no ficheiro master não é viável. No entanto, para simplificar e automatizar parcialmente o processo de saída do PGCrise, foi desenvolvida uma script em VBA, cuja visualização está disponível na Figura 25. O principal objetivo dessa script é garantir que, ao alterar o campo “Estado Papel” para “Inativo”, o campo “Data fim (papel)” seja preenchido automaticamente, no ficheiro “Organigramas.xlsm”. 69 Figura 25 - Atualização Data Fim de Papel Fonte: Elaboração Própria É importante realçar que esta script foi criada no objeto “Sheet1”. Esta decisão foi tomada como parte de uma estratégia para organizar as macros em VBA de forma estruturada. Assim, macros que utilizam a rotina “Worksheet_Change”, ou seja, aquelas que são ativadas por alterações específicas na folha de Excel, estão armazenadas no objeto “Sheet1”. Por outro lado, macros acionadas pela seleção de um botão estão organizadas nos diversos módulos correspondentes. Vale ressaltar que a saída de um colaborador do PGCrise envolve um conjunto mais amplo de ações, além da mencionada. No entanto, este subcapítulo limita-se a abordar a atualização direta do ficheiro master “Organigramas.xlsm”, não entrando em detalhes sobre as restantes ações associadas. Cenário III – Entrada de colaborador do PGCrise (troca entre colaboradores) No cenário de entradas no PGCrise, o processo ocorre exclusivamente por via de trocas informais de informação entre áreas, sem mensagens ou emails padronizados. Essa ausência de formalização inviabiliza a automatização completa da inserção de novos colaboradores no ficheiro master . O objetivo principal é simplificar ao máximo o processo de inserção, permitindo que o preenchimento de algumas variáveis chave resulte no preenchimento automático de todas as variáveis de crise associadas ao colaborador em questão. A atualização do repositório de dados segue uma sequência específica, começando pela inserção do email do colaborador, que serve como identificador único. A partir desse dado, toda a informação pessoal (Nome, Username , Contacto Profissional, Tipo de Identidade, Local de Trabalho e Direção) é extraída do ficheiro “RefPessoas” e inserida automaticamente nas colunas correspondentes do ficheiro master, utilizando a script “AtualizarInfoPessoal” detalhada no Apêndice E – Automatismos desenvolvidos. Na etapa seguinte, é selecionado o OGC no qual o colaborador será alocado. Essa seleção preenche automaticamente a coluna “Tipo Área”, que define as listas de crise associadas ao colaborador. Para facilitar esse processo, foi implementada uma validação de dados na coluna de OGC, permitindo que o utilizador escolha o organigrama a partir de uma lista suspensa. 70 Após essas etapas, o papel de crise do colaborador é definido. Essa definição preenche automaticamente as variáveis restantes, como o direito a Cartão BCM, eSIM, e inclusão nas listas de crise. Contudo, existe um ponto crítico a considerar: caso o colaborador seja designado como Gestor de Continuidade de Negócio (GCN), é necessário alocar previamente uma MCA ( Mission Critical Activity ). Essa etapa é indispensável porque o direito ao Cartão BCM depende do papel de crise e da MCA associada. O código foi estruturado de forma que a variável “Direito a Cartão BCM” seja preenchida automaticamente ao definir o papel de crise. Assim, se a MCA for atribuída após a definição do papel de crise, a variável “Direito a Cartão BCM” poderá ser preenchida incorretamente. Para colaboradores que não sejam GCN, o preenchimento do papel de crise conclui o processo de entrada no ficheiro master. No Apêndice F – Checklist Execução , encontra-se uma checklist detalhada das etapas de execução do ficheiro excel em questão. OM 9.2 - Subprocesso de atualização da informação da BD para o Activity Director Após a atualização no ficheiro master , é necessário proceder à atualização de diversos recursos da empresa. Entre eles está o Activity Director (AD), uma plataforma que regista os colaboradores de crise e os seus respetivos números telefónicos de contingência. Embora a atualização desta plataforma seja essencial, a responsabilidade pela sua gestão recai sobre a equipa de Informação e Sistemas, e não sobre a ARC. Por isso, o objetivo dos automatismos criados é notificar o responsável dessas atualizações sempre que houver entradas ou saídas de colaboradores do PGCrise. Foram desenvolvidos dois automatismos no Power Automate : o automatismo 7 (Entrada no AD) e o automatismo 8 (Saída do AD). Ambos se iniciam com o conector “When a HTTP request is received” acionado por um botão no ficheiro “Organigramas”. A interação com o botão foi implementada através de uma macro VBA, que permite ao utilizador selecionar as linhas correspondentes aos colaboradores a serem atualizados no AD. Essas linhas são convertidas num objeto HTTP, enviado ao Power Automate . No automatismo de entradas, uma Office Script chamada “InfoEntradaAD” é executada no ficheiro “Organigramas”. Essa script recolhe informações essenciais sobre os colaboradores selecionados, formatando-as em JSON para integração com o Power Automate . A partir daí, o conector “Parse JSON” processa os dados e, com a ação “Apply to each” é enviado um email para o responsável pelo AD com os detalhes necessários para a atualização. O automatismo de saídas segue a mesma lógica, mas utiliza uma macro e uma Office Script específicas, adaptadas às diferenças de estado ("Associar Contacto" para entradas e "Desassociar Contacto" para saídas). Ambos os fluxos incluem ações de notificação por email para a equipa BCM, que são ativadas em caso de falha em qualquer etapa. De forma a 71 proporcionar uma visão detalhada dos dois automatismos, encontram-se no Apêndice E – Automatismos desenvolvidos, os diagramas ilustrativos de ambos os automatismos mencionados. OM 9.3 - Subprocesso de atualização da informação da BD para a lista de contactos de crise Na operação anterior da empresa, era utilizada a aplicação Google Contacts para o armazenamento dos contactos de crise. Esta abordagem foi alterada devido a limitações de integração com o Power Automate e questões de segurança, transferindo a gestão para o Outlook Contacts associado à mailbox ([email protected]). O processo de entrada de contactos foi tratado através do desenvolvimento do automatismo 9. Este flow no Power Automate é acionado por um botão no ficheiro “Organigramas”, que permite ao utilizador selecionar as linhas correspondentes aos colaboradores a serem adicionados à lista de contactos. Uma Office Script é responsável por recolher os dados selecionados no Excel, transformá-los em JSON e integrá-los no Power Automate . Este, por sua vez, utiliza a ação “Create Contact” para adicionar os contactos ao Outlook Contacts , considerando variáveis como o eSIM e o Número BCM. Em caso de falha em qualquer etapa do processo, são enviados emails automáticos à equipa BCM, notificando o problema. De forma semelhante, o processo de saída de contactos foi automatizado pelo automatismo 10, que permite remover colaboradores da lista de contactos do Outlook . Este processo segue a mesma lógica de seleção no Excel e integração via Power Automate . A ação “Get Contacts” identifica os contactos correspondentes no Outlook , utilizando o email como critério de filtragem, e a ação “Delete Contact” remove os contactos identificados. Assim como no automatismo anterior, falhas no processo geram notificações automáticas à equipa BCM. Contudo, verificou-se que a mailbox ([email protected]) não deveria ser acessível a todos os colaboradores devido ao caráter restrito de algumas informações. Por essa razão, foi criada uma mailbox de contactos partilhada para o PGCrise. Como o Power Automate não permite criar ou remover contactos diretamente em mailboxes partilhadas, desenvolveu-se o automatismo 11, que envia mensalmente um lembrete ao gestor da informação de crise para realizar manualmente a transferência de contactos entre as mailboxes , garantindo que a lista esteja sempre atualizada. Os três automatismos criados permitiram abordar as necessidades de atualização da lista de contactos de crise, minimizando a intervenção manual e assegurando maior precisão e fiabilidade nos processos, estando disponíveis para consulta no Apêndice E – Automatismos desenvolvidos. 72 OM 9.4 – Subprocesso de atualização da informação da BD para o documento Crisis Pocket Guide Foram criados dois automatismos baseados em VBA para tratar a comunicação entre o ficheiro “Organigramas” e o CPG Excel, e um terceiro automatismo para atualizar a capa do CPG Publisher. Estes casos têm a particularidade de que a troca de informação acontece do ficheiro master para um outro documento Excel. Assim, visto que a comunicação é feita entre dois ficheiros Excel, não é necessário utilizar nenhum flow em Power Automate . O automatismo 12 – UpdateDateCPGPublisher foi desenvolvido para atualizar a data na capa do CPG Publisher. Utilizando o Power Automate Desktop com a funcionalidade de gravação de ecrã, o automatismo edita automaticamente a data no formato "mês, ano". Este flow é acionado por um botão no ficheiro Excel, que ativa o desktop flow para realizar a tarefa. Para o automatismo 13 – EntradasCPGExcel foi desenvolvida uma macro em excel para inserir novos colaboradores no CPG. Esta é acionada por um botão no ficheiro “Organigramas ” , que solicita ao utilizador a seleção das linhas correspondentes aos colaboradores a serem adicionados. Após a seleção, as informações necessárias, como Nome, Telemóvel Profissional, OGC, Papel de Crise, ID de MCA, Estado do Papel e Número BCM, são recolhidas e ajustadas para coincidir com a estrutura de dados do CPG. O automatismo 14 – SaídasCPGExcel tem como objetivo remover colaboradores do CPG. De forma similar ao processo de entradas, o utilizador seleciona as linhas correspondentes aos colaboradores a serem excluídos, e as informações relevantes são ajustadas e eliminadas do ficheiro do CPG. Este automatismo assegura uma comunicação bidirecional eficiente entre os ficheiros envolvidos. Os três automatismos encontram-se disponíveis para visualização no Apêndice E – Automatismos desenvolvidos. OM 9.5 - Subprocesso de atualização da informação da BD para o Portal BCM (Organigramas e CPG) Devido às limitações da API do Confluence , que impede a edição direta de nomes em posições específicas das tabelas, foi necessário desenvolver uma solução alternativa para automatizar a atualização dos organigramas de crise. Essa solução baseia-se na criação de um ficheiro Excel estruturado, que reflete os organigramas de crise da NOS, e na implementação de três automatismos que garantem a gestão das entradas, saídas e sincronização com o Portal BCM. 73 Foram criados dois automatismos, 15 e 16, denominados “EntradaExcelConfluence” e “SaidasExcelConfluence”, respetivamente. Estes automatismos utilizam macros em VBA para adicionar ou remover colaboradores no ficheiro Excel “OGC", com base nos inputs do gestor de crise. A estrutura dessas macros foi adaptada para alinhar os dados do ficheiro Excel com o formato do conteúdo do Crisis Pocket Guide . Seguiu-se o automatismo 17 – Upload OGC no Confluence que realiza a sincronização do ficheiro Excel atualizado com o Portal BCM no Confluence . Este processo começa com um conector "When a HTTP is requested" ativado por um botão no ficheiro master após a seleção das linhas relevantes. Uma Office Script é executada para recolher os dados dos OGCs dos colaboradores selecionados, formatados como JSON , e processados por um ciclo "for each”. Este ciclo avalia as condições relacionadas a cada OGC, ativando, quando necessário, um conector "Run a desktop flow" que utiliza o Power Automate Desktop para atualizar diretamente a página do Confluence . De forma a efetivar as entradas e saídas nos organigramas de crise que estão expostos para toda a organização numa página da aplicação confluence , pensou-se em proceder à atualização da informação, integrando o Power Automate com a API da aplicação. O único entrave neste trajeto, foi o facto de a API não permitir adicionar e apagar nomes de posições específicas de uma tabela. A implementação desses três automatismos permite superar as limitações da API do Confluence , garantindo uma gestão sincronizada dos organigramas de crise da NOS, com um fluxo contínuo de atualizações entre o ficheiro Excel e o Portal BCM. 9.6 - Subprocesso de atualização da informação da BD para a aplicação web SMSPro No ficheiro master “Organigramas” existem três colunas que definem se o colaborador deve ser inserido ou removido das listas de crise do SMSPro. Para automatizar esse processo, foram desenvolvidos dois automatismos: automatismo 18 – Entrada SMSPro via API e Automatismo 19 – Saída SMSPro via API. O automatismo 18, inicia-se com um conector “When a HTTP request is received” acionado por um botão no Excel. A macro criada em VBA permite ao utilizador selecionar as linhas correspondentes aos colaboradores a serem inseridos nas listas. Essas linhas são transformadas num objeto HTTP, que é processado no Power Automate . Uma Office Script é executada para estruturar os dados dos colaboradores em formato JSON , e um conector " Parse JSON " que organiza essas informações. O ciclo “for each” assegura que todos os colaboradores são adicionados às listas corretas. Caso o colaborador possua um cartão BCM, são criados dois contactos: um para o número profissional e outro para o número BCM. Se o colaborador não possuir cartão BCM, apenas o número profissional é considerado. 74 Adicionalmente, existe uma condição que verifica se o colaborador deve ser incluído na lista de contactos dos SIC, inserindo-o, se necessário, através da ação “HTTP”. O automatismo 19 segue a mesma lógica do anterior, mas lida com a remoção de colaboradores das listas de contactos. Antes de retirar um colaborador, verifica-se se este possui outro papel de crise que justifique a sua permanência nas listas. Essa etapa é crucial, pois evita remoções indevidas. Por outro lado, ao adicionar colaboradores, essa verificação não é necessária, visto que o SMSPro impede a duplicação de identidades numa mesma lista. Ambos os automatismos descritos estão disponíveis para consulta no Apêndice E – Automatismos desenvolvidos. OM 9.7 - Subprocesso de atualização da informação da BD para a aplicação web GUIA corporativo (SAP) Além das listas de SMSPro, referidas na oportunidade de melhoria anterior, existem também as listas de distribuição da aplicação GUIA Corporativo (SAP). No ficheiro “Organigramas” existem diversas colunas que indicam se cada colaborador deve ou não estar presente nessas listas. Numa fase inicial, considerouse utilizar a API da aplicação para criar dois automatismos que inserissem e removessem colaboradores, semelhante ao processo desenvolvido para o SMSPro. Contudo, a ausência de uma API para o GUIA inviabilizou essa abordagem. Neste sentido, explorou-se o uso da funcionalidade recorder do Power Automate Desktop . No entanto, o processo de inserção de colaboradores no GUIA envolve a abertura de pop-ups que não são reconhecidos pela ferramenta, descartando também essa opção. Diante dessas limitações, foram desenvolvidos dois automatismos utilizando a linguagem VBA: automatismo 20 – VBAScript (EntradaGUIA) e automatismo 21 – VBAScript (SaídaGUIA). O primeiro automatismo permite ao utilizador selecionar um botão no ficheiro “Organigramas” e escolher as linhas correspondentes aos colaboradores a serem adicionados às listas do GUIA. Após a seleção, uma Message Box informa as listas nas quais o colaborador deve ser incluído (GUIA X e Y). Caso o colaborador não precise de ser inserido em nenhuma lista, é exibida a mensagem “Nenhuma alteração necessária”. Semelhante ao automatismo anterior, o automatismo 21 trata das remoções. Após a seleção das linhas no ficheiro “Organigramas”, uma Message Box informa as listas do GUIA das quais o colaborador deve ser excluído. Se o colaborador não estiver associado a nenhuma lista, a mensagem “Nenhuma alteração necessária” é exibida. Embora estes automatismos não atualizem as listas diretamente no GUIA, eles garantem que o utilizador seja notificado sobre as alterações necessárias, facilitando o processo de gestão manual e minimizando 81 forma a concretizar a execução deste automatismo, recorreu-se então à aplicação “Task Scheduler” sendo criadas duas tasks diárias que levam à abertura dos ficheiros de “RefDireçoes.xlsm” e “Organigramas.xlsm” de forma automática, pelas 9:15 e 9:30 da manhã, respetivamente. A abertura dos ficheiros é o trigger para que o refresh all seja despoletado. Assim, o automatismo 4 fica passível de ser acionado. Este automatismo além de manter atualizado o ficheiro “RefDirecoes.xlsm”, envia um email à equipa BCM a informar da existência de uma nova direção. O mesmo acontece para o automatismo 6 que funciona como uma espécie de confirmação ao trabalho desenvolvido na eliminação de colaboradores (em processo de saída da empresa) do PGCrise. Eventualmente, poderão acontecer falhas, seja da parte dos Recursos Humanos (não indicando à ARC que determinado colaborador saiu da empresa) seja da parte da ARC (não atualizando a informação no tempo devido). Os colaboradores identificados vão então passar a estar como inativos no ficheiro master. No que toca aos e-mails provenientes do departamento de Pessoas e Organização, os mesmos indicam sempre a saída de um determinado colaborador da empresa. De forma a identificar o colaborador em processo de saída, é dado o endereço de e-mail do mesmo. Aqui entra automatismo 5, que basicamente pega nesse endereço de e-mail , e procura-o no ficheiro master “Organigramas.xlsm”, passando o estado do colaborador em questão para inativo. Por último, em relação aos e-mails que tratam alterações nos papeis de crise, de qualquer tipo, os mesmos são tratados manualmente de forma propositada, inserindo e eliminado os colaboradores, consoante a necessidade denotada. 5.2.3 Divulgação da Informação de Crise Surge então a última fase do projeto, e provavelmente a mais importante, que se caracteriza por ser a fase de divulgação da informação. A divulgação da informação de crise ocorre em 6 recursos diferentes e ainda para o Pivot BCM de cada direção, quando assim for necessário. Como já foi referido, este projeto tinha por objetivo que o repositório de dados fosse a base de informação para todos os recursos existentes, isto é, que o repositório de dados fosse a única fonte de alimentação para os vários recursos utilizados pela empresa. Antes de passar para os automatismos que são disparados através do clique em botões específicos no ficheiro Excel “Organigramas.xlsm”, é importante destacar 3 automatismos que já foram citados na fase anterior. Estes são os automatismos 4, 5 e 6, que apesar de serem automatismos que ajudam no tratamento de informação, os mesmos acabam por ser bastante úteis para as trocas de informação necessárias. O automatismo 4, além de adicionar uma nova direção ao ficheiro “RefDirecoes.xlsm”, 82 quando necessário, envia também um e-mail para a Mailbox BCM, de forma a notificar a equipa BCM que existe uma nova direção na empresa para que a equipa possa preencher a informação relativamente à nova direção em causa. No que toca aos automatismos 5 e 6, ambos levam à alteração do repositório de dados quando se dá conta que um colaborador saiu da organização, sendo que, quando assim é, enviam também um e-mail para o Pivot BCM da área afetada pela saída do colaborador e para a Mailbox BCM, contendo nele uma tabela com as características de crise do colaborador em processo de saída da organização, pedindo também um substituto para o mesmo, garantindo assim, que sempre que houver uma saída do PGCrise, há também uma entrada para a substituir. Os restantes automatismos do 7 ao 21, funcionam sempre da mesma maneira, através do clique de um botão em específico no repositório de dados, sendo que há 3 tipos de automatismos para estes casos. Tem-se os automatismos desenvolvidos pelo Power Automate Web , sendo estes os responsáveis pela atualização do departamento do IT , da lista de contactos de crise e das listas de distribuição de SMSPro (automatismos 7, 8, 9, 10, 11, 18, 19). Além disso, tem-se os automatismos que foram desenhados somente a partir da utilização de código VBA, neste caso os mesmos são responsáveis pela atualização dos ficheiros Excel Crisis Pocket Guide, OGC e pelas listas de distribuição de GUIA Corporativo (automatismos 13, 14, 15, 16, 20 e 21). De forma a manter o documento Publisher atualizado, e os OGC’s no Portal BCM em concordância com o ficheiro Excel, criaram-se os automatismos 12 e 17, que utilizam a ferramenta recorder do Power Automate Desktop em conjunto com a aplicação web do Power Automate . 5.3 Síntese e Avaliação da eficácia da ferramenta Este subcapítulo surge com o intuito de fazer um apanhado geral sobre o benefício obtido, para cada uma das oportunidades de melhoria destacadas no capítulo 4.2.4, através do conjunto de automatismos criados para dar resposta às mesmas. Neste sentido, e de forma a avaliar cada um dos automatismos, recorreu-se ao cálculo de um índice de satisfação, com base em três fatores, calculado da seguinte forma (Equação 1): Í𝑛𝑑𝑖𝑐𝑒 𝑆𝑎𝑡𝑖𝑠𝑓𝑎çã𝑜= 0,5× 𝐺𝑎𝑛ℎ𝑜 𝐸𝑓𝑖𝑐𝑖ê𝑛𝑐𝑖𝑎+0,3× 𝑅𝑒𝑑𝑢çã𝑜 𝑑𝑒 𝐸𝑟𝑟𝑜𝑠+ 0,2× 𝐹𝑒𝑒𝑑𝑏𝑎𝑐𝑘 𝑈𝑡𝑖𝑙𝑖𝑧𝑎𝑑𝑜𝑟𝑒𝑠 (1) Os pesos atribuídos a cada fator refletem a sua importância relativa no cálculo do índice, sendo estes definidos, de acordo com a importância dada pela organização a cada um dos fatores em questão. O fator – Ganho Eficiência – mede a redução percentual no tempo necessário para a realização da tarefa 83 após a automação, sendo calculado pela Equação 2. Neste caso foram realizadas 20 medições para cada tarefa pré e pós automatismo, sendo que o valor final resulta da média destas 20 medições. 𝐺𝑎𝑛ℎ𝑜 𝐸𝑓𝑖𝑐𝑖ê𝑛𝑐𝑖𝑎= 𝑇𝑒𝑚𝑝𝑜 𝑃𝑟é 𝐴𝑢𝑡𝑜𝑚𝑎𝑡𝑖𝑠𝑚𝑜 −𝑇𝑒𝑚𝑝𝑜 𝑃ó𝑠 𝐴𝑢𝑡𝑜𝑚𝑎𝑡𝑖𝑠𝑚𝑜 𝑇𝑒𝑚𝑝𝑜 𝑃𝑟é 𝐴𝑢𝑡𝑜𝑚𝑎𝑡𝑖𝑠𝑚𝑜 × 100 (2) O fator – Redução de Erros – avalia a diminuição de falhas ou inconsistências nos processos automatizados. É representado como a diferença percentual entre a taxa de erros antes e após a automação (Equação 3). Para o cálculo deste valor, foram utilizadas as mesmas 20 medições do fator “Ganho Eficiência”, sendo que neste caso, o objetivo passava por perceber a quantidade de vezes que se deram erros no processo de atualização de informação, pré e pós automatismo. Também neste caso, o valor final resulta da média das 20 medições. 𝑅𝑒𝑑𝑢çã𝑜 𝑑𝑒 𝐸𝑟𝑟𝑜𝑠= 𝑇𝑋 erro 𝑃𝑟é 𝐴𝑢𝑡𝑜𝑚𝑎𝑡𝑖𝑠𝑚𝑜 −𝑇𝑋 erro 𝑃ó𝑠 𝐴𝑢𝑡𝑜𝑚𝑎𝑡𝑖𝑠𝑚𝑜 𝑇𝑋 erro 𝑃𝑟é 𝐴𝑢𝑡𝑜𝑚𝑎𝑡𝑖𝑠𝑚𝑜 × 100 (3) O último fator – Feedback Utilizadores – corresponde à opinião dos utilizadores sobre as soluções implementadas, através de uma escala de 1 a 5, em que 1 corresponde a muito mau e 5 a muito bom. O formulário utilizado para a recolha dessas opiniões encontra-se disponível no Apêndice G – Questionário de feedback de utilizadores. Este questionário foi elaborado em conjunto com o restante departamento da ARC, de forma que as questões utilizadas fossem de encontro aos objetivos do departamento com a criação desta ferramenta de automatização. Assim, surge então a Tabela 16, que indica, para cada oportunidade de melhoria, os valores atribuídos a cada uma das variáveis anteriormente descritas, permitindo perceber o valor global do índice de satisfação para cada oportunidade de melhoria. É importante referir que para calcular o índice de satisfação foi necessário passar o feedback de cada um dos três utilizadores, em cada automatismo, para a mesma escala que os outros dois indicadores. Tabela 16 – Avaliação Ferramenta Fonte: Adaptado de (NOS, 2024) Oportunidade de Melhoria Tempo PréAutomatismo (min) Tempo PósAutomatismo (min) Ganho Eficiência Tx. Erros Pré Automatismo Tx. Erros Pós Automatismo Redução de Erros Feedback Utilizadores Índice Satisfação 9.1 8 1,5 81,25% 20% 3% 85% 96% 85% 9.2 5 0,5 90% 23% 2% 91% 96% 92% 9.3 5 0,5 90% 30% 1% 97% 94% 93% 9.4 3 0,5 83% 25% 4% 84% 96% 86% 9.5 4 2 50% 23% 5% 78% 88% 66% 9.6 5 0,5 90% 10% 4% 60% 98% 83% 9.7 5 4 20% 18% 10% 44% 86% 41% 84 9.8 5 5 0% 20% 20% 0% 0% 0% Média 5,00 1,36 72% 21% 4% 77% 93% 78% Depois de calculado o valor do índice de satisfação para um dos automatismos, fez-se uma média dos 7 valores atribuídos a cada automatismo, excluindo a oportunidade de melhoria 9.8 uma vez que não foi alvo de implementação, de forma a encontrar o valor de satisfação para a ferramenta como um todo, chegando-se à conclusão de que o mesmo chega perto dos 80%. Este valor acaba por ser bastante positivo, tendo em consideração que últimas duas oportunidades de melhoria não foram resolvidas na integra, devido a limitações do Power Automate e das próprias aplicações envolvidas em ambos os casos, mas apresentaram melhorias significativas. 85 6. CONCLUSÃO A presente dissertação teve como foco principal a melhoria das atividades de gestão da informação relacionadas com a atualização do Plano de Gestão de Crise (PGCrise) da NOS SGPS. Através de uma abordagem metodológica robusta, baseada no ciclo PDCA, foram identificadas oportunidades de melhoria, propostas soluções práticas e implementadas ferramentas que contribuíram significativamente para a eficiência e eficácia dos processos de gestão de crise. Este capítulo final apresenta uma síntese dos resultados alcançados, das limitações encontradas e das perspetivas para futuras investigações, organizados em três subcapítulos: Resultados do Projeto, Limitações do Projeto e Trabalhos Futuros. 6.1 Resultados do Projeto O principal objetivo desta dissertação era otimizar as atividades de gestão da informação no âmbito da preparação de um Plano de Gestão de Crise (PGCrise) na NOS SGPS, com ênfase na centralização, automatização e estruturação de informações cruciais. Para tal, foram seguidos vetores metodológicos robustos, enraizados no ciclo PDCA, que permitiram identificar oportunidades de melhoria, sugerir soluções práticas e implementar ferramentas que trouxeram impactos positivos na atualização e disponibilização de informações de crise nas diversas ferramentas utilizadas pela organização. O estudo focou-se em resolver os principais problemas enfrentados pelo Departamento de Auditoria, Risco e Compliance (ARC), especialmente no que diz respeito à atualização regular e verificação dos organigramas de gestão de crise, das listas de responsáveis por receber informações específicas e dos métodos de comunicação. As soluções propostas, como a automatização de tarefas repetitivas e a integração eficiente de sistemas, demonstraram-se eficazes, com uma taxa de satisfação de aproximadamente 80%. Estas melhorias resultaram numa redução do tempo de resposta, maior controlo das informações críticas e numa comunicação mais eficiente entre os diferentes níveis envolvidos na gestão de crises. Além disso, este trabalho contribuiu para a teoria e prática do campo da gestão de crises, ao conectar conceitos essenciais da literatura com as necessidades específicas de uma organização complexa e dinâmica como a NOS. Os resultados evidenciaram que a transformação digital e a automatização são componentes-chave para reforçar a robustez organizacional. 86 6.2 Limitações do Projeto Apesar dos resultados positivos alcançados, este projeto enfrentou algumas limitações que podem influenciar a sua aplicabilidade futura. Uma das principais limitações identificadas foi a dependência de ferramentas específicas, como o Power Automate e repositórios de dados estruturados em Excel. Embora estas ferramentas tenham demonstrado eficácia na automatização de tarefas e na gestão centralizada da informação, a sua aplicabilidade está restrita a ambientes onde estas tecnologias estão disponíveis, limitando a escalabilidade da solução para outras plataformas tecnológicas. Esta dependência resultou numa compreensão parcial de alguns fluxos de trabalho, o que, por sua vez, limitou a capacidade de otimizar totalmente processos específicos. Além disso, a natureza dinâmica e complexa da organização exigiria uma abordagem mais abrangente e flexível, que pudesse ser adaptada a diferentes cenários de crise e plataformas corporativas. 6.3 Trabalhos Futuros Para superar as limitações identificadas e aprimorar os resultados alcançados, recomenda-se que estudos futuros explorem a integração de soluções automatizadas com outras plataformas mais robustas e versáteis, como o UiPath. Esta ferramenta permitiria a finalização de processos de automação que não foram concluídos no presente projeto, garantindo maior eficiência, flexibilidade e escalabilidade nos processos de gestão da informação de crise. Além disso, sugere-se a implementação de avaliações contínuas das soluções implementadas, através de ciclos regulares de auditorias e testes abrangentes que considerem diversos cenários de crise. Por fim, recomenda-se que futuras investigações explorem a integração de soluções automatizadas com outras plataformas corporativas, com o objetivo de criar um ambiente digital coeso e altamente eficiente para a gestão de crises. 87 REFERÊNCIAS BIBLIOGRÁFICAS Alexander, M., & Kusleika, D. (2019). Excel 2019 Power Programming with VBA (1st ed.). Wiley. Almeida, F. (2016). Practical SQL Guide for Relational Databases . ISSUU Publishing. https://www.researchgate.net/publication/319852714_Practical_SQL_Guide_for_Relational_Da tabases Anderson, D. R., Sweeney, D. J., Williams, T. A., Camm, J. D., & Martin, R. K. (2011). An Introduction to Management Science: Quantitative Approaches to Decision Making (13th ed.). South-Western College Publishing. Bhushan, N., Rai, K., & St, C. (2022). Strategic Decision Making : Applying the Analytic Hierarchy Process (Decision Engineering) . SpringerISBN. https://www.researchgate.net/publication/362349130_Strategic_Decision_Making_Applying_th e_Analytic_Hierarchy_Process_Decision_Engineering Carvalho, A. (2017). Automatização em Excel . FCA. Choo, C. W. (1996). The knowing organization: How organizations use information to construct meaning, create knowledge and make decisions. International Journal of Information Management , 16 (5), 329–340. https://doi.org/https://doi.org/10.1016/0268-4012(96)00020-5 Codd, F. (1990). The Relational Model for Database Management (1st ed.). ADDISON-WESLEY PUBLISHING COMPANY. https://dl.acm.org/doi/book/10.5555/77708 Coelho, J. (2011). Introdução à base de dados utilizando Microsoft Access. Lisboa: Edição do Autor. https://hdl.handle.net/10400.2/3462 Coombs, T. (2014). Ongoing Crisis Communication: Planning, Managing and Responding (4th ed.). SAGE Publications. De Felice, F., Deldoost, M., Faizollahi, M., & Petrillo, A. (2015). Performance Measurement Model for the Supplier Selection Based on AHP. International Journal of Engineering Business Management , 7 . https://doi.org/10.5772/61702 Dellot, B., & Wallace-Stephens, F. (2017). The Age of Automation: Artificial intelligence, robotics and the future of low-skilled work . https://doteveryone.org.uk/wp-content/uploads/2019/01/rsa_the-ageof-automation-report.pdf Forbes Insights. (2019). Intelligent Automation: How AI and Automation Are Changing the Way Work Gets Done . Forbes Media 88 Goldberg, K. (2012). What Is Automation? IEEE Transactions on Automation Science and Engineering , 9 (1), 1–2. https://doi.org/10.1109/TASE.2011.2178910 Grant, K. (2004). Database processing: Fundamentals, design and implementation (International Edition), 9th Edition. International Journal of Information Management - INT J INFORM MANAGE , 24 , 441– 442. https://doi.org/10.1016/S0268-4012(04)00050-7 Gunjal, B. (2003, December). Database System: Concepts and Design . https://www.researchgate.net/publication/257298522_Database_System_Concepts_and_Desig n Held, B., & Richardson, T. (2018). Microsoft Excel Functions And Formulas . Mercury Learning & Information. Hubka, V., Eder, & Eder, W. (1988). Theory of Technical Systems, A Total Concept Theory for Engineering Design . Springer-Verlag. Hyde, K. M., & Maier, H. (2006). Distance-based and stochastic uncertainty analysis for multi-criteria decision analysis in Excel using Visual Basic for Applications. Environmental Modelling & Software , 21 , 1695–1710. https://doi.org/10.1016/j.envsoft.2005.08.004 IBM. (2018). Reinventing Business with Automation. IBM Corporation. IBM. (2019). IBM Z System Automation 4.3. IBM Corporation. Jaques, T. (2007). Reshaping Crisis Management: The challenge for organizational design (1st ed., Vol. 28). Organization Development Journal. Lomax, P. (1998). VB & VBA in a Nutshell: The Language. (1st ed.). O’Reilly Media. Microsoft. (2016). Overview of the different types of flows . Microsoft. Mikušová, M., & Horváthová, P. (2019). Prepared for a crisis? Basic elements of crisis management in an organisation. Economic Research-Ekonomska Istraživanja , 32 , 1844–1868. https://doi.org/10.1080/1331677X.2019.1640625 Mitroff, I. I., Pauchant, T. C., & Shrivastava, P. (1988). The structure of man-made organizational crises: Conceptual and empirical issues in the development of a general theory of crisis management. Technological Forecasting and Social Change , 33 (2), 83–107. https://doi.org/https://doi.org/10.1016/0040-1625(88)90075-3 Pinto, M. (2011). Microsoft Excel 2010 (Centro Atlântico). Saaty, T. (2008). Decision making with the Analytic Hierarchy Process. Int. J. Services Sciences Int. J. Services Sciences , 1 , 83–98. https://doi.org/10.1504/IJSSCI.2008.017590 89 Saaty, T. L. (1994). How to Make a Decision: The Analytic Hierarchy Process. Aestimum , 24 . https://doi.org/10.13128/Aestimum-7138 Saaty, T., & Vargas, L. (2001). Models, Methods, Concepts & Applications of the Analytic Hierarchy Process . Kluwer Academic Publishers. https://doi.org/10.1007/978-1-4614-3597-6 Sadao, J., Bastos, Y., & Barbosa, R. (2005). O uso de fontes de informação por executivos do setor de tecnologia da informação . Anais do VI Encontro Nacional de Pesquisa em Ciência da Informação (ENANCIB), Brasília, DF. Şahin, M., & Yurdugül, H. (2018). A Content Analysis Study on the Use of Analytic Hierarchy Process in Educational Studies. Eğitimde ve Psikolojide Ölçme ve Değerlendirme Dergisi , 9 , 376–392. https://doi.org/10.21031/epod.373784 Sahin, S., Ulubeyli, S., & Kazaza, A. (2015). Innovative Crisis Management in Construction: Approaches and the Process. Procedia - Social and Behavioral Sciences , 195 , 2298–2305. https://doi.org/https://doi.org/10.1016/j.sbspro.2015.06.181 Spillan, J. (2000). Strategies for successful crisis management . Proceedings of the Southeast Decision Sciences Institute (SE DSI) Conference. Upadhyay, S., & Upadhyay, N. (2023). Mapping crisis communication in the communication research: what we know and what we don’t know. Humanities and Social Sciences Communications , 10 . https://doi.org/10.1057/s41599-023-02069-z Vasickova, V. (2020). Crisis Management Process - A Literature Review and a Conceptual Integration. Acta Oeconomica Pragensia , 27 , 61–77. https://doi.org/10.18267/j.aop.628 90 APÊNDICES O presente capítulo reúne os apêndices que complementam e enriquecem o conteúdo desta dissertação. Os apêndices incluem materiais suplementares, tais como documentos, fluxogramas, tabelas, scripts de automação, e outros elementos relevantes que foram utilizados ao longo da investigação, mas que, pela sua extensão ou natureza detalhada, não foram integrados no corpo principal do texto. Estes anexos servem como referência para uma compreensão mais aprofundada dos processos, metodologias e ferramentas discutidos ao longo deste estudo, proporcionando um suporte prático e técnico que sustenta análises e conclusões apresentadas. A organização dos apêndices segue uma estrutura clara e sequencial, facilitando a consulta e a correlação com os capítulos correspondentes da dissertação. Apêndice A – Fluxograma do processo de atualização da informação de Crise O presente apêndice apresenta um processo de BPMN que descreve o processo de atualização da informação de crise na NOS SGPS. Este diagrama foi desenvolvido com o objetivo de ilustrar, de forma clara e estruturada, as etapas envolvidas na gestão e atualização das informações críticas relacionadas com o Plano de Gestão de Crise (PGCrise). O fluxograma abrange desde a identificação das necessidades de atualização até à validação e disponibilização das informações nas ferramentas utilizadas pela organização 97 Apêndice B - Fluxo de informação do processo de atualização do PGCrise O presente apêndice apresenta o fluxo de informação relativo ao processo de atualização do Plano de Gestão de Crise (PGCrise) na NOS SGPS. Este diagrama tem como objetivo ilustrar, de forma clara e estruturada, o percurso das informações críticas desde a sua recolha até à sua validação e disponibilização nas ferramentas utilizadas pela organização. Figura B 1 - Fluxo de informação do processo de atualização do PGCrise Fonte: Elaboração Própria 98 Apêndice C – Características variáveis constituintes do novo repositório O presente apêndice descreve as características das variáveis que compõem o novo repositório de dados desenvolvido no âmbito da otimização do processo de gestão de crise na NOS SGPS. Estas variáveis foram cuidadosamente definidas e estruturadas para garantir a centralização, a consistência e a acessibilidade das informações críticas necessárias para a atualização e operacionalização do Plano de Gestão de Crise (PGCrise). Tabela C 1 - Características das variáveis da BD criada Fonte: Elaboração Própria Variável Descrição Organigramas.xlsm RefPessoas.xlsx RefCartoes.xlsm RefDirecoes.xlsm RefListas.xlsm RefMCA.xlsm RefOGCs.xlsm RefPapeis.xlsm Nome Nome do colaborador NOS X X Username Username do colaborador NOS X X Email E-mail do colaborador NOS X X Contacto Profissional Número do cartão NOS X X Tipo de Identidade Tipo de colaborador NOS (Externo/Interno) X X Local Trabalho Local de trabalho do colaborador NOS X X Tipo Area Tipo de área do OGC em que o colaborador NOS está incluído X X OGC Organigrama em que o colaborador NOS está incluído X X X Cluster Cluster da MCA atribuída ao colaborador NOS X Direção (ENF) Direção a que pertence o colaborador NOS X X X Papel PGC Papel de Crise atribuído ao colaborador NOS X X ID_MCA Atividade de Crise atribuída ao colaborador NOS X X Data início (Papel) Data de início do Papel de Crise X Data fim (Papel) Data de fim do Papel de Crise X Estado Papel Atividade do papel de Crise X Estado Colaborador Atividade do colaborador na empresa X 99 Cartão BCM Direito a cartão de contingência X Cartão BCM (#) Nº atribuído ao cartão de contingência X X eSIM Direito a cartão virtual eSIM X Crise Core Vermelha Inclusão do colaborador na lista de crise X Crise Core Laranja Inclusão do colaborador na lista de crise X Crise Core SIC Inclusão do colaborador na lista de crise X Crise Não Core Outros Inclusão do colaborador na lista de crise X Crise CE GC NOS Inclusão do colaborador na lista de crise X Crise NAO Core GC Inclusão do colaborador na lista de crise X Crise Ilhas SIC Inclusão do colaborador na lista de crise X Crise Redes Amarelo Inclusão do colaborador na lista de crise X Crise IT Amarelo Inclusão do colaborador na lista de crise X Crise SC Amarelo Inclusão do colaborador na lista de crise X Crise Redes GCN Inclusão do colaborador na lista de crise X Crise Redes GC Inclusão do colaborador na lista de crise X Crise IT GCN Inclusão do colaborador na lista de crise X Crise IT GC Inclusão do colaborador na lista de crise X Crise IT SIC Inclusão do colaborador na lista de crise X Crise IT GC NOS Inclusão do colaborador na lista de crise X Crise SC GCN Inclusão do colaborador na lista de crise X Crise Redes Outros Inclusão do colaborador na lista de crise X Crise SC GC NOS Inclusão do colaborador na lista de crise X Crise SC GC Inclusão do colaborador na lista de crise X Crise SC SIC Inclusão do colaborador na lista de crise X Crise Redes SIC Inclusão do colaborador na lista de crise X Crise SC Outros Inclusão do colaborador na lista de crise X Data de Início na Posição (ENF) Data Entrada na NOS X Data Desativação Data Saída NOS X Estado OGC Atividade do OGC X Data Criação OGC Data de Criação do OGC X Data Eliminação OGC Data de Eliminação do OGC X 100 Localização Portal BCM Link da página do OGC no portal BCM X ID_WS Nome da worksheet do OGC no ficheiro "OGC.xlsx" X Identidades Ativas Número de identidades ativas X Cluster Cluster da MCA X MCA Atividade de Crise X Requisitos Legislativos e Regulamentares Requisitos Legislativos X RTO Tempo de Recuperação Objetivo X RPO Ponto de Recuperação Objetivo X Prioridade Nível de Prioridade da MCA X Crítico Criticidade da MCA X Data Criação MCA Data Criação MCA X Data Eliminação MCA Data Eliminação MCA X Estado MCA Atividade da MCA X Lista de Distribuição Nome das Listas de Distribuição existentes X Tipologia Tipo de Lista X Responsabilidade Responsável pela atualização da Lista X Utilização Utilidade da Lista X Data Criação Lista Data de Criação da Lista X Data Eliminação Lista Data de Eliminação da Lista X Estado Lista Atividade da Lista X GC NOS Papel de Crise X GC NOS Deputy CE Papel de Crise X GC NOS Deputy Core Papel de Crise X GC NOS Deputy não Core Papel de Crise X GC Core Papel de Crise X GC não Core Papel de Crise X SIC Core Papel de Crise X SIC não Core Papel de Crise X GCN Core Papel de Crise X GCN Não Core Papel de Crise X 101 Outros Core Papel de Crise X Outros não Core Papel de Crise X Pivot BCM Papel de Crise X Tipo Cartão Tipologia do Cartão X Estado Cartão Atividade do Cartão X Ação Originalidade do Cartão X Localização Email do colaborador a que o cartão está associado X Data Criação Cartão Data de Criação do Cartão X Data Eliminação Cartão Data de Eliminação do Cartão X Papel PGC - Designação Designação do Papel X Responsabilidades Responsabilidades do Papel X Data Criação Papel Data de Criação do Papel de Crise X Data Eliminação Papel Data de Elininação do Papel de Crise X Estado Papel Atividade do papel de Crise X 102 Apêndice D – Matrizes criadas para o método AHP O presente apêndice apresenta as matrizes desenvolvidas no âmbito da aplicação do método Analytic Hierarchy Process (AHP), utilizadas para apoiar a tomada de decisão no processo de otimização da gestão de crise na NOS SGPS. As matrizes servem como um recurso valioso para a compreensão do processo de decisão e para a validação das soluções propostas, contribuindo para a robustez e a transparência das conclusões apresentadas. Tabela D 1 - Criação de uma matriz comparativa entre Ferramentas, para o critério "Integração com apps OutSystems" Fonte: Elaboração Própria IAO Power Automate UiPath Node-Red Automation Sucess Zapier Python Power Automate 1 0,20 0,25 0,20 0,33 0,14 UiPath 5 1 3 1 5 0,50 Node-Red 4,00 0,33 1 0,33 2 0,20 Automation Sucess 5 1 3,00 1 4 0,5 Zapier 3 0,2 0,50 0,25 1 0,25 Python 7,00 2,00 5 2 4 1 Tabela D 2 - Normalização da Matriz comparativa da tabela D 1 e Cálculo da preferência relativa de cada ferramenta Fonte: Elaboração Própria IAO Power Automate UiPath Node-Red Automation Sucess Zapier Python Pref.Relativa Power Automate 0,04 0,04 0,02 0,04 0,02 0,06 0,04 UiPath 0,20 0,21 0,24 0,21 0,31 0,19 0,23 Node-Red 0,16 0,07 0,08 0,07 0,12 0,08 0,10 Automation Sucess 0,20 0,21 0,24 0,21 0,24 0,19 0,22 Zapier 0,12 0,04 0,04 0,05 0,06 0,10 0,07 Python 0,28 0,42 0,39 0,42 0,24 0,39 0,36 Tabela D 3 - Criação de uma matriz comparativa entre Ferramentas, para o critério "Integração com apps Google" Fonte: Elaboração Própria IAG Power Automate UiPath Node-Red Automation Sucess Zapier Python Power Automate 1 2 4 2 0,25 0,5 UiPath 0,5 1 2 1 0,2 0,25 Node-Red 0,25 0,50 1 0,50 0,17 0,20 Automation Sucess 0,5 1 2 1 0,20 0,25 Zapier 4 5 6 5 1 0,5 Python 2 4 5 4 2 1 103 Tabela D 4 - Normalização da Matriz comparativa da Tabela D 3 e Cálculo da preferência relativa de cada ferramenta Fonte: Elaboração Própria IAG Power Automate UiPath Node-Red Automation Sucess Zapier Python Pref.Relativa Power Automate 0,12 0,15 0,20 0,15 0,07 0,19 0,14 UiPath 0,06 0,07 0,10 0,07 0,05 0,09 0,08 Node-Red 0,03 0,04 0,05 0,04 0,04 0,07 0,05 Automation Sucess 0,06 0,07 0,10 0,07 0,05 0,09 0,08 Zapier 0,48 0,37 0,30 0,37 0,26 0,19 0,33 Python 0,24 0,30 0,25 0,30 0,52 0,37 0,33 Tabela D 5 - Criação de uma matriz comparativa entre Ferramentas, para o critério "Custo" Fonte: Elaboração Própria Custo Power Automate UiPath Node-Red Automation Sucess Zapier Python Power Automate 1 3,00 0,33 3,00 1,00 0,33 UiPath 0,33 1 0,14 1 0,33 0,14 Node-Red 3,00 7,00 1 7,00 3 1,00 Automation Sucess 0,33 1 0,14 1 0,33 0,14 Zapier 1 3 0,33 3 1 0,33 Python 3,00 7,00 1 7 3 1 Tabela D 6 - Normalização da Matriz comparativa da D 5 e Cálculo da preferência relativa de cada ferramenta Fonte: Elaboração Própria Custo Power Automate UiPath Node-Red Automation Sucess Zapier Python Pref.Relativa Power Automate 0,12 0,14 0,11 0,14 0,12 0,11 0,12 UiPath 0,04 0,05 0,05 0,05 0,04 0,05 0,04 Node-Red 0,35 0,32 0,34 0,32 0,35 0,34 0,33 Automation Sucess 0,04 0,05 0,05 0,05 0,04 0,05 0,04 Zapier 0,12 0,14 0,11 0,14 0,12 0,11 0,12 Python 0,35 0,32 0,34 0,32 0,35 0,34 0,33 Tabela D 7 - Criação de uma matriz comparativa entre Ferramentas, para o critério "Segurança" Fonte: Elaboração Própria Segurança Power Automate UiPath Node-Red Automation Sucess Zapier Python Power Automate 1 0,33 4 0,33 5 2 UiPath 3 1 5 1 7 4 Node-Red 0,25 0,20 1 0,20 2 0,50 Automation Sucess 3 1 5,00 1 7 4 Zapier 0,2 0,14 0,50 0,14 1 0,33 Python 0,50 0,25 2 0,25 3 1 104 Tabela D 8 - Normalização da Matriz comparativa da Tabela D 7 e Cálculo da preferência relativa de cada ferramenta Fonte: Elaboração Própria Seg Power Automate UiPath Node-Red Automation Sucess Zapier Python Pref.Relativa Power Automate 0,13 0,11 0,23 0,11 0,20 0,17 0,16 UiPath 0,38 0,34 0,29 0,34 0,28 0,34 0,33 Node-Red 0,03 0,07 0,06 0,07 0,08 0,04 0,06 Automation Sucess 0,38 0,34 0,29 0,34 0,28 0,34 0,33 Zapier 0,03 0,05 0,03 0,05 0,04 0,03 0,04 Python 0,06 0,09 0,11 0,09 0,12 0,08 0,09 Tabela D 9 - Criação de uma matriz comparativa entre Ferramentas, para o critério "Curva de Aprendizagem" Fonte: Elaboração Própria CA Power Automate UiPath Node-Red Automation Sucess Zapier Python Power Automate 1 5 6 5 4 7 UiPath 0,2 1 2 1 0,5 3 Node-Red 0,17 0,5 1 0,5 0,25 4 Automation Sucess 0,2 1 2 1 0,5 3 Zapier 0,25 2 4 2 1 4 Python 0,14 0,33 0,25 0,33 0,25 1 Tabela D 10 - Normalização da Matriz comparativa da Tabela D 9 e Cálculo da preferência relativa de cada ferramenta Fonte: Elaboração Própria CA Power Automate UiPath Node-Red Automation Sucess Zapier Python Pref.Relativa Power Automate 0,51 0,51 0,39 0,51 0,62 0,32 0,48 UiPath 0,10 0,10 0,13 0,10 0,08 0,14 0,11 Node-Red 0,09 0,05 0,07 0,05 0,04 0,18 0,08 Automation Sucess 0,10 0,10 0,13 0,10 0,08 0,14 0,11 Zapier 0,13 0,20 0,26 0,20 0,15 0,18 0,19 Python 0,07 0,03 0,02 0,03 0,04 0,05 0,04 Tabela D 11 - Criação de uma matriz comparativa entre Ferramentas, para o critério "User Friendly" Fonte: Elaboração Própria U-F Power Automate UiPath Node-Red Automation Sucess Zapier Python Power Automate 1 5,00 3,00 5,00 0,50 7,00 UiPath 0,20 1 0,50 1 0,33 4,00 Node-Red 0,33 2,00 1 3,00 0,25 5,00 Automation Sucess 0,20 1 0,33 1 0,33 4,00 Zapier 2 3 4,00 3 1 9,00 Python 0,14 0,25 0,2 0,25 0,11 1 105 Tabela D 12 - Normalização da Matriz comparativa da Tabela D 11 e Cálculo da preferência relativa de cada ferramenta Fonte: Elaboração Própria U-F Power Automate UiPath Node-Red Automation Sucess Zapier Python Pref.Relativa Power Automate 0,26 0,41 0,33 0,38 0,20 0,23 0,30 UiPath 0,05 0,08 0,06 0,08 0,13 0,13 0,09 Node-Red 0,09 0,16 0,11 0,23 0,10 0,17 0,14 Automation Sucess 0,05 0,08 0,04 0,08 0,13 0,13 0,09 Zapier 0,52 0,24 0,44 0,23 0,40 0,30 0,35 Python 0,04 0,02 0,02 0,02 0,04 0,03 0,03 106 Apêndice E – Automatismos desenvolvidos O presente apêndice descreve os automatismos desenvolvidos no âmbito da otimização do processo de gestão de crise na NOS SGPS. Estes automatismos foram concebidos para agilizar tarefas repetitivas, reduzir erros manuais e garantir a atualização eficiente e consistente das informações críticas relacionadas com o Plano de Gestão de Crise (PGCrise). Figura E 1 - Inserção de colaborador no ficheiro master Fonte: Elaboração Própria 113 Figura E 15 - Script AtualizarListasFrontend – Inserção de colaborador no ficheiro master Fonte: Elaboração Própria Figura E 16 – Automatismo 7 - Entrada AD (Envio de Email) Fonte: Elaboração Própria 114 Figura E 17 – Automatismo 8 - Saída AD (Envio de Email) Fonte: Elaboração Própria Figura E 18 – Automatismo 9 – Entrada na Outlook Contacts Fonte: Elaboração Própria 115 Figura E 19 – Automatismo 10 –Saída na Outlook Contacts Fonte: Elaboração Própria Figura E 20 – Automatismo 11 – Envio de lembrete ao gestor da informação de Crise Fonte: Elaboração Própria 116 Figura E 21 – Automatismo 12 - AtualizarDataCPG_Publisher Fonte: Elaboração Própria Figura E 22 – Automatismo 13_1 – EntradasCPGExcel Fonte: Elaboração Própria 117 Figura E 23 – Automatismo 13_2 – EntradasCPGExcel Fonte: Elaboração Própria Figura E 24 – Automatismo 13_3 – EntradasCPGExcel Fonte: Elaboração Própria 118 Figura E 25 – Automatismo 13_4 – EntradasCPGExcel Fonte: Elaboração Própria Figura E 26 – Automatismo 13_5 – EntradasCPGExcel Fonte: Elaboração Própria 119 Figura E 27 – Automatismo 14_1 – SaidasCPGExcel Fonte: Elaboração Própria Figura E 28 – Automatismo 14_2 – SaidasCPGExcel Fonte: Elaboração Própria 120 Figura E 29 – Automatismo 14_3 – SaidasCPGExcel Fonte: Elaboração Própria Figura E 30 – Automatismo 14_4 – SaidasCPGExcel Fonte: Elaboração Própria 121 Figura E 31 – Automatismo 14_5 – SaidasCPGExcel Fonte: Elaboração Própria Figura E 32 – Automatismo 15_1 – EntradasExcelConfluence Fonte: Elaboração Própria 122 Figura E 33 – Automatismo 15_2 – EntradasExcelConfluence Fonte: Elaboração Própria Figura E 34 – Automatismo 15_3 – EntradasExcelConfluence Fonte: Elaboração Própria 129 Figura E 47 – automatismo 18_2 – Entrada SMSPro via API Fonte: Elaboração Própria Figura E 48 – Automatismo 19_1 - Saída SMS via API Fonte: Elaboração Própria 130 Figura E 49 – Automatismo 19_2 - Saída SMS via API Fonte: Elaboração Própria Figura E 50 – Automatismo 19_3 - Saída SMS via API Fonte: Elaboração Própria 131 Figura E 51 – Automatismo 20_1 – EntradaListasGUIA Fonte: Elaboração Própria Figura E 52 – Automatismo 20_2 – EntradaListasGUIA Fonte: Elaboração Própria 132 Figura E 53 – Automatismo 21_1 – SaidaListasGUIA Fonte: Elaboração Própria Figura E 54 – Automatismo 21_2 – SaidaListasGUIA Fonte: Elaboração Própria 133 Apêndice F – Checklist Execução Repositório de Dados O presente apêndice apresenta a checklist desenvolvida para a execução e validação do novo repositório de dados no âmbito do processo de gestão de crise na NOS SGPS. Esta checklist foi concebida como uma ferramenta prática para garantir que todas as etapas críticas na utilização da BD estejam descritas e disponíveis para consulta para os utilizadores da mesma. Tabela F 1 - Checklist de execução da BD Fonte: Elaboração própria Necessidade Tarefa Ficheiro Entrada no PGCrise Inserção do email do colaborador que deu entrada no PGCrise, numa nova linha, na coluna C. Isto leva a que haja um preenchimento total da informação pessoal e do estado de colaborador e respetiva data de entrada Organigramas.xlsm Entrada no PGCrise Inserção do OGC de Crise em que este colaborador vai ser inserido, selecionando um da lista disponível na coluna G. Isto leva a que haja um preenchimento do Tipo de Área Organigramas.xlsm Entrada no PGCrise Inserção do Papel de Crise que o colaborador vai assumir, selecionando um da lista disponível na coluna K. Isto leva a que haja um preenchimento dos campos "Cartão BCM", "Cartão BCM (#)", "eSIM", das Listas de Distribuição e ainda do campo "Cluster" para os colaboradores que não são GCN's. No caso dos GCN's o Cluster é atribuído depois de preencher o campo ID_MCA Organigramas.xlsm Entrada no PGCrise Inserção do ID_MCA (Se o papel for GCN's) assumido pelo colaborador, selecionando um da lista disponível na coluna K. Atualiza automaticamente a coluna Cluster (K).O campo ID_MCA não é preenchido a não ser que o papel seja GCN's Organigramas.xlsm Entrada no PGCrise No caso do papel ser GCN's, reeselecionar o papel atribuído depois de a coluna Cluster estar preenchida, pois há campos que foram preenchidos automaticamente aquando da inserção do Papel mas que dependem do Cluster e do ID_MCA (quando existem) Organigramas.xlsm Entrada no PGCrise Caso haja atribuição automática existem duas hipóteses: Ou o colaborador em questão já tinha um papel de crise anteriormente que lhe dava o direito a cartão BCM ou efetivaemente ele é um novo elemento no PGCrise com direito a um cartão BCM (estava livre na RefCartoes), deve-se então ir ao atualizar a localização do cartão no ficheiro de RefData de Cartões através do botão o botão "Atualizar Localização". RefCartoes.xlsm Entrada no PGCrise Caso não haja atribuição automática de um cartão BCM (não existe nenhum livre na RefCartoes) o campo será preenchido com "A Atribuir". Quando estiver algum cartão disponível, deve-se reselecionar o papel atribuído ao colaborador/es que tenham o output da coluna Cartão BCM (#) como "a atribuir" no ficheiro Organigramas, desde que tenham papel ativo. RefCartoes.xlsm / Organigramas.xlsm Saída da Empresa Preencher os campos "Estado Colaborador" e "Estado Papel" como "Inativo". Isto leva ao preenchimento automático do coluna "Data fim Papel" Organigramas.xlsm Saída da Empresa Caso o colaborador em processo de saída lhe tenha atribuído Cartão BCM, deve-se então abrir o ficheiro da RefData de Cartões, procurar pelo número e preencher a Localização com "Pedido devolução efectuado" RefCartoes.xlsm Saída da Empresa / Saída do Papel de Crise Assim que o cartão devolvido chegar à ARC, abrir o ficheiro de RefData de Cartões e inserir na coluna Localização o output "ARC" RefCartoes.xlsm / Organigramas.xlsm Saída do Papel de Crise Preencher os campo "Estado Papel" como "Inativo". Isto leva ao preenchimento automático do coluna "Data fim Papel" Organigramas.xlsm Alterações de MCA's Abrir o ficheiro de RefData de MCA's e alterar a MCA/MCA's que sofreram alterações nas suas características RefMCA.xlsm Adição de MCA Abrir o ficheiro de RefData de MCA's, adicionar a MCA em questão e preencher os campos todos da RefData RefMCA.xlsm Eliminação de MCA Abrir o ficheiro de RefData de MCA's, e preencher a data de eliminação da MCA RefMCA.xlsm Alterações de MCA's Para qualquer uma das 3 tarefas anteriores, Abrir o ficheiro de Organigramas, ir ao menu "Data" e selecionar "Refresh all" Organigramas.xlsm Alterações de Papeis Abrir o ficheiro de RefData de Papeis e alterar a os papeis que sofreram alterações RefPapeis.xlsm Adição de um Papel Abrir o ficheiro de RefData de Papeis, adicionar o papel em questão e preencher os campos todos da RefData RefPapeis.xlsm 134 Eliminação de um Papel Abrir o ficheiro de RefData de Papeis, e preencher a data de eliminação do Papel RefPapeis.xlsm Alterações de Papeis Para qualquer uma das 3 tarefas anteriores, Abrir o ficheiro de Organigramas, ir ao menu "Data" e selecionar "Refresh all" Organigramas.xlsm Alterações de OGC's Abrir o ficheiro de RefData de OGC's e alterar os que sofreram alterações nas suas características RefOGCs Adição de um OGC Abrir o ficheiro de RefData de OGC's, adicionar o OGC em questão e preencher os campos todos da RefData RefOGCs Eliminação de OGC Abrir o ficheiro de RefData de OGC's, e preencher a data de eliminação do OGC RefOGCs Alterações de OGC's Para qualquer uma das 3 tarefas anteriores, Abrir o ficheiro de Organigramas, ir ao menu "Data" e selecionar "Refresh all" Organigramas.xlsm Alterações de Listas de Distribuição Abrir o ficheiro de RefData de Listas e alterar as que sofreram alterações nas suas características RefListas.xlsm Adição de uma Lista de Distribuição Abrir o ficheiro de RefData de Listas, adicionar a Lista em questão e preencher os campos todos da RefData RefListas.xlsm Eliminação de uma Lista de Distrbuição Abrir o ficheiro de RefData de Listas, e preencher a data de eliminação da Lista RefListas.xlsm Alterações de Listas de Distribuição Para qualquer uma das 2 tarefas anteriores, Abrir o ficheiro de Organigramas, e selecionar o botão "Atualizar listas" Organigramas.xlsm Adição de uma Direção A adição de uma direção é automática. Quando o mesmo acontece, é enviado um email a notificar da necessidade de preencher o negócio em que se enquadra essa direção RefDirecoes.xlsm Eliminação de uma Direção Quando uma direção é eliminada, deve-se preencher o campo "Data Eliminação" RefDirecoes.xlsm 135 Apêndice G – Questionário de feedback de utilizadores Este questionário tem por objetivo perceber o feedback dos três utilizadores da ferramenta de automatização, medindo a perceção dos colaboradores quanto à melhoria na eficiência dos processos automatizados. Utilize a seguinte escala para avaliar os automatismos criados (1 – Discordo Totalmente, 2 – Discordo, 3 – Não concordo nem discordo, 4 – Concordo, 5 - Concordo Totalmente) Formulário de avaliação dos automatismos criados Escala 1 2 3 4 5 O automatismo é user-friendly O automatismo reduz significativamente o tempo necessário para realizar a atualização do PGCrise O automatismo funciona como esperado O automatismo ajudou a melhorar a qualidade de trabalho O automatismo facilita a colaboração com colegas de outros departamentos O automatismo tem integração total com as aplicações necessárias para desempenhar as atividades O tempo de resposta do automatismo é adequado às exigências do trabalho É fácil corrigir o automatismo caso algo não funcione de acordo com o esperado 136