Design de serviços
Processo end-to-end para desenhar serviços com utility e warranty: Service Design Package, 4 dimensões, UX e SLAs
Descarregar pack completoÂmbito e objectivos
Desenhar produtos e serviços adequados ao propósito (utility) e ao uso (warranty), que possam ser entregues pela organização e pelo seu ecossistema. Definição ITIL: "Design products and services that are fit for purpose and use, and that can be delivered by the organization and its ecosystem."
Novo serviço a desenvolver, alteração significativa a um serviço existente, requisito de negócio identificado ou resultado de uma iniciativa de melhoria contínua.
Desde a análise de requisitos de negócio até à produção do Service Design Package (SDP), cobrindo as 4 dimensões do serviço: pessoas, processos, tecnologia e parceiros.
Implementação técnica (build/deployment) e gestão operacional do serviço (operate/support). O design termina com o SDP aprovado e a transição para a equipa de build.
SDP completo e aprovado, contendo: requisitos funcionais e não-funcionais, arquitectura do serviço, SLAs e OLAs definidos, requisitos de segurança, plano de capacidade, plano de continuidade, plano de testes, plano de transição e critérios de aceitação.
O Service Design Package (SDP)
O SDP é o principal deliverable do processo de design de serviços. É o documento que descreve todos os aspectos de um serviço ao longo do seu ciclo de vida e que serve de base para a transição e operação. Um SDP incompleto é a principal causa de falhas em novas implementações de serviços.
| Secção do SDP | Conteúdo | Responsável |
|---|---|---|
| Requisitos de negócio | Objectivos, casos de uso, stakeholders e critérios de sucesso | Service designer / Service owner |
| Arquitectura do serviço | Componentes técnicos, integrações, infraestrutura e dependências | Arquitectura / Técnicos |
| SLAs e OLAs | Targets de disponibilidade, desempenho, tempo de resposta e suporte | Service level manager / Service owner |
| Requisitos de segurança | Controlos, classificação de dados, conformidade e gestão de acessos | Segurança / Service designer |
| Plano de capacidade | Volumes previstos, crescimento, escalabilidade e dimensionamento | Gestão de capacidade / Arquitectura |
| Plano de continuidade | RTO, RPO, cenários de falha e procedimentos de recuperação | Service designer / Arquitectura |
| Plano de testes | Critérios de aceitação, UAT, testes de performance e segurança | Service designer / Técnicos |
| Plano de transição | Sequência de actividades para passar do design ao build e à operação | Service designer / Service owner |
| Critérios de aceitação | Condições mensuráveis que o serviço deve satisfazer antes do go-live | Service owner / Service designer |
Diagrama do processo
Diagrama BPMN simplificado do processo de design de serviços (3 swimlanes). Percorra horizontalmente em dispositivos móveis.
Actividades macro
| # | Actividade | Responsável | Input | Output |
|---|---|---|---|---|
| 1 | Análise de requisitos de negócio | Service designer | Requisito de negócio, business case, estratégia de serviço | Requisitos documentados, stakeholders identificados |
| 2 | Definição de requisitos funcionais e não-funcionais | Service designer / Arquitectura | Requisitos de negócio, restrições técnicas | Lista de requisitos funcionais e NFR (disponibilidade, capacidade, segurança, continuidade) |
| 3 | Design da arquitectura do serviço | Arquitectura / Técnicos | Requisitos funcionais e NFR | Arquitectura técnica, componentes, integrações e dependências |
| 4 | Design da experiência do utilizador | Service designer | Requisitos de utilizador, personas, jornada do cliente | Service blueprint, fluxos de interacção, protótipos UX |
| 5 | Definição de SLAs e OLAs | Service level manager / Service owner | Requisitos de negócio, capacidade técnica | SLAs com o negócio, OLAs com equipas internas |
| 6 | Produção do SDP | Service designer | Todos os outputs das actividades anteriores | Service Design Package completo (rascunho para revisão) |
| 7 | Revisão e aprovação do design | Service owner / Service designer | SDP rascunho, feedback de stakeholders | SDP aprovado formalmente |
| 8 | Transição para build | Service designer | SDP aprovado | SDP entregue à equipa de build e transição |
| 9 | Revisão pós-implementação | Service designer / Service owner | Feedback pós-go-live, métricas iniciais de operação | Lições aprendidas, actualização do SDP, melhorias identificadas |
Descrição detalhada das actividades
A primeira actividade consiste em compreender o que o negócio precisa e traduzir essa necessidade em requisitos estruturados. Aplica-se a técnica de levantamento de requisitos junto dos stakeholders (entrevistas, workshops, análise documental) para garantir que nada fica por capturar antes de avançar para o design.
Técnicas utilizadas
- Entrevistas com stakeholders e utilizadores-chave
- Workshops de levantamento de requisitos
- Análise de processos de negócio existentes
- Revisão de documentação estratégica e business case
- Priorização com MoSCoW (Must, Should, Could, Won't)
Os requisitos funcionais descrevem o que o serviço deve fazer; os requisitos não-funcionais (NFR) descrevem como deve fazê-lo. Os NFR são frequentemente os mais críticos para garantir warranty: disponibilidade, capacidade, segurança e continuidade. Um serviço pode ser funcionalmente correcto mas falhar em warranty se os NFR forem ignorados.
Requisitos não-funcionais principais
- Disponibilidade: percentagem de tempo em que o serviço deve estar operacional (ex. 99,9%)
- Capacidade: volumes de transacções, utilizadores simultâneos, crescimento previsto
- Segurança: controlos de acesso, encriptação, conformidade regulatória (RGPD, ISO 27001)
- Continuidade: RTO (Recovery Time Objective) e RPO (Recovery Point Objective)
- Desempenho: tempos de resposta máximos em carga normal e pico
A arquitectura define a estrutura técnica do serviço: quais os componentes, como se relacionam, quais as integrações com outros sistemas e quais os fornecedores externos envolvidos. Considera as 4 dimensões ITIL: pessoas (quem suporta), processos (como opera), tecnologia (infraestrutura e software) e parceiros (fornecedores e integrações).
Padrões de arquitectura comuns
- Monolítico vs. microserviços para serviços de TI complexos
- On-premises vs. cloud vs. híbrido
- Active-active vs. active-passive para alta disponibilidade
- Integração via API REST ou mensageria para dependências externas
Um serviço tecnicamente correcto pode falhar se a experiência do utilizador for má. O design UX centra-se em como o utilizador interage com o serviço: fluxos de trabalho, interfaces, pontos de contacto e momentos de fricção. O service blueprint mapeia todos os touchpoints visíveis e invisíveis ao utilizador.
Princípios de UX para serviços ITSM
- Desenhar para o utilizador real, não para o utilizador ideal
- Minimizar o número de passos para completar uma tarefa
- Garantir consistência entre canais (portal, telefone, email)
- Tornar visíveis os estados do serviço (disponível, degradado, indisponível)
- Validar protótipos com utilizadores reais antes de finalizar o design
Os SLAs (Service Level Agreements) formalizam os compromissos com o negócio; os OLAs (Operational Level Agreements) formalizam os compromissos internos entre equipas de TI. Ambos devem ser negociados com base na capacidade técnica real, não em aspirações. Targets irrealistas são piores do que targets modestos alcançáveis.
Componentes típicos de um SLA
- Disponibilidade: percentagem mensal e janela de manutenção
- Tempo de resposta: para incidentes por prioridade
- Tempo de resolução: para incidentes por prioridade
- Suporte: horário de suporte, canais disponíveis
- Relatórios: frequência e formato dos relatórios de desempenho
- Revisão: periodicidade de revisão do SLA
O Service Design Package é o documento central do processo. Agrega todos os outputs anteriores num único deliverable coerente e completo. É o passaporte do serviço: sem um SDP completo, a equipa de build não tem informação suficiente para construir o serviço de forma correcta.
Verificação de completude do SDP
- Todos os requisitos (funcionais e NFR) estão documentados e priorizados
- Arquitectura técnica completa com diagramas
- SLAs e OLAs assinados ou em processo de aprovação
- Plano de capacidade com projecções a 1 e 3 anos
- Plano de continuidade com RTO e RPO definidos
- Plano de testes com critérios de aceitação mensuráveis
- Plano de transição com datas e responsáveis
A revisão formal do design envolve todos os stakeholders relevantes: service owner, equipas técnicas, segurança, gestão de capacidade e, quando aplicável, representantes do negócio utilizador. O objectivo é identificar lacunas, inconsistências ou riscos antes de avançar para o build, quando as alterações são mais baratas.
Passos chave
- Distribuir o SDP rascunho para revisão com prazo definido
- Realizar sessão de revisão estruturada (design review meeting)
- Registar comentários, questões e itens em aberto
- Resolver todos os itens em aberto antes da aprovação final
- Obter assinatura formal do service owner para aprovação
A transição formal entrega o SDP aprovado à equipa responsável pela construção e implementação do serviço. Este handover deve incluir uma sessão de briefing onde o service designer explica as decisões de design, os requisitos críticos e os critérios de aceitação, reduzindo o risco de má interpretação do documento.
Passos chave
- Convocar sessão de handover com a equipa de build
- Apresentar o SDP e explicar as decisões de design
- Clarificar os critérios de aceitação e os testes obrigatórios
- Definir canal de comunicação para questões durante o build
- Registar a entrega formal do SDP com data e destinatários
Após o go-live, o service designer revê o desempenho real do serviço face ao que foi desenhado. Esta revisão fecha o ciclo do processo e alimenta a melhoria contínua: identifica defeitos de design encontrados durante o build ou a operação inicial, actualiza o SDP com decisões tomadas durante a implementação e regista lições aprendidas para futuros projectos.
Passos chave
- Recolher feedback da equipa de build sobre o SDP (lacunas, ambiguidades)
- Comparar métricas iniciais de operação com os targets do SDP
- Identificar defeitos de design que surgiram em build ou testes
- Actualizar o SDP com as decisões finais tomadas durante a implementação
- Documentar lições aprendidas no repositório de conhecimento
Modelo RACI
| Actividade | Service designer (SD) |
Arquitectura (AR) |
Service owner (SO) |
SL manager (SLM) |
Segurança (SEC) |
|---|---|---|---|---|---|
| Análise de requisitos de negócio | R | C | A | I | - |
| Requisitos funcionais e NFR | R | R | A | C | C |
| Design da arquitectura | C | R | A | - | C |
| Design da experiência do utilizador | R | C | A | - | - |
| Definição de SLAs e OLAs | C | I | A | R | - |
| Produção do SDP | R | C | A | I | I |
| Revisão e aprovação do design | R | C | A | C | C |
| Transição para build | R | I | A | I | - |
| Revisão pós-implementação | R | C | A | I | - |
Métricas e KPIs
| Métrica | Descrição | Target sugerido |
|---|---|---|
| Designs concluídos no prazo | Percentagem de projectos de design entregues dentro do prazo acordado com o negócio | > 85% |
| Completude do SDP | Percentagem de secções obrigatórias do SDP preenchidas e aprovadas antes da transição para build | 100% |
| Defeitos de design em build/test | Número de defeitos encontrados durante o build ou testes que resultaram de erros ou omissões no design | < 3 por projecto |
| Satisfação com novos serviços | Classificação média dos utilizadores sobre a adequação do serviço às suas necessidades (inquérito pós-go-live) | > 4,0/5,0 |
| Tempo de requisito a SDP | Tempo médio entre a recepção do requisito de negócio e a entrega do SDP aprovado | Definido por projecto |
Interfaces com outros processos
Análise de negócio
Fornece os requisitos de negócio estruturados e o business case que desencadeiam o processo de design.
Build e desenvolvimento
Recebe o SDP aprovado como base para construir o serviço. O design define o que deve ser construído; o build implementa-o.
Gestão de níveis de serviço
Fornece os targets de SLA negociados com o negócio, que o design deve garantir que são tecnicamente alcançáveis.
Segurança da informação
Fornece os requisitos de segurança, conformidade e controlos que devem ser incorporados no design do serviço.
Gestão de capacidade
Fornece os requisitos de dimensionamento e escalabilidade com base nas previsões de carga e crescimento do serviço.
Catálogo de serviços
Após o go-live, o novo serviço é registado no catálogo com a descrição, SLAs e canais de acesso definidos no SDP.
Descarregar o pack completo
Inclui o processo documentado, template de SDP em Word, modelo RACI em Excel e checklist de revisão do design.