SEJA BEM VINDO,
A MIT é formada por 4 Macro Fases: PREPARAÇÃO, REFINAMENTO, REALIZAÇÃO E OPERAÇÃO, além dos grupos de atividades de Vendas e Monitoramento e Controle. Navegue por cada sessão e conheça mais da MIT Digital_________________________________________________________________________________________________________________________________________________________________________________________________________________
INTRODUÇÃO Este guia irá fornecer todos os recursos necessários para o uso da metodologia 
|
CICLO DE VENDA Aborda todo o processo comercial, desde a arquitetura do projeto até o primeiro contato do time de serviços com o cliente após a assinatura da proposta. 
|
MONITORAMENTO E CONTROLE DO PROJETO Este grupo de tarefas tem o objetivo de garantir a boa comunicação do Projeto aos Stakeholders 
|
_________________________________________________________________________________________________________________________________________________________________________________________________________________ |
|
|

É o alinhamento aprofundado das necessidades e expectativas, com definição do time do projeto e partes interessadas, revisão e confirmação do escopo, prazos e da estratégia em geral. |
ACESSE AQUI OS ENTREGÁVEIS E ATIVIDADES DESTA FASE

É o alinhamento mais aprofundado das necessidades e expectativas, com definição do time do projeto e partes interessadas, revisão e confirmação do escopo, dos prazos e da estratégia em geral. É também um momento de identificação/revisão dos riscos e alinhamento técnico. A organização geral deve compor o plano preliminar do projeto e promover um bom evento de abertura e determinação do baseline (versão 1). |

1.1.1 Reunião de Transição com Comercial Acessar Detalhes
É o momento onde ocorre a passagem de bastão da equipe comercial para equipe de projetos, através de uma reunião de alinhamento. Essa fase é essencial para avaliar se há algum descolamento de escopo e definir a estratégia a ser seguida.
Descrição das atividades: - Gerente e/ou Coordenador do Projeto ou PMO (conforme definição da Unidade) organiza agenda da reunião.
- Executivo de Soluções de Negócio, Arquiteto de Soluções, Gerente ou Coordenador do Projeto e Gerente de Portfólio de Projetos organizam insumos para reunião
- Arquiteto de Soluções ou Coordenador de Projeto, conforme definição/estratégia da unidade, preenche o documento de Transição Comercial - MIT065
- Durante a reunião devem ser avaliados/alinhados os seguintes itens:
- Requisitos do cliente e solução vendida
- Detalhe do escopo
- Alinhamento de custo x esforço (orçamento)
- Expectativas do Cliente
- Riscos Iniciais
- Detalhe das questões comerciais (Faturamento, despesas, etc)
- Marcos e Prazos do projeto
- Mapeamento inicial de Stakeholders
- Motivadores do negócio, metas, objetivos, métricas de sucesso
Caso as condições avaliadas durante a reunião estejam equalizadas, o projeto segue para o processo de iniciação e o Gerente ou Coordenador do Projeto deve registrar as informações discutidas no documento de Transição Comercial e armazená-lo no repositório do projeto. Caso seja identificado descolamento de escopo, o Gestor de Portfólio de Projetos e o Atendimento e Relacionamento avaliam as questões levantadas e definem a estratégia de abordagem dos GAPs com o cliente, avaliando a possibilidade de negociação de complemento do projeto com o cliente ou absorção dos gaps pelo projeto ou área. ____________________________________________________________________________________________________________________________________________________________________________________________________
ENTRADA(S): - Proposta Comercial
- Precificação
- Validação Interna da Proposta
|
ATORES: TOTVS - Executivo de Soluções de Negócio (ESN)*
- Arquiteto de Soluções / Engenheiro de Valor (Pré-venda)*
- Gestor de Portfólio de Projetos (GPP)*
- Gerente ou Coordenador do Projeto*
- CS unidade*
- CS Torre*
- PMO
- RMO
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obrigatório |
|


|
1.2.1 Validar Stakeholders Acessar Detalhes
Para entender quais serão as pessoas interessadas no projeto e o papel de cada uma, é necessário o alinhamento das informações na reunião de Passagem de Bastão com o Time Comercial e posteriormente, com o Cliente. Um importante papel que deve ser bem formalizado é o de Aprovador, pois estas pessoas devem ter o direito reconhecido pelo Cliente para aprovar (em diferentes níveis) as definições e entregas do Projeto.
Descrição das atividades: Para entender quais serão as pessoas interessadas no projeto e o papel de cada uma, é necessário o alinhamento das informações na reunião de Passagem de Bastão com o Time Comercial e posteriormente, com o Cliente. Um importante papel que deve ser bem formalizado é o de Aprovador, pois estas pessoas devem ter o direito reconhecido pelo Cliente para aprovar (em diferentes níveis) as definições e entregas do Projeto. ____________________________________________________________________________________________________________________________________________________________________________________________________
ATORES: TOTVS - Executivo de Soluções de Negócios*
- Arquiteto de Soluções*
- Gerente ou Coordenador do Projeto*
CLIENTE - Coordenador ou Comitê do Projeto *
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obrigatório |
|
1.2.2 Definir Estratégia Geral, Premissas, Restrições e Expectativas Acessar Detalhes
Este é um dos momentos mais importantes na condução do projeto, pois é quando se define a estratégia de como o projeto será executado, vinculando seu progresso aos requisitos e expectativas apresentados. É também o momento de fechar um acordo sobre os limites, premissas que podem identificar riscos e restrições que podem direcionar o escopo do projeto para nortear o planejamento. Revisão do repositório do projeto, aceleradores e templates necessários para o projeto.
Descrição das atividades: O Comitê do Projeto, em conjunto com o patrocinador, valida o alinhamento geral, que servirá de base para o planejamento geral do projeto e para a reunião de abertura (Boas-vindas). ____________________________________________________________________________________________________________________________________________________________________________________________________
ATORES: TOTVS - Executivo de Soluções de Negócios*
- Arquiteto de Soluções*
- Gerente ou Coordenador do Projeto*
CLIENTE - Coordenador ou Comitê do Projeto *
- Patrocinador do Projeto
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obrigatório |
|


|
1.3.1 Verificar aspectos técnicos Acessar Detalhes
A definição adequada do ambiente onde será executado o sistema é fundamental para os usuários (Cliente) terem uma boa experiência de uso da solução. É muito importante ter esta decisão bem estruturada, com sua decisão formalizada para evitar futuros atritos por má performance do sistema. Quando o ambiente é administrado pelo Cloud TOTVS, este cuidado se redobra porque o Cliente normalmente tem uma expectativa alta em relação à solução ter uma boa performance dentro da própria TOTVS. Portanto, esta etapa deve ser bem definida no processo de Aprovação Interna da Proposta e na Passagem de Bastão com o Comercial.
Descrição das atividades: - Se a solução do cliente estiver hospedada na TOTVS Cloud, Coordenador ou Gerente do Projeto deve entrar em contato com o time de Cloud para alinhamento do projeto e formalizar o documento de ambiente com o cliente.
- NOTA: durante o período de implantação, o Coordenador ou Gerente do Projeto é o responsável no cliente por acompanhar as atividades do ambiente juntamente com a equipe de Cloud. Na comunidade de Cloud temos documentos específicos
- Especialista de Infraestrutura conduz a análise do ambiente em conjunto com a TI do Cliente, produzindo o Check list ou Documento de Portabilidade (RM).
- Especialista pode, em função dos resultados da análise, propor mudanças para melhorar o ambiente (elaboração do documento de Estrutura de Sizing).
- NOTA: Registrar a negativa do Cliente, caso opte por não seguir as recomendações.
IMPORTANTE: a atividade de Sizing deve estar contemplada na Proposta Comercial para poder ser executada. - TI Cliente deve avaliar a proposta de melhoria e formalizar uma decisão junto ao Comitê do Projeto e para o Gerente ou Coordenador Projeto (TOTVS).
NOTA: Registrar no cronograma o tempo de adequação da infraestrutura para controle de progresso e dependências. ____________________________________________________________________________________________________________________________________________________________________________________________________
ENTRADA(S): - Cloud - Contrato de Serviço separado da proposta de implantação do projeto, assinado pelo cliente, com as definições do ambiente, no modelo de Standard ou Prime. As principais diferenças entre os modelos é tempo de SLA, disponibilidade do ambiente e acessos. Para ambos os casos, é elaborado uma Matriz RACI e um Catálogo de Serviços para cada projeto.
- On Premise (Sizing)– Subcontratação do time de TIS para avaliação e sugestão do ambiente necessário. Orçamento padrão de 40 horas vendidas obrigatoriamente na precificação do projeto para cobrir esses custos. Será elaborado o Documento de Portabilidade com os requisitos mínimos de infra, nos casos de produtos RM, para os outros produtos, é elaborado um Check List de Infra.
|
ATORES: TOTVS - Gerente ou Coordenador do Projeto*
- Analista de Infraestrutura*
- Analista de Cloud*
- Executivo de Soluções de Negócios*
- Arquiteto de Soluções*
CLIENTE - Coordenador ou Comitê do Projeto *
|
SAÍDA(S): - Documentos de Cloud elaborados de acordo com o projeto
- Análise da Infraestrutura do Cliente realizado com parecer técnico validado pela documentação de TIS.
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obrigatório |
|


|
1.4.1 Elaborar Cronograma e Definir Marcos do Projeto Acessar Detalhes
O cronograma é uma forma extremamente visual de exibir o sequenciamento de atividades dentro de um projeto, permitindo que você verifique as interdependências de tarefas e consiga visualizar o caminho crítico, de maneira a ter controle efetivo e mitigar riscos de atraso. - NOTA: Importante ter visibilidade do progresso de outros cronogramas complementares para a gestão.
Com isso, o Gerente do Projeto é capaz de medir o desempenho do projeto e realizar ações de correção ou antecipar eventuais problemas. A comunicação do que fazer e para quem fazer no tempo certo, mostrando a correlação entre as atividades é um fator fundamental de sucesso. A definição dos Marcos de Entrega e a composição dos entregáveis de cada marco deve ser realizada em conjunto com o cliente. - NOTA: Importante considerar que cada fase do projeto pode conter quantos marcos forem necessários de acordo com o contexto de cada projeto. Um entregável como, por exemplo, “Realizar as Capacitações” que pertence a fase “Realização” pode ser definido como marco de entrega dependendo do contexto do seu projeto.
Descrição das atividades: Gerente ou Coordenador do Projeto: - Organiza os entregáveis, atividades e dependências, considerando os limites de prazos acordados para os Marcos
- Revisa o esforço com a equipe alocada no projeto e valida o compromisso dos profissionais em relação aos prazos
- Com o planejamento definido e os custos alocados, a margem de lucro do projeto é definida e comparada com a margem de lucro vendida é possível ter visão do resultado financeiro do projeto.
- Define os Marcos de entrega e faz os acordos com o cliente, ajustando no cronograma, quais serão os entregáveis que compõem cada Marco.
____________________________________________________________________________________________________________________________________________________________________________________________________
ENTRADA(S): - Validação com o cliente das informações para o Planejamento do projeto
- Projeto na ferramenta de Gestão de Projetos
|
ATORES: TOTVS - Gerente ou Coordenador do Projeto*
- RMO*
CLIENTE - Coordenador ou Comitê do Projeto *
|
SAÍDA(S): - Cronograma - MIT032 elaborado, respeitando as expectativas executivas dos Marcos definidos e aprovados.
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obrigatório |
|
1.4.2 Definir Equipe Acessar Detalhes
Sabemos que todo projeto é realizado por pessoas. Portanto, selecionar bem sua equipe e garantir minimamente um perfil adequado avaliando função, habilidade e disponibilidade é outro fator importante de sucesso do projeto. Em caso de indisponibilidade, o RMO é responsável por indicar outras alternativas para substituição dos recursos, o que deve também ser bem alinhado com o Gerente ou Coordenador do Projeto, pois pode afetar custo, prazo e qualidade do projeto.
Descrição das atividades: - Gerente ou Coordenador do Projeto:
- Organiza os papéis definidos durante a Reunião de Passagem de Bastão
- Solicita recursos ao RMO, de acordo com o planejado
- RMO confirma disponibilidades dos seus recursos ou informa alternativas para o Gerente ou Coordenador do Projeto avaliar (empréstimo de recurso de outras Unidades ou alocação de Terceiros), de forma a cumprir com as expectativas validadas, conforme segue:
- Avalia conhecimento/experiência necessários
- Avalia cargo e nível (em função do custo)
- Avalia perfil geral para atendimento
- Analisa locais de atendimento
- Avalia coerência do escopo x demanda
Caso seja necessário a alocação de um Terceiro, o RMO terceiros deve ser envolvido, iniciando os processos para alocação de parceiros. - Gerente ou Coordenador de Projeto alinha com a equipe do projeto os papéis, metas e resultados esperados (Kick Off interno).
____________________________________________________________________________________________________________________________________________________________________________________________________
ATORES: TOTVS - Gerente ou Coordenador do Projeto*
- RMO*
- RMO Terceiros*
- Analistas/Especialistas*
CLIENTE - Coordenador ou Comitê do Projeto *
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obrigatório |
|
1.4.3 Determinar o Baseline 1 Acessar Detalhes
O Baseline é o acordo firmado entre as partes que demonstra todos os aspectos discutidos e tratados durante a preparação do projeto e é de fundamental importância que se estabeleça esta linha de base no Projeto. Tendo esta linha de base firmada, todas as mudanças futuras deverão ser analisadas e seus impactos deverão ser aprovados para criar uma nova linha de base, com exceção do ajuste previsto após o desenho da solução.
Descrição das atividades: Gerente ou Coordenador do Projeto valida o Plano geral do Projeto com o Cliente. ____________________________________________________________________________________________________________________________________________________________________________________________________
ATORES: TOTVS - Gerente ou Coordenador do Projeto*
- Usuários-Chave*
- Executivo de Soluções de Negócios
- Arquiteto de Soluções
CLIENTE - Coordenador ou Comitê do Projeto *
- Patrocinador*
|
SAÍDA(S): - Apresentação do baseline ao Comitê e Patrocinador do Projeto durante reunião de abertura do projeto (Kick Off).
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obrigatório |
|


|
1.5.1 Programar e Realizar a Reunião de Abertura do Projeto (Kick-Off) Acessar Detalhes
Devemos tratar esta Reunião de Abertura como um evento inicial do Projeto, que de fato o será para muitas pessoas. É um momento muito importante de alinhamento geral com todos os participantes que podem não ter tido acesso à estratégia, às mudanças que podem ocorrer, seus papéis como usuários-chave, etc. Por esta razão é que se deve explorar bem o lado de ganhos esperados, oportunidades de visibilidade aos participantes, como fica a Organização após a implementação do sistema, validar o compromisso de todos com o projeto, etc.
Descrição das atividades: - Gerente ou Coordenador do Projeto
- Valida o Planejamento geral do Projeto com o Cliente
- Elabora a apresentação em conjunto com o Cliente, estabelecendo uma linha lógica e de engajamento
- Valida a apresentação de Boas Vindas do projeto - MIT024, com o Cliente
- Cliente organiza internamente o evento com apoio do Gerente ou Coordenador Projeto
- Gerente ou Coordenador Projeto conduz a reunião com limites estabelecidos em conjunto com o Cliente, ou seja, com os papéis da apresentação bem definidos (ex. quem apresenta o objetivo e os benefícios normalmente é o Patrocinador).
____________________________________________________________________________________________________________________________________________________________________________________________________
ENTRADA(S): - Proposta Comercial assinada
- Cronograma
- Monitoramento e Controle do Projeto
|
ATORES: TOTVS - Gerente ou Coordenador do Projeto*
- Usuários-Chave*
- Executivo de Soluções de Negócios*
- Arquiteto de Soluções*
- Suporte TOTVS
CLIENTE - Coordenador ou Comitê do Projeto *
- Patrocinador*
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obrigatório |
|


|
1.6.1 Encerrar a fase e avaliar Quality Gate (Preparação) Acessar Detalhes
Revisão da fase e avaliação de completude
Descrição das atividades: Gerente ou Coordenador do Projeto revisa a completude dos entregáveis da fase, se existem pendências que precisam ser concluídas, se a qualidade entregue está de acordo com o esperado e se existem questões e riscos que precisam ser tratados antes de seguir para a próxima fase. ____________________________________________________________________________________________________________________________________________________________________________________________________
ATORES: TOTVS - Gerente ou Coordenador do Projeto*
CLIENTE - Coordenador ou Comitê do Projeto *
- Cliente*
|
SAÍDA(S): - Revisão do Gate e entregáveis da fase concluídos
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obrigatório |
|
|
|
|
__________________________________________________________________________________________________________________________________________________________________________________  É o desenho efetivo da solução a ser entregue, sendo revisto os requisitos sobre a análise dos processos e eliminação de gaps do escopo e/ou processo. |
ACESSE AQUI OS ENTREGÁVEIS E ATIVIDADES DESTA FASE

O Refinamento é resumidamente o desenho efetivo da solução a ser entregue, sendo revisto os requisitos sobre a análise dos processos, eliminação de gaps do escopo e/ou processo e a definição da configuração. Nesta fase as estratégias do projeto são refinadas e são definidos os fluxos de trabalho para as próximas fases. Além disso, é esperado que ao final desta fase seja elaborado o plano de Sprints para a construção e teste da solução Por esta razão é que normalmente temos ao final deste grupo uma versão de Baseline atualizada (versão 2), que deve ser a versão oficial do projeto, sendo alterada somente com aprovação de mudança pelo Comitê do Projeto. |

2.1.1 Workshop de Avaliação dos Processos Acessar Detalhes
É fundamental conhecer os processos do cliente de acordo com o escopo do projeto para poder desenhar a solução pensando nas mudanças que poderão ocorrer. Esta é uma etapa em que serão necessárias a condução de alguns workshops e entrevistas e é imprescindível que isso ocorra de forma direcionada ao que foi contratado para não gerar frustrações aos nossos clientes. DICA 1: Enviar o material de apoio para levantamento (questionários) antecipadamente para orientar o usuário-chave e prepará-lo melhor para o momento da reunião de levantamento. DICA 2: Solicitar antecipadamente cópias de modelos como relatórios, notas fiscais e qualquer documento que possa auxiliar o entendimento dos processos.
Descrição das atividades:
Analista / Especialista: - Avalia o escopo do projeto para direcionar as entrevistas, alinhando as expectativas durante as mesmas
- Realiza workshops com os usuários-chave do Cliente para entender os processos atuais, formulários e relatórios utilizados no mesmo
- Analista/Especialista deve criar os fluxos dos processos para projetos que contemplem a elaboração de um fluxo
- É responsável por validar e coletar as assinaturas para formalizar o desenho elaborado
- NOTA: Analista / Especialista deve deixar o Gerente ou Coordenador do Projeto sempre alinhado com a condução e status da validação
- DICA 1: As melhores práticas indicam que a validação conjunta dos processos facilita o entendimento e assinatura do Diagrama dos Processos.
- DICA 2: Realizar um double-check do entendimento com os usuários-chave (confirmação da comunicação)
____________________________________________________________________________________________________________________________________________________________________________________________________
ATORES: TOTVS - Analista / Especialista*
- Gerente ou Coordenador do Projeto*
CLIENTE - Coordenador ou Comitê do Projeto*
- Usuários-Chave*
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obrigatório |
|
2.1.2 Desenho de Processos e Configuração Acessar Detalhes
Basicamente, o desenho da solução consiste em demonstrar ao nosso Cliente que entendemos o contexto de negócio definido pelos usuários-chave e que estamos aptos a configurar adequadamente o sistema ao uso, atendendo às expectativas gerais apresentadas. Entretanto, se mesmo assim surgirem questões desta ordem (fora do escopo), o Analista / Especialista deve formalizar os gaps identificados através Solicitação de Mudança - MIT031, propor em conjunto com o Arquiteto e o Comitê do Projeto a melhor abordagem dos assuntos e oferecerem alternativas para os cenários. É muito importante ter o engajamento e responsabilidade dos usuários-chave na definição da solução. - NOTA: O papel do Analista / Especialista neste contexto é trazer sua experiência de outros projetos e contribuir com benchmark nos processos, mas a responsabilidade de definição deve ser do usuário-chave (Cliente).
Descrição das atividades:
- Analista / Especialista elabora o fluxo operacional de acordo com as definições dos usuários-chave, seguindo o escopo acordado com o Cliente e identificando os pontos de desvio para a análise de gaps.
- Usuário-chave valida o fluxo e o descritivo
- Analista / Especialista descreve detalhes relacionados ao fluxo conforme necessidade de clareza:
- Determinando regras de negócio
- Descrevendo racionais de cálculo
- Determinando critérios de entrada
- Determinando critérios de saída
- Identificando os resultados esperados
- Identificando as configurações sistêmicas (Plano de Configuração - Parametrização do Sistema)
- Analista / Especialista deve validar e ter aprovação do cliente no Diagrama dos Processos - MIT041 com os respectivos Usuários-Chave, determinando desta forma a solução a ser construída
- Gerente ou Coordenador do Projeto deve consolidar todos os Diagramas dos Processos - MIT041 aprovados, como registro do Projeto
- NOTA: Este evento pode ser observado como um importante Marco do Projeto.
____________________________________________________________________________________________________________________________________________________________________________________________________
ATORES: TOTVS - Analista / Especialista*
- Gerente ou Coordenador do Projeto*
CLIENTE - Coordenador ou Comitê do Projeto*
- Usuários-Chave*
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obrigatório |
|
2.1.3 Análise de Aderência e GAP's Acessar Detalhes
É essencial que esta análise de gaps seja realizada com o Cliente para identificar as reais necessidades antes de qualquer abordagem de negociação, para garantir valor agregado em qualquer análise de impactos e nos resultados no futuro. É igualmente importante que haja uma análise interna do panorama entre o Gerente ou Coordenador do Projeto e o Arquiteto para definir uma estratégia de abordagem onde deverão indicar uma solução viável para a continuidade do projeto (e gerar um sentimento de parceria com o Cliente). No fim das negociações e após a aprovação, é fundamental que o Gerente ou Coordenador do Projeto realize a atualização dos planos do projeto colocando os impactos levantados para aprovação do novo baseline versão 2.
Descrição das atividades: - Analista / Especialista e Usuários-Chave relacionam os gaps identificados no Diagrama dos Processos - MIT041 e listam na planilha de Monitoramento e Controle do Projeto - MIT013 para organizar o contexto geral
- Analista / Especialista, Gerente ou Coordenador do Projeto e Arquiteto analisam o panorama geral, identificam e definem uma estratégia de abordagem para viabilizar o projeto
- NOTA: A recomendação é realizar esta análise olhando o panorama geral ao invés de avaliar os gaps e mudanças individualmente, pois normalmente existe uma compensação entre itens novos e itens cancelados, balanceando a negociação.
- Gerente ou Coordenador do Projeto e Arquiteto classificam os gaps e submetem para estudo e aprovação do Comitê do Projeto
- Comitê do Projeto:
- Avalia o panorama geral para negociação dos itens (gaps e mudanças) entre as partes
- Aprova a versão final negociada
- Gerente ou Coordenador do Projeto registra o resultado e atualiza o histórico do Projeto com as mudanças e impactos absorvidos.
____________________________________________________________________________________________________________________________________________________________________________________________________
ATORES: TOTVS - Analista / Especialista*
- Gerente ou Coordenador do Projeto*
- Arquiteto de Soluções*
- Executivo de Soluções de Negócio
CLIENTE - Coordenador ou Comitê do Projeto*
- Usuários-Chave*
|
SAÍDA(S): - Análise de Gap e Mudança alinhada com o Cliente, com a definição do Arquiteto e Gerente ou Coordenador do Projeto sobre a abordagem e aprovação das mudanças através da Solicitação de Mudança - MIT031
- Aprovação de um novo baseline sobre as mudanças impactadas pelos gaps e mudanças (aprovados)
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obrigatório |
|


