1. O ticket será encaminhado primeiramente  para os analistas de suporte RH da equipe SMART eSocial, quando o cliente informar no Catálogo de Serviços que trata-se de eSocial e se houver contrato registrado do produto SMART eSocial. Este processo deve ser automático via sistema.

2. A priorização dos incidentes deverá seguir as diretrizes definidas nos tempos de atendimento previstos no Catálogo de Serviços.

3. No caso do incidente não constar em nossa base de conhecimento, o analista de suporte RH deverá avaliar a natureza da ocorrência, abrir um ticket filho para atuação interna e realizar a analise sobre a ocorrência.

4. No caso do analista de suporte RH identificar um possível problema no produto SMART eSocial, o mesmo deverá acionar os times de TAF/TSS e/ou Cloud para continuidade da analise e direcionamento do incidente. Caso o incidente esteja relacionado à um erro de produto, deverá ser aberto uma issue de não conformidade ao time de desenvolvimento. Após conclusão, a equipe de suporte encaminhará a ocorrência ao analista de testes para homologação final e montagem das RDM’s para a devida aplicação de sua solução.

5. Todas as propostas de solução deverão estar disponibilizados a todos os analistas do time SMART eSocial, para provimento de informações na aplicação das soluções.

6. Todo incidente com a solução aplicada deverá ser devidamente registrado na ferramenta de atendimento e ter seu status atribuído como "Resolvido" (ticket filho).

7. O incidente resolvido deverá ser enviado aos clientes solicitantes para a sua validação final, mantendo o ticket pai com o status de “Resolvido”.

8. Todo incidente com status “Resolvido” será fechado automaticamente em até 60 horas úteis, considerando o expediente das 07:00hrs as 19:00hrs.

9. Em incidentes críticos, a validação poderá ser realizada pela equipe de suporte via telefone/conexão remota, nesse caso deverão ser respeitados os seguintes limites de tentativa de contato para validação: 3 tentativas dentro de 3 dias, gerando evidências das tentativas de contato.

10. Incidentes classificados como “Críticos” deverão seguir a Regras de Escalonamento definidas.

11. Caso seja necessária a abertura de uma Mudança para a solução de um incidente, fica sob a responsabilidade do analista de testes/gestão de mudança a abertura e acompanhamento da mudança.

12. O processo de validação das soluções deverá ser executado entre o coordenador de suporte e gestor de mudança, com o objetivo de identificar possíveis novos incidentes afim de previni-los.

13. Os tickets só poderão ser reabertos dentro do período de 60 horas com o status “Resolvido”, após isto, somente será possível abrir um acompanhamento do incidente.

• Ferramenta para abertura de ticket → ZENDESK (suporte.totvs.com)

  • Ferramenta para atendimento dos ticket (zendesk)

  • Catálogo de Serviços (zendesk)

• Ferramenta para consulta e manipulação das configurações dos ambientes Smart eSocial

  • Rancher (rancher.smartfiscal.info)

• Ferramenta para criação de ambiente

  • GraphiQL (taf-launcher.prd.cloud104.io/graphiql e taf-launcher.hmg.cloud104.io/graphiql)

• Ferramenta para consulta e dos dados dos ambientes Smart eSocial.

  • Ferramentas Protheus (app-xxxxx.ke04.smartfiscal.info)

  • LogDNA (app.logdna.com)

• Dash de status dos atendimentos ao cliente:

  • https://analytics.totvs.com.br/#s=/gdc/projects/rcvjipv0i90nyvhzbq3biglhuln8ar7f|projectDashboardPage|/gdc/md/rcvjipv0i90nyvhzbq3biglhuln8ar7f/obj/24274|a42bd84a6e96

