Revendo os vídeos do DCO Essentials 7.1 (vídeo Conducting a “Prep and Review” DCO Session) entendi o seguinte:

Um ESTILO de condução de DCO Session é o Prep & Review que tem 5 estágios:

> PREP:

- acontece apenas uma vez

- arquitetos da workstream preparam artefatos para revisão dos SMEs, revisando TODOS os requisitos e especificações para garantir que estão claros e/ou que o backlog de dúvidas esteja documentado.

- outputs consistem em drafts de especificações detalhadas, draft dos fluxos e UIs

> SESSION:

- acontece apenas uma vez, é o estágio onde a DCO Session ocorre, revisando todo o escopo do Business Case

- o output da PREP é apresentado e validado com os SMEs

- todos os feedbacks das espeficificações devem ser inputados diretamente no Pega

- feedbacks referentes a fluxos e UIs são feitos no Pega somente se não impactarem no tempo da sessão

- outputs consistem em especificações refinadas e acordadas entre todos os participantes, anotações sobre o refinamento  dos mockups dos fluxos e UI além do plano de follow up para itens extraordinários

> POST

- acontece tantas vezes quantas forem necessário, entre o delivery team

- o output é a atualização das especificações conforme o que foi levantado na Session

> PLAYBACK

- acontece tantas vezes quantas forem necessário, envolvendo os mesmos participantes da Session

- apresenta somente as alterações que foram feitas no estágio Post, evitando itens que já foram aprovados

- como na Session, todos os feedbacks das espeficificações devem ser inputados diretamente no Pega

- feedbacks referentes a fluxos e UIs são feitos no Pega somente se não impactarem no tempo da sessão

- sempre que houver feedback/alteração, uma nova Playback é agendada e somente os itens modificados devem ser apresentados

- ocorre até que os SMEs/stakeholders aprovem o business case para que o mesmo seja construído

> APPROVALS

- não fica claro exatamente quando ocorre, no meu entendimento é quando não há mais Playbacks para serem feitas

- o output é a aprovação de todos os artefatos como fluxos e UI

- pode gerar novas notas sobre itens que forem rejeitados, que deverão passar por planejamento da equipe para correção

BPM works best when all of the elements of the process can be accurately modeled. It allows the business to create structured, repeatable processes that are clearly documented and well-understood by the parties that need to execute them. This allows PRPC to “understand” the process, and even perform those steps that lend themselves well to automation – such as enforcing business policies, assigning tasks, and sending correspondence.

Case Management adds value by filling in the gaps when asynchronous, unanticipated, or unpredictable events affect the processing of work. This allows the business to create a more-flexible solution that processes work better than a BPM system.

When businesses combine the standardization of BPM with the flexibility of Case Management, they build solutions that return greater value than if they rely on either approach alone.

So, now that we have a better understanding of BPM and Case Management, what do we need to know about how PRPC solutions can leverage both?

By developing processes in accordance with BPM principles, we create repeatable, automatable processes that drive operational efficiency.

By implementing a solution as a case, we provide a framework to manage its workflow – not just the automatic processes, but also manual, optional, and conditional processes.

Since our solutions are implemented as cases, we can more easily spawn them from other cases, making it easier to manage tasks across the entire workflow.

We can report on the progress of each case – including subcases – separately, improving visibility into the flow of work.

Altogether, these capabilities provide a big picture view of the case – including its components – which we can’t get from just BPM alone.