|
2.2.1 Execução do Protótipo/Workshop da Solução com o Cliente Acessar Detalhes
O objetivo desta etapa é realizar um protótipo preliminar, com base no que foi levantado, que ajude a validar com o cliente os requisitos e dar uma noção do que ele está adquirindo. Este tipo de cerimônia colabora com a antecipação de desvios de entendimento que normalmente são percebidos pelo cliente em etapas futuras do projeto. O protótipo deve responder às perguntas mais importantes, então, mantenha o foco nisso e não em ter algo 100% funcionando. O esforço de construção e execução do protótipo deve ser adequado de acordo com o contexto e orçamento de cada projeto.
Descrição das atividades: - Gerente ou Coordenador do Projeto organiza a cerimônia juntamente com o Comitê (Cliente)
- Analista/Especialista:
- Organizam o roteiro com base no escopo contratado e no que foi levantado
- Certificam-se que o ambiente definido para execução do protótipo esteja atualizado e funcional para garantir a qualidade da cerimônia
- Apresentam o protótipo para validação dos requisitos.
____________________________________________________________________________________________________________________________________________________________________________________________________
ATORES: TOTVS - Analista / Especialista de Implantação*
- Gerente ou Coordenador do Projeto*
CLIENTE - Coordenador ou Comitê do Projeto*
- Usuários-Chave*
|
SAÍDA(S): - Conhecimento básico do funcionamento da ferramenta e flexibilidade que pode proporcionar ao cliente.
- Diagrama dos Processos - MIT041, determinando o desenho da solução, aprovados pelos usuários-chaves (Cliente) e Comitê do Projeto.
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obrigatório |
|


|
2.3.1 Definir Ciclos e Cenários de Testes Acessar Detalhes
O Roteiro de Testes - MIT045 tem o importante papel de orientar os usuários responsáveis pelos testes a simularem todos os processos e seus respectivos cenários variados para garantir que a solução construída realmente atenda aos requisitos e expectativas gerais. É também um bom momento para reafirmar o compromisso com os usuários-chave sobre seu papel de responsáveis pela qualidade dos testes e garantir que estão validando a entrega de um sistema que será usado no dia-a-dia deles. - NOTA: Alguns clientes ainda solicitam executar esta etapa de validação em paralelo às tarefas diárias em um determinado período. É importante destacar que o roteiro estruturado é uma melhor opção, uma vez que o período de teste paralelo à operação pode não conter todos os cenários desejados na solução, aumentando o risco de problemas pós GO LIVE.
Descrição das atividades: - Usuários-Chave (Cliente) organizam os processos e diferentes cenários para cobrir todas as variações de negócio inseridas no contexto da solução
- NOTA: a equipe de projeto TOTVS deve apoiar esta atividade orientando o preenchimento do roteiro de testes, mas a responsabilidade é do Cliente em elaborá-lo
- Analista / Especialista, Gerente ou Coordenador do Projeto organizam, em cima dos cenários propostos, os critérios e limites estabelecidos de como realizarão o teste integrado do sistema
- NOTA: O Teste Integrado do Sistema é o ciclo que garante o bom funcionamento do sistema e normalmente tem um teor mais técnico, ou seja, o sistema é executado com todas as funcionalidades previstas. Os valores e resultados esperados são apurados na validação de entrega
- Gerente do Projeto (Cliente) valida com os usuários-chave o Roteiro de Testes - MIT045 e o publica oficialmente como base dos testes a serem realizados.
____________________________________________________________________________________________________________________________________________________________________________________________________
ATORES: TOTVS - Analista / Especialista de Implantação*
- Gerente ou Coordenador do Projeto*
CLIENTE - Coordenador ou Comitê do Projeto*
- Usuários-Chave*
- Gestores funcionais de áreas de negócio
|
SAÍDA(S): Elaboração do Roteiro de Testes - MIT045 iniciada. NOTA: É uma boa prática iniciar a definição dos roteiros de testes neste momento e fase, porém essa atividade deverá ser finalizada antes da execução dos testes, na fase realização.
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obrigatório |
|


|
2.4.1 Preparação da Capacitação Acessar Detalhes
Organizar a Capacitação com antecedência é fundamental para garantir a efetiva participação de todas as pessoas necessárias no processo, além de garantir que a infraestrutura necessária estará pronta para as datas programadas. - NOTA: esta tarefa pode ser feita em paralelo ao documento de Roteiro de Testes - MIT045, porém a experiência nos traz que é mais fácil organizar a capacitação com base no Roteiro de Testes - MIT045, definido. Entretanto, ocorre muitas vezes que a para a organização geral (infraestrutura) é necessário iniciar antes para garantir a disponibilidade de todos (aviso com antecedência).
Descrição das atividades: - Analistas / Especialistas devem fornecer a sequência de trabalho e conteúdo programático
- Usuários-Chave (Cliente) organizam o calendário, o conteúdo programático e os participantes de acordo com os processos identificados no roteiro de Testes
- Equipe interna do Cliente organiza a infraestrutura para que a capacitação possa ser realizada:
- Local físico
- Máquinas disponíveis
- Acessos (rede)
- Transporte / estadia
- Comitê do Projeto aprova o plano com infraestrutura
- Equipe do Projeto realiza a comunicação da capacitação, considerando todos os detalhes supracitados
- NOTA: é importante considerar no plano de capacitação todas as restrições impostas pela questão de infraestrutura
____________________________________________________________________________________________________________________________________________________________________________________________________
ATORES: TOTVS - Analista / Especialista de Implantação*
- Gerente ou Coordenador do Projeto*
CLIENTE - Coordenador ou Comitê do Projeto*
- Usuários-Chave*
|
SAÍDA(S): NOTA: É uma boa prática iniciar a definição dos roteiros de capacitação neste momento e fase, porém essa atividade deverá ser finalizada antes da execução das capacitações, na fase realização. |
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obrigatório |
|


|
2.5.1 Definição de Conversão de Dados e Interface Acessar Detalhes
Organizar antecipadamente como serão as cargas de dados é fundamental, porque será possível perceber necessidades que geram esforço adicional de construção, seja no âmbito técnico (desenvolvimento de rotinas de cargas), como no âmbito de negócio (para informações cadastradas manualmente). Outro aspecto muito importante neste momento é determinar os responsáveis, o método, quais os critérios de validação e regras de conversão.
Descrição das atividades: - Analista / Especialista e Usuários-Chave (Cliente) avaliam as necessidades de carga de dados para que a solução esteja disponível em sua plenitude, conforme planejamento. Os aspectos avaliados são:
- Qual dado / Item de conversão
- Responsável pela extração
- Haverá de/para? Como será realizado?
- Responsável pela carga
- Qual método (manual / rotina)?
- Critérios de validação
- Responsável pela validação
- Prazos devem constar no cronograma
- Gerente do Projeto (Cliente) aprova os planos de cargas e interfaces
____________________________________________________________________________________________________________________________________________________________________________________________________
ATORES: TOTVS - Analista / Especialista de Implantação*
- Gerente ou Coordenador do Projeto*
CLIENTE - Coordenador ou Comitê do Projeto*
- Usuários-Chave*
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obrigatório |
|


|
2.6.1 Backlog do Projeto e Planejamento das Sprints e Releases Acessar Detalhes
Conduzir um Sprint requer bastante energia e foco. Antes de iniciar um Sprint, você precisará ter a equipe e os desafios certos. Também precisará de tempo e espaço para conduzir seu Sprint. Ou seja, preparar-se para aplicar esse método é fundamental para o sucesso final. O tempo definido para cada Sprint deve ser adequado ao contexto de cada projeto. Idealmente de 2 a 4 semanas.
Descrição das atividades: - Definir o backlog do produto, com todos os requisitos de produtos a serem entregues;
- Definir os entregáveis de cada Sprint de acordo com o time disponível e o período definido para a sprint;
- O planejamento da sprint pode envolver o time do projeto, se necessário, para definição do que é mais importante entregar primeiro levando em consideração o valor agregado ao negócio.
- No processo de detalhamento do backlog deve-se levar em consideração as características do produto e o escopo do projeto.
3. Levar em consideração que as entregas parciais podem ser agrupadas por um conjunto de Sprints, denominado Release, para que seja possível ter uma validação parcial ou entregar uma funcionalidade ou produto em produção. ____________________________________________________________________________________________________________________________________________________________________________________________________
ATORES: TOTVS - Analista / Especialista de Implantação*
- Analista / Consultor de Implantação*
CLIENTE - Coordenador ou Comitê do Projeto*
|
SAÍDA(S): - Plano de Sprints e Releases definido.
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obrigatório |
_ |


|
2.7.1 Encerrar a fase e avaliar Quality Gate (Refinamento) Acessar Detalhes
Revisar todos os aspectos do planejamento geral do Projeto é essencial para reavaliar se realmente todos os pontos foram alinhados, verificar se ainda há alguma pendência, estabelecer um novo compromisso com o Comitê, formalizar um novo baseline e comunicar os Stakeholders de todas as esferas. - NOTA: A partir deste ponto, toda mudança solicitada causará maior impacto do que havia ocorrido até este momento. Portanto, redobra-se o cuidado da análise de impactos para quaisquer novas solicitações.
Descrição das atividades: - Gerente ou Coordenador do Projeto:
- Verifica a completude dos entregáveis da fase
- Organiza as novas informações provindas da fase Refinamento.
- De posse das informações organizadas, revisa os impactos analisados, as aprovações realizadas, comunicação efetivamente realizada e atualiza o baseline do Projeto
- Comitê do Projeto aprova o planejamento geral
- Publicação do Planejamento Oficial
____________________________________________________________________________________________________________________________________________________________________________________________________
ATORES: TOTVS - Analista / Especialista de Implantação*
CLIENTE - Coordenador ou Comitê do Projeto*
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obrigatório |
|
|
|
|
_________________________________________________________________________________________________________________________________________________________________________________________________________________ 
É a construção de fato sobre o desenho detalhado e aprovado na fase anterior. A construção e testes são baseadas em Sprints com base no backlog. |
ACESSE AQUI OS ENTREGÁVEIS E ATIVIDADES DESTA FASE

É a construção de fato sobre o desenho detalhado aprovado na fase anterior. Esta construção implica na disponibilidade dos ambientes de trabalho, execução das sprints de configuração do sistema, desenvolvimento das customizações, carga dos dados e validação da entrega, através de ciclos técnicos e de negócio. É importante definir quais testes críticos deverão ser feitos na transição (virada) e rever o plano de virada do sistema para o ambiente produtivo. A construção e testes são baseadas em Sprints com base no backlog. A execução do plano de virada e dos testes integrados ocorrem nesta etapa. Recapitulando, este grupo de tarefas, têm o objetivo de controlar a construção do sistema dentro do desenho aprovado, garantir o atendimento dos requisitos e um bom plano de virada, administrando a entrega dentro do planejamento aprovado com o Cliente. |

3.1.1 Configurar Produto Acessar Detalhes
É nesta etapa que a configuração do produto ocorre como o combinado e aprovado pelo cliente, respeitando o que foi definido na fase de refinamento e priorizado para cada sprint. Caso surjam questões não previstas ou tratadas na fase anterior, estas serão discutidas pelo time nas reuniões de retrospectivas da Sprint e dependendo da questão deve-se obrigatoriamente registrar uma Solicitação de Mudança para que seja avaliado o impacto e se tenha uma aprovação formal desta, que pode alterar prazo, custo ou qualidade definida durante o Refinamento da Solução. As entregas ocorrem através de Sprints (iterações) com tempo definido (idealmente de 2 a 4 semanas) e cada Sprint deve entregar um incremento do produto que pode ou não ser validado com o cliente, de acordo com o planejamento das releases (grupos de Sprints). É esperado que as seguintes cerimônias aconteçam a cada ciclo de Sprint: - Planejamento da Sprint: Cerimônia para definição do objetivo da sprint, escopo de trabalho, como e o que será entregue.
- Reunião da Iteração: (“Daily”) É a reunião de acompanhamento da sprint, onde é verificado o andamento da Sprint. De curta duração (não mais que 30 min), na qual cada membro reflete sobre: O que fez de ontem para hoje? O que farei de hoje até amanhã? Existe algum impedimento?
A recorrência da reunião pode ser definida de acordo com o contexto de cada projeto e pode ser realizada com todo o time do projeto com ou sem a participação do Coordenador ou Gerente do Projeto. - Revisão da Sprint: é a cerimônia de apresentação do que ficou pronto para validação e coleta de feedback.
- Retrospectiva da Sprint: é a última atividade da sprint, na qual a equipe avalia sua própria atuação durante o processo de trabalho e planeja ações de melhoria a serem implementadas na próxima sprint.
Questões como: O que deu certo? O que pode melhorar? pendências e aprendizado (lições aprendidas) devem ser abordadas e registradas na planilha de Monitoramento e Controle do Projeto. NOTA: Recomenda-se organizar várias Solicitações de Mudança - MIT031 em conjunto para se ter uma melhor percepção dos impactos, ao invés de avaliá-las individualmente. Para tanto, pode-se estipular momentos / datas programadas para solicitar, avaliar e aprovar a demanda.
Descrição das atividades:
- Durante a Sprint o Analista ou Consultor de Implantação:
- Configura o sistema com base no Diagrama dos processos aprovado pelo Cliente e backlog priorizado para a Sprint.
- Reporta o avanço, riscos ou issues encontrados, eventuais atrasos e desvios ocorridos através das reuniões da iteração, ou das reuniões diárias.
- O Gerente ou Coordenador do Projeto acompanha evolução e trabalha na comunicação e alinhamento com o Comitê do Projeto ou Cliente.
- Ao final de cada Sprint é esperado que ocorra a reunião de retrospectiva, com todo o time que participou da Sprint.
- Após o encerramento de cada Sprint, inicia-se um novo ciclo de iteração até que todo o backlog do produto seja entregue.
____________________________________________________________________________________________________________________________________________________________________________________________________
ATORES: TOTVS - Analista / Consultor de Implantação*
- Gerente ou Coordenador do Projeto*
CLIENTE - Coordenador ou Comitê do Projeto*
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obrigatório |
|
3.1.2 Encomendar / Desenvolver Customizações Acessar Detalhes
Customizações / Personalizações devem ter um cuidado especial, pois podem afetar tanto o plano do projeto, como o funcionamento adequado do sistema, considerando o desenho da solução. Para mitigar estes riscos, os usuários-chave envolvidos devem estar acessíveis a utilizar rotinas padrões o máximo possível, assim como os analistas/especialistas estarem aptos a entender as necessidades e apresentar alternativas coerentes com o negócio e operação do Cliente. Ao identificar uma necessidade de customização, o Analista / Especialista deve elaborar a Especificação da Customização informando detalhes importantes para aumentar a qualidade de entrega. O desenvolvimento das customizações deve seguir o combinado e aprovado pelo Cliente, ou seja, seguir o que foi definido no Diagrama dos Processos MIT041 e/ou Especificação da Customização - MIT044
Descrição das atividades: - Analista / Especialista e Usuários-Chave (Cliente) avaliam os detalhes das necessidades de customizações, respeitando o escopo do projeto aprovado no Desenho da Solução (TO BE) e resultados da Análise de GAPs
- Analista / Especialista descreve os detalhes funcionais na Especificação da Customização para encaminhamento / solicitação do desenvolvimento ao time da Fábrica de Software ou do próprio time de desenvolvedores do projeto
- Líder Técnico da Fábrica de Software / Desenvolvedor do projeto avalia as solicitações e valida seu entendimento com o Analista / Especialista responsável pela encomenda.
- Líder Técnico organiza as entregas com o time de desenvolvimento (Backlog / Sprints / Deploy)
- Time da Fábrica realiza o desenvolvimento de acordo com o que foi definido no Diagrama dos Processos MIT041 ou Especificação da Customização - MIT044 e no Projeto Lógico (PL)
- Líder Técnico da Fábrica de Software:
- Reporta avanço, riscos / issues encontrados, eventuais atrasos e desvios ocorridos
- Envia as evidências de teste realizado, demonstrando o resultado positivo.
- Gerente ou Coordenador do Projeto acompanha a evolução e trabalha na comunicação e alinhamento com o Comitê do Projeto / Cliente.
____________________________________________________________________________________________________________________________________________________________________________________________________
ATORES: TOTVS - Desenvolvedor (Fábrica de Software)*
- Líder Técnico (Fábrica de Software)*
- Analista / Consultor de Implantação*
- Gerente ou Coordenador do Projeto*
CLIENTE - Coordenador ou Comitê do Projeto*
|
SAÍDA(S): - Customizações desenvolvidas.
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obrigatório |
|


|
3.2.1 Capacitar Usuários Chave Acessar Detalhes
Esta capacitação deve conduzir os usuários-chave ao uso efetivo do sistema de acordo com o Desenho da Solução aprovado. Deve-se lembrar o compromisso alinhado na preparação / Reunião de Abertura do projeto, que os usuários-chave são responsáveis por replicar o conhecimento e também por eventual suporte.
Descrição das atividades: - Analistas / Consultores e Usuários-Chave se reúnem conforme planejamento da Capacitação realizada no Refinamento
- Os Analistas ou Consultores ministram as capacitações de acordo com o Desenho da Solução aprovado e respectivas configurações.
- Usuários-Chave:
- Devem absorver o conhecimento e realizar o aprofundamento do sistema na prática para garantir eficiência no uso
- Formalizam o recebimento do conhecimento e uso do sistema junto aos Consultores que ministraram o treinamento
- Gerente ou Coordenador do Projeto organiza as formalizações e realiza a validação desta etapa junto ao Comitê do Projeto
- O comitê do projeto aprova a capacitação mediante a assinatura do Roteiro de Capacitação.
____________________________________________________________________________________________________________________________________________________________________________________________________
ATORES: TOTVS - Analista / Consultor de Implantação*
- Gerente ou Coordenador do Projeto*
CLIENTE - Usuários-Chave*
- Coordenador ou Comitê do Projeto*
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obrigatório |
|


|
3.3.1 Preparar e Executar Carga de Dados Acessar Detalhes
Neste momento são realizadas as cargas identificadas e planejadas, seguindo o método estipulado, pelos respectivos responsáveis pela mesma. É de igual importância que se tenha critérios de validação para garantir que a carga tenha tido sucesso, para que os testes e validações seguintes possam gerar os resultados esperados. - NOTA: Nos casos de carga manual, ou seja, dados inseridos manualmente pelos usuários-chave, deve-se combinar muito bem o esforço e os prazos para que o cronograma esteja bem alinhado.
Descrição das atividades: - Analista(s) / Consultor(es) de implantação executam as cargas de dados com rotinas / ferramentas definidas, conforme planejado e alinhado durante a fase Refinamento.
- Usuários-Chave:
- Executam a carga de dados manualmente conforme planejado e alinhado durante a fase Refinamento.
- Validam os dados migrados, por um método ou outro, utilizando as ferramentas combinadas.
- Usuários e Analista(s) / Consultor (es) reportam avanço, riscos / issues encontrados, eventuais atrasos e desvios ocorridos.
- Gerente ou Coordenador do Projeto acompanha evolução e trabalha na comunicação e alinhamento com o Comitê do Projeto / Cliente.
____________________________________________________________________________________________________________________________________________________________________________________________________
ATORES: TOTVS - Analista / Consultor de Implantação*
- Gerente ou Coordenador do Projeto*
CLIENTE - Usuários-Chave*
- TI, se houver*
- Coordenador ou Comitê do Projeto*
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obrigatório |
|


|
3.4.1 Realizar Testes Unitários Acessar Detalhes
O objetivo principal desta tarefa é garantir o funcionamento do sistema para que os usuários-chave possam validar efetivamente a solução. Portanto, o alvo destes testes deve ser mais voltados em executar as rotinas e ter menos foco nos resultados esperados, como por exemplo o cálculo correto dos impostos. - NOTA: Esta divisão de prioridade ocorre porque muito dos resultados esperados tem relação direta com os cadastros e o negócio em si. Por esta razão é que se costuma planejar ciclos com aspectos diferentes.
Descrição das atividades: - Analista(s) / Consultor(es) de implantação, normalmente em conjunto com o time de TI, executam os testes elaborados no Roteiro de Testes com foco no funcionamento do sistema, a fim de garantir sua disponibilidade aos usuários-chave na validação efetiva.
- Analista(s) / Consultor(es) reportam avanço, riscos / issues encontrados, eventuais atrasos e desvios ocorridos.
- Gerente ou Coordenador do Projeto acompanha a evolução e trabalha na comunicação e alinhamento com o Comitê do Projeto / Cliente.
____________________________________________________________________________________________________________________________________________________________________________________________________
ATORES: TOTVS - Analista / Consultor de Implantação*
- Gerente ou Coordenador do Projeto*
CLIENTE - Coordenador ou Comitê do Projeto*
|
SAÍDA(S): - Sistema testado em toda sua funcionalidade, sem considerar resultados de negócio (que dependam de aspectos de cadastros e regras de negócio) e Roteiro de Testes - MIT045 atualizado.
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obrigatório |
|
3.4.2 Realizar Testes Integrados do sistema - Time TOTVS Acessar Detalhes
O objetivo principal desta tarefa é garantir, além do funcionamento do sistema, que os resultados esperados sejam validados, assim como os processos e seus diferentes cenários. Em alguns casos, é incluído após os testes integrados, o teste de carga do sistema.
Descrição das atividades: - Analista(s) / Consultor(es) se organizam de acordo com o planejado para executar a validação geral da solução.
- NOTA 1: nesta etapa, com o sistema em pleno funcionamento, deve-se validar os processos, seus diferentes cenários e apurar os resultados esperados.
- Analista(s) / Consultor(es) reportam o avanço, riscos / issues encontrados, eventuais atrasos e desvios ocorridos.
- Gerente ou Coordenador do Projeto acompanha evolução e trabalha na comunicação e alinhamento com o Comitê do Projeto / Cliente.
NOTA 2: o Gerente ou Coordenador do Projeto pode identificar a necessidade de fazer um teste de carga no sistema, devendo ser realizado nesta etapa, usando um documento de Termo de Validação - MIT010 com o resultado dos testes. ____________________________________________________________________________________________________________________________________________________________________________________________________
ATORES: TOTVS - Analista / Consultor de Implantação*
- Gerente ou Coordenador do Projeto*
- Suporte TOTVS
CLIENTE - Coordenador ou Comitê do Projeto*
|
SAÍDA(S): - Solução testada em toda sua funcionalidade, processos e cenários, considerando inclusive os resultados de negócio (que dependem de aspectos de cadastros e regras de negócio) e Roteiro de Testes - MIT045, atualizado.
- Se aplicável, o Termo de Validação - MIT010 com o resultado dos testes de carga.
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obrigatório |
|
3.4.3 Realizar Testes Integrados do sistema - Time cliente Acessar Detalhes
O objetivo principal desta tarefa é garantir, além do funcionamento do sistema, que os resultados esperados sejam validados, assim como os processos e seus diferentes cenários.
Descrição das atividades: - Analista(s) / Consultor(es) e Usuários-Chave se organizam de acordo com o planejado para executar a validação geral da solução.
- NOTA: nesta etapa, com o sistema em pleno funcionamento, deve-se validar os processos, seus diferentes cenários e apurar os resultados esperados.
- Analista(s) / Consultor(es) reportam o avanço, riscos / issues encontrados, eventuais atrasos e desvios ocorridos.
- Gerente ou Coordenador do Projeto acompanha evolução e trabalha na comunicação e alinhamento com o Comitê do Projeto / Cliente.
____________________________________________________________________________________________________________________________________________________________________________________________________
ATORES: TOTVS - Analista / Consultor de Implantação*
- Gerente ou Coordenador do Projeto*
CLIENTE - Usuários-Chave*
- Coordenador ou Comitê do Projeto*
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obrigatório |
|


