ITIL 4 Specialist High-Velocity IT (HVIT) Português

Machine Translated by Google
XXXXXXXX
ITIL® 4:
TI de alta velocidade
eu
Publicado pela TSO (The Stationery Office), parte da Williams Lea, e

disponível em:
Online
www.tsoshop.co.uk
Correio, Telefone, Fax e E-mail

TSO
PO Box 29, Norwich, NR3 1GN
Pedidos por telefone/Informações gerais: 0333 202 5070
Pedidos por fax: 0333 202 5080 E-mail:
customer.services@tso.co.uk Textphone 0333 202 5077
TSO@Blackwell e outros Agentes Credenciados
AXELOS
Todos os detalhes sobre como entrar em contato com a
AXELOS podem ser encontrados em: https://www.axelos.com
Para mais informações sobre qualificações e acreditação de treinamento, visite: https://
www.axelos.com/certifications https://www .axelos.com/archived-pages/becoming-an-axelos-
partner/training-organization-and-trainer-accreditation Para todas as outras perguntas, envie um email para: ask@axelos.com
Direitos autorais © AXELOS Limited 2020
Todos os direitos reservados. Nenhuma parte desta publicação pode ser reproduzida de qualquer forma ou por qualquer meio sem permissão por escrito
da AXELOS Limited.
Os pedidos de reutilização, reprodução ou republicação de material nesta publicação devem ser enviados para a equipe de licenciamento em:
license@AXELOS.com Endereço da sede: 30 Berners Street, London, England, W1T 3LR
AXELOS, o logotipo AXELOS, o logotipo AXELOS swirl, AgileSHIFT®, ITIL®, MoP®, M_o_R®, MoV®, MSP®, P3M3®, P3O®, PRINCE2®, PRINCE2
Agile® e RESILIA® são marcas registradas de AXELOS Limitada.
Figura 3.7: A estrutura Cynefin está licenciada sob a licença não-portada Creative Commons Attribution-Share Alike 3.0 (https://
creativecommons.org/licenses/by-sa/3.0/) de https://commons.wikimedia.org/wiki/ File:Cynefin_as_of_1st_June_2014.png Figura 3.12: Adaptado de Rother,
M. Toyota Kata Practice Guide. Licenciado sob a licença não portada Creative Commons Attribution 3.0 (https://creativecommons.org/licenses/by/3.0/) de
http://www-personal.umich.edu/~mrother/Supporting_Materials.html.
Primeira edição 2020
ISBN 9780113316403
Impresso no Reino Unido para The Stationery Office Material é

certificado pelo FSC e produzido com celulose ECF, proveniente de florestas totalmente sustentáveis.
P003017691 c20 20/02
Conteúdo
Lista de Figuras 4
Lista de mesas vi
Prefácio vii
Prefácio viii
Sobre as publicações ITIL 4 ix
Sobre a história da ITIL x
Resumo da Fundação ITIL xii
1 Introdução 1
1.1 Público e escopo 1.2 2
Histórico e contexto 2
2 Conceitos-chave de TI de alta velocidade 5

2.1 TI de alta 6
velocidade 2.2 Tecnologia 7
digital 2.3 Organizações 11
digitais 2.4 Transformação 12
digital 2.5 Objetivos e principais características de TI de alta 16
velocidade 2.6 Adotando o sistema de valor de serviço ITIL para habilitar TI de 23
alta velocidade 2.7 Resumo 41
3 Cultura de TI de alta velocidade 43
3.1 Principais padrões de 44
comportamento 3.2 Modelos e conceitos da cultura 46
HVIT 3.3 Princípios orientadores da ITIL 3.4 73
Resumo 76
4 Técnicas de alta velocidade 77
4.1 Técnicas para investimentos valiosos 4.2 78
Técnicas para desenvolvimento rápido 4.3 88
Técnicas para operações resilientes 4.4 Técnicas 108
para valor cocriado 4.5 Técnicas para 127
conformidade garantida 4.6 Resumo 130

138
5 Conclusão 139
Nota final: A história da ITIL 141
Mais pesquisa 143
Glossário 147
Reconhecimentos 159
Índice 167
iii
Lista de Figuras
Figura 0.1 O sistema de valor do serviço xii
Figura 0.2 A cadeia de valor do serviço ITIL xiii
Figura 0.3 O modelo de melhoria contínua xv
Figura 0.4 As quatro dimensões do gerenciamento de serviços xvi
Figura 2.1 Tecnologia digital 8
Figura 2.2 Pilha de tecnologia do sistema de informação 8
Figura 2.3 A pilha de valor de TI 9
Figura 2.4 Transformação digital e transformação de TI 13
Figura 2.5 Exemplos de opções de sourcing para uma função de TI 15
Figura 2.6 Objetivos de uma perspectiva econômica 17
Figura 2.7 Principais características do HVIT 18
Figura 2.8 Um fluxo de valor com três estações de trabalho 19
Figura 2.9 O sistema de valor de serviço ITIL 24
Figura 2.10 Interação do serviço e a faixa de visibilidade 26
Figura 2.11 Ciclo de vida do produto digital de duas perspectivas: consumidor e fornecedor 27
Figura 2.12 Modelo de jornada do cliente 28
Figura 2.13 Ciclos de vida de produtos digitais da perspectiva do consumidor 28
Figura 2.14 A cadeia de valor do serviço ITIL 29
Figura 2.15 Atividades de DevOps em um loop contínuo 30
Figura 2.16 DevOps e a cadeia de valor do serviço 30
Figura 2.17 A perspectiva do consumidor de serviços 31
Figura 2.18 Cadeias de valor de serviço interagindo 32
Figura 2.19 Exemplo de fluxo de valor referente às atividades da cadeia de valor de serviço 32
Figura 2.20 O fluxo de valor no contexto 33
Figura 2.21 Fluxo de valor posicionado em relação à governança, execução e melhoria 34
Figura 2.22 Múltiplas práticas de gerenciamento envolvidas em um fluxo de valor, representadas em uma variação de um
Cadeia de valor do porteiro 35
Figura 2.23 As quatro dimensões do gerenciamento de serviços, incluindo os seis fatores PESTLE 37
Figura 3.1 Principais padrões de comportamento 44
Figura 3.2 Mapa de calor da importância dos principais padrões de comportamento para a ética 51
Figura 3.3 Mapa de calor da importância dos principais padrões de comportamento para o design thinking 53
Figura 3.4 Mapa de calor da importância dos principais padrões de comportamento para reconstrução para
agilidade de serviço 55
Figura 3.5 Mapa de calor da importância dos principais padrões de comportamento para a cultura de segurança 58
Figura 3.6 Mapa de calor da importância dos principais padrões de comportamento para a prevenção do estresse 61
Figura 3.7 A estrutura Cynefin 63
4
Figura 3.8 Mapa de calor da importância dos principais padrões de comportamento para trabalhar em
ambientes complexos 65
Figura 3.9 Mapa de calor da importância dos principais padrões de comportamento para a cultura Lean 68
Figura 3.10 O modelo de melhoria contínua ITIL 69
Figura 3.11 Domínios de melhoria 69
Figura 3.12 Toyota Kata 71
Figura 3.13 Mapa de calor da importância dos principais padrões de comportamento para a melhoria contínua 72
Figura 4.1 Mapa de calor da contribuição da priorização para a cadeia de valor do serviço 81
Figura 4.2 Mapa de calor da contribuição de uma abordagem mínima viável para a cadeia de valor do serviço 83
Figura 4.3 Mapa de calor da contribuição da propriedade do produto ou serviço para a cadeia de valor do serviço 85
Figura 4.4 Experimentação por tempo limitado com teste A/B 86
Figura 4.5 Mapa de calor da contribuição do teste A/B para a cadeia de valor do serviço 87
Figura 4.6 Efeito do tamanho da mudança 90
Figura 4.7 Mapa de calor da contribuição da infraestrutura como código para a cadeia de valor do serviço 91
Figura 4.8 Mapa de calor da contribuição da arquitetura do sistema de informação fracamente acoplado para o
cadeia de valor do serviço 94
Figura 4.9 Mapa de calor da contribuição das retrospectivas para a cadeia de valor do serviço 95
Figura 4.10 Mapa de calor da contribuição de post-mortems sem culpa para a cadeia de valor do serviço 97
Figura 4.11 Realização de valor mais rápida com uma abordagem iterativa 99
Figura 4.12 Mapa de calor da contribuição da análise contínua de negócios para a cadeia de valor do serviço 100
Figura 4.13 Mapa de calor da contribuição do CI/CD para a cadeia de valor do serviço 102
Figura 4.14 Mapa de calor da contribuição dos testes contínuos para a cadeia de valor do serviço 105
Figura 4.15 Um exemplo de um quadro Kanban 107
Figura 4.16 Mapa de calor da contribuição do Kanban para a cadeia de valor do serviço 108
Figura 4.17 Mapa de calor da contribuição da dívida técnica para a cadeia de valor do serviço 111
Figura 4.18 Mapa de calor da contribuição da engenharia do caos para a cadeia de valor do serviço 113
Figura 4.19 Mapa de calor da contribuição da definição de feito para a cadeia de valor do serviço 116
Figura 4.20 Mapa de calor da contribuição do controle de versão para a cadeia de valor do serviço 119
Figura 4.21 Mapa de calor da contribuição de AIOps para a cadeia de valor do serviço 121
Figura 4.22 Mapa de calor da contribuição do ChatOps para a cadeia de valor do serviço 123
Figura 4.23 Mapa de calor da contribuição do SRE para a cadeia de valor do serviço 125
Figura 4.24 Mapa de calor da contribuição da experiência de serviço para a cadeia de valor do serviço 129
Figura 4.25 Mapa de calor da contribuição do DevOps Audit Defense Toolkit para a cadeia de valor do serviço Figura 131
4.26 Mapa de calor da contribuição do DevSecOps para a cadeia de valor do serviço 134
Figura 4.27 Espectro de formalidade de revisão por pares 136
Figura 4.28 Mapa de calor da contribuição da revisão por pares para a cadeia de valor do serviço 137
v
Lista de mesas
Tabela 0.1 As práticas de gerenciamento da ITIL xiv
Tabela 2.1 Objetivos HVIT 16
Tabela 2.2 Principais características da TI de alta velocidade 18
Tabela 2.3 Resumo da influência das características HVIT nas atividades da cadeia de valor do serviço ITIL 19
Tabela 2.4 Etapas do ciclo de vida do produto digital 28
Tabela 2.5 Práticas e sua relevância para os cinco objetivos 36
Tabela 3.1 Modelos e conceitos e padrões de comportamento chave relacionados 46
Tabela 3.2 Elementos da cultura Lean 67
Tabela 4.1 Práticas para as quais a priorização é relevante 81
Tabela 4.2 Práticas para as quais uma abordagem mínima viável é relevante 83
Tabela 4.3 Práticas para as quais a propriedade do produto ou serviço é relevante 85
Tabela 4.4 Práticas para as quais o teste A/B é relevante 88
Tabela 4.5 Práticas para as quais a infraestrutura como código é relevante 92
Tabela 4.6 Práticas para as quais a arquitetura de sistema de informação fracamente acoplada é relevante 94
Tabela 4.7 Práticas para as quais as retrospectivas são relevantes 96
Tabela 4.8 Práticas para as quais post-mortems sem culpa são relevantes 98
Tabela 4.9 Práticas para as quais a análise de negócios contínua é relevante 100
Tabela 4.10 Práticas para as quais CI/CD são mais relevantes 103
Tabela 4.11 Tipos de teste de software 104
Tabela 4.12 Práticas para as quais o teste contínuo é mais relevante 105
Tabela 4.13 Práticas para as quais o Kanban é relevante 108
Tabela 4.14 Práticas para as quais a dívida técnica é relevante 111
Tabela 4.15 Práticas para as quais a engenharia do caos é relevante 114
Tabela 4.16 Práticas para as quais a definição de feito é relevante 116
Tabela 4.17 Práticas para as quais o controle de versão é relevante 119
Tabela 4.18 Práticas para as quais AIOps é relevante 121
Tabela 4.19 Práticas para as quais o ChatOps é relevante 123
Tabela 4.20 Práticas para as quais o SRE é relevante 126
Tabela 4.21 Práticas para as quais a experiência de serviço é relevante 129
Tabela 4.22 Práticas para as quais o DevOps Audit Defense Toolkit é relevante 132
Tabela 4.23 Práticas para as quais o DevSecOps é relevante 134
Tabela 4.24 Atividades em diferentes abordagens de revisão por pares 136
Tabela 4.25 Práticas para as quais a revisão por pares é relevante 137
vi
Prefácio
Nesta nova etapa do desenvolvimento da indústria de TI, a AXELOS tem o prazer de apresentar o ITIL 4, o mais recente passo
na evolução das melhores práticas de TI. Com base em nossa experiência e trazendo um pensamento novo e inovador para o
mercado, o ITIL 4 equipa sua empresa para lidar com os desafios enfrentados atualmente pelo setor.
A adoção do ITIL como a orientação mais usada no mundo sobre gerenciamento de TI e serviços continuará com o ITIL 4. Ele
garante a continuidade das formas de trabalho existentes (onde o gerenciamento de serviços já é bem-sucedido) integrando
práticas modernas e emergentes com práticas estabelecidas e comprovadas. saber como. A ITIL 4 também fornece orientação
sobre esses novos métodos para ajudar indivíduos e organizações a ver seus benefícios e a usá-los com confiança, foco e
interrupção mínima.
A abordagem holística do ITIL 4 eleva o perfil do gerenciamento de serviços em organizações e indústrias, colocando-o
dentro de um contexto mais estratégico. Seu foco tende a ser o gerenciamento de produtos e serviços de ponta a ponta, da
demanda ao valor.
O ITIL 4 é o resultado de uma grande quantidade de trabalho global de pesquisa e desenvolvimento nos setores de
TI e gerenciamento de serviços; este trabalho envolveu profissionais ativos, instrutores, consultores, fornecedores, técnicos e
clientes empresariais. A equipe de arquitetos colaborou com as partes interessadas e usuários mais amplos da ITIL para
garantir que o conteúdo atenda aos requisitos modernos de continuidade, inovação, flexibilidade e valor.
O treinamento ITIL fornece aos indivíduos uma abordagem estruturada para desenvolver suas competências no local de
trabalho atual e futuro. A orientação que acompanha também ajuda as organizações a tirar proveito das tecnologias novas e
futuras, obter sucesso em suas transformações digitais e criar valor conforme necessário para si e para seus clientes.
À medida que a demanda por tecnologia digital cresce, os profissionais estão sob crescente pressão para projetar, desenvolver,
executar e dar suporte a sistemas e serviços digitais. ITIL® 4: High-velocity IT visa ajudar os leitores a entender a transformação
digital e orientá-los e suas organizações para um estado mais integrado entre negócios e tecnologia. Ao discutir as melhores
práticas organizacionais e modelos mentais úteis da perspectiva de um profissional, ele fornece orientação valiosa na aplicação
prática da TI de alta velocidade.
Bem-vindo à nova geração de melhores práticas de TI!
Mark Basham
CEO, AXELOS Global Best Practice
vii
Prefácio
As pessoas dependem da tecnologia digital. O impacto social e econômico das organizações habilitadas digitalmente é sem
precedentes, e essas organizações exigem uma maneira significativamente diferente de trabalhar. Precisamos encontrar um
novo equilíbrio entre controle gerencial e julgamento profissional. O gerenciamento de serviços de TI geralmente se inclina para
o controle, mas as organizações habilitadas digitalmente são baseadas em sistemas complexos e intrinsecamente imprevisíveis.
Esses sistemas são incontroláveis em níveis mais baixos de granularidade, portanto, os instrumentos tradicionais de gerenciamento,
como especialização, processos prescritivos e metas de desempenho, não funcionam. A ação na ponta afiada deve ser baseada
no julgamento profissional e na compreensão da natureza dos sistemas nos quais o profissional trabalha. Os profissionais, portanto,
precisam de maneiras apropriadas de pensar e trabalhar de 'TI de alta velocidade'.
Como leitor, você se preocupa com isso não apenas porque deseja permanecer valioso e relevante em um ambiente de
trabalho em constante mudança, mas também porque tem o privilégio de contribuir para a prosperidade e o bem-estar das
pessoas, proporcionando-lhes melhores experiências digitais. Você se deu ao trabalho de examinar as orientações do setor, como
ITIL, portanto, presumivelmente, está comprometido com seu desenvolvimento profissional. Você está ciente dos desafios e
responsabilidades consideráveis envolvidos no gerenciamento da tecnologia digital. Você está pronto para o desafio e está
preparado para rever e desaprender abordagens antigas e integrar novos conceitos em sua forma de trabalhar. Você leva seu
trabalho e a si mesmo a sério.
Nós, os autores, revisores e outros colaboradores, cada um à sua maneira, estamos comprometidos em tornar nosso setor um
lugar melhor para se trabalhar. Acreditamos que as pessoas vêm em primeiro lugar. Trabalhamos em sistemas humanos complexos
em que os profissionais muitas vezes têm que arriscar. Isso é defensável: há dados limitados disponíveis, então suas ações são
baseadas em hipóteses bem fundamentadas que calibram quando observam os resultados de suas ações. Em locais de trabalho
tóxicos, eles podem ser facilmente culpados (com o luxo de uma retrospectiva) por tomarem as decisões erradas. Isso é inaceitável.
Quando o seu pessoal tem que apostar, é melhor apostar no seu pessoal. Paralelamente às orientações mais 'técnicas' que esta
publicação oferece, chamamos sua atenção para a importância da segurança psicológica, bem-estar e ética no local de trabalho.
Muitas organizações não apenas acumularam dívidas técnicas em seus softwares como resultado de atalhos conscientes ou
inconscientes, mas também têm uma dívida social considerável que precisa ser paga. É por isso que nos importamos. Este é um
momento crucial. É o momento certo para compartilhar nossos pensamentos e, esperançosamente, ser útil.
Testemunhei a preocupação, o engajamento e a generosidade daqueles que contribuíram para esta publicação.
Acreditamos no seu potencial. Agora cabe a você.
Mark Smalley
Editor líder, ITIL® 4: TI de alta velocidade
viii
Sobre as publicações ITIL4

ITIL® 4: TI de alta velocidade aborda as especificidades da transformação digital e ajuda as organizações a evoluir para uma
convergência de negócios e tecnologia ou a estabelecer uma nova organização digital. É uma das quatro publicações ITIL 4, que
se baseiam nos conceitos introduzidos no ITIL Foundation. Cada uma dessas publicações se concentra em um aspecto diferente
do gerenciamento de serviços.
ITIL® 4: Create, Deliver and Support aborda os aspectos culturais e de gerenciamento de equipe do gerenciamento de produtos
e serviços; fornece uma visão geral das ferramentas e tecnologias que suportam o gerenciamento de serviços; e demonstra como
integrar práticas de gerenciamento em fluxos de valor de ponta a ponta.
ITIL® 4: Direct, Plan and Improve ajuda a alinhar a gestão de produtos e serviços com os requisitos de negócios modernos;
impulsionar a transformação organizacional bem-sucedida; e incorporar a melhoria contínua no comportamento de uma
organização em todos os níveis.
ITIL® 4: Impulsionar o Valor das Partes Interessadas fornece orientação sobre como estabelecer, manter e desenvolver
relacionamentos de serviço eficazes em níveis apropriados. Ele lidera as organizações em uma jornada de serviço em suas
funções de provedor de serviços e consumidor, apoiando interação e comunicação eficazes.
As publicações do ITIL 4 são suportadas pelos guias de práticas de gerenciamento do ITIL, que contêm orientações práticas e
pragmáticas que podem ser aplicadas no contexto de todas as publicações do ITIL 4. Práticas que são particularmente relevantes
para ITIL® 4: TI de alta velocidade incluem gerenciamento de arquitetura, gerenciamento de disponibilidade, análise de negócios,
gerenciamento de capacidade e desempenho, gerenciamento de implantação, gerenciamento de segurança da informação,
gerenciamento de infraestrutura e plataforma, monitoramento e gerenciamento de eventos, gerenciamento de portfólio, gerenciamento
de problemas gerenciamento, gerenciamento de relacionamento, gerenciamento de risco, gerenciamento de continuidade de serviço,
design de serviço, central de serviço, validação e teste de serviço e desenvolvimento e gerenciamento de software. Os guias práticos
podem ser acessados online em www.axelos.com/my-axelos/my-itil.
ix
Sobre a história da ITIL

As orientações fornecidas nesta publicação podem ser adotadas e adaptadas para todos os tipos de organização e serviço.
Para mostrar como os conceitos de ITIL podem ser aplicados na prática às atividades de uma organização, ITIL® 4: High-velocity IT
segue as façanhas de uma empresa fictícia em sua jornada ITIL.
Esta empresa, Axle Car Hire, está passando por uma transformação para modernizar seus serviços e melhorar seus níveis de
satisfação e retenção de clientes, e está usando o ITIL para fazer isso. Em cada capítulo do texto, os funcionários da Axle descreverão
como a empresa está melhorando seus serviços e explicarão como estão usando as melhores práticas de ITIL para fazer isso.
As seções do enredo ITIL aparecem em todo o texto, separadas por uma borda distinta.
A história até agora

A Axle Car Hire está passando por uma transformação digital.
A Axle está sediada em Seattle, com filiais na Europa, Estados Unidos e Ásia-Pacífico. Antes de sua transformação, a Axle enfrentou
uma desaceleração nos negócios e uma diminuição na satisfação do cliente. Perdeu clientes para empresas disruptivas que ofereciam
serviços inovadores, incluindo compartilhamento de carros e carros sem motorista, por meio de plataformas online e aplicativos móveis.
Consequentemente, a Axle contratou um novo CIO, Henri, que foi escolhido por sua experiência em transformações de TI em larga
escala, equilibrando abordagens como design thinking, DevOps e Agile com estruturas de gerenciamento como ITIL, ISO, COBIT e
IT4IT. Ele entende a importância de adotar a TI e a inovação digital nos negócios modernos. Ele foi encarregado de aumentar a
satisfação do cliente, atrair e reter clientes e melhorar os resultados da empresa.
Henri priorizou a transformação digital do Axle e usou o ITIL como uma fonte fundamental de melhores práticas para construir
outras abordagens. Isso permitiu a mudança que ele sabia que o negócio precisava. A adoção e adaptação do ITIL ajudaram
Henri a entregar os serviços de alta qualidade que cocriaram valor para a Axle e seus clientes. Ele examinou as maneiras pelas
quais a Axle poderia gerenciar as quatro dimensões do gerenciamento de serviços, adotar a cadeia de valor do serviço e utilizar os
sete princípios orientadores da ITIL na melhoria contínua de seus serviços.
Sob a direção de Henri, novos serviços foram introduzidos, como o sistema avançado de assistência ao motorista e acesso
biométrico aos veículos. Esses novos serviços foram amplamente adotados pelos clientes da Axle. Como resultado, a empresa
ganhou uma reputação de serviço rápido e confiável. A fidelidade do cliente melhorou e as reservas repetidas aumentaram. A
iniciativa de melhoria Axle Green também foi introduzida para ajudar a Axle a alcançar sua visão de ser uma organização
ecologicamente correta. Muitas das metas ecológicas da empresa já foram alcançadas, com planos para novos desenvolvimentos
em andamento. Um projeto para garantir que metade da frota da Axle funcione com eletricidade gerada de forma sustentável está
avançando.
Após um período de forte crescimento, a Axle está experimentando novos modelos de serviço em resposta às mudanças no
clima de negócios. Em diferentes locais ao redor do mundo, a Axle busca soluções para os novos desafios que enfrenta. Se os
novos modelos de serviço forem bem-sucedidos, eles poderão ser implantados nas filiais da Axle em todo o mundo.
x
Conheça os funcionários da Eixo
Aqui estão cinco funcionários-chave da Axle Car Hire:
Henri é o novo CIO da Axle Car Hire. Ele é um executivo de negócios de sucesso que está preparado para agitar as coisas.
Ele acredita em uma abordagem integrada para TI e gerenciamento de serviços.
Marco é o gerente de entrega de TI da Axle Car Hire. Ele é orientado por processos e continuamente faz
referência à estrutura ITIL para ajudá-lo a gerenciar relacionamentos de serviço positivos. No entanto, Marco teve
pouca exposição a uma abordagem combinada ou colaborativa de gerenciamento de serviços.
Radhika é a analista de negócios de TI da Axle Car Hire e é seu trabalho entender os requisitos do usuário da
equipe e dos clientes da Axle Car Hire. Ela é curiosa e enérgica, e se esforça para manter um relacionamento positivo com
todos os seus clientes, internos e externos. Radhika trabalha principalmente em atividades de descoberta e planejamento,
e não em operações de TI. Ela faz muitas perguntas e é ótima em identificar padrões e tendências.
Solmaz É o gerente de transformação de negócios da Axle. Ela é apaixonada pela satisfação do cliente para
clientes existentes e potenciais, e está focada em fornecer serviços adequados para atender às suas necessidades.
Para complementar sua função, ela também se especializou em design centrado no ser humano, tomando decisões de
design com base em como as pessoas podem, precisam e desejam realizar tarefas, em vez de esperar que os usuários
ajustem e acomodem seus comportamentos a um produto. Solmaz é caloroso, colaborativo e simpático.
Su é o gerente de produto da Axle Car Hire para experiência em viagens e trabalhou para a Axle nos últimos cinco anos.
Su é inteligente, meticuloso e apaixonado pelo meio ambiente.
XI
Resumo da Fundação ITIL

Esta seção fornece uma breve recapitulação dos conceitos introduzidos no ITIL® Foundation: ITIL 4 Edition.
Os principais componentes da estrutura ITIL 4 são o sistema de valor de serviço ITIL (SVS) e o modelo de quatro
dimensões.
O sistema de valor de serviço ITIL

O ITIL SVS representa como os vários componentes e atividades da organização trabalham juntos para facilitar a criação de
valor por meio de serviços habilitados por TI. A estrutura do ITIL SVS é mostrada na Figura 0.1.
Os principais componentes do ITIL SVS são:
• a cadeia de valor do serviço ITIL
• as práticas ITIL
• os princípios orientadores da ITIL
• governança •
melhoria contínua.
Oportunidade /
demanda
Figura 0.1 O sistema de valor do serviço
xii
A cadeia de valor do serviço ITIL
O elemento central do SVS é a cadeia de valor do serviço, um modelo operacional que define as principais atividades
necessárias para responder à demanda e facilitar a realização de valor por meio da criação e gestão de produtos e serviços.
A cadeia de valor do serviço é mostrada na Figura 0.2.
A cadeia de valor do serviço ITIL inclui seis atividades da cadeia de valor que levam à criação de produtos e serviços
e, por sua vez, valor. As atividades são:
• plano
• melhorar
• envolver
• design e transição
• obter/construir
• entregar e dar suporte.
Plano
Projeto
e transição
Demanda Produtos Valor

Se empenhar
Obter/construir Entregue e serviços
e dê suporte
Melhorar
Figura 0.2 A cadeia de valor do serviço ITIL
xiii
ITIL® 4: TI de alta velocidade
As práticas ITIL
Práticas são conjuntos de recursos organizacionais projetados para realizar um trabalho ou atingir um objetivo. O ITIL SVS inclui 14
práticas de gerenciamento geral, 17 práticas de gerenciamento de serviços e três práticas de gerenciamento técnico. Estes são
descritos na Tabela 0.1.
Tabela 0.1 As práticas de gerenciamento da ITIL
Práticas gerais de gestão Práticas de gerenciamento de serviços Práticas de gerenciamento técnico
Gerenciamento de arquitetura Gerenciamento de disponibilidade Gerenciamento de implantação
Melhoria contínua Análise de negócio Gerenciamento de infraestrutura e plataforma
Gerenciamento de segurança da informação Gerenciamento de capacidade e desempenho Desenvolvimento e gerenciamento de software
Gestão do conhecimento Alterar ativação
Medição e relatórios Gerenciamento de incidentes
Gestão de mudanças organizacionais Gerenciamento de ativos de TI
Gerenciamento de portfólio Monitoramento e gerenciamento de eventos
Gerenciamento de Projetos Gerenciamento de problemas
Gestão de relacionamento Gerenciamento de lançamento
Gerenciamento de riscos Gerenciamento do catálogo de serviços
Gestão financeira de serviços Gerenciamento de configuração de serviço
Gestão de estratégia Gerenciamento de continuidade de serviço
Gestão de fornecedores Projeto de serviço
Gestão da força de trabalho e talento Balcão de atendimento
Gerenciamento de nível de serviço
Gerenciamento de solicitação de serviço
Validação e teste de serviço
Os princípios orientadores da ITIL
Os princípios orientadores da ITIL são recomendações que podem orientar uma organização em todas as circunstâncias,
independentemente de mudanças em seus objetivos, estratégias, tipo de trabalho ou estrutura de gestão.
Os sete princípios orientadores da ITIL são:
• Foco em valor Tudo o que a organização faz precisa mapear, direta ou indiretamente, valor para o
partes interessadas.
• Comece onde você está Não comece do zero e construa algo novo sem considerar o que já está disponível para ser aproveitado.
• Progrida iterativamente com feedback Não tente fazer tudo de uma vez. • Colabore e
promova a visibilidade Trabalhar em conjunto além das fronteiras produz resultados com maior
buy-in, mais relevância para os objetivos e maior probabilidade de sucesso a longo prazo.
• Pense e trabalhe de forma holística Nenhum serviço ou elemento usado para fornecer um serviço é independente.
• Mantenha-o simples e prático Se um processo, serviço, ação ou métrica não fornecer valor ou produzir um
resultado útil, elimine-o.
• Otimizar e automatizar recursos de todos os tipos, principalmente RH, devem ser usados para o seu melhor efeito.
xiv
Resumo da Fundação ITIL
Governança
Governança é o meio pelo qual uma organização é dirigida e controlada. O papel e a posição da governança no ITIL
SVS variam dependendo de como o SVS é aplicado em uma organização.
Melhoria contínua
A melhoria contínua é uma atividade organizacional recorrente realizada em todos os níveis para garantir que o desempenho
de uma organização atenda continuamente às expectativas das partes interessadas. A ITIL 4 suporta a melhoria contínua com
o modelo de melhoria contínua da ITIL, descrito na Figura 0.3.
Figura 0.3 O modelo de melhoria contínua
xv
O modelo de quatro dimensões

Para dar suporte a uma abordagem holística ao gerenciamento de serviços, a ITIL define quatro dimensões que coletivamente
são críticas para a facilitação efetiva e eficiente de valor para clientes e outras partes interessadas na forma de produtos e
serviços. As quatro dimensões (mostradas na Figura 0.4) são:
• organizações e pessoas
• informação e tecnologia
• parceiros e fornecedores •
fluxos de valor e processos.
As quatro dimensões representam perspectivas relevantes para todo o SVS, incluindo toda a cadeia de valor do serviço e
todas as práticas ITIL. As quatro dimensões são limitadas ou influenciadas por vários fatores externos que muitas vezes
estão fora do controle do SVS.
Fatores Fatores
políticos ECONOMICOS
Organizações Informação
e pessoas e tecnologia
Produtos
e serviços
Fatores Fatores
Ambientais sociais
Parceiros Fluxos de valor

e fornecedores e processos
Fatores
Fatores legais tecnológicos
Figura 0.4 As quatro dimensões do gerenciamento de serviços
xvi
CAPÍTULO 1
INTRODUÇÃO
1. Introdução
A tecnologia digital é cada vez mais importante. Seus impactos econômicos, sociais e políticos são sem precedentes. Ao mesmo tempo, é
cada vez mais desafiador para os profissionais digitais projetar, desenvolver, executar e dar suporte aos sistemas e serviços que atendem a
essa demanda. ITIL® 4: TI de alta velocidade se concentra em produtos e serviços digitais, incluindo experiências digitais do cliente,
abrangendo boas práticas organizacionais e modelos mentais, tudo da perspectiva de um profissional.
1.1 Público e escopo

Esta publicação é destinada a profissionais de TI e gerenciamento de serviços que trabalham em organizações que estão se
tornando mais habilitadas digitalmente. Ele ajudará aqueles que estão familiarizados com os conceitos tradicionais de TI e gerenciamento
de serviços a discutir 'digital' com confiança, desenvolver competências práticas e integrar novos conceitos, técnicas e tecnologias em suas
formas de trabalho.
Você deve usar esta publicação como uma ferramenta para melhorar a forma como você e seus colegas de trabalho:
• fornecer produtos e serviços
• elevar continuamente seus padrões de trabalho
• confiam e são confiáveis
• aceitar ambiguidade e incerteza
• comprometer-se com o aprendizado contínuo.
O escopo desta publicação inclui as principais atividades na cadeia de valor digital, incluindo o que o profissional faz e os recursos que ele
usa ao longo do ciclo de vida dos produtos digitais para:
• fazer os investimentos digitais certos
• realizar e entregar produtos e serviços digitais resilientes rapidamente
• garantir que o consumidor do serviço perceba o valor desses produtos e serviços
• assegurar a conformidade das atividades com os requisitos de governança, risco e conformidade.
1.2 Antecedentes e contexto

O progresso tecnológico, combinado com a tecnologia digital aplicada de forma inovadora, resultou em sistemas complexos e imprevisíveis.
Os sistemas agora compreendem uma infinidade de componentes produzidos por partes que agem com vários graus de confiabilidade,
levando a falhas e falhas intrínsecas. Mudanças contínuas em um sistema e seu ambiente significam que essas falhas também mudam
continuamente. A maioria é pequena demais para causar problemas significativos, seja por redundância e outras formas de resiliência no
sistema, seja por intervenção humana.
No passado, a maioria das pessoas acreditava que a mudança perturbava a estabilidade e que a estabilidade controlava a mudança;
menos mudanças significavam menos risco para a estabilidade. Na última década, uma maneira diferente de pensar foi adotada. Ao reduzir o
2
tamanho da mudança, o risco de interrupção é reduzido. Mudanças menores e mais frequentes melhoram a capacidade de mudança da
organização, reduzindo assim o risco de interrupção. Recentemente, a abordagem predominante tem sido abraçar e permitir mudanças.
Tudo isso mudou o ambiente de modelos 'causais' (se-então-senão), previsíveis, para modelos disposicionais (se-então talvez). Como o
comportamento do sistema nem sempre ou facilmente pode ser previsto, as formas de pensar e trabalhar mudam: de previsão e controle para
insight e compreensão; de grandes mudanças ocasionais a pequenas e freqüentes; desde o planejamento detalhado com antecedência até a
experimentação e o aprendizado contínuos; e de segurança contra falhas para segurança contra falhas. Não são mudanças triviais.
Além desse aumento nas formas de pensar e trabalhar baseadas na complexidade, quebrar silos, ou pelo menos pensar em silos, é uma
preocupação atual. Os grupos homogêneos são menos resilientes e eficazes do que os diversos. Em um contexto organizacional, isso significa
que especialistas, equipes, departamentos e organizações devem abraçar as oportunidades de trabalhar com uma ampla gama de pessoas.
Felizmente, muitas coisas estão mudando. As pessoas estão trabalhando efetivamente em equipes pequenas, orientadas para produtos
ou serviços. A automação é usada com mais frequência para dar suporte aos processos de TI. Os conceitos inter-relacionados de servidores
imutáveis e infraestrutura como código são amplamente adotados. O pensamento sistêmico holístico é mais prevalente. O pensamento científico
está sendo adotado. A imprevisibilidade e a ambiguidade são cada vez mais aceitas como necessárias. Há uma mudança de uma mentalidade
de entrega de valor para uma de cocriação de valor. Os serviços externos são frequentemente adquiridos e integrados para o desenvolvimento
rápido de recursos digitais, como alternativa ou adição à abordagem Agile interna.
Essas mudanças são manifestações de novas formas de pensar e trabalhar que estão se tornando mainstream. ITIL® 4: TI de alta velocidade se
baseia nesses desenvolvimentos e contribui para eles. Entre os temas abordados nesta publicação estão:
• as considerações éticas relevantes para a tecnologia digital
• pensamento de design
• trabalhar em ambientes complexos
• o modelo de melhoria contínua ITIL
• Cultura Lean
• cultura de segurança
• Técnicas enxutas, ágeis, resilientes e contínuas.
3
ITIL ® 4: TI de alta velocidade
4
CAPÍTULO 2
CONCEITOS CHAVE DE
TI DE ALTA VELOCIDADE
2 Conceitos-chave de
Este capítulo apresenta alguns conceitos-chave relacionados à TI de alta velocidade (HVIT). Ele explora a natureza das organizações
habilitadas digitalmente e como uma maneira significativamente diferente de trabalhar é necessária e ilustra como os conceitos
centrais da orientação ITIL podem ser usados como blocos de construção para definir e organizar o trabalho de HVIT.
O capítulo define vários conceitos-chave, incluindo:
• TI de alta velocidade
• tecnologia digital
• organizações digitais
• transformação digital
• objetivos de TI de alta velocidade e características principais.
2.1 TI de alta velocidade
Definição: TI de alta velocidade
A aplicação da tecnologia digital para habilitação significativa de negócios, onde o tempo para o mercado, o tempo para o
cliente, o tempo para mudar e a velocidade em geral são cruciais. A alta velocidade não se restringe ao desenvolvimento
rápido; é necessário em toda a cadeia de valor do serviço, desde a inovação no início, passando pelo desenvolvimento e
operações, até a efetiva realização do valor.
Assim como algumas organizações digitais são mais digitais do que outras, a velocidade em algumas organizações é maior do que
em outras. No entanto, uma organização com maior velocidade não é necessariamente melhor. A velocidade na qual uma
organização deve operar depende da natureza dessa organização em particular e, em alguns casos, uma velocidade menor pode
ser mais benéfica. Também não é necessário, ou mesmo recomendado, que toda a TI de uma organização seja de alta velocidade.
Por exemplo, sistemas mais dinâmicos voltados para o cliente podem ser gerenciados com uma maneira de trabalhar HVIT, enquanto
os sistemas legados de back-office são melhor tratados de maneira mais tradicional.
A alta velocidade não prejudica a utilidade ou a garantia da solução, e a alta velocidade equivale a alto desempenho em geral.
Aumentar a velocidade dentro de uma organização sempre envolverá custos e riscos, principalmente quando há uma mudança
acentuada em vez de uma melhoria gradual. Pode haver situações em que os riscos são assumidos conscientemente para obter ou
manter vantagem competitiva. Outros riscos são muitas vezes assumidos inconscientemente devido à falta de compreensão do
contexto e à diluição dos avisos antes que a informação atinja os níveis de tomada de decisão. Os riscos também podem ser
assumidos quando os tomadores de decisão são influenciados por incentivos e metas desequilibradas; por exemplo, quando são
tomadas decisões com maior probabilidade de ajudar a atingir metas de curto prazo, em vez de decisões mais sustentáveis.
6
Cientificamente falando, a velocidade também tem um componente direcional. No HVIT, isso é interpretado como fazer a coisa certa.
Em outras palavras, não apenas os requisitos da abordagem de alta velocidade devem ser atendidos, mas as decisões corretas
devem ser tomadas em relação ao investimento e à sustentabilidade.
O HVIT fornece a muitas organizações graus mais altos de capacitação digital, mas nem sempre é um investimento prudente.
Para algumas organizações, não faz sentido realizar tal transformação, pois elas têm outras prioridades mais altas. Outros podem
optar por não tentar aumentar a velocidade porque acham que a quantidade de mudança cultural envolvida seria muito difícil de
alcançar ou improvável de gerar um retorno aceitável sobre o investimento.
A história da ITIL: TI de alta velocidade
Henri: A visão da Axle é ser a empresa de aluguel de carros ambientalmente mais reconhecida do mundo.
Isso significa que adotamos tecnologias novas e verdes na busca de nossos objetivos de negócios. Adotar e
usar essas tecnologias de acordo com os princípios orientadores da ITIL mostra ao conselho de administração que
o investimento criterioso nas tecnologias certas, implantadas corretamente, é uma maneira eficaz de fazer nossa
empresa crescer.
Marco: O ritmo da evolução tecnológica moderna significa que ferramentas e soluções podem ficar rapidamente
desatualizadas. A tecnologia que era ótima há cinco anos não é necessariamente a melhor maneira de otimizar
nossos serviços hoje. Nossas ferramentas precisam de revisão contínua e do desenvolvimento e implantação
rápidos de quaisquer atualizações necessárias para garantir que ainda sejam eficazes.
Radhika: Nossa pesquisa mostra que nosso site está desatualizado. Por exemplo, não é otimizado para os
smartphones mais recentes. As plataformas de nossos concorrentes podem ser adaptadas mais rapidamente
para reagir às demandas de um mercado que está cada vez mais fazendo negócios em dispositivos em vez de
computadores. Precisamos melhorar nossa plataforma, ou nossos clientes encontrarão uma maneira mais fácil de
reservar suas viagens.
Solmaz: Estamos competindo com modelos de negócios transformacionais que utilizam a tecnologia e abordam
as mudanças nos requisitos dos clientes de maneiras novas e interessantes. Em resposta, a Axle está pedindo a
várias de nossas filiais que experimentem modelos de negócios inovadores. Em meu papel como gerente de
transformação de negócios, sou responsável por garantir que o negócio tenha agilidade para se adaptar às
mudanças.
2.2 Tecnologia digital
Definições
• Tecnologia digital Tecnologia que digitaliza algo ou processa dados digitais. A tecnologia digital refere-se à tecnologia da
informação (TI) e às partes da tecnologia operacional (OT) que foram digitalizadas.
• Digitalização O processo de transformar algo (por exemplo, texto, som ou imagens) de analógico para
forma digital, expressando a informação em dígitos binários.
7
Tecnologia digital
Tecnologia Tecnologia
IoT
da Informação operacional
Fornece aos Detecta ou altera o estado
usuários informações de dispositivos físicos
Figura 2.1 Tecnologia digital
A tecnologia digital é composta de TI e OT. A TI fornece dados e informações aos usuários, enquanto a OT detecta ou causa
alterações em dispositivos físicos (consulte a Figura 2.1).
2.2.1 Tecnologia da informação

A TI existe como sistemas de informação que são compostos de hardware, software de sistema, dados e aplicativos que são usados
para fins de processamento de dados. A Figura 2.2 mostra uma pilha de tecnologia de sistema de informação com mais detalhes.
Informação é um dado que é útil em um contexto particular. Em TI, tornar as informações disponíveis para os usuários finais é o
objetivo final. Isso pode ser apresentado na forma de números ou texto em uma tela ou de outras maneiras, por exemplo, como
um local móvel em um mapa.
Inscrição
Dados
Plataforma
Tempo de execução
Middleware
Sistemas operacionais
A infraestrutura
Virtualização
Informática
Armazenar
Rede
Instalações
Figura 2.2 Pilha de tecnologia do sistema de informação
8
Conceitos-chave de TI de alta velocidade
Definição: tecnologia da informação
A aplicação da tecnologia digital para armazenar, recuperar, transmitir e manipular dados (processamento de dados), geralmente
no contexto de um negócio ou outro tipo de organização.
Tradicionalmente, o valor da TI tem sido percebido como maior eficiência, porque leva a sistemas de informação automatizados que
processam e fornecem dados de forma mais rápida, confiável e a um custo mais barato do que pode ser feito por humanos. Cada vez
mais, a inteligência artificial (como o aprendizado de máquina) está aplicando a TI não apenas para processar e fornecer dados, mas
também para criar novas informações.
As organizações usam principalmente as informações coletadas de sistemas de informação tradicionais e automatizados para a tomada
de decisões internas. Dessa forma, ajudam a reduzir a incerteza, que é a função primordial da informação. O valor da informação só é
percebido quando são tomadas decisões que foram informadas e melhoradas por essa informação. Como tal, um retorno sobre os
investimentos em TI muitas vezes só pode ser realmente realizado quando a tomada de decisão leva em consideração as informações que
os sistemas de informação fornecem. Se nenhuma ação for tomada, nenhum valor será criado. Em alguns casos, essa ação também pode
ser não fazer nada, por exemplo, para evitar um risco identificado.
A Figura 2.3 demonstra como a pilha de TI contribui para a criação de valor por meio de uma tomada de decisão informada.
Inscrição Agir
Dados
Decisão
Plataforma
Tempo de execução
Em formação
Middleware
Sistemas operacionais
serviço de TI
A infraestrutura
Virtualização Em formação
produtos
Informática sistema
Armazenar
Rede
Instalações Tecnologia da Informação
Figura 2.3 A pilha de valor de TI
Apesar de TI ser um conceito central para organizações em todo o mundo, o termo é muitas vezes mal interpretado. 'IT' pode ser usado
para se referir a qualquer um dos seguintes:
• a função organizacional de TI (o departamento de TI); esta publicação se refere a ela como a 'função de TI'
• Infraestrutura de TI, incluindo aplicativos genéricos de produtividade no local de trabalho (como processamento de texto), mas não
os aplicativos que suportam funções de negócios específicas
9
• sistemas de informação internos de uma organização

• componentes técnicos usados para criar 'produtos digitais'
• tecnologia de processamento de dados (usada para armazenar, recuperar, transmitir e manipular dados)
• tecnologia digital usada para processar dados para digitalizar e automatizar negócios.
Esta publicação usa o termo 'TI' para se referir à aplicação de tecnologia digital para processar dados para digitalizar e automatizar
negócios.
2.2.2 Tecnologia operacional
Definição: Tecnologia operacional
A aplicação de tecnologia digital para detectar ou causar alterações em dispositivos físicos por meio de monitoramento
e/ou controle.
A tecnologia operacional (TO) difere da TI, pois usa dados digitalizados como um meio interno para um objetivo físico, em vez de
disponibilizar informações aos usuários.
'OT' refere-se a dispositivos físicos (por exemplo, válvulas e bombas em máquinas) nos quais os dados digitalizados são usados para
realizar ações físicas. Os dispositivos OT podem ser tão pequenos quanto o módulo de controle do motor (ECM) de um carro ou tão
grandes quanto a rede de controle distribuída para uma rede elétrica nacional.
O termo coletivo "sistemas de controle industrial" (ICSs) é usado para se referir a sistemas OT, como sistemas de controle de supervisão
e aquisição de dados (SCADA), sistemas de controle distribuído (DCSs), unidades terminais remotas (RTUs) e controladores lógicos
programáveis (PLCs). ), juntamente com redes dedicadas e unidades de organização. A esfera OT também inclui sistemas embarcados
(como instrumentação inteligente) e um grande subconjunto de aquisição de dados científicos, controle e dispositivos de computação.
Os dispositivos OT são suportados pela Internet das Coisas (IoT), permitindo que eles se conectem entre si e com sistemas de
informação.
A história da ITIL: tecnologia digital

Henri: Axle Car Hire está liderando o caminho na integração de nossa tecnologia mecânica ou operacional com
nossa tecnologia da informação. Nossos veículos são uma extensão de nossa plataforma digital; eles são nosso
ponto de entrada na Internet das Coisas. A informação recolhida pelos sensores e instalações GPS nos nossos carros
é armazenada e partilhada para que possamos otimizar e automatizar o nosso serviço.
10
2.3 Organizações digitais

As organizações digitais são habilitadas pela tecnologia digital. A tecnologia digital é um importante facilitador de sustentação para os
processos internos dessas organizações e geralmente faz parte de seus produtos e serviços. Como tal, a tecnologia digital é uma parte
estratégica do modelo de negócios de uma organização digital e é aplicada às suas atividades primárias (em vez de suporte). Por isso, priorizar
a tecnologia digital ('digital first') geralmente faz parte da cultura dessa organização (em outras palavras, a forma como as coisas são feitas
nessa organização).
Definição: organização digital
Uma organização que é habilitada pela tecnologia digital para fazer negócios de maneira significativamente diferente ou para
fazer negócios significativamente diferentes.
A definição exata do que 'ser digital' significa normalmente varia entre as organizações, mas geralmente se reflete na experiência do
cliente, no produto ou serviço, no modelo de negócios, no modelo operacional e na experiência do funcionário que a organização oferece.
Em uma organização digital, isso será ativado principalmente pela tecnologia digital.
A maioria das organizações faz algum uso de tecnologia digital e, de certa forma, são digitais. Na prática, no entanto, uma organização é
considerada 'digital' se faz uso diferenciador e, portanto, estratégico, da tecnologia digital.
Por exemplo, uma empresa de táxi tradicional depende da tecnologia digital para suas operações; mas para uma empresa de táxi que conta
com um aplicativo para reservas, a tecnologia digital é estratégica e parte fundamental de seu modelo de negócios.
Embora a digitalização em uma organização geralmente se manifeste em seus produtos e serviços, a digitalização apenas de práticas internas
também pode ser suficiente para qualificá-la como 'digital', desde que isso resulte em benefício significativo.
As organizações digitais não são total e consistentemente digitalizadas e, muitas vezes, algumas partes serão mais digitalizadas do que outras.
Nesses casos, essa diversidade representará um desafio que deve ser cuidadosamente gerenciado para garantir que as diferentes áreas possam
trabalhar em conjunto de forma eficaz.
As partes das organizações que são significativamente digitalizadas impõem demandas específicas às pessoas responsáveis pela capacitação
digital. Essas demandas dependem do grau de habilitação digital, mas geralmente são maiores do que as demandas de sistemas de informação
para atividades de suporte. Para produtos digitais e experiências do cliente, são necessários investimentos digitais inovadores para criar ou
manter uma vantagem competitiva e devem ser realizados rapidamente. Os produtos digitais, serviços e canais de clientes resultantes precisam
ser operacionalmente resilientes e seus usuários devem usá-los bem para obter o retorno do investimento desejado.
A digitalização de uma organização tem implicações significativas para seu modelo operacional (ou seja, os recursos de que precisa e
como eles interagem). Uma consideração importante para os modelos operacionais organizacionais é a centralização ou descentralização
da função de TI e como cada uma dessas opções afetará a eficácia e a eficiência da organização. É importante que o modelo operacional de
uma organização digital seja baseado na cocriação de valor pelo provedor de serviços e pelo consumidor de serviços para garantir que o valor
dos investimentos digitais seja realizado adequadamente.
Para o bem e para o mal, o impacto social, político e econômico da TI é sem precedentes. Há, portanto, uma obrigação moral cada vez mais forte
para organizações habilitadas digitalmente, nas quais a TI capacita o negócio em vez de apenas apoiá-lo, de considerar como elas aplicam a
tecnologia digital além de seus interesses econômicos diretos.
11
A história da ITIL: organizações digitais

Henri: Nosso negócio é habilitado digitalmente, mas nem sempre integrado digitalmente. Por exemplo, algumas
agências ficam para trás na digitalização das reservas que recebem pessoalmente ou por telefone.
Radhika: Vimos o surgimento de serviços de aluguel de carros totalmente automatizados, onde cada ponto de
contato e interação de serviço acontece em um aplicativo personalizável e fácil de usar, e onde o cliente pode até
localizar e desbloquear o carro sem uma única interação humana.
Solmaz: Alguns clientes preferem isso, principalmente quando estão em países onde não falam o idioma local.
Precisamos acompanhar essa demanda para que possamos proporcionar aos nossos clientes a melhor experiência
possível.
2.4 Transformação digital

Transformação é fazer as coisas de forma diferente, ou fazer coisas diferentes. Trata-se também de ressignificar o trabalho para pensar
sobre as coisas de maneira diferente, ou pensar sobre coisas diferentes.
A 'transformação digital' é frequentemente usada para indicar grandes investimentos em digitalização, robotização e outras formas de
automação que permitem às organizações fazer negócios de maneira significativamente diferente ou fazer negócios significativamente
diferentes. Essa mudança tecnológica muitas vezes exige uma mudança organizacional na forma como a organização usa as soluções
digitais.
Definição: transformação digital
O uso da tecnologia digital para permitir uma melhoria significativa na realização dos objetivos de uma organização que não
poderiam ser alcançados por meios não digitais.
O termo 'transformação digital' não é específico para um tipo específico de transformação e pode ser usado para se referir a qualquer
transformação habilitada digitalmente. A entidade transformada geralmente é uma combinação da experiência do cliente, produtos ou
serviços da organização, modelo de negócios, modelo operacional (por exemplo, o fluxo de valor) e experiência do funcionário.
Digitalização x digitalização
A transformação digital às vezes é chamada de 'digitalização'. No entanto, o uso deste termo não é recomendado devido à
possível confusão com digitalização, que é o processo técnico de mudar algo do formato analógico para o formato digital.
12
O termo 'transformação', usado corretamente, significa grande mudança. Apesar disso, a transformação não implica
necessariamente uma única e grande mudança. Com base na abordagem que uma organização seleciona, a transformação pode ser
alcançada com o mesmo sucesso com algumas grandes mudanças ou muitas mudanças menores. Em muitos casos, uma série de
mudanças menores pode até ser a abordagem mais bem-sucedida.
2.4.1 Transformação de TI
Em organizações em que negócios e TI são considerados funções organizacionais separadas, a 'transformação de TI' é frequentemente
usada para denotar grandes mudanças que melhoram a forma como os serviços de TI são fornecidos. A transformação de TI está
focada em como os serviços de TI e os sistemas de informação são desenvolvidos, executados e suportados. Isso pode incluir a
descentralização da função de TI e sua integração em linhas de negócios digitais.
Antes de passarem por uma transformação digital, as organizações são gerenciadas separadamente de seus provedores de
serviços de TI, sejam eles internos ou externos. Um provedor de serviços de TI está focado no gerenciamento de recursos de TI para
criar e entregar produtos e serviços de TI, enquanto um consumidor de serviços está focado no gerenciamento de seus produtos,
serviços e recursos, incluindo aqueles entregues ou suportados pelo provedor de serviços de TI. Atuando como consumidora de serviços,
esta organização pode influenciar a gestão do prestador de serviços. Isso é mostrado como Modelo 1 na Figura 2.4.
Modelo 1
Gerenciamento de TI Gestão de negócios
O negócio
Recursos de TI produtos de TI O negócio
produtos
e serviços Recursos
e serviços
Modelo 2
Modelo 3
Transformação digital
Gestão de negócios digitais
Digitais e analógicos Produtos e serviços

recursos de negócios de negócios digitais
Figura 2.4 Transformação digital e transformação de TI
13
O provedor de serviços de TI e o consumidor de serviços podem transformar seu gerenciamento, recursos, produtos e serviços. Essas
transformações podem estar inter-relacionadas, mas não alteram significativamente a maneira como essas organizações trabalham
juntas ou o papel da TI na organização consumidora de serviços. Isso é mostrado como Modelo 2 na Figura 2.4.
Quando as organizações passam por uma transformação digital, o papel da tecnologia digital no negócio do consumidor de serviços
muda significativamente. Isso inclui alguns ou todos os itens a seguir:
• digitalização dos produtos e serviços da organização
• digitalização das práticas de gestão da organização
• digitalização de uma parte significativa dos recursos da organização
• integração da gestão de TI na gestão de negócios; desenvolvimento de uma parceria com o provedor de serviços de TI ou a fusão
de práticas de gestão.
Essa transformação digital é mostrada como Modelo 3 na Figura 2.4.
Onde negócios e TI não são considerados funções organizacionais separadas, como é o caso da maioria das organizações
digitais, 'transformação de TI' não é um termo apropriado a ser usado. 'Transformação digital' seria usado em seu lugar.
Muitas das abordagens e técnicas descritas nesta publicação são orientadas a software e podem parecer menos relevantes para os
profissionais de operações de TI. No entanto, à medida que as plataformas físicas mudam para tecnologias orientadas por código, como
nuvem, virtualização, conteinerização e infraestruturas sem servidor, é essencial que esses profissionais se tornem competentes na
aplicação de técnicas de engenharia de software. Cada vez mais, os profissionais usam scripts, código e sistemas de controle de versão,
como o GitHub, para fazer e gerenciar alterações, em vez de implementá-las manualmente. Portanto, é crucial que os profissionais em
ambientes HVIT adotem uma abordagem de engenharia de software.
Produtos e serviços digitais são baseados em software, o que é outra razão para os profissionais de operações de TI investirem em
mais conhecimento de engenharia de software. O software é uma preocupação de negócios tão primária que muitos bancos, por
exemplo, se consideram empresas de software com licença bancária. Essa importância crescente levou a uma mudança na política de
terceirização, onde o desenvolvimento e o gerenciamento de aplicativos geralmente são executados como parte integrante da linha de
produtos/serviços ou da linha de negócios que usa a tecnologia digital. Isso é ilustrado na Figura 2.5:
• Em uma função de TI descentralizada, cada unidade de negócios tem uma função de TI integrada e gerencia seus serviços de TI.
• Um departamento de TI atuando como provedor de serviços centralizado atende a várias unidades de negócios e gerencia a maioria
de seus próprios serviços de TI.
• Um departamento de TI atuando como um integrador de serviços centralizado atende a várias unidades de negócios e combina seus
próprios serviços de TI com aqueles adquiridos de provedores de serviços externos.
• Quando a TI está integrada às unidades de negócios, elas se concentram no gerenciamento de serviços de negócios digitais.
Os profissionais que trabalham em funções de TI descentralizadas que são parte integrante de uma linha de negócios terão conhecimento
e competências em mais domínios do que aqueles que trabalham em unidades especializadas. Esses domínios incluem engenharia de
software e a própria linha de negócios. Esses profissionais não trabalham mais com o conceito de prestação de serviços a outros
departamentos: em vez disso, trabalham com seus colegas de trabalho para prestar serviços a clientes externos.
14
TI descentralizada
Limite da empresa
serviços de TI Unidade de negócio
TI como um provedor de serviços centralizado

Limite da empresa
Unidade de negócio

Centralizado
serviços de TI TI
serviços de TI como provedor Unidade de negócio
TI como um integrador de serviços compartilhados

Limite da empresa

TI centralizada
como integradora
TI integrada
Limite da empresa
Negócios e TI integrados
Figura 2.5 Exemplos de opções de sourcing para uma função de TI
15
A história da ITIL: transformação digital

Henri: Nosso objetivo na Axle Car Hire é introduzir novos serviços com base na evolução dos requisitos dos clientes e
continuar a integrar a tecnologia para melhorar nossos serviços. Quando nos adaptamos às preocupações ambientais,
otimizamos a jornada do cliente, aumentamos a personalização do serviço e mudamos nossos serviços, garantimos que
estamos refletindo as tendências atuais do consumidor.
Marco: Recentemente, fizemos a transição de nossos serviços de uma infraestrutura local para uma solução de
nuvem híbrida. Essa foi uma grande reformulação para nossa equipe de TI. Tivemos que atualizar nossos scripts, códigos
e sistemas de controle de versão. Agora podemos oferecer melhor funcionalidade entre departamentos para nossos
clientes internos, e nossas equipes de negócios não estão trabalhando em silos.
Solmaz: Nossa transição para a solução de nuvem híbrida não foi uma mudança única e grande. Para obter os
melhores propósitos de controle de alterações, garantimos que poderíamos fazer uma série de alterações menores e
direcionadas que pudessem ser exaustivamente testadas antes da implantação e que pudessem ser continuamente
revisadas e revisadas.
2.5 2.5.1
Objetivos de TI de alta velocidade e principais características
Objetivos de TI de alta velocidade
A tecnologia é estratégica para os modelos de negócios das organizações digitais e, como tal, demandas mais altas são colocadas no
ciclo de vida de seus produtos digitais. Essas demandas podem ser representadas por cinco objetivos de alto nível que traduzem a visão
e a estratégia de uma organização em objetivos e indicadores mais operacionais. Esses objetivos são:
• investimentos valiosos
• desenvolvimento rápido
• operações resilientes
• valor cocriado
• conformidade garantida.
É importante lembrar que esses objetivos não devem ser gerenciados isoladamente; eles influenciam uns aos outros e interagem uns com
os outros, e precisam ser gerenciados coletivamente. Eles estão descritos na Tabela 2.1.
Tabela 2.1 Objetivos HVIT
Objetivo Descrição Atividades da cadeia de valor de serviço intimamente relacionadas
Investimentos valiosos Aplicação estrategicamente inovadora e eficaz de TI Envolver, planejar, melhorar
Desenvolvimento rápido Rápida realização e entrega de serviços de TI e Envolver, projetar e fazer a transição, obter/construir, melhorar
produtos relacionados a TI
Operações resilientes Serviços de TI altamente resilientes e produtos relacionados a TI Envolver, entregar e apoiar, melhorar
Valor cocriado Interação efetiva entre provedores de serviços e consumidores de Envolver, entregar e apoiar, melhorar
serviços
Conformidade garantida Aderência aos requisitos de governança, risco e conformidade (GRC) Todas as atividades da cadeia de valor
16
Como a Tabela 2.1 mostra, cada objetivo está intimamente relacionado a uma ou mais atividades da cadeia de valor de serviço ITIL, exceto
para conformidade garantida, que se relaciona ao componente de governança do sistema de valor de serviço ITIL e se aplica a todas as
atividades. A relação dos objetivos com as atividades da cadeia de valor é a seguinte:
• O objetivo de investimentos valiosos é alcançado principalmente pela tomada de decisão que ocorre como parte do plano
atividade da cadeia de valor.
• O objetivo de desenvolvimento rápido é alcançado principalmente pelo desenvolvimento e infraestrutura de aplicativos

engenharia que ocorre como parte das atividades de projeto e transição e obtenção/construção da cadeia de valor.
• O objetivo de operações resilientes é alcançado principalmente executando e mantendo o sistema como parte do
entregar e apoiar a atividade da cadeia de valor.
• O objetivo de valor cocriado é alcançado principalmente por meio do suporte ao sistema como parte da entrega e
apoiar a atividade da cadeia de valor (juntamente com o uso efetivo pelo consumidor do serviço).
• O objetivo de conformidade garantida é alcançado pela atenção à conformidade com as normas corporativas e regulatórias
diretivas como parte de todas as atividades da cadeia de valor, não apenas durante a entrega e suporte.
Assim como o objetivo de conformidade garantida é apoiado por todas as atividades da cadeia de valor, as atividades de engajamento e
melhoria da cadeia de valor contribuem para todos os objetivos de HVIT.
Em alguns casos, haverá conflitos entre os diferentes objetivos. Por exemplo, o desenvolvimento rápido pode afetar negativamente as
operações resilientes onde não há tempo suficiente para garantir que os serviços e produtos sejam robustos. Por esse motivo, é importante
garantir que os objetivos sejam adequadamente equilibrados.
O objetivo de investimentos valiosos determina o valor potencial de um investimento. Os investimentos podem ser feitos em diversas áreas,
mas, em última análise, os retornos e os benefícios devem ser avaliados em relação aos outros quatro objetivos. À medida que a organização
progride, ela incorrerá em custos adicionais e poderá sofrer perda de valor onde as soluções e os benefícios forem considerados abaixo do ideal.
O benefício real realizado é a diferença entre o valor potencial do investimento e os custos e a perda de valor. O retorno sobre o investimento
pode então ser expresso como o benefício realizado comparado ao investimento organizacional. Isso é mostrado na Figura 2.6.
Máximo
possível
beneficiar
Velozes Co-criado
desenvolvimento valor
De valor
investimento
Custo
Benefício real realizado
Vazamento de valor
Confiante Resiliente
conformidade operações
Figura 2.6 Objetivos de uma perspectiva econômica
17
Magro Ágil
Cocriação
Contínuo Resiliente
Figura 2.7 Principais características do HVIT
2.5.2 Principais características da TI de alta velocidade
Existem muitas abordagens que podem ser adotadas para alcançar e manter o HVIT. Quatro características são dominantes em
abordagens HVIT comuns. Estes são:
• Lean
• Ágil
• resiliente
• contínuo.
Quando combinadas e utilizadas de forma adequada pelas organizações, essas características possibilitam a cocriação de valor,
conforme mostra a Figura 2.7.
Os benefícios de cada característica estão descritos na Tabela 2.2.
Tabela 2.2 Principais características da TI de alta velocidade
Característica Benefícios
Magro Ajuda a melhorar o rendimento e reduzir o desperdício. Os ambientes HVIT se beneficiam de abordagens com características
Lean devido à pressão no tempo de lançamento no mercado e no tempo de atendimento ao cliente.
Ágil Adiciona colaboração próxima e iterativa com os usuários. Abordagens com características ágeis são importantes para ambientes
HVIT porque produtos e serviços digitais precisam ser desenvolvidos em resposta às demandas de mercado mutáveis.
Resiliente Mantém a disponibilidade e o desempenho viáveis. Os sistemas que suportam ambientes HVIT são complexos e, portanto, propensos a erros.
Abordagens com características resilientes minimizam o efeito de incidentes ao degradar os sistemas gradualmente e restaurar o serviço
rapidamente.
Contínuo Garante uma implantação rápida e confiável. Abordagens com características contínuas estendem o foco Lean no rendimento,
padronizando e automatizando processos para integração, construção, teste e envio de código, permitindo que produtos e serviços
digitais estejam disponíveis quando necessário.
Quando usadas em conjunto, essas características levam à cocriação de valor, ampliando o foco de uma abordagem ao consumo
efetivo de serviços. O valor só é percebido quando o usuário realmente usa os produtos e serviços digitais. Uma abordagem que
usa todas as quatro características principais do HVIT ajudará o provedor de serviços a garantir que o consumidor do serviço
alcance os resultados desejados.
18
Essas características são de natureza técnica, concentrando-se mais nas partes tangíveis dos sistemas de informação (o produto), mas
muitos dos princípios também podem ser aplicados aos serviços de TI.
Isoladamente, essas características não são exclusivas do HVIT. Juntos, no entanto, eles ajudam a atender às demandas mais altas
que as organizações habilitadas digitalmente colocam em TI. Eles contribuem para:
• planejar os investimentos certos em produtos e serviços digitais
• o desenvolvimento e implantação rápidos e confiáveis desses produtos e serviços
• mantê-los operacionais
• garantir que os consumidores de serviços percebam o valor usando-os de forma eficaz.
Semelhante aos cinco objetivos do HVIT, cada característica do HVIT está relacionada a várias ou todas as atividades da cadeia de valor
do serviço ITIL. Isso está descrito na Tabela 2.3.
Tabela 2.3 Resumo da influência das características HVIT nas atividades da cadeia de valor do serviço ITIL
Plano Melhorar Se empenhar Projeto e Obter/construir Entregue e

transição dê suporte
Magro ÿ ÿ ÿ
Ágil ÿ ÿ ÿ ÿ
Resiliente ÿ ÿ ÿ
Contínuo ÿ ÿ ÿ ÿ ÿ
2.5.2.1 Enxuto
As abordagens com características Lean se concentram em dividir grandes peças de trabalho em lotes menores. Um lead time curto é a melhor
maneira de garantir a qualidade, a satisfação do cliente e a felicidade dos funcionários, e uma boa maneira de alcançar lead times curtos é usar
pequenos tamanhos de lote de trabalho. Portanto, é benéfico quebrar pedaços maiores de trabalho em menores. Isso geralmente apresenta
um desafio diferente para o trabalho organizado em lotes maiores que são passados entre funções com procedimentos formais de transferência.
Os tamanhos de lote pequenos ajudam a reduzir o efeito disruptivo das alterações nos sistemas do produto. Quanto menor a mudança,
menor o risco de interrupção. Reduzir o tamanho das alterações também significa que elas podem ser executadas com mais frequência.
Uma maior frequência de mudança melhora a capacidade de mudança de uma organização, o que também reduz o risco de interrupção dos
sistemas operacionais. Isso, por sua vez, ajuda a reduzir a tensão organizacional entre os objetivos HVIT de desenvolvimento rápido e
operações resilientes.
Outra técnica Lean para melhorar o rendimento é reduzir o trabalho em andamento. A Figura 2.8 mostra um exemplo dessa técnica, baseada
em um fluxo de valor com uma série de 'estações de trabalho'. Eles consistem em indivíduos, equipes ou departamentos encarregados de
executar o trabalho com base na entrada de outra estação de trabalho e, em seguida, entregar sua saída para a próxima estação de trabalho.
Em vez de utilizar cada estação de trabalho em um fluxo de valor para a capacidade máxima e 'empurrar' o trabalho para a próxima estação
de trabalho, o trabalho deve ser 'puxado' quando uma determinada estação de trabalho requer entrada. Embora a eficiência (utilização) das
estações de trabalho possa parecer baixa, isso é benéfico para o fluxo de trabalho através do fluxo de valor.
Posto Posto Posto

Ordem de serviço Fluxo Fluxo Produto/serviço
de trabalho de trabalho de trabalho
Figura 2.8 Um fluxo de valor com três estações de trabalho
19
Os quadros Kanban podem ser usados para dar suporte a essa maneira de trabalhar, fornecendo uma visualização da lista de pendências do
trabalho, do trabalho em andamento e do trabalho concluído.
A teoria das restrições oferece a seguinte orientação sobre como melhorar o rendimento:
• Identifique a estação de trabalho mais fraca no fluxo de valor.
• Alivie a carga o máximo possível.
• Organize o trabalho em torno do elo mais fraco. A estação de trabalho menos produtiva determina o quão rápido cada outra estação de
trabalho deve trabalhar para atingir o rendimento máximo. Isso é importante, pois cada estação de trabalho (ou equipe funcional) no
fluxo de valor opere de forma eficiente com produtividade máxima, muitas vezes resultará em um acúmulo de trabalho para a próxima
estação de trabalho.
2.5.2.2 Ágil
Com base no princípio Lean de que pequenos lotes de trabalho são benéficos para o rendimento, as abordagens com características ágeis se
concentram na entrega de pequenas iterações de produtos ou serviços, em incrementos frequentes, para que a abordagem possa ser ajustada
em resposta às mudanças no ambiente. Nessas abordagens, o feedback, na forma de informação, é coletado o mais rápido possível e as
decisões são adiadas o máximo possível.
As técnicas ágeis são focadas em conversas e interações contínuas entre desenvolvedores de software, pessoas de negócios e outras partes
interessadas que melhoram a experiência do cliente. Esta descrição refere-se ao desenvolvimento de software, onde a forma Ágil de trabalhar
evoluiu, mas também pode ser aplicada a outros domínios de trabalho.
O software é desenvolvido por equipes pequenas, relativamente independentes, auto-organizadas e multifuncionais nas quais um
representante do usuário (geralmente chamado de proprietário do produto) desempenha um papel importante. As equipes de desenvolvimento
são confiáveis para executar esse trabalho, o que significa que a função de gerenciamento pode mudar de controle para facilitação, criando um
ambiente mais produtivo (isso é frequentemente chamado de 'liderança servidora'). Isso geralmente é desafiadoramente diferente de organizar
o trabalho em equipes funcionais especializadas, como design, desenvolvimento, implantação e operações.
Pequenas equipes com membros treinados em forma de T (membros com amplo conhecimento geral e profunda especialização em
uma área; mais informações sobre isso podem ser encontradas em ITIL® 4: Criar, Entregar e Suporte) podem levar a um número reduzido
de transferências entre pessoas. Isso ajuda essas equipes a serem altamente eficazes e melhora o fluxo de trabalho. No entanto, quando
diferentes tipos de tarefas são combinados e executados por uma única pessoa, existe o risco de que uma tarefa seja executada com base
em princípios apropriados para um tipo de tarefa, mas não para aquela que deve ser executada. Por exemplo, o conhecimento técnico é
importante para a codificação, enquanto a empatia é necessária ao responder às solicitações do usuário. Um agente de serviço que realiza
várias tarefas entre analisar logs de eventos e responder a chamadas de usuários corre o risco de exibir o comportamento errado em
determinadas situações. Isso pode ser mitigado reforçando fisicamente uma mudança de persona por meio de um ritual ou artefatos; por
exemplo, movendo-se para outra sala para atender chamadas de usuários ou vestindo um uniforme ou crachá para indicar uma função específica.
O proprietário do produto gerencia um backlog de trabalho, que é priorizado de acordo com seu valor. Este valor pode ser determinado
estimando o custo de atraso de cada item de trabalho.
Definição: Custo do atraso
Os benefícios que se espera que sejam perdidos quando o lançamento ou a atualização de uma oferta de serviço for adiada.
20
Ao gerenciar o trabalho, pode ser benéfico ter um entendimento comum entre várias partes interessadas (como desenvolvimento,
suporte e conformidade) sobre quando o trabalho é considerado concluído. Isso é chamado de 'definição de feito' e compreende os
critérios discutidos e acordados que especificam a utilidade e a garantia exigidas de um produto ou serviço proposto. No
desenvolvimento de software Agile, 'pronto' geralmente significa ter incrementos de software que são potencialmente implantáveis.
O DevOps estende essa definição de apenas software implantável para três categorias: implantado, lançado e disponível para uso.
De uma perspectiva de serviço de cocriação, uma maneira melhor de definir o trabalho como 'feito' é quando os usuários alcançaram
os resultados desejados de seus investimentos (consulte a seção 4.3.3 para obter mais detalhes sobre a definição de 'feito').
Os métodos de DevOps baseiam-se no desenvolvimento de software ágil e nas técnicas de gerenciamento de serviços,
enfatizando a estreita colaboração entre as funções de desenvolvimento de software e operações técnicas. Usando altos graus de
automação para liberar tempo de profissionais qualificados para que possam se concentrar em atividades de agregação de valor,
o DevOps é capaz de iluminar aspectos como operabilidade, confiabilidade e manutenibilidade de produtos de software que podem
auxiliar no gerenciamento de serviços.
2.5.2.3 Resiliente
As abordagens com características resilientes estão focadas em manter a disponibilidade e o desempenho viáveis e minimizar o
efeito dos incidentes. Dois exemplos de abordagens com características resilientes são a engenharia de confiabilidade do site (SRE)
e o DevOps.
O SRE aplica uma mentalidade de desenvolvimento de software às operações de TI e ajuda a preencher a lacuna entre o
desenvolvimento e as operações. As equipes SRE são criadas juntamente com as equipes existentes para operações de TI. Essas
equipes de SRE dividem seu tempo entre executar operações de TI e treinar equipes de operações de TI e desenvolver software
que ajude a aumentar a resiliência e o desempenho dos sistemas de TI.
DevOps e, mais explicitamente, DevSecOps, promovem a integração da segurança no trabalho diário de desenvolvimento de
aplicativos e operações de TI, em vez de tê-la como uma função de 'policiamento' separada. Aqui, a função do responsável pela
segurança muda da especificação de requisitos e monitoramento do desempenho para permitir que os profissionais abordem as
questões de segurança. Isso permite que as coisas sejam feitas de forma mais rápida e eficaz, mas muitas vezes envolve um salto
de fé desafiador em confiar aos profissionais essa tarefa.
O DevOps também promove o monitoramento proativo dos sistemas de TI em produção. Esse monitoramento proativo está
altamente correlacionado com um tempo médio para restaurar o serviço (MTRS) mais rápido. Existem muitas ferramentas
disponíveis que fornecem informações sobre sistemas operacionais. A relação sinal/ruído dessas informações deve ser considerada
com cuidado, pois as pessoas têm uma capacidade limitada de absorver informações. Não é apenas ineficaz, mas também um
fardo irracional esperar que as pessoas distingam entre quais informações são importantes e quais não são.
Outras abordagens para a resiliência incluem antifragilidade, arquitetura para resiliência em software e infraestrutura,
microsserviços, conteinerização, troca de recursos, teste de absorção e recuperação de desastres.
2.5.2.4 Contínuo
Abordagens com características contínuas, como integração, entrega e implantação contínuas (CI/CD), são baseadas na crença
de que lotes pequenos e frequentes de trabalho não são apenas mais valiosos porque a funcionalidade pode ser usada mais cedo,
mas são mais seguros porque a mudança é menor e o feedback é obtido mais cedo.
Integração contínua, entrega contínua e implantação contínua (CI/CD) são termos descritivos para uma coleção de práticas
principalmente associadas à engenharia de software, que são centrais para a filosofia de desenvolvimento de software Lean e
Agile. A adoção dessas práticas cresceu rapidamente e é importante entender as características definidoras de CI/CD no contexto
mais amplo de práticas de desenvolvimento de sistemas em evolução
21
ao implementar serviços que são sustentados pelo desenvolvimento de software. Estes são descritos em mais detalhes na
seção 4.2.5.
A chave para a integração, entrega e implantação contínuas é uma relação de trabalho saudável entre todas as partes envolvidas
e uma ampla automação:
• Automação de compilação (a fase de CI) Abrange o controle de versão e a fusão de vários desenvolvedores
alterações em um branch de código compartilhado.
• Automação de teste Testa e valida automaticamente cada alteração em ambientes semelhantes à produção .
• Provisionamento automático Instala e configura hardware e software para ativar o

serviços adquiridos.
• Automação de implantação Automatiza o processo de movimentação de código de ambientes de pré-produção para o ambiente
de produção.
• Teste pós-implantação Valida as propriedades funcionais e não funcionais, em particular desempenho/

teste de carga, que é difícil de testar antes da implantação.
2.5.2.5 Combinando características HVIT para co-criar valor
As organizações que são Lean, Agile, resilientes e contínuas estão mais bem equipadas para a cocriação de valor na forma de
serviços que podem ser facilmente adaptados para ambientes em constante mudança e necessidades dos clientes.
A ciência do serviço define serviço como a aplicação de recursos (incluindo competências, habilidades e conhecimento) para fazer
mudanças que tenham valor para outra organização. A ITIL define um serviço como um meio de permitir a cocriação de valor,
facilitando os resultados que os clientes desejam alcançar, sem que o cliente tenha que gerenciar custos e riscos específicos.
Independentemente de qual definição é aplicada, em qualquer serviço há pelo menos duas entidades que interagem (chamadas de
sistemas de serviço na ciência do serviço). Provedores de serviços e consumidores de serviços formam um exemplo simples de um
par de sistemas de serviços, mas existem outros, como órgãos reguladores. Um conceito central na ciência de serviço é a lógica de
serviço dominante.
Definição: lógica dominante de serviço
Um modelo mental de uma troca (econômica) em que as organizações cocriam valor aplicando suas competências e
outros recursos para o benefício umas das outras.
A lógica dominante no serviço considera o serviço como o processo de fazer algo para e com outra parte. A criação de valor é
um processo colaborativo. Na lógica dominante de serviço, o valor é sempre cocriado. A lógica dominante de serviço contrasta com a
lógica dominante de bens, na qual o provedor entrega valor ao cliente transferindo a propriedade dos bens.
Quando a lógica de serviço dominante é aplicada à entrega do serviço, o provedor presta mais atenção à situação específica do
cliente e envolve o cliente no processo de entrega do serviço. Essa é uma maneira mais eficaz de ajudar a realizar o trabalho do
cliente. A interação do serviço é focada no consumidor, e o consumidor cria valor quando integra e aplica os recursos do provedor
de serviço (e de outros sistemas de serviço) para realizar a troca. Cada consumidor determina o valor ou a qualidade da experiência
do serviço com base nas necessidades pessoais em um momento específico e em um contexto específico.
22
A história da ITIL: Principais características da TI de alta velocidade
Solmaz: Na Axle, nos orgulhamos de poder nos adaptar rapidamente às mudanças na demanda e nas oportunidades. Os
serviços prestados por nossa tecnologia criam valor não apenas para nós, mas para todos os nossos stakeholders: nossos
parceiros, fornecedores e clientes.
Henri: Garantimos que nossos investimentos em tecnologia estejam alinhados com nossos objetivos e cumpram os
requisitos de governança, regulamentação e conformidade.
Marco: Nossas escolhas de tecnologia refletem as quatro características da TI de alta velocidade: Lean, Agile, resiliente e
contínua. Dados os extensos dados que coletamos sobre nossos clientes, garantimos que nossos dados e tecnologia sejam
resistentes a ataques cibernéticos e estáveis sob pressão. Trabalhamos em pequenos lotes, adaptando cada alteração aos
requisitos do cliente e empregamos integração, entrega e implantação contínuas. Também monitoramos nossos processos
para reduzir o desperdício de esforços sempre que possível.
2.6 Adotando o sistema de valor de serviço ITIL para permitir

O HVIT alinha o trabalho relacionado a TI de alto valor com negócios de alta velocidade, da inovação à realização de valor. Isso requer fluxo
rápido, feedback rápido e melhoria rápida, e não apenas resulta em coisas sendo feitas mais rapidamente, mas também melhora a qualidade
dos produtos e serviços relacionados a TI. Isso tem implicações significativas para os modelos operacionais de TI organizacionais. As organizações
habilitadas digitalmente definem e estruturam suas atividades e recursos relacionados à TI de maneira diferente das organizações nas quais a TI
tem menos importância estratégica. As demandas mais altas que as organizações habilitadas digitalmente colocam na tecnologia se refletem na
maneira como operam. Por exemplo, uma organização habilitada digitalmente pode ter equipes baseadas em produtos/serviços relativamente
independentes, em vez de uma estrutura organizacional funcional, e um maior apetite por experimentações iterativas rápidas e falhas.
Esta seção ilustra como a orientação ITIL pode ser usada para fornecer blocos de construção para um modelo operacional de TI que define o
trabalho de HVIT e sua organização.
Um modelo operacional é o 'back-end' do modelo de negócios de uma organização e entrega as propostas de valor definidas nesse modelo de
negócios. O modelo operacional é uma representação dos blocos de construção de uma organização e os relacionamentos entre eles. Ele pode
ser usado como uma descrição do estado atual da organização ou como um projeto de estado futuro, conhecido como 'modelo operacional de
destino'.
Definições
• Modelo operacional Uma representação conceitual e/ou visual de como uma organização cocria valor com seus clientes e outras
partes interessadas, bem como como a organização se administra.
• Modelo operacional de TI de alta velocidade Um modelo operacional de TI em que a tecnologia digital desempenha um papel importante
na cocriação de valor.
23
Uma abordagem de alta velocidade é normalmente necessária para um modelo operacional quando há cocriação de valor com os clientes,
quando os modelos operacionais estão se tornando significativamente mais digitais ou em resposta a circunstâncias incertas, ambíguas
e em rápida mudança. Muitas vezes, há tanto valor, se não mais, no processo de criação do modelo operacional quanto no produto final.
Um modelo operacional HVIT é aquele em que a tecnologia digital desempenha um papel importante na cocriação de valor. Todos os
modelos operacionais têm alguns elementos digitais, mas um modelo operacional digital é aquele em que a tecnologia digital torna possível
um modelo que de outra forma não é viável ou prático sem ela.
Os modelos operacionais para organizações habilitadas digitalmente são caracterizados por seu foco em:
• fluxos de valor dedicados para cada um de seus produtos e serviços
• cultura de cocriação que promove alto desempenho e melhoria contínua
• equipes permanentes baseadas em produtos/serviços em vez de equipes temporárias de projeto
• automação de processos de TI, incluindo infraestrutura como código.
Na ITIL, os fluxos de valor estão no centro do modelo operacional porque são os conjuntos de etapas necessárias para entregar
produtos e serviços. HVIT pode ser suportado por muitos elementos do sistema de valor de serviço ITIL (veja a Figura 2.9).
As seções a seguir descrevem como o HVIT se relaciona com os conceitos de:
• produtos e serviços digitais
• ciclos de vida de produtos digitais
• a cadeia de valor do serviço ITIL
• fluxos de valor
• Práticas de gerenciamento ITIL
• as quatro dimensões do gerenciamento de serviços
• fatores externos
• governança e gestão.
Princípios orientadores
Governança
Oportunidade/ Cadeia de valor do serviço Valor

exigem
Práticas
Contínuo
melhoria
Figura 2.9 O sistema de valor de serviço ITIL
24
As organizações HVIT também podem se beneficiar da aplicação dos princípios orientadores da ITIL. Esses princípios, e como eles podem
ser usados, são discutidos com mais detalhes no Capítulo 3.
2.6.1 Produtos e serviços digitais

A ITIL define um produto como uma configuração dos recursos de uma organização projetados para oferecer valor para um consumidor.
O produto é fornecido ao consumidor por meio de serviços que possibilitam a cocriação de valor por ambas as partes. Esses serviços se
manifestam para o consumidor como uma combinação de aquisição de bens, uso de recursos (tangíveis) do provedor e interação com o
provedor. O valor é cocriado durante a prestação e consumo do serviço, quando o consumidor aplica seus próprios recursos para utilizar o
produto.
Alguns produtos podem ser definidos como digitais.
Definição: produto digital
Um produto é digital quando a tecnologia digital desempenha um papel significativo em seus bens, recursos ou interações de serviços
associados.
No sentido da definição de produto digital, um papel significativo geralmente significa que, sem a tecnologia, o produto não existe ou carece de
recursos ou características críticas.
Os serviços são baseados em um ou mais produtos e podem oferecer experiências de usuário digitais e analógicas. Exemplos de serviços
baseados em produtos digitais incluem serviços bancários on-line, compartilhamento de viagens, comércio eletrônico, ingressos eletrônicos
para eventos, armazenamento e compartilhamento de fotos e vídeos, e-learning, reserva e gerenciamento de voos de companhias aéreas,
streaming de música, aplicativos para smartphones e câmeras digitais . À medida que os algoritmos digitais se tornam mais sofisticados, no
entanto, a experiência analógica normalmente será apenas para lidar com circunstâncias excepcionais que excedem o escopo do algoritmo.
Para cocriar valor, fornecedores e consumidores se envolvem em uma interação de serviço. Uma interação de serviço é o que ocorre
quando um consumidor faz uso real da oferta de serviço de um provedor, que é baseada nos produtos do provedor e outros recursos.
Uma interação de serviço entre um consumidor e um provedor é uma combinação de três tipos de interações:
• Ações de serviço Onde (em resposta a uma solicitação ou proativamente) o provedor de serviços aplica seus recursos, por exemplo,
fornecendo informações sobre o uso de um serviço de TI. As organizações HVIT usam produtos digitais para automatizar grandes
volumes de ações de serviço e interações com os consumidores para maior eficiência e eficácia.
• Acesso a recursos Onde o consumidor do serviço utiliza os recursos do provedor de serviços, por exemplo, fazendo login em um site. As
organizações HVIT fornecem acesso aos seus recursos ou acessam os recursos do consumidor usando canais fornecidos por produtos
digitais.
• Transferência de mercadorias Quando o consumidor do serviço adquire a propriedade dos recursos do provedor de serviços, por
exemplo, comprando um laptop. As organizações HVIT normalmente não oferecem bens físicos como parte de seus produtos e serviços
digitais.
A visão que o provedor e o consumidor têm dos recursos um do outro é chamada de 'faixa de visibilidade'.
Alguns recursos são visíveis para a outra parte e alguns estão ocultos ou 'invisíveis'. Durante uma interação de serviço, o consumidor interage
com alguns dos recursos do provedor e é afetado por outros recursos 'invisíveis' usados pelo
25
Provedores de serviço Consumidor de serviço

Recursos Recursos
Serviço
interação
Ações de serviço
Acesso a recursos
Transferência de mercadorias
Faixa de visibilidade
Figura 2.10 Interação do serviço e a faixa de visibilidade
provedor que desempenha um papel indireto na interação do serviço. Da mesma forma, o provedor de serviço interage com alguns
dos recursos do consumidor de serviço e é indiretamente afetado pelos recursos 'invisíveis' do próprio consumidor de serviço.
A largura da faixa de visibilidade é crucial para a experiência do serviço e a eficácia da interação do serviço. Se for muito
amplo, qualquer uma das partes pode se sentir confusa ou distraída por eventos que não têm relevância ou relevância para a
interação. Se for muito estreito, qualquer uma das partes pode se sentir frustrada pela falta de informação e influência. Um
equilíbrio delicado deve ser alcançado, e a maneira correta de lidar com isso varia entre diferentes provedores e consumidores. Para
lidar com isso de forma eficaz, cada parte deve ser capaz de perceber as necessidades da outra e ajustar sua abordagem
adequadamente. As organizações HVIT geralmente usam uma rede complexa de seus próprios produtos e serviços, juntamente com
os fornecidos por parceiros e fornecedores. Nesse ecossistema, os provedores normalmente têm maior visibilidade dos recursos do
consumidor do que vice-versa.
Um exemplo de interação de serviço e a faixa de visibilidade é mostrado na Figura 2.10.
Mais informações sobre a faixa de visibilidade podem ser encontradas em ITIL® 4: Drive Stakeholder Value.
2.6.2 Ciclos de vida de produtos digitais
Consumidores e provedores de serviços têm perspectivas diferentes sobre produtos digitais. Cada um deles tem seus próprios
ciclos de vida de produtos, que se sobrepõem durante o período de engajamento entre o consumidor e o fornecedor. Para o provedor
de serviços, o ciclo de vida de um produto dura enquanto houver clientes em potencial para esse produto.
Para o consumidor de serviço, o ciclo de vida continua enquanto o produto for usado e, estritamente falando, é um ciclo de vida
de uso do produto.
Do ponto de vista de um consumidor de serviços, o ciclo de vida de um produto digital começa com a exploração do mercado para
possíveis soluções para uma determinada demanda. Esses consumidores podem ser caracterizados em termos de
26
Psicográfico do consumidor
…… – Segurança – Poder – Status – Novidade – Afiliação……
–
Exp ore
o Exp
eu eu
ré
Cocriar
o re Exp
Exp
eu
ore
eu
Consumidor-fornecedor
interações
Figura 2.11 Ciclo de vida do produto digital de duas perspectivas: consumidor e fornecedor
psicografia mapeando seus traços de personalidade compartilhados, crenças, valores, atitudes, interesses, estilos de vida e outros fatores.
O provedor de serviços geralmente os considera ao projetar e oferecer um produto ou serviço.
Do ponto de vista de um prestador de serviços, o ciclo de vida de um produto inicia-se com a exploração de oportunidades de
mercado para investimento em novos produtos, quando se busca potenciais clientes para produtos existentes.
Em um determinado momento, o consumidor e o provedor de serviços se descobrirão e se envolverão, às vezes levando a uma
transação.
Antes que um serviço possa ser prestado e consumido, há atividades de integração, onde os preparativos são feitos em ambos os lados.
Em seguida, o provedor e o consumidor começam a interagir, usando o serviço para cocriar valor, até que uma das partes anuncie o fim
do compromisso. Isto é seguido por atividades de offboarding e desengajamento.
Há muitos motivos válidos para o término de uma relação de serviço, incluindo:
• o consumidor não tem mais demanda pelo produto
• o consumidor está insatisfeito com o fornecedor
• o provedor não pode atender à demanda alterada
• o provedor retira um produto não lucrativo.
A Figura 2.11 ilustra como os consumidores e provedores de serviços têm seus próprios ciclos de vida de produtos digitais. O consumidor
de serviço contrata o provedor de serviço, possivelmente como substituto de um provedor de serviço anterior. Após o período de
contratação, o contrato é rescindido e o consumidor do serviço substitui o prestador de serviço por outro, ou não precisa mais de um
prestador de serviço.
Em um nível mais detalhado, a jornada do cliente compreende sete interações:
• Explorar Compreender os mercados e as partes interessadas.
• Envolver relacionamentos Foster.
• Oferta Formar a demanda e as ofertas de serviços.
• Concordar Alinhar as expectativas e concordar com o serviço.
• A bordo Suba a bordo ou saia da viagem.

• Cocriar Fornecer e consumir.
• Perceba o valor da colheita e melhore.
Um modelo da jornada do cliente é mostrado na Figura 2.12. Mais informações sobre a jornada do cliente podem ser encontradas em
ITIL® 4: Drive Stakeholder Value.
27
Explorar Se empenhar Oferta Aceita Co-criar a bordo Realize
Cliente
Provedor de serviço
Serviço Linha de Banda de

interação visibilidade visibilidade
Figura 2.12 Modelo de jornada do cliente
Quando um provedor de serviço é substituído, há um período de transição para ambas as partes, antes que o serviço do
novo provedor possa ser fornecido e consumido. O consumidor do serviço geralmente requer assistência e garantia na
transferência do serviço do provedor de serviços atual para o novo.
Quando o consumidor ainda tem demanda por uma solução, ele se depara com a tarefa de offboarding do produto insatisfatório
ou aposentado, paralelamente à onboarding de seu substituto. O risco de descontinuidade é uma preocupação séria.
Para reduzir essa preocupação, os provedores às vezes se oferecem para cuidar da transição do provedor atual para o
sucessor. A Figura 2.13 mostra a perspectiva do consumidor sobre os ciclos de vida dos produtos digitais.
A Tabela 2.4 descreve os estágios do ciclo de vida de um produto digital da perspectiva do provedor de serviços e do
consumidor de serviços.
Cocriar Cocriar Cocriar

Fora de bordo A bordo Fora de bordo A bordo
Figura 2.13 Ciclos de vida de produtos digitais da perspectiva do consumidor
Tabela 2.4 Etapas do ciclo de vida do produto digital
Fase do ciclo de vida Provedor de serviço Consumidor de serviço
Exploração O provedor de serviços pesquisa e desenvolve a oferta de produtos O consumidor do serviço toma conhecimento da existência de um produto
e serviços. e o avalia como interessante e depois desejável, após o que é feito um

acordo.
Integração Uma instância do produto é instalada e a organização do usuário é integrada, às vezes com uma transição de um produto substituído.
Cocriando valor O provedor de serviços entrega e suporta o produto e experimenta um retorno crescente, O consumidor de serviço usa o produto e experimenta um
estável ou decrescente do investimento, levando a uma decisão de valor crescente, estável ou decrescente, eventualmente levando a uma
investimento de comprar (usar e melhorar o produto), manter (usar, mas não decisão de substituir ou aposentar o produto.
melhorá-lo) ou vender (usar e reduzir, substituir ou aposentar).
Desembarque A instância do produto é desinstalada e a organização do usuário é desvinculada, às vezes com uma transição para um produto de substituição.
Aposentado O provedor de serviços não oferece mais ou oferece suporte ao O consumidor do serviço não usa mais este produto, mas outros
produto. consumidores podem usá-lo.
28
velo
Capí
alta
Prin
con
de
TI
–
2 Demanda
Interação
Recursos
Recursos
Produtos
Oferta
Se empenhar
Plano
Projeto
e transição
Obter/construir Entregar e dar

suporte
Outro
serviço
fornecedor
Recursos
Produtos
Oferta
Valor
Serviço
consumidor
Oferta
Produtos
Recursos
Melhorar Outro
serviço
fornecedor
Figura 2.14 A cadeia de valor do serviço ITIL
2.6.3 A cadeia de valor do serviço ITIL
As atividades necessárias para entregar produtos e serviços são modeladas pela cadeia de valor de serviço da organização e pelas
práticas. A cadeia de valor do serviço descreve as atividades arquetípicas da organização (veja a Figura 2.14).
A cadeia de valor do serviço ITIL é útil para descrever, em um nível bastante alto de abstração, os tipos de atividades que um provedor
de serviço executa. Ajuda as pessoas a se concentrarem no objetivo de cada atividade da cadeia de valor e nas entradas e saídas, sem se
perder nos detalhes das atividades de nível inferior em um fluxo de valor.
As atividades da cadeia de valor estão intimamente relacionadas e podem ser organizadas em qualquer ordem para explicar e discutir
uma série de situações diferentes.
2.6.3.1 Atividades da cadeia de valor e DevOps
Em ambientes HVIT, o conceito de 'contínuo' é frequentemente usado e é uma característica chave de muitas abordagens HVIT.
'Contínuo' refere-se a ciclos rápidos e iterativos de atividades, possibilitados por ciclos de feedback curtos. CI/CD é um exemplo bem
conhecido disso, onde novos incrementos de software fluem por parte de um fluxo de valor sem atraso, habilitado por um alto grau de
automação.
A comunidade DevOps geralmente ilustra isso usando uma figura de oito com um loop contínuo de desenvolvimento de aplicativos
conectados e atividades de operações de TI, conforme mostrado na Figura 2.15. As atividades Dev e Ops são habilitadas por
infraestrutura e plataformas para codificação, teste, implantação, produção e assim por diante.
Esse loop pode ser usado juntamente com as atividades da cadeia de valor do serviço ITIL para fornecer uma perspectiva combinada
de DevOps e ITIL. Na terminologia ITIL, o DevOps se concentra no desenvolvimento, implantação e execução de componentes de
serviço concretos em vez de serviços intangíveis. Os componentes de serviço dominantes no DevOps são os aplicativos, dados e
plataformas que, juntos, formam um produto para o consumidor.
29
Código Liberar
Desenvolvedor
Operações
Teste Monitor
A infraestrutura
Figura 2.15 Atividades de DevOps em um loop contínuo
O foco da cadeia de valor do serviço está nos produtos e serviços, e não nos componentes individuais do serviço. Ele descreve
o que é necessário para a interação entre os produtos do provedor de serviços e outros recursos, incluindo os recursos do
consumidor do serviço.
A Figura 2.16 mostra como o loop de DevOps e as atividades da cadeia de valor do serviço podem ser combinadas. Algumas
atividades da cadeia de valor de serviço (como design e transição) foram divididas em duas 'subatividades' que são mais fáceis
de mapear para partes do modelo DevOps.
Se empenhar
Projeto Apoiar
Obtivermos Entregar
Código Liberar
Desenvolvedor
Operações
Construir
Teste Monitor
A infraestrutura
Figura 2.16 DevOps e a cadeia de valor do serviço
30
As atividades da cadeia de valor do serviço são vinculadas ao modelo DevOps na Figura 2.16 das seguintes maneiras:
• A atividade da cadeia de valor de design é executada em paralelo com o Dev, focando mais no serviço do que no produto de software.
• A atividade de obtenção da cadeia de valor é a interface com o Dev externo, integrando o produto de software desenvolvido com os demais
recursos que compõem o serviço.
• A atividade da cadeia de valor de construção corresponde ao desenvolvimento interno.
• A atividade da cadeia de valor de transição é executada em paralelo e corresponde à implantação de Dev para Ops.
• A atividade da cadeia de valor de entrega e suporte corresponde às operações e geralmente é mais abrangente que as operações.
• A atividade da cadeia de valor de engajamento é executada em paralelo com todas as atividades subjacentes.
• A atividade da cadeia de valor do plano corresponde à parte de planejamento do Dev.
• A atividade de melhoria da cadeia de valor corresponde a um dos princípios do DevOps: experimentação, aprendizado e aprimoramento
contínuos em todas as atividades do DevOps (geralmente chamado de 'Terceira Via' do DevOps).
Este é um exemplo de como o HVIT pode ser aplicado à cadeia de valor do serviço, para ajudar a preencher a lacuna entre as disciplinas
profissionais, permitindo a discussão do trabalho de diferentes perspectivas. Para melhorar a colaboração entre as disciplinas, é importante
primeiro que cada disciplina entenda a perspectiva da outra e use ilustrações com as quais a outra disciplina esteja familiarizada. Uma vez
estabelecido isso, a discussão pode passar do entendimento para o entendimento.
2.6.3.2 Consumidor de serviço
Outra maneira pela qual o HVIT pode ser aplicado à cadeia de valor do serviço é ilustrando a proximidade entre os provedores de serviços e os
consumidores de serviços. Um consumidor de serviço considera a interação de alto nível com um provedor de serviço em termos de aquisição,
fornecimento e uso.
O consumidor traduz sua demanda em requisitos e contrata um provedor para fornecer serviços que eles usam para criar valor. Isso pode ser
representado como uma cadeia de valor de serviço da perspectiva do consumidor, conforme mostrado na Figura 2.17. Essa ilustração pode ser
expandida para incorporar a perspectiva do provedor de serviços em termos de atividades da cadeia de valor do serviço.
D Aquisição R Provisão S Usar V
D = Demanda R = Requisitos S = Serviço V = Valor
Figura 2.17 A perspectiva do consumidor de serviços
31
n
uma mp
EU
r
P v
Design e
transição
Obter/construir
R
Se empenhar
Demanda D Aquisição P Usar Valor V
Se empenhar
Entregar e
Apoio, suporte
Requisitos vr Serviço
Peu mp
uma
n EU
produtos
Figura 2.18 Cadeias de valor de serviço interagindo
A Figura 2.18 mostra as seis atividades da cadeia de valor do provedor de serviços, com projeto e desenvolvimento inicial na
metade superior e entrega e suporte (em paralelo com aprimoramento subsequente) na parte inferior. As interfaces primárias entre o
consumidor e o provedor são marcadas pelos requisitos do consumidor (R) e pelo serviço do provedor (S). Design e desenvolvimento e
entrega e suporte são conectados pelo produto (P) que é implantado.
A Figura 2.19 mostra como um fluxo de valor pode fluir pelas atividades da cadeia de valor. Assim como a vinculação das
atividades da cadeia de valor e o DevOps, essa combinação pode ser usada para promover melhores formas de trabalho (incluindo
como obter feedback mais rápido).
n
uma mp
EU
r
P v
Design e
transição
Obter/construir
R
Se empenhar
Demanda D Aquisição P Usar V Valor
Se empenhar
Entregar e
Apoiar
Requisitos vr Serviço
Peu mp
uma
n EU
produtos
Figura 2.19 Exemplo de fluxo de valor referente às atividades da cadeia de valor de serviço
32
2.6.4 Fluxos de valor

Um fluxo de valor é uma série de etapas que uma organização realiza para criar produtos e serviços e entregá-los aos
consumidores. São conjuntos de atividades que são realizadas de acordo com diretrizes (princípios, abordagens, técnicas, etc.) e
dentro de restrições (regulamentos, políticas, orçamentos, etc.).
É importante reconhecer que a cadeia de valor do serviço e as práticas associadas são modelos nos quais se baseiam os
fluxos de valor reais. Os fluxos de valor podem ser observados onde as pessoas e outros recursos agem para cocriar valor.
Cadeias de valor de serviço e práticas associadas não podem ser observadas, pois são representações abstratas usadas para
modelar os fluxos de valor.
Isso é mostrado na Figura 2.20, em um fluxo de valor que é acionado pela demanda por valor, que é cocriada usando produtos
e serviços. O fluxo de valor consiste em etapas nas quais os recursos são combinados resultando em produtos projetados para
permitir a criação de valor, não apenas para o consumidor do serviço, mas também para outros stakeholders.
As atividades realizadas pelos recursos são orientadas por diversos métodos adotados pela organização (descrições de fluxos de
valor e processos/procedimentos/instruções de trabalho nas práticas, descrições das atividades na cadeia de valor do serviço e
princípios norteadores).
A cadeia de valor de serviço descreve as atividades que são necessárias para gerenciar produtos e serviços de forma eficaz,
enquanto um fluxo de valor compreende uma série real de etapas para criar produtos e serviços e entregá-los aos consumidores.
Como tal, os fluxos de valor podem ser considerados onde as coisas realmente acontecem: onde as práticas ITIL são usadas e o
valor é cocriado. Não existe uma estrutura definida para fluxos de valor e eles são exclusivos para cada organização. As
organizações de HVIT geralmente são orientadas a produtos/serviços e têm vários fluxos de valor que refletem a diversidade de
seus produtos e serviços. Seus modelos operacionais compreendem, portanto, múltiplos fluxos de valor.
Método
Valor Valor
fluxos e corrente
Guia
Atividades princípios
processos
Consumidor de serviço
Serviço
ações
Etapa Etapa
Acesso a
Demanda Recursos Valor
produtos Transferir
de bens
Em formação Parceiros
Organizações e e
e pessoas tecnologia fornecedores
Recursos
Figura 2.20 O fluxo de valor no contexto
33
A palavra 'stream' indica a importância do rendimento: fazer o trabalho com rapidez e pontualidade. Muitos fatores podem
retardar as coisas em um fluxo de valor, incluindo transferências e sobrecarga, tornando o gerenciamento de filas muito
importante. O rendimento será beneficiado se cada tarefa for realizada por uma pessoa ou equipe, embora isso raramente seja o caso.
Também pode ser aumentado limitando o fluxo de trabalho de entrada à capacidade da 'estação de trabalho'. De uma
perspectiva de ponta a ponta, isso significa que a carga de trabalho deve ser equilibrada em todo o fluxo de valor.
Também é importante obter feedback o mais rápido possível, não apenas para fazer quaisquer melhorias que possam
ser necessárias, mas, crucialmente em um ambiente HVIT volátil, também para avaliar se a maneira de trabalhar ou
pensar precisa ser melhorada. Nesses ambientes dinâmicos, a melhoria do trabalho diário é tão importante quanto a
realização do trabalho diário.
Em ambientes HVIT, os sistemas geralmente são complexos e, portanto, imprevisíveis. Isso torna menos provável que
processos, procedimentos e instruções de trabalho detalhados sejam úteis, pois muitas vezes não serão seguidos. Também
não é útil ou viável prever ou ditar a sequência de etapas em um fluxo de valor e as atividades dentro dessas etapas, exceto
em um alto nível de abstração. Em vez disso, a sequência de atividades e etapas geralmente emergirá durante e como
resultado das 'micro-interações' que ocorrem durante a execução. Isso significa que os profissionais devem ser capazes de
observar as mudanças esperadas e inesperadas que suas ações e as dos outros fazem e ajustar suas próximas ações de
acordo. Essa maneira de trabalhar é mais exploratória do que confirmatória, mudando de previsão e controle para insight e
compreensão; de grandes mudanças ocasionais a pequenas e freqüentes; desde o planejamento detalhado com antecedência
até a constante experimentação e aprendizado; e de segurança contra falhas para segurança contra falhas.
Três aspectos-chave dos fluxos de valor são governança, execução e melhoria, conforme mostrado na Figura 2.21.
A governança se aplica tanto à execução quanto à melhoria e, por sua vez, a melhoria se aplica à execução e à governança.
Na execução, as operações recebem os recursos necessários e as operações e recursos são gerenciados. O fluxo de valor
está posicionado na execução e, portanto, é governado e aprimorado.
O fluxo de valor que é governado, gerenciado, dotado de recursos e continuamente aprimorado, juntamente com os recursos
que o orientam e possibilitam, pode ser considerado o núcleo do modelo operacional: é como uma organização cria valor
com seus clientes e outras partes interessadas. .
Governança Governança
Melhoria Melhoria
Execução Execução
Gestão
Fluxos Valor
de valor e corrente
Guia
Atividades princípios
processos
Serviço
ações
Etapa Etapa
Operações Demanda
Acesso a
Recursos Valor
produtos Transferir
de bens
Recursos
Informação e Parceiros
Organizações e
e pessoas
tecnologia fornecedores
Figura 2.21 Fluxo de valor posicionado em relação à governança, execução e melhoria
34
2.6.5 Práticas de gerenciamento ITIL

As práticas de gerenciamento da ITIL descrevem recursos e atividades necessários para cumprir propósitos específicos e formas geralmente
aceitas de gerenciar esses recursos e atividades.
As organizações fornecem serviços, e muitas vezes bens, que ajudam seus clientes. Isto implica a execução de um conjunto de atividades, com ou sem
o envolvimento direto do cliente. Para realizar essas atividades, tanto a organização quanto o cliente precisam ter certas habilidades. Essas habilidades
podem ser exclusivas de uma atividade específica ou podem ser exigidas por várias atividades, como manter um relacionamento efetivo entre si durante
cada estágio do trabalho. As habilidades envolvem a interação de uma combinação de pessoas e vários tipos de recursos.
Terminologia ITIL
As práticas ITIL representam a capacidade de uma organização de cumprir um propósito específico. Isso envolve recursos de todas as
quatro dimensões do gerenciamento de serviços. Uma prática pode ser apoiada por várias soluções organizacionais, incluindo equipes e
ferramentas dedicadas. Embora essas equipes e ferramentas possam ter os mesmos títulos das práticas das quais fazem parte, elas não
devem ser confundidas com elas.
Existem 34 práticas de gestão ITIL, agrupadas em três categorias:
• Práticas gerais de gerenciamento , como gerenciamento de mudanças organizacionais, são encontradas em muitos outros
domínios de negócios, mas também se aplicam ao gerenciamento de serviços.
• As práticas de gerenciamento de serviços estão no centro do gerenciamento de serviços e são descritas em detalhes para que o leitor não apenas
entenda a prática, mas também saiba como desenvolver e usar a habilidade necessária.
• As práticas de gerenciamento técnico estão intimamente relacionadas às práticas de gerenciamento de serviços porque se concentram nos
componentes do serviço: em outras palavras, os recursos técnicos que fazem parte de um serviço. Esses recursos técnicos são aplicativos, dados,
plataformas e infraestrutura.
Uma prática em si é apenas uma coleção de recursos que permite que uma organização faça algo. O valor só emerge de uma prática quando é
aplicado no contexto de um fluxo de valor. As práticas ITIL podem ser consideradas como blocos de construção para os fluxos de valor de uma
organização. Cada prática descreve como pode ser usada em
Fluxo de valor passo 1 Fluxo de valor etapa 2 Etapa 3 do fluxo de valor
Atividades de Atividades de Atividades de

Serviço
Prática A Prática B Prática N
Prática D
Prática E
Prática Y
Prática Z
Figura 2.22 Múltiplas práticas de gerenciamento envolvidas em um fluxo de valor, representadas em uma variação de uma cadeia de valor de Porter
35
um fluxo de valor, mas cada fluxo de valor aplicará as práticas de sua própria maneira específica. Embora a padronização tenha
seus benefícios, principalmente em termos de eficiência, geralmente é mais eficaz adequar as práticas às necessidades específicas
de cada fluxo de valor.
Cada etapa de um fluxo de valor consiste em atividades definidas e descritas em práticas de gestão; outras práticas
podem contribuir para o fluxo de valor com informações, ferramentas ou métodos. Isso é mostrado na Figura 2.22.
2.6.5.1 Principais práticas para HVIT
As práticas mais relevantes para HVIT e produtos digitais estão ilustradas na Tabela 2.5.
Tabela 2.5 Práticas e sua relevância para os cinco objetivos
Valor
Investimentos valiosos cocriado
Operações resilientes
Desenvolvimento rápido Conformidade garantida
Gerenciamento de arquitetura ÿ ÿ
Gerenciamento de disponibilidade ÿ ÿ ÿ
Análise de negócio ÿ ÿ ÿ
Gerenciamento de capacidade e desempenho ÿ ÿ ÿ
Alterar ativação ÿ ÿ ÿ
Melhoria contínua ÿ ÿ ÿ ÿ ÿ
Gerenciamento de implantação ÿ ÿ ÿ
Gerenciamento de incidentes ÿ ÿ
Gerenciamento de segurança da informação ÿ ÿ
Gerenciamento de infraestrutura e plataforma ÿ ÿ
Gerenciamento de ativos de TI ÿ ÿ
Gestão do conhecimento ÿ ÿ
Medição e relatórios ÿ ÿ ÿ
Monitoramento e gerenciamento de eventos ÿ
Gestão de mudanças organizacionais ÿ ÿ
Gerenciamento de portfólio ÿ ÿ
Gerenciamento de problemas ÿ
Gerenciamento de Projetos ÿ
Gestão de relacionamento ÿ ÿ
Gerenciamento de lançamento ÿ ÿ ÿ
Gerenciamento de riscos ÿ ÿ ÿ
Gerenciamento do catálogo de serviços ÿ
Gerenciamento de configuração de serviço ÿ ÿ ÿ
Gerenciamento de continuidade de serviço ÿ ÿ ÿ
Projeto de serviço ÿ ÿ ÿ
Balcão de atendimento ÿ
Gestão financeira de serviços ÿ ÿ ÿ
Gerenciamento de nível de serviço ÿ ÿ
Gerenciamento de solicitação de serviço ÿ ÿ
Validação e teste de serviço ÿ ÿ ÿ
Desenvolvimento e gerenciamento de software ÿ ÿ
Gestão de estratégia ÿ ÿ
Gestão de fornecedores ÿ ÿ ÿ
Gestão da força de trabalho e talento ÿ ÿ ÿ ÿ ÿ
36
2.6.6 As quatro dimensões do gerenciamento de serviços
Serviços e gerenciamento de serviços requerem recursos ativos e passivos, que podem ser qualquer coisa que uma
organização tenha adquirido ou desenvolvido para realizar atividades relevantes. Os funcionários, parceiros e fornecedores de
uma organização são recursos ativos (operantes), ou atores. Eles interagem com outros atores e com recursos e produtos
passivos (operando).
Exemplos de recursos organizacionais incluem:
• organizações (incluindo finanças e recursos físicos, como prédios) e pessoas
• informação e tecnologia
• parceiros e fornecedores.
Essas são três das quatro dimensões do gerenciamento de serviços que são um componente-chave da estrutura ITIL.
As quatro dimensões são influenciadas pela variedade de fatores externos PESTLE: políticos, econômicos, sociais,
tecnológicos, legais e ambientais, conforme mostrado na Figura 2.23.
As quatro dimensões do gerenciamento de serviços identificam os tipos de recursos que são usados em um fluxo de valor.
Três das quatro dimensões (organizações e pessoas, informação e tecnologia e parceiros e fornecedores) são recursos
concretos que são utilizados operacionalmente durante a execução das etapas do fluxo de valor. A dimensão de fluxos de valor
e processos representa recursos abstratos que são usados como entrada para o design de fluxos de valor. Isso é mostrado na
Figura 2.20.
Exemplos da aplicação de cada dimensão ao HVIT são descritos nas seções a seguir.
Político Econômico
fatores fatores
Organizações Em formação
e pessoas e Tecnologia
Produtos
e serviços
Ambiental Social
fatores fatores
Parceiros Fluxos de valor

e fornecedores e processos
Jurídico Tecnológica
fatores fatores
Figura 2.23 As quatro dimensões do gerenciamento de serviços, incluindo os seis fatores PESTLE
37
2.6.6.1 Organizações e pessoas

Em ambientes HVIT, onde a TI é parte integrante dos produtos e serviços de uma organização, é provável que a função de TI seja
parte integrante das linhas de negócios responsáveis pelos vários produtos e serviços. Muitas vezes, haverá equipes multifuncionais
baseadas em produtos/serviços, com membros de equipe orientados para negócios e orientados para TI. Embora possa haver um
centro de serviços de TI centralizado para tecnologia digital não diferenciada, como e-mail e Wi-Fi, a tecnologia digital diferenciada
muitas vezes será gerenciada como parte das atividades primárias. Também pode haver equipes orientadas para a plataforma que
dão suporte a vários produtos/
equipes baseadas em serviços. Um dos desafios organizacionais em tais ambientes é gerenciar um ambiente híbrido
onde algumas tecnologias são dedicadas e outras são compartilhadas, e onde sistemas pequenos, dinâmicos e orientados a
produtos precisam interagir com sistemas back-end grandes e menos flexíveis.
Dentro das equipes orientadas a produtos/serviços, não há acordos de nível de serviço entre negócios e TI, pois fazem parte da
mesma equipe. O mesmo se aplica a acordos entre grupos de TI dentro da equipe. Ainda pode haver métricas e indicadores, mas
estes estão diretamente alinhados com os objetivos primários da linha de negócios, não como parte de transações internas com
uma função de TI.
Os profissionais de TI em ambientes HVIT geralmente trabalham no mesmo local físico que seus colegas de trabalho que não
são de TI, geralmente no contexto de equipes independentes baseadas em produtos/serviços. Isso é bom não apenas para a
comunicação, mas também para construir um entendimento melhor e comum do contexto de negócios no qual a tecnologia digital é usada.
2.6.6.2 Informação e tecnologia

Esta seção refere-se à informação e tecnologia que são usadas como 'recursos de produção' para produzir a informação e
tecnologia que compõem os produtos e serviços digitais; em outras palavras, o ferramental usado para produzir o produto, não o
produto em si.
Em ambientes HVIT que derivam valor significativo da tecnologia digital, parte desse valor está relacionado às informações que
os sistemas digitais fornecem e parte está relacionada à tecnologia digital que fornece as informações de forma rápida,
resiliente, segura e eficiente. Portanto, demandas mais altas são colocadas tanto na informação e tecnologia que capacitam
digitalmente as organizações quanto na informação e tecnologia (ferramentas de TI) que suportam os processos de TI. Um
exemplo de ferramentas HVIT é um pipeline de implantação automatizado que envia novas versões de aplicativos de forma mais
rápida e confiável para a produção.
A informação é muitas vezes um recurso mal utilizado na função de TI. Os profissionais devem estar cada vez mais conscientes
dos dados que têm à sua disposição e fazer melhor uso deles. É comum em ambientes HVIT que as informações sejam criadas e
utilizadas em tempo real e às vezes de forma espontânea. Por exemplo, as ferramentas de monitoramento fornecem acesso em
tempo real às informações de desempenho quando necessário (como quando um alerta indica uma condição de exceção ou um
incidente foi detectado). As ferramentas de colaboração integradas com bots (ChatOps) podem ser usadas para trocar e adquirir
informações adicionais conforme necessário para agir.
É fundamental entender o fluxo de informações e como o trabalho é feito, para que as pessoas tenham as informações de que
precisam, quando e onde precisam, como parte de suas práticas de 'trabalho como sempre'. Essa necessidade crítica é parcialmente
atendida pela análise de negócios, mas o domínio do gerenciamento de informações de negócios1 expande o escopo para incluir o
uso real das informações. O gerenciamento de informações de negócios não apenas garante que as necessidades de informações
corretas sejam identificadas, mas também que as informações sejam usadas de forma eficaz no contexto dos processos de
negócios. Isso se aplica igualmente às informações que suportam os processos dentro do domínio de gerenciamento de serviços e
TI. O fluxo livre de informações é uma característica de uma organização de alta confiança. Isso é consistente com a 'cultura
generativa',2 caracterizada por altos graus de cooperação, compartilhamento de riscos, apetite por inovação e desejo de aprender
com o fracasso, que é frequentemente encontrado em organizações de HVIT.
38
A duplicação de dados (com o risco de diferentes fontes de verdade) pode ser evitada pela integração de sistemas. Isso também diz
respeito ao uso de diferentes ferramentas; por exemplo, desenvolvedores usando uma ferramenta e operações usando outra, sem
interfaces e consolidação. Adicionar automaticamente um identificador comum e visível (como um Sprint ID, ID de item de backlog ou
número de ticket) é uma maneira de combiná-los. Por exemplo, adicionar um ID de história de usuário a um registro de alteração
enquanto uma alteração avança por um pipeline de implantação é uma ótima maneira de adotar os princípios orientadores da ITIL de
'colaborar e promover visibilidade' e 'otimizar e automatizar'.
O crescimento extremo esperado da inteligência artificial (IA) e do aprendizado de máquina só aumentará as demandas de informações
e conhecimento bem gerenciados.
2.6.6.3 Parceiros e fornecedores

Os ambientes HVIT normalmente fazem uso extensivo de infraestruturas, plataformas e outros serviços baseados em nuvem.
Esses serviços de utilidade geralmente são fornecidos por organizações em seus próprios termos e condições. Os serviços públicos
baseados em nuvem geralmente são de alta qualidade e acessíveis, mas o consumidor individual tem pouca ou nenhuma influência
sobre o provedor. Portanto, é crucial analisar as dependências e tomar as medidas adequadas em termos de contratos e SLAs, incluindo
acordos de compartilhamento de riscos, provedores secundários e planos de contingência e soluções alternativas.
Ao terceirizar o trabalho em um ambiente HVIT, é importante considerar se o provedor de serviços externo trabalha de maneira
semelhante ao seu cliente, pois é difícil integrar partes com formas fundamentalmente diferentes de trabalhar no mesmo fluxo de valor. A
terceirização funcional, na qual funções discretas, como testes, são terceirizadas, geralmente é menos eficaz do que terceirizar todo um
fluxo de valor. Devido a essa restrição, as funções de TI geralmente contratam pessoal externo em vez de terceirizar o trabalho.
2.6.6.4 Fluxos de valor e processos

Os ambientes HVIT reconhecem que pode ser melhor criar um fluxo de valor exclusivo para cada produto ou serviço digital. Isso pode
ser menos eficiente do que um fluxo de valor único padronizado e centralizado que atende a vários produtos e serviços, mas os
benefícios em termos de eficácia geralmente superam os custos, por isso é aconselhável considerar essa alternativa. Se essa opção for
considerada, a organização também deve pensar em maneiras de compartilhar ferramentas e melhores práticas entre os fluxos de valor,
quando apropriado. Ao projetar fluxos de valor exclusivos, é importante lembrar que algum tipo de padronização pode ser necessária
para a escalabilidade, portanto, a compensação precisa ser cuidadosamente considerada.
Um processo é uma sequência predeterminada de atividades inter-relacionadas que transforma entradas em saídas. Os processos
podem ser usados para detalhar as etapas em um fluxo de valor, e os procedimentos e instruções de trabalho podem fornecer níveis
adicionais de orientação detalhada.
Como os processos são predeterminados, eles são aplicáveis a situações previsíveis. Quando uma situação é imprevisível, é improvável
que a aplicação de um processo resulte nas saídas e resultados desejados. Nessas circunstâncias, uma abordagem baseada em casos
é mais eficaz, pois dá ao profissional a liberdade de aplicar seu julgamento profissional sobre quais atividades são apropriadas. Os
ambientes HVIT geralmente lidam com sistemas complexos que são imprevisíveis, portanto, o uso de processos deve ser reservado para
aquelas situações em que é viável predeterminar a sequência apropriada de atividades. Os praticantes geralmente pensam em termos
de vários padrões de atividades que podem funcionar e experimentam para selecionar os padrões certos para a tarefa em questão.
2.6.7 Fatores externos

As escolhas de mercados, produtos e serviços, recursos e atividades de uma organização são influenciadas por múltiplos fatores
externos, que podem ser políticos, econômicos, sociais, tecnológicos, legais e ambientais (PESTLE). Tudo isso influencia as quatro
dimensões do gerenciamento de serviços.
39
Os ambientes HVIT também são caracterizados por graus relativamente altos de volatilidade, incerteza,
complexidade e ambiguidade, que são referidos pela sigla 'VUCA'. O VUCA apresenta um sério desafio gerencial, e
deve ser considerado no planejamento e gestão das organizações. O grau em que uma organização experimenta os
elementos do VUCA é refletido em se ela busca mais planos de curto ou longo prazo e em quantos programas de
transformação em grande escala ela passa.
Uma organização que experimenta VUCA em maior grau normalmente buscará abordagens mais evolutivas, baseadas em
uma avaliação da disposição dos atores no ambiente externo e interno e na experimentação dos fatores que influenciam
esses atores. Nessas organizações, o foco está mais em gerenciar o presente, em vez de fazer e seguir um roteiro para
um estado futuro predeterminado.
Os gerentes restringem o comportamento impondo controles conduzidos por políticas externas e internas, regras,
sanções e assim por diante. Ao mesmo tempo, os trabalhadores determinam como contribuem para a organização dentro
dos limites desses controles. Nas organizações HVIT, os profissionais desempenham um papel ativo no desempenho e na
melhoria organizacional. Eles também estão em posição de desafiar limites onde são menos rígidos. Os profissionais têm
a oportunidade de demonstrar liderança tomando a iniciativa.
2.6.8 Governança e gestão

Pode ser fácil confundir os termos 'governança' e 'gestão' e como eles são aplicados dentro das organizações.
A governação, em particular, pode ser aplicada ao mais alto nível de órgãos não executivos, mas também a níveis mais
baixos, onde se torna cada vez mais difícil distinguir entre governação e gestão. Por uma questão de clareza, esta publicação
refere-se a diferentes entidades organizacionais de governança e gestão. Um corpo diretivo está em um nível de autoridade
mais alto do que a entidade organizacional que é governada, enquanto um gerente faz parte dessa entidade organizacional.
Governança é o meio pelo qual uma organização é dirigida e controlada. O corpo diretivo avalia a situação da
organização, define a direção para os gerentes e monitora o desempenho da organização.
A gestão está ancorada na governança. Os gerentes lidam com o planejamento, construção, organização e melhoria
da entidade organizacional.
A responsabilidade pela tecnologia digital é parte integrante das linhas de negócios digitais em organizações
habilitadas digitalmente e não é uma unidade separada, como um centro de serviços de TI centralizado (embora possam
existir para serviços de TI não diferenciados, como e-mail). A entidade organizacional governada e gerenciada é,
portanto, responsável tanto pela tecnologia digital quanto pelo seu uso no contexto de produtos e serviços digitais. Isso
é benéfico para o alinhamento de negócios e TI dentro de uma organização, pois apenas atividades e recursos de
negócios e TI precisam ser alinhados, em vez de entidades organizacionais separadas com alvos diferentes. Os
profissionais de tecnologia digital, portanto, se reportarão à mesma gerência que seus colegas de trabalho menos técnicos.
Os profissionais operam dentro de uma estrutura de governança e gestão. Eles entendem as restrições aplicáveis
e sabem como agir dentro dessa estrutura, e sua percepção e julgamento influenciam como eles agem. Quanto mais
insights eles tiverem e quanto melhores forem suas habilidades de julgamento, mais o profissional tomará a iniciativa de
dobrar as regras quando os benefícios e riscos associados forem justificáveis. Isso pode ser muito benéfico, pois os
ambientes HVIT geralmente são altamente imprevisíveis, o que significa que instruções predeterminadas não são viáveis
nem desejáveis.
Um praticante de HVIT, portanto, deve exercer julgamento no trabalho. Para fazer isso de forma eficaz, eles
devem entender o raciocínio por trás de certas restrições que estão em vigor. Um papel importante do gerente em um
ambiente HVIT é, portanto, fornecer contexto e permitir que o profissional assuma o controle.
40
2.7 Resumo
O Capítulo 2 forneceu uma visão geral dos principais conceitos relacionados a uma organização digital, incluindo tecnologia digital,
transformação digital e TI de alta velocidade. Compreender esses conceitos e alinhar a taxonomia que eles formam entre
organizações e ecossistemas são fundamentais para o sucesso das iniciativas de transformação digital, pois geralmente envolvem
muitas pessoas de diferentes organizações e origens.
Para ter sucesso em uma transformação digital, as organizações precisam ser (ou se tornar) Ágeis, Lean, resilientes e capazes
de entregar continuamente. Todos esses atributos permitem a cocriação de valor em alta velocidade: mais rápido, com uma
direção clara de desenvolvimento.
Finalmente, o capítulo explorou o sistema de valor de serviço da ITIL (SVS) e seus componentes da perspectiva de alta
velocidade e descreveu como os componentes do SVS podem trabalhar juntos em um ambiente de alta velocidade para garantir um
valor eficaz, sustentável e resiliente. -criação.
Para resumir, o Capítulo 2 explicou:
• os principais conceitos de transformação digital e TI de alta velocidade
• o que precisa ser alcançado para permitir alta velocidade e transformação digital
• como os modelos e conceitos ITIL 4 podem ajudar no sucesso da transformação digital.
O Capítulo 3 abordará os aspectos culturais da transformação digital: padrões de comportamento-chave para uma organização
de alta velocidade e abordagens-chave para a evolução cultural relacionada.
41
42
CAPÍTULO 3
ALTA VELOCIDADE
CULTURA DE TI
3 Cultura de TI de alta velocidade
Este capítulo explora o tipo de cultura que apoia e possibilita o trabalho de HVIT. Ele descreve cinco padrões de comportamento chave que refletem
as necessidades organizacionais e as aspirações dos profissionais para trabalhar em um ambiente gratificante. Ele também explora uma série de
modelos e conceitos que apoiam esses padrões de comportamento e informam a cultura organizacional.
3.1 Principais padrões de comportamento
Existem cinco padrões de comportamento chave que refletem as necessidades organizacionais e as aspirações dos profissionais de trabalhar em
um ambiente gratificante. Esses padrões de comportamento pretendem apelar ao desejo humano de contribuir para algo que valha a pena,
aprender e melhorar e ser reconhecido por sua intenção e esforço.
Os cinco principais padrões de comportamento mostrados na Figura 3.1 são:
• confiar e ser confiável
• elevar continuamente a fasquia
• ajudar a realizar o trabalho dos clientes
Embora a maioria desses padrões de comportamento não seja exclusiva do HVIT, a combinação e a adesão a todos os cinco são benéficas para o
tipo de pessoa que entende as demandas de uma empresa mais habilitada digitalmente.
Aceite a ambiguidade e a incerteza
Ajude a
Confie e seja Continuamente realizar os
confiável aumentar a qualidade
trabalhos dos clientes
Comprometa-se com o aprendizado contínuo
Figura 3.1 Principais padrões de comportamento
44
3.1.1 Aceitar ambiguidade e incerteza

Esse padrão de comportamento reflete a natureza volátil e ambígua das organizações típicas habilitadas digitalmente. Nesses
ambientes, onde os sistemas à prova de falhas costumam ser uma ilusão, é importante favorecer a experimentação e não ter
medo de falhar com segurança e atenção. Os praticantes não devem ter medo do desconhecido. Eles devem ser capazes de
aceitar que as coisas não são perfeitas e ter técnicas para lidar com isso.
3.1.2 Confie e seja confiável
Esse padrão de comportamento é respeitar as habilidades profissionais das pessoas e confiar nelas para tomar as decisões
certas, além de considerar os outros, reconhecer a diversidade e ser inclusivo. As pessoas devem receber feedback sobre seu
trabalho que seja honesto, mas atencioso. Esse padrão de comportamento também está relacionado à redução do estresse e
do esgotamento ao prestar atenção ao tratamento injusto, relacionamentos tóxicos, falta de reconhecimento, falta de controle,
valores conflitantes e recursos insuficientes. A segurança psicológica também é importante para promover um melhor desempenho.
Os mais novos devem ser encorajados a partilhar os seus conhecimentos em vez de terem medo de falar, e os mais velhos devem
sentir-se à vontade para falar se não souberem alguma coisa ou precisarem de pedir ajuda.
3.1.3 Elevar continuamente a barra

Esse padrão de comportamento se concentra em nunca estar satisfeito com o status quo, com o ponto de vista de que,
mesmo que as coisas sejam satisfatórias hoje, não serão amanhã. Clientes e usuários sempre ficarão mais felizes quando se
tomar a iniciativa de fazer melhorias, e sempre há uma melhoria a ser feita, por menor que seja.
Os profissionais são incentivados a mostrar liderança, identificando oportunidades de melhoria e contribuindo para acompanhá-
las.
3.1.4 Ajudar a realizar o trabalho dos clientes

Esse padrão de comportamento representa a essência de toda organização. Todas as organizações têm uma variedade de partes
interessadas, mas os clientes geralmente são os mais importantes. Esse padrão de comportamento se concentra no ato de ajudar
alguém a resolver seus problemas e se tornar quem eles procuram se tornar. Ele reconhece a psicografia do cliente: ou seja, como
o cliente quer se sentir antes, durante e depois de usar produtos e serviços digitais e físicos. Isso envolve fazer uma afirmação
ousada e honesta delineando que os produtos e serviços que uma organização oferece fornecerão um determinado resultado para
as pessoas que acreditam ou desejam certas coisas, e não são projetados para aqueles que não acreditam ou não desejam essas
coisas.
3.1.5 Comprometer-se com o aprendizado contínuo
Esse padrão de comportamento sustenta os outros. A ignorância é a causa raiz de muitos problemas organizacionais,
geralmente quando alguém não tem as informações corretas quando precisa agir, ou mesmo quando está criando um sistema
inicialmente. Também pode ser um problema quando se acredita erroneamente que as situações são cognoscíveis e podem
ser previstas. Isso se liga ao padrão de comportamento de aceitar a ambiguidade e a incerteza. É importante que os profissionais
se comprometam a aprender e melhorar continuamente seus conhecimentos e o nível de informação que possuem. Experimentos
orientados por dados podem ser usados para desafiar e melhorar hipóteses.
'Confiar e ser confiável' é uma pré-condição importante para a experimentação. Ciclos de feedback curtos são outra chave para
o aprendizado contínuo.
45
A história da ITIL: cultura de TI de alta velocidade
Radhika: Nós nos envolvemos com os clientes para entender melhor suas necessidades de viagem atuais e
futuras. Comparamos os resultados dessa análise com nossa oferta de serviços existente. Um pedido que os
clientes continuavam fazendo era para uma melhor digitalização de nossos serviços.
Henri: O conselho de administração concordou em investir em melhorias em nosso aplicativo, o que tornará mais
fácil para nossos clientes reservar carros em uma variedade maior de smartphones e dispositivos. Também estamos
pensando em adicionar vários outros recursos ao nosso aplicativo para melhorar a experiência de nossos usuários.
Su: Primeiro, desenvolveremos as melhorias na funcionalidade de reserva do smartphone. Isso será seguido por
recursos complementares, como um programa de afiliados, um programa de associação, upgrades automáticos de
veículos para clientes regulares e reservas prioritárias simplificadas. Cada um desses conceitos será testado antes
de iniciarmos o desenvolvimento.
Solmaz: Queremos buscar uma abordagem de alta velocidade para desenvolver os novos recursos do nosso
aplicativo. Podemos apoiar isso certificando-nos de que temos a cultura certa em vigor.
3.2 Modelos e conceitos da cultura HVIT

Há uma série de modelos e conceitos que informam a cultura organizacional. Estes são agrupados em três categorias:
• propósito
• pessoas
• progresso.
Os modelos e conceitos são descritos nas seções a seguir. A Tabela 3.1 descreve os principais padrões de comportamento aos quais
cada um dos modelos e conceitos e cada um dos princípios orientadores da ITIL se relaciona.
Tabela 3.1 Modelos e conceitos e padrões de comportamento chave relacionados
Aceite a Confie e seja Elevar a barra Ajude a Comprometa-se
confiável
ambiguidade e a incerteza continuamente realizar os trabalhos com o
dos clientes aprendizado contínuo
Propósito
Ética ÿ ÿ ÿ ÿ ÿ
Pensamento de design ÿ
Pessoas
Reconstruindo para agilidade no atendimento ÿ
Cultura de segurança ÿ
Prevenção do estresse ÿ
Progresso
Trabalhar em ambientes complexos ÿ
Cultura enxuta ÿ ÿ ÿ
Modelo de melhoria contínua ITIL ÿ ÿ ÿ
46
Cultura de TI de alta velocidade
Aceite a ambiguidade Confie e seja Elevar a barra Ajude a Comprometa-se
e a incerteza confiável continuamente realizar os trabalhos com o
dos clientes aprendizado contínuo
Princípios orientadores da ITIL
Foco no valor ÿ
Comece onde você está ÿ
Progrida iterativamente com feedback ÿ ÿ
Colabore e promova a visibilidade ÿ
Pense e trabalhe de forma holística ÿ
Mantenha-o simples e prático ÿ
Otimize e automatize ÿ
A história da ITIL: Modelos e conceitos da cultura HVIT

Solmaz: Podemos adotar vários modelos e conceitos para nos ajudar a alcançar uma maneira de trabalhar em alta
velocidade à medida que desenvolvemos a nova funcionalidade do aplicativo.
3.2.1 Objetivo
Propósito é a meta externa que impulsiona os esforços das pessoas: ou seja, as mudanças que os produtos e serviços possibilitam.
Modelos e conceitos na categoria de propósito incluem:
• Ética Um sistema de princípios que define o que é bom para os indivíduos e para a sociedade.
• Design thinking O conjunto de técnicas cognitivas e práticas pelas quais os conceitos de design são desenvolvidos.
3.2.1.1 Ética
O impacto social, político e econômico da TI é sem precedentes, para melhor e para pior. As organizações digitais, nas quais a TI conduz os
negócios em vez de apenas apoiá-los, têm, portanto, uma obrigação moral cada vez mais forte de considerar como aplicam a TI, além de seus
interesses econômicos diretos.
A engenharia de software muitas vezes se torna um meio de engenharia social, e isso nem sempre é intencional. Os algoritmos de aprendizado
de máquina são suscetíveis a pegar um conjunto de dados de treinamento e amplificar o pior dos preconceitos humanos.
As organizações têm a responsabilidade de se comportar eticamente para entender e corrigir esses preconceitos.
Definição: Ética
Um sistema de princípios que define o que é bom para os indivíduos e para a sociedade.
47
Por que a ética é importante
A criação da internet e a transferência de informações quase instantânea entre pessoas anteriormente desconectadas já está tendo
um efeito profundo na sociedade humana. Seu impacto total ainda não é conhecido, ou totalmente conhecido. Assim como cientistas ou
engenheiros, os profissionais de TI devem aceitar a responsabilidade moral pelo que criam. Isso significa que uma atenção cuidadosa e
detalhada deve ser dada à ética e à moralidade, tanto no trabalho do dia-a-dia quanto no quadro geral.
Um problema agravante é que o mundo está se tornando cada vez mais complexo. Os sistemas em que as pessoas vivem e trabalham
têm muitas conexões, algumas das quais são conhecidas, algumas cognoscíveis e outras incognoscíveis, e qualquer intervenção terá
consequências não intencionais. Às vezes, pequenas coisas têm grandes consequências. Na era hiperconectada moderna, as coisas
podem sair do controle muito rapidamente. Várias considerações podem ser levadas em consideração ao promover o comportamento
ético no local de trabalho.
A tecnologia digital permite informações mais amplas e profundas sobre as pessoas. Um indivíduo pode, portanto, receber informações
detalhadas sobre outros. Isso pode mudar a percepção das pessoas, e talvez as respostas comportamentais, nos negócios e nos
relacionamentos pessoais. A competência profissional inclui até que ponto uma pessoa é capaz de aplicar sua própria moral em
combinação com a ética defendida por sua organização ou sociedade. Forçar a ética em um funcionário apenas por meio de uma política
não é eficaz, pois a ética é considerada pessoal.
Educação
A ética é um aspecto muito negligenciado da educação em engenharia de software. Não basta dar formação pós-núcleo: a ética
deve fazer parte da educação que a antecede. Medir e monitorar as atitudes relacionadas ao comportamento ético é tão importante
quanto criar regras e gerenciar a conformidade.
Os profissionais podem ser educados em ética e incentivados a participar de workshops que conscientizam as pessoas sobre as
consequências éticas. Também é fundamental que, dentro das organizações, os cenários sejam explorados e as atitudes em relação à
ética sejam medidas. As políticas e práticas de recrutamento devem se concentrar em uma compreensão mais ampla da ética. A
capacidade de ver o quadro mais amplo, pensar em abstrações e imaginar consequências deve ser vista como uma habilidade essencial
necessária em todos os estágios do ciclo de vida do produto. Em um nível micro, a ética pode até ser incluída em retrospectivas e
programas de lições aprendidas. Ironicamente, os métodos ágeis que se concentram na eliminação de pendências geralmente negligenciam isso.
As unidades de trabalho individuais são muitas vezes realizadas independentemente do contexto do sistema mais amplo e da
capacidade e vontade das pessoas de imaginar as consequências potenciais de suas ações. O princípio orientador da ITIL de pensar
e trabalhar de forma holística destina-se a evitar tais situações.
O objetivo aqui é criar uma cultura ética no setor de TI tanto quanto uma cultura focada na qualidade e no foco no usuário.
Design organizacional
A forma como as organizações são projetadas também pode ser alterada para aumentar a confiança e a interação entre os membros da
equipe, seguindo o princípio de 'colaborar e promover visibilidade'. Isso requer uma força de trabalho cognitiva e culturalmente diversa,
fortemente conectada, com alto grau de visibilidade em redes estreitas, mas não necessariamente em todo o sistema. O desenho
organizacional deve, portanto, ser examinado com vistas a construir confiança de longo prazo em vez de ganhos de curto prazo, e
buscando mudar as interações sociais na rede para aumentar a interdependência trabalhando em conjunto.
Isso não apenas ajuda a resolver problemas, mas também cria uma ecologia de suporte à decisão baseada na confiança. Se você sabe
que seu comportamento é observado por aqueles cujo respeito você busca, isso muda as coisas para melhor. Ele constrói uma ecologia
de interação confiável na qual questões ou dilemas éticos são menos propensos a vir à tona.
48
Hábitos e o papel do fracasso
Os hábitos são mais poderosos que as regras e criam padrões de comportamento e respostas que não envolvem análise e
tomada de decisão. A educação e o desenho organizacional precisam criar circunstâncias nas quais os hábitos de virtude surjam
naturalmente. Nessas circunstâncias, a interação social exclui o comportamento antiético.
O conhecimento abstrato do que é certo é combinado com os hábitos de comportamento do dia-a-dia, o que significa que a
virtude vem naturalmente ao que fazemos.
Os hábitos geralmente são mais bem formados pela interação física e pelo fracasso tolerado. A abstração e o uso da
metáfora na aprendizagem permitem maior adaptabilidade e aplicação contextual em condições de incerteza.
Aprende-se mais com o fracasso do que com o sucesso, mas apenas em um ambiente sem culpa.
Ética e inteligência artificial
Muito trabalho está sendo feito na área de não apenas emular a inteligência humana na tecnologia, mas também
incorporar a inteligência emocional na tecnologia de autoaprendizagem, também conhecida como IA.
A IA é uma preocupação fundamental da ética na era digital. O termo 'tecnoética', originalmente cunhado na década de 1970,
ressurgiu recentemente quando se fala em ética e IA. A tecnoética é o uso responsável da ciência, tecnologia e ética em uma
sociedade moldada pela tecnologia. À medida que a quarta revolução industrial se desenvolve, as organizações precisam
expandir sua agenda ética para incluir aspectos de 'biotecnologia'.
O ChatOps é um bom exemplo disso, que inclui a inteligência emocional como foco para melhorar as operações.
O ChatOps tenta verificar o estado emocional do cliente, a fim de responder adequadamente e entender e gerenciar seu estado
emocional ao lidar com seu incidente ou solicitação. Outros exemplos podem ser encontrados em assistentes de voz, software de
análise de imagem, mecanismos de busca, sistemas de reconhecimento de voz e rosto e assim por diante.
O uso de IA ou qualquer área de nova tecnologia continua a evoluir à medida que se aprende mais sobre suas características
através do uso. No entanto, é necessário desenvolver a inteligência emocional nas pessoas antes de fazer qualquer tentativa de
projetá-la e usá-la na tecnologia.
Definição: Inteligência emocional
A capacidade de entender como as pessoas sentem e reagem, e usar essa habilidade para fazer bons julgamentos e
evitar ou resolver conflitos.
Tópicos de tecno-ética para discussão
Recomenda-se discutir a ética e sua aplicação com a gerência e colegas de trabalho. Exemplos de tópicos que devem ser
considerados incluem:
• Quem dentro de uma organização decide o que é moral ou quais princípios seguir?
• Que princípios se espera que governem o comportamento ético? Estes podem incluir integridade, honestidade, respeito,
responsabilidade pessoal, compaixão e confiabilidade.
• O que esses princípios significam?
49
Exemplos de perguntas éticas
Uma situação comum com preocupações éticas é o uso de cookies de navegador que rastreiam o padrão de uso de um usuário
e, portanto, permitem que a empresa 'pop-up' sugestões para outros serviços ou produtos que correspondam ao histórico de
navegação do cliente. É importante considerar as questões éticas e sociais envolvidas nessa situação; e se isso deve ser
considerado uma prática comum, não necessitando de mais reflexão, ou pode ter implicações de longo prazo para a privacidade
pessoal ou até mesmo violar a lei.
Os departamentos de RH agora estão usando um método de triagem de candidatos que registra as emoções dos candidatos
enquanto são entrevistados e faz referência cruzada com seus sistemas, verificando na Internet suas postagens de mídia social
para analisar as respostas comportamentais. Nenhum psicólogo está envolvido na avaliação dos dados específicos coletados;
em vez disso, depende da análise do software, que pode ter incluído a psicologia em seu design. Você se sente confortável se é
assim que você será julgado para funções futuras (internas ou externas)? Esta é uma tecnologia que você gostaria de ter para
ajudá-lo a escolher sua equipe?
Um analista de service desk recebeu uma solicitação de alguém para acessar o sistema de um colega para que possa continuar
com o trabalho necessário enquanto esse colega estiver ausente. A resposta normal é 'não', porque a maioria das organizações
tem uma política de senha que nega a qualquer pessoa, exceto o proprietário, o acesso ao sistema.
No entanto, há outra resposta, pois a TI não existe para impedir que a empresa ou o indivíduo realizem o trabalho. A resposta
simples é 'Sim, claro. Tudo o que é necessário é que o formulário de autorização seja preenchido e assinado.' Ambas as partes
nesta situação estão aplicando uma ética de privacidade empresarial apropriada; no entanto, a pessoa que acessa o sistema de
seu colega ainda está sob seu próprio reconhecimento enquanto estiver nesse sistema.
Algo aparentemente inocente pode levar a danos incríveis se a ética de qualquer pessoa for comprometida. A
confiança é uma faceta primária da ética.
Mensagem chave
Ao aplicar a ética, os profissionais devem aspirar aos seguintes comportamentos:
• Pense em como suas ações afetam os outros.
• Estabelecer princípios éticos genéricos.
• Aceite que os princípios éticos simplesmente ajudam a esclarecer situações específicas.

• Discutir dilemas.
• Assuma a responsabilidade de escolher o curso de ação menos pior.
A Figura 3.2 destaca os principais padrões comportamentais relevantes para a ética.
50
0 1 2 3
Baixo Alto
Ajude a
Figura 3.2 Mapa de calor da importância dos principais padrões de comportamento para a ética
A história da ITIL: Ética

Su: Cada decisão que tomamos tem um componente ético, desde a empresa para a qual trabalhamos até os
serviços que utilizamos. A visão da Axle Car Hire inclui uma ênfase na sustentabilidade ambiental.
Sabemos que os recursos do mundo são finitos e acreditamos que, eticamente, somos obrigados a minimizar
nossa pegada quando usamos esses recursos limitados. Além disso, muitos de nossos clientes escolhem
nossos serviços por causa de nossas iniciativas verdes.
Henri: O compromisso da Axle com o comportamento empresarial ético não se limita à sustentabilidade.
Inclui a forma como tratamos nossos colaboradores, selecionamos e tratamos fornecedores e parceiros e
contribuímos com a sociedade. Uma postura ética pode ser boa para os negócios, além de ser a coisa certa a
fazer. Os clientes entregarão seus negócios a organizações que reflitam seus valores.
3.2.1.2 Pensamento de design

Design é mais do que apenas mercadorias. Experiências, processos e sistemas do usuário também são projetados aplicando uma
abordagem que veio a ser conhecida como 'design thinking'. Design thinking é apenas como os designers pensam. Ele está em
constante evolução e recentemente atraiu mais atenção e interesse à medida que as organizações habilitadas digitalmente começaram
a procurar projetar o pensamento para melhorar a percepção do mercado de seus produtos digitais.
Os designers criam produtos com uma intenção específica e um propósito específico, para transformar uma situação que não é
conveniente ou ideal em uma que é. Eles pensam em maneiras de transformar essas condições desfavoráveis em mais preferíveis,
tornando-as mais adequadas ao propósito e ao uso.
51
Definição: Design thinking
O conjunto de processos cognitivos e práticos pelos quais os conceitos de design são desenvolvidos.
Para organizações habilitadas digitalmente, a qualidade de seus produtos digitais e experiências do cliente são imensamente
importantes. Uma compreensão do design thinking oferece aos profissionais, juntamente com colegas de trabalho e clientes, a
capacidade de contribuir para a criação de melhores produtos digitais e experiências do cliente, além de ajudar a concluir trabalhos para
os clientes de maneira eficaz. O design thinking é particularmente útil ao abordar 'problemas perversos': em outras palavras, problemas
que têm necessidades não articuladas e hipóteses conflitantes.
Os clientes não são os únicos que usam produtos. Eles também são usados por provedores de serviços, vendedores, gerentes,
desenvolvedores, operadores e outras partes interessadas. Uma preocupação do design thinking é tentar resolver a questão de
equilibrar os interesses de todos esses stakeholders, bem como os da própria organização. O consumidor, em geral, tem a maior
prioridade, pois uma organização é financiada por seus clientes.
Os designers apreciam isso e, portanto, também se preocupam com os aspectos econômicos do design
Mensagem chave
Ao aplicar o design thinking, os profissionais devem aspirar ao seguinte comportamento:
• Empatia com as partes interessadas É importante ser capaz de entender o ponto de vista e as necessidades
dos interessados.
• Especular e experimentar Designers devem ser capazes de criar hipóteses com base na observação e
reflexão e testá-los com protótipos.
• Atreva-se a decidir Os designers devem se concentrar no que os clientes fazem e precisam, não necessariamente no que
eles dizem que querem. Os designers devem ser empáticos e capazes de sentir o que é mais importante e tomar decisões
de acordo.
A Figura 3.3 destaca os principais padrões comportamentais que são relevantes para o design thinking.
A história da ITIL: Design thinking
Marco: Ao projetar a nova funcionalidade para nosso aplicativo, tentamos considerar tudo o que teria impacto em
nossos clientes. Levamos em consideração a experiência do cliente inerente aos smartphones, os processos que
sustentam a funcionalidade do aplicativo e as interações do cliente com nossos sistemas ao fazer pedidos, pegar um
carro e viajar. Cada componente do serviço combina com os outros para envolver o cliente e faz parte de toda a
jornada do cliente.
52
0 1 2 3
Baixo Alto
Ajude a
Figura 3.3 Mapa de calor da importância dos principais padrões de comportamento para o design thinking
3.2.2 Pessoas
Os modelos e conceitos da categoria pessoas tratam da organização do trabalho que produz ou depende do conhecimento e da promoção
de um ambiente de trabalho saudável e produtivo. Modelos e conceitos na categoria de pessoas incluem:
• Reconstruindo para agilidade de serviço Uma abordagem para organizar o trabalho do conhecimento e a prestação de serviços que
reflete sua natureza complexa e social.
• Cultura de segurança Promover um clima em que as pessoas se sintam à vontade para estar e se expressar.
• Prevenção do estresse Prevenir, monitorar e remediar a tensão insalubre no local de trabalho.
3.2.2.1 Reconstruindo para agilidade no atendimento
As formas de trabalho do HVIT têm sérias implicações para uma organização e para a maneira como ela gerencia seus serviços.
A gestão é tradicionalmente focada na especialização do trabalho, processos prescritivos e metas para impulsionar e medir o
desempenho, com base na suposição de que os recursos e o trabalho são previsíveis o suficiente para serem controlados em um baixo
nível de granularidade.
No trabalho do conhecimento e na prestação de serviços, no entanto, existem muitas interações humanas sutis que tornam impossível
prever os resultados de uma interação de serviço. Isso torna inútil impor alvos detalhados em humanos como se fossem máquinas. As
pessoas são intrinsecamente imprevisíveis e responderão à intenção percebida de um colega de trabalho ou cliente, que responderá em
troca. Às vezes, a intenção é percebida incorretamente, levando a uma resposta inesperada. Ambas as partes devem, portanto, avaliar
constantemente suas respostas e ajustar de acordo.
Onde os humanos estão envolvidos, as interações de serviço são interações sociais. Uma abordagem de gestão típica não reflete a
realidade social de um local de trabalho de serviço e, portanto, é ineficaz. Uma abordagem melhor3 é afrouxar o controle para que as
pessoas tenham mais liberdade para usar seu julgamento profissional em circunstâncias intrinsecamente imprevisíveis. Isso é central
para a ideia de reconstruir a organização para agilidade de serviço.
53
Definição: Reconstruindo para agilidade de serviço
Uma abordagem para organizar o trabalho do conhecimento e a prestação de serviços que reflete sua natureza complexa e social.
Ao seguir essa abordagem, é desejável manter algum grau de processo em vigor, pois as pessoas geralmente gostam de saber mais ou
menos o que esperar e o que se espera delas. Algum controle também deve ser mantido na forma de restrições relacionadas à estrutura
organizacional.
Dentro dessas diretrizes e limites, no entanto, é importante tratar as pessoas como seres humanos. As saídas e resultados do serviço
podem ser arruinados pelos menores detalhes da interação humana, não apenas com os clientes, mas também com os colegas de
trabalho. Quando processos detalhados e outras restrições encorajam as pessoas a agir de forma tão previsível quanto algoritmos, as
coisas invariavelmente dão errado, pois as pessoas naturalmente agem de forma mais intuitiva e imprevisível.
As pessoas tendem a exibir desobediência inteligente, e isso deve ser incentivado, em vez de punido, para que a coisa certa seja feita para
o cliente.
O grau de controle que deve ser mantido depende em grande parte da previsibilidade e, portanto, da controlabilidade do trabalho
que está sendo executado. Por exemplo, os processos podem ser implementados para trabalhos padronizados ou algorítmicos e
com requisitos, prioridades, abordagens e recursos conhecidos ou conhecidos.
O fornecimento de um laptop padrão para um novo funcionário é um bom exemplo desse tipo de trabalho. O trabalho passa entre
postos especializados de acordo com uma rota predeterminada, e cada posto de trabalho (aprovação, preparação, logística) fica
alheio ao que outros postos fizeram ou farão; mas, seguindo os procedimentos padrão, o trabalho será feito.
Este tipo de trabalho, onde uma pessoa segue um processo pré-definido conduzido por um conjunto de instruções estabelecidas ao
longo de um caminho consistente, é descrito como algorítmico. O trabalho heurístico, por outro lado, é centrado em pessoas criando ideias
e abordagens, criando hipóteses e experimentos até que uma solução seja encontrada. Um bom exemplo disso é o gerenciamento de
casos, que é usado em muitos setores, como serviços de emergência, medicina, assistência social, direito e policiamento. Cada situação ou
'caso' tem que ser tratado de forma diferente pelo gerente de caso porque as situações não se encaixam em um processo pré-determinado.
O trabalho algorítmico sempre produzirá o resultado 'correto' para o qual foi projetado, enquanto o trabalho heurístico geralmente será bem-
sucedido, mas pode levar a uma variedade de resultados.
Ao buscar uma abordagem heurística e menos predefinida para o trabalho, os processos e outras formas de controle às vezes são
usados temporariamente para fornecer suporte até que haja competência e confiança suficientes para trabalhar heuristicamente com
menos restrições.
A gênese do movimento DevOps é um bom exemplo de transformação de baixo para cima, impulsionada pelos valores do praticante.
Começou com a iniciativa de alguns profissionais que formaram um grupo, que se transformou em uma conferência e, eventualmente, em
um movimento global, bem conhecido fora do setor.
Este é um bom exemplo de mudança que foi iniciada e impulsionada pelos valores das pessoas e seus desejos de melhorar as coisas
e se divertir no processo. Não havia direção ou controle de cima para baixo. Na verdade, muito disso aconteceu abaixo do radar
corporativo, o que significa que as pessoas tinham (e reivindicavam) liberdade suficiente para agir sem restrições corporativas.
Valores pessoais
As pessoas fazem suas melhores contribuições para o trabalho que está alinhado com seus valores pessoais, e isso deve sempre ser
uma consideração primordial para as organizações ao recrutar novos funcionários. Isso não significa necessariamente que
54
os funcionários devem ter o mesmo conjunto de valores que sua organização. Isso não é produtivo, pois a diversidade coerente e a
tensão funcional são benéficas para a evolução de uma organização.
É importante que os profissionais estejam cientes dos valores dos membros de sua equipe. Diferenças de valores podem explicar
comportamentos diferentes, e estar ciente disso pode desencadear reflexão e recalibração de modelos mentais individuais ou coletivos.
É ingênuo e moralmente duvidoso tentar mudar os valores de outras pessoas. Os valores surgem ao longo do tempo como resultado
de interações em um determinado contexto social; eles são muitas vezes difíceis de articular e têm de ser experimentados para serem
compreendidos.
Mensagem chave
Ao reconstruir para agilidade de serviço, os profissionais devem aspirar ao seguinte comportamento:
• Afrouxe o controle Dê às pessoas mais liberdade para usar seu julgamento profissional em circunstâncias
intrinsecamente imprevisíveis.
• Usar processos como andaimes temporários para fornecer suporte Processos e outras formas de controle podem
fornecer suporte até que haja competência e confiança suficientes para trabalhar heuristicamente com menos restrições.
• Respeitar os valores dos membros da equipe e permitir que eles trabalhem dentro dessas Pessoas fazem suas
melhores contribuições para um trabalho alinhado com seus valores pessoais.
A Figura 3.4 destaca os principais padrões comportamentais que são relevantes para a reconstrução da agilidade do serviço.
0 1 2 3
Baixo Alto
Ajude a
Figura 3.4 Mapa de calor da importância dos principais padrões de comportamento para reconstrução para agilidade de serviço
55
A história da ITIL: Reconstruindo para agilidade de serviço
Solmaz: Na Axle, temos uma estrutura para orientar nosso trabalho, e a equipe que trabalha no
desenvolvimento da nova funcionalidade do aplicativo segue isso, juntamente com os princípios e políticas da Axle.
A estrutura foi projetada para ser flexível o suficiente para permitir que a equipe se adapte às mudanças nas
circunstâncias e à natureza experimental de seu trabalho. Isso torna mais fácil para eles experimentarem
novas abordagens e métodos ao desenvolver a nova funcionalidade do aplicativo, o que significa que eles têm
mais liberdade para experimentar.
3.2.2.2 Cultura de segurança
As organizações habilitadas digitalmente estão sob pressão especial para melhorar continuamente seu desempenho sob
condições de mercado mutáveis. O progresso tecnológico significa que seus produtos têm um impacto econômico, social e
político cada vez mais significativo e, portanto, o fracasso organizacional pode muitas vezes levar a consequências
desastrosas. O desafio para essas organizações é promover um conjunto eficaz de crenças, percepções e valores
compartilhados em relação aos riscos. Isso, por sua vez, criará uma cultura de segurança e resultará em um comportamento
benéfico para todas as partes interessadas, incluindo a força de trabalho.
Definição: Cultura de segurança
Um clima em que as pessoas se sintam confortáveis sendo (e se expressando).4
Em uma cultura de segurança, as pessoas se sentem confiáveis e valorizadas. Eles são, portanto, mais propensos a apontar
riscos do que quando temem que isso prejudique sua reputação e posição. Uma boa cultura de segurança pode ser promovida
pelo compromisso da alta administração com a segurança, práticas realistas para lidar com riscos, aprendizado organizacional
contínuo e cuidado e preocupação com os riscos compartilhados por toda a força de trabalho. Um 'perigo', neste caso, deve
ser entendido em um sentido mais amplo do que apenas perigos físicos; inclui fatores ambientais, falhas de tecnologia, erros
humanos e fluxos de processo.
Os sistemas complexos que estão frequentemente presentes em ambientes HVIT são inerentemente perigosos. Esses
sistemas sempre contêm várias falhas e, portanto, problemas latentes. Mudanças contínuas no sistema e em seu ambiente
significam que as falhas também mudam continuamente. A maioria dessas falhas é pequena demais para causar problemas
significativos, seja por redundância e outras formas de resiliência no sistema, seja por intervenção humana. Quando problemas
significativos acontecem, geralmente é devido a uma combinação imprevisível de várias falhas e, portanto, não a uma única
causa raiz. Lidar com essas questões requer pessoal experiente e habilidoso e condições de trabalho favoráveis. Essas condições
são mais críticas quando as coisas ficam estressantes, porque nesses momentos, as pessoas voltam ao modo de sobrevivência
com base em suposições profundamente arraigadas sobre a cultura organizacional. Portanto, é crucial que coisas como não
culpar as pessoas e tratar falhas como oportunidades de melhoria sejam mais do que valores corporativos adotados. Em
ambientes HVIT, é crucial que as pessoas se sintam capazes de compartilhar suas opiniões e experimentar melhorias sem medo
de julgamento ou constrangimento.
56
A natureza inerentemente perigosa de sistemas complexos
Richard Cook5 forneceu insights sobre a natureza inerentemente perigosa de sistemas complexos em seu estudo de como esses
sistemas falham. Sua pesquisa se concentrou em dispositivos médicos, que às vezes são críticos para a vida dos pacientes. A ciência
da complexidade evoluiu desde que seu artigo foi publicado, assim como sua terminologia, mas muitas das seguintes afirmações foram
comprovadas e desenvolvidas no contexto de vários setores, incluindo TI:
• Sistemas complexos são sistemas intrinsecamente perigosos.
• Sistemas complexos são fortemente defendidos com sucesso contra falhas.
• A catástrofe requer várias falhas – falhas de ponto único não são suficientes. • Sistemas complexos
contêm misturas variáveis de falhas latentes dentro deles. • Sistemas complexos são executados em
modo degradado.
• A catástrofe está sempre ao virar da esquina.
• A atribuição pós-acidente a uma 'causa raiz' é fundamentalmente errada.
• A retrospectiva influencia as avaliações pós-acidente do desempenho humano.
• Os operadores humanos têm papéis duplos: como produtores e como defensores contra falhas.
• Todas as ações do praticante são apostas. •
Ações na ponta afiada resolvem todas as ambiguidades.
• Profissionais humanos são o elemento adaptável de sistemas complexos.
• A experiência humana em sistemas complexos está em constante mudança.
• A mudança introduz novas formas de fracasso.
• Visões de 'causa' limitam a eficácia das defesas contra eventos futuros. • A segurança é uma
característica dos sistemas e não de seus componentes. • As pessoas criam segurança
continuamente.
• Operações sem falhas requerem experiência com falhas.
Mensagem chave
Ao aplicar a cultura de segurança, os profissionais devem aspirar ao seguinte comportamento:
• Aja sobre os requisitos de segurança Não fale apenas sobre por que a segurança é importante: faça algo a respeito. •
Demonstre vulnerabilidade Não tenha medo de falar sobre quaisquer dúvidas e peça ajuda quando necessário.
• Promova o feedback e aja de acordo com ele.
• Seja gentil e compassivo Construa relacionamentos humanos.
• Seja realista sobre o fracasso Reconheça que o fracasso acontecerá e que as pessoas não são culpadas,
mas o sistema.
A Figura 3.5 destaca os principais padrões comportamentais que são relevantes para a cultura de segurança.
57
0 1 2 3
Baixo Alto
Ajude a
Figura 3.5 Mapa de calor da importância dos principais padrões de comportamento para a cultura de segurança
A história da ITIL: cultura de segurança
Su: O desenvolvimento da nova funcionalidade do aplicativo pode exigir experimentação e, às vezes, a aceitação de falhas
ou alterações inesperadas. Se os membros de nossa equipe se sentirem seguros e valorizados, estarão em melhores
condições para produzir seu melhor trabalho.
Solmaz: Criar uma cultura e um ambiente em que cada membro da equipe se sinta confortável ao demonstrar seu trabalho,
expressar dúvidas ou pedir feedback significa que podemos avançar rapidamente com o design e o lançamento de
atualizações adicionais para o aplicativo e reduz a chance de problemas não serem contestados ou boas ideias sendo
ignoradas.
3.2.2.3 Prevenção de estresse
Definição: Prevenção do estresse
A prevenção, monitoramento e remediação de tensão insalubre no local de trabalho.
Muitas pessoas sofrem de estresse, esgotamento e problemas de saúde mental. Embora as questões de saúde física sejam reconhecidas e
discutidas no trabalho há muito tempo, a discussão sobre questões de saúde mental só começou a sério mais recentemente. Agora, no
entanto, está se tornando aceitável e desejável abordar tais questões.
58
As preocupações com a saúde mental não são exclusivas do HVIT ou TI em geral. Eles são, no entanto, críticos tanto para o alto
desempenho organizacional quanto para o bem-estar dos funcionários.
Alguns trabalhos são mais intrinsecamente estressantes do que outros. O trabalho de desenvolvimento, por exemplo, pode ser estressante
por causa da pressão para cumprir prazos, enquanto no trabalho de operações, o estresse pode vir da pressão constante para responder a
um fluxo interminável de chamadas ou esperar um pager tocar.
Nenhum local de trabalho está sempre livre de estresse. As coisas acontecem inesperadamente, e o equilíbrio certo deve ser
alcançado entre os interesses de todas as partes interessadas, incluindo os funcionários. Portanto, é benéfico ajudar os funcionários
a desenvolver habilidades básicas de vida para negociar e sobreviver à pressão temporária do trabalho, ferramentas inadequadas, mal-
entendidos com gerentes e outros colegas de trabalho e outras situações estressantes.
As pessoas são fundamentais tanto para a entrega eficaz de TI e gerenciamento de serviços quanto para transformações bem-sucedidas.
Muitas vezes, no entanto, a resposta a isso é tratar as pessoas como um problema que precisa ser resolvido, em vez de abordar
as preocupações das pessoas afetadas. Como parte da boa governança corporativa de TI, é vital entender o impacto humano que o
trabalho tem sobre todos os envolvidos. Isso deve ser gerenciado de forma eficaz para gerar uma força de trabalho entusiasmada e
saudável.
Um equilíbrio saudável entre vida profissional e pessoal deve ser visto como um requisito básico de uma organização. Isso é
particularmente relevante agora, pois a natureza hiperconectada do trabalho tende a misturar trabalho e vida, e a introdução de novas
tecnologias torna muito mais fácil para as pessoas serem contatadas e buscarem trabalho fora do horário normal de trabalho.
A ausência de um equilíbrio saudável entre vida profissional e pessoal não pode, a longo prazo, ser compensada de outras maneiras.
À medida que os modelos de entrega adotam abordagens de alta velocidade, as organizações precisam mudar a maneira como criam e
mantêm produtos e serviços. Em alguns casos, isso pode exigir novas tecnologias; mas em todos os casos, haverá uma mudança
significativa na cultura, medição de desempenho e outros elementos humanos; portanto, torna-se ainda mais importante considerar o
impacto humano. Isso se aplica tanto durante a transformação do modelo quanto quando o modelo se tornar a norma. Esses dois estágios
apresentam desafios muito diferentes, mas igualmente sérios, que muitas organizações ainda precisam enfrentar.
Estresse durante a mudança
Quando as formas fundamentais de trabalho são alteradas, o que antes era visto como bom comportamento pode ser prejudicado e
transformado em comportamento menos desejável. Os gerentes podem responder a esse desafio tentando fazer com que as pessoas
mudem esses comportamentos. Embora isso seja importante, eles também devem entender a necessidade de ajudar as pessoas durante o
processo de mudança e que a maneira como os indivíduos processam esse nível de mudança internamente pode diferir significativamente
de uma pessoa para outra.
Isso é especialmente verdadeiro para aqueles que prosperam trabalhando de maneira altamente estruturada, ou cujas funções não
exigem contato humano frequente, ou que têm problemas latentes de saúde mental.6 O dever da organização de cuidar deles não é
removido pela mudança para novos modelos; nem o valor que eles podem trazer para a organização é diminuído.
Estresse durante os negócios como de costume
Quando uma abordagem de alta velocidade é adotada e se torna a maneira regular e incorporada de trabalhar em uma organização,
novas formas de estresse podem ser geradas, que são situacionais, mas de longo prazo. A pressão para entregar constantemente pode ser
exaustiva e desmoralizante. A ameaça da IA substituindo empregos está sempre presente, e o ciclo de entrega pode significar que há poucas
chances de reconhecer e comemorar coletivamente o sucesso. Onde a alta velocidade também depende do suporte de plantão em todos os
momentos e da necessidade de trabalhar em horários não convencionais, o impacto na vida doméstica também pode ser significativo.
59
Abordagens
Deixar de gerenciar adequadamente esses problemas pode levar a consequências significativas tanto para os indivíduos quanto
para a organização, e por isso é importante que eles sejam abordados adequadamente. Existem várias abordagens que podem ser
tomadas para prevenir o estresse no local de trabalho.
As abordagens Lean e Agile incentivam a limitação do trabalho em andamento e puxando o trabalho em vez de tê-lo empurrado de
outras áreas. Isso não apenas melhora o rendimento, mas também reduz a sobrecarga e o estresse potencial.
As técnicas de CI/CD permitem implementações menores, mais frequentes e mais confiáveis. Isso reduz o impacto negativo
potencial nos sistemas operacionais, permitindo que a implantação seja executada durante o horário comercial, em vez de à noite e
nos fins de semana. Isso, por sua vez, ajuda a reduzir a sobrecarga e o estresse potencial de ter que trabalhar fora do horário normal
de trabalho.
Os departamentos de RH podem desempenhar um papel crucial na redução do estresse no local de trabalho e devem estar
envolvidos no desenvolvimento de abordagens estratégicas, táticas e operacionais para esse objetivo, incluindo uma avaliação
de risco detalhada. A assistência de profissionais de saúde mental deve ser procurada ativamente para desenvolver essas
abordagens. Um programa educacional no local de trabalho é essencial para garantir que as pessoas estejam cientes dos sinais
de problemas de saúde mental em si e nos outros, e de como responder corretamente a eles. Este programa deve se estender a ações
claramente compreendidas que protegerão indivíduos que sofrem problemas graves no local de trabalho.
A assistência deve ser fornecida às pessoas com deficiências invisíveis, para garantir que possam interagir efetivamente com
equipes e projetos de alta velocidade, mantendo um senso de controle pessoal sobre seu ambiente. Isso pode significar, por exemplo,
fornecer opções alternativas para uma presença física em Scrums, garantindo que eles tenham um ponto de ligação que entenda suas
formas preferidas de trabalhar e levando em consideração suas necessidades como parte dos processos de planejamento.
As mudanças nos sistemas de gestão de desempenho devem ser equilibradas e manter a flexibilidade para recompensar
comportamentos específicos ao perfil de um indivíduo, quando necessário. Quando as equipes estão atendendo a vários requisitos de
entrega de alta pressão, elas podem ver uma diminuição no estresse por serem capazes de se auto-organizar e manter o gerenciamento
local de priorização e recursos.
Qualquer que seja a opção escolhida, deve-se deixar claro para os funcionários que essas abordagens não fazem julgamentos e que
sua principal preocupação deve ser o bem-estar a longo prazo dos indivíduos. Uma vez que as abordagens tenham sido
implementadas, é vital que elas não sejam subvertidas para atingir outros objetivos.
Vigilância contínua
Uma vez que uma ou mais abordagens para a prevenção do estresse tenham sido implementadas, é vital verificar constantemente
novos problemas potenciais e novas orientações, principalmente em um ambiente de trabalho e de TI em rápida mudança. O trabalho
HVIT é um conceito relativamente novo, o que significa que as pessoas inevitavelmente enfrentarão novos desafios e tensões.
A crescente ênfase na prevenção do estresse e na saúde mental no local de trabalho também dará origem a novas formas de
gerenciar esses problemas, o que pode levar a que conselhos anteriormente aceitos se tornem obsoletos como resultado de novas
evidências e estudos clínicos. Portanto, é importante manter as abordagens de saúde mental e prevenção do estresse atualizadas.
A Figura 3.6 destaca os principais padrões comportamentais relevantes para a prevenção do estresse.
60
Mensagem chave
Ao procurar prevenir o estresse no local de trabalho, os profissionais devem aspirar ao seguinte comportamento:
• Peça conselhos a profissionais de saúde mental.
• Realizar uma avaliação de risco de problemas de saúde mental.
• Desenvolver abordagens estratégicas, operacionais e sem julgamento para estresse e saúde mental.
• Garantir que as abordagens adotadas sejam utilizadas apenas para o bem-estar dos indivíduos, não subvertidas para
outros objetivos.
• Ajude as pessoas com deficiências invisíveis a interagir com as equipes de HVIT de forma eficaz.
A história da ITIL: prevenção do estresse
Henri: Estamos pedindo à nossa equipe que faça melhorias em nosso aplicativo em um ritmo acelerado, o que pode
ser estressante.
Marco: A data de lançamento de uma nova funcionalidade pode ser particularmente estressante para uma equipe
de desenvolvimento.
Radhika: Podemos ajudar a reduzir o estresse de nossos funcionários, garantindo que nosso departamento de RH
esteja adotando as abordagens corretas para apoiar a boa saúde mental e a prevenção do estresse.
Henri: Também podemos oferecer palestras educacionais para nossos funcionários para conscientizá-los sobre os perigos
de níveis excessivos de estresse e o que eles devem fazer se estiverem tendo problemas relacionados ao estresse.
0 1 2 3
Baixo Alto
Ajude a
Figura 3.6 Mapa de calor da importância dos principais padrões de comportamento para a prevenção do estresse
61
3.2.3 Progresso
Os modelos e conceitos na categoria de progresso tratam da compreensão da natureza complexa do trabalho e da melhoria através do
aprendizado. Modelos e conceitos nesta categoria incluem:
• Trabalhar em ambientes complexos Uma abordagem à gestão do trabalho que aplica diferentes heurísticas à tomada de decisão com base no
pensamento da complexidade.
• Cultura Lean Uma maneira de trabalhar que é fundamental para experimentação, aprendizado e melhoria contínuas.
• O modelo de melhoria contínua ITIL Um modelo que fornece às organizações uma abordagem estruturada para
implementando melhorias.
3.2.3.1 Trabalhando em ambientes complexos
Para trabalhar de forma eficaz, os profissionais devem compreender a natureza do ambiente, ou sistema, em que trabalham. Uma característica
importante de um sistema é sua previsibilidade, pois ela determina qual forma de trabalho é eficaz. O pensamento sistêmico em geral, e o
pensamento complexo em particular, ajudam a dar sentido ao sistema e oferecem orientação quanto a abordagens eficazes.
Do ponto de vista prático, o pensamento sistêmico é ver os resultados de nossas ações em um contexto mais amplo. Um sistema é considerado
como um conjunto de partes que, quando combinadas, possuem qualidades que não estão presentes em nenhuma das próprias partes. O
pensamento sistêmico é um campo que ainda está em desenvolvimento, e um dos desenvolvimentos mais recentes é a aplicação da teoria de
sistemas a sistemas complexos e sistemas adaptativos complexos.
Definições
• Pensamento sistêmico Uma abordagem holística para análise e tomada de decisão que se concentra no
relação entre os componentes de um sistema e a forma como o sistema funciona, tanto como um todo quanto no contexto de
sistemas maiores.
• Pensamento de complexidade Uma abordagem de pensamento sistêmico baseada no reconhecimento e compreensão dos vários
níveis de complexidade inerentes aos sistemas e ao contexto em que operam.
• Sistemas adaptativos complexos Sistemas que se adaptam e co-evoluem com um ambiente em mudança,
resultando em:
• comportamento que não é previsto pelo comportamento de partes do sistema
• a incapacidade de examinar o sistema isoladamente de outros sistemas em seu ambiente.
O estudo de sistemas adaptativos complexos é altamente interdisciplinar e combina insights das ciências naturais e sociais. 'Complexo' significa
que o comportamento do todo não é previsto pelo comportamento das partes, e as coisas podem acontecer de forma orgânica e imprevisível. Em
outras palavras, o comportamento é emergente. 'Adaptativo' significa que os sistemas têm a capacidade de mudar e aprender com a experiência.
Sistemas adaptativos complexos exibem um comportamento que não pode ser previsto, mas muitas vezes pode ser explicado retrospectivamente.
Alguns sistemas são imprevisíveis porque seus limites restringem apenas parcialmente os agentes que atuam dentro do sistema, e os agentes
modificam os limites.
62
Exemplos de sistemas adaptativos complexos incluem o mercado de ações, insetos sociais e colônias de formigas, a biosfera, o
cérebro e o sistema imunológico, bactérias, cidades, empresas manufatureiras e qualquer empreendimento baseado em grupos sociais
humanos em um sistema cultural e social, como o político. partidos ou comunidades.
Uma maneira heurística de trabalhar é baseada na exploração e experimentação que favorece a velocidade sobre a completude,
exatidão ou precisão.7 As heurísticas geralmente funcionam, mas os resultados podem variar. As heurísticas baseadas em complexidade
são, portanto, formas exploratórias e experimentais de trabalhar com sistemas que são, por definição, muito imprevisíveis para o
trabalho algorítmico.
Sistemas adaptativos (organizacionais) complexos são frequentemente encontrados em ambientes HVIT. A

imprevisibilidade inerente a esses sistemas apresenta um desafio para as pessoas que estão acostumadas a trabalhar com processos
predeterminados, análises detalhadas e planos de projeto baseados no conhecimento ou cognoscibilidade do trabalho. Em sistemas
complexos, o comportamento surge como resultado de interações imprevisíveis entre muitos agentes e as fronteiras que os restringem
e, portanto, os afetam. Os limites também podem ser afetados pelos agentes, aumentando a imprevisibilidade.
Nestas circunstâncias, é necessária uma abordagem experimental e não linear. Múltiplos experimentos devem ser realizados em
paralelo (para que não se influenciem) e o que funciona e o que não funciona deve ser observado. Os profissionais devem estar
preparados para lidar com os efeitos colaterais negativos de experimentos 'fracassados' e para continuar e ampliar os experimentos
bem-sucedidos, tendo em mente que as circunstâncias e os resultados mudarão.
A maioria das organizações experimentará uma variedade de contextos de trabalho, alguns sendo mais previsíveis do que outros.
Portanto, é importante ser capaz de entender a natureza do trabalho específico que está sendo executado e agir de acordo. A
estrutura de criação de sentido Cynefin8 (veja a Figura 3.7) oferece uma maneira prática de avaliar a complexidade e determinar
cursos de ação apropriados. Distingue entre cinco domínios ou contextos que caracterizam a relação entre causa e efeito:
• Óbvio Clara causalidade, onde as melhores práticas predeterminadas devem ser aplicadas.
• Complicado Causalidade pouco clara, mas conhecida que pode ser determinada por análise ou perícia, seguida por
boa prática.
• Complexo Causalidade pouco clara e desconhecida que requer experimentação segura para falhas (prática emergente).
Complexo Complicado
Sondar–Sentir–Responder Sentir–Analisar–Responder
Transtorno
Caótico Óbvio
Agir-Sense-Responder Sentir–Categorizar–Responder
Figura 3.7 A estrutura Cynefin

Depois de Snowden (2011); reproduzido com permissão da Cognitive Edge
63
• Caótico Uma forma mais extrema de complexidade que exige ação imediata para fazer a transição da situação para complexa
(nova prática).
• Desordem O estado de não saber em qual dos outros domínios você está, com a tendência de assumir que o
domínio corresponde ao contexto em que você é mais experiente.
Cynefin também é descrito como um sistema 'liminar', porque em vez de ter limites completamente sólidos entre cada domínio, as
'bordas' entre ordem, complexidade e caos tendem a ser pensadas como uma mudança de fase. Os limites liminares são transitórios:
uma questão pode estar em estado de tensão entre domínios adjacentes.
O reconhecimento da complexidade e, portanto, da imprevisibilidade, como um estado de coisas legítimo permite que os engenheiros
repensem sua crença de que processos e planos rígidos são a maneira organizacionalmente correta de responder a todas as situações.
Como uma falha complexa não possui um caminho único e consistente de uma causa a um efeito, é provável que vários fatores sejam
causais e é provável que não haja um precedente exato para eles em questões abordadas anteriormente.
Além disso, as evidências disponíveis podem apoiar teorias conflitantes sobre o que está causando o problema. Para solucionar
problemas nesta circunstância, Cynefin define uma série de etapas a serem seguidas:
• Identifique várias hipóteses para o que pode estar acontecendo.
• Em paralelo, teste cada hipótese 'coerente' (ou seja, plausível) usando experimentos pequenos e seguros para falhas.
• Observe o impacto dos experimentos.
• Onde resultados positivos forem observados, tente amplificá-los. Com resultados negativos, tente
amortecer seu efeito.
A imprevisibilidade não é necessariamente indesejável; isso depende da natureza das atividades. Em geral, as operações se
beneficiam da baixa variabilidade, enquanto a pesquisa e o desenvolvimento se beneficiam da alta variabilidade. Quanto menor a
variabilidade nos processos de produção e entrega, mais consistente a qualidade do produto e mais rápida e barata a produção. A
variabilidade pode ser reduzida descobrindo e lidando com suas causas subjacentes (raiz).
Há também circunstâncias em que a alta variabilidade é benéfica. Em pesquisa e desenvolvimento, onde há incerteza sobre o potencial
de um produto, essa variabilidade pode ser explorada obtendo feedback rápido, assumindo riscos racionais e alterando dinamicamente
o produto em resposta. Um bom exemplo é o conceito de produto mínimo viável, no qual um produto útil, mas não completo, é lançado
para avaliar o potencial de mercado e ajustar o produto de acordo. Há um paralelo com as opções de ações: quanto maior a
variabilidade, maior o lucro potencial com uma perda limitada. Quanto mais tempo as decisões de desenvolvimento de produtos
puderem esperar para serem tomadas, mais opções haverá para aumentar o valor do produto.
Em sistemas complexos, as falhas são inevitáveis; prevenir falhas é impossível. Existem, no entanto, várias maneiras de responder a
falhas. Por exemplo, antifragilidade é uma qualificação de sistemas adaptativos complexos que aumentam em capacidade, resiliência
ou robustez como resultado de estresse ou falha. É contrastado com fragilidade (falha), resiliência (recuperando-se de uma falha) e
robustez (resistindo a falha).
Essa maneira divergente de pensar sobre sistemas é eficaz, mas tem um preço, pois os profissionais devem avaliar continuamente se
estão adotando a abordagem correta. Eles não devem ser tentados pela simplicidade superficial da 'melhor prática' que foi relatada e
que se acredita ter funcionado em outros lugares, mas fazer um esforço para buscar a melhor solução através de um estudo diligente.
A Figura 3.8 destaca os principais padrões comportamentais relevantes para trabalhar em ambientes complexos.
64
Mensagem chave
Ao trabalhar em ambientes complexos, os profissionais devem aspirar ao seguinte comportamento:
• Avalie a causalidade, estando ciente do viés natural em relação ao domínio da experiência dominante.
• Agir de acordo com o contexto; em termos de Cynefin:
• No domínio Óbvio, aplique construções como processos prescritivos e cascata detalhada

planos baseados.
• No domínio Complicado, aplique construções como gerenciamento de caso9 e timeboxing. Quando

transição de Complexo para Complicado, aplique construções como Scrum.
• No domínio Complex, aplique técnicas 'pré-Scrum', como paralela/independente

experimentação e desintermediação do analista para descobrir e resolver requisitos de usuário não
articulados ou ambíguos.
• No domínio Caótico, assuma o controle e aja rapidamente para estabilizar a situação e fazer a transição para o
domínio Complexo.
• Cuidado ao usar 'receitas' baseadas em casos que são apresentados como se pudessem ser adotados sem
adaptação; entender o contexto e não confundir correlação com causalidade (às vezes as coisas não se repetem no
mesmo contexto); nunca repita 'o que você faz' sem entender 'por que você faz'; não copie cegamente os líderes da
indústria.
• Tenha cuidado ao definir o estado futuro e fechar a lacuna; não tente projetar sistemas humanos, mas evolua-os;
desenvolver o potencial evolutivo do presente e passar para o 'possível adjacente'.
0 1 2 3
Baixo Alto
Ajude a
Figura 3.8 Mapa de calor da importância dos principais padrões de comportamento para trabalhar em ambientes complexos
65
A história da ITIL: Trabalhando em ambientes complexos

Su: Como acontece com qualquer sistema complexo, o negócio da Axle Car Hire tem muitos componentes interativos.
Isso inclui equipes e serviços internos e externos, clientes e seus comportamentos e fatores externos, como fluxo de
tráfego, mudanças nas estradas e ações industriais que podem afetar nossas dependências (por exemplo, assistência na
estrada ou abastecimento de gasolina).
Marco: À medida que desenvolvemos a nova funcionalidade para nosso aplicativo, devemos estar atentos a como isso
pode afetar as áreas mais amplas da Axle e seus negócios. Por exemplo, se introduzirmos atualizações automáticas de
veículos por meio do aplicativo, precisamos ter certeza de que nossos outros sistemas e infraestrutura são capazes de se
coordenar adequadamente com essa funcionalidade.
Su: Se precisarmos fazer alterações no aplicativo para acomodar essas outras áreas, devemos ser adaptáveis sem
perder o controle de nosso trabalho.
3.2.3.2 Cultura Lean
Definição: cultura Lean
Um ambiente de trabalho onde a confiança, o respeito, a curiosidade, a investigação, a diversão e a intensidade coexistem para
apoiar a aprendizagem e a descoberta.
Lean é um equilíbrio entre a busca por padronização e previsibilidade para evitar erros e, ao mesmo tempo, promover uma cultura de
tomada de risco calculada, curiosidade e investigação, com base em uma base de confiança e respeito.
Para ser eficaz, resiliente e adaptável, um ambiente HVIT deve ser construído sobre uma base sólida da cultura Lean.
Os líderes desempenham um papel fundamental na definição das normas sociais e expectativas das equipes e sua interação com outras
equipes. A cultura Lean se resume aos padrões sociais que motivam as pessoas e inspiram um forte nível de engajamento. Os líderes
Lean articulam esse objetivo e apoiam as pessoas na resolução de problemas à medida que buscam alcançá-lo.
O Lean produziu muitas ferramentas e métodos (mapeamento do fluxo de valor, solução estruturada de problemas, trabalho padrão e Hoshin
Kanri, para citar apenas alguns). Essas ferramentas foram refinadas ao longo de décadas, mas raramente são aplicadas de forma eficaz no
nível de obtenção de resultados inovadores. Isso geralmente ocorre devido à falta de consciência focada e atenção necessária para
experimentar o processo de pensamento/aprendizado/descoberta inerente a toda prática Lean.
A Tabela 3.2 descreve os elementos de uma cultura Lean.
66
Tabela 3.2 Elementos da cultura Lean
Confiar A confiança garantida no caráter, habilidade, força ou verdade de alguém ou alguma coisa, incluindo uma equipe, um processo de trabalho e, mais importante, processo.
Respeito O ato de dar atenção especial, consideração, consideração especial e estima a outro.
Curiosidade Um desejo implacável de saber como e por que as coisas funcionam, o que faz as coisas funcionarem melhor e o que 'melhor' parece depois que as coisas são
melhoradas.
Investigação Uma busca sistemática pelos fatos sobre a natureza das coisas: suas origens, suas causas, suas interdependências, seus ciclos de vida e sua natureza.
Brincadeira Uma maneira nova e divertida de visualizar ideias e sua relação com outras ideias, ao mesmo tempo em que mantém um foco sério.
Intensidade Um foco profundo no tópico em questão e a persistência para não se distrair ou perder o caminho.
O que precisa estar em vigor para criar, nutrir e sustentar uma cultura Lean?
Os líderes devem saber o que fazer para promover uma cultura Lean consciente e por que estão fazendo isso. A habilidade chave
que os líderes precisam desenvolver é a consciência do momento presente. Essa abordagem se concentra na criação de um ambiente
em que os funcionários da linha de frente que recebem segurança, suporte, tempo e espaço para experimentar coisas novas
aprenderão com o que funciona e com o que não funciona.
Os líderes precisam estar profundamente conscientes do que as pessoas estão dizendo e fazendo, e se conectarem respeitosamente com os outros.
Os funcionários precisam acreditar que estão seguros ao trazer problemas, oferecer ideias, pedir ajuda ou simplesmente dizer que não
estão claros em seu trabalho. Os comportamentos dos gerentes tradicionais não comunicam nenhuma dessas crenças, criam segurança
psicológica ou ajudam a criar o tipo de ambiente que convida ou apoia o engajamento ou a iniciativa dos funcionários.
Talvez a coisa mais importante que líderes e gerentes possam fazer seja moldar a cultura e alinhar o foco. Para que isso aconteça, eles
precisam saber qual cultura estão tentando construir e articulá-la claramente dentro do contexto dos objetivos de sua organização.
Novamente, isso requer um alto grau de consciência pessoal e segurança psicológica.
Gerentes que são apoiados e incentivados a criar uma nova maneira
A liderança sênior deve modelar, treinar e reforçar novas formas de pensar, agir e apoiar as pessoas. Para que isso aconteça, eles
devem conhecer e colocar em prática alguns novos comportamentos:
• Faça perguntas se eles não tiverem as informações de que precisam.
• Ouça a pessoa, não apenas o problema.
• Reconheça que eles ouviram e o que ouviram.
• Faça perguntas focadas nas coisas sobre as quais eles se perguntam, não no que eles estão pensando.
• Pergunte que ajuda é necessária.
Esses comportamentos podem ser adotados na condução de caminhadas no Gemba. As caminhadas pelo Gemba são uma
parte importante da filosofia de gestão Lean. Os gerentes observam o processo real de trabalho, entendem o trabalho, fazem perguntas
e aprendem. Isso leva a uma melhor compreensão de todo o fluxo de valor e seus problemas, em vez de basear a compreensão em
relatórios de segunda mão e uma abstração idealizada do local de trabalho.
Esses comportamentos exigem um alto grau de autoconsciência e inteligência emocional. Mindfulness é a habilidade chave que posiciona
alguém para desenvolver as habilidades de comunicação, coaching e liderança necessárias para apoiar e incentivar os outros. Pensar sem
consciência é conhecido como muda (desperdício, atividade sem valor agregado). É por isso que a presença consciente ou fluxo profundo
é tão essencial para uma cultura Lean.
A Figura 3.9 destaca os principais padrões comportamentais que são relevantes para a cultura Lean.
67
Mensagem chave
Ao aplicar a cultura Lean, os profissionais devem aspirar ao seguinte comportamento:
• Confie nas pessoas e no 'sistema', mas permaneça vigilante e dê feedback quando necessário.
• Trate as pessoas decentemente.
• Esforce-se para entender como as coisas funcionam e o que pode ser melhorado.
• Reúna os fatos sistematicamente e questione as hipóteses.
• Desenvolva novos insights com uma combinação de criatividade e análise.
• Concentre-se conscientemente no tópico em questão.
A história da ITIL: cultura Lean
Marco: Incentivamos nossa equipe de desenvolvimento de aplicativos a adotar uma cultura Lean, criando um ambiente de
trabalho de confiança, respeito, curiosidade, questionamento, diversão e intensidade.
Solmaz: O trabalho de desenvolvimento de aplicativos muitas vezes pode ser experimental, e adotar essa cultura permite que
nossa equipe assuma riscos calculados e os ajuda a explorar uma variedade de opções para implementar novas funcionalidades.
0 1 2 3
Baixo Alto
Ajude a
Figura 3.9 Mapa de calor da importância dos principais padrões de comportamento para a cultura Lean
68
Figura 3.10 O modelo de melhoria contínua ITIL
3.2.3.3 Modelo de melhoria contínua ITIL

O modelo de melhoria contínua da ITIL (veja a Figura 3.10) fornece às organizações uma abordagem estruturada para
implementar melhorias. O modelo se aplica a todo o sistema de valor do serviço e seu uso torna as iniciativas mais propensas
a serem bem-sucedidas. Ele suporta uma abordagem iterativa de melhoria, dividindo o trabalho em partes gerenciáveis com
objetivos separados que podem ser alcançados de forma incremental.
Os ambientes HVIT aplicam o modelo de melhoria contínua com foco na iteração, experimentação e pensamento
científico orientado por dados. O modelo de melhoria contínua é um componente crítico da abordagem geral de melhoria
de uma organização que deve ser aplicada a produtos e serviços, a todas as práticas de gerenciamento e à própria
prática de melhoria contínua (veja a Figura 3.11). Embora o desenvolvimento e a revisão do
Melhorar
Práticas de gerenciamento Produtos e serviços
Orienta o Orienta o
Análise Melhoria de Melhoria de
Abordagem de melhoria contínua
Figura 3.11 Domínios de melhoria
69
abordagem de melhoria contínua é responsabilidade da administração de uma organização, recomenda-se que os profissionais em
todos os níveis se envolvam na melhoria contínua.
Mais informações sobre o modelo de melhoria contínua e sua aplicação podem ser encontradas no guia de práticas de melhoria
contínua e em ITIL® 4: Direct, Plan and Improve.
Toyota Kata
De todos os tipos de organização, aquelas que são habilitadas digitalmente estão sob pressão especial para melhorar continuamente
seu desempenho sob condições de mercado mutáveis. As circunstâncias são muitas vezes imprevisíveis, tornando difícil ou mesmo
irresponsável criar e seguir planos predeterminados para grandes mudanças. As melhorias são feitas passo a passo, com base na boa
interpretação das informações disponíveis. Circunstâncias em mudança exigem que as organizações sejam flexíveis e criativas na
maneira como definem maneiras de melhorar. Ao mesmo tempo, as iniciativas de melhoria devem ser disciplinadas, orientadas por dados
e justificadas. Isso requer crença no pensamento científico, execução disciplinada, prática para desaprender velhos hábitos e aprender e
sustentar novos, e confiança e competência para improvisar quando apropriado.
O pensamento científico disciplinado com melhorias incrementais reduz nosso viés natural de tirar conclusões erradas. A prática e o
coaching nos ajudam a formar e sustentar novos hábitos, após os quais podemos começar a improvisar.
Uma abordagem para a experimentação científica é o Toyota Kata.
Definição: Toyota Kata
Um modelo mental e padrão de comportamento para o pensamento científico e rotinas para prática e coaching.
Essa abordagem de melhoria em quatro etapas é baseada em cinco perguntas:
• O que estamos tentando alcançar?

• Onde estamos agora?
• Que obstáculo está agora em nosso caminho?
• Qual é o nosso próximo passo e o que esperamos?
• Quando podemos ver o que aprendemos ao dar esse passo?
As etapas do kata de melhoria são:
1. Entenda a direção: a melhoria deve visar objetivos específicos, não apenas aleatórios.
2. Compreenda a condição atual: uma direção não é útil a menos que saibamos onde estamos agora.
3. Estabeleça a próxima condição-alvo e identifique os obstáculos: descreva o resultado que desejamos a seguir e o
condição esperada do processo para gerar esse resultado.
4. Experimente para a próxima condição-alvo: crie ideias para superar um obstáculo e faça experimentos com essa ideia. Se
possível, teste apenas uma hipótese de cada vez.
Essas etapas são descritas na Figura 3.12.
No contexto do modelo de melhoria contínua ITIL, o Toyota Kata ajuda a responder às perguntas:
• Etapa 1: Qual é a visão?
• Etapa 2: onde estamos agora?
70
1
3 Pegue o
direção ou
desafio
Obstáculos Estabelecer
Limite de seu próximo
conhecimento alvo
doença
2
4
Segure o
atual Experimentos
doença
Figura 3.12 Toyota Kata10
• Passo 3: Onde queremos estar?
• Passo 4: Como chegamos lá?
Essa abordagem funciona efetivamente onde há muitas opções disponíveis para responder à pergunta 'Como chegamos lá?' ou
mesmo 'Onde queremos estar?', e a experimentação é a melhor maneira de responder a isso.
O Toyota Kata ajuda a justificar a confiança para perseguir objetivos aparentemente inatingíveis em sistemas complexos e
ajuda as equipes que tomam suas próprias decisões e manobram com eficiência.
A adoção do Toyota Kata demonstra o compromisso com o melhor desempenho e ajuda a lidar com a incerteza adotando uma
abordagem passo a passo. Sua ênfase na observação, descoberta e melhoria correlaciona-se fortemente com a melhoria por ser
curioso.
Ciclo OODA
O loop OODA11 é outra técnica de melhoria que pode ser utilizada no contexto de HVIT. OODA significa 'observar, orientar, decidir,
agir'. O loop OODA originou-se em operações durante campanhas militares e agora também é aplicado com frequência em outros
tipos de organizações. A abordagem mostra como a agilidade pode superar o poder bruto. É especialmente aplicável à segurança
cibernética e é considerado para tornar os processos mais imediatamente reativos do que a abordagem PDCA (plan-do-check-act)
mais familiar. Portanto, é popular em indústrias onde surgem desafios inesperados.
O loop OODA foi desenvolvido para explicar como direcionar energias para derrotar um combatente. O loop é na verdade um
conjunto de loops interativos que estão em operação contínua durante o combate. Todas as decisões são baseadas em observações
da situação em evolução em combinação com a filtragem do problema em questão. Decisões e ações são baseadas em observações,
que são processadas para orientá-las para a tomada de decisão. A orientação é a parte mais importante do ciclo porque informa
como observar, decidir e agir. A orientação é influenciada pela herança genética, tradição cultural e experiência anterior.
71
Mensagem chave
Ao usar a melhoria contínua, os profissionais devem aspirar ao seguinte comportamento:
• Estabelecer visão, missão e objetivos do negócio.

• Realize avaliações de linha de base.
• Defina metas mensuráveis.
• Definir o plano de melhoria.
• Reconhecer a complexidade e experimentar.
• Executar ações de melhoria.
• Avaliar métricas e indicadores chave de desempenho (KPIs).
A Figura 3.13 destaca os principais padrões comportamentais que são relevantes para a melhoria contínua.
A história da ITIL: modelo de melhoria contínua da ITIL
Solmaz: Seguimos os passos do modelo de melhoria contínua ITIL ao implementar novas funcionalidades e
melhorias em nosso aplicativo. No entanto, às vezes não sabemos como alcançar o próximo estado-alvo, ou
mesmo qual pode ser esse estado. Em tais situações, vamos experimentar para identificar o melhor próximo
passo.
0 1 2 3
Baixo Alto
Ajude a
Figura 3.13 Mapa de calor da importância dos principais padrões de comportamento para a melhoria contínua
72
3.3 Princípios orientadores da ITIL
Os princípios orientadores da ITIL incorporam as mensagens centrais da ITIL e do gerenciamento de serviços em geral. Eles ajudam na
adoção e adaptação da orientação ITIL às necessidades e circunstâncias específicas de qualquer organização, incluindo organizações
HVIT. Os princípios também incentivam e apoiam as organizações na melhoria contínua em todos os níveis.
Alguns dos princípios orientadores da ITIL se manifestam mais em um ambiente HVIT do que outros. Esta seção descreve como cada
princípio pode ser aplicado a uma forma de trabalho HVIT.
3.3.1 Foco no valor

O princípio do foco no valor afirma que tudo o que uma organização faz precisa mapear, direta ou indiretamente, o valor para os
stakeholders. Abrange muitas perspectivas, incluindo a experiência de clientes e usuários.
O foco no princípio do valor se reflete em dois dos objetivos do HVIT: investimentos valiosos e valor cocriado. Este princípio é
particularmente aplicável ao HVIT porque os produtos e serviços digitais que as organizações de HVIT fornecem afetarão seus
consumidores.
Ao trabalhar em uma organização HVIT, é importante ter em mente que pode ser necessário criar valor para:
• colegas em toda a organização (por exemplo, diretores de conformidade, auditores, agentes de suporte ou
equipes de desenvolvimento)
• partes interessadas externas que se beneficiam de valor, riqueza ou informações geradas entre a organização e seus consumidores (por
exemplo, acionistas, autoridades fiscais, autoridades regulatórias, fornecedores ou fornecedores de tecnologia).
Cada grupo de partes interessadas pode ter uma expectativa de valor diferente, e a organização precisa encontrar maneiras de
equilibrar as necessidades muitas vezes conflitantes. Em um ambiente HVIT, as partes interessadas e suas necessidades provavelmente
mudarão com frequência. Como resultado, o foco no princípio de valor tem uma conexão muito forte com o princípio de pensar e
trabalhar de forma holística.
3.3.2 Comece onde você está

O princípio de começar onde você está está focado em não começar do zero e construir algo novo sem considerar o que já está
disponível para ser aproveitado. Isso é particularmente verdadeiro para uma organização que deseja passar por uma transformação digital.
A organização pode já ter muitos dos recursos necessários para o trabalho de alta velocidade, embora possa precisar modificá-los para
atender a novos objetivos e formas de trabalho. Por exemplo:
• Os processos de habilitação de mudanças existentes podem precisar ser reorientados para enfatizar modelos de mudança padrão em
vez de aprovações por um conselho consultivo de mudanças.
• O gerenciamento de projetos pode precisar se concentrar na governança do trabalho em relação ao caso de negócios e na coordenação
em várias equipes de TI e não TI.
Existe o perigo de que, ao seguir uma forma de trabalho HVIT, uma organização possa afetar seus relacionamentos, sabedoria e inteligência
existentes. Embora isso possa ser necessário em alguns casos, as organizações devem ter o cuidado de revisar o que têm antes de
prosseguir, pois muito disso pode ser mantido para o trabalho de HVIT. Por exemplo:
• Muitos gerentes de projeto conhecem e entendem o tempo necessário para lançar um produto em um complexo
ecossistema.
• Muitos gerentes de compras construíram relacionamentos com os principais fornecedores, parceiros e fornecedores, que podem
fornecer recursos para trabalho de alta velocidade.
73
HVIT é reduzir o tempo total da ideia ao lançamento para a entrega de um produto digital. Ao considerar opções para reutilizar o
que já existe em vez de simplesmente construir do zero, as organizações geralmente podem entregar produtos ao mercado mais
rapidamente.
3.3.3 Progresso iterativamente com feedback
Este princípio está focado em resistir à tentação de fazer tudo de uma vez. Mesmo grandes iniciativas precisam ser realizadas de
forma iterativa. Quando o trabalho é organizado em seções menores e gerenciáveis que podem ser executadas e concluídas em
tempo hábil, o foco em cada esforço menor é mais nítido e fácil de manter. O uso de feedback antes, depois e durante cada iteração
garantirá que as ações sejam focadas e apropriadas, mesmo em circunstâncias mutáveis e imprevisíveis.
Progredir de forma iterativa com feedback é um dos princípios centrais da maneira de melhorar do Toyota Kata, que oferece
orientação para a melhoria passo a passo com base no pensamento científico orientado por dados (consulte a seção 3.2.3.3).
Uma abordagem iterativa não se limita ao desenvolvimento de software e pode ser adotada pelo gerenciamento de serviços
trabalhando em um ambiente de alta velocidade. Por exemplo:
• A introdução ou modificação da habilitação de mudanças para focar na padronização das mudanças pode ser implementada de
forma iterativa, usando o feedback de todas as partes interessadas relevantes para melhorar a prática de forma incremental.
• Os registros de melhoria contínua podem ser escritos como épicos e histórias de usuários e programados em iterações curtas que
usam ciclos de feedback para determinar se as melhorias tiveram os efeitos desejados.
Os ciclos de revisão de entrega de serviços com os principais parceiros e fornecedores podem ser reduzidos de ciclos trimestrais para
mensais, ou mesmo semanais, criando um ciclo de entrega e feedback rápido para permitir uma maneira de trabalhar em alta velocidade.
3.3.4 Colaborar e promover visibilidade
Esse princípio afirma que trabalhar em conjunto além das fronteiras produz resultados com melhor adesão, maior relevância para os
objetivos e maior probabilidade de sucesso a longo prazo. A realização requer informação, compreensão e confiança. O trabalho e
as consequências devem ser visíveis, as agendas ocultas devem ser evitadas e as informações devem ser compartilhadas o máximo
possível.
Este princípio é particularmente relevante para HVIT, pois o trabalho em alta velocidade depende de acesso rápido a diferentes
recursos, incluindo informações, e uma forma de trabalho altamente colaborativa.
Ao trabalhar em um ambiente HVIT, é importante:
• modular o grau de independência, auto-organização, colaboração e visibilidade para minimizar a sobrecarga de trabalho
• promover a visibilidade ponto a ponto ao longo de um fluxo de valor, juntamente com visibilidade hierárquica entre os
gestão e liderança, e engenheiros e pessoal da linha de frente.
Exemplos deste princípio posto em prática incluem:
• registrar alterações técnicas e incidentes em uma ferramenta centralizada para relatar e escalar para o nível sênior
gestão
• usar um quadro branco ou parede acessível ao público para documentar o trabalho em andamento, mas também manter
informações em formato eletrônico para que possam ser facilmente comunicadas, analisadas e relatadas
• liderança sênior publicando e promovendo metas, objetivos e políticas organizacionais.
74
3.3.5 Pense e trabalhe de forma holística
Este princípio afirma que nenhum serviço ou elemento usado para fornecer um serviço está sozinho. Os resultados alcançados pelo
provedor de serviço e pelo consumidor do serviço sofrerão a menos que a organização trabalhe no todo, não apenas nas partes.
Os resultados são entregues aos clientes internos e externos por meio da gestão eficaz e eficiente e da integração dinâmica de informações,
tecnologia, organização, pessoas, práticas, parceiros e acordos, todos coordenados para fornecer um valor definido.
Muito do pensamento em HVIT concentra-se corretamente em atender às necessidades dos consumidores. No entanto, existem muitas
outras partes interessadas que podem ser impactadas positiva ou negativamente pelo trabalho de alta velocidade. Portanto, é importante
pensar nas implicações que as decisões tomadas por equipes de alta velocidade têm para todas as partes interessadas. Por exemplo:
• A redução dos esforços de documentação pode ter um impacto positivo no desenvolvimento de software e
prática de gerenciamento, mas pode afetar negativamente outras práticas, como central de serviços, gerenciamento de versões,
gerenciamento de conhecimento, gerenciamento de incidentes ou gerenciamento de problemas.
• A mudança para a computação em nuvem altera o equilíbrio das despesas de capital e receitas/despesas operacionais,
o que, por sua vez, tem impacto na governança financeira e nos resultados que a organização reporta aos acionistas e autoridades fiscais.
A introdução de novos produtos e serviços digitais pode ter efeitos indiretos nas indústrias (exemplos famosos incluem táxis,
hospitalidade e aluguel de vídeo), o que, por sua vez, pode criar resultados positivos e negativos para as sociedades e economias
locais.
3.3.6 Mantenha-o simples e prático
Este princípio afirma que se um processo, serviço, ação ou métrica não fornece valor ou não produz resultado útil, ele deve ser
eliminado. Em um processo ou procedimento, o número mínimo de etapas necessárias para atingir o(s) objetivo(s) deve sempre ser
usado. O pensamento baseado em resultados também deve sempre ser usado para produzir soluções práticas que produzam resultados.
Este princípio se aplica ao trabalho de HVIT e aos sistemas que o cercam e possibilitam, e ao consumo de produtos e serviços.
Mantê-lo simples não significa manter as coisas simplistas, mas refere-se à filosofia de reduzir responsabilidades gerais, otimizar (ou em
alguns casos reduzir) o grau de automação e reduzir o atrito entre as equipes.
Exemplos de como este princípio pode ser aplicado ao trabalho HVIT incluem:
• identificar as informações mínimas necessárias para realizar o trabalho, e não sobrecarregar as ferramentas de monitoramento e
gerenciamento de configuração de banco de dados (CMDB) para rastrear tudo o que a organização pode gerenciar
• usar uma parede com notas adesivas para acompanhar o trabalho, em vez de investir em um sistema eletrônico de gerenciamento de trabalho
• reduzindo o número de campos que um consumidor precisa preencher para se inscrever em uma conta, mas ainda coletando
informações suficientes para permitir o trabalho de serviço e suporte.
3.3.7 Otimizar e automatizar
Este princípio afirma que os recursos de todos os tipos, particularmente os recursos humanos, devem ser usados da melhor maneira
possível. Qualquer coisa que seja realmente um desperdício deve ser eliminada, e a tecnologia deve ser usada para fazer tudo o que a
tecnologia pode fazer. A intervenção humana deve ser reservada para onde realmente contribui com valor.
75
O princípio de otimizar e automatizar se manifesta não apenas na melhoria contínua dos produtos e serviços digitais de uma
organização, mas também na melhoria de seus processos. Exemplos de aplicação deste princípio ao trabalho HVIT incluem:
• documentar e simplificar os processos implementados para testar o software antes de investir em ferramentas de CI/CD
• projetar formulários iterativamente para diferentes tipos de tíquetes (por exemplo, solicitações de mudança, tíquetes de incidentes ou formulários de
solicitação) antes de procurar ferramentas e fluxo de trabalho de gerenciamento de serviços e de TI para acelerar o processamento de tíquetes.
É um erro comum otimizar uma única parte de um sistema e trabalhar para a eficiência individual em vez da eficácia geral. Isso
geralmente cria filas que realmente retardam o processo geral, mesmo quando a eficácia individual é otimizada.
3.4 Resumo
Este capítulo explorou os aspectos culturais da transformação digital e as principais abordagens por meio das quais o comportamento
e as atitudes dos profissionais podem evoluir em relação a esses aspectos.
Para sobreviver e ter sucesso em um ambiente de alta velocidade, organizações e pessoas devem adotar os seguintes padrões de
comportamento:

• confiar e ser confiável
• elevar continuamente a fasquia
• ajudar a realizar o trabalho dos clientes
Para apoiar esses comportamentos, as organizações devem evoluir a maneira como pensam e operam em relação ao propósito, às
pessoas e ao progresso:
• como eles definem e cumprem sua missão e objetivos
• como eles garantem um ambiente produtivo, seguro e livre de estresse para seus funcionários
• como eles permitem alto desempenho em circunstâncias em constante mudança.
O capítulo descreveu e explicou abordagens e técnicas para abordar todos os três aspectos.
Esses padrões de comportamento e a cultura organizacional em geral criam um ambiente onde muitas das técnicas e modelos
descritos no Capítulo 4 podem ser aplicados com sucesso.
76
CAPÍTULO 4
ALTA VELOCIDADE
TÉCNICAS
4
Técnicas de TI de alta velocidade
Este capítulo descreve uma seleção de técnicas que caracterizam os ambientes HVIT. Algumas geralmente são encontradas apenas
nesses ambientes, enquanto outras são técnicas mais gerais que são cruciais para o trabalho de HVIT. A seleção não é exaustiva;
essas técnicas são exemplos que caracterizam formas de trabalho que ajudam organizações altamente habilitadas digitalmente a
atingir seus objetivos exigentes.
As técnicas neste capítulo são agrupadas e descritas com base em sua relação com um dos cinco objetivos do HVIT:
• investimentos valiosos
• desenvolvimento rápido
• operações resilientes
• valor cocriado
• conformidade garantida.
Embora as técnicas listadas aqui sejam agrupadas por esses objetivos, uma técnica geralmente suporta vários objetivos. Cada
técnica pode ser usada no contexto de várias práticas de gerenciamento de ITIL e, no final de cada uma das seções a seguir, há uma
tabela que lista quais práticas a técnica discutida é relevante e descreve como essa técnica contribui para cada prática. Há também um
mapa de calor para cada uma das técnicas, que indica aproximadamente o quanto cada atividade da cadeia de valor do serviço ITIL é
afetada por essa técnica.
A história da ITIL: técnicas de TI de alta velocidade

Su: A atualização do nosso aplicativo de reservas que melhorará seu desempenho em smartphones e
dispositivos foi implantada com sucesso. Temos planos de desenvolver ainda mais o aplicativo, adicionando
funcionalidades suplementares, como um programa de associação, links de afiliados, reserva prioritária e upgrades
de veículos. Utilizamos e continuaremos a utilizar muitas técnicas que nos ajudam a otimizar nosso trabalho e focar
em valor.
4.1 Técnicas para investimentos valiosos

O objetivo de investimentos valiosos envolve identificar e justificar investimentos digitais que contribuam significativamente para a
estratégia de negócios. Este exercício deve resultar em uma boa compreensão do valor potencial de um investimento digital, custos
previstos e retorno do investimento, e os critérios definidos para sua utilidade. A garantia, ou requisitos não funcionais, também deve ser
determinada, embora não acrescente ao valor potencial da funcionalidade. A garantia garante que o valor potencial de um investimento
não seja afetado negativamente por interrupções, mau uso ou outros fatores.
78
A realização de investimentos valiosos baseia-se na pesquisa de mercado e no desenvolvimento de novos produtos. Novos
produtos e serviços digitais devem ser pensados e avaliados em termos de rentabilidade. A qualidade substantiva dos produtos
e serviços e o momento em que são lançados são fatores cruciais para obter e manter uma vantagem competitiva. Quanto mais
cedo um investimento potencial for previsto e avaliado, mais cedo os benefícios, como vantagem competitiva, poderão ser obtidos.
Princípios éticos devem ser usados para tomar decisões de investimento que considerem uma ampla gama de interesses das
partes interessadas.
Também é importante avaliar continuamente os investimentos depois de justificados e aprovados, pois podem existir opções
mais valiosas de investimento. Quanto mais cedo as informações sobre investimentos alternativos forem disponibilizadas, mais
cedo os investimentos atuais poderão ser reavaliados.
Fazer investimentos valiosos em organizações comerciais geralmente significa obter mais receita por meio de vendas e
preços mais altos, despesas operacionais e de capital reduzidas ou riscos reduzidos. Em organizações sem fins lucrativos,
investimentos valiosos não são focados em receita, mas se relacionam ao objetivo primário específico da organização.
Investimentos valiosos podem ser medidos por receitas e custos de vendas, mas também por competências que foram
desenvolvidas durante a realização do investimento. O valor de um investimento só pode ser determinado quando o retorno é
realizado; isso ocorre após o investimento, quando o valor é cocriado entre o provedor, o consumidor e outros stakeholders.
Nas organizações digitais, a TI impulsiona e capacita os negócios. Portanto, é de importância crucial que o potencial em
constante evolução da TI seja continuamente avaliado para obter vantagens estratégicas. As principais preocupações nisso devem
ser a qualidade intrínseca das iniciativas de investimento e a velocidade com que podem ser identificadas, avaliadas, projetadas,
desenvolvidas e implantadas. Há sempre um período de desconhecimento antes que um investimento potencial, que se relacione
com a oportunidade ou a demanda, seja identificado. Quanto mais cedo forem identificados os desenvolvimentos tecnológicos e
avaliado o seu potencial de negócio, mais cedo poderá ser tomada uma decisão de investimento.
As técnicas que podem ser usadas para alcançar investimentos valiosos incluem:
• técnicas de priorização
• produtos e serviços mínimos viáveis
• propriedade do produto ou serviço
• Teste A/B.
A história da ITIL: Técnicas para investimentos valiosos

Marco: Nossa estratégia de negócios é viabilizada por um criterioso investimento em tecnologia. Por
utilizarmos técnicas de trabalho ágeis, podemos garantir a garantia de nossa tecnologia: nosso código sempre
funcionará. Monitoramos nossos investimentos para garantir que gastemos com sabedoria e que a
funcionalidade do nosso aplicativo atenda aos requisitos de nossos clientes.
4.1.1 Técnicas de priorização

As filas ocorrem sempre que a demanda por trabalho excede a capacidade de concluí-lo dentro do prazo esperado.
Em uma situação ideal, uma organização não teria variação na demanda e teria a qualidade e a quantidade adequadas de recursos
necessários para satisfazê-la. No entanto, as organizações geralmente precisam lidar com uma capacidade fixa, mas uma demanda
variável por serviços. Esse desequilíbrio cria filas ou backlogs nos quais os itens de trabalho precisam ser priorizados.
79
A priorização é uma atividade comumente associada ao trabalho de suporte e desenvolvimento de software (por exemplo, priorizar
a investigação de incidentes ou um sprint backlog), mas seu uso é universal.
4.1.1.1 Custo do atraso

Uma técnica útil para priorização é estimar o custo do atraso de uma oferta de serviço nova ou aprimorada. Refere-se aos benefícios
financeiros e não financeiros que seriam perdidos se uma atividade ou tarefa de serviço fosse atrasada. Uma compreensão do custo
do atraso dá aos profissionais a capacidade de priorizar o trabalho com base em dados de valor, em vez de sua intuição. Isso se aplica
à priorização inicial e à avaliação e redefinição de prioridades contínuas do trabalho em andamento dentro das circunstâncias em
mudança. Quase sempre, a criticidade comercial dos produtos e serviços digitais justifica o esforço envolvido na estimativa do custo do
atraso.
O custo do atraso pode ser aplicado à tomada de decisões em vários níveis, como em grandes investimentos em um nível de produto
ou serviço em um portfólio de produtos ou serviços, investimentos menores em um nível de recurso em produtos ou serviços ou
tarefas operacionais.
Essa técnica é particularmente útil em ambientes HVIT porque os investimentos geralmente são mais significativos e as condições de
mercado mudam rapidamente, o que significa que é importante avaliar continuamente as opções de investimentos alternativos.
4.1.1.2 Comprar/manter/vender
Um portfólio de produtos (ou outros ativos) pode ser gerenciado usando a técnica de compra/retenção/venda. Isso envolve
avaliar cada produto e decidir qual das três estratégias de investimento melhor se aplica a ele:
• Comprar Investir na melhoria ou ampliação do produto.
• Reter o gasto o mínimo possível para manter o produto, desde que os custos sejam acessíveis.
• Vender Investir na retirada, redução ou substituição do produto.
Essa técnica esclarece a diferença entre os custos e os benefícios de desenvolver, manter ou descontinuar um produto, juntamente com
os riscos e compensações associados. Ajuda os tomadores de decisão a serem explícitos sobre suas escolhas e a aceitar as
consequências de suas decisões.
4.1.1.3 Outras técnicas

Existem muitas outras técnicas de priorização de produtos que os proprietários de produtos/serviços podem considerar, incluindo
classificação empilhada, Kano, valor presente líquido (VPL), retorno sobre o investimento (ROI) e adequação/viabilidade/atratividade.
A Figura 4.1 mostra a contribuição da priorização para a cadeia de valor do serviço.
A Tabela 4.1 descreve as práticas para as quais a priorização é relevante.
80
0 1 2 3
Baixo Alto
Plano
Projeto
e transição

Se empenhar
Obter/construir Entregar e serviços
e suporte
Melhorar
Figura 4.1 Mapa de calor da contribuição da priorização para a cadeia de valor do serviço
Tabela 4.1 Práticas para as quais a priorização é relevante
Prática de gerenciamento ITIL Atividades/recursos associados à priorização Impacto
Gerenciamento de portfólio Priorizando continuamente as ofertas de serviços com base no valor, incorporando o custo do atraso. H
Gerenciamento de problemas Calcular o custo financeiro de problemas e erros abertos para priorizar e direcionar os esforços de gerenciamento de H
problemas.
Comparar os custos das soluções alternativas com os das soluções de longo prazo.
Gerenciamento de Projetos Calcular o impacto financeiro da execução ou atraso do trabalho do projeto. H
Desenvolvimento e gerenciamento Calcular o impacto financeiro de atrasar o trabalho em novos recursos de software ou componentes de serviço H
de software maiores baseados em software.
Decidir se obter ou construir componentes de software.
Alterar ativação Calcular o custo e o benefício de priorizar e programar mudanças em serviços ou componentes de serviço. M
Gerenciamento de incidentes Calcular o custo de incidentes e incidentes graves para priorizar o trabalho de maior impacto econômico. M
Gerenciamento de lançamento Calcular o custo e o benefício de priorizar e agendar lançamentos de serviços novos ou alterados. M
Gerenciamento financeiro de serviço Calcular dados de perfil de valor de tempo para fornecer informações para priorizar ofertas de serviço. M
Gerenciamento de solicitações de serviço Calcular e comparar o impacto financeiro de cumprir ou atrasar o cumprimento de eu
solicitações a fim de priorizar o trabalho com o maior benefício.
81
A história da ITIL: técnicas de priorização

Su: Depois que as atualizações do aplicativo foram implantadas, nossas prioridades se dividiram. Queríamos desenvolver
novos recursos do nosso sprint backlog, mas havia solicitações de suporte que precisávamos gerenciar para garantir que
nossos clientes ficassem satisfeitos com nosso serviço.
Radhika: Assim como estávamos envolvidos em um impulso de marketing, percebemos que os erros conhecidos em nosso
aplicativo estavam gerando má publicidade. Portanto, o custo de atrasar as correções tornou-se maior do que o valor de adicionar
novos recursos.
Su: Usamos a técnica buy/ hold/ sell para planejar investimentos em nosso conjunto de produtos:
• Comprar Investimos no app, melhorando a experiência e ampliando suas funcionalidades.
• Reter A opção de reservar em nosso site teve que ser mantida porque os clientes ainda
usando isso. No entanto, optamos por minimizar o investimento na mesma.
• Vender Um pequeno número de clientes empresariais ainda desejava reservar por fax. Retiramos essa funcionalidade,
trabalhando com os clientes para fazer a transição deles para modos de comunicação mais modernos.
Trabalhamos arduamente para garantir um retorno satisfatório do investimento.
4.1.2 Produtos e serviços mínimos viáveis

Um produto ou serviço mínimo viável é aquele que possui recursos suficientes para permitir sua avaliação inicial e a coleta de feedback para
desenvolvimento futuro. A abordagem do 'mínimo viável' é uma forma eficiente de desenvolver produtos e serviços, principalmente quando o mercado
é volátil e imprevisível. É consistente com o pensamento de complexidade, que reconhece que algumas coisas são incognoscíveis e, portanto, é
impossível projetar um produto ou serviço com requisitos completos e predeterminados. Quando os requisitos são desconhecidos, não articulados ou
ambíguos, os experimentos podem estabelecer o que funciona e o que não funciona. Portanto, uma abordagem mínima viável permite investimentos
valiosos e contribui para o desenvolvimento rápido por meio de um estilo de trabalho iterativo.
Em mercados voláteis, pode ser difícil julgar quais ofertas de produtos ou serviços serão bem-sucedidas. Essa incerteza pode ser abordada
por meio de uma abordagem mínima viável. Em vez de investir recursos e tempo consideráveis no desenvolvimento de um produto ou serviço em
grande escala, o fornecedor do produto ou serviço deve limitar seus esforços.
Eles devem apontar para um produto ou serviço que seja desenvolvido o suficiente para estimular o feedback e outros dados, e podem então indicar
se e como o desenvolvimento deve continuar. Assim que dados suficientes são coletados, uma decisão pode ser tomada, o que aumenta as chances
de sucesso. Além disso, se for tomada a decisão de interromper o desenvolvimento, o fornecedor do produto ou serviço pode alocar seus recursos
para outro investimento, minimizando o desperdício da ideia original.
Um produto ou serviço mínimo viável normalmente tem três características principais:
• Tem valor suficiente para que as pessoas estejam dispostas a usá-lo ou comprá-lo.
• Demonstra o potencial de benefício suficiente para reter os primeiros adeptos.
• Fornece um ciclo de feedback para orientar o desenvolvimento futuro.
A Figura 4.2 mostra um mapa de calor da contribuição de uma abordagem mínima viável para a cadeia de valor do serviço.
A Tabela 4.2 descreve as práticas para as quais uma abordagem mínima viável é relevante.
82
0 1 2 3
Baixo Alto
Plano
Projeto
e transição

Se empenhar
e suporte
Melhorar
Figura 4.2 Mapa de calor da contribuição de uma abordagem mínima viável para a cadeia de valor do serviço
Tabela 4.2 Práticas para as quais uma abordagem mínima viável é relevante
Prática de gerenciamento ITIL Atividades/recursos associados a uma abordagem mínima viável Impacto
Gerenciamento de arquitetura Usar uma abordagem mínima viável para descrever a arquitetura de serviço, técnica, informação ou ambiente que H
criará as restrições, limites ou facilitadores necessários para outros tipos de serviço ou trabalho de produto.
Análise de negócio Usando uma abordagem mínima viável como uma ferramenta para extrair o valor do negócio principal de um produto ou H
serviço.
Gerenciamento de capacidade e Usar o gerenciamento de capacidade e desempenho como base para calcular os recursos mínimos (número de H
desempenho servidores, número de agentes de central de atendimento, etc.) necessários para um produto ou serviço mínimo viável.
Monitoramento e Usando monitoramento e gerenciamento de eventos como base para projetar e configurar ferramentas de monitoramento e H
gerenciamento de eventos telemetria, que são usadas para operar e aprender com o produto ou serviço mínimo viável.
Gerenciamento de portfólio Utilizar o conceito de produto mínimo viável como ferramenta dinâmica de tomada de decisão para apoiar bons investimentos no H
portfólio de funcionalidades dentro de um produto ou serviço.
Gerenciamento de Projetos Articular a saída mínima necessária para satisfazer o caso de negócios. H
Projeto de serviço Usar uma abordagem mínima viável para projetar os elementos necessários da experiência do cliente e da experiência do H
usuário de um produto ou serviço.
Validação e teste do serviço Desenvolvimento de casos de teste para verificar se todos os componentes do serviço suportam o mínimo viável H
produto ou serviço.
Desenvolvimento e gerenciamento Usando uma abordagem mínima viável como ferramenta de tomada de decisão para priorizar o trabalho em H
de software recursos de software.
Gerenciamento de infraestrutura e Usando uma abordagem mínima viável como ferramenta de tomada de decisão para projetar, implementar e priorizar o M
plataforma trabalho contínuo em componentes de infraestrutura.
Gerenciamento do Usar uma abordagem mínima viável como base para descrever todos os produtos, serviços e ofertas de serviços e garantir que M
catálogo de serviços essas informações estejam disponíveis para públicos relevantes.
Gerenciamento de Projetar e construir planos de continuidade para dar suporte a um produto ou serviço mínimo viável. M
continuidade de serviço
Gestão de fornecedores Usar uma abordagem mínima viável para articular os resultados necessários quando parceiros e fornecedores fornecem M
produtos e serviços.
83
A história da ITIL: Produtos e serviços mínimos viáveis

Su: À medida que desenvolvemos novas funcionalidades de aplicativos, nós o lançamos como um produto mínimo viável para que
possamos avaliar o interesse do cliente. Isso ajuda a garantir que não investimos mais recursos do que o necessário no
desenvolvimento e nos permite entender a demanda do mercado. O feedback sobre o produto mínimo viável determina a
priorização futura.
Solmaz: Reconhecemos que não sabemos o que os futuros clientes gostariam. Trabalhando iterativamente, podemos testar o
produto em todas as etapas e, se cometermos um erro, retornar às versões anteriores bem-sucedidas sem sacrificar um
investimento significativo.
4.1.3 Propriedade do produto ou serviço
O Scrum sugere três papéis: o proprietário do produto, a equipe de desenvolvimento e o Scrum master. O proprietário do produto é responsável por
maximizar o valor do produto que a equipe de desenvolvimento produz. A propriedade do produto envolve estabelecer e priorizar requisitos e comunicá-
los à equipe de desenvolvimento. No contexto dessas equipes de desenvolvimento de software, é o proprietário do produto que faz a ligação e negocia
com os diversos stakeholders, incluindo os consumidores. Os ambientes HVIT geralmente são orientados ao produto, portanto, o conceito do proprietário
do produto é altamente relevante para o HVIT. O conceito de proprietário do produto também se aplica a serviços e proprietários de serviços.
A função de proprietário do produto depende de:
• Habilidades e experiência Os proprietários de produtos precisam ser qualificados em gerenciamento de partes interessadas, análise de requisitos,
pesquisa de mercado, segmentação de clientes e muito mais. Os proprietários de produtos com experiência em análise de negócios ou gerenciamento
de produtos geralmente têm essas habilidades e podem precisar apenas de um curso curto para se familiarizar com as formas ágeis de trabalhar.
No entanto, a equipe técnica que se torna proprietária do produto pode precisar de mais treinamento.
• Autoridade No mínimo, um proprietário do produto deve ser capaz de identificar e comunicar prioridades de curto prazo sem debates e discussões
prolongados ou desnecessários. As organizações devem confiar nos proprietários de produtos para usar sua autoridade.
• Legitimidade O proprietário do produto também precisa ter legitimidade. O contato direto com o cliente e a experiência em primeira mão
reforçarão essa legitimidade e fornecerão a eles o conhecimento de que precisam para priorizar de forma eficaz.
• Tempo Os proprietários de produtos precisam de tempo para cumprir sua função, inclusive para pensar sobre suas histórias, filtrar e editar o
backlog, visitar as partes interessadas, analisar feedback, trabalhar com a equipe, avaliar a realização de benefícios pós-entrega e refletir sobre
o progresso e o atual estado de seus projetos.
A propriedade do produto ou serviço é uma parte fundamental de todas as atividades da cadeia de valor e contribui para investimentos valiosos.
A Figura 4.3 mostra a contribuição da propriedade do produto ou serviço para a cadeia de valor do serviço.
A Tabela 4.3 descreve as práticas para as quais a propriedade do produto ou serviço é relevante.
84
0 1 2 3
Baixo Alto
Plano
Projeto
e transição

Se empenhar
e suporte
Melhorar
Figura 4.3 Mapa de calor da contribuição da propriedade do produto ou serviço para a cadeia de valor do serviço
Tabela 4.3 Práticas para as quais a propriedade do produto ou serviço é relevante
Prática de gerenciamento ITIL Atividades/recursos associados à propriedade do produto ou serviço Impacto
Gerenciamento de infraestrutura e Envolvimento dos proprietários de produtos e serviços na articulação, refinamento e priorização da(s) lista(s) de H
plataforma pendência(s) de desenvolvimento de infraestrutura e plataforma e na decisão de adquirir componentes e serviços de

infraestrutura disponíveis comercialmente.
Gerenciamento de portfólio Envolvimento de proprietários de produtos (software) e gerentes de produtos ou serviços na avaliação e priorização H
das propostas de investimento em produtos ou serviços.
Gestão de relacionamento Estruturação de interações com stakeholders. H
Envolvimento no estabelecimento das prioridades dos clientes para produtos e serviços novos ou alterados.
Coordenação de requisitos e feedback dos clientes.
Envolvimento no tratamento de reclamações e mediação de requisitos conflitantes.
Gerenciamento do Envolvimento de proprietários e gerentes de produtos ou serviços na publicação de informações sobre todos os H
catálogo de serviços produtos, serviços e ofertas de serviços.
Desenvolvimento e gerenciamento Envolvimento dos proprietários de produtos e serviços na articulação, refinamento e priorização do backlog de H
de software desenvolvimento de software e na decisão de adquirir ou atualizar software disponível comercialmente.
Gerenciamento de Projetos Envolvimento de proprietários e gerentes de produtos e serviços na entrega do trabalho do projeto e no gerenciamento M
de riscos.
Gerenciamento de riscos Envolvimento dos proprietários de produtos e serviços na articulação e mitigação dos riscos corporativos. M
Gestão de fornecedores Envolvimento de proprietários e gestores de produtos e serviços na articulação de necessidades, estruturação de M
interações e negociação com parceiros e fornecedores.
85
A história da ITIL: Propriedade do produto ou serviço

Su: Eu sou o proprietário do produto dedicado para o aplicativo de reservas. Faço contato e
negocio com as equipes de desenvolvimento, marketing, gestão de frotas, reservas e outros.
Priorizo os requisitos e comunico regularmente as prioridades às partes interessadas.
Tenho formação técnica com experiência em desenvolvimento ágil e treinamento em análise de

negócios, incluindo tempo de trabalho com clientes. Entendo o nível de alterações que posso autorizar
e quando preciso escalar um problema. A Axle garante que tenho tempo para cumprir minha função e
que entendo o que é exigido de mim e como o produto se concentra no valor.
4.1.4 Teste A/B

Pode ser difícil prever se um recurso será valioso para os usuários. Esse problema pode ser resolvido medindo o
comportamento do usuário para coletar dados sólidos; no entanto, quando há muitos fatores de influência, é quase
impossível isolar o efeito do novo recurso. Portanto, um grupo de controle é necessário.
O teste A/B é um experimento de tempo limitado no qual um grupo de usuários, o grupo de controle, recebe uma versão
antiga de um produto ou serviço. Ao mesmo tempo, outro grupo de usuários, o grupo de tratamento, recebe uma nova
versão do produto ou serviço que inclui o novo recurso. Supondo que todos os outros fatores que influenciam ambos os
grupos sejam iguais, as medidas dos grupos podem ser comparadas, reunindo assim dados para uma decisão baseada
em valor. Este método é ilustrado na Figura 4.4.
O teste A/B contribui para a prática de gerenciamento de portfólio. A essência do gerenciamento de portfólio é fazer os
investimentos certos dentro das restrições de financiamento e recursos. O gerenciamento de portfólio é aplicável em
vários níveis, incluindo o 'portfólio' de recursos dentro de um produto ou serviço. O teste A/B ajuda a determinar qual
versão de um recurso é mais valiosa. Como tal, contribui para investimentos valiosos.
Experimente em
o mesmo tempo
Tratamento
grupo
Nova versão
Decisão
Versão antiga sem alteração
Grupo de controle
Tempo
Figura 4.4 Experimentação por tempo limitado com teste A/B
86
Exemplo
O departamento de marketing de uma organização deseja alterar a descrição de um produto no site da organização
adicionando vídeos curtos do produto. O departamento tem certeza de que esse novo recurso aumentará
significativamente a taxa de conversão, que atualmente é de 2,5% (ou seja, 2,5% dos visitantes adicionam esse produto
ao carrinho de compras). Se o recurso fosse implementado sem teste A/B e a taxa de conversão aumentasse, seria
impossível dizer se o aumento foi devido a essa alteração específica. Muitos fatores podem influenciar essa métrica ao
mesmo tempo, como uma nova campanha publicitária para o produto.
O departamento de marketing decide realizar um teste A/B. Um grupo de usuários de tratamento vê uma página
de produto com vídeos e um grupo de controle de usuários vê a versão anterior da página de produto sem vídeos. Ao
comparar a taxa de conversão do grupo de tratamento com a do grupo de controle, é mais fácil julgar o efeito da
mudança.
Como os ambientes HVIT geralmente são orientados ao produto e operam sob pressão de tempo em mercados
imprevisíveis, o teste A/B é particularmente relevante para o HVIT.
A Figura 4.5 mostra a contribuição dos testes A/B para a cadeia de valor do serviço.
A Tabela 4.4 descreve as práticas para as quais o teste A/B é relevante.
0 1 2 3
Baixo Alto
Plano
Projeto
e transição

Se empenhar
e suporte
Melhorar
Figura 4.5 Mapa de calor da contribuição do teste A/B para a cadeia de valor do serviço
87
Tabela 4.4 Práticas para as quais o teste A/B é relevante
Prática de gerenciamento ITIL Atividades/recursos associados ao teste A/B Decidir e Impacto
Gerenciamento de portfólio priorizar quais serviços, produtos e recursos investir no uso de dados de teste A/B. H
Gerenciamento de riscos Usando métodos de teste A/B para determinar a eficácia das opções de mitigação de risco antes de fazer novos H
investimentos.
Projeto de serviço Usando métodos de teste A/B para determinar a eficácia da experiência do cliente e protótipos de experiência do H
usuário antes de fazer mais investimentos e decisões de design.
Gerenciamento de arquitetura Projetar e refinar a arquitetura técnica, de informações, de produtos e serviços usando métodos de teste A/B. M
Melhoria contínua Usar métodos de teste A/B para determinar a eficácia de várias opções e iniciativas de melhoria antes de fazer M
novos investimentos.
Gestão do conhecimento Usar métodos de teste A/B para determinar a eficácia de diferentes técnicas e ferramentas de gerenciamento de M
conhecimento, apresentação e comunicação antes de fazer novos investimentos.
Gestão de mudanças Usar métodos de teste A/B para determinar a eficácia das mudanças organizacionais antes de fazer novos M
organizacionais investimentos.
Gerenciamento de problemas Usando métodos de teste A/B para determinar a eficácia de soluções alternativas e abordagens de controle de M
erros antes de fazer mais investimentos.
Validação e teste de serviço Definir e executar atividades de serviço, validação e teste de produto usando A/B M
métodos de teste.
A história da ITIL: testes A/B

Su: Desenvolvemos uma nova funcionalidade para o aplicativo: a cada quatro reservas feitas pelo aplicativo,
oferecemos aos clientes um upgrade gratuito para um carro melhor.
Marco: Para avaliar o valor dessa nova funcionalidade para nossos clientes, realizamos um teste A/ B: 50% de
nossos clientes tinham a opção de upgrade e 50% não. Os resultados foram conclusivos: 70% dos clientes
atualizaram seus veículos quando tiveram a oportunidade. Daqueles que atualizaram uma vez gratuitamente, 20%
optaram por alugar o veículo de especificação mais alta em sua próxima reserva.
Su: Com base nesses resultados, podemos estar confiantes no lançamento dessa nova funcionalidade.
4.2 Técnicas para desenvolvimento rápido

O objetivo de desenvolvimento rápido envolve a realização de produtos e serviços digitais novos e aprimorados com frequência,
rapidez e confiabilidade. 'Desenvolvimento' refere-se ao desenvolvimento de produtos em geral, embora o desenvolvimento de aplicativos
seja frequentemente incluído nisso.
Em geral, quanto mais cedo os produtos digitais forem entregues, mais cedo o valor poderá ser percebido. Às vezes, porém, este não é o
caso, e o cronograma deve ser alterado de acordo; por exemplo, uma entrega antecipada pode não estar alinhada com a demanda do
mercado. Separar um único produto em uma série de entregas incrementais permite uma entrega geral mais rápida e permite que os
usuários percebam o valor mais cedo do que se esperassem pelo produto inteiro.
Além de rápida e frequente, a entrega deve ser confiável. No entanto, às vezes é melhor entregar um produto ou serviço rapidamente,
ou restaurar o serviço rapidamente, quando há capacidade, do que esperar para entregar um
88
produto ou serviço marginalmente mais confiável. O tempo médio para recuperar o serviço (MTRS) geralmente é uma métrica melhor
do que o tempo médio entre falhas (MTBF) nessas instâncias.
O desenvolvimento rápido não tem valor intrínseco; seu valor está relacionado ao valor do que está sendo desenvolvido. Em
organizações comerciais, permite um retorno mais rápido do investimento, melhorando o tempo de colocação no mercado e o tempo de
chegada ao cliente. Isso geralmente é expresso em termos de mais receita de vendas, pois o fluxo de receita começa mais cedo.
Também pode ser expresso no volume de tráfego do site ou no número de clientes em potencial que se inscrevem em correspondências,
entre outras coisas.
O desenvolvimento rápido pode ser medido em termos do tamanho do aplicativo (mudança) por unidade de tempo. O tamanho do
aplicativo pode ser expresso em unidades técnicas, como linhas de código, ou unidades funcionais, como pontos de história ou pontos
de função. A comparação de produtividade deve ser feita com cautela, pois depende de muitos fatores: por exemplo, os requisitos não
funcionais não são refletidos nos pontos de história. Comparar a produtividade faz mais sentido quando os critérios são especificados
para uma determinada combinação de aplicativos e equipes.
As organizações geralmente se concentram no desenvolvimento rápido do aplicativo porque é isso que fornece a
funcionalidade e o valor. No entanto, é igualmente importante que os componentes relacionados também sejam desenvolvidos ou
entregues rapidamente. Isso inclui solicitações de serviço, como fornecimento de equipamentos, fornecimento de direitos de acesso,
configuração de novas caixas de correio ou relatórios de business intelligence (BI).
Também pode ser útil rastrear a previsibilidade dos tempos de desenvolvimento esperados; por exemplo, registrando quando os
desvios do planejamento são relatados. Os gerentes devem incentivar as pessoas a relatar possíveis atrasos o mais rápido possível;
este é o comportamento desejado.
Sob pressão de negócios para obter valor rapidamente, as equipes de desenvolvimento Agile fornecem incrementos de
software potencialmente implantáveis com a maior frequência possível. Infelizmente, esses lançamentos geralmente precisam esperar
dias, semanas ou, às vezes, meses para a implantação real, que geralmente é o atraso mais longo no fluxo de valor. Isso geralmente
ocorre devido a uma abordagem cautelosa generalizada para aprovação e implantação. Normalmente, parte do processo de aprovação
é uma avaliação por um conselho consultivo de mudanças que se reúne apenas em dias programados. A implantação real também
costuma acontecer de acordo com um cronograma. Portanto, existe um conflito potencial entre desenvolvimento rápido e operações
resilientes.
O pensamento por trás dessa abordagem é que a mudança é potencialmente disruptiva e, portanto, deve ser cuidadosamente
controlada. Como as mudanças rápidas e cuidadosas são alvos diametralmente opostos, as equipes de desenvolvimento e as
operações de TI geralmente não colaboram de forma eficaz, e os profissionais de TI e gerenciamento de serviços precisam preencher
a lacuna.
Essa tensão é baseada em um modelo mental familiar no qual a mudança interrompe a estabilidade e os controles de
estabilidade mudam: quanto menos mudanças, menor o risco para a estabilidade. Mais recentemente, surgiu uma forma diferente
de pensar. Uma redução no tamanho da mudança reduz o risco de interrupção. Mudanças menores também significam que a
mudança pode acontecer com mais frequência. Ao mudar com mais frequência, a capacidade de mudança da organização é
melhorada. O aumento da capacidade de mudança leva, por sua vez, a um menor risco de interrupção. A Figura 4.6 demonstra o efeito
do tamanho da mudança.
A comunidade DevOps adotou essa forma de pensar e desenvolveu práticas apropriadas e tecnologia de suporte. A pesquisa
descobriu que o alto desempenho em termos de frequência de implantação, tempo de espera para mudança e taxa de falha de
mudança está correlacionado com controle de versão, entrega contínua e testes automatizados. A pesquisa também sugere que a
aprovação de mudanças com base na revisão por pares dentro da equipe não é menos arriscada do que usar um conselho consultivo de
mudanças.
89
Mudanças menores levam a

uma frequência mais alta
O
Mudanças maiores levam a
uma qualidade mais baixa
Frequência de Tamanho
mudança
R da mudança
O
Um backlog maior leva a
mudanças maiores
O
S
Frequência mais alta leva a
Qualidade da
mudanças menores R
mudança
Tamanho da
O
lista de pendências
Frequência mais alta leva a um

backlog menor O
A qualidade mais baixa leva a
R = Reforço
mais itens de backlog para
S = Igual
O = Oposto consertar as coisas
Figura 4.6 Efeito do tamanho da mudança

Reproduzido com a gentil permissão de Oleg Skrynnik
As técnicas que podem ser usadas para alcançar o desenvolvimento rápido incluem:
• infraestrutura como código
• arquitetura de sistema de informação fracamente acoplada
• comentários
• análise de negócios contínua
• integração contínua/entrega contínua
• teste contínuo
• Kanban.
A história da ITIL: Técnicas para desenvolvimento rápido

Solmaz: Desenvolvemos novas funcionalidades de aplicativos em incrementos, lançando melhorias e alterações com
regularidade e frequência. Isso nos ajuda a perceber o valor mais cedo e receber feedback mais cedo. Também nos permite
priorizar o desenvolvimento de novos recursos e o trabalho de suporte. Como as mudanças são pequenas, elas exigem
menos suporte e o risco de interrupção do serviço é menor.
4.2.1 Infraestrutura como código
A infraestrutura como código (IaC) permite o provisionamento mais rápido de ambientes, contribuindo para um desenvolvimento mais rápido e
operações mais resilientes. A tecnologia de virtualização e hipervisor (geralmente fornecida pela nuvem) permite que itens de infraestrutura
sejam criados, modificados e removidos remotamente por meio de interfaces de programação. Hoje, é prática comum construir e configurar
servidores usando scripts e arquivos de configuração.
90
O IaC é uma maneira de gerenciar e provisionar infraestrutura e plataformas de TI usando arquivos de definição legíveis por máquina
em vez de configurar fisicamente os componentes de hardware. Esses arquivos podem ser armazenados em um sistema de controle
de versão (consulte controle de versão na seção 4.3.4).
O conceito de idempotência é fundamental para IaC. Isso significa que um comando de implantação sempre configura o
ambiente de destino no estado especificado, independentemente do que era anteriormente. Isso pode ser feito reconfigurando
o ambiente de destino ou substituindo-o por um novo. Para isso, são feitas alterações na descrição do ambiente e é criada uma nova
versão do modelo de configuração. O código é validado e testado para evitar problemas comuns de implantação. O pipeline de
lançamento executa o modelo de configuração, resultando em ambientes de destino recém (re)configurados. Se forem necessárias
alterações, a origem será editada, não o destino. Ferramentas como Vagrant, Ansible, Puppet e Docker suportam todo o processo.
Soluções baseadas em nuvem, como infraestrutura como serviço (IaaS) e plataforma como serviço (PaaS), usam definições de IaC
para provisionar e remover ambientes dinamicamente. As equipes podem provisionar vários ambientes de teste de maneira confiável e
sob demanda. Isso permite que eles testem aplicativos em ambientes semelhantes à produção no início do ciclo de desenvolvimento.
A escolha de usar IaC em vez de uma configuração física tradicional é uma decisão de projeto arquitetônico com consequências
de longo alcance. A essência da arquitetura é escolher quais blocos de construção, ou recursos, usar e como usá-los. A digitalização
da infraestrutura e das plataformas permite o provisionamento mais rápido e confiável de todos os ambientes necessários, como
desenvolvimento, teste e produção, contribuindo para desenvolvimento e implantação rápidos. É igualmente relevante para alcançar
operações resilientes, pois permite a recuperação mais rápida de alguns incidentes e evita outros, reduzindo erros humanos, como
configuração manual incorreta e desvio de configuração. O IaC também é mais eficiente porque possui menos operações manuais
repetíveis, contribuindo assim para investimentos valiosos ao reduzir os custos de infraestrutura.
A Figura 4.7 mostra a contribuição da IaC para a cadeia de valor do serviço.
0 1 2 3
Baixo Alto
Plano
Projeto
e transição

Se empenhar
e suporte
Melhorar
Figura 4.7 Mapa de calor da contribuição da infraestrutura como código para a cadeia de valor do serviço
91
Tabela 4.5 Práticas para as quais a infraestrutura como código é relevante
Prática de gerenciamento ITIL Atividades/recursos associados à infraestrutura como código Impacto
Gerenciamento de arquitetura Verificando decisões de arquitetura e comparando soluções de infraestrutura. H
Alterar ativação Habilitando o rápido provisionamento ou descomissionamento de componentes de infraestrutura virtual para equilibrar a H
velocidade de entrega com as necessidades de governança, risco e conformidade.
Gerenciamento de implantação Automatizando a implantação de infraestrutura, garantindo uma implantação mais rápida, repetível e confiável de H
infraestrutura e aplicativos.
Gerenciamento de Projetar e aplicar políticas de segurança em componentes de infraestrutura virtual. H
segurança da informação
Gerenciamento de ativos de TI Rastreamento do uso de licenças de software comercial atribuídas a componentes de infraestrutura virtual que H
geralmente são provisionados ou desativados rapidamente.
Gestão do conhecimento Armazenar arquivos de configuração do servidor virtual e disponibilizá-los para automação de IaC. H
Gerenciamento de Projetar e manter bancos de dados e relacionamentos de gerenciamento de configuração no nível apropriado de H
configuração de serviço granularidade para rastrear componentes de infraestrutura virtual que geralmente são provisionados ou desativados
rapidamente.
Gerenciamento financeiro de serviços Deslocamento de financiamento de despesas de capital para despesas operacionais devido à redução H
investimento em infraestrutura física.
Gerenciamento de solicitações de serviço Automatizando o provisionamento ou descomissionamento de componentes de infraestrutura virtual. H
Validação e teste de serviço Projetar e manter casos de teste para garantir que o IaC virtual atenda aos requisitos e políticas organizacionais. H
Desenvolvimento e gerenciamento Desenvolvendo arquitetura e código de software para alavancar a entrega/provisionamento rápido de infraestrutura de H
de software hardware virtual.
Gerenciamento de incidentes Automatizando (quando apropriado) tarefas de recuperação de incidentes, aproveitando os recursos de IaC. M
Gerenciamento de infraestrutura e Entrega/provisionamento rápido de infraestrutura de hardware virtual. M
plataforma
Gerenciamento de problemas Detecção de problemas e controle de erros aproveitando os recursos de IaC. M
Gerenciamento de Projetar planos de continuidade apropriados para refletir o uso dos recursos de IaC pela organização. M
Gestão de fornecedores Seleção de fornecedores que podem fornecer recursos de IaC ou alavancar os investimentos da organização M
em IaC.
Gerenciamento de riscos Reconhecer os riscos introduzidos ou mitigados pelo uso de IaC. eu
A Tabela 4.5 descreve as práticas para as quais a infraestrutura como código é relevante.
A história da ITIL: Infraestrutura como código
Marco: Em modo de teste, criamos vários ambientes de teste usando tecnologia de hypervisor em uma máquina
virtual. Queríamos emular o uso do aplicativo em várias plataformas. Como validamos o código em todas as etapas do
ciclo de desenvolvimento, sabíamos que o aplicativo continuaria a funcionar em diferentes dispositivos à medida que
crescesse.
4.2.2 Arquitetura de sistema de informação fracamente acoplada
A arquitetura do sistema de informação fracamente acoplada é baseada em componentes relativamente pequenos e independentes.
Essa arquitetura permite que o trabalho seja feito em equipes pequenas, relativamente independentes, baseadas em produtos ou
serviços e em equipes baseadas em plataforma. Ao dividir um sistema em partes que podem ser desenvolvidas e gerenciadas de forma
relativamente independente, as equipes podem se concentrar em sua própria parte e limitar suas interações com outras equipes. O produto- ou
92
equipes baseadas em serviços incluem desenvolvedores e engenheiros, juntamente com proprietários de produtos/serviços, que representam
a perspectiva do consumidor. Essa colaboração mais próxima é benéfica para o desenvolvimento rápido, bem como para a cocriação de valor.
Também contribui para investimentos valiosos, desenvolvimento rápido e operações resilientes (onde as operações de TI também são
representadas na equipe).
Um dos maiores problemas com arquiteturas fortemente acopladas (como em sistemas de informação monolíticos) é a velocidade muito
baixa de mudança, pois muitas mudanças exigem que várias partes do sistema sejam redesenhadas e redesenvolvidas. Adicionar mais
equipes e funcionários para trabalhar no mesmo sistema pode realmente reduzir a velocidade, pois pode resultar em muitas interconexões
profundas entre componentes em um nível de arquitetura.
Uma técnica intimamente relacionada é o estrangulamento de aplicação. Isso pode ser aplicado para criar gradualmente um novo
aplicativo em torno de um antigo, substituindo lentamente o código antigo por um novo código. Isso é útil quando é inviável refatorar um
aplicativo (reestruturando o código sem alterar sua funcionalidade) e ele precisa ser substituído.
Essa técnica pode comprometer o desempenho e a confiabilidade, portanto, é necessário um monitoramento cuidadoso se for usada.
Técnicas como microsserviços e conteinerização são frequentemente associadas à arquitetura fracamente acoplada.
Definições
• Microsserviços Uma variação da arquitetura orientada a serviços na qual um aplicativo é projetado e desenvolvido como um conjunto
de serviços pequenos e fracamente acoplados, cada um executando seu próprio processo e usando mecanismos leves para se
comunicar.
• Contêinerização A técnica de empacotar software em unidades padronizadas leves, autônomas e executáveis para
desenvolvimento, envio e implantação.
Os benefícios da arquitetura de sistema de informação fracamente acoplada incluem:
• Facilita o desenvolvimento mais rápido e mudanças mais frequentes.
• Permite arquitetura evolutiva.
• É mais eficiente e leva a menos trabalho necessário para reprojetar e desenvolver novamente um produto ou serviço.
• Permite uma mudança de uma estrutura de equipe focada em componentes para uma estrutura de equipe baseada em produto ou recurso.
A Figura 4.8 mostra a contribuição da arquitetura de sistema de informação fracamente acoplada para a cadeia de valor do serviço.
A Tabela 4.6 descreve as práticas para as quais a arquitetura de sistema de informação fracamente acoplada é relevante.
A história da ITIL: Arquitetura de sistema de informação fracamente acoplada

Su: Usamos uma arquitetura de sistema de informação fracamente acoplada para o aplicativo. Ao tratar o sistema
como componentes relativamente pequenos e independentes, as equipes que trabalham em cada componente podem
trabalhar de forma independente porque entendem as entradas que o componente receberia e as saídas que seriam
exigidas pelos componentes subsequentes no fluxo de trabalho. Isso reduziu a duplicação, complexidade e
interdependências entre os diferentes componentes do aplicativo.
93
0 1 2 3
Baixo Alto
Plano
Projeto
e transição

Se empenhar
e suporte
Melhorar
Figura 4.8 Mapa de calor da contribuição da arquitetura do sistema de informação fracamente acoplado para a cadeia de valor do serviço
Tabela 4.6 Práticas para as quais a arquitetura de sistema de informação fracamente acoplada é relevante
Prática de gerenciamento ITIL Atividades/recursos associados à arquitetura de sistema de informação fracamente acoplada Projetar arquiteturas Impacto
Gerenciamento de arquitetura de serviço, técnica e de informação fracamente acopladas. H
Análise de negócio Compreender as necessidades do consumidor e traduzi-las em requisitos detalhados para cada componente de uma H
arquitetura de serviço fracamente acoplada.
Gerenciamento de implantação O escopo de implantações e padrões de implantação é reduzido com a dissociação da arquitetura do sistema; isso H
torna as implantações mais fáceis de gerenciar e replicar e são fortes candidatas à automação.
Gerenciamento de Projetar e gerenciar políticas de segurança da informação para serviços e componentes de serviço fracamente H
segurança da informação acoplados.
Gerenciamento de infraestrutura e O projeto detalhado, construção, execução e gerenciamento de componentes de infraestrutura e plataforma fracamente H
plataforma acoplados.
Gerenciamento de problemas Investigando problemas e projetando controles de erro que abrangem vários sistemas fracamente acoplados. H
Gerenciamento de Projetar e manter informações sobre vários serviços e componentes de serviços e suas inter-relações. H
configuração de serviço
Gerenciamento de nível de serviço Projetar e alinhar os níveis de serviço de uma arquitetura fracamente acoplada com as expectativas do consumidor no H
ponto de consumo do serviço.
Desenvolvimento e gerenciamento O projeto detalhado, construção, execução e gerenciamento de componentes de software fracamente acoplados. H
de software
Alterar ativação A arquitetura fracamente acoplada reduz os riscos associados a alterações em aplicativos e infraestrutura, caso essas M
alterações falhem. O perfil de risco mais baixo resulta na aprovação de mudanças no nível da equipe, e não no nível
divisional ou organizacional, reduzindo a burocracia.
Gerenciamento de incidentes Quando os incidentes são isolados, sua investigação e resolução podem ser planejadas e executadas de forma M
menos estressante e mais eficiente. O impacto das interrupções de serviço na arquitetura fracamente acoplada geralmente
é restrito ao item de configuração (CI) inservível e não aos outros CIs. Isso se deve ao princípio de design de que os
componentes do sistema devem ser resilientes e não depender de serviços disponíveis de outros ICs. Como resultado, os
incidentes têm um impacto menor sobre os clientes.
94
Prática de gerenciamento ITIL Atividades/recursos associados à arquitetura de sistema de informação fracamente acoplado Gerenciamento Impacto
financeiro de serviços A arquitetura de sistema fracamente acoplado permite o acoplamento e desacoplamento de serviços de terceiros com mais M
facilidade, permitindo que o provedor de serviços aproveite a redução de preços e novas ofertas. Essa
flexibilidade também exige que o provedor de serviços empregue um modelo de contabilidade de custos
ágil para mudar de provedor com eficiência.
Gestão de fornecedores Estabelecer contratos e gerenciar o desempenho quando alguns componentes de uma arquitetura M
fracamente acoplada são fornecidos por fornecedores ou prestadores de serviços externos.
Gestão de estratégia A dissociação da arquitetura fortemente acoplada é uma decisão de nível estratégico, devido ao investimento eu
necessário e às potenciais implicações do modelo operacional de aproveitá-la (por exemplo, introdução de

equipes autônomas). Um exemplo dessa arquitetura é a arquitetura orientada a serviços que pode incorporar
serviços de terceiros como parte do serviço de ponta a ponta.
4.2.3 Revisões
Progredir de forma iterativa com feedback implica ter revisões regulares das realizações, para identificar as lições a serem
aprendidas e corrigir o curso das ações, se necessário. No entanto, essas revisões não devem retardar o progresso ou
introduzir controles excessivos.
4.2.3.1 Retrospectivas
No Agile, uma retrospectiva é uma reunião de equipe no final de uma iteração (ou 'sprint') ou projeto para discutir o que deu
certo, o que pode ser melhorado e como se beneficiar das descobertas no futuro. Esse feedback rápido e frequente contribui
para o desenvolvimento rápido. As retrospectivas podem ser aplicadas à maioria dos cenários e em qualquer área que precise
de melhoria contínua. Para serem eficazes, eles devem ser agendados regularmente e um facilitador deve suavizar as
contribuições dos participantes. As ações que são insumos para a melhoria contínua devem ser identificadas e as
responsabilidades delegadas. A Figura 4.9 mostra a contribuição das retrospectivas para a cadeia de valor do serviço.
0 1 2 3
Baixo Alto
Plano
Projeto
e transição

Se empenhar
e suporte
Melhorar
Figura 4.9 Mapa de calor da contribuição das retrospectivas para a cadeia de valor do serviço
95
Tabela 4.7 Práticas para as quais as retrospectivas são relevantes
Prática de gerenciamento ITIL Atividades/recursos associados às retrospectivas Atividades e Impacto
Melhoria contínua técnicas para revisar as iniciativas de melhoria contínua periodicamente ou após a conclusão, para entender se os H
resultados pretendidos estão sendo alcançados.
Gerenciamento de Projetos Atividades e técnicas para revisar o trabalho do projeto e aprender lições que podem beneficiar futuros projetos H
semelhantes.
Gerenciamento de nível de serviço Atividades e técnicas para revisar e, se necessário, modificar os níveis de serviço periodicamente para entender como H
melhorar.
Desenvolvimento e gerenciamento Atividades e técnicas para revisar o trabalho periodicamente para entender como melhorar. H
de software
Alterar ativação Atividades e técnicas para revisar a eficácia e eficiência de fazer mudanças periodicamente para entender como M
melhorar (incluindo decisões sobre a criação ou suspensão de modelos de mudança padrão).
Gerenciamento de incidentes Atividades e técnicas para revisar o trabalho de gerenciamento de incidentes periodicamente ou após grandes incidentes M
para entender como melhorar.
Gerenciamento de problemas Atividades e técnicas para revisar controles de problemas e erros periodicamente para entender como melhorar. M
Gestão de relacionamento Atividades e técnicas para revisar regularmente o status e a direção dos relacionamentos existentes M
com diversos interessados.
Gerenciamento de riscos Atividades e técnicas para revisar as mitigações de risco periodicamente, ou após uma mitigação ter sido desencadeada, M
para entender como melhorar.
Gerenciamento de Atividades e técnicas para revisar a eficiência e eficácia dos planos de continuidade após a recuperação de um desastre. M
Balcão de atendimento Atividades e técnicas para revisar as interações do service desk periodicamente para entender como melhorar. M
Gestão de fornecedores Atividades e técnicas para revisar regularmente o status e a direção dos relacionamentos existentes com vários parceiros e M
fornecedores.
A Tabela 4.7 descreve as práticas para as quais as retrospectivas são relevantes.
4.2.3.2 Post-mortems sem culpa

A tecnologia digital tem consequências sociais e econômicas cada vez mais significativas, principalmente em ambientes HVIT.
Por isso, é cada vez mais importante prevenir incidentes. No entanto, sistemas complexos são inerentemente perigosos: apesar
de todos os esforços, eles falharão. Portanto, também é cada vez mais importante aprender com o fracasso.
Um post-mortem é um registro formal de um incidente em termos de seu impacto, esforços de resolução/mitigação, causas e
medidas para prevenir a recorrência. A qualidade de um post-mortem é melhor quando os participantes se sentem capazes de
compartilhar seus conhecimentos e opções sem medo de sua reputação e posição. É por isso que é crucial focar no que, e não em
quem, causou um incidente. Essa cultura sem culpa se originou nos setores de saúde e aviação, onde vidas estão em risco. Post-
mortems sem culpa estão fortemente relacionados à cultura de segurança e segurança psicológica (ver seção 3.2.2.2).
Definição: post-mortem sem culpa
Uma descrição e análise sem julgamento das circunstâncias e eventos que precederam um incidente.
96
Post-mortems não são apenas úteis para as pessoas envolvidas no incidente, mas devem ser compartilhados e lidos por outras pessoas
que possam se beneficiar dos resultados. Também é importante compartilhar as descobertas com a comunidade em geral, incluindo os
consumidores, pois a transparência e a vulnerabilidade estabelecem confiança e ajudam a cocriar valor.
Bons comportamentos relevantes para post-mortems incluem:
• conduzir post-mortems como parte do 'business as usual', não como exceção
• focar no que causou um incidente, não em quem
• compartilhar resultados de forma ampla e transparente para aprender e fomentar a confiança.
A Figura 4.10 mostra a contribuição de post-mortems sem culpa para a cadeia de valor do serviço.
A Tabela 4.8 descreve as práticas para as quais post-mortems sem culpa são relevantes.
0 1 2 3
Baixo Alto
Plano
Projeto
e transição

Se empenhar
e suporte
Melhorar
Figura 4.10 Mapa de calor da contribuição de post-mortems sem culpa para a cadeia de valor do serviço
A história da ITIL: comentários
Marco: Trabalhar no aplicativo pode ser exigente, mas nos beneficiamos das retrospectivas. Analisamos
regularmente o trabalho finalizado para entender quais lições podem ser aprendidas para uso no próximo sprint.
Estes são post-mortems irrepreensíveis: discutimos nosso trabalho aberta e honestamente, sem medo de que a
causa de um incidente seja atribuída a qualquer membro da equipe.
97
Tabela 4.8 Práticas para as quais post-mortems sem culpa são relevantes
Prática de gerenciamento ITIL Atividades/recursos associados a post-mortems sem culpa Investigação de Impacto
Alterar ativação mudanças bem-sucedidas e fracassadas para identificar oportunidades para melhorar o sucesso de mudanças futuras. H
Gerenciamento de implantação Investigar implantações bem-sucedidas e malsucedidas de componentes de serviço para identificar H
oportunidades para melhorar o sucesso de implantações futuras.
Gerenciamento de incidentes Investigar as atividades de gerenciamento de incidentes (e gerenciamento de incidentes graves) para identificar H
oportunidades de melhoria.
Gerenciamento de problemas Ajustar a abordagem de liderança para examinar o sistema e não as pessoas. H
Post-mortems sem culpa ajudam as organizações a obter mais informações sobre as circunstâncias
relacionadas aos incidentes. Isso fornece melhores informações para identificação e investigação de
problemas.
Gerenciamento de Projetos Investigar as atividades do projeto para identificar lições aprendidas e oportunidades para melhorar projetos futuros. H
Gerenciamento de lançamento Investigar releases de serviços bem-sucedidos e com falha para identificar oportunidades para melhorar o sucesso de H
releases futuros.
Melhoria contínua Investigar atividades de melhoria contínua para identificar as lições aprendidas, entender as mudanças no sistema M
e identificar oportunidades para aumentar ou manter o sucesso de melhorias futuras.
Gerenciamento de Obter mais informações sobre as circunstâncias relacionadas a violações de segurança e incidentes de segurança. M
segurança da informação
Gerenciamento de riscos Avaliar as mitigações de risco depois de acionadas para entender como melhorar as mitigações e as respostas aos M
riscos atuais e futuros.
Alterando registros de risco e explorando novas áreas de possíveis riscos.
Balcão de atendimento Investigar o envolvimento com partes interessadas externas para identificar oportunidades para melhorar as interações M
e comunicações contínuas.
Validação e teste de serviço Investigar atividades de validação e teste bem-sucedidas e fracassadas para identificar oportunidades para melhorar o M
sucesso de esforços futuros.
Desenvolvimento e gerenciamento Capturar lições aprendidas e ideias para melhorias de sprints. M
de software
Envolver parceiros e fornecedores para coletar feedback para o registro de aprendizados.
4.2.4 Análise de negócios contínua

Ambientes HVIT imprevisíveis e em rápida mudança exigem ajustes contínuos em resposta à demanda flutuante do
mercado. Isso tem implicações para a análise de negócios.
Quando uma decisão de investimento é tomada, é crucial verificar quaisquer suposições iniciais feitas sobre
especificações, características e recursos do produto ou serviço. Alguns provedores ignoram a necessidade de interagir com
usuários reais o mais rápido possível e passam vários meses ou até anos no desenvolvimento antes de apresentar sua
solução aos clientes e usuários. Muitas vezes, quando essa abordagem é adotada, alguns recursos do produto ou serviço
são desnecessários, alguns precisam de reajustes significativos e outros que seriam altamente valiosos estão ausentes. No
entanto, os recursos e o tempo da organização já foram gastos e as oportunidades de marketing estão diminuindo.
Uma maneira melhor de desenvolver é implementar ciclos de feedback o mais cedo possível. Ciclos de feedback adequados
podem fornecer informações valiosas sobre a direção na qual o produto ou serviço deve ser desenvolvido. Para que um ciclo
de feedback seja útil, é importante desenvolver iterativamente. Uma abordagem mínima viável (ver seção 4.1.2) poderia ser
usada para este propósito. A Figura 4.11 ilustra esse conceito.
98
Cascata
Tempo
Versão 1.0 Versão 2.0
Comentários
Valor Valor
Incremental
Tempo
Incremento de MVP Incremento Incremento Incremento
Valor
Figura 4.11 Realização de valor mais rápida com uma abordagem iterativa
No passado, os requisitos sempre eram definidos no início de um projeto em discussões formais entre as partes interessadas e
um analista de negócios que havia recebido uma tarefa temporária baseada no projeto. Esses requisitos se tornariam então a base para
as atividades de desenvolvimento.
Cada vez mais, no entanto, os produtos são desenvolvidos e melhorados com base no feedback. O feedback pode ser relatado pelos
usuários ou observado indiretamente. A análise e a especificação de requisitos acontecem de forma contínua.
A análise de negócios geralmente não é mais realizada por um analista de negócios dedicado; é um papel que pode ser cumprido em
combinação com outros papéis. Quando essa abordagem é usada, o desenvolvimento pode ser desafiador porque a arquitetura do
produto já foi estabelecida. Portanto, a análise de pré-desenvolvimento deve considerar essas preocupações futuras e criar uma
arquitetura flexível. A análise pós-desenvolvimento difere da pré-desenvolvimento no sentido de que é menos focada na criação de uma
arquitetura e mais focada em trabalhar efetivamente dentro das restrições arquiteturais do sistema.
A Figura 4.12 mostra a contribuição da análise contínua de negócios para a cadeia de valor do serviço.
A Tabela 4.9 descreve as práticas para as quais a análise contínua de negócios é relevante.
A história da ITIL: Análise de negócios contínua

Radhika: Os princípios orientadores da ITIL são úteis para todas as equipes da empresa. Por exemplo, o foco no
princípio de valor se encaixa perfeitamente na análise de negócios. As circunstâncias mudam continuamente e os
recursos que estão em desenvolvimento podem se tornar de prioridade mais baixa ou mais alta, dependendo de como
seu valor é afetado. Por exemplo, uma nova legislação que afeta o uso de aplicativos ou armazenamento de dados se
tornaria automaticamente uma alta prioridade.
99
0 1 2 3
Baixo Alto
Plano
Projeto
e transição

Se empenhar
e suporte
Melhorar
Figura 4.12 Mapa de calor da contribuição da análise contínua de negócios para a cadeia de valor do serviço
Tabela 4.9 Práticas para as quais a análise contínua de negócios é relevante
Prática de gerenciamento ITIL Atividades/recursos associados à análise contínua de negócios Impacto
Análise de negócio Analisar continuamente os clientes, as condições do mercado e o ecossistema mais amplo para entender H
seus impactos nos produtos e serviços da organização.
Gerenciamento de infraestrutura e Analisar continuamente os clientes, as condições do mercado e o ecossistema mais amplo para entender H
plataforma seus impactos na infraestrutura e nos produtos da plataforma da organização.
Gerenciamento de portfólio Analisar continuamente os clientes, as condições do mercado e o ecossistema mais amplo para entender seus impactos H
na forma como a organização investe em vários produtos e serviços.
Monitoramento de investimentos em portfólio em andamento para identificar vazamento de valor ou para verificar a
cocriação de valor.
Gerenciamento de Projetos Analisar continuamente os clientes, as condições do mercado e o ecossistema mais amplo para entender H
seus impactos nos projetos da organização e nos casos de negócios associados.
Gestão de relacionamento Analisar continuamente os clientes, as condições do mercado e o ecossistema mais amplo para entender H
seus impactos nos relacionamentos da organização com as partes interessadas externas.
Gerenciamento de riscos Verificação contínua de riscos corporativos internos e externos para avaliar e entender seu impacto nos produtos e H
serviços da organização e para projetar mitigações e contramedidas apropriadas.
Projeto de serviço Analisar continuamente os clientes, as condições do mercado e o ecossistema mais amplo para entender H
seus impactos nas experiências dos clientes e usuários dos produtos e serviços da organização.
Desenvolvimento e gerenciamento Analisar continuamente os clientes, as condições do mercado e o ecossistema mais amplo para entender H
de software seus impactos nos produtos de software da organização e a priorização do trabalho contínuo de desenvolvimento
de software.
Gestão de estratégia Monitorar e avaliar continuamente os clientes, as condições do mercado e o ecossistema mais amplo para H
entender seus impactos nos produtos e serviços da organização e ajustar a estratégia de acordo.
100
Prática de gerenciamento ITIL Atividades/recursos associados à análise contínua de negócios Impacto
Gerenciamento de arquitetura Analisar continuamente o uso da tecnologia dentro da organização e por partes interessadas externas M
para entender seus impactos na arquitetura técnica, de serviços e de informações da organização.
Gestão do conhecimento Analisar continuamente os clientes, as condições do mercado e o ecossistema mais amplo para criar um M
entendimento compartilhado entre as partes interessadas relevantes.
Gerenciamento de Analisar continuamente os clientes, as condições do mercado e o ecossistema mais amplo para M
continuidade de serviço entender seus impactos nas medidas de continuidade e recuperação de desastres da organização.
Gestão de fornecedores Analisar continuamente os clientes, as condições do mercado e o ecossistema mais amplo para M
entender seus impactos nos relacionamentos da organização com parceiros e fornecedores.
Integração contínua, entrega contínua e

4.2.5 implantação contínua
Integração contínua, entrega contínua e implantação contínua (CI/CD) são termos descritivos para uma coleção de práticas
principalmente associadas à engenharia de software, que são centrais para a filosofia de desenvolvimento de software Lean e Agile. A
adoção dessas práticas cresceu rapidamente e é importante entender as características definidoras de CI/CD e o contexto mais amplo das
práticas de desenvolvimento de sistemas em evolução ao implementar serviços que são sustentados pelo desenvolvimento de software.
Definições
• Integração contínua Uma abordagem para integrar, construir e testar código dentro do software
ambiente de desenvolvimento.
• Entrega contínua Uma abordagem para desenvolvimento de software na qual o software pode ser liberado para
produção a qualquer momento. Implantações frequentes são possíveis, mas as decisões de implantação são tomadas caso a
caso, geralmente porque as organizações preferem uma taxa de implantação mais lenta.
• Implantação contínua Uma abordagem de desenvolvimento de software na qual as alterações passam pelo pipeline e são
colocadas automaticamente no ambiente de produção, permitindo várias implantações de produção por dia. A implantação
contínua depende da entrega contínua.
CI/CD contribui para o desenvolvimento rápido e, como as implantações são mais confiáveis, para operações resilientes.
A integração contínua é a automação alcançada no processo de compilação e teste de código cada vez que o código é confirmado, o que
resulta em alterações no controle de versão. A integração contínua promove a prática de compartilhamento de código na comunidade de
desenvolvimento de software, mesclando as alterações em um repositório de código compartilhado centralmente.
A confirmação de código aciona a funcionalidade de compilação automatizada para extrair a confirmação de código mais recente do
repositório de controle de versão compartilhado e compilar, testar e validar a ramificação mestre completa (ou seja, o tronco).
A integração contínua surgiu como uma prática devido à natureza isolada do desenvolvimento de software, em que os desenvolvedores
exigem pontos de integração constantes entre suas alterações e o restante da base de código da equipe de desenvolvimento. Longos ciclos
de espera causam conflitos de mesclagem, bugs com caminhos de resolução difíceis, estratégias de código divergentes e esforços
duplicados. Um dos principais objetivos da integração contínua é manter o branch master livre de exceções e erros. As equipes de
desenvolvimento de software podem estabelecer políticas de filial para garantir que a filial principal atenda a determinados critérios de
qualidade pré-acordados e pré-autorizados.
101
A entrega contínua é focada no processo de construção e teste de novos lançamentos e promovê-los para o ambiente de
produção. Isso requer ambientes de teste, que se tornam parte de um pipeline de lançamento para automatizar o provisionamento
de infraestrutura e a implantação de novos lançamentos.
A entrega contínua é uma prática Lean; seu objetivo é manter um ambiente de produção livre de incidentes funcionando bem.
Isso é alcançado descobrindo o caminho mais curto desde a disponibilidade do novo código no repositório de controle de
versão até o gerenciamento de empacotamento para fins de implantação.
A entrega contínua depende do conceito de anéis de implantação progressiva para um modelo de implantação. O primeiro
anel de implantação geralmente é uma 'versão canário' em um ambiente de produção acessível à equipe interna de TI da
organização ou a outros grupos relevantes de usuários internos. Anéis de implantação consecutivos dão as boas-vindas a
populações de usuários mais amplas. Esses anéis de implantação subsequentes podem exigir um ponto de aprovação por um
decisor-chave. Se uma organização usa esses anéis para implantação, geralmente segue a mesma abordagem para gerenciamento de versão.
Outro modelo de implantação usa o conceito de 'implantação azul/verde', em que a versão existente continua sendo executada
em um ambiente de produção (conhecido como 'azul') enquanto uma nova versão é implantada em um ambiente 'verde' idêntico.
Normalmente, o balanceamento de carga é usado para redirecionar um número limitado de usuários para a versão 'verde'. Se
ocorrer um incidente, o tráfego pode ser redirecionado para a versão 'azul'. Caso contrário, o ambiente 'verde' se torna o padrão e
o ambiente 'azul' é usado para a próxima implantação.
A Figura 4.13 mostra a contribuição do CI/CD para a cadeia de valor do serviço.
A Tabela 4.10 descreve as práticas para as quais CI/CD são mais relevantes.
0 1 2 3
Baixo Alto
Plano
Projeto
e transição

Se empenhar
e suporte
Melhorar
Figura 4.13 Mapa de calor da contribuição do CI/CD para a cadeia de valor do serviço
102
Tabela 4.10 Práticas para as quais CI/CD são mais relevantes
Prática de gerenciamento ITIL Atividades/recursos associados ao CI/CD Impacto
Alterar ativação A taxa de mudança nos produtos e serviços da organização pode ser ajustada usando um pipeline de CI/CD de acordo H
com as necessidades e expectativas do negócio.
Gerenciamento de implantação A instalação sistemática/automática de versões específicas ou pacotes de software em um ambiente predeterminado H
(integração, teste de aceitação do usuário, produção).
Gerenciamento de infraestrutura e Uso de técnicas de CI/CD para infraestrutura digital. H
plataforma
Gerenciamento de lançamento Reconhecimento de que a implantação de software e o lançamento de funcionalidades são atividades muitas vezes H
distintas que ajudam a planejar e gerenciar lançamentos.
Gerenciamento de Gerenciar repositórios de código e as ferramentas associadas que fazem parte de uma cadeia de ferramentas de CI/CD e H
configuração de serviço atualizar continuamente CMDB(s) para refletir quando alterações significativas (nível de CI) foram feitas.
Validação e teste de serviço Desenvolvimento de casos de teste automatizados para suportar atividades de integração contínua. H
Desenvolvimento e gerenciamento Uso de técnicas de CI/CD que são usadas para software aplicativo. H
de software
Gerenciamento de arquitetura Projetar e melhorar a arquitetura de serviços, técnica e de informações para aproveitar os recursos de CI/CD. A M
conteinerização é uma escolha de arquitetura que suporta CI/CD.
Gerenciamento de Garantir a conformidade com as políticas de segurança da informação reduzindo o trabalho manual. Aumentar a escala e o M
segurança da informação escopo da automação aproveitando as ferramentas de CI/CD pode ajudar a garantir a conformidade com as políticas de
segurança da informação, reduzindo o trabalho manual e melhorando a rastreabilidade das alterações.
Gestão do conhecimento Atualizar continuamente as bases de conhecimento para garantir que a organização mantenha um entendimento M
atualizado do software que está sendo construído e implantado por meio de pipelines de CI/CD.
Gerenciamento de Os pipelines de CI/CD devem ser configurados para enviar componentes de software para sistemas de continuidade e M
continuidade de serviço recuperação de desastres.
Gerenciamento de riscos Reduzindo os impactos de certos tipos de riscos corporativos por meio do uso da automação de CI/CD. eu
A história da ITIL: Integração contínua, entrega contínua e

implantação contínua
Marco: Criamos ambientes idênticos de compilação, teste e live para o aplicativo, o que nos permite integrar
e entregar continuamente um novo código compatível com a base de código existente. Como resultado,
podemos desenvolver o aplicativo em alta cadência com código que já funciona. Também temos menos
incidentes causados por bugs que podem ter caminhos de resolução difíceis.
4.2.6 Testes contínuos

O teste de software não é apenas testar o software desenvolvido e operacional. O teste é algo que deve ser realizado
durante todo o ciclo de vida de desenvolvimento de software. A Tabela 4.11 descreve os diferentes tipos de teste.
103
Tabela 4.11 Tipos de teste de software
Testando as ideias Todo software se origina de uma ideia, muitas vezes uma tentativa de resolver um problema. Testar a ideia ajuda a determinar sua
qualidade de uma perspectiva do cliente (com base em desejos e necessidades) e uma perspectiva de negócios (com base em métricas,
incluindo crescimento, receita, conversão e base de usuários).
Testando os artefatos Artefatos, como épicos, histórias de usuários, critérios de aceitação, diagramas de fluxo de dados e diagramas de fluxo de processo,
devem ser testados. Inspecionar as informações dentro dos artefatos pode ajudar a identificar ambiguidades, suposições e informações
relacionadas a riscos e variáveis. Essas informações podem ser usadas como feedback para ajudar a revisar e melhorar os artefatos.
Testar a experiência do usuário e os Os artefatos são usados para atividades de design, atividades de programação e atividades de teste. As atividades de design produzem
designs de interface do usuário mais artefatos de design do que podem ser testados. As interfaces e a experiência são testadas usando artefatos relevantes, e os
resultados dos testes podem afetar outros artefatos.
Testando a arquitetura e os designs Ao projetar a arquitetura de software e discutir como construí-la e novos recursos, o teste exploratório pode aprimorar os projetos e as
de código ideias.
Testando o código As revisões de código são uma parte importante da construção de um produto de alta qualidade. Qualquer pessoa deve ser capaz de ler o
código e testá-lo de diferentes perspectivas. O teste de unidade verifica se cada unidade do software funciona como deveria. Testes unitários
são frequentemente automatizados. É importante notar que este é o primeiro ponto dentro do ciclo de vida de desenvolvimento de software
onde deve haver algo tangível para medir.
Testando o software operacional Testar o software operacional é a atividade mais comum associada ao teste. Muitas equipes ágeis incluem 'teste' como um status em seu
fluxo de trabalho após o desenvolvimento. No entanto, o teste não deve ser um status em um fluxo de trabalho; deve ser uma série de
atividades estruturadas conduzidas ao longo do ciclo de vida de desenvolvimento de software.
Testes em diferentes Quando se trata de ambientes de teste, uma abordagem baseada em risco pode ser apropriada. Existem muitos riscos que podem ser testados.
ambientes Alguns deles não podem ser testados em um ambiente de desenvolvimento. Para outros, é necessário um ambiente rigorosamente integrado
para teste. Alguns riscos só podem ser testados no ambiente de produção real.
Testando os pipelines de lançamento Os processos de pipeline podem ser testados, e as equipes geralmente o fazem de forma implícita para aprimorar seus pipelines para serem
o mais eficientes e rápidos possível. Isso requer uma boa compreensão da estrutura por trás do teste de pipeline.
Testando o sistema em Alguns riscos devem ser testados no ambiente de produção, como riscos de desempenho (particularmente riscos de carga e estresse do
produção usuário), teste de aceitação do usuário (onde os usuários usam o sistema como fariam com o software ao vivo) e riscos de observabilidade
(para testar a eficácia de soluções e implementações de observabilidade).
Ao testar em produção, o objetivo deve ser minimizar o risco de testes afetarem os clientes.
As estratégias para conseguir isso incluem:
• Versões Canary O novo recurso é lançado inicialmente para um grupo pequeno e direcionado de usuários, aumentando gradualmente para
todos os usuários.
• Alternância de recursos Os recursos podem ser ocultados atrás de um sinalizador de recurso, facilmente ativados ou desativados
ativando ou desativando o sinalizador.
• Implantações Azul/Verde Dois ambientes de produção idênticos são executados simultaneamente (um 'azul' e um 'verde'), com apenas
um dos ambientes funcionando, atendendo a todo o tráfego de produção, enquanto o outro é usado para implantação das novas
versões.
• Estratégias automatizadas de reversão As ferramentas de automação podem reverter rapidamente a versão para sua versão anterior
versão em caso de incidente.
Testando os serviços em Existem muitos serviços, atividades e tecnologias que são implementados para software de produção lançado, que podem ser testados.
produção
Do ponto de vista da entrega de serviços, é importante testar os processos. Por exemplo, ao testar se um usuário pode acessar o
suporte, é importante perguntar: quão fácil é para os usuários obterem suporte?
Que oportunidades os usuários têm dentro do software para fazer isso?
Para obter testes contínuos, vários princípios12 devem estar em vigor, incluindo:
• Os testes devem ser escritos no nível mais baixo possível.
• Testes com menos dependências externas devem ser favorecidos.
• Escreva uma vez, execute em qualquer lugar, inclusive no sistema de produção.
• Os produtos devem ser projetados para testabilidade.
• O código de teste é o código do produto; apenas testes confiáveis sobrevivem.
• A infraestrutura de teste é um serviço compartilhado.
104
• A propriedade do teste segue a propriedade do produto.
• Injeções de falhas e engenharia de caos na produção devem ser praticadas para testar a resiliência do serviço.
• Testes não confiáveis devem ser eliminados.
A Figura 4.14 mostra a contribuição dos testes contínuos para a cadeia de valor do serviço.
A Tabela 4.12 descreve as práticas para as quais o teste contínuo é mais relevante.
0 1 2 3
Baixo Alto
Plano
Projeto
e transição

Se empenhar
e suporte
Melhorar
Figura 4.14 Mapa de calor da contribuição dos testes contínuos para a cadeia de valor do serviço
Tabela 4.12 Práticas para as quais o teste contínuo é mais relevante
Prática de gerenciamento ITIL Atividades/recursos associados a testes contínuos Impacto
Gerenciamento de arquitetura Projetar e melhorar a arquitetura de serviços, técnica e de informações para alavancar CI/ H
capacidades de CD.
Validação e teste de serviço Os testes de unidade, integração e regressão são realizados continuamente durante todo o ciclo de vida do desenvolvimento. H
Isso inclui teste de unidade de aplicativo, teste de serviço de infraestrutura, teste funcional/não funcional, versões canário,
teste azul/verde e teste de segurança de infraestrutura.
Gerenciamento de implantação Alterações ou implantações que fazem com que os testes contínuos falhem acionam o cordão Andon da equipe. Os membros M
da equipe então se aglomeram para resolver o problema.
Gerenciamento de Garantir a conformidade com as políticas de segurança da informação reduzindo o trabalho manual. Aproveitar as ferramentas de M
segurança da informação teste automatizadas pode ajudar a garantir a conformidade com as políticas de segurança da informação, reduzindo o trabalho
manual e melhorando a rastreabilidade das alterações.
Gerenciamento de problemas Testes automatizados ajudam a verificar a resolução de problemas, a presença de erros conhecidos ou a eficácia das M
soluções alternativas.
Gerenciamento de Os testes automatizados podem acelerar o provisionamento de recursos técnicos necessários para a recuperação de um M
continuidade de serviço desastre.
Gerenciamento de riscos Reduzindo o impacto de certos tipos de riscos corporativos usando a automação de testes. eu
105
A história da ITIL: testes contínuos

Su: Todos os produtos que lançamos no mercado são exaustivamente testados para garantir que sejam adequados à finalidade e
ao uso. As melhorias do aplicativo não são diferentes. Testamos:
• as ideias iniciais para a nova funcionalidade para garantir que eles tenham o potencial de alcançar
nossos objetivos
• épicos, histórias de usuários e critérios de aceitação
• melhorias no design da interface para garantir que seja intuitivo e fácil de usar
• projetos de código e arquitetura de software para garantir que sejam robustos
• código para corrigir bugs e falhas que foram introduzidas durante o desenvolvimento
• o sistema e o software em produção.
Em cada estágio, revisitamos decisões anteriores se os testes sugerissem que havíamos introduzido ineficiências ou
defeitos significativos.
4.2.7 Kanban
Kanban é um conjunto de princípios, práticas e atividades regulares que visam desenvolver e gerenciar um fluxo de trabalho previsível, rítmico e
constante. Quando aplicado corretamente, pode acelerar significativamente o desenvolvimento de produtos e serviços de alta qualidade. O mecanismo
de acionamento baseado em pull permite que os clientes puxem o trabalho através do fluxo de valor. O trabalho puxado também tem a vantagem de que
o trabalho não é empurrado para as pessoas, sobrecarregando-as desnecessariamente e improdutivamente. Isso é valioso em equipes Lean, onde a
sobrecarga é uma forma de desperdício.
Definição: Kanban
Um método Lean baseado em um fluxo de trabalho baseado em pull altamente visualizado que gerencia e melhora o trabalho em
sistemas humanos, equilibrando demandas com capacidade disponível e melhorando o tratamento de gargalos no nível do sistema.
As principais práticas do Kanban são:
• visualização do trabalho
• limitar o trabalho em andamento
• gerenciamento de fluxo
• tornar as políticas de processo explícitas
• implementação de ciclos de feedback
• melhorar a colaboração
• evoluindo experimentalmente.
Às vezes, as organizações usam apenas quadros Kanban para visualizar o trabalho em andamento. Embora o uso de um quadro seja importante,
é uma aplicação limitada do Kanban. O poder do Kanban depende da implementação holística e atenção constante ao fluxo de trabalho. Um exemplo
de quadro Kanban é mostrado na Figura 4.15.
106
Em andamento
Façam Estágio 1 Estágio 2 Estágio 3 Feito
Limite de WIP = 3 Limite de WIP = 4 Limite de WIP = 2
Feito Dentro Feito Dentro Feito
Em andamento progresso progresso
Figura 4.15 Um exemplo de um quadro Kanban
Kanban sugere um sistema de reuniões regulares que garantem uma comunicação eficaz. Este sistema é muitas vezes referido como
'cadências Kanban'. A frequência das cadências é específica de uma organização e deve ser definida e ajustada caso a caso. As
reuniões são:
• revisão da estratégia
• revisão de operações
• revisão de risco
• revisão de entrega de serviço
• reunião de reabastecimento
• reunião de planejamento de entrega.
A Figura 4.16 mostra a contribuição do Kanban para a cadeia de valor do serviço.
A Tabela 4.13 descreve as práticas para as quais o Kanban é relevante.
A história da ITIL: Kanban

Radhika: Usamos um quadro Kanban para visualizar fluxos de trabalho para o desenvolvimento de nosso aplicativo para
que pudéssemos rastrear gargalos. Muitas vezes, eles podem ser eliminados com recursos extras ou redesenhando o
fluxo de trabalho. A natureza visual de um quadro Kanban permite que colegas e partes interessadas fora da equipe
principal de desenvolvimento entendam como o trabalho está progredindo, o que lhes permite planejar melhor e criar mais
valor.
107
0 1 2 3
Baixo Alto
Plano
Projeto
e transição

Se empenhar
e suporte
Melhorar
Figura 4.16 Mapa de calor da contribuição do Kanban para a cadeia de valor do serviço
Tabela 4.13 Práticas para as quais o Kanban é relevante
Prática de gerenciamento ITIL Atividades/recursos associados ao Kanban Impacto
Alterar ativação Visualizando e melhorando o fluxo de mudanças em serviços e componentes de serviço, limitando o trabalho em andamento. H
Melhoria contínua Visualizando e melhorando o fluxo de melhorias no SVS. H
Gerenciamento de Projetos Visualizando e melhorando o fluxo de trabalho entre projetos e equipes. H
Gerenciamento de lançamento Visualizando e melhorando a qualidade dos lançamentos para os consumidores. H
Desenvolvimento e gerenciamento Visualizando e melhorando o fluxo de componentes de software novos ou alterados em ambientes ativos. H
de software
Gerenciamento de incidentes Visualizando e melhorando a velocidade e a qualidade da resolução de incidentes, limitando o trabalho em andamento. M
Gerenciamento de portfólio Visualização e melhoria do fluxo de investimentos em todo o(s) pipeline(s) do portfólio. M
Gerenciamento de problemas Visualizando e melhorando o controle de problemas e erros, limitando o trabalho em andamento. M
Gestão de fornecedores Visualização do progresso de integração/desligamento do fornecedor. M
4.3 Técnicas para operações resilientes

O objetivo de operações resilientes envolve garantir que os produtos digitais estejam disponíveis para uso sempre que necessário.
O valor potencial dos investimentos digitais só pode ser realizado quando os produtos e serviços digitais investidos estiverem
disponíveis para uso. O cumprimento dos requisitos não funcionais fornece garantia e reduz o risco de que problemas afetem
negativamente a utilidade dos produtos e serviços.
108
Os sistemas de informação dependem cada vez mais de tantos componentes que o comportamento muitas vezes não pode ser previsto
ou garantido. Os sistemas à prova de falhas são uma ilusão; as organizações devem estar preparadas para falhas inevitáveis e inesperadas.
A ênfase não está mais em manter um longo intervalo entre falhas; trata-se de restaurar o serviço rapidamente quando ocorrem problemas
inevitáveis. Isso reduz a interrupção das operações de negócios.
A resiliência se aplica a todas as partes da pilha de sistemas e também à organização que gerencia essas partes componentes. É somente
quando cada componente é resiliente que as partes voltadas para o consumidor são resilientes. Operações resilientes não acrescentam nada ao
valor potencial de um investimento; em vez disso, eles garantem que seu valor potencial possa ser realizado. Como os sistemas de informação
são complexos e, portanto, intrinsecamente propensos a erros, a resiliência tem a ver com a limitação de danos. Dependendo da natureza dos
sistemas, os danos podem ser expressos em termos de perda de receita, preços mais baixos, custos incorridos e danos à reputação. Por exemplo,
quando um site de comércio eletrônico sofre de baixa disponibilidade ou desempenho:
• a receita é perdida se os clientes recorrerem a outros fornecedores
• há pressão para baixar os preços devido à redução da satisfação do cliente
• os custos são incorridos para restaurar o serviço, implementar soluções alternativas e comunicar-se com os consumidores
• danos à reputação ocorrem quando o provedor é percebido como lidando mal com os incidentes; por exemplo, não tomando as medidas
apropriadas, não se importando, retendo informações ou não aprendendo com os incidentes.
A consumerização da TI levou a uma expectativa de que os sistemas corporativos de TI estarão disponíveis a qualquer hora e em qualquer lugar.
A resiliência pode ser drasticamente melhorada pelos recursos de nuvem que agora estão disponíveis por uma fração do custo dos sistemas
locais. Sistemas e serviços resilientes não são mais uma escolha, são uma expectativa realista devido à nuvem e à consumerização de TI.
As operações resilientes podem ser medidas em termos de disponibilidade, desempenho e segurança. A disponibilidade é medida como uma
porcentagem juntamente com uma especificação do tempo médio entre a falha e o tempo médio para restaurar o serviço. A disponibilidade é
notoriamente pouco confiável como indicador de seu efeito sobre os consumidores de serviços. Também é difícil de medir; por exemplo, quando
um sistema está parcialmente disponível.
O desempenho é medido de várias maneiras; por exemplo, o tempo de carregamento de uma página da Web, a execução de uma
consulta de dados ou a conclusão de um processo em lote. A segurança pode ser medida em termos de brechas de segurança, mas isso apenas
mede as brechas que foram detectadas. Os melhores indicadores são a maturidade do monitoramento dos controles e a capacidade de analisar
as informações de log para identificar riscos e violações.
As técnicas que podem ser usadas para alcançar operações resilientes incluem:
• dívida técnica
• engenharia do caos
• definição de feito
• controle de versão
• AIOps
• Operações de bate-papo
• engenharia de confiabilidade do site.
A história da ITIL: Técnicas para operações resilientes

Henri: Nosso aplicativo deve ser confiável e consistente, ou será considerado defeituoso por nossos clientes.
Também precisamos garantir que nossa equipe seja resiliente e possa se adaptar a diferentes condições, caso suas
formas de trabalho precisem mudar.
109
4.3.1 Dívida técnica
Definição: dívida técnica
O backlog total de retrabalho acumulado pela escolha de soluções alternativas em vez de soluções de sistema que levariam
mais tempo.
No desenvolvimento e gerenciamento de software, a dívida técnica é o acúmulo total de retrabalho necessário para reparar
softwares abaixo do padrão (mudanças no) software. Geralmente, quando o software é usado, as melhorias e os reparos se seguem.
Quando essas alterações forem aplicadas, a qualidade do software diminuirá, a menos que seja feito um esforço para limitar os danos.
Isso é conhecido como 'entropia de software', que é particularmente relevante para HVIT devido aos grandes investimentos em software,
à frequência das mudanças e à necessidade de mudar rapidamente para acompanhar a demanda do mercado.
A dívida técnica é o acúmulo de trabalho necessário para corrigir danos ocorridos durante o aprimoramento ou reparo do software. Esses
danos geralmente são causados por uma combinação de tempo, dinheiro, conhecimento e habilidades limitados.
Por exemplo, as organizações que estão sob pressão para restaurar o serviço normal quando o software falha podem aplicar uma
solução fácil para resolver o problema rapidamente. Muitas vezes, há a intenção de corrigi-lo adequadamente mais tarde, mas em muitos
casos, isso não acontece. A 'correção adequada' pretendida pode não ser formalmente registrada e será posteriormente esquecida.
A dívida técnica também pode ocorrer durante o desenvolvimento inicial de um aplicativo, onde prazos ou restrições orçamentárias
levam a atalhos. Quase todo projeto tem um legado, que às vezes surpreende seus benfeitores.
Interesse técnico é a soma do custo envolvido na aplicação de mudanças em softwares difíceis de serem alterados devido à
qualidade comprometida, mais o custo dos incidentes causados por essas imperfeições. Desde que os juros não sejam proibitivos, a
dívida técnica pode ser perfeitamente aceitável. No entanto, tende a se acumular e, quanto maior a dívida, maior o risco envolvido. Esse
risco deve ser gerenciado.
A redução da dívida técnica resulta em menos incidentes e, portanto, contribui para operações resilientes. Também contribui para
investimentos valiosos e desenvolvimento rápido. Um equilíbrio entre esses benefícios deve ser alcançado e mantido. Portanto, é
prudente reconhecer a existência de dívida técnica, qualificá-la e quantificá-la da melhor maneira possível, avaliar os riscos
associados de curto e longo prazo e tomar as decisões apropriadas como parte do gerenciamento do produto (software), incluindo
alocar um orçamento para 'reembolsar' a dívida técnica (ver também o conceito de erro de orçamento na seção 4.3.7).
A Figura 4.17 mostra a contribuição da dívida técnica para a cadeia de valor do serviço.
A Tabela 4.14 descreve as práticas para as quais a dívida técnica é relevante.
A história da ITIL: dívida técnica

Henri: O trabalho de desenvolvimento do aplicativo irá reutilizar muito código existente; portanto, acumularemos
alguma dívida técnica. À medida que nosso aplicativo cresce, talvez seja necessário implementar soluções alternativas
para acelerar os lançamentos, mas isso pode tornar o código suscetível a incompatibilidades posteriormente.
Marco: Quanto mais trabalharmos para melhorar o código original, mais resiliente ele será e menos dívida técnica
acumularemos.
110
0 1 2 3
Baixo Alto
Plano
Projeto
e transição

Se empenhar
e suporte
Melhorar
Figura 4.17 Mapa de calor da contribuição da dívida técnica para a cadeia de valor do serviço
Tabela 4.14 Práticas para as quais a dívida técnica é relevante
Prática de gerenciamento de ITIL Atividades/recursos associados à dívida técnica Impacto
Gerenciamento de incidentes A resolução e o gerenciamento de incidentes requerem conhecimento da dívida técnica existente e dos esforços planejados H
para resolvê-la.
Gerenciamento de infraestrutura e Identificando e reduzindo a dívida técnica criando ou modificando componentes de serviços de infraestrutura e plataforma. H
plataforma
Gestão do conhecimento Garantir que todas as partes interessadas relevantes tenham acesso a informações atualizadas. H
Gerenciamento de portfólio Decidir se investir recursos para corrigir a dívida técnica presente em produtos e serviços ao vivo e entender o impacto H
nos investimentos em produtos e serviços futuros.
Avaliar a dívida técnica para que novos itens do portfólio possam ser introduzidos no pool existente.
Avaliar a dívida técnica dos itens atuais do portfólio para evitar a drenagem de valor.
Gerenciamento de problemas Aplicação de métodos de controle de problemas e controle de erros para gerenciar dívida técnica. H
Desenvolvimento e gerenciamento Identificando e reduzindo a dívida técnica criando ou modificando componentes de serviços de infraestrutura e plataforma. H
de software
Análise de negócio Compreender o impacto da dívida técnica na articulação de requisitos e soluções. M
Melhoria contínua Identificar, priorizar e gerenciar esforços para reduzir a dívida técnica. M
Gerenciamento de O projeto, implementação e aprimoramento dos controles de segurança da informação são influenciados pela dívida técnica M
segurança da informação existente. Os controles de segurança da informação também podem resultar na criação de dívida técnica, que precisa ser
reconhecida e comunicada a todas as partes interessadas relevantes.
Gerenciamento de Projetos O planejamento e a execução de projetos são influenciados pela dívida técnica existente. M
Os projetos também podem resultar na criação de dívida técnica, que precisa ser reconhecida e comunicada a todas as partes
interessadas relevantes.
Gerenciamento de riscos Reconhecer o impacto da dívida técnica em riscos corporativos novos ou existentes; as mitigações de risco podem criar dívida M
técnica que precisa ser reconhecida e comunicada a todas as partes interessadas relevantes.
Balcão de atendimento A comunicação com usuários externos que precisam de assistência com incidentes e solicitações requer conhecimento da dívida M
técnica existente e dos esforços planejados para resolvê-la.
111
4.3.2 Engenharia do caos
Definição: engenharia do caos
A disciplina de experimentar em um sistema para criar confiança na capacidade do sistema de suportar condições turbulentas
na produção.
Para lidar com a incerteza de sistemas distribuídos, a engenharia do caos se baseia em quatro etapas básicas13:
• Defina o estado estacionário; esta será a saída de um comportamento normal.
• Hipotetize que esse estado estacionário continuará.
• Introduza variáveis que reflitam eventos do mundo real.
• Tente refutar a hipótese.
Os princípios para uma aplicação ideal da engenharia do caos são:
• Construir e formular hipóteses em torno do comportamento de estado estacionário Concentre-se nas saídas mensuráveis do
sistema, em vez dos atributos do sistema.
• Variar eventos do mundo real Variáveis de caos refletem eventos do mundo real. A priorização deve ser definida por
considerando o impacto ou a frequência estimada dos eventos.
• Executar experimentos em produção O Chaos prefere experimentar diretamente no tráfego de produção.
• Automatize experimentos para execução contínua Crie automação nos sistemas para conduzir a orquestração
e análise.
• Minimize o raio da explosão As consequências dos experimentos devem ser minimizadas e contidas.
Alguns dos benefícios da engenharia do caos são:
• prepara a equipe para falhas aleatórias de instância
• incentiva a redundância
• torna os sistemas mais fortes, incutindo confiança para se mover rapidamente em sistemas complexos
• introduz condições realistas em uma execução controlada, descobrindo pontos fracos antes que eles causem problemas
• aborda os pontos fracos mais significativos de forma proativa, antes que eles afetem os clientes em produção.
O macaco do caos é uma das ferramentas do chamado exército símio,14 o conjunto de ferramentas mais conhecido para a engenharia do caos.
The Simian army é uma coleção de ferramentas de teste de nuvem de código aberto criadas pela Netflix®. O macaco do caos testa as
respostas às falhas do sistema desativando certos componentes para ver como os sistemas restantes responderão.
Embora o macaco do caos possa interromper as operações, também contribui para sua resiliência a longo prazo.
Definição: macaco do caos
Uma ferramenta que testa a resiliência dos sistemas de TI desativando intencionalmente os componentes em produção para testar
como os sistemas restantes respondem à interrupção.
112
A implantação do macaco do caos resulta na terminação de um sistema selecionado aleatoriamente dentro de um grupo identificado de
sistemas. Isso cria uma situação próxima a um incidente natural e testa a capacidade dos sistemas de sustentar falhas. Outro membro do
exército símio, o macaco da conformidade, verifica cada serviço para cumprir as melhores práticas definidas pelo arquiteto.
Outros membros do exército símio incluem:
• Macaco de latência Induz atrasos artificiais para simular a degradação do serviço e verificar se depende
serviços respondem adequadamente.
• Doctor monkey Executa verificações de integridade para determinar instâncias não íntegras e desligá-las proativamente se os proprietários não
corrigirem a causa raiz.
• Security monkey Localiza e encerra instâncias de violações de segurança ou vulnerabilidades.
• Macaco zelador Garante que o ambiente de nuvem esteja livre de desordem e desperdício.
A Figura 4.18 mostra a contribuição da engenharia do caos para a cadeia de valor do serviço.
A Tabela 4.15 descreve as práticas para as quais a engenharia do caos é relevante.
0 1 2 3
Baixo Alto
Plano
Projeto
e transição

Se empenhar
e suporte
Melhorar
Figura 4.18 Mapa de calor da contribuição da engenharia do caos para a cadeia de valor do serviço
113
Tabela 4.15 Práticas para as quais a engenharia do caos é relevante
Prática de gerenciamento ITIL Atividades/recursos associados à engenharia do caos Utilizar a engenharia Impacto
Melhoria contínua do caos como uma das ferramentas mais eficazes para melhorar a qualidade do serviço. H
Gerenciamento de infraestrutura e Projetar infraestrutura e plataformas para resiliência e redundância suficientes para lidar com interrupções inesperadas H
plataforma causadas por ferramentas de engenharia de caos.
Fornecer informações para engenharia de caos em relação a componentes de serviço e atividades de backup.
Gerenciamento de Projetar medidas de continuidade de serviço com resiliência e redundância suficientes para lidar com interrupções inesperadas H
continuidade de serviço causadas por ferramentas de engenharia de caos.
Monitorar continuamente os planos, medidas e mecanismos de continuidade para resiliência.
Gerenciamento de nível de serviço Os testes devem ser projetados e executados considerando a estratégia de continuidade de negócios, acordos de nível H
de serviço e critérios claros estabelecidos para degradação do serviço caso uma interrupção artificial exceda os níveis
aceitáveis.
Desenvolvimento e gerenciamento As próprias ferramentas de engenharia do caos são aplicativos de software que precisam ser desenvolvidos (ou configurados) e H
de software gerenciados. O software deve ser projetado e arquitetado com resiliência e redundância suficientes.
Gerenciamento de arquitetura A construção de infraestrutura resiliente, que é promovida pela engenharia do caos. M
Considerando as interações entre serviços e componentes para atender a demanda.
Gerenciamento de capacidade e Ao executar esse tipo de teste, as informações de desempenho devem ser capturadas. Como resultado, melhorias devem M
desempenho ser identificadas para garantir que os serviços sejam projetados para desempenho, escalabilidade e capacidade ideais.
Gerenciamento de incidentes As equipes podem praticar a resposta e a recuperação de interrupções usando ferramentas de engenharia do caos. Eles devem M
estar preparados para gerenciar incidentes sem afetar os usuários. Redundância e automação devem ser incorporadas aos
processos.
Medição e relatórios Os testes de engenharia do caos envolvem experimentos e hipóteses e ajudarão a coletar e analisar dados para planejamento M
e previsão. Os resultados apoiam a estratégia de negócios de continuidade.
Monitoramento e As ferramentas de monitoramento e gerenciamento de eventos podem ser configuradas para sinalizar interrupções orquestradas M
gerenciamento de eventos por ferramentas de engenharia de caos ou para monitorar a qualidade do serviço em vez dos componentes técnicos.
Gestão de mudanças A engenharia do caos ajudará a garantir o envolvimento e a cooperação no ambiente ao vivo. M
organizacionais
Gerenciamento de problemas Detectar problemas de forma proativa introduzindo falhas aleatórias e procurando possíveis falhas em serviços/componentes. Os M
dados coletados das ferramentas de engenharia do caos podem ajudar a identificar problemas subjacentes que exigem
investigação e correção.
Gerenciamento de CMDBs e repositórios de código devem ter alta disponibilidade e informações precisas (alinhadas com os objetivos do ponto de M
configuração de serviço recuperação definidos pelo gerenciamento de continuidade de serviço) para ajudar a organização a se recuperar rapidamente de
interrupções.
Projeto de serviço Os princípios de teste de engenharia de caos podem ajudar os arquitetos a projetar sistemas mais resilientes e melhorar a M
experiência do usuário.
Balcão de atendimento A equipe de service desk deve estar informada sobre o teste e preparada para gerenciar incidentes sem impactar os usuários. M
Validação e teste de serviço Os princípios de teste de engenharia de caos podem ajudar a avaliar a confiabilidade do serviço. Os arquitetos devem se concentrar na interrupção M
do serviço.
Gerenciamento de riscos Certos tipos de riscos organizacionais podem ser mitigados usando ferramentas e métodos de engenharia do caos para eu
aumentar a resiliência e a robustez organizacional.
A história da ITIL: engenharia do caos

Radhika: Precisávamos testar a resiliência do aplicativo. Por exemplo, o que aconteceria se a
funcionalidade de associação deixasse de funcionar? Os clientes ainda poderiam reservar um carro? A
reserva ainda pode ser atribuída à conta deles retrospectivamente?
Solmaz: Usamos a ferramenta do macaco do caos para entender como o aplicativo funcionaria sob coação.
Isso nos permitiu ver onde o sistema poderia falhar, o que significava que poderíamos alterar o código e a
arquitetura do software para reduzir ou eliminar áreas fracas.
114
4.3.3 Definição de feito
Definição de feito
Uma lista de verificação dos critérios acordados para um produto ou serviço proposto.
A 'definição de pronto' é comumente usada por desenvolvedores de aplicativos que empregam a metodologia Agile Scrum.
A comunidade Scrum define 'pronto' como 'ter produzido incrementos de software potencialmente liberáveis'. Nos círculos de DevOps,
isso foi estendido para 'lançado para produção'. Essa extensão tão necessária ainda é inadequada quando vista de uma perspectiva
de ponta a ponta. Liberar a funcionalidade necessária não é útil se os usuários a usarem mal, interpretarem dados incorretamente, tomarem
decisões abaixo do ideal ou não agirem em boas decisões. Uma função de TI com foco restrito pode não ver a prevenção como sua
responsabilidade, mas como responsabilidade da organização.
Portanto, uma definição mais completa de pronto inclui critérios de operação e uso. A técnica é amplamente aplicável e é frequentemente
encontrada em ambientes HVIT.
Uma definição de pronto descreve os critérios funcionais que contribuem para a utilidade de um produto ou serviço e os critérios não
funcionais que contribuem para sua garantia. Esses critérios não funcionais devem ser definidos e acordados com o responsável pelas
operações. Uma definição de pronto que inclua critérios não funcionais, portanto, contribui para operações resilientes e para o valor
cocriado por meio de uma usabilidade aprimorada, e também para um desenvolvimento mais rápido, pois é necessário menos retrabalho.
Critérios não funcionais especificam a qualidade necessária para as pessoas que irão operar, manter e aprimorar o sistema, e por aqueles
que irão garantir a segurança e a conformidade regulatória. Esses critérios abordam as qualidades necessárias de execução e evolução. Os
critérios funcionais descrevem 'o quê', enquanto os critérios não funcionais descrevem 'como'. Os atributos de qualidade são especificados
na definição de feito, para que as equipes de desenvolvimento e suporte possam considerá-los nas fases iniciais. Para o desenvolvimento,
são restrições de projeto de software.
No desenvolvimento de software Agile, 'pronto' geralmente significa ter incrementos de software que são potencialmente implantáveis.
O DevOps estende essa definição para três categorias: implantado, lançado e disponível para uso. De uma perspectiva de serviço
de cocriação, uma maneira melhor de definir o trabalho como 'feito' é quando os usuários alcançaram os resultados desejados de seus
investimentos. Independentemente da abordagem escolhida, a definição de feito deve ser holística e focada no valor.
Os seguintes aspectos devem ser considerados ao criar uma definição de pronto:
• Os ambientes devem ser preparados para uso A estrutura de integração contínua deve ser verificada e
trabalhando.
• As entregas para suporte devem ser completas Todos os critérios, histórias de usuários e testes devem ter sido aceitos.
• As métricas devem estar disponíveis É importante avaliar cada versão para verificar se ela atende ao usuário
histórias e critérios (mais conhecidos como 'story points' no mundo ágil).
• O código deve ser compreensível, sustentável e pronto para suportar mudanças futuras.
Também é útil considerar a definição de pronto, que descreve quando um item do backlog está pronto para ser trabalhado. A sigla 'INVEST'
representa critérios úteis. Os itens devem ser:
• Independente Autocontido e não dependente de outros itens do backlog.
• Negociável Discussão e ajustes são possíveis.
115
• Valioso Deve haver clareza sobre como as partes interessadas se beneficiariam.
• Estimativa Com escopo suficiente para uma aproximação aceitável.
• Pequeno Pequeno o suficiente para estimar e planejar em um cronograma.
• Testável Com critérios de aceitação claros.
Os testes de resiliência verificam se o sistema atende aos critérios não funcionais acordados em diferentes áreas, como
disponibilidade, capacidade, eficiência, manutenibilidade, desempenho, privacidade, confiabilidade, recuperabilidade e segurança.
A Figura 4.19 mostra a contribuição da definição de feito para a cadeia de valor do serviço.
A Tabela 4.16 descreve as práticas para as quais a definição de feito é relevante.
0 1 2 3
Baixo Alto
Plano
Projeto
e transição

Se empenhar
e suporte
Melhorar
Figura 4.19 Mapa de calor da contribuição da definição de feito para a cadeia de valor do serviço
Tabela 4.16 Práticas para as quais a definição de feito é relevante
Prática de gerenciamento ITIL Atividades/recursos associados à definição de feito Impacto
Gerenciamento de disponibilidade Os requisitos detalhados de garantia para o serviço novo ou alterado devem ser negociados e acordados com H
as partes interessadas.
Gerenciamento de capacidade e Uma definição de lista de verificação concluída deve considerar os requisitos de capacidade, previsão de H
desempenho demanda e desempenho para gerenciar as expectativas do negócio e do cliente.
Alterar ativação As atividades de habilitação de mudanças podem ser estruturadas em torno de uma definição de concluído; por H
exemplo, para criar um limite com gerenciamento de liberação ou gerenciamento de implantação.
Melhoria contínua A definição de concluído pode ser usada para definir o escopo e estruturar as atividades de melhoria contínua e H
para verificar se os resultados foram alcançados.
Gerenciamento de implantação As atividades de gerenciamento de implantação podem ser estruturadas em torno de uma definição de H
concluído; por exemplo, para criar um limite com o gerenciamento de liberação. Ao mover versões para
ambientes ativos, as equipes devem verificar se as entregas para suporte estão completas: todos os requisitos,
histórias de usuários e testes devem ser aceitos.
116
Prática de gerenciamento ITIL Atividades/recursos associados à definição de feito Impacto
Gerenciamento de incidentes As atividades de gerenciamento de incidentes podem ser estruturadas em torno de uma definição de concluído; por exemplo, para H
criar um limite com o gerenciamento de problemas.
Gerenciamento de segurança Testes de segurança como vulnerabilidade, penetração ou conformidade com políticas devem ser considerados na definição de H
da informação feito para produtos e serviços resilientes.
Gerenciamento de Projetos As tarefas ou saídas do projeto podem definir critérios de sucesso ou conclusão usando uma definição de abordagem H
concluída.
Gerenciamento de lançamento As atividades de gerenciamento de liberação podem ser estruturadas em torno de uma definição de concluído; por exemplo, para H
criar um limite com habilitação de mudanças ou gerenciamento de implantação. As versões devem ser projetadas para corresponder
às expectativas de negócios, clientes e usuários. É importante medir cada versão para verificar se ela atende às histórias e aos
requisitos do usuário.
Gerenciamento de nível de serviço Uma definição de pronto pode articular ações de serviço para provedores e consumidores e pode ser usada como base para H
monitorar o desempenho real em relação ao desempenho esperado.
Gerenciamento de requisições de serviço As atividades de gerenciamento de requisições de serviço, como registro ou atendimento de requisições, podem ser H
estruturado usando uma definição de abordagem feita.
Validação e teste de serviço As atividades de teste podem ser estruturadas em torno de uma definição de concluído para garantir que vários tipos de testes sejam H
realizados.
Desenvolvimento e gerenciamento de O software pode ser desenvolvido (ou configurado) para atender a uma definição de pronto antes de ser implantado em ambientes H
software ativos, garantindo que o código seja compreensível, sustentável e pronto para suportar mudanças futuras.
Análise de negócio Requisitos funcionais e não funcionais para garantia e utilidade devem ser capturados para atender às necessidades e M
expectativas dos clientes.
Projeto de serviço A definição de pronto deve ser centrada no cliente, a fim de tornar os métodos de design mais fáceis de adotar e garantir que os M
serviços sejam sustentáveis e econômicos.
Gerenciamento do Quando a nova funcionalidade, produto ou serviço for lançado, o catálogo de serviços deverá ser atualizado. eu
catálogo de serviços
Balcão de atendimento Os atributos de qualidade são especificados na definição de feito para que as equipes de desenvolvimento e suporte eu
possam considerá-los nas fases iniciais.
A história da ITIL: Definição de feito

Su: A equipe de entrega do aplicativo inclui pessoas de vários departamentos da Axle Car Hire.
A definição tradicional de pronto, quando o desenvolvedor entrega o código de trabalho, não é a mais
eficiente ou precisa. Queremos garantir a resiliência, garantia, capacidade de manutenção, utilidade e
usabilidade do aplicativo. Para nós, 'feito' significa:
• os ambientes de produção e teste estão prontos para uso

• a estrutura de integração contínua está preparada
• as histórias de usuários e os testes foram reconhecidos
• as medições e métricas foram aceitas e podem ser testadas
• o software é legível, utilizável e adaptável.
117
4.3.4 Controle de versão
Definição: controle de versão
A gestão administrativa de fontes e artefatos de sistemas de informação, produtos e serviços.
O controle de versão é de particular relevância para o HVIT, porque uma forte correlação foi estabelecida entre um bom controle de
versão e alto desempenho de TI: ele fornece um tempo de mudança mais rápido, implantação mais frequente e um tempo médio
mais rápido para restaurar o serviço.
O controle de versão rastreia quais versões de fontes e artefatos existem em quais ambientes. A prática comum de armazenar
código-fonte de software em um sistema de controle de versão pode ser expandida para incluir quase todos os outros componentes
significativos de um sistema, produto ou serviço de TI, como:
• scripts para criar e configurar infraestrutura para cada ambiente, incluindo desenvolvimento, teste,
e produção
• critérios de aceitação, casos de teste e testes em si
• bibliotecas, módulos e componentes externos e internos
• informações sobre interdependências
• scripts e arquivos de configuração para pipelines de implantação
• scripts para tarefas operacionais, como operações recorrentes
• documentação, incluindo decisões de arquitetura
• artefatos necessários para construir e executar o sistema
• contratos, acordos e assim por diante.
Portanto, o controle de versão se aplica não apenas aos componentes de serviço (desenvolvidos/projetados e gerenciados na
atividade de obtenção/construção da cadeia de valor), mas também no nível de serviços. O controle de versão adequado permite a
coleta de informações valiosas sobre os estados atuais e anteriores de cada componente necessário para um produto ou serviço.
Essas informações incluem o estado inicial, as alterações, a hora e a data da alteração, a pessoa que fez a alteração e qualquer
informação adicional de esclarecimento e suporte. Os benefícios do controle de versão incluem:
• O controle de versão suporta a infraestrutura como técnica de código (consulte a seção 4.2.1).
• A aplicação do controle de versão a fontes e artefatos está relacionada a um lead time de mudança mais rápido, mais frequente
implantação e um tempo médio mais rápido para restaurar o serviço.
• Os testes automatizados que são suportados pelo controle de versão se correlacionam com um lead time mais rápido para mudança.
• O controle de versão é um pré-requisito para entrega contínua, que se correlaciona com implantações mais frequentes.
O controle de versão, portanto, contribui para operações resilientes e desenvolvimento rápido. Também pode ser considerado um
facilitador para a arquitetura evolutiva: uma prática em que as decisões arquitetônicas não são restritivas, mas sim possibilitam a
evolução e melhoria contínua de produtos e serviços sem redesenhar e desenvolver soluções anteriores.
A Figura 4.20 mostra a contribuição do controle de versão para a cadeia de valor do serviço.
A Tabela 4.17 descreve as práticas para as quais o controle de versão é relevante.
118
0 1 2 3
Baixo Alto
Plano
Projeto
e transição

Se empenhar
e suporte
Melhorar
Figura 4.20 Mapa de calor da contribuição do controle de versão para a cadeia de valor do serviço
Tabela 4.17 Práticas para as quais o controle de versão é relevante
Prática de gerenciamento ITIL Atividades/recursos associados ao controle de versão Impacto
Gerenciamento de implantação Usando repositórios controlados por versão para implantar componentes de serviço novos ou alterados ou retornar a H
uma versão anterior.
Gerenciamento de Abordar ou encerrar os riscos de segurança da informação sinalizando versões vulneráveis de componentes H
segurança da informação de serviço.
Gerenciamento de infraestrutura e Componentes de infraestrutura, definições de configuração e componentes de infraestrutura virtual e física podem ser H
plataforma formalmente armazenados e gerenciados usando um repositório controlado por versão.
Gerenciamento de Os CMDBs podem ser federados, aproveitando repositórios de código controlados por versão, arquivos de configuração de H
configuração de serviço infraestrutura como código e até mesmo um armazenamento de dispositivos físicos e outros hardwares. Os check-ins devem
ocorrer várias vezes ao dia e as especificações do ambiente devem ser gerenciadas e controladas por versão.
Desenvolvimento e gerenciamento O código e até mesmo as definições de configuração de outros componentes de software podem ser gerenciados H
de software formalmente usando um repositório controlado por versão para abrigar as saídas do trabalho de desenvolvimento e
gerenciamento de software.
Melhoria contínua Criar uma linha de base do ambiente atual e atualizar a linha de base assim que as melhorias forem feitas. M
Gerenciamento de incidentes Usar um repositório controlado por versão de componentes de software ou hardware para resolver um incidente. M
Gestão do conhecimento Atualizando repositórios de conhecimento e comunicando informações quando as versões dos componentes de serviço M
mudam.
Gerenciamento de Compreender o impacto de novas versões de componentes de serviço; e, se viável, propagá-los em planos M
continuidade de serviço de continuidade de serviço e recuperação de desastres.
Gerenciamento de solicitações de serviço Usando um repositório controlado por versão de componentes de software ou hardware para M
atender aos pedidos.
119
A história da ITIL: controle de versão
Marco: Praticamos integração contínua e entrega contínua. Utilizamos o controle de versão para manter
sistematicamente um registro de cada iteração do aplicativo que lançamos. Se uma versão for instável, podemos
restaurar rapidamente o serviço retornando-o à versão estável anterior.
4.3.5 AIOps
Definição: AIOps
A aplicação de aprendizado de máquina e big data às operações de TI para receber insights contínuos que fornecem
correções e melhorias contínuas por meio da automação. Também conhecido como 'inteligência artificial para operações
de TI' ou 'operações de TI algorítmicas'.
AIOps visa trazer a IA para as operações de TI, abordando os desafios colocados pelas tendências modernas na evolução
contínua da infraestrutura, como o crescimento de sistemas definidos por software. As implicações dessas novas tecnologias,
como o aumento na taxa de reconfiguração e remodelação da infraestrutura, exigem tecnologias de gerenciamento mais
automatizadas e dinâmicas, que podem ter um impacto significativo nos serviços digitais de uma organização.
As plataformas AIOps são usadas para aprimorar e substituir parcialmente muitas funções primárias de operações de TI,
como monitoramento de disponibilidade e desempenho, reconhecimento de falhas, análise preditiva e correlação e análise de eventos.
AIOps aproveita plataformas de dados e aprendizado de máquina, coletando dados observacionais (por exemplo, eventos,
arquivos de log, métricas operacionais) e dados de engajamento (por exemplo, solicitações de clientes e tíquetes de service
desk) e extraindo insights aplicando processamento cognitivo ou algorítmico a esses dados .
Esses insights podem ser usados para gerar alguns ou todos os resultados comuns, como:
• Detecção e previsão de problemas Ajudando a organização de serviços a responder mais rapidamente a incidentes.
• Manutenção e ajuste proativos do sistema Reduzindo o esforço humano e possíveis erros.
• Análise de limite Permitindo uma imagem mais precisa da faixa normal de operação de um sistema.
A aplicação do AIOps depende muito da disponibilidade dos dados a serem analisados e se os dados se prestam à análise, o que
pode não acontecer se forem de natureza extremamente complexa e fraca correlação entre sintomas, causas e efeitos.
Algumas organizações também começaram a usar AIOps além das operações de TI, para fornecer aos gerentes de negócios
insights em tempo real sobre o impacto da TI nos negócios. Isso os mantém informados e permite que tomem decisões com base
em dados relevantes em tempo real.
A Figura 4.21 mostra a contribuição dos AIOps para a cadeia de valor do serviço.
A Tabela 4.18 descreve as práticas para as quais AIOps é relevante.
120
0 1 2 3
Baixo Alto
Plano
Projeto
e transição

Se empenhar
e suporte
Melhorar
Figura 4.21 Mapa de calor da contribuição de AIOps para a cadeia de valor do serviço
Tabela 4.18 Práticas para as quais AIOps é relevante

Prática de gerenciamento ITIL Atividades/recursos associados a AIOps Impacto
Gerenciamento de capacidade e AIOps fornece recursos para identificar padrões e anomalias, determinar a capacidade e utilização de ativos e planejar a H
desempenho capacidade de produtos ou serviços futuros.
Gerenciamento de incidentes Os dados de gerenciamento de incidentes podem se beneficiar dos recursos altamente automatizados fornecidos pelas H
ferramentas AIOps que aumentam o trabalho manual.
Resolver incidentes correlacionados com dados contextuais pré-analisados mesclados de diferentes sistemas.
Gerenciamento de infraestrutura e As ferramentas de AIOps podem automatizar grande parte do gerenciamento diário de infraestrutura e recursos de H
plataforma plataforma.
Monitoramento e As ferramentas AIOps podem ajudar a correlacionar vastos conjuntos de dados de várias ferramentas de monitoramento. H
gerenciamento de eventos Eles criam uma melhor compreensão do ambiente de TI.
O AIOps permite a cocriação de valor por meio de um conjunto integrado de métricas de negócios e operacionais,
reduzindo assim a frequência de eventos ou incidentes operacionais porque são previstos e evitados.
O AIOps ajuda a otimizar a TI e reduzir os custos de TI substituindo ferramentas de monitoramento de TI focadas em silo e
monitorando a integridade e o desempenho de aplicativos de todas as camadas em fluxos de valor.
Alterar ativação AIOPs suporta a visualização de detalhes de dependência em cada nível de dispositivo. M
Gerenciamento de ativos de TI Os AIOps podem coletar informações de inventário dinâmicas com atributos lógicos e físicos. M
Medição e relatórios AIOps fornece dados para métricas para avaliar o desempenho e a conformidade regulatória. Também ajuda a automatizar M
a tarefa de geração de relatórios.
Gerenciamento de problemas As informações das ferramentas AIOps podem ajudar na identificação e investigação de problemas e erros e na M
automatização e monitoramento da aplicação de soluções alternativas.
Eles também podem ajudar na detecção proativa de problemas com base em dados pré-processados e mesclados.
Gerenciamento de Os dados de AIOps podem ser usados para detectar alterações em itens de configuração, ajudando a identificar M
configuração de serviço alterações não autorizadas.
A tabela continua
121
Tabela 4.18 continuação
Prática de gerenciamento ITIL Atividades/recursos associados a AIOps As Impacto
Balcão de atendimento informações das ferramentas AIOps podem apoiar o envolvimento com partes interessadas externas. AIOps M
ajuda as organizações a planejar proativamente, identificando problemas e seus impactos nos negócios antes
que eles ocorram. AIOps também permite a triagem informada de consultas de usuários com base em dados
mesclados e tendências identificadas.
Gestão da força de As organizações que implementam silos de divisão de AIOps em suas equipes de TI permitem que a M
trabalho e talento equipe menos experiente seja mais produtiva, desenvolvendo habilidades e eficiências.
Gestão do conhecimento A combinação de conhecimento de processos de TI, operações, resultados de desempenho e algoritmos de eu
processamento de dados suporta funções críticas de negócios.
A história da ITIL: AIOps

Radhika: Milhares de clientes usam o aplicativo e alugam nossos veículos. Essas transações geram uma enorme
quantidade de dados, que é uma rica fonte de informações sobre a demanda do cliente.
Su: Criamos scripts para analisar os dados, encontrar padrões de uso e otimizar a infraestrutura do serviço. Por exemplo,
se os dados sugerem que os usuários de carros elétricos estão chegando ao fim da carga da bateria, os scripts automaticamente
destacam uma dica explicando como recarregar a bateria, com um mapa do ponto de recarga mais próximo.
4.3.6 Operações de bate-papo
O ChatOps é um modelo no qual pessoas, ferramentas, processos e automação estão conectados em um fluxo transparente. Esse modelo ajuda a
controlar pipelines e colaboração. É uma integração perfeita de comunicações instantâneas com execução operacional: um movimento emergente que
promove a integração de várias equipes, ferramentas e plataformas de DevOps. O desenvolvimento é impulsionado ao trazer ferramentas e plataformas
para as conversas. Quando os bots são membros da equipe, é possível enviar solicitações a eles e obter respostas instantâneas.
O ChatOps permite a comunicação colaborativa entre humanos e ferramentas, reduzindo o tempo de resposta a incidentes, eliminando solicitações
repetitivas de informações e automatizando algumas ações regulares de operações de TI.
Os elementos do ChatOps incluem:
• Plataforma de bate-papo O serviço que conecta as partes interessadas, as equipes e os sistemas em que trabalham.
• Bots O núcleo do modelo ChatOps. Os bots existem e funcionam entre a ferramenta de colaboração e as ferramentas de DevOps.
Eles recebem solicitações de membros da equipe e, em seguida, recuperam informações dos sistemas integrados executando scripts.
• Serviços de integração e automação Os elementos de terceiros no ChatOps; por exemplo, para rastreamento de problemas: sistemas de controle de
versão, infraestrutura como código, servidores de integração contínua ou ferramentas de monitoramento.
Este modelo está se tornando cada vez mais popular. As organizações estão conectando suas plataformas de chat aos seus sistemas de compilação
para receber notificações e executar e consultar processos em seus servidores de integração contínua. O mesmo modelo pode ser aplicado às equipes
de garantia de qualidade. O fluxo de trabalho do ChatOps considera:
• trabalho necessário
• trabalho acontecendo
• trabalho realizado.
122
Esse modelo promove feedback, melhora a comunicação e o treinamento cruzado e aprimora a colaboração da equipe.
Enquanto 'conversam', as pessoas colaboram e inovam, impulsionando o progresso. O ChatOps humaniza o trabalho capturando
conhecimento e identificando requisitos para entregar serviços conforme planejado ou esperado.
Esse tipo de ferramenta destacou a necessidade de colaboração instantânea entre ferramentas, equipes de operação e ferramentas de
mensagens. O ChatOps é a evolução dos chats tradicionais, pois permite que os sistemas participem da conversa.
Por exemplo, DevOps ou ferramentas de gerenciamento de TI e serviços podem notificar os grupos de suporte sobre um incidente ou evento.15
A Figura 4.22 mostra a contribuição do ChatOps para a cadeia de valor do serviço.
A Tabela 4.19 descreve as práticas para as quais o ChatOps é relevante.
0 1 2 3
Baixo Alto
Plano
Projeto
e transição

Se empenhar
e suporte
Melhorar
Figura 4.22 Mapa de calor da contribuição do ChatOps para a cadeia de valor do serviço
Tabela 4.19 Práticas para as quais o ChatOps é relevante
Prática de gerenciamento de ITIL Atividades/recursos associados ao ChatOps Impacto
Balcão de atendimento Comunicação e coordenação com os usuários para melhor gerenciar incidentes e solicitações. H
Alterar ativação Comunicação e coordenação entre todas as equipes envolvidas no gerenciamento de mudanças em serviços e M
componentes de serviço. Algumas ferramentas de ChatOps podem ser integradas a outras ferramentas de
gerenciamento de serviços e TI. O ChatOps fornece um canal de comunicação com usuários e membros da equipe
sobre serviços novos ou alterados, humanizando assim a forma de trabalhar.
Melhoria contínua Atingir metas de iniciativas de melhoria contínua para melhorar a comunicação e coordenação entre as equipes. M
Gerenciamento de implantação Comunicação e coordenação entre todas as equipes envolvidas na implantação de componentes de serviço novos ou M
alterados. Algumas ferramentas do ChatOps podem ser integradas às ferramentas de implantação.
Gerenciamento de incidentes Comunicação e coordenação entre as partes interessadas externas e várias equipes envolvidas nas atividades de M
gerenciamento de incidentes. Algumas ferramentas de ChatOps podem ser integradas a outras ferramentas de
gerenciamento de serviços e TI. O ChatOps auxilia as equipes de TI nas atividades de suporte, como registro, análise
e diagnóstico, reduzindo assim os tempos de resposta e eliminando tarefas repetitivas.
A tabela continua
123
Tabela 4.19 continuação
Prática de gerenciamento de ITIL Atividades/recursos associados ao ChatOps Impacto
Gestão do conhecimento Procurando por conhecimento não estruturado em logs de bate-papo. M
Capturar conhecimento e identificar requisitos para entregar serviços conforme planejado ou esperado.
Coleta de feedback para apoiar a melhoria contínua.
Gerenciamento de problemas Executar análises de causa raiz e post-mortems. M
Gerenciamento de lançamento Comunicação e coordenação entre todas as equipes envolvidas no gerenciamento de mudanças nos serviços. M
Gerenciamento de riscos Armazenar dados e informações em um formato pesquisável. eu
4.3.7 Engenharia de confiabilidade do local
Definição: Engenharia de confiabilidade do site
Uma disciplina que incorpora aspectos de engenharia de software e os aplica a problemas de infraestrutura e operações com o
objetivo de criar sistemas de software ultraescaláveis e altamente confiáveis.
Como as organizações altamente habilitadas digitalmente exigem operações altamente resilientes, a engenharia de confiabilidade do site
(SRE) é particularmente relevante para o HVIT.
O SRE aplica uma mentalidade de desenvolvimento de software às operações de TI e ajuda a alinhar o desenvolvimento e as operações.
As equipes de SRE dividem seu tempo entre executar operações de TI, treinar equipes de operações de TI e desenvolver software que
aumenta a resiliência e o desempenho dos sistemas de TI. Eles tendem a gastar menos da metade de seu tempo em labuta (caso contrário,
isso indica um sistema problemático).
A labuta é definida16 como trabalho que é:
• Manual Requer tempo prático de humanos.
• Repetitivo Está sendo feito repetidamente.
• Automatizável Pode ser alcançado por uma máquina porque não requer julgamento humano específico.
• Tático É orientado a interrupções e reativo, em vez de orientado a estratégias e proativo.
• Desprovido de valor duradouro Não melhora permanentemente o serviço.
• Dimensionamento linear É dimensionado proporcionalmente ao tamanho do serviço, volume de tráfego ou contagem de usuários.
O SRE é baseado na experiência que sugere que os sistemas são complexos e, portanto, falharão. O esforço é, portanto, equilibrado entre
prevenir falhas e reduzir os impactos de falhas inevitáveis, como projetar sistemas para degradar gradualmente em vez de falhar abruptamente.
O fracasso é visto como uma oportunidade de aprender, reconhecendo que as pessoas são o elemento adaptável de sistemas complexos e
que sua experiência está mudando tanto quanto as outras partes do sistema.
O aprendizado com as falhas não está focado na identificação de uma causa raiz, pois em sistemas complexos isso não é eficaz ou
mesmo possível (consulte a seção 3.2.3.1). Em vez disso, as falhas são usadas para melhorar o conhecimento coletivo da equipe. Eles
ajudam as pessoas a calibrar continuamente seus modelos mentais, para que reconheçam os perigos com mais facilidade e ajam para
manter o sistema dentro dos limites do desempenho aceitável. Os praticantes avaliam quando aplicar uma correção padrão e quando a
improvisação é necessária. Eles nunca têm certeza das consequências de suas ações e aprendem com o feedback sobre como o desempenho
do sistema muda de acordo com suas ações. Como a equipe deve assumir riscos, é crucial que não faça parte de uma cultura de culpa. Embora
124
os algoritmos têm seu lugar, no aprendizado de máquina, por exemplo, as heurísticas são mais eficazes para lidar com sistemas
complexos, então o julgamento humano é crucial. Isso requer inteligência, experiência e motivação para agir; e um local de trabalho que
encoraje o comportamento desejado.
No gerenciamento de disponibilidade, é importante equilibrar a prevenção de interrupções e a resolução de incidentes. As

métricas de disponibilidade de chave correspondentes são MTBF e MTRS. Quanto mais complexo o sistema, mais falhas são inevitáveis,
o que significa que o foco deve mudar da prevenção de falhas para a restauração rápida do serviço. O equilíbrio correto varia de serviço
para serviço, dependendo dos requisitos de garantia do serviço e das características do sistema subjacente. Em ambientes HVIT, os
sistemas geralmente serão mais complexos e, portanto, será mais eficaz focar na redução do MTRS do que no aumento do MTBF.
Pode ser um desafio equilibrar o investimento em novos recursos e na confiabilidade do serviço. Um orçamento de erro é uma ferramenta
poderosa de SRE que ajuda nessa área. Mudanças tendem a causar incidentes no sistema. O trabalho de desenvolvimento de recursos e
o trabalho de desenvolvimento de estabilidade precisam ser equilibrados. Um orçamento de erro é um mecanismo de controle que aloca
capacidade adequada ao trabalho de desenvolvimento para estabilidade, garantindo o equilíbrio certo. Quando um serviço está próximo de
seu orçamento de erro, a equipe do produto deve se concentrar em melhorias em vez de novos recursos.
Um orçamento de erro é expresso como 100 por cento menos o objetivo de nível de serviço (SLO) do serviço. Um serviço SLO de 99,9%
tem um orçamento de erro de 0,1%. Este montante deve ser gasto na melhoria da estabilidade. Os orçamentos de erro permitem que as
equipes se regulem dentro das políticas, com consequências se os orçamentos de erro forem excedidos.
É importante que os SLOs sejam expressos em termos que afetem a experiência do consumidor do serviço, em vez de serem KPIs
internos do sistema.
As melhorias que o SRE traz para disponibilidade, latência e desempenho contribuem para operações resilientes.
A Figura 4.23 mostra a contribuição do SRE para a cadeia de valor do serviço.
A Tabela 4.20 descreve as práticas para as quais o SRE é relevante.
0 1 2 3
Baixo Alto
Plano
Projeto
e transição

Se empenhar
e suporte
Melhorar
Figura 4.23 Mapa de calor da contribuição do SRE para a cadeia de valor do serviço
125
Tabela 4.20 Práticas para as quais o SRE é relevante
Prática de gerenciamento ITIL Atividades/recursos associados ao SRE Impacto
Gerenciamento de disponibilidade Usando técnicas e ferramentas de SRE para melhorar a visibilidade de um sistema, a fim de avaliar a integridade do H
serviço e diagnosticar problemas.
Acompanhar as métricas 'técnicas' de MTBF e (mais importante) MTRS, como minutos de indisponibilidade do usuário,
número de transações perdidas, perda de valor comercial e satisfação do usuário.
Usando orçamentos de erro para equilibrar a confiabilidade e a inovação do serviço.
Gerenciamento de capacidade e Usando técnicas e ferramentas de SRE para melhorar a visibilidade de um sistema, a fim de avaliar a integridade do H
desempenho serviço e diagnosticar problemas.
Os sistemas de monitoramento e SLOs definidos devem ser contabilizados e medidos.
Melhorar o monitoramento para entender melhor o sistema quando as coisas dão errado.
Alterar ativação Usando técnicas e ferramentas de SRE para permitir alterações nos componentes de serviço e a reversão de H
alterações com falha.
Gerenciamento de incidentes Usando técnicas e ferramentas de SRE para gerenciar incidentes nas camadas de infraestrutura ou plataforma. H
Gerenciamento de infraestrutura e Usando técnicas e ferramentas de SRE para ajudar a arquitetar e projetar recursos de infraestrutura e plataforma para H
plataforma atender às necessidades da organização.
Monitoramento e Usando técnicas e ferramentas de SRE para melhorar a visibilidade de um sistema, a fim de avaliar a integridade do H
gerenciamento de eventos serviço e diagnosticar problemas.
Gerenciamento de problemas Os dados das ferramentas SRE podem ajudar a identificar problemas, garantindo que as soluções alternativas sejam H
aplicadas rapidamente por meio do uso da automação.
A automatização dos processos de TI melhora a resiliência e reduz a labuta.
Uso de post-mortems.
Projeto de serviço A colaboração do SRE durante a fase de projeto pode evitar que vários problemas ou incidentes ocorram posteriormente na H
produção. Embora as decisões de projeto possam ser revertidas ou retificadas posteriormente no ciclo de vida do
desenvolvimento, essas mudanças têm um alto custo em termos de esforço e complexidade.
Desenvolvimento e gerenciamento Fornecer requisitos às equipes de SRE e atuar no feedback. H
de software
Gerenciamento de implantação O processo de implantação deve estar alinhado com o processo de risco descrito no design de serviço. M
Gestão de mudanças Uma equipe de SRE tem a responsabilidade central de preparar suas equipes para uma inovação rápida. M
organizacionais
Gerenciamento de lançamento Com o SRE, as técnicas utilizadas para liberação de software são aplicadas à infraestrutura digitalizada. M
Gerenciamento de Com o SRE, a descoberta automatizada e o controle de versão podem ser aplicados a componentes de infraestrutura. M
Validação e teste de serviço Para engenharia de versão no SRE, é recomendável que os destinos de teste de compilação contínuos correspondam M
aos mesmos destinos de teste que controlam o lançamento do projeto.
A história da ITIL: Engenharia de confiabilidade do site
Su: Quanto mais recursos adicionamos ao aplicativo, mais complexo ele se torna e mais provável é que o
código nele falhe. A falha é uma característica inevitável de qualquer plataforma de software. A maneira como
o aplicativo falha pode nos ensinar como recalibrá-lo para ser mais resiliente.
Radhika: A engenharia de confiabilidade do local equilibra nossa necessidade de reduzir a ocorrência de falhas
com a necessidade de reparar o serviço após a falha. Quanto mais automatizarmos o trabalho e reduzirmos as
ações manuais repetitivas, mais forte será o código.
126
4.4 Técnicas para valor cocriado

O objetivo de valor cocriado envolve a cocriação de valor a partir de produtos digitais por meio da estreita colaboração do provedor
de serviços e do consumidor do serviço.
O valor cocriado diz respeito ao consumidor de serviço usando os produtos e serviços do provedor de serviços de forma eficaz e
se beneficiando de sua utilidade e garantia. Um retorno sobre os investimentos digitais só é percebido quando a tomada de
decisão, seja feita por pessoas, automação ou IA, é aprimorada por informações derivadas de sistemas de informação
automatizados. Os usuários, portanto, precisam entender os produtos e informações digitais e seus usos em seu contexto. Eles
devem entender a funcionalidade bem o suficiente para usá-la adequadamente e ser capazes de interpretar as informações
corretamente para melhorar a tomada de decisões. Finalmente, as pessoas ou coisas têm que agir de acordo com essas decisões;
só então o valor é realizado.
Exemplo
Alguém usa um aplicativo de carona para obter transporte para o aeroporto. Eles interpretam erroneamente a hora de
chegada indicada como uma garantia em vez de uma estimativa. Eles tomam uma decisão mal informada de esperar. Eles
então têm um passeio nervoso para o aeroporto porque podem perder o voo. Corretamente interpretada, a informação os
levaria a decidir chamar um táxi comum e, portanto, teria valor.
Muitos usuários não usam a funcionalidade dos sistemas de informação de forma eficaz. Eles também interpretam erroneamente o
significado dos dados que um sistema fornece, posteriormente tomam decisões abaixo do ideal e, portanto, não obtêm o retorno
necessário de seu investimento em TI. Não apenas o valor potencial não é realizado, mas a produtividade geralmente diminui
quando ocorrem problemas. Parte da perda resultante é devido a problemas relacionados a operações resilientes e parte é perdida
devido ao uso indevido pelo consumidor do serviço. Isso significa que o suporte ao usuário proativo e funcional deve ser priorizado.
Em um ambiente de negócios, essa forma de suporte é mais adequada para uma função localizada, como um superusuário proativo
que atua como um 'treinador de realização de valor', do que para uma central de serviços distante.
'Valor cocriado' refere-se ao valor para o consumidor de serviço, provedor de serviço e outras partes interessadas. Para o consumidor
do serviço, o valor é o resultado que a saída do serviço facilita. Para o prestador de serviços, dependendo da natureza do
investimento, o valor pode ser expresso em diferentes termos, como receita de produtos e serviços digitais, tráfego do site e redução
de custos e riscos.
Em ambientes HVIT, onde os consumidores de serviços usam produtos e serviços digitais regularmente, as expectativas são
maiores. Os consumidores exigem uma experiência do usuário e do cliente mais intuitivas e responsivas. Quanto melhor os
provedores de serviços entenderem como os consumidores de serviços usam o serviço de TI ou produto digital, mais bem equipados
estarão para apoiá-los. Da mesma forma, quanto mais os consumidores de serviços entenderem como os provedores de serviços
fornecem serviços de TI ou produtos digitais, mais bem equipados estarão para interagir efetivamente com eles. Esses conceitos
ilustram a natureza simbiótica e cocriativa dos serviços.
Embora a experiência digital seja, por definição, algorítmica, os consumidores experientes de serviços digitais esperam que ela
também seja sofisticada e tão bem ajustada às suas circunstâncias quanto possível. Se isso for muito difícil para o serviço digital
realizar, os consumidores do serviço esperam uma experiência física/analógica/humana sofisticada com a equipe do provedor de
serviços. Onde a experiência digital depende de algoritmos avançados, a experiência humana depende de heurísticas avançadas
que são necessárias para lidar com situações imprevisíveis. Essas interações de serviço são interações sociais, e um serviço pode
ser arruinado por pequenos detalhes na interação humana.
Provedores de serviços e consumidores experientes reconhecem as restrições contextuais e a natureza humana do
127
outra parte. Isso resulta na experiência mútua de que o possível foi realizado, com respeito mútuo pela posição de cada um.
A cocriação não é apenas sobre a interação do serviço, onde o valor é realmente realizado. É também sobre o envolvimento do
consumidor no design de serviço e desenvolvimento adicional. A colaboração entre um proprietário do produto Scrum e uma equipe de
desenvolvimento é um bom exemplo da estreita colaboração entre profissionais de TI, pessoas de negócios e, em alguns casos, clientes e
consumidores. Essas equipes autossuficientes orientadas a produtos ou serviços são muito eficazes. Em muitos casos, essa construção só
pode ser realizada quando o sistema de informação é projetado com essa forma de trabalhar em mente, permitindo que várias pequenas
equipes trabalhem em partes relativamente isoladas do sistema maior sem muita necessidade de interação. Isso requer uma arquitetura de
sistema de informação fracamente acoplada (consulte a seção 4.2.2).
Uma técnica importante para apoiar a cocriação de valor é a experiência de serviço.
A história da ITIL: Técnicas para valor cocriado

Henri: Nosso objetivo é co-criar valor para todas as partes interessadas, por isso precisamos garantir que a
interface que oferecemos para reservar carros seja consistente e intuitiva, independentemente de quaisquer mudanças
que estejam acontecendo sob a superfície. O aplicativo deve responder perfeitamente aos requisitos do cliente, para
garantir que os usuários recebam um serviço otimizado que forneça valor ideal.
4.4.1 Experiência de serviço

A 'experiência de serviço' refere-se ao fato de que os consumidores de serviço valorizam um serviço baseado em uma combinação da saída
'técnica' do serviço e como ele é percebido de uma perspectiva humana. Isso significa que os provedores de serviços devem estar cada vez
mais atentos às necessidades dos consumidores e aos recursos que têm à sua disposição para cocriar valor. Os serviços não são recebidos
passivamente: a cocriação de valor exige esforço do consumidor. O provedor de serviços e o consumidor precisam responder dinamicamente
ao comportamento um do outro e acomodar exceções o máximo possível.
Quando, em algumas organizações habilitadas digitalmente, negócios e TI convergem em uma única entidade organizacional, não há mais
entidades de negócios e TI que precisam ser alinhadas. Portanto, também não há mais um relacionamento entre negócios e TI para gerenciar.
'Pessoas de negócios' e 'pessoas de TI' se reportam ao mesmo gerenciamento, têm os mesmos objetivos e geralmente estão fisicamente
localizados. Quando uma forma de trabalho Ágil ou Scrum é adotada, com uma equipe relativamente independente dedicada a um único
produto, o pessoal de negócios e o pessoal de TI estão na mesma equipe, e o proprietário do produto representa os interesses do negócio. O
proprietário do produto geralmente gerencia os relacionamentos com clientes externos e outras partes interessadas. Essas outras partes
interessadas incluem outros proprietários de produtos com quem as sinergias são exploradas; por exemplo, conhecimento e compartilhamento
de recursos.
A análise de dados e o aprendizado de máquina podem contribuir significativamente para o gerenciamento de relacionamentos. A
segurança da informação também é importante, assim como a ética. O gerenciamento da experiência do cliente e as jornadas do cliente
são outros tópicos que merecem consideração.
Para obter mais detalhes sobre relacionamentos de serviço e experiência de serviço, consulte ITIL® 4: Drive Stakeholder Value.
A Figura 4.24 mostra a contribuição da experiência de serviço para a cadeia de valor do serviço.
A Tabela 4.21 descreve as práticas para as quais a experiência de serviço é relevante.
128
0 1 2 3
Baixo Alto
Plano
Projeto
e transição

Se empenhar
e suporte
Melhorar
Figura 4.24 Mapa de calor da contribuição da experiência de serviço para a cadeia de valor do serviço
Tabela 4.21 Práticas para as quais a experiência de serviço é relevante
Prática de gerenciamento ITIL Atividades/recursos associados à experiência de serviço Impacto
Análise de negócio Compreender as necessidades do usuário e traduzi-las em experiência do cliente ou requisitos de experiência do usuário, H
além dos requisitos tradicionais de utilidade e garantia.
Gerenciamento do Descrevendo serviços e ofertas em termos de aspectos técnicos e experienciais. H
catálogo de serviços
Projeto de serviço Articular as necessidades da experiência do cliente e da experiência do usuário além de uma experiência básica. H
Balcão de atendimento Ser empático e ter inteligência emocional para entender as necessidades experienciais dos usuários. H
Oferecendo aos usuários uma escolha de canais de comunicação.
A experiência de serviço requer habilitadores de tecnologia e informações, como ferramentas de autoatendimento, portais
online, aplicativos móveis, ferramentas de call center e bate-papo.
Usando a satisfação do usuário como um KPI.
Avaliar a experiência do usuário, enquanto escolhe uma ferramenta para comunicação bidirecional com os usuários.
Coleta de dados de experiência de serviço (estimativas aproximadas de usuários satisfeitos/insatisfeitos com o serviço).
Gerenciamento de nível de serviço Promover uma boa compreensão da psicografia do consumidor do serviço e o efeito (emocional) das interações do H
serviço no consumidor.
Desenvolvimento e gerenciamento A experiência de serviço desejada informa o design da interface do usuário. H
de software
Monitoramento e Desenvolvimento e configuração de ferramentas e técnicas para monitorar a experiência de serviço e eventos M
gerenciamento de eventos associados, além de monitoramento técnico e gerenciamento de eventos.
Gestão de relacionamento Ser empático e emocionalmente inteligente para entender as necessidades experienciais dos consumidores. M
Validação e teste de serviço Desenvolvimento e manutenção de testes da experiência de serviço. M
Gestão de fornecedores Engajamento e gestão de fornecedores com base em acordos subjetivos e objetivos. M
129
A história da ITIL: experiência de serviço

Su: Na Axle Car Hire, não há divisão entre o negócio e a TI. A equipe de desenvolvimento colabora para fornecer
uma experiência de serviço que responda aos requisitos do cliente. Usamos dados do aplicativo e dos veículos para
orientar a otimização e automação do serviço. O aplicativo é personalizável, para que o usuário possa otimizar o
serviço de acordo com suas necessidades.
4,5 Técnicas para conformidade garantida

O objetivo de conformidade garantida envolve garantir que a prestação de serviços e o consumo de serviços cumpram as diretrizes
corporativas e regulatórias com relação à governança, risco e conformidade. Além de garantir a conformidade, também é importante
assegurar aos responsáveis que a conformidade foi alcançada.
Embora os requisitos externos possam permanecer os mesmos, pode haver formas alternativas e mais apropriadas para que as
organizações habilitadas digitalmente os cumpram.
A alta velocidade é frequentemente associada à tomada de riscos e, do ponto de vista comercial, esses riscos podem ser necessários.
Paradoxalmente, um dos maiores riscos que uma organização pode correr é não correr riscos suficientes.
No entanto, os riscos devem ser justificados, e existem regras internas e regulamentos externos que as organizações devem cumprir.
Os órgãos de governo devem ter certeza de que suas diretrizes foram seguidas. A conformidade garantida tranquiliza as pessoas que
são responsáveis e afetadas por questões de governança, risco e conformidade, pois se sentem mais confiantes sabendo que a
organização atua dentro dessas restrições.
Em relação à governança, o profissional não governa, mas é governado. Eles operam dentro de uma estrutura de governança e
devem entender as restrições aplicáveis e como agir dentro dessa estrutura. A percepção e o julgamento do praticante influenciam a
forma como eles agem. Quanto mais discernimento eles tiverem e melhores suas habilidades de julgamento, mais o profissional será
capaz de julgar quando pode ser apropriado desviar-se das regras quando os benefícios e riscos associados são justificáveis. Isso requer
que o profissional entenda o pensamento por trás das restrições.
A conformidade garantida pode ser medida pela (falta de) violações de segurança, multas por reguladores, má publicidade, ações
exigidas por auditores internos e externos e o custo das medidas para garantir a conformidade com questões de governança, risco e
conformidade.
As técnicas que podem ser usadas para alcançar a conformidade garantida incluem:
• Kit de ferramentas de defesa de auditoria de DevOps
• DevSecOps
• revisão por pares.
A história da ITIL: Técnicas para conformidade garantida

Henri: Como todos os negócios éticos, a Axle cumpre totalmente as leis e regulamentos. Utilizamos técnicas que
garantem a conformidade porque às vezes a TI progride tão rapidamente que os requisitos de conformidade podem ser
negligenciados ou atrasados. Nossa equipe de governança dedicada é apenas uma das maneiras de ficarmos atentos
às mudanças nos requisitos de conformidade.
130
4.5.1 Kit de ferramentas de defesa de auditoria de DevOps
O DevOps Audit Defense Toolkit17 é uma orientação que aborda a tensão entre TI e auditoria causada por padrões de trabalho
novos e mais fluidos encontrados na comunidade DevOps. Isso ajuda a demonstrar aos auditores que a função de TI entende os
riscos do negócio e os está mitigando adequadamente. O Toolkit sugere técnicas para mitigar riscos e criar uma perspectiva
comum e um entendimento compartilhado entre a função de TI e os auditores. Portanto, contribui para a conformidade garantida.
Ao reduzir a burocracia desnecessária, também contribui para o desenvolvimento rápido.
O DevOps Audit Defense Toolkit é relevante para o HVIT porque alguns dos princípios e técnicas do HVIT parecem contradizer os
requisitos de conformidade convencionais. Normalmente, porém, trata-se de encontrar outras formas de alcançar os resultados
desejados. As regulamentações internas são derivadas de requisitos externos e, muitas vezes, regulamentações internas alternativas
podem ser encontradas. É essencial, no entanto, envolver os auditores neste processo.
A Figura 4.25 mostra a contribuição do DevOps Audit Defense Toolkit para a cadeia de valor do serviço.
A Tabela 4.22 descreve as práticas para as quais o DevOps Audit Defense Toolkit é relevante.
0 1 2 3
Baixo Alto
Plano
Projeto
e transição

Se empenhar
e suporte
Melhorar
Figura 4.25 Mapa de calor da contribuição do DevOps Audit Defense Toolkit para a cadeia de valor do serviço
131
Tabela 4.22 Práticas para as quais o DevOps Audit Defense Toolkit é relevante
Prática de gerenciamento ITIL Atividades/recursos associados ao DevOps Audit Defense Toolkit A auditoria fornece novas Impacto
Melhoria contínua informações ou oportunidades de melhoria que são formalmente registradas, priorizadas e gerenciadas. H
Gerenciamento de Projetar e implementar controles no ciclo de vida do produto para fornecer ampla rastreabilidade e responsabilidade H
segurança da informação conjunta.
Monitoramento e Os data warehouses operacionais que consolidam dados de desempenho e eventos fornecem um rico repositório de H
gerenciamento de eventos informações para auditar a implementação e o desempenho dos controles.
Gerenciamento de Configurações padronizadas para dar suporte aos requisitos de segurança e auditoria. H
Gestão do conhecimento Dar à equipe e a outras partes interessadas importantes acesso à documentação política relevante e relatórios de M
auditoria anteriores.
Gerenciamento de riscos Criando uma abordagem equilibrada e prática entre gerenciamento de riscos corporativos, gerenciamento de riscos técnicos e M
novas formas de trabalho.
Gestão da força de trabalho Treinar a equipe sobre suas obrigações e deveres para garantir o cumprimento de todas as políticas e regulamentos relevantes. M
e talento
Análise de negócio Incorporar descobertas de auditoria e remediação sugerida no backlog do produto. eu
Gestão de estratégia Incorporar auditorias externas ou internas regulares no roteiro de um serviço para fornecer governança independente do serviço. eu
4.5.2 DevSecOps
A maioria das organizações tem uma equipe de segurança da informação dedicada, que realiza avaliações de risco e define
políticas, procedimentos e controles. Em ambientes de alta velocidade, a segurança da informação é integrada o máximo possível
no trabalho diário de desenvolvimento e operações, e transfere a dependência do controle do processo para a verificação de pré-
condições, como experiência e integridade dos funcionários. O papel do oficial de segurança muda de 'policiamento' para permitir
que outros tomem as medidas necessárias.
'DevSecOps' refere-se a essa integração de atividades relacionadas à segurança no trabalho diário de desenvolvimento de
aplicativos e operações de TI. A segurança está incorporada em todo o processo de DevOps e nos quatro pilares de cultura,
automação, métricas e compartilhamento (CAMS ou CALMS com a adição de Lean).
Definição: Integração de funções
Ter uma tarefa propensa a fraude ou erro executada por uma pessoa porque outros controles foram aplicados. Isso
serve como uma alternativa à separação (ou segregação) de funções.
Tradicionalmente, as funções são separadas para reduzir o risco de fraude e erro; por exemplo, o risco de que código não
testado e não autorizado seja implantado em produção. Isso pode, no entanto, levar a atrasos e frustração com a
burocracia percebida. A separação de funções não é um objetivo em si: é um método para atingir um objetivo. Outros meios
estão disponíveis para atingir o mesmo objetivo, para que as funções possam ser integradas mantendo o mesmo nível de
garantia.
A segurança da informação é criticamente dependente do comportamento das pessoas em toda a organização. Funcionários
bem treinados e que seguem as políticas de segurança da informação e outros controles podem ajudar a detectar, prevenir e
corrigir incidentes de segurança. Funcionários mal treinados ou insuficientemente motivados podem ser uma grande
vulnerabilidade.
132
Muitos processos e procedimentos são necessários para dar suporte ao gerenciamento de segurança da informação. Esses incluem:
• um processo de gerenciamento de incidentes de segurança
• um processo de gerenciamento de risco
• um processo de revisão e auditoria de controle
• um processo de gerenciamento de identidade e acesso
• gerenciamento de eventos
• procedimentos para testes de penetração, verificação de vulnerabilidades e assim por diante
• procedimentos para gerenciar alterações relacionadas à segurança, como alterações de configuração de firewall.
Essa maneira integrada de abordar a segurança contribui para a conformidade garantida.
Estudo de caso
Um grande provedor de serviços de streaming de música depende da capacidade de entregar rapidamente. Melhora continuamente para manter
sua posição de liderança. Sua forma de trabalhar, seu modelo de atuação, é baseado na agilidade e na melhoria contínua. Uma mudança iminente
em seu status legal introduz novos requisitos de conformidade, desencadeando uma mudança em seu modelo operacional.
Em particular, seus sistemas financeiros são impactados pelos controles exigidos em relação à segregação de funções e trilhas de auditoria.
Os processos e as ferramentas associadas precisam ser alterados. Isso encontra inicialmente resistência das equipes autônomas, que se
orgulhavam das formas de trabalho que haviam desenvolvido.
Para superar essa resistência, as equipes recebem um desafio e apropriação da solução. As novas regulamentações são apresentadas como
um fato da vida: um resultado natural do crescimento do empreendimento. Como as equipes estão acostumadas a trabalhar com muita
autonomia, elas são confiáveis para descobrir como cumprir sem comprometer o fluxo e a agilidade. Eles recebem ajuda especializada da
equipe de auditoria interna e da equipe de ferramentas de processo.
Cada equipe desenvolve seu próprio fluxo de processo e configuração de ferramenta de processo e interage com as principais partes
interessadas. Embora a diversidade de abordagens seja provavelmente menos eficiente do que uma solução única para todas as equipes,
os benefícios são evidentes. Há um fluxo melhor porque cada equipe segue seu próprio processo específico. E, significativamente, cada equipe
assume total responsabilidade pelo cumprimento dos controles.

Isso cria benefícios sustentáveis.
Os principais aprendizados deste caso são:
• Jogue com os pontos fortes das equipes Neste caso, a responsabilidade foi bem-vinda. Com equipes menos autônomas, outra abordagem
pode ser necessária.
• Concentre-se em regulamentações externas, não em como elas foram traduzidas em políticas e restrições internas. Muitas vezes,
existem formas alternativas de alcançar a mesma conformidade. Isso requer flexibilidade da equipe de auditoria interna.
A Figura 4.26 mostra a contribuição do DevSecOps para a cadeia de valor do serviço.
A Tabela 4.23 descreve as práticas para as quais o DevSecOps é relevante.
133
0 1 2 3
Baixo Alto
Plano
Projeto
e transição

Se empenhar
e suporte
Melhorar
Figura 4.26 Mapa de calor da contribuição do DevSecOps para a cadeia de valor do serviço
Tabela 4.23 Práticas para as quais o DevSecOps é relevante

Prática de gerenciamento ITIL Atividades/recursos associados ao DevSecOps Impacto
Melhoria contínua Melhorias nos controles e políticas de segurança podem fazer parte do aprendizado e feedback incorporados pelas H
equipes de desenvolvimento e operações.
Gerenciamento de Projetar e implementar controles em um ciclo de vida de desenvolvimento para fornecer ampla rastreabilidade H
segurança da informação e responsabilidade conjunta.
Integrar os deveres de segurança da informação no trabalho diário dos profissionais.
Monitoramento e Configurando ferramentas de monitoramento para verificar continuamente ameaças e vulnerabilidades para que H
gerenciamento de eventos possam ser escaladas para as equipes apropriadas.
Alterar ativação Implementar um controle preventivo que requer automaticamente pré-autorização do gerenciamento de M
segurança antes que os desenvolvedores possam fazer certos tipos de edições de dados de produção, incluindo
funções às quais eles têm direitos, com base em determinados critérios definidos.
Gerenciamento de implantação O gerenciamento de segurança fornece orientação sobre gerenciamento de credenciais chave, verificações M
de segurança de pipeline de CD, segurança de contêiner, teste de penetração automatizado e monitoramento
de dados e desempenho.
A gestão da segurança da informação e a gestão de riscos devem ser parte integrante do trabalho diário dos
profissionais.
Gestão do conhecimento Dar à equipe e a outras partes interessadas acesso à documentação política relevante. M
Gerenciamento de riscos Criando uma abordagem equilibrada e prática entre gerenciamento de riscos corporativos, gerenciamento de riscos M
técnicos e novas formas de trabalho.
Identificar e remover dependências de equipes/partes externas ao alterar os serviços de TI, o que pode envolver a
delegação de autoridade de aprovação ao gerente de produto/entrega da equipe.
Investir na automação de processos (ex. CI/CD) com controles definidos e integrados para fazer cumprir os requisitos
de separação de funções. Além disso, empregar software de conformidade de terceiros independente para suspender a
produção de implantações até que as aprovações sejam fornecidas.
134
Prática de gerenciamento ITIL Atividades/recursos associados ao DevSecOps Impacto
Gestão de risco continuada Detalhamento dos requisitos e controles de risco em vigor nos contratos de fornecedores para apoiar a integração M
de funções, respeitando a política de segurança da organização.
Realização de mapeamento de fluxo de valor para identificar e minimizar transferências e aprovações de processos.
Validação e teste de serviço O gerenciamento de dados de teste é um elemento-chave que ajuda a garantir estabilidade contínua, confiabilidade, M
disponibilidade e segurança.
Gestão de estratégia Integrando deveres para equilibrar requisitos regulatórios com velocidade de execução. M
Gestão da força de trabalho Treinar e orientar a equipe e outras partes interessadas relevantes sobre como construir segurança no trabalho M
e talento de desenvolvimento e operações.
Análise de negócio Compreender as políticas de segurança, padrões, riscos, ameaças potenciais e vulnerabilidades em ambientes eu
internos e externos e traduzi-los em requisitos para equipes de desenvolvimento e operações.
Incorporando requisitos de segurança no backlog do produto.
Gerenciamento de infraestrutura O gerenciamento de segurança pode aprimorar o gerenciamento de infraestrutura e plataforma (especialmente eu
e plataforma ao aproveitar a infraestrutura como código) com orientação sobre padrões seguros e treinamento, análises de
privacidade, modelagem de ameaças, gerenciamento de credenciais e segurança de dados.
profissionais.
Desenvolvimento e gerenciamento Aprimorando o desenvolvimento de software com orientação sobre padrões e treinamento de codificação segura, eu
de software análises de privacidade, modelagem de ameaças, análise de código, código-fonte e gerenciamento de credenciais
e segurança de dados.
profissionais.
A história da ITIL: DevSecOps

Henri: A integridade e a segurança dos dados são fundamentais para a forma como as equipes da Axle Car Hire trabalham.
Ao trabalhar rapidamente para fornecer novos recursos de aplicativos em alta cadência, existe o risco de introduzir brechas de
segurança que podem ser exploradas.
Marco: Todos os nossos funcionários são treinados para saber como seu comportamento pode comprometer nossa segurança.
Eles seguem os processos de segurança e podem detectar, prevenir e corrigir incidentes de segurança.
4.5.3 Revisão por pares
Definição: revisão por pares
Um julgamento sobre um trabalho científico ou outro trabalho profissional por outros que trabalham na mesma área. Quando aplicado no
desenvolvimento de software, um produto de trabalho é examinado por seu desenvolvedor e um ou mais colegas para avaliar seu conteúdo
técnico e qualidade. Isso contribui para a conformidade garantida.
135
Ao menos A maioria
formal formal
Ad hoc Passar Par Par Equipe de passo a passo Inspeção

Reveja por aí cheque de mesa programação Reveja
Figura 4.27 Espectro de formalidade de revisão por pares
Com base no valor demonstrado das revisões por pares no setor de engenharia, vários especialistas do setor o identificaram como uma prática
de desenvolvimento muito desejável. A experiência mostrou que os problemas (defeitos) são eliminados mais cedo se um processo de
desenvolvimento incorpora revisões por pares; essas revisões são tão eficazes ou até mais eficazes do que os testes.18
A revisão por pares fornece uma prática de engenharia disciplinada para detectar e corrigir defeitos em artefatos de projeto.
Também foi considerado uma das formas mais eficazes de promover a qualidade e a produtividade dos processos de projeto em engenharia de
software e outras disciplinas de engenharia, incluindo engenharia elétrica, civil, mecânica e proteção contra incêndio.
Os dados coletados durante o processo de revisão por pares são usados para corrigir defeitos e para avaliar e melhorar o próprio processo de
desenvolvimento.
A abordagem de revisão por pares pode consistir em um ou mais dos seguintes:
• inspeção
• revisão da equipe
• passo a passo
• programação em pares
• verificação de mesa de pares
• passar ao redor
• revisão ad hoc.
Essas abordagens são ilustradas na Figura 4.27 em ordem de formalidade. Além disso, as atividades normalmente incluídas em diferentes tipos
de revisões por pares estão descritas na Tabela 4.24 (de Wiegers, 2002; reimpresso com permissão da Pearson Education Inc., NY).
Tabela 4.24 Atividades em diferentes abordagens de revisão por pares
Tipo de revisão Atividades
Planejamento Preparação Reunião Correção Verificação
Inspeção Sim Sim Sim Sim Sim
Revisão da equipe Sim Sim Sim Sim Não
Passo a passo Sim Não Sim Sim Não
Programação em pares Sim Não Contínuo Sim Sim
Verificação da mesa de pares, Não Sim Possivelmente Sim Não

passe ao redor
136
0 1 2 3
Baixo Alto
Plano
Projeto
e transição

Se empenhar
e suporte
Melhorar
Figura 4.28 Mapa de calor da contribuição da revisão por pares para a cadeia de valor do serviço
Revisão ad hoc Não Não Sim Sim Não
Tabela 4.25 Práticas para as quais a revisão por pares é relevante
Prática de gerenciamento ITIL Atividades/recursos associados à revisão por pares Impacto
Gerenciamento de riscos Reduzindo o risco de uma alteração não autorizada ser desenvolvida e lançada em produção. H
Cruzamento entre identificação e avaliação de riscos.
Desenvolvimento e gerenciamento Inspecionando o trabalho de desenvolvimento entre pares para aumentar a qualidade do código para garantir que ele satisfaça H
de software efetivamente a demanda e as expectativas de desempenho.
Alterar ativação Colegas que atuam como autoridades de mudança realizando revisões por pares em mudanças padrão ou de baixo M
risco.
Autorizar algumas mudanças por revisão por pares ou avaliação inicial de solicitações de mudança.
Melhoria contínua Revisar o trabalho feito como parte de iniciativas de melhoria contínua, para ajudar a aumentar a qualidade dos resultados M
alcançados.
Gerenciamento de infraestrutura e Inspecionando a infraestrutura e os componentes da plataforma para aumentar sua qualidade. M
plataforma
Gestão do conhecimento Revisar artigos de conhecimento e documentação semelhante para ajudar a eliminar preconceitos e aumentar a M
qualidade da comunicação em toda a organização.
Gerenciamento de problemas Revendo soluções alternativas e correções propostas para erros para aumentar sua qualidade. M
Gerenciamento de arquitetura Realização de orientações sobre as alterações propostas na arquitetura de tecnologia para garantir que as alterações estejam eu
alinhadas com os planos e roteiros acordados.
A Figura 4.28 mostra a contribuição da revisão por pares para a cadeia de valor do serviço.
A Tabela 4.25 descreve as práticas para as quais a revisão por pares é relevante.
137
A história da ITIL: revisão por pares
Su: Nossa equipe de desenvolvimento de aplicativos trabalha de forma colaborativa e realiza revisões regulares
programadas por pares. Nós nos beneficiamos da expertise e experiência de nossos colegas, que revisam o
trabalho uns dos outros e encontram e corrigem problemas antes que eles cheguem ao ambiente real.
Solmaz: Promovemos uma cultura aberta e isenta de culpas, o que significa que os indivíduos se sentem à
vontade para partilhar o seu trabalho com os seus homólogos. Isso ajuda a construir serviços fortes e
impactantes que criam valor para todas as partes interessadas.
4.6 Resumo
No Capítulo 2, foram descritos cinco objetivos organizacionais importantes que possibilitam a TI de alta velocidade. Para apoiar a
realização desses objetivos, as organizações podem empregar inúmeras técnicas e modelos. Alguns deles foram desenvolvidos
recentemente, enquanto outros foram adaptados de modelos operacionais e abordagens de gestão adotados anteriormente. O Capítulo
4 explorou algumas técnicas populares e importantes.
No capítulo, as técnicas são agrupadas em torno dos objetivos de alta velocidade; no entanto, a maioria deles contribui, até
certo ponto, para a realização de múltiplos objetivos.
As técnicas HVIT são universalmente aplicáveis no contexto de muitas práticas. Para ajudar a adotá-los nas práticas, são fornecidos
mapas de calor de suas contribuições relativas à cadeia de valor do serviço.
Os profissionais são convidados a tratar este capítulo como um conjunto de ferramentas multifuncionais, aplicando as ferramentas
de acordo com o contexto e as tarefas de trabalho que estão sendo executadas. A implementação das técnicas aqui descritas não
deve se tornar um objetivo em si; devem ser sempre tratados como meios para atingir os objetivos da organização. Isso vale para os
demais capítulos desta publicação e para o ITIL em geral: as ferramentas devem ser adotadas e adaptadas para atender às necessidades
da organização.
138
CAPÍTULO 5
CONCLUSÃO
5
Conclusão
A tecnologia digital interrompeu os negócios em muitos setores, introduzindo novas oportunidades e novos desafios.
Produtos, serviços e operações de negócios passaram por mudanças significativas, conhecidas como transformação
digital, e essa mudança requer novas abordagens para o gerenciamento de TI e negócios.
Para atender a esses requisitos, muitos métodos, técnicas e ferramentas foram desenvolvidos. O número e a variedade
deles e a decisão de como melhor usá-los podem apresentar desafios, e nem sempre é fácil selecionar a abordagem apropriada.
Além de mudanças em produtos, serviços e operações, a transformação digital também envolve mudanças culturais e
organizacionais, que vêm com suas próprias dificuldades.
Líderes e profissionais de negócios e TI devem entender o cenário da transformação digital e ser capazes de definir objetivos,
adotar padrões de comportamento eficazes e empregar técnicas apropriadas para obter sucesso.
Esta publicação fornece uma visão geral dos principais conceitos de transformação digital e negócios de alta velocidade e
gerenciamento de TI. Sugere um conjunto de objetivos e padrões comportamentais que ajudarão a transformar um negócio,
permitindo-lhe tirar o máximo proveito da tecnologia digital. Finalmente, descreve uma coleção de técnicas e métodos úteis
que podem apoiar cada um dos objetivos. O ITIL SVS fornece uma estrutura geral que ajudará na aplicação prática da TI de
alta velocidade.
Para tirar o máximo proveito do ITIL® 4: TI de alta velocidade, ele deve ser estudado juntamente com os guias de práticas de
gerenciamento do ITIL, que estão disponíveis on-line e fornecem recomendações práticas detalhadas para todas as 34
práticas. Eles incluem orientação prática que pode ser aplicada no contexto de todas as publicações ITIL 4.
Todas as publicações ITIL são holísticas e focadas em valor. Eles abordam as quatro dimensões do gerenciamento de serviços e
ajudam a gerenciar recursos de uma forma que permite a criação de valor para a organização, seus clientes e outras partes
interessadas.
ITIL® 4: Direct, Plan and Improve fornece orientação sobre como alinhar o gerenciamento de produtos e serviços com os
requisitos de negócios atuais, impulsionando a transformação organizacional bem-sucedida e incorporando a melhoria contínua
na cultura de uma organização em todos os níveis.
ITIL® 4: Drive Stakeholder Value contém orientações sobre como estabelecer, manter e desenvolver relacionamentos de serviço
eficazes. Ele lidera as organizações em uma jornada de serviço em suas funções como provedor de serviço e consumidor de
serviço, ajudando-as a interagir e se comunicar de forma eficaz em cada etapa.
ITIL® 4: Create, Deliver and Support fornece orientação sobre os aspectos culturais e de gerenciamento de equipe do
gerenciamento de produtos e serviços e uma visão geral das várias ferramentas e tecnologias que suportam o gerenciamento
de serviços. Ele demonstra como integrar práticas de gerenciamento em fluxos de valor de ponta a ponta.
140
NOTA FIM:
A HISTÓRIA DA ITIL
Nota final: A história da ITIL

A nova funcionalidade do aplicativo de reservas da Axle provou ser um grande sucesso e mais clientes do que nunca estão
usando o aplicativo para fazer reservas de carros. Ao adotar uma cultura e técnicas que suportam uma maneira de trabalhar
em alta velocidade, a equipe de desenvolvimento conseguiu implementar de forma rápida e eficaz melhorias no aplicativo que
estão criando valor real para a Axle.
O desenvolvimento de outras melhorias no aplicativo ainda está em andamento à medida que os requisitos para novos recursos
são identificados. Após o sucesso do trabalho na nova funcionalidade do aplicativo, Henri e a equipe agora estão analisando
como podem adotar uma abordagem de alta velocidade em outras áreas do negócio para ajudar a Axle a crescer e melhorar
como uma organização digital. As técnicas usadas para o trabalho de desenvolvimento do aplicativo, juntamente com as lições
aprendidas, foram documentadas e compartilhadas com as equipes que trabalham em projetos semelhantes. Uma experiência
tão positiva significa que a Axle está agora pronta para dar o próximo passo em sua jornada de transformação digital.
142
MAIS LONGE
PESQUISAR
Mais pesquisa
Publicações AXELOS
AXELOS (2020) ITIL® 4: Criar, entregar e dar suporte. TSO, Londres.
AXELOS (2020) ITIL® 4: Direcionar, Planejar e Melhorar. TSO, Londres.
AXELOS (2020) ITIL® 4: Impulsione o valor das partes interessadas. TSO, Londres.
AXELOS (2019) ITIL® Foundation: ITIL 4 Edition. TSO, Londres.
AXELOS (2018) Um guia para AgileSHIFT®. TSO, Londres.
AXELOS (2017) Gerenciando Projetos de Sucesso com PRINCE2®. TSO, Londres.
AXELOS (2016) ITIL® Practitioner Guidance. TSO, Londres.
AXELOS (2015) PRINCE2 Agile®. TSO, Londres.
AXELOS (2015) RESILIA®: Melhor Prática de Resiliência Cibernética. TSO, Londres.
Gabinete do Gabinete (2011) Gerenciando Programas de Sucesso. TSO, Londres.
Escritório de Comércio Governamental (2010) Gestão de Risco: Orientação para Profissionais. TSO, Londres.
Escritório de Comércio do Governo (2010) Gestão de Valor. TSO, Londres.
Notas finais
1. AXELOS (2011) ITIL V3 e BiSL: Orientação sólida para alinhamento de TI de negócios de uma perspectiva de negócios: https://
www.axelos.com/case-studies-and-white-papers/itil-and-bisl-sound- orientação para negócios [acessado em 14 de janeiro de 2020]. Este estudo
de caso está relacionado ao ITIL V3, mas os conceitos discutidos permanecem válidos.
2. Westrum, R. (2014) Uma tipologia de culturas organizacionais: www.ncbi.nlm.nih.gov/pmc/articles/PMC1765804/

pdf/v013p0ii22.pdf [acessado em 14 de janeiro de 2020].
3. Derivado de Lumiere, em Johnson, PA (2014) Making Light Work Fairday Books, Sheffield.
4. Dra. Amy Edmondson, Harvard Business School, que cunhou o termo 'segurança psicológica': www.youtube.
com/watch?v=LhoLuui9gX8 [acessado em 14 de janeiro de 2020].
5. Cook, RI (2002) Como sistemas complexos falham. Laboratório de Tecnologias Cognitivas, Universidade de Chicago: https://
www.researchgate.net/publication/228797158_How_complex_systems_fail [acessado em 14 de janeiro de 2020].
6. O termo 'saúde mental' é usado aqui para significar claramente aqueles com uma condição de longo prazo e possivelmente latente que é
capaz de diagnóstico clínico. Isso é para distingui-lo do estresse situacional que qualquer pessoa pode sofrer durante grandes mudanças, mas que
é reduzido uma vez que o aspecto situacional, como o medo de ser demitido, foi gerenciado.
7. As formas heurísticas de trabalho contrastam com as formas algorítmicas de trabalho, onde um conjunto de instruções inequívocas são fornecidas
para a execução de uma tarefa. Algoritmos sempre produzem o resultado 'correto'.
8. Wikipedia, estrutura Cynefin: https://en.wikipedia.org/wiki/Cynefin_framework [acessado em 14 de janeiro de 2020].
9. Inglaterra, RE (2013) Além disso! A Abordagem Padrão+Caso: Veja Resposta de Serviço sob uma Nova Luz.
Plataforma de publicação independente CreateSpace, Califórnia.
144
10. Adaptado de The Toyota Kata Practice Guide de Mike Rother. Licenciado sob a licença não portada Creative Commons Attribution
3.0 de http://www-personal.umich.edu/~mrother/Supporting_Materials.html [acessado em 14 de janeiro de 2020].
11. Wikipedia, loop OODA: https://en.wikipedia.org/wiki/OODA_loop [acessado em 14 de janeiro de 2020].
12. Microsoft, Shift left para tornar os testes rápidos e confiáveis: https://docs.microsoft.com/en-us/azure/devops/learn/
devops-at-microsoft/shift-left-make-testing-fast-reliable [acessado em 14 de janeiro de 2020].
13. Princípios da Engenharia do Caos: http://principlesofchaos.org/ [acessado em 14 de janeiro de 2020].
14. Blog de tecnologia da Netflix, The Netflix Simian Army: https://medium.com/netflix-techblog/the-netflix-simian-army 16e57fbab116
[acessado em 14 de janeiro de 2020].
15. Abdula, M., Averdunk, I., Barcia, R., Brown, K. e Emuchay, N. (2018) The Cloud Adoption Playbook: Proven Strategies for Transforming
Your Organization with the Cloud. John Wiley & Sons, Indianópolis.
16. Beyer, B., Jones, C., Petoff, J. e Murphy, NR (editores) (2016) Site Reliability Engineering: How Google Runs Production Systems. Google
Livros.
17. Kit de ferramentas de defesa de auditoria de DevOps: https://itrevolution.com/devops-audit-defense-toolkit/

18. Garousi, V. (2010) Aplicando revisões por pares no ensino de engenharia de software: um experimento e lições aprendidas. IEEE
Transactions on Education (Volume 53, Edição 2, maio): https://ieeexplore.ieee.org/
documento/5152941 [acessado em 14 de janeiro de 2020].
Outras publicações
Bell, SC e Orzen, MA (2010) Lean IT: habilitando e sustentando sua transformação Lean.
Imprensa de produtividade.
Blackburn, S. (2003) Ética: Uma Introdução Muito Curta. OUP, Oxford.
Inglaterra, R (2013) Além disso! A Abordagem Padrão+Caso: Veja Resposta de Serviço sob uma Nova Luz. Plataforma de publicação
independente CreateSpace, Califórnia.
Gianotten, M. (2017). Empatia digital: quando a tecnologia encontra o toque. Giarte, Amsterdã.
Godin, S. (2018) Isso é marketing: você não pode ser visto até aprender a ver. Portfólio Pinguim.
Humble, J. e Farley, D. (2010) Entrega contínua: lançamentos de software confiáveis por meio de construção, teste e automação de
implantação. Addison Wesley.
Johnson, PA (2014) Making Light Work: Rethinking the Service Organization. Livros de feira. https://fairday.co.uk/product/
making-light-work-rethinking-the-service-organisation-peter-a-johnson/
Liker, J. (2004) The Toyota Way: 14 Princípios de Gestão do Maior Fabricante do Mundo. McGraw-Hill.
Murphy, NR, Beyer, B., Jones, C. e Petoff, J. (2016) Site Reliability Engineering: How Google Runs Production Systems. Mídia
O'Reilly.
Reinertsen, DG (2009) Os Princípios do Fluxo de Desenvolvimento de Produto: Desenvolvimento de Produto Lean de Segunda
Geração. Celeritas.
Ries, E. (2011) A startup enxuta: como a inovação constante cria empresas radicalmente bem-sucedidas.
Portfólio Pinguim.
145
Rother, M. (2009) Toyota Kata: Gerenciando Pessoas para Melhoria, Adaptação e Resultados Superiores.
McGraw-Hill.
Snowden, D. (2011) A estrutura Cynefin. https://cognitive-edge.com/ [acessado em 30 de janeiro de 2020].
Wiegers, K. (2002) Revisões por Pares em Software: Um Guia Prático. Pearson Education, NY.
Williams, B. (1993) Moralidade: Uma Introdução à Ética. Cambridge University Press.
Sites
Cognitive Edge: The Future, Backwards https://cognitive-edge.com/methods/the-future-backwards/ [acessado em
30 de janeiro de 2020].
DeLuccia IV, J., Gallimore, J., Kim, G. e Miller, B. (2015). O kit de ferramentas de defesa de auditoria DevOps. Revolução de TI
https://cdn2.hubspot.net/hubfs/228391/_archive/Corporate/DevOps_Audit_Defense_Toolkit_v1.0.pdf [acessado em 30 de janeiro
de 2020].
Klein, G. (2007) Realizando um Projeto Pré-morte Harvard Business Review setembro de 2007. https://hbr. org/2007/09/
performing-a-project-premortem [acessado em 30 de janeiro de 2020].
The Netflix Simian Army (2011) https://netflixtechblog.com/the-netflix-simian-army-16e57fbab116 [acessado em 30

de janeiro de 2020].
Sigler, E. (2014) O que é ChatOps? https://www.pagerduty.com/blog/what-is-chatops/ [acessado em

30 de janeiro de 2020].
Snowden, DJ e Boone, ME (2007) Estrutura de um líder para a tomada de decisões. Harvard Business Review novembro de 2007
https://hbr.org/2007/11/a-leaders-framework-for-decision-making [acessado em 30 de janeiro de 2020].
Zacarias, D. 20 Técnicas de priorização de produtos: um mapa e uma visita guiada https://foldingburritos.com/product prioritization-
techniques/ [acessado em 30 de janeiro de 2020].
146
RECONHECIMENTOS
Reconhecimentos
A AXELOS Lda agradece a todos os que contribuíram para o desenvolvimento desta orientação e, em particular, gostaria de
agradecer às seguintes pessoas.
Editor principal
Mark Smalley
Mark Smalley, também conhecido como o Paradigmologista de TI, pensa, escreve e fala sobre 'paradigmas' de TI (nossas
perspectivas em mudança sobre TI). Mark é instrutor/consultor na Smalley.IT e instrutor mestre para o Projeto Phoenix da
GamingWorks e simulações de negócios MarsLander. Ele é embaixador global da DevOps Agile Skills Association e contribuiu
para muitos corpos de conhecimento no domínio de gerenciamento de TI.
Equipe de autoria
Akshay Anand
Akshay é embaixadora de produtos na AXELOS, trabalhando no desenvolvimento de novas orientações e pesquisas dentro do
portfólio ITSM. Com experiência nos EUA, Reino Unido e Índia, ele aconselhou clientes da Fortune 100 sobre seus recursos de
ITSM, implementou conjuntos de ferramentas como Remedy e ServiceNow e liderou atividades globais de ITSM na Macmillan
Publishing. Mais recentemente, Akshay se concentrou em reunir equipes de desenvolvimento Agile e profissionais de ITSM para
enfrentar os desafios apresentados pelas tecnologias emergentes. Ele tweeta como @bloreboy.
Dan Ashby
Dan é um especialista em qualidade e testes com experiência em qualidade líder em empresas como eBay, AstraZeneca
e Photobox. Ele é especialista na construção e implementação de qualidade de software e estratégias e equipes de teste, e é um
blogueiro entusiasmado, escritor, podcaster e orador público. Um forte crente na criação de espaços seguros para as pessoas
aprenderem sobre o ofício dos testes, Dan está profundamente envolvido nos encontros e cursos de treinamento do Testing
Essentials em parceria com o Ministry of Testing para ajudar a desenvolver habilidades e conhecimentos de testes práticos que
podem ser aplicados em qualquer contexto .
Ariana Búcio
Ariana é consultora, instrutora, pesquisadora e auditora experiente em ITSM. Ela ajudou várias organizações na
América Latina a adaptar e adotar as melhores práticas de ITSM. Ela escreve sobre ITSM e fala em conferências e webinars.
Ariana contribui como revisora do padrão de certificação SDI. Sua paixão por service desks e melhores práticas é demonstrada
como auditora e consultora líder de SDI, promovendo a criação de valor para a organização e seus clientes.
160
Ana Yasmeen Chong Rosales

Ana é uma treinadora, consultora, palestrante e professora apaixonada na região da América Latina. Sua experiência na
liderança de diversas equipes e projetos a levou a acreditar que inspirar pessoas é a ação mais importante. É CEO da BPGurus,
empresa especializada em consultoria e treinamento em melhores práticas para serviços digitais e ITSM. Sua carreira se concentrou
em ajudar as organizações a adotar soluções integrais em ITSM e e-learning.
Ela é auditora líder do Service Desk Institute e participa de diversos fóruns focados no empoderamento de mulheres
em TI.
James Finister
James é um parceiro da equipe de consultoria Enterprise Agility da TCS, com foco na implementação de lições comuns nos
ecossistemas de TI e de negócios. Ele é um colaborador de muitas fontes de melhores práticas da indústria, incluindo padrões
ISO, é um membro honorário vitalício do itSMF UK e detentor de seu prêmio pelo conjunto da obra.
Reni Friis
Reni tem mais de 20 anos de experiência em ITSM, com foco em fazer o Lean fazer sentido em um contexto de TI.
Reni é um talentoso consultor de gerenciamento de TI, instrutor e palestrante internacional em tópicos como Lean IT, DevOps,
SIAM e liderança. Ela é membro permanente do quadro de conteúdo da Lean IT Association e também contribuiu para o
desenvolvimento e aprimoramento de estruturas para VeriSM, SIAM e DevOps.
Seu estilo é caracterizado pelo humor, energia e ir direto ao ponto (que agrega valor).
Marco Gianotten
Marco é o fundador da boutique de consultoria de pesquisa Giarte. Ele é um orador público, autor de Digital Empathy e iniciador
do movimento Xperience Level Agreement. As jornadas do cliente, os requisitos emocionais e a experiência do usuário serão o
novo normal no ITSM. Ele inspira as organizações a repensar, transformar e simplificar a TI.
Rudolf Greger
Rudolf é um filósofo do design com a missão de melhorar a vida das pessoas. Com 30 anos de experiência, sua vocação
é designer e sua profissão é design thinking coach. Ele co-fundou a GP designpartners, uma consultoria de design industrial da
Europa Central, e fundou o design thinking tank para promover o design thinking.
Rudolf é um sparring de nível C; ele organiza jams de design, escreve sobre design e dá palestras em conferências.
Jon Hall
Jon é um gerente de produto focado em inovação com um extenso histórico na vanguarda de ferramentas e práticas focadas em
ITIL. Ele é bem conhecido na comunidade DevOps por explorar a evolução necessária do gerenciamento de serviços para apoiar e
permitir o sucesso do DevOps por meio de novas formas de trabalho. Ele é um especialista reconhecido e citado em swarming
como uma prática de trabalho transformacional. Seu trabalho foi citado por luminares do DevOps, como Gene Kim, e ele fala
regularmente em eventos de ITSM e DevOps.
161
Ian Jones
Ian é um arquiteto pragmático e consultor de organizações digitais e de TIC que liderou com sucesso muitos modelos
operacionais de TI e projetos de gerenciamento de serviços de TI. Ele trabalhou com várias organizações em todos os
setores da indústria, desde start-ups até empresas com serviços de missão crítica. Sua extensa experiência prática na
integração de práticas de entrega modernas (por exemplo, Agile, DevOps, Lean e ITIL) foi reconhecida por seus colegas com
vários prêmios do setor. Ian vive com sua família em Brisbane, Austrália.
Ola Källgården
Ola é apaixonado por encontrar o equilíbrio certo entre ordem e caos. Ele dobra e torce estruturas, modelos e filosofias para
torná-los mais úteis. Ele tem experiência em funções de TI, como desenvolvedor, analista de negócios, gerente de projeto,
gerente de mudança organizacional e consultor de gestão. Além de orientar e treinar clientes em nome da Oligo Consulting, Ola
também é palestrante e um aclamado e credenciado treinador de ITIL e DevOps.
Allan Kelly
Allan é um reconhecido especialista em processos e gestão de desenvolvimento de software. Como Agile coach, consultor e
conselheiro, ele ajuda equipes e empresas a aprimorar seus processos e melhorar seus produtos digitais. Ele inventou o Value
Poker, os Perfis de Valor de Tempo e as Folhas de Diálogo Retrospectivo. Ele é o autor da carta Dear Customer, The Truth about
IT Projects e livros, incluindo Project Myopia, Continuous Digital, Xanpan e seu mais recente, The Art of Agile Product Ownership.
Seu blog está em https://www.allankellyassociates.co.uk/blog/ e ele twitta como @allankellynet.
Donna Knapp
Donna tem mais de 30 anos de experiência no setor de TI trabalhando como profissional, consultora e educadora.
Ela é gerente de desenvolvimento de currículo da ITSM Academy. Os anos de experiência prática e o amor pelo aprendizado
de Donna fazem dela uma palestrante requisitada sobre questões relacionadas ao ITSM e ao service desk. Donna é autora de
The ITSM Process Design Guide: Developing, Reengineering, and Improving IT Service Management, bem como de dois livros
universitários, A Guide to Service Desk Concepts e A Guide to Customer Service Skills for Service Desk Professional.
Dagfinn Krog
Dagfinn é um profissional de TI com 25 anos de experiência no setor, tendo trabalhado como consultor de infraestrutura,
segurança e gerenciamento de serviços. Atualmente, ele trabalha como especialista em segurança de TI em ambientes de
várias fontes, preenchendo lacunas entre tecnologia, gerenciamento de serviços e risco de negócios. Ele também é um
membro do conselho de longa data da itSMF Noruega.
Jeffrey Liker
Jeffrey é professor emérito de engenharia industrial e de operações na Universidade de Michigan e presidente da Liker Lean
Advisors. Ele é autor do best-seller internacional The Toyota Way: 14 Management Principles from the World's Greatest
Manufacturer e é coautor de nove outros livros sobre a Toyota, incluindo The Toyota Way to Service Excellence, Designing the
Future e The Toyota Way to Lean Leadership. . Seus artigos e livros ganharam 13 Prêmios Shingo de Excelência Operacional.
162
Reconhecimentos
Krikor Maroukian
Krikor é consultor sênior de gerenciamento de serviços modernos da Microsoft® e representante internacional da itSMF Hellas. Ele
também tem experiência em gerenciamento de projetos e gerenciamento de segurança da informação. Ele se concentra em pesquisa
e desenvolvimento de gerenciamento de serviços de alto desempenho na região EMEA. Krikor é pesquisador da Henley Business
School e membro do BoD da British Computer Society (seção helênica). Ele é autor de artigos acadêmicos sobre gerenciamento de
serviços, gerenciamento de projetos e engenharia de processos de negócios orientados a modelos e recebeu o Emerald Literati
Network Award for Excellence em 2017.
Simone Jo Moore
Simone é conhecida como mixologista de gerenciamento de serviços e API humana (interface de programação de aplicativos).
Pessoas conectadas, conhecimento compartilhado, possibilidades descobertas e potencial realizado são seus valores ativos.
Reconhecida líder de pensamento entre os 25 principais do setor, Simone é consultora sênior, instrutora mestre, autora de
cursos, co-apresentadora de podcast e mentora em estruturas como VeriSM, ITIL, DevOps, CASM, KCS e SFIA. Simone
combina isso com recursos humanos, mudança organizacional e formação complementar em saúde para uma profunda
experiência de liderança compartilhada por meio de treinamento, workshops e conferências.
Pasi Nikkanen
A Pasi é apaixonada por impulsionar a felicidade e a produtividade dos funcionários no gerenciamento de serviços. Ele é o diretor
de produtos da HappySignals, apresentador de podcast no HappyToday – The Employee Experience e palestrante regular de
webinars e eventos. Ele trabalhou com serviços internos e terceirização em uma grande empresa nórdica de TI e como designer
de serviços para muitas grandes empresas globais.
Mike Orzen
Mike é considerado um pioneiro do Lean e da tecnologia. Ele é coautor dos livros premiados Lean IT: Enabling and Sustaining
Your Lean Enterprise e da continuação The Lean IT Field Guide. Muitas vezes referido como "o pai do Lean IT", Mike é
reconhecido internacionalmente como um líder de pensamento em Lean, Lean IT e DevOps. Ele recebeu o Prêmio Shingo de
Excelência Operacional, membro do corpo docente do Lean Enterprise Institute e membro, facilitador e avaliador do Shingo
Institute. Mike também é instrutor certificado de Kundalini Yoga e praticante dedicado de yoga e meditação.
Oleg Skrynnik
Oleg é sócio-gerente da Cleverics, tendo trabalhado em TI por mais de 20 anos (principalmente em cargos gerenciais). Tem
experiência na criação e transformação de departamentos de TI em grandes empresas e aplica sua experiência profissional em
projetos de consultoria, compartilhando as lições aprendidas com os participantes de seus treinamentos, masterclasses e
simulações de negócios. Oleg co-fundou a itSMF Rússia e é um orador e autor reconhecido.
Ele ganhou o primeiro prêmio no ITSM in Russia Award em 2014 e 2017 por seus artigos e escreveu DevOps: A Business
Perspective, no qual o exame EXIN DevOps Foundation é baseado.
163
Dave Snowden
Dave é diretor do Cynefin Center, que se concentra na aplicação da ciência natural aos sistemas sociais. Ele é um importante pensador e
praticante nas áreas de sistemas adaptativos complexos e teoria narrativa. Ele tem uma longa carreira que abrange o design de sistemas de
apoio à decisão, gestão geral e estratégica e (nos últimos 20 anos) pesquisa e desenvolvimento. Em 2006, foi diretor do programa de
pesquisa EPSRC (Reino Unido) sobre emergência e, em 2007, foi nomeado para um painel de revisão da NSF (EUA) sobre pesquisa
científica da complexidade. Ele ganhou vários prêmios por seu trabalho e publicações.
A história da ITIL
Katrina Macdermid
Katrina é embaixadora global da ITIL 4, autora e criadora de uma estrutura integrada inovadora, design de serviço ITIL centrado no
ser humano. Ela é uma ITIL Master, com sólida experiência em projetar e implementar modelos operacionais de TI que colocam a
experiência do cliente no centro de todos os processos ITIL. Katrina foi responsável pela implementação bem-sucedida de programas
estratégicos importantes e gerenciamento de serviços integrados em algumas das maiores e mais emblemáticas organizações da Austrália.
Ela é uma conhecida conferencista em design de serviço ITIL centrado no ser humano.
Craig Smith
Craig é poeta e romancista, com três livros em seu nome. Atualmente trabalha como editor-chefe da equipe de conteúdo da AXELOS.
Craig encomendou e editou ITIL Practitioner Guidance, juntamente com ITIL e DevOps: Getting Started and Using Kanban in ITIL
Operations. Craig também co-escreveu ITIL Foundation Exam Tips, o blog mais lido no site AXELOS.
Equipe de arquitetos AXELOS ITIL 4
Akshay Anand Embaixador do produto ITSM
Philip Hearsum Gerente de portfólio ITIL
Roman Jouravlev Gerente de desenvolvimento de portfólio ITIL
Margo Leach Diretor de produto
Heigor Simões de Freitas Gerente de produto ITSM
164
Reconhecimentos
Editores líderes de ITIL 4
Dinara Adyrbayeva Biblioteca prática ITIL 4
David Cannon ITIL® 4: Estratégia Digital e de TI
Erika Flora ITIL® 4: Estratégia Digital e de TI
Lou Hunnebeck ITIL® 4: Direcione, Planeje e Melhore
Christian F. Nissen ITIL® 4: Impulsione o Valor das Partes Interessadas
Barclay Rae ITIL® 4: Criar, entregar e dar suporte
Stuart Rance Exames ITIL 4
Equipe do projeto
David Atkins Gerente de entrega e produção de conteúdo
Rachida Chekaf Chefe de traduções
Sarah Conner Editor de produção
Adrian Crago Graham Chefe de PMO
Ricky Elizabeth Gerente de marca e design
Emily Holbrook Editor de comissionamento: conteúdo suplementar ITIL
James Lord Especialista em Qualificações e Avaliação Sênior
Michael Macgregor Gestor de projeto
Amy Metcalfe Editor de projetos
James Robertson Especialista em Qualificações e Avaliação Sênior
Tom Young Editor de comissionamento: conteúdo principal da ITIL
Contribuintes
Mark Bodman, Mike Fulton, Matthew Helm, Jessica Hinkel, John Kendrick, Caspar Millar, James Monek, Mark Toomey,
Ole Westergaard.
A AXELOS gostaria de agradecer aos seguintes por sua valiosa visão:
Arie van Bennekum, Daniel Billing, Erik van Busschbach, Andrew Campbell, James Cusick, Carmen DeArdo, Rob
England, Robert Falkowitz, Dave Favelle, Dave Hahn, Julia Harrison, Dave van Herpen, Erica Morrison, Shuiji Tomita,
Karel van Zeeland, Sun Zhenpeng.
165
166
ÍNDICE
Índice
UMA sistemas adaptativos complexos 62–
O teste A/B 86–88 63 ambientes complexos 62–65
aceita ambiguidade e incerteza (padrão de sistemas complexos 56–57, 62–63
comportamento chave) 45, 46–47 pensamento de complexidade 62
Características ágeis 18, 20–21 macaco de conformidade 113
AIOps 120–122 conteinerização 93 análise de negócios
trabalho algorítmico 54 contínua 98–101 melhoria contínua xv,

antifragilidade 64 36, 69, 74, 88, 96, 98, 108, 111, 114, 116, 119, 123, 132,
gerenciamento de arquitetura 36, 83, 88, 92, 94, 101, 103, 134, 137 modelo de melhoria contínua 69-72
105, 114, 137 inteligência artificial 49 conformidade aprendizagem contínua 45, 46-47 elevar continuamente a
garantida 16–17, 130–137 provisionamento automático 22 fasquia (padrão de comportamento chave) 45, 46-47
serviços de automação 122 gerenciamento de disponibilidade características contínuas 18, 21– 22 entrega contínua 102
36, 116, 125, 126 implantação contínua 102 integração contínua 101
integração, entrega e implantação contínuas
Padrões de comportamento B
44–45 post-mortems sem culpa 96– (CI/CD) 21–22, 101–103
98 bots 122 automação de construção teste contínuo 103–105 custo
22 análise de negócios 36, 83, 94, do atraso 20, 80 cultura 46–72
jornadas do cliente 27–28
98–101, 111, 117, 129, 132, 135 gerenciamento de informações
de negócios 38–39 compra/manter/venda técnica 80
Estrutura Cynefin 63-64
D
definição de automação de
Capacidade C e gerenciamento de desempenho 36, 83, 114, implantação 115–117 concluída
116, 126 alteram 2–3, 59, 89 alteram a habilitação 36, 22 gerenciamento de implantação 36, 92, 94, 98, 103, 105,
81, 92, 94, 96, 98, 103, 116, 119, 123, 126, 134
design thinking 51–53
108, 116, 121, 123, 126, 134, 137 DevOps 21, 29–32, 54
Kit de ferramentas de defesa de auditoria DevOps 131–132
engenharia do caos 112-114 macaco do caos
112-113 DevSecOps 132–135
ChatOps 49, 122–124 organizações digitais 11
CI/CD (integração, entrega e implantação ciclos de vida de produtos digitais
contínuas) 21–22, 101–103 serviços 26–28 produtos e serviços digitais 25–26

baseados em nuvem 39 valor cocriado 16–17, tecnologia digital 7–10 transformação
22, 127–129 colaborar e promover visibilidade digital 12–15 digitalização 12 digitalização
(princípio orientador) xiv, 39, 47 , 74 comprometem- 7, 12 dimensões do gerenciamento de
se com a aprendizagem contínua (padrão serviços xvi, 37–39 doctor monkey 113
de comportamento chave) 45, 46–47 'feito ' 115-117
168
E Modelo de melhoria contínua ITIL 69–72
educação 48 Princípios orientadores da ITIL xiv, 73–76
inteligência emocional 49 erros Práticas de gerenciamento da ITIL xiv, 35–36
orçamentários 125 ética 47–51 Cadeia de valor do serviço ITIL xiii, 29–32
Sistema de valor de serviço ITIL xii, 24
fatores externos 39-40
F J macaco zelador 113
falhas 49, 64, 124–125

desenvolvimento rápido 16–17, 88–108
K
ciclos de feedback 98–99 foco no valor Kanban 106–108
(princípio orientador) xiv, 47, 73 quatro dimensões do mantê-lo simples e prático (princípio orientador) xiv, 47,
gerenciamento de serviços xvi, 37–39 75
padrões de comportamento chave 44-45, 46-47

G gestão do conhecimento 36, 88, 92, 101, 103, 111, 119, 122, 124,
governança xv, 40 132, 134, 137
princípios orientadores xiv, 73–76

L
H latência macaco 113

hábitos 49 Características magras 18, 19-20
Cultura Lean 66-68
ajudar a realizar o trabalho dos clientes (padrão de
comportamento chave) 45, 46–47 trabalho arquitetura de sistema de informação fracamente acoplada 92–95
heurístico 54, 63 TI de alta velocidade (HVIT)

M
cultura 46-72 gerenciamento
definição 6 40 práticas de gerenciamento xiv,
características principais 18–22 35–36 tempo médio entre falhas (MTBF) 89,
objetivos 16–17 modelo 125 tempo médio para recuperar serviço
operacional 23–24 (MTRS) 89, 125 medição e relatórios 36, 114,
121 microsserviços 93
EU produtos e serviços mínimos viáveis 82–83 monitoramento
IaC (infraestrutura como código) 90–92 e gerenciamento de eventos 36, 83, 114, 121, 126, 129, 132, 134
gerenciamento de incidentes 36, 81, 92, 94, 96, 98, 108, 111,
114, 117, 119, 121, 123, 126 informações 38–39 MTBF (tempo médio entre falhas) 89, 125
MTRS (tempo médio para recuperar serviço) 89, 125
gerenciamento de segurança da informação 36, 92, 94, 98,

103, 105, 111, 117, 119, 132–133, 134 O
pilha de tecnologia de sistema de informação 8–9 Modelos
tecnologia da informação 8–10 pilha de valor de operacionais de loop 71 OODA
tecnologia da informação 9 gerenciamento de 23–24 tecnologia operacional (OT) 10
infraestrutura e plataforma 36, 83, 85, 94, 100, 103, 111, 114, 119, otimizar e automatizar (princípio orientador) xiv, 39, 47,
121, 135, 137 infraestrutura como código (IaC) 90–92 75–76
serviços de integração e automação 122 integração de funções gestão de mudança organizacional 36, 88, 114 cultura
132–133 organizacional 46–72 desenho organizacional 48
TI (tecnologia da informação) 8–10 OT (tecnologia operacional) 10
Gerenciamento de ativos de TI 36, 92, 121 terceirização 14–15, 39

Transformação de TI 13–15
169
P service desk 36, 96, 98, 111, 114, 117, 122, 123, 129 experiência
parceiros 39 em serviço 128–129 gestão financeira de serviço 36, 81, 92, 95

revisão por pares 135– gestão de nível de serviço 36, 94, 96, 114, 117, 129 gestão de
137 valores pessoais 54–55 serviço dimensões xvi, 37–39 propriedade do serviço 84–85
PILÃO 37 gerenciamento de solicitação de serviço 36, 81, 92, 117, 119
gerenciamento de portfólio 36, 81, 83, 85, 86, 88, 100, 108, 111 validação e teste de serviço 36, 83, 88, 92, 98, 103, 105, 114, 117,
testes pós-implantação 22 post-mortems 96–98 práticas 126, 129, 135 cadeia de valor de serviço xiii, 29–32 sistema de
xiv, 35–36 técnicas de priorização 79–81 monitoramento proativo valor de serviço xii, 24 lógica de serviço dominante 22 pensamento
21 gerenciamento de problemas 36, 81, 88, 92, 94, 96, 98, 105, em silo 3
108, 111, 114, 117, 121, 124, 126, 137 processos 39 propriedade
do produto 84–85 equipes baseadas em produtos/serviços 38
progridem iterativamente com feedback (princípio orientador)
xiv , 47, 74 gerenciamento de projetos 36, 81, 83, 85, 96, 98,
100, 108, 111, 117 propósito 47–52 Simian army 112–113
engenharia de confiabilidade do site (SRE) 21, 124–126
desenvolvimento e gerenciamento de software 36, 81, 83, 85,
92, 94, 96, 98, 114, 117, 119, 126, 129, 135, 137 sourcing
14–15
SRE (engenharia de confiabilidade do site) 21, 124–126

comece onde você está (princípio orientador) xiv, 47, 73–74
gerenciamento de estratégia 36, 95, 100, 132, 135 prevenção de
estresse 58–61 gerenciamento de fornecedores 36, 83, 85, 92,
R 95, 101, 108, 129 fornecedores 39
reconstrução para agilidade de serviço 53–55

gerenciamento de relacionamento 36, 85, 96, 100, 129
gerenciamento de versão 36, 81, 98, 103, 108, 116, 124, SVS (sistema de valor de serviço) xii, 24
126 características resilientes 18, 21 operações pensamento sistêmico 62
resilientes 16–17, 108–114 retrospectivas 95–96 revisões

T
95–98
dívida técnica 110-111
tecno-ética 49
automação de teste 22
gestão de risco 36, 85, 88, 92, 96, 98, 100, 103, 105, 111, 114,
124, 132, 134-135, 137 riscos 6 pensar e trabalhar holisticamente (princípio orientador) xiv, 47,
48, 75 labuta 124
S Toyota Kata 70–71
cultura de segurança 56– confie 45, 48 confie e
58 macaco de segurança seja confiável (padrão de comportamento chave) 45, 46–47
113 separação de tarefas

U
132 agilidade de serviço 53–
55 gerenciamento de catálogo de serviço 36, 83, 85, 117, 129 imprevisibilidade 64
gerenciamento de configuração de serviço 36, 92, 103, 114,

119, 121, 132 consumidores de serviço 31– 32 V
investimentos valiosos 16–17, 78–88
gerenciamento de continuidade de serviço 36, 83, 96, 101, 103, fluxos de valor 33–34, 39 variabilidade 64
105, 114, 119 design de serviço 36, 83, 88, 100, 114, 117, velocidade 6–7
126, 129
170
Índice
controle de versão 118–119

volatilidade, incerteza, complexidade e ambiguidade
(VUCA) 40
W
força de trabalho e gestão de talentos 36, 122, 132
trabalhando em ambientes complexos 62–65
171
172

ITIL 4 Specialist High-Velocity IT (HVIT) Português

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

ITIL 4 Specialist High-Velocity IT (HVIT) Português

Enviado por

Direitos autorais:

Formatos disponíveis

Machine Translated by Google

Publicado pela TSO (The Stationery Office), parte da Williams Lea, e

Correio, Telefone, Fax e E-mail

TSO@Blackwell e outros Agentes Credenciados

Direitos autorais © AXELOS Limited 2020

Impresso no Reino Unido para The Stationery Office Material é

Sobre as publicações ITIL 4 ix

Sobre a história da ITIL x

Resumo da Fundação ITIL xii

1.1 Público e escopo 1.2 2

2 Conceitos-chave de TI de alta velocidade 5

velocidade 2.2 Tecnologia 7

digital 2.3 Organizações 11

digitais 2.4 Transformação 12

digital 2.5 Objetivos e principais características de TI de alta 16

velocidade 2.6 Adotando o sistema de valor de serviço ITIL para habilitar TI de 23

alta velocidade 2.7 Resumo 41

3 Cultura de TI de alta velocidade 43

3.1 Principais padrões de 44

comportamento 3.2 Modelos e conceitos da cultura 46

HVIT 3.3 Princípios orientadores da ITIL 3.4 73

4 Técnicas de alta velocidade 77

4.1 Técnicas para investimentos valiosos 4.2 78

Técnicas para desenvolvimento rápido 4.3 88

Técnicas para operações resilientes 4.4 Técnicas 108

para valor cocriado 4.5 Técnicas para 127

conformidade garantida 4.6 Resumo 130

Nota final: A história da ITIL 141

Mais pesquisa 143

Figura 0.2 A cadeia de valor do serviço ITIL xiii

Figura 0.3 O modelo de melhoria contínua xv

Figura 0.4 As quatro dimensões do gerenciamento de serviços xvi

Figura 2.1 Tecnologia digital 8

Figura 2.2 Pilha de tecnologia do sistema de informação 8

Figura 2.3 A pilha de valor de TI 9

Figura 2.4 Transformação digital e transformação de TI 13

Figura 2.5 Exemplos de opções de sourcing para uma função de TI 15

Figura 2.6 Objetivos de uma perspectiva econômica 17

Figura 2.7 Principais características do HVIT 18

Figura 2.8 Um fluxo de valor com três estações de trabalho 19

Figura 2.9 O sistema de valor de serviço ITIL 24

Figura 2.10 Interação do serviço e a faixa de visibilidade 26

Figura 2.12 Modelo de jornada do cliente 28

Figura 2.13 Ciclos de vida de produtos digitais da perspectiva do consumidor 28

Figura 2.14 A cadeia de valor do serviço ITIL 29

Figura 2.15 Atividades de DevOps em um loop contínuo 30

Figura 2.16 DevOps e a cadeia de valor do serviço 30

Figura 2.17 A perspectiva do consumidor de serviços 31

Figura 2.18 Cadeias de valor de serviço interagindo 32

Figura 2.20 O fluxo de valor no contexto 33

Figura 2.21 Fluxo de valor posicionado em relação à governança, execução e melhoria 34

Figura 3.1 Principais padrões de comportamento 44

Figura 3.7 A estrutura Cynefin 63

Figura 3.10 O modelo de melhoria contínua ITIL 69

Figura 3.11 Domínios de melhoria 69

Figura 3.12 Toyota Kata 71

Figura 4.4 Experimentação por tempo limitado com teste A/B 86

Figura 4.6 Efeito do tamanho da mudança 90

Figura 4.15 Um exemplo de um quadro Kanban 107

Figura 4.27 Espectro de formalidade de revisão por pares 136

Tabela 2.1 Objetivos HVIT 16

Tabela 2.2 Principais características da TI de alta velocidade 18

Tabela 2.4 Etapas do ciclo de vida do produto digital 28

Tabela 2.5 Práticas e sua relevância para os cinco objetivos 36