Capítulo 17 – Metodologia de Implementação

Base de Conhecimento MASTERINSOFT®

 

17.1. Introdução – A importância de uma metodologia

A MASTERINSOFT® é uma plataforma altamente configurável, relacional e orientada a processos. Isso significa que pode adaptar-se a organizações muito diferentes, mas também exige uma implementação bem conduzida.

Uma implementação sem metodologia pode levar a três problemas principais:

1. Configurar o sistema sem compreender verdadeiramente o negócio.
2. Replicar maus processos existentes.
3. Criar dados, entidades e fluxos sem coerência futura.

Por isso, a metodologia de implementação é essencial. Ela garante que todos os Master Partners seguem uma abordagem comum, mantendo qualidade, consistência e capacidade de evolução.

A implementação não deve começar pela configuração da plataforma. Deve começar pela compreensão do cliente.

17.2. Visão geral das fases

A implementação deve seguir uma sequência lógica:

1. Levantamento de requisitos.
2. Diagnóstico dos processos atuais.
3. Modelação dos processos futuros.
4. Desenho do modelo de dados.
5. Definição de permissões e perfis.
6. Configuração da plataforma.
7. Configuração do BPM.
8. Configuração de dashboards.
9. Configuração documental.
10. Migração ou carregamento inicial de dados.
11. Testes e validação.
12. Formação.
13. Go-live.
14. Acompanhamento e melhoria contínua.

Estas fases podem ser adaptadas à dimensão do cliente, mas não devem ser ignoradas.

17.3. Fase 1 – Levantamento de requisitos

O levantamento de requisitos é a fase onde o Master Partner compreende a realidade da organização.

O objetivo não é perguntar ao cliente “que campos quer no sistema”. O objetivo é perceber como a empresa funciona.

Devem ser analisados:

1. Quem são os utilizadores.
2. Que departamentos existem.
3. Que processos são executados.
4. Que documentos são usados.
5. Que indicadores são necessários.
6. Que problemas existem atualmente.
7. Que sistemas ou ficheiros são utilizados.

Exemplo:

Se o cliente diz “preciso de gerir projetos”, o Master Partner deve aprofundar:

1. Que tipos de projetos existem?
2. Quem aprova os projetos?
3. Existem orçamentos?
4. Existem horas associadas?
5. Há compras ligadas aos projetos?
6. Há relatórios obrigatórios?
7. Existem auditorias?

O entregável desta fase deve ser um documento de requisitos funcional, organizado por áreas: CRM, SRM, Projetos, RH, Património, Stock, Produção, BI e Documentação.

17.4. Fase 2 – Diagnóstico dos processos atuais

Depois de recolher requisitos, é necessário perceber como os processos funcionam hoje.

Esta fase permite identificar:

1. Processos manuais.
2. Duplicações de trabalho.
3. Aprovações por email.
4. Ficheiros Excel paralelos.
5. Falhas de rastreabilidade.
6. Pontos de bloqueio.
7. Falta de indicadores.

O objetivo é perceber a diferença entre:

1. Como o cliente acha que trabalha.
2. Como o cliente realmente trabalha.

Muitas vezes, o processo formal é diferente do processo real. O Master Partner deve descobrir o processo real.

Exemplo:

O cliente pode dizer que “todas as compras são aprovadas”. Mas, na prática, algumas compras podem ser feitas por email, outras por telefone e outras sem registo prévio.

Esta fase permite identificar oportunidades de melhoria antes da configuração.

17.5. Fase 3 – Modelação dos processos futuros

Depois de compreender o processo atual, deve ser desenhado o processo futuro.

Aqui o Master Partner não deve apenas copiar o que existe. Deve melhorar.

Cada processo deve ser representado com:

1. Início.
2. Etapas.
3. Responsáveis.
4. Estados.
5. Regras.
6. Aprovações.
7. Documentos associados.
8. Resultado esperado.

Exemplo de processo de compra:

1. Pedido de compra criado.
2. Validação pelo gestor.
3. Aprovação financeira.
4. Seleção de fornecedor.
5. Emissão de ordem de compra.
6. Receção.
7. Validação da fatura.
8. Fecho.

Nesta fase, o Master Partner deve identificar onde o BPM será aplicado.

Perguntas essenciais:

1. Que evento inicia o processo?
2. Que condições determinam o próximo passo?
3. Que ações devem ser automáticas?
4. Quem deve ser notificado?
5. Que dados devem ser obrigatórios?

17.6. Fase 4 – Desenho do modelo de dados

O modelo de dados é a base da implementação.