|
3.5.1 Definir Testes de Virada (Melhor Prática) Acessar Detalhes
É fundamental restringir o lançamento oficial do sistema aos usuários-chave, para que estes possam realizar atividades reais no sistema já no ambiente de Produção, garantindo o funcionamento essencial do negócio, considerando todos os processos críticos.
Descrição das atividades: - Usuários-Chave definem as operações críticas como critério de GO LIVE, logo após a execução do Cutover
- Gerente ou Coordenador do Projeto:
- Acompanha as definições e avalia se estão de acordo com os critérios de qualidade estabelecidos
- Ao final, registra a decisão no Roteiro de Testes - MIT045.
____________________________________________________________________________________________________________________________________________________________________________________________________
ATORES: TOTVS - Analista / Consultor de Implantação*
- Gerente ou Coordenador do Projeto*
CLIENTE - Usuários-Chave (responsável pela execução)*
- Coordenador ou Comitê do Projeto*
|
____________________________________________________________________________________________________________________________________________________________________________________________________
|
|
3.5.2 Definir / Revisar Plano de Virada Acessar Detalhes
A Definição/Revisão do plano de virada deve ser realizado logo após serem obtidos os resultados dos Testes Integrados e Validação da Solução, onde se tem mais detalhes sobre as necessidades de suspensão do sistema, sobre as mudanças de processo no negócio, sobre o impacto nas demais áreas etc. É importante que qualquer nova questão que surja seja tratada neste momento, evitando assim postergar um problema que pode trazer impactos negativos para todo o projeto.
Descrição das atividades: - Analista / Especialista e Usuários-Chave (Cliente) reavaliam os detalhes dos impactos na transição do sistema para Produção após resultados, considerando aspectos técnicos e funcionais:
- Técnicos
- Ações de ambiente (infraestrutura)
- Ações de configuração
- Ações de transporte de dados
- Ações equalização de customizações
- Ações de atualização da aplicação (software), que pode decorrer ao longo do projeto
- Preparação de atividades Cloud (quando houver serviços de host).
- Funcionais:
- Alinhamento com as áreas que podem sofrer impacto com o período de suspensão (execução do cutover)
- Alinhamento com os Clientes sobre a mesma questão
- Alinhamento com Fornecedores e Parceiros sobre a mesma questão
- Treinamento e preparação das mudanças operacionais (processos TO BE)
- Plano de Contingência de negócio
- Comitê do Projeto aprova a revisão do plano de Virada e Rollback - MIT054
____________________________________________________________________________________________________________________________________________________________________________________________________
ATORES: TOTVS - Analista / Consultor de Implantação*
- Gerente ou Coordenador do Projeto*
- Cloud TOTVS (quando houver serviço de host)*
CLIENTE - Usuários-Chave*
- Coordenador ou Comitê do Projeto*
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obrigatório |
|
3.5.3 Aprovar e divulgar a virada Acessar Detalhes
A aprovação do Comitê (decisão de GO) deve ser seguida de uma divulgação oficial de liberação da execução do Transição a todos os interessados para que: - Todas as áreas envolvidas, Cliente, Fornecedores e Parceiros possam se programar adequadamente e/ou combinarem planos de contingência
- O projeto ganhe força política e estratégica na Organização
- O projeto tenha engajamento final, pois neste momento é fundamental que todos coloquem a devida prioridade do seu tempo em prol da qualidade da transição.
Adicionalmente, uma ação de comunicação interna TOTVS, clara e estruturada, fortalece a cooperação entre as áreas e assegura o suporte necessário para o sucesso do cliente após o Go Live. Descrição das atividades: - Comitê do Projeto aprova a revisão do Plano de Virada e Rollback - MIT054 e o divulga oficialmente juntamente com a estratégia de gestão da mudança.
- O CP envia um e-mail de Comunicação de Go Live para solicitar o apoio das áreas internas no alinhamento e na preparação para a entrada em produção de um cliente
____________________________________________________________________________________________________________________________________________________________________________________________________
ATORES: TOTVS - Analista / Consultor de Implantação*
- Gerente ou Coordenador do Projeto*
- Suporte TOTVS
CLIENTE - Usuários-Chave*
- Coordenador ou Comitê do Projeto*
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obrigatório |
|


|
3.6.1 Encerrar a fase e avaliar Quality Gate (Realização) Acessar Detalhes
Revisão do gate e conclusão das entregas da fase
Descrição das atividades: - Gerente ou Coordenador do Projeto revisam os entregáveis da fase.
____________________________________________________________________________________________________________________________________________________________________________________________________
ATORES: TOTVS - Gerente ou Coordenador do Projeto*
CLIENTE - Cliente*
- Coordenador ou Comitê do Projeto*
|
SAÍDA(S): - Revisão do Gate e entregáveis da fase concluídos.
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obrigatório |
|
|
|
|
_________________________________________________________________________________________________________________________________________________________________________________________________________________ 
É a execução das atividades de transição para entrada em produção e o período de acompanhamento ou Operação Assistida logo após a decisão de GO LIVE! |
ACESSE AQUI OS ENTREGÁVEIS E ATIVIDADES DESTA FASE

4.1.1 Preparar Ambiente de Produção Acessar Detalhes
Esta etapa consiste na preparação ou revisão do ambiente que será utilizado para a operação real do sistema na Organização. Portanto, é imprescindível que esteja dentro das especificações técnicas definidas ao longo do projeto. O checklist de instalação tem o objetivo de orientar detalhadamente os parâmetros técnicos, enquanto que o Plano de Virada e Rollback - MIT054 tem como objetivo trazer insumos extras para que o analista de infraestrutura possa ter uma visão mais ampla do ambiente e expectativas. - IMPORTANTE: equipe de TI deve participar efetivamente das ações, sendo o único pessoal com acesso ao ambiente de Produção, sendo assim responsável direto.
Descrição das atividades:
- Especialista de Infraestrutura prepara o ambiente de Produção seguindo as especificações técnicas definidas
- TI (Cliente) deve publicar o final da operação e os resultados desta
NOTA: todas as atividades definidas no Plano de Virada e Rollback - MIT054 para o ambiente devem ser executadas nesta etapa. ____________________________________________________________________________________________________________________________________________________________________________________________________
ATORES: TOTVS - Gerente ou Coordenador do Projeto*
- Analista de Infraestrutura*
- Analista de Cloud*
CLIENTE - Gerente ou Coordenador do Projeto *
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obrigatório |
|
4.1.2 Treinar Usuários Finais (Melhor prática) Acessar Detalhes
Este treinamento deve conduzir os usuários finais ao uso efetivo do sistema, respeitando todas as definições estabelecidas no Refinamento da Solução, no Roteiro de Capacitação e na entrega efetiva realizada. - NOTA: Esta tarefa é de total responsabilidade do Cliente, salvo o mesmo ter comprado da TOTVS este tipo de serviço no escopo do Projeto. Mesmo tendo adquirido, é importante trazer os usuários-chave como participantes para que possam assumir o papel de replicadores e de referência no processo de negócio.
Descrição das atividades: - Usuários-Chave (replicadores) se reúnem conforme organização interna (Cliente) e ministram os treinamentos de acordo com o Refinamento da Solução e Roteiro de Capacitação revisado
- Usuários Finais devem absorver o conhecimento e realizar o aprofundamento do sistema na prática para garantir eficiência no uso
- Usuários-chave:
- Formalizam o treinamento junto aos Usuários Finais
- Organizam as formalizações e realizam a validação desta etapa junto ao Comitê do Projeto.
____________________________________________________________________________________________________________________________________________________________________________________________________
ATORES: TOTVS - Analista / Consultor de implantação*
- Gerente ou Coordenador do Projeto*
CLIENTE - Usuários-Chave (Replicadores)*
|
SAÍDA(S): - Capacitação realizada e validada.
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obrigatório |
|
4.1.3 Realizar alinhamento com suporte TOTVS (Melhor prática) Acessar Detalhes
Sabemos que após o projeto, para continuar uma boa experiência do Cliente, é fundamental alinhar a demanda com o time de suporte para que este possa se preparar para atender bem o Cliente deste ponto em diante em sua Jornada. O ponto aqui é descrever o escopo da demanda, tendências de suporte e data efetiva do GO LIVE.
Descrição das atividades: - Gerente ou Coordenador do Projeto preenche o documento de Transição para o Suporte , realiza reunião de alinhamento com o time de Suporte TOTVS das funcionalidades que serão utilizadas pelo cliente.
____________________________________________________________________________________________________________________________________________________________________________________________________
ATORES: TOTVS - Gerente ou Coordenador do Projeto*
- Suporte TOTVS*
|
____________________________________________________________________________________________________________________________________________________________________________________________________
|
|
4.1.4 Definir e Formalizar a Estratégia e Contrato de Acompanhamento Acessar Detalhes
Desde o momento que os usuários-chave recebem o treinamento aprofundado e percebem a demanda exigida de suporte, deve-se neste momento, decidir o quanto estes podem absorver do suporte e o quanto ainda precisarão de suporte do time de consultores, considerando a demanda. A Proposta complementar deve refletir o cenário aprovado pelo Comitê, uma vez que foram considerados os aspectos gerais e revisados após a validação da solução. - NOTA: Deve-se tomar muito cuidado nesta definição, considerando as expertises por frente conduzida x autonomia do Cliente para propor um cenário equilibrado e eficiente.
Descrição das atividades: - Analistas / Consultores e Usuários-Chave se reúnem com Gerente ou Coordenador do Projeto e representante do Comitê (Cliente) para reavaliar as necessidades de acompanhamento pós GO LIVE, considerando os aspectos de suporte x demanda com base nos resultados da Capacitação realizada
- Gerente ou Coordenador do Projeto:
- Planeja o acompanhamento conforme demanda revisada para apurar os impactos de custo x qualidade previstas na fase de pré-venda
- Registra a decisão via Ata de Reunião
- Comitê do Projeto aprova novo planejamento e eventual diferença de custo, com base no cenário apresentado pela equipe do projeto (analistas / consultores e usuários-chave)
- Executivo de Soluções de Negócios elabora uma Proposta Comercial complementar para suprir os gaps de acompanhamento identificados e aprovados pelo Comitê (caso necessário)
- Cliente aprova a Proposta Complementar.
____________________________________________________________________________________________________________________________________________________________________________________________________
ATORES: TOTVS - Analista / Consultor de implantação*
- Gerente ou Coordenador do Projeto*
- Executivo de Soluções de Negócio*
CLIENTE - Usuários-Chave*
- Gerente ou Coordenador do Projeto *
|
SAÍDA(S): - Definição dos responsáveis pelo suporte pós GO LIVE, registradas em Ata de Reunião - MIT005 e aprovada pelo Comitê
- Proposta Comercial complementar aprovada pelo Cliente (caso necessário).
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obrigatório |
|
4.1.5 Executar a Virada (Transição) Acessar Detalhes
A execução da transição (virada) deve ser realizada com bastante foco e atenção aos resultados esperados para garantir a qualidade do ambiente de Produção. Caso ocorram imprevistos, deve-se ter um plano de contingência e/ou pessoas que possam decidir alternativas rapidamente, uma vez que normalmente se trabalha em uma janela restrita. Assim que finalizado, deve certificar-se sobre os resultados e liberar o sistema para a última etapa antes da publicação oficial, que é a execução de operações críticas em Produção (Teste de Virada).
Descrição das atividades: - Analistas / Especialista e Usuários-Chave (Cliente) executam as tarefas planejadas na transição (virada) do sistema para Produção, conforme definido no Plano de Virada e Rollback - MIT054, considerando aspectos técnicos e funcionais:
- Técnicos
- Ações de ambiente (infraestrutura)
- Ações de configuração
- Ações de transporte de dados
- Ações equalização de customizações
- Ações de atualização da aplicação (software), que pode decorrer ao longo do projeto
- Funcionais:
- Alinhamento com as áreas que podem sofrer impacto com o período de suspensão
- Alinhamento com os Clientes sobre a mesma questão
- Alinhamento com Fornecedores e Parceiros sobre a mesma questão
- Treinamento e preparação das mudanças operacionais (processos TO BE)
- Plano de Contingência de negócio
- Comitê do Projeto comunica o término e o resultado da execução, liberando o Teste de Virada.
____________________________________________________________________________________________________________________________________________________________________________________________________
ATORES: TOTVS - Analista / Especialista*
- Analista de Infraestrutura*
- Gerente ou Coordenador do Projeto*
CLIENTE - Usuários-Chave*
- Gerente ou Coordenador do Projeto *
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obrigatório |
|
4.1.6 Executar Testes de Virada Acessar Detalhes
É fundamental restringir o lançamento oficial do sistema aos usuários-chave, para que estes possam realizar atividades reais no sistema já no ambiente de Produção, garantindo o funcionamento essencial do negócio. Assim que validada as operações críticas, confirma-se o GO LIVE para todos os demais participantes da Organização. NOTA: O tempo dedicado deve ter sido planejado antecipadamente, assim como os limites, caso a execução não saia exatamente como o esperado.
Descrição das atividades: - Usuários-Chave executam as operações críticas definidas como critério de GO LIVE, logo após a execução da Transição (Virada)
- Analista / Especialista acompanha os resultados e avalia se estão de acordo com os critérios de qualidade estabelecidos
- Ao final, Gerente ou Coordenador do Projeto registra a decisão via Ata de Reunião
- Comitê do Projeto publica oficialmente o GO LIVE.
____________________________________________________________________________________________________________________________________________________________________________________________________
ATORES: TOTVS - Analista / Especialista*
- Gerente ou Coordenador do Projeto*
CLIENTE - Usuários-Chave*
- Gerente ou Coordenador do Projeto *
|
SAÍDA(S): - Resultado do Teste de Virada em Produção
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obrigatório |
|
4.1.7 Aprovar e Divulgar o GO / NO GO Oficial Acessar Detalhes
O Comitê deve divulgar oficialmente a decisão do GO / NO-GO a todos os interessados para que: - Todas as áreas envolvidas possam iniciar os trabalhos normalmente
- O sistema seja liberado para atuação junto aos Clientes, Fornecedores e Parceiros
- Tenhamos um evento formal de reconhecimento da entrega do Projeto.
Descrição das atividades: Comitê do Projeto divulga oficialmente a decisão de GO / NO-GO, com base no resultado do Teste de Virada (podendo ser positivo ou negativo). ____________________________________________________________________________________________________________________________________________________________________________________________________
ENTRADA(S): - Ciclos de Testes realizados com sucesso
|
ATORES: TOTVS - Gerente ou Coordenador do Projeto*
CLIENTE - Usuários-Chave*
- Gerente ou Coordenador do Projeto *
|
SAÍDA(S): - Termo de Validação - MIT010 (Termo de autorização para GO Live) assinado, com a decisão de GO/NO-GO divulgado oficialmente na Organização e entre todas as partes interessadas do Projeto.
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obrigatório |
|

|
4.2.1 Acompanhar Operação Assistida Acessar Detalhes
A operação assistida é o acompanhamento das equipes do cliente e pelo time de serviços para esclarecimento de dúvidas após primeiros dias em produção conforme estabelecido em contrato como período de garantia. Após o Comitê do Projeto divulgar oficialmente a decisão de GO / NO-GO, inicia-se a Operação Assistida de acordo com a estratégia e propostas complementares aprovadas. Este período é bastante crítico e deve ser conduzido a levar o Cliente em um nível de autonomia suficiente para executar sua operação de forma segura e confiante. - NOTA: É comum surgir novas oportunidades neste período, sendo novos negócios e/ou continuidade da assistência recorrente. É importante que o Gerente ou Coordenador do Projeto esteja atento para alinhar com o Executivo de Soluções de Negócio no momento da finalização.
Descrição das atividades: - Analistas / Especialistas contratados (de acordo com a estratégia e contratos aprovados) iniciam o suporte à operação do sistema
- Gerente ou Coordenador do Projeto avalia periodicamente os resultados e prepara gradativamente a retirada da equipe de suporte
- Coordenador (Cliente) em conjunto com os usuários-chave se preparam para manter a operação sem o suporte local do time do projeto, de forma gradativa e de acordo com a estratégia aprovada
- Gerente ou Coordenador do Projeto encerra formalmente a operação assistida ao término do período combinado.
____________________________________________________________________________________________________________________________________________________________________________________________________
ENTRADA(S): - Usuários finais operando o sistema
|
ATORES: TOTVS - Analista / Especialista*
- Gerente ou Coordenador do Projeto*
CLIENTE - Gerente ou Coordenador do Projeto *
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obrigatório |
|
4.2.2 Encaminhamento do cliente ao Suporte Padrão Acessar Detalhes
Sabemos que após o projeto, para continuar uma boa experiência do Cliente, é fundamental alinhar a demanda com o time de suporte para que este possa se preparar para atender bem o Cliente deste ponto em diante em sua Jornada. O objetivo é esclarecer e direcionar o Cliente ao tipo de serviço que melhor pode agregar valor à sua operação e à sua experiência com a TOTVS. Com o fim da operação assistida o cliente entra em loops de potenciais atividades com a TOTVS. Este momento que não tem data para terminar é a macro etapa de Ongoing na Jornada do Cliente. Para conhecer em detalhes a Central de Relacionamento TOTVS e os Canais Digitais que o cliente tem acesso, acesse a trilha na Universidade TOTVS.
Descrição das atividades: Gerente ou Coordenador do Projeto repassa as informações sobre o funcionamento do Suporte e as opções de Atendimento ao cliente. ____________________________________________________________________________________________________________________________________________________________________________________________________
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obrigatório |
|

|
4.3.1 Realizar retrospectiva do projeto (Relacionamento e cliente) Acessar Detalhes
Este momento de encaminhamento ao time de Relacionamento deve ser usado para: - Deixar o Cliente ciente da estrutura da TOTVS
- Estreitar o relacionamento
- Procurar desenvolver as oportunidades identificadas ao longo do Projeto
- Buscar o feedback geral.
Descrição das atividades: - Gerente ou Coordenador do Projeto repassa o histórico do projeto com o Executivo de Soluções de Negócio e as oportunidades identificadas ao longo do Projeto
- Gerente ou Coordenador do Projeto e Executivo de Soluções de Negócio alinham com o Cliente as novas oportunidades e reforçam o elo de parceria.
____________________________________________________________________________________________________________________________________________________________________________________________________
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obrigatório |
|
4.3.2 Registar lições aprendidas do projeto Acessar Detalhes
O tema lição aprendida deve ser bem estruturado para realmente se ter uma base de conhecimento que possa ser reutilizada e compartilhada aos colaboradores que buscam experiências adquiridas.
Descrição das atividades: Gerente ou Coordenador do Projeto organiza os registros coletados ao longo do projeto para registrá-los de forma estruturada. ____________________________________________________________________________________________________________________________________________________________________________________________________
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obrigatório |
|
4.3.3 Encerrar o projeto Acessar Detalhes
A formalização de conclusão é um evento imprescindível para o reconhecimento do término do projeto e serve também para liberar os recursos para outros projetos, assim como reconhecer a Receita atrelada à conclusão de fato. Importante ressaltar que a construção deste encerramento inicia-se desde a preparação do projeto, definindo os critérios de aceite ao longo do mesmo. A boa condução com transparência e evidências dos acordos e entregas realizadas e reconhecidas, farão com que este momento seja muito suave junto ao Cliente, firmando uma boa experiência em sua Jornada!
Descrição das atividades: - Gerente ou Coordenador do Projeto organiza as evidências de avanço e conclusão do Projeto e apresenta ao Comitê para formalizar o encerramento do projeto, inclusive com a validação de marcos pendentes ou parcelas de faturamento pendentes
- Comitê do Projeto e Patrocinador aprovam o Certificado de Conclusão de Serviços - MIT062 (Termo de Encerramento)
- Gerente ou Coordenador do Projeto organiza as ações para o encerramento do projeto internamente e envia ao PMO, após o cliente dar o aceite no Certificado de Conclusão de Serviços - MIT062 (Termo de Encerramento)
- NOTA: Devem ser observadas políticas e procedimentos internos de cada unidade que podem determinar regras específicas, além das descritas neste documento, para o encerramento administrativo do projeto.
____________________________________________________________________________________________________________________________________________________________________________________________________
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obrigatório |
|
|
|
|
_________________________________________________________________________________________________________________________________________________________________________________________________________________
PAPÉIS E RESPONSABILIDADES A Matriz RACI a seguir orienta a atribuição das responsabilidades ao time do projeto TOTVS, de acordo com os entregáveis e artefatos desta metodologia. 
|
INDICADORES Monitorar os indicadores de desempenho de uma empresa é fundamental para saber se ela está no caminho certo. 
|
COLABORAÇÃO E AGRADECIMENTOS A concretização de um projeto desta natureza não se deve apenas aos seus autores, mas antes, a todos aqueles que de forma direta ou indireta se envolveram. 
|
_________________________________________________________________________________________________________________________________________________________________________________________________________________ |
|
|
SEA BIENVENIDO,
El MIT está formado por 4 Macro Fases: Preparación, Refinamiento, Realización y Operación además de los grupos de actividades de Ventas y Seguimiento y Control. Explore cada sesión y obtenga más información sobre MIT Digital_________________________________________________________________________________________________________________________________________________________________________________________________________________
INTRODUCCIÓN Esta guía le proporcionará todos los recursos que necesita para utilizar la metodología. 
|
CICLO DE VENTAS Abarca todo el proceso comercial, desde la arquitectura del proyecto hasta el primer contacto del equipo de servicio con el cliente tras la firma de la propuesta. 
|
MONITOR Y CONTROL DE PROYECTOS Este grupo de tareas tiene el objetivo de garantizar la buena comunicación del Proyecto a los Stakeholders 
|
_________________________________________________________________________________________________________________________________________________________________________________________________________________ |
|
|