• Ferramenta para consultar a saúde dos ambientes

  • UPTIME ROBOT (uptimerobot.com/dashboard#mainDashboard)

Cada TOPOLOGIA conterá 9 PODs, sendo:

• Protheus-Appserver

  • Produção

  • Homologação

  • Update (somente é utilizado no momento da atualização do ambiente)

• Protheus-Dbaccess

• Protheus-LicenseServer

• Protheus-Lockserver

• Protheus-Status

• Protheus-TSS

• Protheus-Webservice

  • Produção

  • Homologação

Product Owner SMART

Horário de trabalho estimado: Comercial

Responsável pelo gerenciamento, manutenção e melhorias do produto SMART. Deverá manter os artefatos (Metadados, Repositório, Binários e etc.) e será o responsável pelas aprovações das RDM’s e do encaminhamento dos RDM’s para o comitê de mudança.

Coordenador de Suporte

Horário de trabalho estimado: Comercial

Gerenciar e Coordenar os processos com eficiência e eficácia, garantido que as diretrizes definidas sejam seguidas pelos analistas de suporte. Deve produzir análises e estatísticas gerenciais, acompanhar os indicadores do processo de suporte e acompanhar a evolução dos ambientes do cliente.

Líder de Suporte

Horário de trabalho estimado: Comercial

Gerenciar e liderar os processos com eficiência e eficácia, garantido que as diretrizes definidas sejam seguidas pelos analistas de suporte. Deve contribuir na produção da análises e estatísticas gerenciais, acompanhar os indicadores do processo de suporte, fazer a gestão do time de suporte e será o ponto de contato para demandas do time.

Dois Analistas de Suporte RH

Horário de trabalho estimado: Comercial

• 1 Analista de Suporte Labore
• 1 Analista de Suporte HCM

Serão responsáveis por receber e avaliar as ocorrências abertas, assim como posicionar o cliente sobre as atividades que estão em execução, provendo a solução dos incidentes aos clientes, seguindo as diretrizes relacionadas aos processos. Estes analistas deverão ter conhecimento em processos de suporte para o tema de e-Social. Também deverão ter conhecimento de como funciona os processos de Webservices para comunicação entre os sistemas TOTVS DS/RM com TAF.

Dois Analistas de Suporte TAF/TSS

Horário de trabalho estimado: Comercial

Serão responsáveis pela analise das ocorrências abertas pelo time de suporte RH. Deverá executar os processos de suporte no produto SMART eSocial e reportar todas as ocorrências de produto encontradas para o time de desenvolvimento do produto SMART eSocial.

Estes analistas deverão ter conhecimento em processos de suporte para o tema de e-Social. Também deverão ter conhecimento no mecanismos de comunicação entre os ERPs e TAF/TSS e integração com o governo.

Dois Analistas de Suporte Cloud

Horário de trabalho estimado: Comercial (7hrs às 19hrs) + Stand-by em horário estendido (6hrs às 7hrs e 19hrs à 24hrs) – semana e sábados, domingos e feriados. As quinta-feira, horário de revezamento entre as 0hr às 6hrs.

Serão responsáveis pelo gerenciamento e manutenção da infraestrutura dos clientes SMART eSocial, assim como o responsável pela aplicação das mudanças nestes ambientes mediante aos RDM’s aprovados. Estes analistas deverão ter conhecimento em processos de suporte e da infraestrutura utilizada para este projeto. Devem ser capazes de auxiliar na resolução de problemas com a infraestrutura e também o time de suporte e de produto no sentido de duplicar/restaurar e mantenir ambientes e etc.

Um Analista de testes

Horário de trabalho estimado: Comercial

Analista responsável pelo processo de qualidade e montagem das RDM’s para envio ao gestor de mudança. Este analista deverá ter conhecimento em processos de qualidade e da arquitetura do Protheus para homologação de todos os artefatos do ambiente e correções disponibilizadas para o produto SMART eSocial. Também deverá ter conhecimento no processo de execução do ROBÔ de teste do Protheus e deverá auxiliar o time de produto na montagem de novos casos de testes.

Um Analista de desenvolvimento

Horário de trabalho estimado: Comercial

Analista responsável pelo processo manutenção do produto e integrante do time de desenvolvimento SMART eSocial para acompanhamento e estabilização do produto. 

1. Todas as mudanças normais e emergenciais serão iniciadas com o registro na ferramenta zendesk através do preenchimento do formulário para mudanças (RDM).
2. Todas as mudanças deverão ser classificadas pelo Tipo:
3. Mudanças Normais deverão ser enviadas ao gerente de mudanças para a avaliação, categorização e classificação das mudanças.
4. Mudanças Emergenciais, os gestores de mudanças deverão ser comunicados antes da execução da mesma, o mesmo ficará responsável por buscar as aprovações necessárias para a execução.
5. A priorização de Mudanças deverá seguir os Critérios de Priorização. (Anexo II)
6. O gestor de mudança ficará responsáveis pela aprovação e avaliação da necessidade de envolvimento do comitê de mudanças junto com o solicitante.
7. O solicitante da mudança emergencial em conjunto com o gestor de mudança deverá envolver os responsáveis pela execução da mudança para planejamento das atividades básicas de homologação e plano de retorno (Rollback).
8. Todas as mudanças normais deverão passar por uma análise de viabilidade técnica que poderá envolver o time de suporte, agentes de mudança, fornecedores cloud e o gerente de mudança. No caso de a mudança ser vetada, o gestor de mudança tem a função de notificar a recusa ao grupo solicitante.
9. Após aprovado o plano de execução das mudanças o gestor de mudança tem a função de submeter a mudança para a execução seguindo as definições do fluxo do processo.
10. O comitê de mudanças terá a responsabilidade de avaliar os impactos que a mudança poderá causar ao negócio, apoiando-se nos níveis de serviços estabelecidos, no impacto em outros serviços e nos negócios, priorizar a execução das mudanças e aprovar o plano de comunicação de execução e avaliar os resultados das mudanças com base no histórico para avaliar pontos de melhoria.
11. As execuções serão iniciadas a partir do processo de Gerenciamento de Mudanças, com os agentes de mudança e se necessário fornecedores atuando na implementação.
12. Para o planejamento das mudanças, o gestor de mudança será responsável por avaliar os requisitos técnicos solicitados pelas mudanças podendo consultar os agentes de mudança e os fornecedores propondo um planejamento para a execução da mudança solicitada.
13. Deverá ser registrado na RDM um parecer técnico das necessidades para a execução.
14. No planejamento da execução os grupos de solução deverão dimensionar o tempo estimado para a implementação da execução.
15. Os agentes de mudança ou fornecedores envolvidos na mudança deverão prever e garantir as atividades de retorno ao estado original do ambiente relacionado à execução e o tempo previsto para retornar à situação anterior à implementação, caso a mudança seja implementada com falhas.
16. A Janela de implementação deverá respeitar as definições estabelecidas pela TOTVS.
17. As mudanças emergenciais serão realizadas sob demanda. Sempre que houver um problema grave impactando os clientes.
18. As atividades de emitir detalhes técnicos e preparar mudança deverão ser executadas respeitando os fluxos e atividades da equipe Smart eSocial.
19. Membros do Comitê:
20. Membros Fixos CM: Gestor de Mudança, Gestor de suporte do segmento de services, Diretor do segmento de services, Coordenador de suporte responsável pelo time Smart eSocial e demais envolvidos nas RDMs.
21. Membros Fixos Gestor de Mudança, Gestor de suporte do segmento de services, Diretor do segmento de services, Coordenador de suporte responsável pelo time Smart eSocia
22. Critério para aprovação
    1. CM: Consensual.
    2. CME: Consensual.
23. Datas e Horários das Reuniões de Comitê:
24. O comitê de mudança acontece uma vez por semana, sendo, Terça-feira. das 14:00hrs às 16:00hrs.
25. Em caso de feriados a substituição deve ser programada com antecedência pelo gestor de mudanças. Horário de entrega para os comitês: limite até às 10hrs do dia da reunião com a(s) RDM(s) preenchida.
26. As mudanças ocorrerão uma vez por semana, na madrugada de quinta-feira das 00:00hr às 06:00hs.
    1. No caso de mudanças emergenciais, poderá ocorrer em qualquer horário, desde que, todos os clientes estejam cientes da indisponibilidade da ferramenta durante o período de atualização;
    2. O gestor de mudança deverá avaliar se poderá aplicar as RDMs dentro do calendário estipulado (anexo V). Em casos de fatores externos, como: alterações no produto de alto impacto, processos de fechamentos dos clientes, alterações de regras do governo e etc.o gestor de mudança poderá flexibilizar a janela, submetendo-a ao CM. Caso a alteração seja permanente, o gestor de mudança deverá alterar este documento e submete-lo ao CM.

FERRAMENTAS

• Ferramenta para abertura de mudanças (Template de RDM)

• Ferramenta para aprovações automáticas (Ainda em estudo de implantação)

• Ferramenta para gerenciamento dos ambientes do cliente

  • RANCHER

• Ferramenta de snapshot dos ambientes para execuções de rollback

  • Em construção

• Ferramenta para consulta e manipulação das configurações dos ambientes Smart eSocial

  • RANCHER