Problemas de Ownership Design podem ser encontrados em toda governança de TI e, muitas vezes, podem ser as causas subjacentes de muitos problemas de governança de TI. Infelizmente, isso se deve à natureza humana, porque é inerente à nossa natureza perguntar: “o que eu ganho com isso?”.
O que é Ownership Design e como ele pode evitar problemas comuns na TI?
Isso soa familiar? É sexta-feira, 16h, quando chega uma mensagem frenética do COO: “ninguém está conseguindo acessar o CRM. Por um acaso você começou uma atualização de fim de semana mais cedo ou algo parecido?”. Depois de realizar uma investigação (e ligar para casa para avisar que o planejamento do fim de semana se foi), você descobre que existe uma aplicação obsoleta em execução, que não possui mais suporte pelo fornecedor nem as atualizações recentes. Tempos atrás, o time de TI teve que passar por diversos obstáculos só para conseguir colocar essa aplicação em execução, pois era o que a área de negócios desejava.
Agora são 18h30, e todos os envolvidos estão reunidas em uma reunião no Teams. A área de negócios culpa o time de TI por não conseguir manter os sistemas operando. O time de TI culpa a área de negócios por insistir em utilizar um software obsoleto só porque “é o que usamos há décadas”. A chamada acaba. São 19h30 e, a despeito dos gritos e do apontamento de dedos, nenhum progresso foi feito. Você diz em voz alta: “ninguém quer tomar a questão para si. Onde está a responsabilidade?”. Isso soa familiar?
O que aconteceu?
Embora algo como a situação acima aconteça em diferentes tipos de organizações, de vários setores do mercado, ela tem uma causa raiz: Ownership Design. Compreendendo o conceito de Ownership Design, conseguimos ajudar a minimizar estes problemas e, por fim, alcançar a eficiência no ambiente geral de TI.
O que é Ownership Design?
Ownership Design, em tradução livre, seria o design e a implementação do famoso “sentimento de dono”). Ou seja, é, simplesmente, uma maneira de orientar com precisão o comportamento dos colaboradores, usando regras cuidadosamente projetadas, que definem como as pessoas assumem a responsabilidade das coisas.
Mas como? Aqui vai um exemplo real:
Todos nós gostamos de compartilhar nossas contas da Netflix – membros da família, vizinhos, colegas e até mesmo estranhos! Ainda que muitos usuários não percebam, compartilhar contas da Netflix pode ser um crime federal sob a Lei Fraude e Abuso de Computador (leis criminais a respeito de crimes cometidos com auxílio de computador nos Estados Unidos) e punível com até um ano de prisão. No entanto, o CEO da Netflix, Reed Hastings, transformou isso em uma oportunidade de marketing, dizendo: “adoramos que as pessoas compartilhem a Netflix”.
Isso pode soar contraintuitivo – uma empresa não deveria exigir que todos pagassem por seu próprio acesso? Ao permitir que as pessoas compartilhem suas contas, a Netflix espera que essas pessoas se tornem obcecadas com seus programas e eventualmente adquira sua própria assinatura. E essa estratégia de Ownership Design foi bem-sucedida.
Também conhecido como “roubo tolerado”, está é uma das muitas maneiras pelas quais o Ownership Design pode moldar o comportamento das pessoas.
Problemas comuns de Ownership Design
Aqui estão alguns dos problemas comuns de Ownership Design que podem ser encontrados em muitas organizações:
“Eu colho, você semeia”
A área de negócios quer uma aplicação, mas é o time de TI o responsável por implementá-la. Quando as coisas vão bem, o negócio se beneficia. Quando algo dá errado, é sempre culpa da TI. Então, o que está errado?
Se analisarmos esta questão pela ótica do Ownership Design, uma das causas raiz é o desalinhamento de interesses. Nessa relação, o interesse da área de negócios é uma aplicação melhor, o que exige mais esforços da TI. Enquanto isso, a TI opera com sua própria agenda crítica, e ao desviar esforços para um trabalho adicional, acaba por fornecer pouco ou nenhum benefício. Sendo assim, acaba gerando mais políticas e requisitos, como Acordos de Nível de Serviço (SLAs), que podem ser estabelecidos para forçar a TI a fornecer uma “melhor” qualidade de serviço. A realidade é que isso só funciona no papel.
Uma solução comum é o modelo chargeback (“cobrança retroativa”) . Isso permite que TI aloque seu orçamento para unidades de negócios específicas em vez de centralizá-lo em um único departamento, o que essencialmente torna as despesas rastreáveis, aumentando a transparência.
“Nuvem: um passe livre para a isenção de responsabilidade”
Mais e mais organizações estão migrando para a nuvem. Algumas delas adotam “cloud-first” (conceito de nuvem desde a concepção do projeto, o que pode trazer ganhos financeiros e eficiência operacional). A adoção da nuvem não apenas torna os limites da rede cada vez mais ambíguos, mas também torna o a definição de responsabilidades equivocada. Durante uma avaliação de segurança, a o departamento de TI em muitas organizações pode dizer: “Esta é uma plataforma em nuvem, não gerenciada por nós. Esse fornecedor de nuvem tem uma ótima reputação, então todos os usam.”. Dessa forma, a nuvem é usada quase como um passe livre para a isenção de responsabilidade.
E aqui está o problema: isso não é verdade. A história nos ensinou que uma má implementação pode minar uma grande tecnologia. Neste caso, entra a delegação de responsabilidades.
Para superar esse problema, uma organização deve garantir que os colaboradores entendam quais são suas responsabilidades. Muitos provedores de serviços de nuvem já possuem documentações que podem ser usadas como referência. Por exemplo, a AWS tem um modelo de atribuições compartilhadas que descreve como as responsabilidades são compartilhadas entre eles e os clientes.
“Construa uma comunidade, não silos”
A governança tradicional de TI nos diz para definir claramente as propriedades, as funções e as responsabilidades. Geralmente, isso acaba fazendo com que as pessoas gastem mais tempo para encontrar alguém para culpar, transformando a governança de TI em um jogo de apontar dedos. Agora, vamos parar e realizar uma análise da realidade: quantas dessas funções e responsabilidades foram implementadas com sucesso de maneira assídua?
A governança excessivamente sofisticada apenas cria um fardo a ser imposto, gerando um ambiente de tensão em vez de criar um senso de comunidade. Somos todos humanos, e nossas práticas de negócios devem levar em conta isso. Um típico exemplo desta situação é a classificação da informação e rotulagem de dados. Muitas reuniões de governança de dados se transformam em jogos de apontar o dedo sobre quem deve aplicar rótulos e como esses rótulos devem ser aplicados. Em seguida, os usuários são culpados por não aplicarem corretamente os rótulos. Isso fere os sentimentos de todos!
Em vez de uma abordagem simples e direta, a governança de TI precisa funcionar mais como um balizador . Você pode aumentar ou diminuir a baliza, conforme necessário. Isso também é conhecido como “ambiguidade projetada”. Usando novamente a classificação da informação como um exemplo, na maioria das organizações, quão realista é para um usuário memorizar páginas de definições e categorizar adequadamente a sua sensibilidade toda vez que um documento é criado? Os fatores humanos devem ser levados em consideração – nós todos somo ocupados (e um pouco preguiçosos de vez em quando). Pode ser mais eficaz fornecer uma “regra prática” definida aos usuários para esta classificação, em vez de políticas excessivamente sofisticadas. Quando as tecnologias automatizadas estiverem prontas, uma opção é transferir a imposição desta responsabilidade para tecnologias automatizadas que possam entender o contexto de um documento em vez de simplesmente combinar padrões. Por exemplo, utilizar a IA para categorizar os dados com base nessas regras sofisticadas de uma maneira muito mais confiável. Afinal, a IA deve ser imune a algumas de nossas falhas humanas.
Use o Ownership Design como uma ferramenta
Os exemplos discutidos aqui são apenas a ponta do iceberg. Problemas de Ownership Design podem ser encontrados em toda governança de TI e, muitas vezes, podem ser as causas subjacentes de muitos problemas de governança de TI. Infelizmente, isso se deve à natureza humana, porque é inerente à nossa natureza perguntar: “o que eu ganho com isso?”.
Não se deixe enganar pelo termo Ownership Design. Não é uma abordagem simples. Em vez disso, deve ser usado como um balizador: você deve aumentar ou diminuir esta baliza, conforme necessário. O objetivo final nunca é ter uma designação clara de quem possui o quê, mas sim usá-lo como uma ferramenta para moldar o comportamento das pessoas. E quando usado corretamente, o Ownership Design pode ser uma ferramenta extremamente poderosa.
*Jacky Guo e Eric Mauser, Gerentes de Segurança e Privacidade da Protiviti INC.
Fonte: “Not My Problem” – The Oversight of Ownership Design – Technology Insights Blog (protiviti.com)