Es el alineamiento más profundo de necesidades y expectativas, con la definición del equipo de proyecto y stakeholders, revisión y confirmación del alcance, plazos y la estrategia en general. |
ACCEDE AQUÍ A LOS ENTREGABLES Y ACTIVIDADES DE ESTA FASE

Es una alineación más profunda de las necesidades y expectativas, con la definición del equipo del proyecto y partes interesadas, y la revisión y confirmación del alcance, los plazos y la estrategia en general. También es hora de realizar una identificación/revisión de los riesgos y alineación técnica. La organización general debe conformar el plan preliminar del proyecto y promover un buen evento de apertura y la determinación de la baseline (versión 1). |

1.1.1 Reunión de Transición con Comercial Detalles de acceso
Es el momento en el que se lleva a cabo la entrega de testigo del equipo comercial al equipo del proyecto, a través de una reunión de alineación. Esta fase es esencial para evaluar si existe algún distanciamiento del alcance y definir la estrategia a seguir.
Descripción de actividades: - Gerente y/o coordinador de proyecto o PMO (según la definición de la Unidad) organiza la agenda de reuniones.
- Arquitecto de Soluciones o Coordinador de Proyecto, según la definición / estrategia de unidad, complete el documento de Transición Comercial - MIT065
- Ejecutivo de Soluciones de Negocio, Arquitecto de Soluciones, Gerente o Coordinador del Proyecto y Gerente de Portafolio de Proyectos organizan insumos para reunión
- Durante la reunión se deben evaluar/alinear los siguientes ítems:
- Requisitos del cliente y solución vendida
- Detalle del alcance
- Alineación de costo vs. esfuerzo (presupuesto)
- Expectativas del Cliente
- Riesgos iniciales
- Detalle de las cuestiones comerciales (Facturación, gastos, etc.)
- Hitos y plazos del proyecto
- Mapeo inicial de partes interesadas
- Impulsores del negocio, metas, objetivos, métricas de éxito
Si se ecualizan las condiciones evaluadas durante la reunión, el proyecto pasa al proceso de iniciación y el gerente o coordinador del proyecto debe registrar la información discutida a través del transición comercial y almacenarlo en el repositorio del proyecto. Si se identifica el distanciamiento del alcance, el Gestor de Portafolio de Proyectos y la Atención y Relación evalúan los problemas planteados y definen la estrategia de abordaje de los GAPS con el cliente, evaluando la posibilidad de negociar el complemento del proyecto con el cliente o absorber los gaps por el proyecto o área. ____________________________________________________________________________________________________________________________________________________________________________________________________
ENTRADA(S): - Propuesta Comercial
- Precios
- Validación interna de la Propuesta
|
ACTORES: TOTVS - Ejecutivo de Soluciones de Negocio*
- Arquitecto de Soluciones*
- Gestor de portafolio de proyectos*
- Gerente o coordinador del proyecto*
- PMO
- RMO
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obligatorio |
|


|
1.2.1 Validar Las Partes Interesadas Detalles de acceso
Para entender qué personas serán las interesadas en el proyecto y el papel de cada una, es necesario alinear la información en el encuentro de la Entrega de testigo con el Equipo Comercial y más tarde con el Cliente. Un importante papel que debe estar bien formalizado es el de Aprobador, porque estas personas deben tener el derecho reconocido por el Cliente de aprobar (en diferentes niveles) las definiciones y entregas del Proyecto.
Descripción de actividades: Genere o coordinador del proyecto valida los nombres y la función con el Cliente. El mapeo de las partes interesadas ahora servirá como una lista de validación del papel de cada uno. ____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Ejecutivo de Soluciones de Negocios*
- Arquitecto de Soluciones*
- Gerente o coordinador del proyecto*
CLIENTE - Coordinador o Comité de Proyecto*
|
SALIDA(S): - Mapeo de Partes Interesadas y Matriz RACI - MIT034 completada con las partes interesadas del proyecto.
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obrigatório |
|
1.2.2 Definir Estrategia General, Premisas y Restricciones, Alineación y Expectativas Detalles de acceso
Este es uno de los momentos más importantes en la conducción del proyecto, ya que es cuando se define la estrategia de cómo se ejecutará el proyecto, vinculando su progreso a los requisitos y expectativas presentados. También es el momento de cerrar un acuerdo sobre los límites, premisas que pueden identificar riesgos y restricciones que pueden dirigir el alcance del proyecto para orientar la planificación. Revisión del repositorio del proyecto, aceleradores y templates necesarios para el proyecto.
Descripción de actividades: El Comité del Proyecto, junto con el patrocinador, validan la alineación general, que servirá de base para la planificación general del proyecto y la reunión de apertura (Bienvenida). ____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Ejecutivo de Soluciones de Negocios*
- Arquitecto de Soluciones*
- Gerente o coordinador del proyecto*
CLIENTE - Coordinador o Comité de Proyecto*
- Patrocinador del proyecto
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obligatorio |
|


|
1.3.1 Verificar aspectos técnicos Detalles de acceso
La definición adecuada del entorno donde se ejecutará el sistema es fundamental para que los usuarios (Cliente) tengan una buena experiencia en el uso de la solución. Es muy importante tener esta decisión bien estructurada, con su decisión formalizada para evitar futuras fricciones por el bajo rendimiento del sistema. Cuando el entorno es administrado por Cloud TOTVS, este cuidado se redobla porque el Cliente normalmente tiene una gran expectativa de que la solución tenga un buen rendimiento dentro de TOTVS. Por lo tanto, esta etapa debe estar bien definida en el proceso de Aprobación Interna de la Propuesta y en la Entrega de testigo con el Comercial.
Descripción de actividades: - Si la solución del cliente está alojada en TOTVS Cloud, el coordinador o gerente de proyecto debe ponerse en contacto con el equipo de Cloud para la alineación del proyecto y formalizar el documento de entorno con el cliente.
- NOTA: Durante el período de implementación, el coordinador o gerente del proyecto es responsable del cliente para hacer un seguimiento de las actividades del entorno junto con el equipo de Cloud. En la comunidad Cloud tenemos documentos específicos
- Especialista en Infraestructura realiza el análisis del entorno en conjunto con TI del Cliente, produciendo la Lista de Verificación o Documento de Portabilidad (RM).
- Especialista puede, dependiendo de los resultados del análisis, proponer cambios para mejorar el entorno (preparación del documento de Estructura de Sizing).
- NOTA: Registrar la negativa del cliente si decide no seguir las recomendaciones.
IMPORTANTE: la actividad de Sizing debe estar incluida en la Propuesta Comercial para poder ser ejecutada. - TI Cliente debe evaluar la propuesta de mejora y formalizar una decisión con el Comité de Proyecto y para el gerente o coordinador de proyecto (TOTVS).
- NOTA: Registrar en el cronograma el tiempo de adecuación de la infraestructura para el control de progreso y dependencias.
____________________________________________________________________________________________________________________________________________________________________________________________________

|
ENTRADA(S): - Cloud - Contrato de servicio separado de la propuesta de implementación del proyecto, firmado por el cliente, con las definiciones del entorno, en el modelo Estándar o Prime. Las principales diferencias entre los modelos son el tiempo de SLA, disponibilidad del entorno y accesos. Para ambos casos, se elaboran una matriz RACI y un Catálogo de Servicios para cada proyecto.
- On Premise (Sizing) - Subcontratación del equipo de TIS para la evaluación y sugerencia del entorno necesario. El presupuesto estándar de 40 horas se vende obligatoriamente en los precios del proyecto para cubrir estos costos. El Documento de Portabilidad se preparará con los requisitos mínimos de infraestructura, en el caso de los productos RM, para los demás productos, se preparará una lista de verificación de infraestructura.
|

|
ACTORES: TOTVS - Gerente o coordinador del proyecto*
- Analista de infraestructura*
- Analista de Cloud*
- Ejecutivo de Soluciones de Negocios*
- Arquitecto de Soluciones*
CLIENTE - Coordinador o Comité de Proyecto*
|
SALIDA(S): - Documentos de Cloud preparados según el proyecto
- Análisis de la infraestructura del Cliente realizado con dictamen técnico validado por la documentación de TIS.
- Documentos de Cloud elaborados de acordo com o projeto
- Análise da Infraestrutura do Cliente realizado com parecer técnico validado pela documentação de TIS.
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obligatorio |
|


|
1.4.1 Preparar el cronograma y definir los hitos del proyecto Detalles de acceso
El cronograma es una forma extremadamente visual de mostrar la secuencia de actividades dentro de un proyecto, lo que le permite verificar las interdependencias de las tareas y poder visualizar la ruta crítica, para tener un control efectivo y mitigar los riesgos de retraso. NOTA: Es importante tener visibilidad del avance de otros cronogramas complementarios para la gestión. Con esto, el Project Manager es capaz de medir el desempeño del proyecto y tomar acciones correctivas o anticipar posibles problemas. Comunicar qué hacer ya quién hacerlo en el momento adecuado, mostrando la correlación entre las actividades es un factor clave de éxito. La definición de los Hitos de Entrega y la composición de los entregables para cada hito debe realizarse en conjunto con el cliente. NOTA: Es importante considerar que cada fase del proyecto puede contener tantos hitos como sean necesarios de acuerdo al contexto de cada proyecto. Un entregable como, por ejemplo, "Hacer realidad las capacidades" que pertenece a la fase "Realización" se puede definir como un hito de entrega según el contexto de su proyecto.
Descripción de actividades: Gerente o coordinador del proyecto: - Organiza las actividades y dependencias, teniendo en cuenta los límites de plazos acordados para los hitos
- Revisa el esfuerzo con el equipo asignado en el proyecto y valida el compromiso de los profesionales en relación con los plazos
- Con la planificación definida y los costos asignados, se define el margen de beneficio del proyecto y, en comparación con el margen de beneficio vendido, es posible tener una visión general del resultado financiero del proyecto.
- Define los hitos de entrega y realiza los acuerdos con el cliente, ajustando en el cronograma, cuáles serán los entregables que componen cada hito.
____________________________________________________________________________________________________________________________________________________________________________________________________
ENTRADA(S): - Validación con el cliente de la información para la planificación del proyecto
- Proyecto en la herramienta de Gestión de proyectos
|
ACTORES: TOTVS - Gerente o coordinador del proyecto*
- RMO*
CLIENTE - Coordinador o Comité de Proyecto*
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obligatorio |
|
1.4.2 Definir Equipo Detalles de acceso
Sabemos que cada proyecto es realizado por personas. Por lo tanto, seleccionar bien a su equipo y garantizar un perfil mínimamente adecuado mediante la evaluación de la función, habilidad y disponibilidad es otro factor importante en el éxito del proyecto. En caso de indisponibilidad, RMO es responsable de indicar otras alternativas para reemplazar los recursos, que también deben estar bien alineados con el gerente o coordinador de proyecto, ya que puede afectar el costo, el plazo y la calidad del proyecto.
Descripción de actividades: - Gerente o coordinador del proyecto:
- Organiza los papeles definidos durante la reunión de Entrega de testigo
- Solicita recursos de RMO, según lo planificado
- RMO confirma la disponibilidad de sus recursos o informa alternativas para que el gerente o coordinador del proyecto evalúe (préstamo de recursos de otras unidades o asignación de terceros), con el fin de cumplir con las expectativas validadas, de la siguiente manera:
- Evalúa conocimiento/experiencia necesarios
- Evalúa puesto y nivel (dependiendo del costo)
- Evalúa perfil general para atención
- Analiza lugares de atención
- Evalúa coherencia del alcance vs. demanda
Si se requiere la asignación de un tercero, RMO terceros debe estar implicado iniciando los procesos para asignación de asociados. - Gerente o coordinador de proyecto alinea con el equipo del proyecto los papeles, metas y resultados esperados (Kick Off interno).
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Gerente o coordinador del proyecto*
- RMO*
- RMO Terceros*
- Analistas/Especialistas*
CLIENTE - Coordinador o Comité de Proyecto*
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obligatorio |
|
1.4.3 Determinar la Baseline 1 Detalles de acceso
La Baseline es el acuerdo firmado entre las partes que demuestra todos los aspectos discutidos y tratados durante la preparación del proyecto y es de fundamental importancia establecer esta línea de base en el proyecto. Una vez firmada esta línea de base, se deben analizar todos los cambios futuros y se deben aprobar sus impactos para crear una nueva línea de base, con la excepción del ajuste previsto después del diseño de la solución.
Descripción de actividades: El gerente o coordinador de proyecto valida el Plan general de proyecto con el Cliente ____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Gerente o coordinador del proyecto*
- Usuarios clave*
- Ejecutivo de Soluciones de Negocios
- Arquitecto de Soluciones
CLIENTE - Coordinador o Comité de Proyecto*
- Patrocinador*
|
SALIDA(S): - Presentación de la baseline al Comité y al patrocinador del proyecto durante la reunión de apertura del proyecto (Kick Off).
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obligatorio |
|


|
1.5.1 Programar y Realizar la Reunión de Apertura Del Proyecto (Kick-Off) Detalles de acceso
Debemos tratar esta reunión de apertura como un evento inicial del proyecto, que de hecho será para muchas personas. Es un momento muy importante de alineación general con todos los participantes que pueden no haber tenido acceso a la estrategia, los cambios que pueden ocurrir, sus papeles como usuarios clave, etc. Por esta razón, se debe explorar bien el lado de los beneficios esperados, oportunidades de visibilidad para los participantes, cómo queda la organización después de la implementación del sistema, validar el compromiso de todos con el proyecto, etc.
Descripción de actividades: - Gerente o coordinador del proyecto
- Valida la planificación general del proyecto con el Cliente
- Prepara la presentación junto con el Cliente, estableciendo una línea lógica y de participación
- Valida la presentación de Bienvenida - MIT024, con el Cliente
- El cliente organiza internamente el evento con el apoyo del gerente o coordinador del proyecto
- Gerente o coordinador del proyecto conduce la reunión con los límites establecidos en conjunto con el Cliente, es decir, con los papeles de presentación bien definidos (por ejemplo, quien presenta el objetivo y los beneficios suele ser el Patrocinador).
____________________________________________________________________________________________________________________________________________________________________________________________________
ENTRADA(S): - Propuesta comercial firmada
- Cronograma
- Plan de riesgo y cambios
|
ACTORES: TOTVS - Gerente o coordinador del proyecto*
- Usuarios clave*
- Ejecutivo de Soluciones de Negocios*
- Arquitecto de Soluciones*
- Soporte TOTVS
CLIENTE - Coordinador o Comité de Proyecto*
- Patrocinador*
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obligatorio |
|


|
1.6.1 Finalización de la fase y evaluación de Quality Gate (Preparación) Detalles de acceso
Revisión de la fase y evaluación de completitud
Descripción de actividades: Gerente o coordinador del proyecto revisa la completitud de los entregables de la fase, si hay cuestiones pendientes que deben completarse, si la calidad entregada es la esperada y si hay problemas y riesgos que deben tratarse antes de pasar a la siguiente fase. ____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Gerente o coordinador del proyecto*
CLIENTE - Coordinador o Comité de Proyecto*
- Clienter*
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obligatorio |
|
|
|
|
__________________________________________________________________________________________________________________________________________________________________________________  Es el diseño efectivo de la solución a entregar, revisando los requerimientos en el análisis de procesos y eliminando brechas de alcance y/o proceso. |
ACCEDE AQUÍ A LOS ENTREGABLES Y ACTIVIDADES DE ESTA FASE

El refinamiento es en resumen el diseño efectivo de la solución a entregar, siendo revisados los requisitos en el análisis de los procesos, la eliminación de gaps del alcance y/o proceso y la definición de la configuración. En esta fase se perfeccionan las estrategias del proyecto y se definen los flujos de trabajo para las siguientes fases. Además, se espera que al final de esta fase sea elaborado el plan de Sprints para la construcción y prueba de la solución Por esta razón es que normalmente tenemos al final de este grupo una versión de Baseline actualizada (versión 2), que debe ser la versión oficial del proyecto, siendo modificada solo con la aprobación del cambio por parte del Comité del Proyecto.
|

