Modelo de processo
Definição de um processo
O termo processo é frequentemente mal utilizado em contextos de gestão de serviços. Definido como "uma série de actividades que são significativas para o cliente, com uma meta específica", um processo deve limitar-se apenas a actividades.
Requisitos para processos
Para definir uma arquitectura de processos, precisamos de mais do que apenas esta definição simples. O USM especifica 10 requisitos que devem ser realizados para um processo, antes de podermos realmente chamá-lo de processo e tratá-lo como tal:
- Um processo descreve o que tem de acontecer sucessivamente, não quem ou como.
- Um processo pode ser interpretado com um verbo.
- Um processo pode ser contado.
- Os processos não dependem de condições práticas (◊).
- Os processos têm um propósito único e relevante para o cliente.
- Um processo pode ser dividido em subprocessos, sem que isso altere o processo.
- Um modelo de processo organiza os processos.
- Um modelo de processo integral inclui todas as actividades de gestão de serviços.
- Num modelo de processo integrado, cada actividade ocorre apenas uma vez.
- Todas as actividades são dirigidas utilizando o controlo de processos.
Processos versus práticas
Se testarmos os 'processos' de todos os referenciais, standards e arquitecturas de referência existentes em relação a estes 10 requisitos, podemos demonstrar que todos eles descrevem combinações de pessoas, processos e tecnologias: o quê, o quem e o como. Portanto, todos eles falham no primeiro dos 10 requisitos. Na verdade, eles descrevem práticas, e práticas não são processos: práticas são derivadas de processos, adicionando o quem e o como ao o quê. A grande maioria também falha no requisito 5: não são orientados para o cliente. A maioria destes processos são assuntos internos do prestador de serviços e, como tal, são apenas parte dos processos orientados para o cliente. Além disso, quando as pessoas utilizam BPMN ou qualquer outra das chamadas técnicas ou produtos de 'modelação de processos de negócio' que utilizam 'swimlanes', especificam papéis e documentos, falhando no requisito 1.
O e-book "Demystifying the term PROCESS" explica isso detalhadamente.
Criar o modelo de processos com apenas cinco processos
Remover todos os quem e como destas práticas leva-nos ao material central de uma arquitectura de processos: apenas o o quê.
A reformatação do conjunto restante de actividades, de forma a que o resultado cumpra os restantes 10 requisitos, conduz a um modelo de processo orientado para o cliente, integral, integrado e não redundante para a gestão de serviços.
Nesse modelo de processo, encontramos apenas cinco processos que são independentes da linha de negócio da organização. Quatro desses processos são reativos: são acionados externamente, pelo cliente. Esses processos reativos são usados para responder à procura do cliente. O processo concreto envolvido numa interação pode ser determinado com a Árvore de Decisão de Processos USM.
- Acordar (Gestão de Contratos - CTM): elaborar e manter acordos de serviço e orientar a sua implementação. Este processo diz respeito tanto aos acordos de serviço com os clientes como aos acordos com fornecedores externos e com equipas de solução internas que contribuem para o serviço. A chamada correspondente é denominada desejo, que inclui o conceito de reclamação. O desejo atua como o acionador do processo. 'Acordar' aciona sempre 'Alterar', para a implementação do acordo novo ou atualizado.
- Alterar (Gestão de Alterações - CHM): o desenvolvimento e a libertação controlados de alterações à infraestrutura do serviço acordado. Este processo está relacionado com a facilitade e/ou o suporte, na medida em que faz parte da infraestrutura gerida. A chamada associada é denominada pedido de alteração (RFC). O pedido de alteração atua como o acionador do processo. 'Alterar' aciona sempre 'Operar' para a implementação da infraestrutura atualizada.
- Recuperar (Gestão de Incidentes - INC): a reparação e recuperação do serviço conforme acordado (essencialmente não o tão rápido quanto possível mas o tão rápido quanto acordado). Este processo diz respeito tanto a falhas como a falhas iminentes de qualquer dimensão, incluindo desastres. A chamada correspondente é denominada incidente (ou reporte de falha). O incidente atua como o acionador do processo. 'Recuperar' desencadeia 'Alterar' ou 'Operar', dependendo se é necessário ou não um ajuste da infraestrutura gerida.
- Operar (Gestão de Operações - OPS): a execução planeada de todas as acções operacionais para o serviço acordado e a monitorização do desempenho da infraestrutura e de todos os seus componentes. A chamada correspondente é denominada pedido de serviço (ou pedido de operações). O pedido de serviço atua como o desencadeador do processo.
Um dos cinco processos é proativo: é desencadeado internamente, pela organização do prestador de serviços. Este processo proativo visa melhorias estruturais nos serviços prestados, gerindo todas as ameaças e inovações para a entrega do serviço.
- Melhorar (Gestão de riscos - RIM): a prevenção de efeitos prejudiciais para os serviços acordados (mitigando ameaças), bem como a promoção de melhorias estruturais nos serviços acordados (fomentando inovações). A chamada correspondente é denominada risco. O risco age como o desencadeador do processo. 'Melhorar' pode desencadear 'Acordar', 'Alterar' ou 'Operar', dependendo do tipo de medida que deve ser implantada para mitigar o risco. O processo 'Melhorar' não é desencadeado por outros processos, mas apenas por pessoas: em termos do modelo de processo, é 'auto-desencadeante'. As pessoas submetem riscos, mas os riscos também são procurados ativamente. A parte interessada directa aqui é a própria organização do prestador de serviços. O cliente é apenas uma parte interessada indirecta: todas as melhorias acabarão por melhorar a entrega do serviço.
Num modelo de processo que cumpre todos os 10 requisitos, o desempenho é alcançado com fluxos de trabalho: fluxos compostos de actividades, que consistem em fragmentos não sobrepostos de processos individuais do modelo de processo integrado. Por exemplo, uma acção de recuperação pode ser realizada através de uma alteração ou reinicialização de alguma infraestrutura, mas em ambos os casos a execução é realizada num único processo: Gestão de Operações. Isto cria um controlo inequívoco sobre a entrega real do serviço e evita conflitos.
Esta modelagem de processos integrada única para prestadores de serviços pode ser facilmente aprendida, aplicada e suportada com ferramentas, usando no máximo 8 templates de fluxos de trabalho USM standardizados para todas as suas actividades de gestão de serviços. Imagine a redução na complexidade e no custo que poderá conseguir com um sistema de gestão como este.
Standardização do layout de um processo
Todos os processos têm o mesmo layout básico e, consequentemente, todos os processos também têm actividades semelhantes. No início e no final de cada processo, encontramos sempre as mesmas actividades semelhantes: iniciar e terminar o processo. Os processos diferem principalmente num aspecto: o propósito do processo relacionado com o cliente e, com isso, diferem na natureza do processo. Essa diferença manifesta-se nas actividades no corpo do processo.
Na imagem abaixo, as actividades no corpo de cada processo são indicadas com a sua cor. Nessa imagem, as actividades semelhantes (mas não «idênticas») são cinzentas. Os detalhes das actividades do corpo são tratados por processo no USM book.
A cooperação entre os componentes do modelo de processos
Devido à não redundância dos processos, cada processo (excluindo OPS) requer um ou mais dos restantes para completar um desempenho necessário. Portanto, cada um dos processos (excluindo OPS) é dividido em duas secções: a secção inicial que aciona o bloco de processo seguinte e as secções que fecham o processo administrativamente. As setas na imagem abaixo demonstram como os blocos de processo se acionam mutuamente.
A consequência desta não redundância e dependência interna entre blocos de processos leva ao the concept of USM workflows, com resultados surpreendentes.
