As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Fluxo de trabalho operacional
O fluxo de trabalho operacional dá suporte à base técnica e aos fluxos de trabalho da jornada do usuário. A maioria das atividades não técnicas que são cruciais para o sucesso geral da migração fazem parte desse fluxo de trabalho.
Esse fluxo de trabalho envolve decisões que podem ser alteradas ou revertidas com pouco esforço ou impacto. As especificações do produto baseadas em como as pessoas trabalham e se envolvem raramente estão corretas na primeira vez, pois há muitas partes interessadas e vozes a serem consideradas. É importante se engajar desde o início e consultar amplamente e com frequência, portanto, uma abordagem ágil e iterativa faz sentido para esse fluxo de trabalho. Você começa com um rascunho inicial de um modelo operacional ou materiais de treinamento e repete com frequência e rapidez para chegar ao produto final.
O fluxo de trabalho operacional consiste em cinco fases: governança do projeto, alinhamento, definição do modelo operacional, introdução do serviço e treinamento.
Governança do programa
As atividades de governança do programa ocorrem durante todo o cronograma de um projeto de migração. Independentemente do estágio em que o projeto se encontra, as atividades devem ser regulares (reuniões recorrentes programadas), transparentes (a equipe do projeto tem a oportunidade de abordar riscos e questões com franqueza) e com governança engajada (os líderes estão capacitados e dispostos a tomar decisões ou escalar adequadamente). Elas são vitais para destacar e resolver problemas de forma rápida e eficaz.
Alinhamento
Essa é a primeira atividade formal do projeto e se concentra em alinhar o escopo do projeto aos resultados comerciais. O alinhamento oferece uma oportunidade de validar e ajustar planos e estimativas anteriores com base em discussões com as partes interessadas.
As principais ações durante essa atividade incluem:
-
Descubra casos de uso de clientes de alto nível, pontos problemáticos técnicos e comerciais atuais e oportunidades de melhoria.
-
Discuta e concorde com os resultados comerciais desejados, determine suas prioridades relativas e identifique os critérios de sucesso.
-
Desenvolva um design de solução de alto nível, usado para definir opções de escopo e tecnologia nessa fase inicial. Esse design de alto nível fornece orientação para acelerar as atividades de design de baixo nível em fases posteriores.
-
Valide os cronogramas e os custos de implementação.
Definição do modelo operacional
As atividades nesta fase definem quem usará a solução de central de atendimento e como a solução será gerenciada. O modelo operacional não é um documento processual, um runbook ou um arquivo de configuração. Por exemplo, ele não deve explicar como extrair logs e anexá-los a um tíquete de suporte, nem fornecer capturas de tela desse procedimento. Em vez disso, ele deve identificar quem deve extrair os logs e para qual fila ou fornecedor eles devem ser enviados.
A definição do modelo operacional deve incluir:
-
Uma matriz responsável, responsabilizável, compatível, consultada e informada (RASCI), para que cada equipe entenda seus perfis e responsabilidades e como interagirão com outras equipes. A seguir está um trecho de uma matriz RASCI.
-
Fluxos de processo que definem as end-to-end atividades e quem é responsável por cada atividade. Por exemplo, deve haver um fluxo de processo para engajar o out-of-hours suporte para que fique claro quem é chamado, o que acontece se eles não puderem ser contatados, quem registra o ticket de suporte e como a importância do negócio é avaliada. Outro exemplo é a mensagem de emergência na fila. O fluxo do processo deve mostrar quem decide que ele precisa ser iniciado e quais dados eles devem usar para tomar essa decisão.
O modelo operacional geralmente é definido na segunda metade de um projeto, porque você precisa finalizar o design da solução e as jornadas do usuário antes de definir os processos para gerenciá-los com precisão. No entanto, recomendamos que você alinhe as partes interessadas no início do processo e reserve seu tempo para as fases posteriores do projeto.
Reúna exemplos de documentos semelhantes da sua organização que você possa usar como modelos. Isso facilitará a revisão e a aprovação pelas partes interessadas, pois a estrutura do documento será familiar para elas.
Certifique-se de que suas partes interessadas aprovem o modelo operacional antes que sua nova central de atendimento entre em produção, e faça com que seja um requisito para sua decisão de entrar em operação. Cada membro da equipe precisa entender seu perfil e o processo de operação da central de atendimento no ambiente de produção.
Introdução ao serviço (SI)
As atividades de SI implementam as mudanças definidas no modelo operacional. Pense na definição do modelo operacional como as fases de design e criação do novo modelo, e o SI como a fase de implantação do modelo operacional.
A equipe de SI geralmente é uma equipe dedicada em sua organização e trabalha de forma independente da equipe do projeto. O projeto deve passar pelos critérios e listas de verificação da equipe de SI antes de receber aprovação para ser lançado. Por exemplo, as listas de verificação incluem resultados do teste de aceitação do usuário (UAT) e a confirmação de que um evento conflitante (como um congelamento de alterações ou outro evento programado para lançamento) não está ocorrendo no mesmo dia em que o projeto é lançado, que os usuários têm o treinamento necessário e que as equipes operacionais estão prontas para prosseguir.
Não deixe as atividades de SI para o final do projeto. Envolva a equipe de SI no início do projeto e inclua-a em sua lista de distribuição para obter a documentação do projeto. O envolvimento precoce garante que a equipe de SI possa ajudar na preparação para a entrada em operação, como ajudar a selecionar o plano de AWS suporte
Treinamento
Criar materiais de treinamento e conduzir sessões de treinamento bem frequentadas são vitais para o sucesso das migrações. A tecnologia pode funcionar perfeitamente, mas se os usuários não souberem atender chamadas e realizar suas tarefas diárias, a migração será considerada uma falha.
As atividades de treinamento podem incluir treinamento direto de usuários, treinamento de instrutores, treinamento para supervisores, treinamento para equipe de suporte e treinamento para administradores de sistemas ou proprietários de produtos. Cada organização é única, então algumas opções podem ser mais adequadas à cultura do que outras.
Nós recomendamos uma abordagem treine o treinador que envolva a equipe de treinamento interna da sua organização. Sua equipe conhece a cultura da sua organização e o formato e as técnicas de treinamento que melhor se adequam aos seus usuários. Os membros da equipe do projeto podem assumir perfis de especialistas no assunto (SME) para fornecer materiais técnicos (como manuais do usuário, manuais do console do administrador e guias de tela) que podem ser usados como material de origem para as sessões de treinamento do instrutor. Se sua organização não tiver uma equipe de treinamento, o projeto SMEs deve treinar supervisores e liderar a equipe de suporte, que podem então treinar os usuários do contact center.
Também recomendamos que os administradores de sistemas e proprietários de produtos façam cursos formais de treinamento de produtos ministrados por instrutor para obter uma compreensão mais profunda do ambiente da AWS e console do Amazon Connect, para que eles possam usar os recursos do produto e solucionar problemas de forma eficaz.