2.1.1 Taller de Evaluación de Procesos Detalles de acceso
Es fundamental conocer los procesos del cliente de acuerdo con el alcance del proyecto para poder diseñar la solución pensando en los cambios que puedan producirse. Esta es una etapa en la que será necesaria la conducción de algunos workshops y entrevistas y es imprescindible que esto ocurra de una manera dirigida a lo contratado para no generar frustración a nuestros clientes.
SUGERENCIA 1: Enviar el material de apoyo para estudio (cuestionarios) con antelación para guiar al usuario clave y prepararlo mejor para el momento de la reunión del estudio. SUGERENCIA 2: Solicitar con antelación copias de modelos como informes, facturas y cualquier documento que pueda ayudarle a comprender los procesos.
Descripción de actividades:
Analista/Especialista: - Evalúa el alcance del proyecto para dirigir las entrevistas, alineando las expectativas durante las mismas
- Realiza workshops con usuarios clave del Cliente para comprender los procesos actuales, formularios e informes utilizados en el mismo
- Analista/Especialista debe crear los flujos de los procesos para proyectos que contemplen la elaboración de un flujo
- Es responsable de validar y recopilar las firmas para formalizar el diseño elaborado
- NOTA: Analista/Especialista debe dejar al gerente o coordinador del proyecto siempre alineado con la conducta y el estado de la validación
- SUGERENCIA 1: Las mejores prácticas indican que la validación conjunta de los procesos facilita la comprensión y la firma del Diagrama de los Procesos.
- SUGERENCIA 2: Realizar una double-check de la comprensión con los usuarios clave (confirmación de comunicación)
____________________________________________________________________________________________________________________________________________________________________________________________________
ENTRADA(S): - Propuesta comercial firmada
- Material de apoyo para estudio (cuestionarios)
|
ACTORES: TOTVS - Analista/Especialista*
- Gerente o coordinador del proyecto*
CLIENTE - Coordinador o Comité de Proyecto*
- Usuarios clave*
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obligatorio |
|
2.1.2 Diseño de Los Procesos y Configuración Detalles de acceso
Básicamente, el diseño de la solución consiste en demostrar a nuestro Cliente que entendemos el contexto de negocio definido por los usuarios clave y que somos capaces de configurar adecuadamente el sistema al uso, cumpliendo con las expectativas generales presentadas. Sin embargo, si aún surgen preguntas de esta orden (fuera del alcance), el analista/especialista debe formalizar los gaps identificados a través de Solicitud de Cambio - MIT031, proponer junto con el arquitecto y el Comité del Proyecto el mejor abordaje para los asuntos y ofrecer alternativas a los escenarios. Es muy importante tener la participación y la responsabilidad de los usuarios clave en la definición de la solución. NOTA: El papel del analista/especialista en este contexto es traer su experiencia de otros proyectos y contribuir con benchmark en los procesos, pero la responsabilidad de la definición debe ser del usuario clave (Cliente).
Descripción de actividades: Analista/especialista elabora el flujo operativo de acuerdo con las definiciones de los usuarios clave, siguiendo el alcance acordado con el Cliente e identificando los puntos de desviación para el análisis de gaps. El usuario clave valida el flujo y el descriptivo Analista/especialista describe los detalles relacionados con el flujo según sea necesario para mayor claridad: Determina reglas de negocio Describe racionales de cálculo Determina criterios de entrada Determina criterios de salida Identifica los resultados esperados Identifica las configuraciones sistémicas (Plan de Configuración (parametrización del sistema)
Analista/especialista debe validar y tener la aprobación del cliente en el Diagrama de Proceso - MIT041 con los respectivos Usuarios Clave, determinando así la solución que será construida Gerente o coordinador del proyecto debe consolidar todos los Diagramas de Proceso - MIT041 aprobados, como registro del proyecto NOTA: Este evento puede ser visto como un hito importante del proyecto.
____________________________________________________________________________________________________________________________________________________________________________________________________
ENTRADA(S): - Propuesta comercial firmada
- Diagrama de proceso - MIT041 completado
- Material de soporte para estudio (cuestionario)
|
ACTORES: TOTVS - Analista/Especialista*
- Gerente o coordinador del proyecto*
CLIENTE - Coordinador o Comité de Proyecto*
- Usuarios clave*
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obligatorio |
|
2.1.3 Analisar aderência e GAPs (GAP Analysis) Detalles de acceso
Es esencial que este análisis de gaps se realice con el Cliente para identificar las necesidades reales antes de cualquier abordaje de negociación, para asegurar un valor agregado en cualquier análisis de impacto y en los resultados en el futuro. También es importante que exista un análisis interno del panorama entre el gerente o coordinador del proyecto y el arquitecto para definir una estrategia de abordaje donde deban indicar una solución viable para la continuidad del proyecto (y generar un sentimiento de asociación con el Cliente). Al final de las negociaciones y después de la aprobación, es esencial que el gerente o coordinador del proyecto actualice los planes del proyecto colocando los impactos planteados para la aprobación de la nueva baseline versión 2.
Descripción de actividades: - Analista/especialista y usuarios clave relacionan los gaps identificados en el Diagrama de Proceso -MIT041 y lista en la hoja de trabajo Plan de Riesgo y Cambio - MIT036 para organizar el contexto general
- Analista/especialista, gerente o coordinador de proyectos y arquitecto analizan el panorama general, identifican y definen una estrategia de abordaje para hacer posible el proyecto
- NOTA: La recomendación es realizar este análisis examinando el panorama general en lugar de evaluar los gaps y los cambios individualmente, ya que normalmente hay compensación entre los nuevos ítems y los ítems cancelados, equilibrando la negociación.
- Gerente o coordinador del proyecto y arquitecto clasifican los gaps y se someten al estudio y aprobación del Comité del Proyecto
- Comité del Proyecto:
- Evalúa el panorama general para la negociación de los ítems (gaps y cambios) entre las partes
- Aprueba la versión final negociada
- Gerente o coordinador del proyecto registra el resultado y actualiza el historial del Proyecto con los cambios e impactos absorbidos.
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Analista/Especialista*
- Gerente o coordinador del proyecto*
- Arquitecto de Soluciones*
- Ejecutivo de Soluciones de Negocios
CLIENTE - Coordinador o Comité de Proyecto*
- Usuarios clave*
omitê do Projeto* |
SALIDA(S): - Análisis de gap y cambios alineado con el Cliente, con la definición del arquitecto y gerente o
coordinador del proyecto sobre el abordaje y aprobación de los cambios a través de la Solicitud de Cambio - MIT031 - Aprobación de una nueva baseline sobre los cambios impactados por los gaps y los cambios
(aprobados)
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obligatorio |
|


|
2.2.1 Ejecución del prototipo/Taller de solución con el cliente Detalles de acceso
El objetivo de esta etapa es realizar un prototipo preliminar, basado en lo que se ha planteado, que ayude a validar con el cliente los requisitos y dar una noción de lo que está adquiriendo. Este tipo de ceremonia colabora con el anticipo de desviaciones de entendimiento que suelen ser percibidas por el cliente en futuras etapas del proyecto. El prototipo debe responder a las preguntas más importantes, así que mantenga el enfoque en esto y no en tener algo 100 % funcionando. El esfuerzo de construcción y ejecución del prototipo debe ser adecuado según el contexto y el presupuesto de cada proyecto.
Descripción de actividades: ____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Analista/especialista en Implementación*
- Gerente o coordinador del proyecto*
CLIENTE - Coordinador o Comité de Proyecto*
- Usuarios clave*
|
SAÍDA(S): - Conhecimento básico do funcionamento da ferramenta e flexibilidade que pode proporcionar ao cliente.
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obligatorio |
|


|
2.3.1 Definir los ciclos y escenarios de pruebas Detalles de acceso
El Guia de pruebas - MIT045 tiene el importante papel de guiar a los usuarios responsables de las pruebas para simular todos los procesos y sus respectivos escenarios variados para garantizar que la solución construida realmente cumpla con los requisitos y expectativas generales. También es un buen momento para reafirmar el compromiso con los usuarios clave sobre su papel como responsables de la calidad de las pruebas y asegurarse de que están validando la entrega de un sistema que se utilizará en su rutina. - NOTA: Algunos clientes todavía solicitan realizar esta etapa de validación en paralelo con las tareas diarias en un período determinado. Es importante resaltar que el itinerario estructurado es una mejor opción, ya que el período de prueba paralelo a la operación puede no contener todos los escenarios deseados en la solución, aumentando el riesgo de problemas posteriores al GO LIVE.
Descripción de actividades: - Los usuarios clave (Cliente) organizan los procesos y diferentes escenarios para cubrir todas las variaciones de negocio insertadas en el contexto de la solución
- NOTA: el equipo del proyecto TOTVS debe apoyar esta actividad guiando el rellenado del itinerario de pruebas, pero es responsabilidad del Cliente prepararlo
- Analista/especialista, gerente o coordinador del proyecto organizan, sobre los escenarios propuestos, los criterios y límites establecidos ya que realizarán la prueba integrada del sistema
- NOTA: la Prueba Integrada del Sistema es el ciclo que asegura el correcto funcionamiento del sistema y suele tener un contenido más técnico, es decir, el sistema se ejecuta con todas las funcionalidades esperadas. Los valores y resultados esperados se calculan en la validación de entrega
- Gerente del proyecto (Cliente) valida con los usuarios clave el Guia de Pruebas - MIT045 y lo publica oficialmente como base de las pruebas por realizar.
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Analista/especialista*
- Gerente o coordinador del proyecto*
CLIENTE - Coordinador o Comité de Proyecto*
- Usuarios clave*
- Gestores funcionales de las áreas de negocio
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obligatorio |
|


|
2.4.1 Preparación de la capacitación Detalles de acceso
Es fundamental conocer los procesos del cliente según el alcance del proyecto para poder diseñar la solución considerando los cambios que se puedan producir. Esta es una etapa en la que será necesario realizar algunos talleres y entrevistas y es fundamental que esto se dé de forma dirigida a lo contratado para no generar frustraciones a nuestros clientes. TIP 1: Envíe el material de apoyo de la encuesta (cuestionarios) con anticipación para orientar al usuario clave y prepararlo mejor para el momento de la reunión de la encuesta. TIP 2: Solicite con anticipación copias de modelos como informes, facturas y cualquier documento que pueda ayudar a entender los procesos.
Descripción de actividades: - Los analistas/especialistas deben proporcionar la secuencia de trabajo y el contenido programático
- Los usuarios clave (Cliente) organizan el calendario, el contenido programático y los participantes de acuerdo con los procesos identificados en el Itinerario de Pruebas
- El equipo interno del Cliente organiza la infraestructura para que la capacitación pueda llevarse a cabo:
- Lugar físico
- Máquinas disponibles
- Accesos (red)
- Transporte/hospedaje
- El Comité de Proyectos aprueba el plan con infraestructura
- El Equipo del Proyecto lleva a cabo la comunicación de la capacitación, teniendo en cuenta todos los detalles mencionados anteriormente
- NOTA: es importante tener en cuenta en el plan de capacitación todas las restricciones impuestas por el tema de la infraestructura.
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Analista/especialista*
- Gerente o coordinador del proyecto*
CLIENTE - Coordinador o Comité de Proyecto*
- Usuarios clave*
|
SALIDA(S): - Procedimiento de Capacitación - MIT037 preparado y otra información sobre esta actividad.
NOTA: Es una buena práctica comenzar la definición de procedimiento de Capacitación en este momento y fase, pero esta actividad debe completarse antes de la ejecución de la capacitación, en la fase de realización.
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obligatorio |
|


|
2.5.1 Definición de la conversión de datos e interfaces Detalles de acceso
Organizar de antemano cómo serán las cargas de datos es fundamental, ya que será posible percibir necesidades que generen esfuerzo adicional de construcción, ya sea en el ámbito técnico (desarrollo de rutinas de carga), como en el ámbito de negocio (para información registrada manualmente). Otro aspecto muy importante en este momento es determinar quién es el responsable, el método, cuáles son los criterios de validación y las reglas de conversión.
Descripción de actividades: ____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Analista/especialista en Implementación*
- Gerente o coordinador del proyecto*
CLIENTE - Coordinador o Comité de Proyecto*
- Usuarios clave*
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obligatorio |
|


|
2.6.1 Backlog do Projeto e Planejamento das Sprints e Releases Detalles de acceso
Conducir una Sprint requiere mucha energía y concentración. Antes de comenzar una Sprint, necesitará tener el equipo y los desafíos adecuados. También necesitará tiempo y espacio para conducir su Sprint. Es decir, prepararse para aplicar este método es fundamental para el éxito final. El tiempo establecido para cada Sprint debe ser adecuado para el contexto de cada proyecto. Idealmente de 2 a 4 semanas.
Descripción de actividades: - Definir el backlog del producto, con todos los requisitos de productos que se entregarán;
- Definir los entregables de cada Sprint según el equipo disponible y el período definido para el sprint;
- La planificación de sprint puede involucrar al equipo del proyecto, si es necesario, para definir lo que es más importante para entregar primero teniendo en cuenta el valor agregado
para el negocio. - En el proceso de descripción detallada del backlog se deben tener en cuenta las características del producto y el alcance del proyecto.
3. Tener en cuenta que las entregas parciales se pueden agrupar por un conjunto de Sprints, denominado Release, para que pueda tener una validación parcial o entregar una funcionalidad o producto en producción. ____________________________________________________________________________________________________________________________________________________________________________________________________
ENTRADA(S): - Diagrama de proceso - MIT041
- Definición de los ciclos y escenarios de prueba
- Preparación de la capacitación
- Definición de conversión de datos e interfaces
|
ACTORES: TOTVS - Analista/especialista en Implementación*
- Gerente o coordinador del proyecto*
CLIENTE - Coordinador o Comité de Proyecto*
|
SALIDA(S): - Plan de Sprints y Releases definido
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obligatorio |
|


|
2.7.1 Finalización de la fase y evaluación de Quality Gate (Refinamiento) Detalles de acceso
Revisar todos los aspectos de la planificación general del Proyecto es esencial para reevaluar si realmente todos los puntos se han alineado, verificar si aún hay alguno pendiente, establecer un nuevo compromiso con el Comité, formalizar una nueva baseline y comunicar a las partes interesadas de todas las esferas. - NOTA: A partir de este punto, cualquier cambio solicitado tendrá un impacto mayor que el que había ocurrido hasta este momento. Por lo tanto, se redobla el cuidado del análisis de impactos para cualquier nueva solicitud.
Descripción de actividades: - Gerente o coordinador del proyecto:
- Verifica la completitud de los entregables de la fase
- Organiza la nueva información proveniente de la fase de Refinamiento.
- En posesión de la información organizada, revisa los impactos analizados, las aprobaciones realizadas, la comunicación efectivamente realizada y actualiza la baseline del Proyecto
- Comité del Proyecto aprueba la planificación general
- Publicación de la Planificación Oficial
____________________________________________________________________________________________________________________________________________________________________________________________________
ENTRADA(S): - Diagrama de proceso - MIT041
- Definición de los ciclos y escenarios de prueba
- Preparación de la capacitación
- Definición de conversión de datos e interfaces
|
ACTORES: TOTVS - Gerente o coordinador del proyecto*
CLIENTE - Coordinador o Comité de Proyecto*
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obligatorio |
|
|
|
|
_________________________________________________________________________________________________________________________________________________________________________________________________________________ 
En realidad, se basa en el diseño detallado y aprobado en la fase anterior. La construcción y las pruebas se basan en Sprints basados en la acumulación. |
ACCEDE AQUÍ A LOS ENTREGABLES Y ACTIVIDADES DE ESTA FASE

Es la construcción de facto en base al diseño detallado aprobado en la fase anterior. Esta construcción implica la disponibilidad de los entornos de trabajo, ejecución de las sprints de configuración del sistema, desarrollo de las personalizaciones, carga de los datos y validación de la entrega, a través de ciclos técnicos y empresariales.
Es importante definir qué pruebas críticas se deben llevar a cabo en la transición y revisar el plan de transición del sistema para el entorno productivo.
La construcción y las pruebas se basan en sprints basados en el backlog. La ejecución del plan de transición y de las pruebas integradas ocurren en esta etapa.
Para resumir, este grupo de tareas tiene como objetivo controlar la construcción del sistema dentro del diseño aprobado, garantizar la atención de los requisitos y un buen plan de transición, administrando la entrega dentro de la planificación aprobada con el Cliente. |

3.1.1 Configurar el producto Detalles de acceso
Es en esta etapa que la configuración del producto ocurre como combinado y aprobado por el cliente, respetando lo que se definió en la fase de refinamiento y priorizado para cada sprint. Si surgen problemas imprevistos o tratados en la fase anterior, estos serán discutidos por el equipo en las reuniones de retrospectivas de la Sprint y dependiendo del problema, obligatoriamente se debe registrar una Solicitud de Cambio para evaluar el impacto y tener una aprobación formal de esta, que puede cambiar el plazo, costo o calidad definida durante el Refinamiento de la Solución.
Las entregas ocurren a través de Sprints (iteraciones) con tiempo definido (idealmente de 2 a 4 semanas) y cada Sprint debe entregar un incremento de producto que puede o no validarse con el cliente, de acuerdo con la planificación de las releases (grupos de Sprints). Se espera que las siguientes ceremonias se lleven a cabo cada ciclo de Sprint: - Planificación de la Sprint: Ceremonia para definición del objetivo de la sprint, alcance del trabajo, cómo y qué se entregará.
- Reunión de la iteración (“Daily”): es la reunión de seguimiento de la sprint, donde se verifica la marcha de la sprint. De corta duración (no más de 30 min), en la que cada miembro reflexiona sobre:
- ¿Qué ha hecho de ayer a hoy?, ¿Qué haré de hoy hasta mañana?, ¿hay algún impedimento?
La periodicidad de la reunión se puede definir según el contexto de cada proyecto y se puede realizar con todo el equipo del proyecto con o sin la participación del coordinador o gerente del proyecto. - Revisión de la sprint: es la ceremonia de presentación de lo que está listo para la validación y la recopilación de feedback.
- Retrospectiva de la sprint: es la última actividad de la sprint, en la que el equipo evalúa su propio desempeño durante el proceso de trabajo y planifica las acciones de mejora que se implementarán en la próxima sprint.
Cuestiones tales como: ¿Qué funcionó? ¿Qué puede mejorar? actividades pendientes y de aprendizaje (lecciones aprendidas) deben abordarse y registrarse en la lista de Retrospectiva y Actividades Pendientes.
NOTA: Se recomienda organizar varias Solicitudes de Cambio - MIT031 juntas para tener una mejor percepción de los impactos, en lugar de evaluarlos individualmente. Para ello, es posible estipular momentos/fechas programadas para solicitar, evaluar y aprobar la demanda.
Descripción de actividades: Durante la Sprint el analista o consultor de implementación: Configura el sistema en función del diagrama de procesos aprobado por el Cliente y el backlog priorizado para la Sprint. Informa el avance, riesgos o issues encontrados, eventuales retrasos y desviaciones que se produjeron a través de reuniones de la iteración, o reuniones diarias.
El gerente o coordinador del proyecto sigue la evolución y trabaja en la comunicación y alineación con el Comité del Proyecto o Cliente. Al final de cada Sprint se espera que tenga lugar la reunión retrospectiva, con todo el equipo que participó en el Sprint. Después de la finalización de cada Sprint, comienza un nuevo ciclo de iteración hasta que se entrega todo el backlog del producto.
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Analista/Consultor de Implantación*
- Gerente o coordinador del proyecto*
CLIENTE - Coordinador o Comité de Proyecto*
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obligatorio |
|
3.1.2 Encomienda/Desarrollo de personalizaciones Detalles de acceso
Con las Personalizaciones debe tenerse un cuidado especial, pues pueden afectar tanto el plan del proyecto, como el funcionamiento adecuado del sistema, considerando el diseño de la solución. Para mitigar estos riesgos, los usuarios clave involucrados deben estar accesibles para utilizar rutinas estándar lo máximo posible, así como los analistas/especialistas deben estar aptos para entender las necesidades y presentar alternativas coherentes con el negocio y operación del cliente. Al identificar una necesidad de personalización, el Analista / Especialista debe elaborar la Especificación de la personalización informando detalles importantes para aumentar la calidad de entrega El desarrollo de las personalizaciones debe seguir lo acordado y aprobado por el Cliente, es decir, seguir lo que se definió en el Diagrama de Proceso MIT041 y/o en la Especificación de Personalización MIT044.
Descripción de actividades: - El Analista / Especialista y Usuarios clave (Cliente) evalúan los detalles de las necesidades de personalizaciones, respetando el alcance del proyecto aprobado en el Diseño de la solución (TO BE) y resultados del Análisis de GAPS
- El Analista / Especialista describe los detalles funcionales en la Especificación de la personalización para encaminamiento / solicitud del desarrollo al equipo de la Fábrica de software o del propio equipo de desarrolladores del proyecto
- Líder Técnico organiza entregas con el equipo de desarrollo (Backlog/Sprints/Deploy)
- Equipo de la Fábrica realiza el desarrollo de acuerdo a lo definido en el Diagrama de Proceso MIT041 y en el Proyecto Lógico (PL)
- Líder técnico de la Fábrica de Software:
- Informa avance, riesgos/issues encontrados, posibles retrasos y desviaciones ocurridas
- Envía las evidencias de la prueba realizada, demostrando el resultado positivo.
- Gerente o coordinador de proyecto sigue la evolución y trabaja en la comunicación y alineación con el Comité del Proyecto/Cliente.
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Desarrollador (Fábrica de Software)*
- Líder técnico (Fábrica de Software)*
- Analista/Consultor de Implantación*
- Gerente o coordinador del proyecto*
CLIENTE - Coordinador o Comité de Proyecto*
|
SALIDA(S): - Personalizaciones desarrolladas.
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obligatorio |
|


|
3.2.1 Capacitar a los usuarios clave Detalles de acceso
Esta capacitación debe conducir a los usuarios clave al uso eficaz del sistema de acuerdo con el Diseño de la solución aprobado. Cabe recordar el compromiso alineado en la preparación/Reunión de Apertura del proyecto, que los usuarios clave son responsables de replicar el conocimiento y también de eventual soporte.
Descripción de actividades: Analistas/consultores y usuarios clave se reúnen de acuerdo con la planificación de la Capacitación realizada en el Refinamiento Analistas o consultores imparten las capacitaciones de acuerdo con el Diseño de la Solución aprobado y sus respectivas configuraciones. Usuarios clave: Deben absorber el conocimiento y realizar la profundización del sistema en la práctica para garantizar la eficiencia en el uso Formalizan la recepción de conocimiento y uso del sistema con los Consultores que impartieron la capacitación
El gerente o coordinador del proyecto organiza las formalizaciones y valida esta etapa con el Comité del Proyecto El Comité del Proyecto aprueba la realización de la Capacitación a través del documento de comprobación de la etapa.
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Analista/Consultor de Implantación*
- Gerente o coordinador del proyecto*
CLIENTE - Usuarios clave*
- Coordinador o Comité de Proyecto*
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obligatorio |
|


|
3.3.1 Preparar y ejecutar carga de datos Detalles de acceso
En este momento, se realizan las cargas identificadas y planificadas, siguiendo el método estipulado, por los respectivos responsables de la misma. Es igualmente importante que se tengan criterios de validación para garantizar que la carga se ha realizado con éxito, de modo que las pruebas y validaciones siguientes puedan generar los resultados esperados. - NOTA: En los casos de carga manual, es decir, datos introducidos manualmente por los usuarios clave,
se debe combinar muy bien el esfuerzo y los plazos para que el cronograma esté bien alineado.
Descripción de actividades: - Los analista(s)/consultor(es) de implementación ejecutan las cargas de datos con rutinas/herramientas definidas, según lo planificado y alineado durante la fase de Refinamiento.
- Usuarios clave:
- Ejecutan la carga de datos manualmente según lo planificado y alineado durante la fase de Refinamiento.
- Validan los datos migrados por un método u otro utilizando las herramientas combinadas.
- Usuarios y analista(s)/Consultor(es) informan el avance, riesgos/issues encontrados, eventuales retrasos y desviaciones ocurridas.
- Gerente o coordinador de proyecto sigue la evolución y trabaja en la comunicación y alineación con el Comité del Proyecto/Cliente.
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Analista/Consultor de Implantación*
- Gerente o coordinador del proyecto*
CLIENTE - Usuarios clave*
- TI, si lo hay*
- Coordinador o Comité de Proyecto*
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obligatorio |
|


|
3.4.1 Realizar Pruebas unitarias Detalles de acceso
El objetivo principal de esta tarea es garantizar el funcionamiento del sistema para que los usuarios clave puedan validar eficazmente la solución. Por lo tanto, la meta de estas pruebas debe centrarse más en la ejecución de rutinas y tener menos atención en los resultados esperados, como el cálculo correcto de los impuestos. - NOTA: Esta división de prioridad ocurre porque gran parte de los resultados esperados están
directamente relacionados con los registros y el propio negocio. Por esta razón, generalmente se planifican ciclos con diferentes aspectos.
Descripción de actividades: - Analista(s)/consultor(es) de implementación, generalmente en conjunto con el equipo de TI, realizan las pruebas elaboradas en el Itinerario de Pruebas centradas en el funcionamiento del sistema, con el fin de garantizar su disponibilidad a los usuarios clave en la validación efectiva.
- Analista(s)/consultor(es) informan el avance, riesgos/issues encontrados, eventuales retrasos y desviaciones ocurridas.
- Gerente o coordinador de proyecto sigue la evolución y trabaja en la comunicación y alineación con el Comité del Proyecto/Cliente.
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Analista/Consultor de Implantación*
- Gerente o coordinador del proyecto*
CLIENTE - Coordinador o Comité de Proyecto*
|
SALIDA(S): - Sistema probado en toda su funcionalidad, sin tener en cuenta los resultados de negocio (que dependen de aspectos de registros y reglas de negocio) e Guia de Pruebas - MIT045 actualizado.
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obligatorio |
|
3.4.2 Realizar Pruebas Integradas del Sistemas - Equipo TOTVS Detalles de acceso
El objetivo principal de esta tarea es garantizar, además del funcionamiento del sistema, que se validen los resultados esperados, así como los procesos y sus diferentes escenarios. En algunos casos, se incluye después de las pruebas integradas, la prueba de carga del sistema.
Descripción de actividades: - Analista(s)/consultor(es) se organizan de acuerdo con lo planificado para realizar la validación general de la solución.
- NOTA 1: en esta etapa, con el sistema en pleno funcionamiento, se deben validar los procesos, sus diferentes escenarios y determinar los resultados esperados.
- Analista(s)/Consultor(es) informan el avance, riesgos/issues encontrados, eventuales retrasos y desviaciones ocurridas.
- Gerente o coordinador de proyecto sigue la evolución y trabaja en la comunicación y alineación con el Comité del Proyecto/Cliente.
- NOTA 2: el gerente o coordinador del proyecto puede identificar la necesidad de realizar una prueba de carga en el sistema, que debe realizarse en esta etapa, utilizando un documento Término de Validación - MIT010 con el resultado de las pruebas.
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Analista/Consultor de Implantación*
- Gerente o coordinador del proyecto*
- Soporte TOTVS
CLIENTE - Coordinador o Comité de Proyecto*
|
SALIDA(S): - Solución probada en todas sus funcionalidades, procesos y escenarios, considerando incluso los resultados del negocio (que dependen de aspectos de registros y reglas de negocio) eGuia de Pruebas - MIT045, actualizado.
- Si procede, el Término de Validación - MIT010 con el resultado de las pruebas de carga.
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obligatorio |
|
3.4.3 Realizar Pruebas Integradas del Sistemas - Equipo cliente Detalles de acceso
El objetivo principal de esta tarea es garantizar, además del funcionamiento del sistema, que los resultados esperados se validen, así como los procesos y sus diferentes escenarios.
Descripción de actividades: - Analista(s)/consultor(es) y usuarios clave se organizan de acuerdo con lo planificado para realizar la validación general de la solución.
- NOTA: en esta etapa, con el sistema en pleno funcionamiento, se deben validar los procesos, sus diferentes escenarios y determinar los resultados esperados.
- Analista(s)/Consultor(es) informan el avance, riesgos/issues encontrados, eventuales retrasos y desviaciones ocurridas.
- Gerente o coordinador de proyecto sigue la evolución y trabaja en la comunicación y alineación con el Comité del Proyecto/Cliente.
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Analista/Consultor de Implantación*
- Gerente o coordinador del proyecto*
CLIENTE - Usuarios clave*
- Coordinador o Comité de Proyecto*
|
SALIDA(S): - Solución probada en todas sus funcionalidades, procesos y escenarios, considerando incluso los resultados de negocio (que dependen de aspectos de registros y reglas de negocio), Guia de prueba - MIT045 y Término de Validación - MIT010 (Término de Homologación) firmado.
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obligatorio |
|


|
3.5.1 Definición de la Prueba de Transición (Mejor Práctica) Detalles de acceso
Es fundamental restringir el lanzamiento oficial del sistema a los usuarios clave, para que puedan realizar actividades reales en el sistema ya en el entorno de producción, garantizando el funcionamiento esencial del negocio, considerando todos los procesos críticos.
Descripción de actividades: - Usuarios clave definen las operaciones críticas como criterios de GO LIVE, justo después de la ejecución del Cutover
- Gerente o coordinador del proyecto:
- Hace el seguimiento de las definiciones y evalúa si están de acuerdo con los criterios de calidad establecidos
- Al final, registra la decisión en el Guia de Pruebas - MIT045.
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Analista/Consultor de Implantación*
- Gerente o coordinador del proyecto*
CLIENTE - Usuarios clave*
- Coordinador o Comité de Proyecto*
|
____________________________________________________________________________________________________________________________________________________________________________________________________
|
|
3.5.2 Definición/Revisión del Plan de Transición Detalles de acceso
La definición/revisión del plan de transición debe realizarse inmediatamente después de obtener los resultados de las Pruebas Integradas y Validación de la Solución, donde se dispone de más detalles sobre las necesidades de suspensión del sistema, sobre los cambios de proceso en el negocio, sobre el impacto en otras áreas, etc. Es importante que cualquier nuevo problema que surja se trate en este momento, evitando así posponer un problema que pueda traer impactos negativos a todo el proyecto.
Descripción de actividades: - Analista/especialista y usuarios clave (Cliente) reevalúan los detalles de los impactos en la transición del sistema a la producción después de los resultados, considerando aspectos técnicos y funcionales:
- Técnicos
o Acciones de entorno (infraestructura) o Acciones de configuración o Acciones de transporte de datos o Acciones ecualización de personalizaciones o Acciones de actualización de la aplicación (software), que pueden transcurrir a lo largo del proyecto o Preparación de actividades Cloud (cuando hay servicios de host). - Funcionales:
o Alineación con áreas que pueden sufrir impacto con el período de suspensión (ejecución de cutover) o Alineación con los Clientes sobre la misma pregunta o Alineación con proveedores y asociados en la misma pregunta o Capacitación y preparación de los cambios operativos (procesos TO BE) o Plan de contingencia de negocio
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Analista/Consultor de Implantación*
- Gerente o coordinador del proyecto*
- Cloud TOTVS (cuando hay servicio host)*
CLIENTE - Usuarios clave*
- Coordinador o Comité de Proyecto*
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obligatorio |
|
3.5.3 Aprovar y divulgar la transición Detalles de acceso
a aprobación del Comité (decisión de GO) debe ir seguida de una divulgación oficial de la liberación de la ejecución de la Transición a todos los interesados para que: - Todas las áreas involucradas, Clientes, Proveedores y Asociados puedan programar adecuadamente y/o combinar planes de contingencia
- El proyecto gane fuerza política y estratégica en la Organización
- El proyecto tenga un compromiso final, porque en este momento es fundamental que todos pongan la adecuada prioridad de su tiempo a favor de la calidad de la transición.
Adicionalmente, una acción de comunicación interna de TOTVS, clara y estructurada, fortalece la cooperación entre las áreas y asegura el soporte necesario para el éxito del cliente después del Go Live. Descripción de actividades: - Comité de Proyecto aprueba la revisión del Plan de giro y Retroceso - MIT054 y lo divulga oficialmente junto con la estrategia de gestión del cambio.
- El CP envía un correo electrónico de Comunicación de Go Live para solicitar el apoyo de las áreas internas en la alineación y en la preparación para la entrada en producción de un cliente.
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Analista/Consultor de Implantación*
- Gerente o coordinador del proyecto*
- Soporte TOTVS
CLIENTE - Usuarios clave*
- Coordinador o Comité de Proyecto*
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obligatorio |
|


|
3.6.1 Finalización de la fase y evaluación de Quality Gate (Realización) Detalles de acceso
Revisión del gate y conclusión de las entregas de fase
Descripción de actividades: - Gerente o coordinador del proyecto revisan los entregables de la fase.
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Analista/Consultor de Implantación*
- Gerente o coordinador del proyecto*
- Soporte TOTVS
CLIENTE - Cliente*
- Coordinador o Comité de Proyecto*
|
SALIDA(S): - Revisión del Gate y entregables de la fase completados
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obligatorio |
|
|
|
|
_________________________________________________________________________________________________________________________________________________________________________________________________________________ 
Es la ejecución de las actividades de transición para la entrada en producción y el período de seguimiento u Operación Asistida justo después de la decisión de GO LIVE! |
ACCEDE AQUÍ A LOS ENTREGABLES Y ACTIVIDADES DE ESTA FASE

Es la ejecución efectiva de las actividades para la entrada en producción del sistema, incluyendo la revisión del entorno, la realización de la transición y el seguimiento de la operación asistida del sistema poco después de la divulgación oficial del GO LIVE. En esta etapa también, después de que el sistema se haya validado efectivamente, se debe realizar la capacitación de los usuarios finales.
Este grupo de tareas tiene como objetivo controlar las acciones de finalización del proyecto, garantizando la calidad acordada y un período de transición asistida para formalizar la conclusión de los servicios contratados. |

4.1.1 Preparación del Entorno de Producción Detalles de acceso
Esta etapa consiste en preparar o revisar el entorno que se utilizará para la operación real del sistema en la Organización. Por lo tanto, es imprescindible que esté dentro de las especificaciones técnicas definidas a lo largo del proyecto. La lista de verificación de instalación tiene como objetivo guiar los parámetros técnicos en detalle, mientras que el Plan de giro y Retroceso - MIT054 tiene como objetivo traer insumos extras para que el analista de infraestructura pueda tener una visión más amplia del entorno y las expectativas.
- IMPORTANTE: el equipo de TI debe participar eficazmente en las acciones, siendo el único personal con acceso al entorno de producción, siendo así responsable directo.
Descripción de actividades: - Especialista en Infraestructura prepara el entorno de producción siguiendo las especificaciones técnicas definidas
- TI (Cliente) debe publicar el final de la operación y los resultados de esta
- NOTA: todas las actividades definidas en el Plan de giro y Retroceso - MIT054 para el entorno deben ejecutarse en esta etapa.
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Gerente o coordinador del proyecto*
- Analista de infraestructura*
- Analista de Cloud*
CLIENTE - Coordinador o Comité de Proyecto*
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obligatorio |
|
4.1.2 Capacitar a los usuarios finales (mejores prácticas) Detalles de acceso
Esta capacitación debe conducir a los usuarios finales al uso eficaz del sistema, respetando todas las definiciones establecidas en el Refinamiento de la solución, en procedimiento de capacitación y en la entrega efectiva realizada. - NOTA: Esta tarea es responsabilidad exclusiva del Cliente, excepto que haya comprado este tipo de servicio a TOTVS dentro del alcance del Proyecto. Aunque lo haya adquirido, es importante traer a los usuarios clave como participantes para que puedan asumir el papel de replicadores y de referencia en el proceso de negocio.
Descripción de actividades: - Los usuarios clave (replicadores) se reúnen según la organización interna (Cliente) y proporcionan capacitación de acuerdo con el Refinamiento de la solución y procedimiento de capacitación revisado
- Los usuarios finales deben absorber el conocimiento y realizar la profundización del sistema en la práctica para garantizar la eficiencia en el uso
- Usuarios clave:
o Formalizar la capacitación con los usuarios finales o Organizan las capacitaciones y realizan la validación de esta etapa con el Comité del Proyecto.
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Analista/Consultor de Implantación
- Gerente o coordinador del proyecto*
CLIENTE - Usuarios clave (Replicadores)
- Usuarios finales (áreas del Cliente)
- Coordinador o Comité de Proyecto*
|
SALIDA(S): - Capacitación realizada y validada.
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obligatorio |
|
4.1.3 Realizar alineación con soporte TOTVS (Mejores prácticas) Detalles de acceso
Sabemos que después del proyecto, para continuar una buena experiencia del cliente, es fundamental alinear la demanda con el equipo de soporte para que este pueda prepararse para atender bien al cliente desde este punto hacia adelante en su jornada. Este punto es para describir el alcance de la demanda, tendencias de soporte y fecha efectiva del GO LIVE.
Descripción de actividades: - Project Manager o Coordinador completa el documento Transición al soporte- MA081, realiza una reunión de alineación con el equipo de Soporte de TOTVS de las funcionalidades que serán utilizadas por el cliente.
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Gerente o coordinador del proyecto*
- Soporte TOTVS*
|
____________________________________________________________________________________________________________________________________________________________________________________________________
|
|
4.1.4 Definir y Formalizar el Contrato de Estrategia y Seguimiento Detalles de acceso
Desde el momento en que los usuarios clave reciben la capacitación en profundidad y se dan cuenta de la demanda de soporte requerida, debe decidirse en este momento cuánto pueden absorber del soporte y cuánto todavía necesitarán el soporte del equipo de consultores, teniendo en cuenta la demanda. La Propuesta complementaria debe reflejar el escenario aprobado por el Comité, ya que se consideraron los aspectos generales y se revisaron después de la validación de la solución. - NOTA: Se debe tener mucho cuidado en esta definición, teniendo en cuenta las experiencias por delante realizada vs. autonomía del Cliente para proponer un escenario equilibrado y eficiente.
Descripción de actividades: - Analistas/consultores y usuarios clave se reúnen con el gerente o coordinador del proyecto y representante del Comité (Cliente) para reevaluar las necesidades de seguimiento después del GO LIVE, considerando los aspectos del soporte vs. demanda en base a los resultados de la capacitación realizada
- Gerente o coordinador del proyecto:
- Planifica el seguimiento de acuerdo con la demanda revisada para determinar los impactos de costo vs. calidad previstos en la fase de preventa o Registra la decisión a través de Acta de Reunión
- El Comité del Proyecto aprueba una nueva planificación y una eventual diferencia de costos, en función del escenario presentado por el equipo del proyecto (analistas/consultores y usuarios clave)
- Ejecutivo de Soluciones de Negocios elabora una Propuesta Comercial complementaria para suplir los gaps de seguimiento identificados y aprobadas por el Comité (si es necesario)
- El Cliente aprueba la Propuesta Complementaria.
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Analista/Consultor de Implantación*
- Gerente o coordinador del proyecto*
CLIENTE - Usuarios clave (Replicadores)*
- Usuarios finales (áreas del Cliente)*
- Coordinador o Comité de Proyecto*
|
SALIDA(S): - Definición de los responsables del soporte posterior a GO LIVE, registrada en el Acta de Reunión - MIT005 y aprobada por el Comité
- Propuesta Comercial complementaria aprobada por el Cliente (si es necesario).
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obligatorio |
|
4.1.5 Ejecutar el giro (transición) Detalles de acceso
La ejecución de la transición debe realizarse con mucho enfoque y atención a los resultados esperados para garantizar la calidad del entorno de producción. En caso de imprevistos, se debe tener un plan de contingencia y/o personas que pueden decidir alternativas rápidamente, ya que por lo general trabajan en una ventana restringida. Una vez completado, debe asegurarse de los resultados y liberar el sistema hasta la última etapa antes de la publicación oficial, que es la ejecución de operaciones críticas en producción (Prueba de Transición).
Descripción de actividades: - Analistas/especialistas y usuarios clave (Cliente) ejecutan las tareas planificadas en la transición del sistema para Producción, tal como se define en el Plan de giro y Retroceso - MIT054, considerando aspectos técnicos y funcionales:
- Técnicos
- Acciones de entorno (infraestructura)
- Acciones de configuración
- Acciones de transporte de datos
- Acciones ecualización de personalizaciones
- Acciones de actualización de la aplicación (software), que puede transcurrir a lo largo del proyecto
- Funcionales:
- Alineación con las áreas que pueden verse afectadas por el período de suspensión
- Alineación con los Clientes sobre la misma pregunta
- Alineación con proveedores y asociados en la misma pregunta
- Capacitación y preparación de los cambios operativos (procesos TO BE)
- Plan de contingencia de negocio
- El Comité del Proyecto anuncia el fin y el resultado de la ejecución, liberando la Prueba de Transición.
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Analista/Consultor de Implantación*
- Analista de infraestructura*
- Gerente o coordinador del proyecto*
CLIENTE - Usuarios clave (Replicadores)*
- Coordinador o Comité de Proyecto*
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obligatorio |
|
4.1.6 Ejecutar pruebas de Transición Detalles de acceso
Es fundamental restringir el lanzamiento oficial del sistema a los usuarios clave, para que puedan realizar actividades reales en el sistema ya en el entorno de producción, garantizando el funcionamiento esencial del negocio. Una vez validadas las operaciones críticas, se confirma el GO LIVE para todos los demás participantes de la Organización. - NOTA: El tiempo dedicado debe haber sido planificado con antelación, así como los límites, si la ejecución no sale exactamente como se esperaba.
Descripción de actividades: - Los usuarios clave ejecutan las operaciones críticas definidas como criterio de GO LIVE, justo después de la ejecución de la Transición
- Analista/especialista supervisa los resultados y evalúa si están de acuerdo con los criterios de calidad establecidos
- Al final, el gerente o coordinador del proyecto registra la decisión a través del Acta de Reunión
- El Comité de Proyectos publica oficialmente el GO LIVE.
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Analista/Especialista*
- Gerente o coordinador del proyecto*
CLIENTE - Usuarios clave (Replicadores)*
- Coordinador o Comité de Proyecto*
|
SALIDA(S): - Resultado de la Prueba de Transición en Producción
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obligatorio |
|
4.1.7 Aprobar y divulgar el GO/NO GO Oficial Detalles de acceso
El Comité debe divulgar oficialmente la decisión del GO/NO-GO a todas las partes interesadas para que: - Todas las áreas involucradas pueden comenzar los trabajo normalmente
- El sistema se libera para actuación con los clientes, proveedores y asociados
- Tendremos un evento formal para reconocer la entrega del Proyecto.
Descripción de actividades: El Comité del Proyecto divulga oficialmente la decisión de GO/NO-GO, basado en el resultado de la Prueba de Transición (puede ser positivo o negativo). ____________________________________________________________________________________________________________________________________________________________________________________________________
ENTRADA(S): - Ciclos de pruebas realizados con éxito.
|
ACTORES: TOTVS - Gerente o coordinador del proyecto*
CLIENTE - Usuarios clave (Replicadores)*
- Coordinador o Comité de Proyecto*
|
SALIDA(S): - Término de Validación - MIT010 (Término de autorización para GO Live) firmado, con la decisión de GO/NO-GO divulgada oficialmente en la Organización y entre todas las partes interesadas del Proyecto.
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obligatorio |
|

|
4.2.1 Monitorizar la operación asistida Detalles de acceso
Después de que el Comité del Proyecto divulgue oficialmente la decisión de GO/NO-GO, empieza la Operación Asistida de acuerdo con la estrategia y propuestas complementarias aprobadas. Este período es muy crítico y debe conducirse a llevar al Cliente a un nivel de autonomía suficiente para ejecutar su operación de forma segura y con confianza. - NOTA: Es común que surjan nuevas oportunidades en este período, siendo nuevos negocios y/o continuidad de la asistencia recurrente. Es importante que el gerente o coordinador del proyecto esté atento a alinearse con el Ejecutivo de Soluciones de Negocio en el momento de la finalización.
Descripción de actividades: - Analistas/especialistas contratados (según la estrategia y contratos aprobados) comienzan el soporte a la operación del sistema
- El gerente o coordinador del proyecto evalúa periódicamente los resultados y prepara gradualmente la retirada del equipo de soporte
- Coordinador (Cliente) junto con los usuarios clave se preparan para mantener la operación sin el soporte local del equipo del proyecto, gradualmente y de acuerdo con la estrategia aprobada
- Gerente o coordinador del proyecto finaliza formalmente la operación asistida al final del período combinado.
____________________________________________________________________________________________________________________________________________________________________________________________________
ENTRADA(S): - Usuarios finales operando el sistema
|
ACTORES: TOTVS - Analista/Especialista*
- Gerente o coordinador del proyecto*
CLIENTE - Coordinador o Comité de Proyecto*
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obligatorio |
|
4.2.2 Encaminamiento al Soporte Estándar Detalles de acceso
Sabemos que después del proyecto, para continuar una buena experiencia del Cliente, es fundamental alinear la demanda con el equipo de soporte para que pueda prepararse para servir bien al Cliente a partir de este momento en su Recorrido. El objetivo es aclarar y orientar al Cliente al tipo de servicio que mejor pueda aportar valor a su operación y a su experiencia con TOTVS.
Descripción de actividades: Gerente o coordinador de proyecto repasa información sobre el funcionamiento del soporte y las opciones de atención al cliente. ____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Gerente o coordinador del proyecto*
CLIENTE |
SALIDA(S): - Información del soporte repasada al cliente.
Centro de Relación TOTVS: suporte.totvs.com
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obligatorio |
|

|
4.3.1 Realizar retrospectiva del proyecto (Alineación con Relación) Detalles de acceso
Este momento de encaminamiento al equipo de Relación debe utilizarse para: - Dejar que el Cliente tenga conocimiento de la estructura de TOTVS
- Estrechar la relación
- Procurar desarrollar las oportunidades identificadas a lo largo del Proyecto
- Buscar el feedback general.
Descripción de actividades: - El gerente o coordinador del proyecto repasa el historial del proyecto con el Ejecutivo de Soluciones de Negocio y las oportunidades identificadas a lo largo del Proyecto
- El gerente o coordinador del proyecto y el Ejecutivo de Negocio alinean con el Cliente las nuevas oportunidades y refuerzan el vínculo de asociación
- El gerente o coordinador del proyecto repasa el historial del proyecto con el Ejecutivo de Soluciones de Negocio y las oportunidades identificadas a lo largo del Proyecto
- El gerente o coordinador del proyecto y el Ejecutivo de Negocio alinean con el Cliente las nuevas oportunidades y refuerzan el vínculo de asociación
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Gerente o coordinador del proyecto*
- Ejecutivo de Soluciones de Negocio*
CLIENTE |
SALIDA(S): - Cliente consciente del nuevo momento, con la asociación bien encaminada y nuevas oportunidades lanzadas para desarrollar la asociación.
|
____________________________________________________________________________________________________________________________________________________________________________________________________
|
* Obligatorio
|
4.3.2 Registrar las lecciones aprendidas del proyecto Detalles de acceso
El tema de lecciones aprendidas debe estar bien estructurado para tener realmente una base de conocimientos que pueda ser reutilizada y compartida con los empleados que buscan las experiencias adquiridas.
Descripción de actividades: El Gerente o Coordinador del Proyecto organiza los registros recopilados a lo largo del proyecto pararegistrarlos de manera estructurada. ____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Gerente o coordinador del proyecto*
- Arquitecto de soluciones*
- Ejecutivo de Soluciones de Negocio*
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obligatorio |
|
4.3.3 Cerrar el proyecto Detalles de acceso
La formalización de la conclusión es un evento indispensable para el reconocimiento del fin del proyecto y también sirve para liberar recursos para otros proyectos, así como para reconocer los Ingresos vinculados a la conclusión de hecho. Es importante destacar que la construcción de este cierre empieza a partir de la preparación del proyecto, definiendo los criterios de aceptación a lo largo del proyecto. La buena conducción con transparencia y evidencia de los acuerdos y entregas realizados y reconocidos, hará que este momento sea muy fluido con el Cliente, estableciendo una buena experiencia en su Recorrido.
Descripción de actividades: - El gerente o coordinador del proyecto organiza las pruebas del avance y la finalización del Proyecto y presenta al Comité para formalizar el cierre del proyecto, incluyendo la validación de hitos pendientes o cuotas de facturación pendientes
- El Comité del Proyecto y el Patrocinador aprueban el Certificado de Finalización de Servicios - MIT062 (Término de Cierre)
- El gerente o coordinador del proyecto organiza las acciones para el cierre del proyecto internamente y lo envía a PMO, después de que el cliente acepte el Certificado de Finalización de Servicios - MIT062 (Término de Cierre)
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Gerente o coordinador del proyecto*
- Soporte TOTVS
CLIENTE |
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obligatorio |
|
|
|
|
_________________________________________________________________________________________________________________________________________________________________________________________________________________
FUNCIONES Y RESPONSABILIDADES La Matriz RACI a continuación guía la asignación de responsabilidades al equipo del proyecto TOTVS, de acuerdo con los entregables y los artefactos de esta metodología. 
|
INDICADORES El seguimiento de los indicadores de desempeño de una empresa es fundamental para saber si va por buen camino. 
|
COLABORACIÓN Y AGRADECIMIENTO La realización de un proyecto de esta naturaleza no se debe sólo a sus autores, sino a todos aquellos que directa o indirectamente estuvieron involucrados. 
|
_________________________________________________________________________________________________________________________________________________________________________________________________________________ |
|
|
BE WELCOME,MIT is formed by 4 Macro Phases: Preparation, Refinement, Realization and Operation, in addition to the groups of activities of Sales and Monitoring and Control. Browse each session and learn more about the Digital TIM_________________________________________________________________________________________________________________________________________________________________________________________________________________
INTRODUCTION This guide will provide you with all the resources you need to use the metodology 
|
SALES CICLE It's covers the entire commercial process, from project architecture to the first contact to the service team with the client after signing the proposal 
|
MONITOR AND PROJECT CONTROL This group of tasks has the objective of guaranteein the good comunication of the Project to the Stakeholders 
|
_________________________________________________________________________________________________________________________________________________________________________________________________________________ |
|
|

It is the deeper alignment of needs and expectations, with the definition of the project team and stakeholders, review and confirmation of the scope, deadlines and the strategy in general. |
ACCESS HERE THE DELIVERIABLES AND ACTIVITIES OF THIS PHASE

This is the most in-depth alignment of needs and expectations, defining the project team and stakeholders, reviewing and confirming the scope, deadlines and strategy in general. It is also a time for identification/review of risks and technical alignment. The overall organization should include the preliminary project plan and promote a good opening and baseline determination event (version 1).
|

1.1.1 Transition meeting with commercial Access Details
This is the point when the baton is passed from the commercial team to the project team, through an alignment meeting. This stage is essential to assess whether there is any scope detachment and to define the strategy to be followed.
Description of activities: - Project Manager and/or Coordinator or PMO (as defined by the Unit) organizes the meeting’s agenda.
- Solutions Architect or Project Coordinator, as per unit definition/strategy, complete the Commercial Transition document - TIM065
- Business Solutions Executive, Solutions Architect, Project Manager or Coordinator and Project Portfolio Manager organize meeting inputs
- The following items should be evaluated/aligned during the meeting:
- Customer requirements and solution sold
- Scope detail
- Cost x effort alignment (budget)
- Customer expectations
- Initial Risks
- Details of the commercial aspects (Billing, expenditures, etc.)
- Project Milestones and Deadlines
- Initial Stakeholder Mapping
- Business drivers, targets, objectives, success metrics
If the conditions assessed during the meeting are equalized, the project proceeds to the initiation process and the Project Manager or Coordinator must record the information discussed in Commercial Transition and store it in the project repository. If detachment of scope is identified, the Project Portfolio Manager and Customer Service and Relations assess the issues raised and define the strategy for addressing the GAPs with the customer, evaluating the possibility of negotiating add-ons to the project with the customer or absorbing the gaps by the project or area.
____________________________________________________________________________________________________________________________________________________________________________________________________
INPUT(S): - Business Proposal
- Pricing
- Internal Validation of the Proposal
|
ACTORES: TOTVS - Business Solutions Executive*
- Solution Architect*
- Project Portfolio Manager*
- Project Manager or Coordinator*
- PMO
- RMO
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Mandatory |
|


|
1.2.1 Stakeholder Validation Access Details
To understand who will be interested in the project and the role of each one, it is necessary to align the information during the Passing of the Baton meeting with the Commercial Team and later, with the Customer. An important role that must be carefully formalized is that of Approver, as the Customer must recognize their approval rights (at different levels) for the definitions and deliverables of the Project.
Description of activities: Project Manager or Coordinator validates names and role with the Customer. The Stakeholder Mapping will now serve as a validation list for each one’s role. ____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Business Solutions Executive*
- Solution Architect*
- Project Manager or Coordinator*
CUSTOMER - Project Coordinator or Committee*
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obrigatório |
|
1.2.2 General Strategy, Assumptions & Constraints, Alignment & Expectations Access Details
This is one of the most important moments while conducting the project, as it is when the strategy of how the project will be executed is defined, linking its progress to the requirements and expectations presented. It is also the time to agree on limits, assumptions that can identify risks and constraints that can drive the scope of the project to guide planning. Review of the project repository, accelerators and templates required for the project.
Description of activities: The Project Committee, together with the Sponsor, validate the overall alignment, which will serve as a basis for the general project planning and kickoff meeting (Welcome). ____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Business Solutions Executive*
- Solution Architect*
- Project Manager or Coordinator*
CUSTOMER - Project Coordinator or Committee*
- Project Sponsor
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Mandatory |
|


|
1.3.1 Check technical aspects Access Details
The proper definition of the environment where the system will run is essential for users (Customer) to have a positive experience while using the solution. It is very important to carefully structure and formalize this decision to avoid future friction due to poor system performance. When the environment is managed by TOTVS Cloud, this care is enhanced because the Customer normally has a high expectation in relation to the solution having strong performance within TOTVS itself. Therefore, this step must be well defined in the process for Internal Approval of the Proposal and in the Passing of the Baton with the Commercial department.
Description of activities: - If the customer’s solution is hosted on TOTVS Cloud, the Project Coordinator or Manager must
contact the Cloud team to align the project and formalize the environment document with the customer. - NOTE: during the deployment period, the Project Coordinator or Manager is responsible for
monitoring the activities of the environment together with the Cloud team for the customer. We have specific document in the Cloud community - Infrastructure Expert analyzes the environment along with the Customer’s IT, producing the Checklist
or Portability Document (RM). - The expert can, depending on the results of the analysis, propose changes to improve the environment (elaboration of the Sizing Structure document).
- NOTE: Record the Customer’s refusal if they choose not to follow the recommendations.
IMPORTANT: the Sizing activity must be included in the Business Proposal in order to be executed. - Customer IT must evaluate the improvement proposal and formalize a decision with the Project
Committee and Project Manager or Coordinator (TOTVS). - NOTE: Record the time for adapting the infrastructure in the schedule to control progress and
dependencies.
____________________________________________________________________________________________________________________________________________________________________________________________________
INPUT(S): - Cloud - Service Contract separate from the project implementation proposal, signed by the client, with the environment definitions, in the Standard or Prime model. The main differences between the models are SLA time, environment availability and access. For both cases, a RACI Matrix and a Service Catalog are prepared for each project.
- On Premise (Sizing) – Subcontracting the IT team to evaluate and suggest the necessary environment. Standard budget of 40 hours must be sold in project pricing to cover these costs. The Portability Document will be prepared with the minimum infra requirements, in the case of RM products, for other products, an Infra Check List will be prepared.
|
ACTORS: TOTVS - Project Manager or Coordinator*
Infrastructure Analyst* Cloud Analyst* Business Solutions Executive* Solutions Architect*
CLIENTE - Project Coordinator or Committee *
|
SAÍDA(S): - Cloud documents prepared according to the project
Analysis of the Customer's Infrastructure carried out with a technical opinion validated by TIS documentation.
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obrigatório |
|


|
1.4.1 Develop Schedule and Define Project Milestones Access Details
The schedule is an extremely visual way of showing the sequencing of activities within a project, allowing you to check the interdependencies of tasks and visualize the critical path, in order to gain effective control and mitigate risks of delay. - NOTE: It is important to have visibility of the progress of other complementary schedules for
management.
This allows the Project Manager to measure the performance of the project and conduct corrective actions or anticipate any problems. Communicating what to do and who should do it at the right time, showing the correlation between activities, is a fundamental success factor.
Description of activities: Project Manager or Coordinator: - Organizes activities and dependencies, taking into account the deadlines agreed for the Milestones
- Reviews the effort with the team allocated to the project and validates the professionals’ commitment
regarding the deadlines - Once the planning is defined, the costs are allocated, the project’s profit margin is set and compared to the profit margin sold, it is possible to get a better picture of the project’s financial result.
- Defines the delivery Milestones and makes the agreements with the customer, adjusting the schedule
and which deliverables will make up each Milestone.
____________________________________________________________________________________________________________________________________________________________________________________________________
INPUT(S): - Validation with the customer of the information for Project Planning
- Project in the Project Management tool
|
ACTORES: TOTVS - Project Manager or Coordinator*
- RMO*
CUSTOMER - Project Coordinator or Committee*
|
OUTPUT(S): - Schedule - TIM032 prepared, respecting the executive expectations of the approved Milestones.
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obrigatório |
|
1.4.2 Define Team Access Details
Project Manager or Coordinator: - Organizes the roles defined during the Passing of the Baton Meeting
- Requests resources from the RMO, as planned
- The RMO confirms availability of its resources or informs alternatives for the Project Manager or Coordinator to evaluate (resource loan from other Units or allocation from Third Parties), in order to comply with validated expectations, as follows:
- Evaluates knowledge/experience required
- Evaluates position and level (depending on cost)
- Evaluates overall profile for service
- Analyzes service locations
- Evaluates coherence of the scope x demand
If a Third Party allocation is necessary, the third party RMO must be involved, initiating the processes for partner allocation. - Project Manager or Coordinator aligns with the project team the roles, targets and expected results (Internal kickoff).
Description of activities: - Organizes the roles defined during the Passing of the Baton Meeting
- Requests resources from the RMO, as planned
- The RMO confirms availability of its resources or informs alternatives for the Project Manager or Coordinator to evaluate (resource loan from other Units or allocation from Third Parties), in order to comply with validated expectations, as follows:
- Evaluates knowledge/experience required
- Evaluates position and level (depending on cost)
- Evaluates overall profile for service
- Analyzes service locations
- Evaluates coherence of the scope x demand
If a Third Party allocation is necessary, the third party RMO must be involved, initiating the processes for partner allocation. - Project Manager or Coordinator aligns with the project team the roles, targets and expected results (Internal kickoff).
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Project Manager or Coordinator*
- Third-party RMO*
- Analysts/Experts*
CUSTOMER - Project Coordinator or Committee*
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Mandatory |
|
1.4.3 Determine Baseline 1 Access Details
Baseline is the agreement signed between the parties that demonstrates all aspects discussed and addressed during the preparation of the project and establishing this baseline in the Project is fundamentally important. Once this baseline is set, all future changes should be analyzed and their impacts must be approved to create a new baseline, with the exception of the adjustment provided after the solution design.
Description of activities: Project Manager or Coordinator validates the overall Project Plan with the Customer ____________________________________________________________________________________________________________________________________________________________________________________________________
ATORES: TOTVS - Gerente ou Coordenador do Projeto*
- Usuários-Chave*
- Executivo de Soluções de Negócios
- Arquiteto de Soluções
CLIENTE - Coordenador ou Comitê do Projeto *
- Patrocinador*
|
OUTPUT(S): - Presentation of the baseline to the Project Sponsor and Committee during the project’s Kickoff meeting.
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Mandatory |
|


|
1.5.1 Schedule and Host the Project Kickoff Meeting Access Details
We should treat this Kickoff Meeting as an initial event for the Project, which in fact will be for many people. It is a very important moment for overall alignment with all participants who may not have had access to the strategy, changes that may occur, their roles as key users, etc.
That is why it is necessary to carefully explore the expected gains side, opportunities for visibility to the participants, how the Organization is after the implementation of the system, validate everyone’s commitment to the project, etc.
Description of activities: - Project Manager or Coordinator
- Validates the general Project Planning with the Customer
- Prepares the presentation along with the Customer, establishing a logical and engaging line
- Validates the presentation of the Project Welcome Guide – TIM024, with the Customer
- Customer internally organizes the event with support from the Project Manager or Coordinator
- Project Manager or Coordinator holds the meeting with limits established along with the Customer, i.e. with well-defined presentation roles (e.g. who presents the objective and benefits is usually the Sponsor).
______________________________________________________________________________________________________________________________ |
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Project Manager or Coordinator*
- Key users*
- Business Solutions Executive*
- Solutions Architect *
- TOTVS Support
CUSTOMER - Project Coordinator or Committee*
- Sponsor*
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Mandatory |
|


|
1.6.1 Stage completion and Quality Gate evaluation (Preparation) Access Details
Stage review and completeness evaluation
Description of activities: Project Manager or Coordinator reviews the completeness of deliverables for the stage, whether there are pending issues that need to be completed, whether the quality delivered is in line with expectations and whether there are issues and risks that need to be addressed before moving on to the next stage. ____________________________________________________________________________________________________________________________________________________________________________________________________
INPUT(S): - Opening Term - TIM021
- Schedule – TIM032 and team definition
- Project kickoff meeting held
|
ACTORES: TOTVS - Project Manager or Coordinator*
CUSTOMER - Project Coordinator or Committee*
- Customer*
|
OUTPUT(S): - Gate review and stage deliverables completed
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Mandatory |
|
|
|
|
__________________________________________________________________________________________________________________________________________________________________________________  It is the effective design of the solution to be delivered, reviewing the requirements on process analysis and eliminating scope and/or process gaps. |
ACCESS HERE THE DELIVERIABLES AND ACTIVITIES OF THIS PHASE

Refinement is basically the effective design of the solution to be delivered, reviewing the requirements for analyzing the processes, eliminating gaps in the scope and/or process and defining the configuration. During this stage, the project’s strategies are refined and workflows for the next stages are defined. It is also expected that at the end of this stage, the Sprints plan will be prepared for the construction and testing of the solution.
That is why we usually have an updated Baseline version at the end of this group (version 2), which must be the official version of the project, where alterations are only allowed through change approval by the Project Committee.
|

2.1.1 Process evaluation workshop Access Details
It is essential to learn about the customer’s processes according to the scope of the project to be able to design the solution while considering the changes that may occur. This is a stage in which it will be necessary to conduct some workshops and interviews and it is essential that this occurs in a way that is targeted to what was hired in order not to avoid generating frustration for our customers. TIP 1: Send the survey support material (questionnaires) in advance to guide key users and better prepare them for the survey meeting. TIP 2: Request copies of templates such as reports, invoices and any document that can assist in understanding the processes in advance.
Description of activities: Analyst/Expert: - Evaluates the scope of the project to align expectations during the interviews and direct their progress
- Conduct workshops with the Customer’s key users to understand current processes, forms and reports they use
- Analyst/Expert must create process flows for projects that include the elaboration of a flow
- They are responsible for validating and collecting signatures to formalize the elaborated design
- NOTE: Analyst/Expert must keep the Project Manager or Coordinator always aligned with the conduct and status of the validation
- TIP 1: Best practices indicate that joint validation of processes facilitates understanding and signing of the Process Diagram.
- TIP 2: Double-check understanding with key users (confirmation of communication)
____________________________________________________________________________________________________________________________________________________________________________________________________
INPUT(S): - Signed Business Proposal
- Survey support material (questionnaires)
|
|
ACTORES: TOTVS - Analyst/Expert*
- Project Manager or Coordinator*
CUSTOMER - Project Coordinator or Committee*
- Key Users*
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Mandatory |
|
2.1.2 Process Design and Configuration Access Details
- Basically, the solution design consists of demonstrating to our Customer that we understand the business context defined by the key users and that we are able to properly configure the system for use, meeting the general expectations presented.
However, if issues of this order (outside scope) still arise, the Analyst/Expert must formalize the gaps identified through a Change Request – TIM031, propose together with the Architect and the Project Committee the best approach to the issues and offer alternatives for the scenarios. It is very important to have the engagement and responsibility of key users in defining the solution. - NOTE: The role of the Analyst/Expert in this context is to provide his experience from other projects and contribute benchmarks to the processes, but the key user (Customer) must be responsible for definition.
Description of activities:
- The Analyst/Expert prepares the operational flow according to the definitions of key users, following the scope agreed with the Customer and identifying the deviation points for gap analysis.
- Key user validates flow and description
- Analyst/Expert describes details related to the flow as needed for clarity:
- Determining business rules
- Describing calculation rationales
- Determining entry criteria
- Determining exit criteria
- Identifying expected results
- Identifying systemic settings (Configuration Plan - System Parameterization)
- Analyst/Expert must validate and receive approval from the customer in the Process Diagram – TIM041 with the respective Key Users, thus determining the solution to be built
- Project Manager or Coordinator must consolidate all approved Process Diagrams – TIM041, as Project records
- NOTE: This event can be seen as an important Project Milestone.
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Analyst/Expert*
- Project Manager or Coordinator*
CUSTOMER - Project Coordinator or Committee*
- Key Users*
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Mandatory |
|
2.1.3 Adherence and GAP Analysis Access Details
It is essential that this gap analysis is performed with the Customer to identify the actual needs before any negotiation approach, to ensure added value in any analysis of impacts and results in the future. It is just as important to have an internal analysis of the panorama between the Project Manager or Coordinator and the Architect to define an approach strategy where they must indicate a viable solution for the continuity of the project (and generate a feeling of partnership with the Customer). At the end of the negotiations and after approval, it is essential that the Project Manager or Coordinator update the project plans, placing the impacts raised for approval of the new baseline version 2.
Description of activities: - Analyst/Expert and Key Users list the gaps identified in the Process Diagram – TIM041 and in the Project Monitoring and Control - TIM013 to organize the overall context
- Analyst/Expert, Project Manager or Coordinator and Architect analyze the big picture, identify and define an approach strategy to make the project feasible
- NOTE: It is recommended that this analysis be conducted while considering the big picture instead of assessing gaps and changes individually, as there is usually a trade-off between new and canceled items, balancing the negotiation.
- Project Manager or Coordinator and Architect classify the gaps and submit for study and approval by the Project Committee
- Project Committee:
- Evaluates the big picture for negotiating items (gaps and changes) between the parties
- Approves the final negotiated version
- Project Manager or Coordinator records the result and updates the Project history with the changes
and impacts absorbed.
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Analyst/Expert
- Project Manager or Coordinator*
- Business Solutions Executive*
- Solution Architect*
CUSTOMER - Project Coordinator or Committee*
- Key Users*
|
OUTPUT(S): - Gap and Change Analysis aligned with the Customer, with the definition of the Architect and Project Manager or Coordinator on the approach and approval of changes through the Change Request – TIM031
- Approval of a new baseline on changes impacted by gaps and changes (approved)
- NOTE: if there is no approval, the decision to reject the identified gaps and changes must be recorded.
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Mandatory |
|


|
2.2.1 Prototype execution Access Details
The objective of this stage is to produce a preliminary prototype, based on what was surveyed, which helps to validate the requirements with the customer and give a sense of what is being acquired. This type of ceremony helps to anticipate deviations in understanding that are normally perceived by the customer in future stages of the project. The prototype should answer the most important questions, so stay focused on that and not on having something that is fully functional. The effort to build and execute the prototype must be adapted according to each project’s context and budget.
Description of activities: - Project Manager or Coordinator organizes the ceremony along with the Committee (Customer)
- Analyst/Expert:
- Organize the procedure based on the scope hired and what was surveyed
- They make sure that the environment defined for the execution of the prototype is updated and functional to ensure the quality of the ceremony
- Present the prototype for validation of requirements.
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Deployment Analyst/Expert*
- Project Manager or Coordinator*
CUSTOMER - Project Coordinator or Committee*
- Key users*
|
OUTPUT(S): - Basic knowledge of how the tool works and the flexibility it can provide the customer.
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Mandatory |
|


|
2.3.1 Definition of test cycles and scenarios Access Details
The Test Script - TIM045 has the important role of guiding the users responsible for the tests to simulate all the processes and their respective varied scenarios to ensure that the solution built actually meets the overall requirements and expectations. It is also a good time to reaffirm the commitment with key users about their role as those responsible for the quality of the tests and to ensure that they are validating the delivery of a system that will be used in their daily lives. - NOTE: Some customers even request to perform this validation step in parallel with daily tasks for a given period. It is important to highlight that the structured procedure is a better option, since the test period parallel to the operation may not contain all the desired scenarios in the solution, increasing the risk of post-GO LIVE problems.
Description of activities: - Key Users (Customer) organize the processes and different scenarios to cover all business variations inserted in the context of the solution
- NOTE: the TOTVS project team must support this activity by guiding the completion of the test procedure, but the Customer is responsible for its preparation
- Analyst/Expert, Project Manager or Coordinator organize, based on the proposed scenarios, the established criteria and limits of how they will perform the integrated system test
- NOTE: the Integrated System Test is the cycle that guarantees the proper functioning of the system and usually has a more technical content, i.e. the system is executed with all the features foreseen.
The expected values and results are determined in the delivery validation - Project Manager (Customer) validates the Test Script - TIM045 with key users and publishes it officially as the basis for the tests to be performed.
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Analyst/Expert*
- Project Manager or Coordinator*
CUSTOMER - Project Coordinator or Committee*
- Key Users*
- Functional managers of business areas
|
OUTPUT(S): Elaboration of the Test Script - TIM045 started. NOTE: It is a good practice to start defining the training scripts at this time and phase, but this activity must be completed before carrying out the training, in the realization phase.
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Mandatory |
|


|
2.4.1 Training Preparation Access Details
Organizing the Training in advance is essential to ensuring the effective participation of all those necessary to the process, in addition to ensuring that the necessary infrastructure will be ready for the scheduled dates. NOTE: this task can be performed in parallel with the Test Script - TIM045 document , but experience shows that it is easier to organize training based on the defined Test Script - TIM045. However, it often occurs that the overall organization (infrastructure) needs to start early to ensure everyone’s availability (advance notice).
Description of activities: - Analysts/Experts must provide the work sequence and scheduling content
- Key Users (Customer) organize the calendar, scheduling content and participants according to the processes identified in the Test Procedure
- The Customer’s internal team organizes the infrastructure so that the training can be conducted:
- Physical location
- Available machines
- Access (network)
- Transportation/accommodation
- Project Committee approves the infrastructure plan
- The Project team conducts the training communication, considering all the aforementioned details
- NOTE: it is important to consider all restrictions imposed by the infrastructure issue in the training plan.
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Analyst/Expert*
- Project Manager or Coordinator*
CUSTOMER - Project Coordinator and Manager*
- Key Users*
- Project Committee – as needed for approval
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Mandatory |
|


|
2.5.1 Definition of Data Conversion and Interfaces Access Details
Organizing in advance how data loads will be is fundamental, because it will be possible to perceive needs that generate additional construction effort, both in the technical scope (development of load routines), as well as in the business scope (for manually registered information). Another very important aspect at this point is to determine the persons in charge, method, validation criteria and conversion rules.
Description of activities: - Analyst/Expert and Key Users (Customer) evaluate the data load needs so that the solution is fully
available as planned. The aspects evaluated include: o Which data/Conversion item o Person in charge of the extraction o Will there be from/to? How will it be accomplished? o Person responsible for the load o Which method (manual/routine)? o Validation criteria o Person responsible for the validation o Deadlines must be included in the schedule o Project Manager (Customer) approves the load and interface plan
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Analyst/Expert*
- Project Manager or Coordinator*
CUSTOMER - Project Coordinator and Manager*
- Key Users*
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Mandatory |
|


|
@2.6.1 Project Backlog and Sprint and Release Planning Access Details
Conducting a Sprint requires a lot of energy and focus. Before starting a Sprint, you need to have the right team and challenges. You will also need time and space to conduct your Sprint. In other words, preparing to apply this method is fundamental for its ultimate success. The time set for each Sprint must be appropriate to the context of each project. Ideally from 2 to 4 weeks.
Description of activities: 1. Define the product backlog, with all product requirements to be delivered; 2. Define the deliverables for each Sprint according to the team available and the period defined for the sprint; - Sprint planning can involve the project team, if necessary, to define what is most important to deliver first taking into account the value added to the business.
- In the process of detailing the backlog, the characteristics of the product and its scope must be taken into account.
3. Take into account that partial deliveries can be grouped into a set of Sprints, called a Release, so that it is possible to have partial validation or deliver a feature or product in production ____________________________________________________________________________________________________________________________________________________________________________________________________
INPUT(S): - Process diagram – TIM041
- Definition of test cycles and scenarios
- Training preparation
- Definition of Data conversion and Interfaces
|
ACTORES: TOTVS - Deployment Analyst/Consultant*
- Project Manager or Coordinator*
CUSTOMER - Project Coordinator or Committee*
|
OUTPUT(S): - Sprints and Releases Plan defined.
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Mandatory |
_ |


|
2.7.1 Stage completion and Quality Gate evaluation (Refinement) Access Details
Reviewing all aspects of the general Project Planning is essential to reassess whether all points have actually been aligned, check if there are any pending issues, establish a new commitment with the Committee, formalize a new baseline and notify Stakeholders from all spheres. - NOTE: From this point on, any requested change will have a greater impact than what has occurred so far. Therefore, there is a need to carefully analyze the impacts of any new requests.
Description of activities: - Project Manager or Coordinator:
o Checks the completeness of stage deliverables o Organizes new information from the Refinement stage. o In possession of the organized information, reviews the impacts analyzed, the approvals made, the communication actually conducted and updates the Project baseline - Project Committee approves general planning
- Publication of Official Planning
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Project Manager or Coordinator*
CUSTOMER - Project Coordinator or Committee*
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Mandatory |
|
|
|
|
_________________________________________________________________________________________________________________________________________________________________________________________________________________ 
It is actually building on the detailed and approved design in the previous phase. Building and testing is based on Sprints based on the backlog. |
ACCESS HERE THE DELIVERIABLES AND ACTIVITIES OF THIS PHASE

It is the actual building on the detailed design approved in the previous stage. This construction implies the availability of work environments, execution of system configuration sprints, development of customizations, data loads and delivery validation, through technical and business cycles. It is important to define which critical tests must be performed in the transition (turnover) and to review the plan for the system’s turn over to the production environment. Construction and testing are based on Sprints based on the backlog. The execution of the turnover plan and the integrated testing occur at this stage. To recapitulate, the purpose of this group of tasks is to control the construction of the system within the approved design, ensuring the fulfillment of the requirements and a smooth turnover plan, managing the delivery within the planning approved by the Customer. |

3.1.1 Configure Product Access Details
It is at this stage that the product configuration occurs as agreed and approved by the customer, respecting what was defined in the refinement stage and prioritized for each sprint. In the event that unforeseen issues arise or are addressed in the previous stage, these will be discussed by the team at Sprint retrospective meetings and depending on the issue, a Change Request must be recorded in order to evaluate the impact and obtain its formal appr oval, which can change the deadline, cost or quality defined during the Solution Refinement. Deliveries occur through Sprints (iterations) with defined time (ideally 2 to 4 weeks) and each Sprint must deliver an increment of the product that may or may not be validated with the customer, according to the release schedule (Sprint groups). The following ceremonies are expected to take place during each Sprint cycle: ● Sprint Planning: Ceremony to define the sprint’s purpose, scope of work, how and what will be delivered. ● Iteration Meeting (“Daily”): This is the sprint follow-up meeting, where its progress is checked. Short duration (no more than 30 min), in which each member reflects on: What did you do from yesterday to today?, What will I do from today to tomorrow?, Are there any hindrances? The recurrence of the meeting can be defined according to the context of each project and can be conducted with the entire project team with or without the participation of the Project Coordinator or Manager.
NOTE: It is recommended to organize several Change Requests – TIM031 together to have a better perception of the impacts, instead of evaluating them individually. To that end, it is possible to stipulate scheduled times/dates to request, evaluate and approve the demand.
Description of activities: - During the Sprint, the Deployment Analyst or Consultant:
o Configures the system based on the Process Diagram approved by the Customer and prioritized backlog for the Sprint. o Reports the progress, risks or issues found, any delays and deviations that occurred through the iteration meetings or the daily meetings. The Project Manager or Coordinator monitors progress and works on communication and alignment with the Project Committee or Customer. At the end of each Sprint, a retrospective meeting is expected to be held with the entire team that participated in the Sprint. After the completion of each Sprint, a new iteration cycle begins until the entire product backlog is delivered.
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Deployment Analyst/Consultant*
- Project Manager or Coordinator*
CUSTOMER: - Project Coordinator or Committee*
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Mandatory |
|
3.1.2 Backlog/Development of Customizations Access Details
Customizations require special care because they can affect both the project plan and the proper functioning of the system, considering the design of the solution. To reduce these risks, the key users involved must be able to use standard routines as much as possible, as the analysts/specialist must be able to understand the needs and present alternatives consistent with the Customer's business and operation. When identifying a need for customization, the Analyst/Specialist must prepare the Customization Specification stating relevant details to increase the quality of delivery. The development of customizations must follow that agreed and approved by the Customer, i.e. follow what was defined in the TIM041 Process Diagram and/or in the TIM044 Customization Specification. .
Description of activities: - The Analyst/Specialist and the Key Users (Customer) evaluate the details of customization needs, respecting the project scope approved in the Design of the Solution (TO BE) and the results of the GAP Analysis
- The Analyst/Specialist describes the functional details in the Customization Specification for forwarding/requesting to the Software Factory team or to the developer team of the project itself
- Technical Lead organizes deliveries with the development team (Backlog/Sprints/Deploy)
- Factory Team carries out the development according to what was defined in the TIM041 Process Diagram and in the Logical Project (PL)
- Software Factory Technical Lead:
o Reports progress, risks/issues found, possible delays and deviations that occurred o Sends the evidence of the test performed, showing the positive result. - Project Manager or Coordinator monitors progress and works on communication and alignment with the Project Committee/Customer.
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Developer (Software Factory)*
- Technical Lead (Software Factory)*
- Deployment Analyst/Consultant*
- Project Manager or Coordinator*
CUSTOMER: - Project Coordinator or Committee*
|
OUTPUT(S): - Customizations developed.
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Mandatory |
|


|
3.2.1 Training of Key Users Access Details
This training should lead key users to the effective use of the system in accordance with the approved Solution Design. It is important to remember the commitment aligned in the preparation/Project Kickoff Meeting, that the key users are responsible for replicating the knowledge and also for any support.
Description of activities: - Analysts / Consultants and Key Users meet according to the training plan carried out in Refinement
- Analysts or Consultants provide training in accordance with the approved Solution Design and respective configurations.
- Key Users:
o They must absorb the knowledge and deepen the system in practice to ensure efficient use o Formalize the receipt of knowledge and use of the system with the Consultants who provided the training - Project Manager or Coordinator organizes the formalizations and carries out the validation of this stage with the Project Committee
- The Project Committee approves the training by signing the Training Script - TIM037.
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Deployment Analyst/Consultant*
- Project Manager or Coordinator*
CUSTOMER: - Key Users*
- Project Coordinator or Committee*
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Mandatory |
|


|
3.3.1 Prepare and Execute Data Load Access Details
At this time, the identified and planned loads are conducted, following the stipulated method, by the respective persons in charge of such task. It is equally important to have validation criteria to ensure that the load has been successful, to ensure that the following tests and validations can generate the expected results. NOTE: In cases of manual loading, i.e. data entered manually by key users, the effort and deadlines must be carefully agreed to ensure a well-aligned schedule.
Description of activities: - Deployment Analyst(s)/Consultant(s) perform the data loads with defined routines/tools, as planned and aligned during the Refinement stage.
- Key users:
- Perform data loads manually as planned and aligned during the Refinement stage.
- Validate the migrated data, by one method or another, using the agreed tools.
- Users and Analyst(s)/Consultant(s) report progress, risks/issues found, possible delays and deviations that occurred.
- Project Manager or Coordinator monitors progress and works on communication and alignment with the Project Committee/Customer.
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Deployment Analyst/Consultant*
- Project Manager or Coordinator*
CUSTOMER: - Key Users*
- Project Coordinator or Committee*
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Mandatory |
|


|
3.4.1 Unit Tests Access Details
The main purpose of this task is to guarantee the functioning of the system so that key users can effectively validate the solution. Therefore, the target of these tests should be more focused on executing the routines and less focused on the expected results, such as the correct calculation of taxes, for example. o NOTE: This priority division occurs because a large part of the expected results is directly related to the registrations and the business itself. That is why it is customary to plan cycles with different aspects.
Description of activities: - Implementation Analyst(s)/Consultant(s), usually in conjunction with the IT team, perform the tests developed in the Test Procedure with a focus on the functioning of the system, in order to guarantee its availability to key users in the effective validation.
- Analyst(s)/Consultant(s) report progress, risks/issues found, possible delays and deviations that occurred.
- Project Manager or Coordinator monitors progress and works on communication and alignment with the Project Committee/Customer.
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Deployment Analyst/Consultant*
- Project Manager or Coordinator*
CUSTOMER: - Project Coordinator or Committee*
|
OUTPUT(S): - System tested in all its features, without considering business results (which depend on aspects of registration and business rules) and Test Script - TIM045 updated.
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Mandatory |
|
3.4.2 Integrated System Testing – TOTVS Team Access Details
The main purpose of this task is to ensure, in addition to the functioning of the system, that the expected results are validated, as well as the processes and their different scenarios. In some cases, the system load test is included after the integrated tests.
Description of activities: - Analyst(s)/Consultant(s) are organized according to the plan to perform the overall validation of the solution.
o NOTE 1: at this stage, with the system fully operational, the processes and their different scenarios must be validated and the expected results verified. - Analyst(s)/Consultant(s) report progress, risks/issues found, possible delays and deviations that occurred.
- Project Manager or Coordinator monitors progress and works on communication and alignment with the Project Committee/Customer.
o NOTE 2: the Project Manager or Coordinator can identify the need to conduct a load test on the system, which must be performed at this stage, using a Validation Statement document – TIM010 with the results of the tests.
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Deployment Analyst/Consultant*
- Project Manager or Coordinator*
- TOTVS Support
CUSTOMER: - Project Coordinator or Committee*
|
OUTPUT(S): - Solution tested in all its features, processes and scenarios, also considering business results (which depend on aspects of registration and business rules) and Test Script - TIM045 updated.
- If applicable, the Validation Term - TIM010 with the result of the load tests.
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Mandatory |
|
3.4.3 Integrated System Testing – Customer Team Access Details
The main purpose of this task is to ensure, in addition to the functioning of the system, that the expected results are validated, as well as the processes and their different scenarios.
Description of activities: - Analyst(s)/Consultant(s) and Key Users are organized according to the plan to perform the overall validation of the solution.
o NOTE: at this stage, with the system fully operational, the processes and their different scenarios must be validated and the expected results verified. - Analyst(s)/Consultant(s) report progress, risks/issues found, possible delays and deviations that occurred.
- Project Manager or Coordinator monitors progress and works on communication and alignment with the Project Committee/Customer.
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Deployment Analyst/Consultant*
- Project Manager or Coordinator*
CUSTOMER: - Key Users*
- Project Coordinator or Committee*
|
OUTPUT(S): - Solution tested in all its features, processes and scenarios, also considering business results (which depend on aspects of registration and business rules), Test Script - TIM045 and Validation Term - TIM010 Ratification Statement) signed.
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Mandatory |
|