Nesta fase, define-se como a realidade do cliente será representada dentro da MASTERINSOFT®.

Devem ser definidas:

1. Entidades.
2. Campos.
3. Relações.
4. Estados.
5. Campos obrigatórios.
6. Campos calculados.
7. Regras de validação.

Exemplo:

Para gerir projetos, podem ser necessárias entidades como:

1. Projeto.
2. Fase.
3. Tarefa.
4. Entregável.
5. Timesheet.
6. Rubrica orçamental.
7. Despesa.
8. Documento.

O erro mais comum é criar campos duplicados em várias entidades.

Exemplo errado:

Guardar o nome do cliente dentro de cada projeto como texto.

Exemplo correto:

Projeto ligado à entidade Conta/Cliente através de uma relação.

Este princípio é fundamental para manter a coerência do sistema.

17.7. Fase 5 – Definição de permissões e perfis

Antes de configurar o sistema, é necessário definir quem pode ver, editar, aprovar ou consultar informação.

A MASTERINSOFT® deve refletir a estrutura real da organização.

Devem ser definidos perfis como:

1. Administrador.
2. Gestor.
3. Comercial.
4. Técnico.
5. Financeiro.
6. Recursos Humanos.
7. Auditor.
8. Utilizador externo, se aplicável.

Cada perfil deve ter permissões sobre:

1. Entidades.
2. Campos.
3. Documentos.
4. Dashboards.
5. Ações de BPM.

Exemplo:

Um colaborador pode registar tempos, mas não alterar o custo/hora.

Um auditor pode consultar documentos e histórico, mas não alterar registos.

Esta fase é crítica para garantir segurança, governança e conformidade.

17.8. Fase 6 – Configuração da plataforma

Só depois das fases anteriores é que se deve iniciar a configuração.

A configuração deve seguir o modelo desenhado.

Inclui:

1. Criação de entidades.
2. Criação de campos.
3. Criação de relações.
4. Configuração de estados.
5. Definição de vistas/listagens.
6. Configuração de formulários.
7. Configuração de permissões.

A boa prática é configurar por blocos.

Exemplo:

1. Primeiro CRM.
2. Depois Projetos.
3. Depois RH.
4. Depois SRM.
5. Depois integrações relacionais.

Cada bloco deve ser testado antes de avançar.

17.9. Fase 7 – Configuração do BPM

O BPM é o motor operacional da plataforma.

Nesta fase, os processos modelados anteriormente são traduzidos para fluxos reais dentro do sistema.

Cada workflow deve ter:

1. Evento inicial.
2. Condições.
3. Etapas.
4. Estados.
5. Ações automáticas.
6. Responsáveis.
7. Notificações.
8. Regras de exceção.

Exemplo:

Evento: oportunidade marcada como ganha.

Ações:

1. Criar projeto.
2. Associar cliente.
3. Criar tarefas base.
4. Notificar gestor de projeto.
5. Gerar documento de início.

O BPM deve ser configurado com cuidado. Um processo mal configurado pode gerar tarefas erradas, notificações excessivas ou bloqueios operacionais.

17.10. Fase 8 – Configuração de dashboards e BI

Depois de configurar dados e processos, devem ser criados dashboards.

Os dashboards devem responder a perguntas de gestão.

Exemplos:

1. Qual o estado das oportunidades?
2. Qual a execução financeira dos projetos?
3. Que compras estão pendentes?
4. Qual a ocupação da equipa?
5. Que stock está abaixo do mínimo?
6. Qual a margem por cliente?

Os dashboards devem ser definidos por perfil.

Exemplo:

1. Direção: visão global.
2. Comercial: pipeline.
3. Financeiro: custos e faturação.
4. Operações: tarefas e produção.
5. RH: disponibilidade e tempos.

Um dashboard não deve ser apenas bonito. Deve ser útil para decidir.

17.11. Fase 9 – Configuração documental

A geração documental é uma das capacidades mais diferenciadoras da MASTERINSOFT®.

Nesta fase, são configurados templates DOCX com variáveis.

Devem ser identificados documentos como:

1. Propostas.
2. Contratos.
3. Relatórios de projeto.
4. Ordens de compra.
5. Relatórios de auditoria.
6. Fichas técnicas.
7. Documentos de produção.

Cada documento deve definir:

1. Entidade de origem.
2. Variáveis utilizadas.
3. Tabelas dinâmicas.
4. Condições.
5. Momento de geração.
6. Responsável pela validação.

Exemplo:

Um relatório de projeto pode incluir automaticamente:

