# Método PEXOR

O **PEXOR** é o método operacional da Rise para transformar processos soltos em fluxos claros, executáveis e replicáveis.

Ele serve para três coisas ao mesmo tempo:

* encontrar gargalos reais;
* publicar o fluxo padrão no GitBook;
* transformar a rotina em tarefa template no Rise OS.

> O PEXOR não é um projeto pontual. Ele é um ciclo contínuo de melhoria.

***

### Quando usar

Use o PEXOR quando:

* um processo depende demais de uma pessoa;
* existem retrabalhos, atrasos ou handoffs confusos;
* a equipe executa a mesma rotina de formas diferentes;
* uma área precisa criar um novo playbook;
* um fluxo já funciona, mas ainda não escala.

***

### As 5 fases do ciclo

{% stepper %}
{% step %}

### 1. Perceber

Diagnostique o fluxo atual.

Mapeie:

* objetivo do processo;
* gatilho de início;
* etapas reais;
* responsáveis por etapa;
* dependências;
* gargalos;
* exceções recorrentes.

**Saída esperada:** fluxo atual documentado e lista priorizada de gargalos.
{% endstep %}

{% step %}

### 2. Estruturar

Desenhe o fluxo ideal.

Defina:

* owner do processo;
* entradas e saídas por etapa;
* critérios de passagem;
* SLA de cada fase;
* pontos de decisão;
* escalonamentos;
* ferramentas envolvidas.

**Saída esperada:** fluxo padrão com governança clara.
{% endstep %}

{% step %}

### 3. Executar

Coloque o fluxo em produção.

A execução inclui:

* publicação do playbook no GitBook;
* criação das tarefas template no Rise OS;
* alinhamento com o time executante;
* definição da data de entrada em vigor.

**Saída esperada:** playbook publicado e rotina pronta para uso.
{% endstep %}

{% step %}

### 4. Otimizar

Meça o que acontece no uso real.

Revise:

* tempo por etapa;
* volume travado;
* erros recorrentes;
* dúvidas frequentes;
* feedback do time.

**Saída esperada:** backlog de melhoria e versão revisada do playbook.
{% endstep %}

{% step %}

### 5. Replicar

Transforme o fluxo validado em template escalável.

Replicar significa:

* reaplicar a lógica em outra vertical;
* adaptar o playbook sem perder o padrão;
* reaproveitar estrutura, checklist e tarefas template.

**Saída esperada:** modelo pronto para novos processos e novas áreas.
{% endstep %}
{% endstepper %}

***

### Entregáveis mínimos de um ciclo PEXOR

Cada ciclo deve gerar, no mínimo:

1. **Diagnóstico do fluxo atual**
2. **Mapa do fluxo futuro**
3. **Responsáveis, SLAs e handoffs definidos**
4. **Playbook publicado no GitBook**
5. **Tarefas template criadas no Rise OS**
6. **Checklist de revisão e melhoria contínua**

Se algum item faltar, o ciclo ainda não terminou.

***

### O que precisa existir em todo playbook novo

Antes de publicar um novo playbook, valide estes pontos:

* objetivo do fluxo em uma frase;
* início e fim do processo bem definidos;
* responsáveis por cada etapa;
* entradas e saídas explícitas;
* SLA ou prazo esperado;
* critérios de aprovação, devolução ou escalonamento;
* exceções mais comuns;
* ferramenta onde a execução acontece;
* indicador simples para acompanhar performance.

{% hint style="warning" %}
Não documente o processo idealizado. Documente o processo que a equipe consegue executar com consistência.
{% endhint %}

***

### Como transformar um gargalo em playbook

{% stepper %}
{% step %}

### 1. Escolha o gargalo certo

Priorize fluxos com maior impacto em prazo, receita, risco ou experiência.
{% endstep %}

{% step %}

### 2. Rode a sessão de diagnóstico

Reúna quem opera o processo no dia a dia.

O foco é entender o fluxo real. Não a versão teórica.
{% endstep %}

{% step %}

### 3. Desenhe o fluxo padrão

Simplifique etapas, elimine ambiguidade e defina owners.
{% endstep %}

{% step %}

### 4. Publique e operacionalize

Suba o playbook no GitBook e crie a rotina correspondente no Rise OS.
{% endstep %}

{% step %}

### 5. Revise após uso real

Depois das primeiras execuções, ajuste o que travou e publique a nova versão.
{% endstep %}
{% endstepper %}

***

### Papéis no ciclo PEXOR

**Owner da vertical**

* responde pelo processo;
* aprova o fluxo final;
* cobra adoção.

**Operadores do processo**

* descrevem a rotina real;
* apontam exceções e gargalos;
* validam se o playbook é executável.

**Responsável pela documentação**

* transforma o fluxo validado em playbook claro;
* organiza versão, estrutura e atualização.

**Stakeholders consultados**

* entram quando há impacto regulatório, financeiro, técnico ou comercial.

***

### Cadência recomendada

Uma cadência simples funciona melhor:

* **Diagnóstico inicial:** 60 a 90 minutos
* **Desenho do fluxo padrão:** 60 minutos
* **Publicação e ativação:** até 5 dias úteis
* **Primeira revisão:** entre 15 e 30 dias após entrada em uso
* **Revisões seguintes:** sempre que houver mudança relevante no processo

***

### Como o PEXOR se conecta ao ecossistema Rise

O método fecha o ciclo em dois ambientes:

* **GitBook** — onde o fluxo fica documentado, consultável e versionado.
* **Rise OS** — onde a execução recorrente vira tarefa template.

A documentação explica **como operar**.

A tarefa template garante **como repetir**.

***

### Cobertura do método

O PEXOR é transversal. Ele pode ser aplicado em qualquer vertical da Rise, incluindo:

* Jurídico
* Financeiro
* Marketing
* Comercial
* Tecnologia
* Recursos Humanos

***

### Próximo passo

Depois de estruturar um fluxo com PEXOR, conecte o conteúdo à arquitetura já usada no [Visão Geral do Playbook Operacional](/internal/playbook/visao-geral-do-playbook-operacional.md).

Assim o playbook novo nasce no mesmo padrão das demais áreas e fica mais fácil de manter, revisar e replicar.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://rise-finance-2.gitbook.io/internal/playbook/metodo-pexor.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.