|
3.5.1 Turnover Testing Definition (Best Practice) Access Details
It is essential to restrict the official release of the system to key users, so that they can perform real activities in the system already in the Production environment, guaranteeing the essential functioning of the business, considering all critical processes.
Description of activities: - Key Users define critical operations as a GO LIVE criterion, right after the Cutover is executed
- Project Manager or Coordinator:
o Monitor definitions and assess whether they meet the established quality criteria o At the end, record the decision in the Test Script - TIM045.
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Deployment Analyst/Consultant*
- Project Manager or Coordinator*
CUSTOMER: - Key Users(person responsible for the execution)*
- Project Coordinator or Committee*
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Mandatory |
|
3.5.2 Definition/Review of the Turnover Plan Access Details
The Definition/Review of the turnover plan must be conducted immediately after obtaining the results of the Integrated Tests and Solution Validation, where there are more details about the needs for suspension of the system, changes in the business process, the impact on other areas etc. It is important that any new issue that arises be addressed at this time, thus avoiding postponing a problem that may cause negative impacts to the entire project.
Description of activities: - Analyst/Expert and Key Users (Customer) reassess the details of the impacts on the system transition to Production after results, considering technical and functional aspects:
- Technical:
o Environment actions (infrastructure) o Configuration actions o Data transport actions o Customization equalization actions o Update application actions (software), which can take place throughout the project o Preparation of Cloud activities (when there are host services). - Functional:
o Alignment with areas that may be impacted by the suspension period (cutover execution) o Alignment with Customers on the same issue o Alignment with Suppliers and Partners on the same issue o Training and preparation of operational changes (TO BE processes) o Business Contingency Plan - Project Committee approves the review of the Turnover and Rollback plan – TIM054
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Deployment Analyst/Consultant*
- Project Manager or Coordinator*
- TOTVS Cloud (when there are host services)*
CUSTOMER: - Key Users(person responsible for the execution)*
- Project Coordinator or Committee*
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Obrigatório |
|
3.5.3 Turnover Approval and Disclosure Access Details
The Committee's approval (GO decision) must be followed by an official release of the Transition execution to all stakeholders so that: - All areas involved, Customer, Suppliers and Partners can properly plan and/or agree on contingency plans
- The project gains political and strategic strength in the Organization
- The project must have final engagement, because at this moment it is essential that everyone appropriately prioritize their time in favor of the quality of the transition.
Additionally, a clear and structured TOTVS internal communication action strengthens cooperation between areas and ensures the necessary support for the customer’s success after Go Live. Description of activities: ____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Deployment Analyst/Consultant*
- Project Manager or Coordinator*
- TOTVS Support
CUSTOMER: - Key Users(person responsible for the execution)*
- Project Coordinator or Committee*
|
OUTPUT(S): - Turn and Rollback Plan - TIM054 officially approved and disclosed to all Project stakeholders.
- Email with the Go Live Communication sent to TOTVS internal areas to support alignment and preparation for a customer’s production go-live..
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Mandatory |
|