1. Nome do cliente.
2. Nome do projeto.
3. Tarefas concluídas.
4. Horas registadas.
5. Custos por rubrica.
6. Documentos anexos.

17.12. Fase 10 – Migração ou carregamento inicial de dados

Nem sempre é necessário migrar tudo.

O Master Partner deve avaliar:

1. Que dados são essenciais.
2. Que dados estão atualizados.
3. Que dados estão duplicados.
4. Que dados devem ser limpos antes de importar.

Exemplos de dados iniciais:

1. Clientes.
2. Contactos.
3. Produtos.
4. Fornecedores.
5. Colaboradores.
6. Projetos em curso.
7. Stock existente.
8. Ativos patrimoniais.

A migração deve ser validada antes do go-live.

É preferível migrar menos dados, mas com qualidade, do que importar histórico desorganizado.

17.13. Fase 11 – Testes e validação

Os testes devem simular a realidade.

Não basta verificar se um campo grava corretamente.

É necessário testar fluxos completos.

Exemplos:

1. Lead → oportunidade → proposta → projeto.
2. Pedido de compra → aprovação → ordem de compra → stock.
3. Projeto → tarefa → timesheet → custo.
4. Encomenda → stock → produção → entrega.
5. Compra de equipamento → património → manutenção.

Os testes devem envolver utilizadores reais.

Cada teste deve ter:

1. Cenário.
2. Resultado esperado.
3. Resultado obtido.
4. Correções necessárias.
5. Validação final.

17.14. Fase 12 – Formação

A formação deve ser prática e orientada a funções.

Não deve ser uma apresentação genérica do sistema.

Cada utilizador deve aprender aquilo que vai usar.

Exemplos:

1. Comercial: gerir leads, oportunidades e propostas.
2. Gestor de projeto: acompanhar tarefas, custos e recursos.
3. Colaborador: registar tempos e consultar tarefas.
4. Financeiro: validar despesas e analisar custos.
5. Direção: consultar dashboards.

A formação deve explicar não só “como clicar”, mas também “porquê”.

O utilizador deve compreender o processo.

17.15. Fase 13 – Go-live

O go-live é o momento em que o sistema passa a ser usado em produção.

Deve ser preparado com cuidado.

Antes do go-live, confirmar:

1. Dados carregados.
2. Utilizadores criados.
3. Permissões validadas.
4. Workflows testados.
5. Documentos configurados.
6. Dashboards disponíveis.
7. Plano de suporte definido.

Durante os primeiros dias, é recomendável acompanhamento próximo.

O objetivo é corrigir rapidamente dúvidas, bloqueios ou ajustes necessários.

17.16. Fase 14 – Acompanhamento e melhoria contínua

A implementação não termina no go-live.

A MASTERINSOFT® é uma plataforma evolutiva.

Depois da entrada em produção, devem ser realizadas sessões de acompanhamento para avaliar:

1. Utilização real.
2. Dificuldades dos utilizadores.
3. Processos que precisam de ajuste.
4. Novos dashboards.
5. Novos documentos.
6. Novas automações.

Esta fase é fundamental para garantir que a plataforma continua alinhada com a organização.

17.17. Fatores críticos de sucesso

Uma implementação bem-sucedida depende de:

1. Envolvimento da direção.
2. Participação dos utilizadores-chave.
3. Boa análise inicial.
4. Modelo de dados bem desenhado.
5. Processos bem definidos.
6. Formação adequada.
7. Acompanhamento após go-live.

Sem estes elementos, mesmo uma plataforma poderosa pode não gerar todo o seu valor.

17.18. Erros comuns a evitar

1. Começar pela configuração antes da análise.
2. Criar entidades sem modelo relacional claro.
3. Duplicar dados entre módulos.
4. Copiar processos antigos sem melhoria.
5. Criar dashboards sem objetivo.
6. Subestimar formação.
7. Ignorar a gestão da mudança.
8. Migrar dados sem limpeza.
9. Automatizar processos mal definidos.
10. Não acompanhar o cliente após o go-live.

17.19. Conclusão do capítulo

A metodologia de implementação é o que transforma a MASTERINSOFT® numa solução de sucesso.

A plataforma oferece a capacidade.

O método garante o resultado.

Uma boa implementação deve sempre seguir esta lógica:

Compreender → Modelar → Configurar → Validar → Formar → Acompanhar

17.20. Mensagem-chave para Master Partners

Um Master Partner não implementa apenas tecnologia.

Implementa uma nova forma de trabalhar.

A qualidade da implementação determina o valor que o cliente vai obter da MASTERINSOFT®.