|
3.6.1 Stage completion and Quality Gate evaluation (Realization) Access Details
Gate review and completion of stage deliveries
Description of activities: - Project Manager or Coordinator reviews the deliverables for the stage.
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Project Manager or Coordinator*
CUSTOMER: - Customer*
- Project Coordinator or Committee*
|
OUTPUT(S): - Gate review and stage deliverables completed
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Mandatory |
|
|
|
|
_________________________________________________________________________________________________________________________________________________________________________________________________________________ 
It is the execution of transition activities for entry into production and the follow-up period or Assisted Operation right after the decision to GO LIVE! |
ACCESS HERE THE DELIVERIABLES AND ACTIVITIES OF THIS PHASE

It is the effective execution of activities for the system to come online in Production, including the review of the environment, performing the transition (turnover) and monitoring the assisted operation of the system right after the official GO LIVE! disclosure. End users should also be trained in this step, after the system has been effectively validated.
The purpose of this group of tasks is to control the completion actions for the project, guaranteeing the agreed quality and an assisted transition period to formalize the conclusion of the contracted services.
|

4.1.1 Preparation of the Production Environment Access Details
This step consists of preparing or reviewing the environment that will be used for the actual operation of the system in the Organization. Therefore, it is essential that it is within the technical specifications defined throughout the project. The installation checklist aims to provide detailed guidance on the technical parameters, while the Turn and Rollback Plan - TIM054 aims to provide extra inputs so that the infrastructure analyst can have a broader view of the environment and expectations. - ATTENTION: the IT team must effectively participate in the actions, being the only staff with access to the Production environment, thus being directly responsible.
Description of activities: - Infrastructure Expert prepares the Production environment following the defined technical specifications
- IT (Customer) should post the end of the operation and its results
- NOTE: all activities defined in the Turnover and Rollback Plan – TIM054 for the environment must be performed in this step.
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Project Manager or Coordinator*
- Cloud Analyst *
- Infrastructure Analyst *
CUSTOMER - Project Coordinator or Committee*
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Mandatory |
|
4.1.2 End User Training (Best Practice) Access Details
This training should lead the end users to the effective use of the system, respecting all the definitions established in the Refinement of the Solution, Training Procedure and in the effective delivery performed. NOTE: Unless this type of service was purchased from TOTVS under the scope of the Project, the Customer is solely responsible for this task. Even if it was acquired, it is important to bring key users as participants so that they can assume the role of replicators and be a reference in the business process.
Description of activities: - Key Users (replicators) meet according to internal organization (Customer) and provide training in accordance with the Solution Refinement and revised Training Procedure
- End Users must absorb knowledge and gain deeper understanding of the system in practice to ensure efficient use
- Key users:
o Formalize training with End Users o Organize formalizations and validate this step with the Project Committee.
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Deployment analyst/consultant*
- Project Manager or Coordinator*
CUSTOMER - Project Coordinator or Committee*
- Key Users (Replicators)*
- End Users (Customer areas)*
|
OUTPUT(S): - Training performed and validated
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Mandatory |
|
4.1.3 Alignment with TOTVS Support (Best Practice) Access Details
We know that after the project, in order to continue a good customer experience, it is essential to align the demand with the support team so that it can prepare itself to serve the customer well from this point on in their journey. The point here is to describe the GO LIVE scope of demand, support trends, and effective date.
Description of activities: - Project Manager or Coordinator completes the Transition to Support document – SM081, holds an alignment meeting with the TOTVS Support team of the functionalities that will be used by the customer.
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Project Manager or Coordinator*
- TOTVS Support*
|
OUTPUT(S): - Transition to Support - SM081
|
____________________________________________________________________________________________________________________________________________________________________________________________________
|
|
4.1.4 Definition and Formalization of the Monitoring Strategy and Agreement Access Details
From the moment that the key users receive in-depth training and perceive the required demand for support, it is necessary at this point to decide how much they can absorb from the support and how much they will still need support from the team of consultants, considering the demand. The complementary Proposal must reflect the scenario approved by the Committee, since the general aspects were considered and reviewed after the solution was validated. NOTE: Great care must be taken in this definition, considering the expertise per front conducted vs. the Customer’s autonomy to propose a balanced and efficient scenario.
Description of activities: - Analysts/Consultants and Key Users meet with the Project Manager or Coordinator and Committee representative (Customer) to reassess the follow-up needs after GO LIVE, considering the support x demand aspects based on the results of the Training conducted
- Project Manager or Coordinator:
o Plan the follow-up according to the revised demand to determine the cost x quality impacts foreseen in the pre-sale stage o Records the decision via the Meeting Minutes - Project Committee approves new planning and any cost difference, based on the scenario presented by the project team (analysts/consultants and key users)
- Business Solutions Executive prepares a complementary Business Proposal to fill the monitoring gaps identified and approved by the Committee (if necessary)
- Customer approves the Complementary Proposal.
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Project Manager or Coordinator*
- Business Solutions Executive*
- Deployment analyst/consultant*
CUSTOMER: - Project Coordinator or Committee
- Key Users
|
OUTPUT(S): - Definition of the people in charge of post-GO LIVE support, registered in the Meeting Minutes – TIM005 and approved by the Committee
- Complementary Business Proposal approved by the Customer (if necessary).
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Mandatory |
|
4.1.5 Execution of the Turnover (Transition) Access Details
The transition (turnover) must be executed with sufficient focus and attention to the expected results to guarantee the quality of the Production environment. If unforeseen circumstances occur, a contingency plan must be in place and/or people who can decide on alternatives quickly, since this scenario usually works in a restricted window. Once finalized, the results must be checked and the system released for the last step before official publication, which is the execution of critical operations in Production (Turnover Test).
Description of activities: - Analysts/Experts and Key Users (Customer) perform the tasks planned in the transition (turnover) of the system to Production, as defined in the Turn and Rollback Plan - TIM054, considering technical and functional aspects:
- Technicians
o Environment actions (infrastructure) o Configuration actions o Data transport actions o Customization equalization actions o Update application actions (software), which can take place throughout the project - Functional:
o Alignment with areas that may be impacted by the suspension period o Alignment with Customers on the same issue o Alignment with Suppliers and Partners on the same issue o Training and preparation of operational changes (TO BE processes) o Business Contingency Plan - Project Committee communicates the end and the result of the execution, releasing the Turnover Test.
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Analyst/Expert*
- Infrastructure Analyst*
- Project Manager or Coordinator*
CUSTOMER: - Project Coordinator or Committee*
- Key Users*
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Mandatory |
|
4.1.6 Turnover Testing Execution (Best Practice) Access Details
It is essential to restrict the official release of the system to key users, so that they can perform real activities in the system already in the Production environment, guaranteeing the essential functioning of the business. Once the critical operations are validated, GO LIVE is confirmed for all other participants in the Organization. - NOTE: The time dedicated must have been planned in advance, as well as the limits, in case the execution does not go exactly as expected.
Description of activities: - Key Users execute the critical operations as GO LIVE criteria, right after the Transition (Turnover) is executed
- Analyst/Expert monitors the results and assesses whether they meet the established quality criteria
- At the end, the Project Manager or Coordinator records the decision via the Meeting Minutes
- Project Committee officially publishes the GO LIVE.
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Analyst/Expert*
- Project Manager or Coordinator*
CUSTOMER: - Project Coordinator or Committee*
- Key Users*
|
OUTPUT(S): - Result of the Turnover Test in Production
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Mandatory |
|
4.1.7 Official GO/NO-GO Approval and Disclosure Access Details
The Committee should officially disclose the GO/NO-GO decision to all stakeholders so that: - All areas involved can start work normally
- The system is released for operation with Customers, Suppliers and Partners
- We have a formal event to acknowledge the delivery of the Project.
Description of activities: Project Committee officially discloses the GO/NO-GO decision, based on the result of the Turnover Test (which can be positive or negative). ____________________________________________________________________________________________________________________________________________________________________________________________________
INPUT(S): - Test cycles performed successfully.
|
ACTORES: TOTVS - Project Manager or Coordinator*
CUSTOMER: - Project Coordinator or Committee*
- Key Users*
|
OUTPUT(S): - Validation Term - TIM010 (GO Live authorization statement) signed, with the GO/NO-GO decision officially disclosed in the Organization and among all of the Project’s stakeholders.
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Mandatory |
|

|
4.2.1 Monitor Assisted Operation Access Details
After the Project Committee officially discloses the GO/NO-GO decision, Assisted Operation begins in accordance with the approved strategy and complementary proposals. This period is very critical and must be conducted to lead the Customer to a level of autonomy sufficient to carry out its operation in a safe and confident manner. - NOTE: It is common for new opportunities to arise during this period, with new business and/or continuity of recurring assistance. It is important that the Project Manager or Coordinator be attentive to align with the Business Solutions Executive at the time of completion.
Description of activities: - Contracted analysts/experts (according to the approved contracts and strategy) start supporting the operation of the system
- Project Manager or Coordinator periodically evaluates the results and gradually prepares the withdrawal of the support team
- Coordinator (Customer) together with the key users prepare to maintain the operation without the local support of the project team, gradually and in accordance with the approved strategy
- Project Manager or Coordinator formally ends the assisted operation at the end of the agreed period.
____________________________________________________________________________________________________________________________________________________________________________________________________
INPUT(S): - End users operating the system
|
ACTORES: TOTVS - Analyst/Expert*
- Project Manager or Coordinator*
CUSTOMER: - Project Coordinator or Committee*
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Mandatory |
|
4.2.2 Referral to Standard Support Access Details
We know that after the project, to ensure a continued positive Customer experience, it is essential to align the demand with the support team so that they can prepare themselves to serve the Customer well from this point forward on their Journey. The objective is to clarify and direct the Customer to the type of service that can best add value to their operation and their experience with TOTVS.
Description of activities: Project Manager or Coordinator passes information along about how Support works and customer service options. ____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Project Manager or Coordinator*
CUSTOMER: |
OUTPUT(S): - Support information passed on to the customer.
TOTVS Relationship Center: suporte.totvs.com
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Mandatory |
|

|
4.3.1 Conduct project retrospective (Relationship and client) Access Details
This moment of referral to the Relationship team should be used to: - Inform the Customer of the TOTVS structure
- Strengthen the relationship
- Seek to develop the opportunities identified throughout the Project
- Seek general feedback.
Description of activities: - Project Manager or Coordinator reviews the project’s history with the Business Solutions Executive and the opportunities identified throughout the Project
- Project Manager or Coordinator and Business Solutions Executive align new opportunities with the Customer and reinforce the partnership link
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Project Manager or Coordinator*
- Business Solutions Executive*
CUSTOMER: |
OUTPUT(S): - Customer is aware of the new moment, with the partnership well underway and new opportunities launched for its development.
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Mandatory |
|
4.3.2 Record of Lessons Learned from the Project Access Details
The lessons learned theme must be well structured to really have a knowledge base that can be reused and shared with employees seeking acquired experiences.
Description of activities: Project Manager or Coordinator organizes records collected throughout the project to record them in a structured way. ____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Project Manager or Coordinator*
- Solution Architect*
- Business Solutions Executive*
|
____________________________________________________________________________________________________________________________________________________________________________________________________ * Mandatory |
|
4.3.3 Project Completion Access Details
Formalization of completion is an essential event for recognizing the end of the project and also serves to release resources for other projects, as well as recognizing the Revenue linked to the actual conclusion. It is important to point out that the construction of this closure begins with the preparation of the project, defining the acceptance criteria throughout the project. Good management with transparency and evidence of agreements and deliveries made and recognized, will make this moment very smooth with the Customer, establishing a good experience in their Journey!
Description of activities: - Project Manager or Coordinator organizes evidence of progress and completion of the Project and presents it to the Committee to formalize the closure of the project, including the validation of outstanding milestones or outstanding billing installments
- Project Committee and Sponsor approve the Service Completion Certificate – TIM062 (Term of Closure)
- Project Manager or Coordinator organizes the actions to close the project internally and sends it to the PMO, after the client accepts the Service Completion Certificate – TIM062
- (Closure Term)
- NOTE: Internal policies and procedures of each unit must be observed, which may determine specific rules, in addition to those described in this document, for the administrative closure of the project.
____________________________________________________________________________________________________________________________________________________________________________________________________
ACTORES: TOTVS - Project Manager or Coordinator*
- TOTVS Support
CUSTOMER: |
____________________________________________________________________________________________________________________________________________________________________________________________________ * Mandatory |
|
|
|
|
_________________________________________________________________________________________________________________________________________________________________________________________________________________
ROLES AND RESPONSIBILITIES
The RACI Matrix below guides the assignment of responsibilities to the TOTVS project team, according to the deliverables and artifacts of this methodology. 
|
INDICATORS Monitoring a company's performance indicators is essential to know if it is on the right track. 
|
COLLABORATION AND ACKNOWLEDGME
The realization of a project of this nature is not only due to its authors, but rather to all those who were directly or indirectly involved. 
|
_________________________________________________________________________________________________________________________________________________________________________________________________________________ |
|
|
|