View
1
Download
0
Category
Preview:
Citation preview
FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO PORTO
Tecnologia Blockchain - Potencial deAplicação no âmbito dos Processos de
Negócio das Cadeias de Abastecimento
Tiago Alves Borrego
MESTRADO INTEGRADO EM ENGENHARIA ELECTROTÉCNICA E DECOMPUTADORES
Orientador: Professor Américo Lopes de Azevedo
Co-orientador: Engenheiro João Luís Martins
22 de Outubro de 2019
Tecnologia Blockchain - Potencial de Aplicação no âmbitodos Processos de Negócio das Cadeias de Abastecimento
Tiago Alves Borrego
MESTRADO INTEGRADO EM ENGENHARIA ELECTROTÉCNICA E DECOMPUTADORES
22 de Outubro de 2019
Resumo
O blockchain é uma tecnologia emergente recentemente generalizada para muitas áreas comenormes potencialidades. O seu modo de operação enquadra-se perfeitamente nas supply chains,independentemente do setor. Por norma englobam todos os processos e atividades desde a recolhada matéria prima até à entrega do produto, com trocas e transformações complexas a acontecer,desde a origem até à entrega final do produto. As preocupações, como rastreabilidade de produtos,gestão de inventário, controlo de qualidade e cumprimentos de prazos, são alguns deles.
A solução para muitos dos problemas referidos pode ser encontrada na utilização de tecnologiablockchain, pois permite não só melhorar a velocidade de entrega dos produtos ao cliente, mastambém assegurar a rastreabilidade, para garantir um excelente controlo de qualidade, uma boatransferência de dados e segurança da informação.
Esta dissertação foca-se no estudo e conhecimento das funcionalidades e potencialidades datecnologia blockchain, e demonstrar que processos de negócio podem usufruir do potencial subja-cente à tecnologia. Para responder às questões propostas nesta dissertação, foram analisados casosde estudos por setores, processos de negócio e o potencial de aplicação da tecnologia blockchainna gestão da supply chain.
Na avaliação do potencial de aplicação na gestão de uma supply chain, foi utilizado o modeloSCOR a fim de se compreender os processos existentes e, posteriormente, foi realizado um estudoindividual às categorias e aos respetivos processos onde foram analisadas as dificuldades e asnecessidades dos mesmos. De seguida, foram avaliadas as dificuldades e as necessidades de cadacategoria de processos. Desta forma foi possível qualificar a importância e realizar um matchingentre as dificuldades e/ou necessidades de cada processo e o potencial de utilização da tecnologiablockchain.
No final, foi possível concluir que a tecnologia blockchain pode atuar em diversos setores,empresas e processos de negócios.
Após uma reflexão sobre as análises realizadas e de se ter concluído que cada empresa apre-senta processos com diferentes importâncias, foi construído um simulador para que qualquer em-presa que tenha uma organização orientada sobre o modelo SCOR consiga analisar os seus pro-cessos e refletir sobre o potencial da tecnologia blockchain no mesmo.
i
Abstract
The blockchain is an emerging technology which has recently been generalised to many areaswith huge potential. Its operating mode fits perfectly in the supply chains, regardless their sector.Normally, they comprise all the procedures and activities from the picking of the raw material tothe final delivery of the product. Some of the worries are the traceability of products, inventorymanagement, quality control and deadline fulfillment.
The solution to many of the problems in these areas can be found in the use of the blockchaintechnology, as it permits not only improving the velocity of the products delivery to the client, butalso assure the traceability, to ensure an excellent quality control, a good data transference andinformation security.
This dissertation focuses in the study and knowledge of the functions and potentialities of theblockchain technology and shows which business procedures can enjoy the potential underlyingthe technology.
To answer the questions suggested in this paper, it was analysed study cases by sectors, busi-ness procedures and the potential of the application of the blockchain technology in the manage-ment of the supply chain.
In the evaluation of this potential, it was used the SCOR model to understand the existingprocedures and, later, it was made an individual study to the categories and their procedures toanalyse the difficulties and necessities.
After that, the difficulties and necessities of each processes category were studied.Thus, it was possible to qualify the importance and carry out a matching between the difficul-
ties and/ or necessities of each process and the potential of using the blockchain technology.In the end, it was concluded that the blockchain technology can act on different sectors, com-
panies and business procedures.After a reflection on the analysis made and the conclusion that each company presents proce-
dures with different importance, it was made a simulator, so that any company which is organisedwith the SCOR model can analyse its processes and reflect on the potential of using the blockchaintechnology.
iii
Agradecimentos
Ao Professor Américo Lopes de Azevedo, pessoa que muito admiro e que tive a honra e oprivilégio de conhecer, expresso o meu profundo agradecimento pela confiança, disponibilidade eamabilidade sempre presentes ao longo deste trabalho.
Ao Engenheiro João Luís Martins pela orientação, e pela disponibilidade.Aos meus pais, pilares fundamentais na minha vida, por estarem sempre presentes. Pelo apoio
constante, confiança nas minhas capacidades e principalmente por nunca me deixarem desistir.À minha irmã pelo apoio e paciência durante este período.Aos meus amigos pelo apoio, incentivo e presença constante ao longo destes meses.
Tiago Alves Borrego
v
Conteúdo
1 Introdução 11.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Objetivo e Questões de Investigação . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Metodologia utilizada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Estrutura da dissertação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Tecnologia Blockchain 52.1 Funcionalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 Desafios Tecnológicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 Propriedades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4 Conceitos chave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.1 Distributed Ledger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.4.2 Criptografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.2.1 Hashing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.4.2.2 Merkle Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.4.2.3 Patricia Trie . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.3 Consenso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.4.4 Smart Contracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4.4.1 Blockchain Oracles . . . . . . . . . . . . . . . . . . . . . . . 152.4.4.2 Exemplo de Implementação . . . . . . . . . . . . . . . . . . . 16
2.4.5 Verificação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.5 Arquitetura Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.6 Tipos de Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.6.1 Blockchain Público . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.6.2 Blockchain Privado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.6.3 Blockchain Federado/Consórcio . . . . . . . . . . . . . . . . . . . . . . 24
2.7 Blockchains vs Centralized Databases . . . . . . . . . . . . . . . . . . . . . . . 252.8 Blockchain Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3 Casos de Estudo por Setores 313.1 Setor Agricultura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.2 Setor Automóvel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.3 Setor da Administração Pública . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.4 Setor da Educação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.5 Setor da Saúde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.6 Setor dos Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.7 Setor Energético . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.8 Setor Financeiro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.9 Setor Gaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
viii
CONTEÚDO ix
3.10 Registo de Propriedade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.11 Filantropia e Ajuda Humanitária . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4 Processos de Negócios 474.1 Ciclo de Vida dos Processos de Negócio . . . . . . . . . . . . . . . . . . . . . . 484.2 Tipos de Processos de Negócio . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2.1 Processos Operacionais/Primários . . . . . . . . . . . . . . . . . . . . . 494.2.2 Processos de Suporte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.2.3 Processos de Gestão . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.3 Modelos para Design de Processos de Negócio . . . . . . . . . . . . . . . . . . 514.3.1 SCOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.3.2 PCF (APQC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.3.3 eTOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.3.4 COBIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5 Potencial de Aplicação no contexto da Supply Chain Management (SCM) 575.1 Caracterização da Supply Chain . . . . . . . . . . . . . . . . . . . . . . . . . . 575.2 Da Supply Chain para o Blockchain . . . . . . . . . . . . . . . . . . . . . . . . 595.3 Objetivos Principais de Implementação da Tecnologia Blockchain . . . . . . . . 595.4 Análise de processos seguindo o modelo SCOR . . . . . . . . . . . . . . . . . . 60
5.4.1 Hierarquia dos processos no modelo SCOR . . . . . . . . . . . . . . . . 605.4.2 Análise das necessidades dos processos e cálculo do potencial de utiliza-
ção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625.5 Simulador para o Potencial de Aplicação no âmbito da Tecnologia Blockchain . . 715.6 Exemplo de Implementação Blockchain . . . . . . . . . . . . . . . . . . . . . . 725.7 Outras possibilidades de implementação . . . . . . . . . . . . . . . . . . . . . . 75
6 Conclusão 776.1 Visão Global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776.2 Trabalho Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
A 79
Referências 81
Lista de Figuras
2.1 Exemplos de Criptomoedas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Transmissão Peer-to-Peer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Exemplo de uma Merkle Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.4 Exemplo de uma Patricia Trie . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.5 Exemplo de implementação de um Smart Contract . . . . . . . . . . . . . . . . 162.6 Como um sistema de verificação verifica se a transação é solicitada pelo verdadeiro
remetente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.7 Exemplo de um blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.8 Arquitetura interna de um bloco . . . . . . . . . . . . . . . . . . . . . . . . . . 192.9 Tipos de Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.10 Centralizada vs Descentralizada vs Redes Distribuídas . . . . . . . . . . . . . . 222.11 Blockchain vs Base de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1 Ciclo de Vida de Gestão de Processos . . . . . . . . . . . . . . . . . . . . . . . 484.2 Supply Chain Operations Reference (SCOR) - SCOR v12.0 . . . . . . . . . . . . 524.3 Doze níveis de processos do PCF . . . . . . . . . . . . . . . . . . . . . . . . . . 534.4 Modelo eTOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.5 Cubo de COBIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.1 Exemplo simplificado de uma supply chain de vestuário . . . . . . . . . . . . . . 575.2 Exemplo de uma supply chain de vestuário . . . . . . . . . . . . . . . . . . . . . 585.3 Hierarquia dos processos no modelo SCOR, adaptado de SCOR 12.0 . . . . . . . 615.4 Processos pertencentes à categoria sP1 (Plan Supply Chain) . . . . . . . . . . . 625.5 Importância de cada parâmetro em cada nível . . . . . . . . . . . . . . . . . . . 695.6 Análise por parâmetro de avaliação . . . . . . . . . . . . . . . . . . . . . . . . 715.7 Amostra 1 do Simulador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725.8 Análise Final do Simulador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735.9 Cadeia Simplificada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745.10 Ações tomadas por cada utilizador . . . . . . . . . . . . . . . . . . . . . . . . . 745.11 Exportação de ações na cadeia . . . . . . . . . . . . . . . . . . . . . . . . . . . 745.12 Esquema de finalização do processo . . . . . . . . . . . . . . . . . . . . . . . . 755.13 Comprovativo blockchain final . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
xi
Lista de Tabelas
2.1 Comparação de sistemas blockchain . . . . . . . . . . . . . . . . . . . . . . . . 102.2 Exemplos de encriptação (SHA-256) . . . . . . . . . . . . . . . . . . . . . . . . 112.3 Prova exemplo de que o hashing é case sensitive (SHA-256) . . . . . . . . . . . 122.4 Algoritmos de consenso mais utilizados na tecnologia blockchain . . . . . . . . . 142.5 Blockchain Público vs Privado vs Consórcio/Federado . . . . . . . . . . . . . . 252.6 Permissionless vs Permissioned vs Central Database . . . . . . . . . . . . . . . 25
3.1 Possíveis vantagens da aplicação da tecnologia no setor da agricultura . . . . . . 32
5.1 Dificuldades e necessidades inerentes ao nível Plan . . . . . . . . . . . . . . . . 625.2 Dificuldades e necessidades inerentes ao nível Source . . . . . . . . . . . . . . . 635.3 Dificuldades e necessidades inerentes ao nível Make . . . . . . . . . . . . . . . . 645.4 Dificuldades e necessidades inerentes ao nível Deliver . . . . . . . . . . . . . . 655.5 Dificuldades e necessidades inerentes ao nível Return . . . . . . . . . . . . . . . 665.6 Dificuldades e necessidades inerentes ao nível Enable . . . . . . . . . . . . . . . 675.7 Tabela de geral de análise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705.8 Cálculo da nota média geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705.9 Cálculo da nota média geral sem o parâmetro da redundância . . . . . . . . . . . 70
xiii
Abreviaturas
B2B Business-to-businessBC BlockchainBPM Business Process ManagementBTC BitcoinDLT Distributed Ledger TechnologyETH EthereumMRO Maintenance, Repair and OverhaulOM Operation ManagementPM Project ManagementSCM Supply Chain ManagementTPS Transação por segundo
xv
Capítulo 1
Introdução
Perspetiva-se um grande potencial em torno do blockchain. Assim, nesta dissertação, irá ser
estudada a aplicabilidade desta tecnologia em contextos reais. Em particular, o principal objetivo
será estudar e investigar o potencial do blockchain no contexto dos processos de negócio.
1.1 Motivação
A gestão de processos de negócio (BPM) preocupa-se maioritariamente com o design, a exe-
cução, a monitorização e o aprimoramento dos processos de negócios. Os sistemas que supor-
tam a promulgação e a execução de processos são extensivamente utilizados pelas empresas para
otimizar e automatizar os processos intraorganizacionais. No entanto, para processos interorgani-
zacionais os desafios da conceção conjunta e da falta de confiança mútua dificultam uma maior
aceitação.
A tecnologia emergente de blockchain tem o potencial de mudar drasticamente o ambiente
no qual os processos interorganizacionais são capazes de operar, uma vez que os blockchains
oferecem uma forma confiável de executar processos, mesmo numa rede sem qualquer confiança
mútua entre os nós.
Tendo isto em consideração a motivação para a realização desta dissertação passa por aumen-
tar o conhecimento sobre esta tecnologia, bem como as suas possíveis aplicações e respetivas
vantagens.
1
2 Introdução
1.2 Objetivo e Questões de Investigação
Esta dissertação tem como objetivo geral compreender e analisar os casos de uso e aferir o
potencial da aplicação da tecnologia blockchain nos diversos processos de negócios.
Por outro lado, os objetivos mais restritos são essencialmente explicar as principais, funcio-
nalidades, propriedades, desafios e conceitos chave da tecnologia e explorar possíveis casos de
uso.
Pretende-se também encontrar novas utilidades e potenciais inovações, usando a tecnologia
blockchain, ou possivelmente expandir e melhorar uma ideia já existente através da análise dos
processos de negócios às suas dificuldades e necessidades.
Para tal, será realizada uma análise aprofundada aos processos de negócio, no que se relaciona
com os seus tipos, intervenientes, ações, categorias e níveis. O objetivo será sempre analisar as
possíveis dificuldades e as necessidades dos processos, tendo em vista avaliar o potencial uso da
tecnologia blockchain.
Assim, após uma cuidada leitura e análise do tema em apreço, resultaram as seguintes questões
de investigação:
• Que tipo de processos poderão usufruir do potencial subjacente à tecnologia de blockchain?
• Quais as propriedades da tecnologia blockchain que mais podem contribuir para a melhoria
da eficácia e eficiência dos processos de negócio?
1.3 Metodologia utilizada
Esta dissertação explorou uma análise da literatura existente na área e nomeadamente infor-
mação técnica. Assim, foram realizados um conjunto ações com vista a responder às questões de
investigação:
1. Em sessões de brainstorming sobre a tecnologia e os possíveis caminhos de aplicação tendo
em conta a gestão de processos de negócio;
2. Na pesquisa e análise de bibliografia relativa à tecnologia blockchain, com o objetivo de
entender as suas principais funcionalidades, propriedades, desafios e conceitos chave;
3. Na pesquisa e na análise relativa aos tipos de processos de negócio e aos modelos mais
utilizados para o design de processos de negócios;
4. Numa análise aprofundada de um dos modelos antes levantados com o objetivo de compre-
ender a sua organização interna e posteriormente analisar todos os processos, intervenientes
e ações inerentes ao mesmo;
1.4 Estrutura da dissertação 3
5. Na avaliação das necessidades e/ou dificuldades dos processos analisados sendo posterior-
mente realizada uma avaliação individual sobre cada categoria de processos;
6. No desenvolvimento de um simulador para que qualquer utilizador ou empresa, que possua
uma organização orientada sobre o modelo SCOR, possa avaliar o potencial da tecnologia
blockchain.
1.4 Estrutura da dissertação
No seguimento da metodologia utilizada a presente dissertação foi estruturada da seguinte
forma:
• Capítulo 1 - É dada a visão geral do objetivo da investigação e da metodologia seguida.
• Capítulo 2 - Centra-se na tecnologia blockchain. Nas primeiras secções são abordadas as
funcionalidades, os desafios tecnológicos e as propriedades da tecnologia. De seguida são
aprofundados os termos mais técnicos como os conceitos chave, a arquitetura e os tipos de
redes.
• Capítulo 3 - Resulta do estudo e da análise de casos de estudo da tecnologia blockchain.
Para este capítulo foram selecionados diversos casos de estudo, de diferentes setores e de
empresas com diferentes objetivos e dimensões.
• Capítulo 4 - Serve de introdução para os processos de negócio (ciclo de vida e tipos de
processos) e para os modelos de design existentes.
• Capítulo 5 - Resulta da análise do potencial de aplicação da tecnologia blockchain no con-
texto do supply chain management onde são estudados os problemas de uma suply chain
e os principais objetivos da implementação da tecnologia blockchain. Este capítulo apre-
senta, recorrendo ao modelo SCOR, uma análise individual às categorias e aos respetivos
processos, sendo analisadas as dificuldades e as necessidades dos mesmos. Tem como obje-
tivo compreender, com base nas dificuldades e nas necessidades individuais dos processos,
o potencial uso da tecnologia blockchain. Uma vez que este processo de análise pode ser
considerado muito subjetivo e diferente de empresa para empresa foi realizado um simu-
lador para que qualquer empresa orientada segundo o modelo SCOR analise o potencial
da tecnologia. No final do capítulo, é apresentado, através de imagens, um exemplo de
aplicação.
• Capítulo 6 - São expostas as conclusões, com base no estudo e no trabalho realizado para
o desenvolvimento desta dissertação. Para além disso são apresentados possíveis trabalhos
futuros.
Capítulo 2
Tecnologia Blockchain
Nos dias que correm, quando as pessoas ouvem falar no termo blockchain, associam, de forma
errada, a mais uma moeda eletrónica. Atualmente, o exemplo mais conhecido da tecnologia block-
chain em ação é o Bitcoin, líder em criptomoedas, ou seja, moedas que são transacionadas por
transferência de valor, sem qualquer realidade física ou controlo por um banco central. Como
seria de esperar, a existência de este tipo de moedas depende de forma direta de um sistema de
segurança que seja inviolável (ou quase), baseado em encriptação.
Apesar de o Bitcoin [1] ter sido o pioneiro na tecnologia de moeda virtual, existem outras
moedas que aplicam a mesma tecnologia como a Litecoin, Dogecoin ou Ethereum que permitem
trocas de valores de forma aberta, anónima e “de certa forma” mais seguras (exemplos apresenta-
dos na Figura 2.1). Estas aplicações da tecnologia blockchain associadas às criptomoedas, fazem
parte da primeira geração e são denominadas Blockchain 1.0.
Figura 2.1: Exemplos de Criptomoedas
Após a implantação das primeiras criptomoedas e tendo em consideração as propriedades in-
trínsecas desta tecnologia (tais como a segurança, inviolabilidade, imutabilidade e resiliência),
notou-se que esta poderia ter outras aplicações. Neste sentido, as plataformas de desenvolvimento
blockchain evoluíram e permitiram a inserção de transações mais complexas através dos contratos
inteligentes (smart contracts). Foi através destas novas aplicações que surgiu o chamado Block-
chain 2.0.
5
6 Tecnologia Blockchain
2.1 Funcionalidades
Atualmente a base dos sistemas económicos, legais e políticos são contratos, transações e
registos. Estes têm algumas finalidades ou objetivos, como sejam:
• Proteger ativos e estabelecer limites organizacionais;
• Estabelecer e verificar identidades e eventos crónicos;
• Governar as interações entre nações, organizações, comunidades e indivíduos;
• Guiar/comandar a ação social [2].
No entanto, estas ferramentas e as burocracias formadas para as gerir não acompanharam a
transformação digital da economia e acabam por ser como um percalço, que na hora da partida
prende um atleta de fazer um sprint.
Com efeito, a tecnologia blockchain promete resolver este problema com os seguintes princí-
pios básicos:
1. Distributed Database
Cada participante de um blockchain tem acesso a todo o banco de dados e ao seu histó-
rico completo, podendo assim verificar os registos dos seus parceiros de transação sem um
intermediário. Nenhuma parte individual controla os dados ou as informações.
2. Transmissão Peer-to-Peer
A comunicação ocorre diretamente entre os pares sem necessitar de um nó central, pois cada
nó armazena e envia informações para todos os outros nós (Figura 2.2).
Figura 2.2: Transmissão Peer-to-Peer
3. Transparência
Toda a transação e o seu valor associado são visíveis para qualquer pessoa com acesso ao
sistema. Cada nó, ou participante, num blockchain tem um endereço alfanumérico exclusivo
que o identifica. Os usuários podem optar por permanecer anónimos ou fornecer provas da
sua identidade a outros participantes.
2.2 Desafios Tecnológicos 7
4. Imutabilidade dos Registos
Quando uma transação é inserida no banco de dados e as informações são atualizadas, os
registos não podem ser alterados, porque eles estão vinculados a cada registo de transação
que veio antes deles (daí o termo "cadeia").
Vários algoritmos e abordagens computacionais são implantados para garantir que a gra-
vação no banco de dados seja permanente, impermutável, ordenada cronologicamente e
disponível para todos os outros participantes na rede.
5. Lógica Computacional
A natureza digital de um ledger indica, desde logo, que as transações de blockchain podem
ser vinculadas à lógica computacional, ou seja, podem ser programadas. Assim, os usuários
podem configurar algoritmos e regras que acionam automaticamente transações entre os
nós.
2.2 Desafios Tecnológicos
É importante também salientar que esta tecnologia blockchain ainda tem que enfrentar inúme-
ros desafios, sendo que entre eles se destacam os seguintes:
• Taxa de Transferência: Enquanto que o número de inclusões na blockchain do Ethereum é
limitado para aproximadamente 15 inclusões de transação por segundo (tps), os volumes de
transações para a rede de pagamentos VISA são em média de 50 tps e têm uma capacidade
máxima de 50000 tps [3].
• Latência: Provém da existência de blocos de confirmação para garantir que a transação
não seja removida devido a bifurcações acidentais ou maliciosas. Mesmo com melhorias
técnicas como uma rede de descargas elétricas ou cadeias laterais geradas a partir de uma
cadeia principal, é improvável que as blockchains obtenham latências tão baixas quanto os
sistemas controlados centralmente.
• Usabilidade: A usabilidade é muito limitada, seja no suporte ao developer (por falta de
ferramentas adequadas e fáceis de usar) como no suporte ao usuário final (pela dificuldade
na utilização e interpretação dos dados).
• Segurança: Por se tratar de uma rede aberta, a segurança representará sempre um desafio.
Embora possa ser resolvido por criptografia direcionada, a confidencialidade num sistema
distribuído, que replica todos os dados em toda a sua rede, é muito baixa.
• Desperdício de recursos: Particularmente eletricidade, são devidos ao mecanismo de con-
senso, em que os mineradores competem constantemente numa corrida para ver quem con-
segue minerar o próximo bloco por uma alta recompensa.
8 Tecnologia Blockchain
2.3 Propriedades
De seguida serão descritas as propriedades mais relevantes e as suas respetivas vantagens em
torno da utilização da tecnologia blockchain:
• Verificabilidade Pública
Permite que qualquer pessoa verifique o estado e a exatidão do estado do sistema. Num
distributed ledger, cada transição de estado realizada é confirmada por verificadores (por
exemplo, mineradores no Bitcoin). No entanto, qualquer observador pode verificar se o
estado do ledger foi alterado de acordo com o protocolo. É importante referir que todos
os observadores têm a mesma visão. Num sistema centralizado isso já não se verifica, pois
diferentes observadores podem ter visões completamente diferentes do estado. Como tal,
alguns observadores podem não conseguir verificar se todas as transições de estado foram
executadas corretamente. Neste caso, os observadores precisam de confiar no estado que a
entidade central lhes fornece.
• Integridade
A integridade de informações garante que estas sejam protegidas contra modificações não
autorizadas, ou seja, os dados recuperados estão corretos. A integridade da informação está
intimamente ligada à verificabilidade pública. Isto porque se um sistema fornece verifica-
bilidade pública implica que qualquer um pode verificar a integridade dos dados. Por outro
lado a integridade só pode ser garantida se o sistema centralizado não for comprometido.
• Imutabilidade
Ligado diretamente com o ponto acima descrito a imutabilidade é umas das propriedades
principais da tecnologia blockchain. A maneira como a imutabilidade é garantida será abor-
dada na Subsecção 2.4.2. De forma resumida, esta é garantida com recurso a um hash code
por bloco que contém a informação dos blocos e dos respetivos hash anteriores. Caso um
bloco seja alterado a sua hash é também alterada e a rede de blocos quebra, uma vez que, as
informações foram adulteradas.
• Redundância
Nos sistemas blockchain, a redundância é inerentemente fornecida através da replicação
entre os escritores. Em sistemas centralizados, a redundância é geralmente obtida através
da replicação em diferentes servidores físicos e através de backups.
• Hierarquia
A chamada âncora de confiança ("Trust Anchor"[4]) define quem representa a autoridade
mais alta de um determinado sistema que tem autoridade para conceder e revogar o acesso
de leitura e gravação a um sistema.
2.4 Conceitos chave 9
• Transparência
A transparência dos dados e o processo de atualização do estado é um requisito para que
haja uma verificabilidade pública. A possibilidade de controlar a transparência das infor-
mações presentes na cadeia com base no participante que as observa é outra vantagem desta
tecnologia, na medida em que pode ser criada a diferenciação entre participantes.
• Privacidade
A privacidade é uma propriedade muito importante de qualquer sistema. Naturalmente
existe uma tensão inerente entre privacidade e transparência, que será desenvolvido adi-
ante. A privacidade é certamente mais fácil de conseguir num sistema centralizado porque
a transparência e a verificabilidade pública não são necessárias para o funcionamento do
sistema.
Como se pode observar há um tradeoff inerente entre a transparência e a privacidade. Um
sistema totalmente transparente permite a qualquer pessoa ver qualquer informação, ou seja, não
há nenhuma privacidade. Por outro lado, um sistema totalmente privado não oferece qualquer
transparência. No entanto, um sistema pode fornecer estas duas propriedades de forma equili-
brado, isto é, fornecer garantias de privacidade significativas e ao mesmo tempo tornar o processo
de transições transparentes.
2.4 Conceitos chave
Categorizar blockchains como privadas ou públicas é útil para identificar as principais ca-
racterísticas de muitos blockchains. No entanto, entender as suas diferenças subtis exige uma
taxonomia mais refinada. De seguida serão abordados quatro conceitos subjacentes, com base nos
quais uma classificação mais detalhada dos sistemas pode ser obtida [5].
Na Tabela 2.1 encontra-se uma lista de blockchains e as suas respetivas propriedades. Os
sistemas assinalados em itálico estão inativos ou em fase de desenvolvimento.
2.4.1 Distributed Ledger
Um ledger é nem mais nem menos do que uma lista ordenada de transações. Numa cadeia
de blocos (blockchain), o ledger é replicado em todos os nós e as transações são agrupadas em
blocos que, por sua vez, se encontram encadeados. Assim, o ledger distribuído é essencialmente
uma estrutura de dados somente anexada e replicada. É, por este motivo, que não é necessário um
componente central para monitorizar e regularizar todas as ocorrências.
Um blockchain inicia com um ou mais estados iniciais e depois o ledger é que regista e arma-
zena todos o histórico de operações/atualizações feitas nos estados.
10 Tecnologia Blockchain
AplicaçãoExecução
Smart ContractLinguagem doSmart Contract
Data Model Consenso
Hyperledgerv0.6.0
AplicaçõesGerais
Dockers Golang, Java Key-value PBFT
Hyperledgerv1.0.0
AplicaçõesGerais
Dockers Golang, Java Key-valueOrdering service
(Kafka)
Bitcoin Crypto-currency Native Golang, C++Transaction
basedPoW
Litecoin Crypto-currency Native Golang, C++Transaction
basedPoW (memory)
ZCash Crypto-currency Native C++Transaction
basedPoW (memory)
EthereumAplicações
GeraisEVM Solidity, Serpent, LLL
Accountbased
PoW
Multichain Digital assets Native C++Transaction
basedTrusted validators
(round robin)
QuorumAplicações
GeraisEVM Golang
Accountbased
Raft
HydraChainAplicações
GeraisPython, EVM Solidity, Serpent, LLL
Accountbased
Trusted validators(majority)
OpenChain Digital assets - -Transaction
basedSingle validator
IOTA Digital assets - -Account
basedIOTA’s Tangle
Consensus
BigchainDB Digital assets NativePython,
crypto-conditionsTransaction
basedTrusted validators
(majority)
MonaxAplicações
GeraisEVM Solidity
Accountbased
Tendermint
Ripple Digital assets - -Account
basedRipple consensus
Kadena Pact applications Native Pact Table ScalableBFT
Stellar Digital assets - -Account
basedStellar consensus
DfinityAplicações
GeraisEVM Solidity, Serpent, LLL
Accountbased
Threshold relay
ParityAplicações
GeraisEVM Solidity, Serpent, LLL
Accountbased
Trusted validators(round robin)
TezosMichalesonapplications
Native MichalesonAccount
basedProof of Stake
Corda Digital assets JVM Kotlin, JavaTransaction
basedRaft
SawtoothLake
AplicaçõesGerais
Native Python Key-value Proof of elapsed time
Tabela 2.1: Comparação de sistemas blockchain (os sistemas em itálico estão inativos ou em fasede desenvolvimento) [5]
2.4 Conceitos chave 11
2.4.2 Criptografia
Para que seja garantida a integridade dos ledgers, os sistemas blockchain recorrem muito a
técnicas criptográficas. A integridade antes falada refere-se à capacidade de detetar adulterações
dos dados e é uma propriedade vital em ambientes públicos onde não há qualquer confiança pré-
estabelecida. A criptografia garante também que o blockchain seja, como já foi referido, um
sistema imutável e inviolável. Como tal, é necessário compreender alguns conceitos chaves da
criptografia usada nos sistemas de blockchain.
2.4.2.1 Hashing
Hashing consiste na produção de uma chave de saída de comprimento fixo através de uma
string de caracteres normalmente mais curta. Serve, portanto, para apresentar a string original de
forma encriptada e basta um carácter da hash ser alterado para que todo o valor inicial deixe de
ter qualquer sentido. O Bitcoin, por exemplo, usa a encriptação SHA-256, onde não importa o
tamanho de entrada visto que o tamanho da saída será sempre o mesmo (64) (Tabela 2.2).
Hello Word9AEA7EB32AEBE6F10C3EC1381C66E18FFD50F20C54E29FD85B5AE159CF80C9D0
FEUP4BD4176A8306523A0C1E60A4C84F5412E199377AA78079CD5346A0EB29EE7F16
My name is Tiago0B987101096E388853BC3EC07720F29C7FEFEAD1995E80BFCE24C954A399FF38
Tabela 2.2: Exemplos de encriptação (SHA-256)
A importância e a facilidade de implementação do hashing deve-se às suas propriedades de:
• Encriptação única
Não interessa o número de vezes que uma string é passada para hash porque esse valor
(hash) será sempre o mesmo.
• Rapidez
A passagem de uma string para a hash correspondente é muito rápida.
• Elevada complexidade
É inviável e quase impossível saber um valor de hash sem ser por tentativa e erro ou, natu-
ralmente, sabendo o valor de input.
• Imutáveis
Uma pequena alteração modifica todo o significado da hash. Por exemplo, apenas alterar
uma letra maiúscula para uma letra minúscula:
12 Tecnologia Blockchain
A 559AEAD08264D5795D3909(...)84FE55590EEF31A88A08FDFFD
a CA978112CA1BBDCAFAC231(...)8147C4E72B9807785AFEE48BB
Tabela 2.3: Prova exemplo de que o hashing é case sensitive (SHA-256)
• Resistente a Colisões
É inviável encontrar duas mensagens diferentes com a mesma hash.
2.4.2.2 Merkle Tree
Após entender o que é hashing, é também importante entender o que é a Merkel Tree e de que
maneira é que desempenha um papel importante a manter a integridade do sistema.
Na Figura 2.3, é possível observar uma Merkle Tree muito simplificada. A Merkle Tree é
composta por leaf nodes, em que cada um desses leaf node contém a hash da sua folha de dados
correspondente.
Figura 2.3: Exemplo de uma Merkle Tree [6]
Entre os leaf nodes e a raiz da árvore é possível ver que os nodes (nós) são compostos pela
concatenação das hash’s dos seus filhos. Por exemplo, a hash de ramificação 0 é o hash dos seus
filhos concatenados, ramificações Hash 0-0 e Hash 0-1. É importante notar que a leaf of “Data
Blocks” não faz parte da árvore.
O exemplo antes dado é a forma mais comum e simples de apresentar uma Merkle Tree e é
conhecida como a Binary Merkle Tree. Como é possível observar há um hash superior que é, nem
mais nem menos, o hash da árvore inteira (Top Hash). Isto faz com que as Merkles Trees, apesar
de possuírem “n” número de hashes, possam ser representadas através de uma hash única.
2.4 Conceitos chave 13
A estrutura da árvore permite o mapeamento eficiente de grandes quantidades de dados e a
identificação eficaz do local onde ocorreram mudanças de dados.
Caso o hash raiz seja conhecido e confiável, é possível que qualquer utilizador, usando uma
prova de Merkle, verifique a posição e a integridade de um dado dentro de um banco de dados.
Uma das qualidades mais importantes da estrutura da Merkle Tree é a capacidade de autenticar
conjuntos arbitrariamente grandes de dados com um mecanismo idêntico ao usado para verificar
quantidades muito menores.
A Merkle Tree é, portanto, vantajosa para distribuir grandes conjuntos de dados em partes
menores, onde é mais fácil verificar a integridade dos dados, mesmo que o tamanho geral destes
seja elevado.
2.4.2.3 Patricia Trie
A Patricia Trie, também chamada de Prefix Tree, Radix Tree ou apenas de Trie usa uma key,
como um caminho, de tal modo que todos os nós que partilham o mesmo prefixo partilhem também
o mesmo caminho.
Figura 2.4: Exemplo de uma Patricia Trie [7]
Por apresentarem uma estrutura rápida a encontrar os prefixos comuns, por ser simples de
desenvolver e por requerer pouca memória, é que esta estrutura é muito usada para implementar
tabelas de roteamento, por exemplo num router.
2.4.3 Consenso
Como já foi dito anteriormente a maioria dos blockchains, para além de terem muitas coisas
em comum, funcionam todos de maneira semelhante. Uma das formas pelas quais os blockchains
podem ser únicos é a maneira como o consenso é alcançado, ou seja, como é realizada a veracidade
e a legitimidade das transações adicionadas.
Existem vários mecanismos de consenso que são utilizados em sistemas que possuem a tec-
nologia blockchain. Uma vez que o foco da dissertação não incide sobre qual o mecanismo a ser
usado apenas serão aprofundados alguns dos principais [8], [9].
14 Tecnologia Blockchain
Na Tabela 2.4, são apresentados outros algoritmos mais utilizados bem como algumas das suas
características principais.
Algoritmo Definição PrincipaisCasos de Uso
Proof of Work(PoW)
Os nós têm de recorrer ao poder computacionalpara que possam descobrir um hash (por tentativaerro) que satisfaça uma determinada condição,para um determinado bloco. Quando um nó encontraeste hash ganha permissão para estender o blockchaincom esse bloco. Ao mesmo tempo é responsável poravisar os outros nós e de lhes transmitir a nova cadeiapara que estes não trabalhem sobre um bloco que jáfoi solucionado. O nó responsável por acrescentar umnovo bloco recebe uma recompensa.
BlockchainsPúblicos
(Bitcoin e outrascriptomoedas)
Proof of Stake(PoS)
Os mineradores apostam inicialmente os seus tokens decriptomoedas no bloco que querem incluir no blockchain.Ao fazerem esta aposta estão automaticamente aptospara "minar"o respetivo bloco. A probabilidade de issoacontecer é diretamente proporcional com a quantidadeque aposta relativamente à soma de apostas realizadaspelos outros utilizadores. (ex: Se o Daniel colocar 30tokens e ao todo forem apostados 100 tokens, o Danieltem 30% de chance de minar o bloco)
BlockchainsPúblicos
eBlockchainsFederados
Proof of Elapsed Time(PoET)
Cada participante da rede recebe um tempo aleatório deespera, e o primeiro participante a terminar a sua esperarecebe o próximo bloco.
BlockchainsPrivados
eBlockchainsFederados
Tabela 2.4: Algoritmos de consenso mais utilizados na tecnologia blockchain
2.4.4 Smart Contracts
Um smart contract é um protocolo informatizado em código, executado em cima da tecnolo-
gia de um blockchain e projetado para facilitar, verificar e reforçar a negociação ou a execução de
um contrato. Este contrato apresenta sempre um conjunto de regras sob as quais as partes desse
contrato concordam em interagir umas com as outras. Caso estas regras sejam cumpridas, o con-
trato será automaticamente aplicado. Apesar de serem considerados inteligentes, estes contratos
não devem ser confundidos com os contratos jurídicos aceites pelos tribunais e/ou aplicações da
lei.
A forma mais primitiva de um smart contract é uma máquina de venda automática, onde as
regras de compra e venda são programadas à priori e verificadas antes, durante e após cada pedido
de compra. Ao selecionar um produto através do seu número correspondente e inserir as moedas, a
2.4 Conceitos chave 15
máquina apenas executa o contrato programado anteriormente, que funciona de forma inteligente,
na medida em que vai confirmar se foi colocado o dinheiro mínimo para o levantamento do produto
ou se foi colocado dinheiro a mais e que quantidade é necessária devolver. A criação destes smart
contracts e das respetivas máquinas de venda automática permitiram a redução de custos, bem
como a oferta de um serviço de disponibilidade absoluta (24 horas por dia e 7 dias por semana).
Por vezes, mesmo sendo considerados inteligentes, estes contratos precisam de validação ex-
terna uma vez que o blockchain não consegue procurar nem verificar ocorrências fora da rede. Isto
é conseguido por agentes designados de “oráculos” (oracles) que serão explicados mais à frente.
Os smart contracts são um conjunto de programas: [10]
• Auto verificáveis;
• Auto executáveis;
• Resistentes à adulteração.
E a sua utilização pode trazer inúmeros benefícios, como por exemplo:
• Atualizações em tempo real;
• Maior grau de segurança;
• Menor risco de execução;
• Reduzir a dependência de intermediários confiáveis;
• Menores custos de transação.
2.4.4.1 Blockchain Oracles
Um oracle, no contexto da tecnologia blockchain, é um agente que localiza, verifica e envia
ocorrências do exterior da rede para o interior da mesma para que estas informações possam ser
utilizadas por smart contracts [11].
Estas ocorrências externas podem ser nem mais nem menos que informações relativas a tem-
peraturas, conclusões de pagamentos, alterações de preços, peso, etc.
Os oracles são portanto a única maneira de os smart contracts interagirem com dados fora do
ambiente blockchain.
Existem alguns tipos de oracles, entre os quais:
• Software oracles - Operam com a informação disponível online e de livre acesso como por
exemplo, atrasos de aviões, meteorologia ou preços de mercadorias.
• Hardware oracles - Operam com informação retirada no terreno através de sensores como
por exemplo sensores RFDI que depois informam a rede blockchain que mercadorias aca-
baram de ser produzidas e as suas especificações.
16 Tecnologia Blockchain
• Inbound oracles - São responsáveis por fornecer aos smart contracts informações externas.
Por exemplo, adquirir uma determinada quantidade de Bitcoins, caso a mesma atinja um
determinado valor no mercado.
• Outbound oracles - Ao contrário do caso anterior os outbound oracles permitem aos smart
contracts enviar dados para o exterior. Por exemplo, o envio de um aviso de que um de-
terminado pagamento foi realizado com sucesso para depois desencadear uma determinada
operação no mundo real.
• Consensus based oracles - Com base noutros oracles e num algoritmo de consenso é retor-
nada uma informação fidedigna. Por exemplo, 10 sensores ao longo de um tapete de uma
fábrica para garantir que a temperatura das peças que por ele passam é sempre a mesma.
2.4.4.2 Exemplo de Implementação
Para escrever um smart contract é necessário usar uma Smart Contract Language (SCL), seja
para escrever diretamente ou para compilar. Um exemplo de uma SCL pode ser o Solidity, que é
uma linguagem de alto nível, orientada a contratos e desenvolvida para executar smart contracts
no Ethereum Virtual Machine (EVM). Esta linguagem possui uma sintaxe muito semelhante à
do JavaScript. O exemplo dado de uma máquina de vendas automáticas pode ser traduzido num
smart contract simples (usado apelas para fins de demonstração) (Figura 2.5).
Figura 2.5: Exemplo de implementação de um Smart Contract [12]
• insertCoin: Função pública que é chamada quando o utilizador insere uma moeda.
• releaseProduct: Função privada que fornece o produto quando o utilizador insere o valor
necessário para comprar o produto.
2.4 Conceitos chave 17
2.4.5 Verificação
Para que uma transação seja adicionada a um bloco e o respetivo bloco adicionado à cadeia
é necessário verificar a veracidade da transação, ou seja, é necessário verificar a identidade do
remetente, se é mesmo o próprio a solicitar ou se é outra pessoa no seu lugar.
Por exemplo, quando o Paulo envia à Joana 100 euros, este pedido de transação chega a um
intermediário que faz de verificador.
Este intermediário tem como função verificar que o pedido está mesmo a ser realizado pelo
Paulo e não por outra pessoa. A figura 2.6 esquematiza esta verificação.
Figura 2.6: Como um sistema de verificação verifica se a transação é solicitada pelo verdadeiroremetente
Para realizar esta verificação são necessárias dois tipos de chaves, públicas e privadas, conhe-
cidas como assinaturas digitais. Qualquer utilizador que queira realizar uma transação precisa de
usar a sua chave privada para “assinar” a transação, e considera-se a sua transação e a sua chave
privada como entradas para uma função de sinal que cria uma assinatura. Em blockchain o algo-
ritmo usado para criar uma assinatura para cada transação é o algoritmo de assinatura digital da
curva elíptica (Elliptic Curve Digital Signature Algorithm (ECDSA)).
De seguida, tanto esta assinatura como a transação são enviadas para o verificador que verifica
se essa entidade pertence à pessoa correta ou não, usando a chave pública do remetente, que é
conhecida por todos.
18 Tecnologia Blockchain
Posteriormente, a transação, a assinatura do remetente e a chave pública do mesmo são inseri-
das numa função de verificação para obter um resultado booleano (verdadeiro ou falso).
Como a assinatura em cada transação contém 256 bits a única maneira para falsificar é adivi-
nhar o único caso entre 2256 casos que funciona.
Para além de verificar a veracidade do remetente, o verificador também tem como função
verificar se o remetente tem em sua posse os fundos que pretende enviar ao destinatário.
2.5 Arquitetura Blockchain
A arquitetura de um sistema blockchain é, como o nome indica, uma série de blocos (blocks),
que se encontram ligados sequencialmente um ao outro como uma corrente (chain). Cada bloco
contém muitas transações, que são validadas, conforme mostrado na subsecção 2.4.5.
A Figura 2.7 apresenta de uma forma simples e esquematizada um exemplo de uma blockchain.
Figura 2.7: Exemplo de um blockchain [13]
Na Figura 2.8 é possível observar ao pormenor a arquitetura presente num bloco, que é com-
posto essencialmente por:
• Prev_Hash:
Esta é uma hash que faz ligação ao bloco anterior. É gerada através de uma função hash na
qual são introduzidas todas as informações do bloco anterior.
• Timestamp:
A hora a que o bloco foi encontrado.
• Tx_Root:
Este campo é conhecido como a Merkle Root (raíz Merkle), explicada da subsecção 2.4.2.2,
que contém o valor de hash de todas as transações validadas presentes no bloco. Como é
2.5 Arquitetura Blockchain 19
possível observar na Figura 2.7, todas as transações são representadas com um valor hash
que depois combina com outro hash (correspondente a outra transação) e é inserido noutra
função hash (em árvore). Este processo é repetido até que haja apenas uma entidade, a
Merkle Root.
• Version:
Corresponde à versão do protocolo usada pelo bloco.
• Nonce:
Este campo é usado no PoW, abordado na subsecção 2.4.3, que indica o esforço que um nó
teve para obter o direito de acrescentar o seu bloco à cadeia.
• Bits:
Este campo indica o nível de dificuldade do PoW.
Figura 2.8: Arquitetura interna de um bloco [9]
20 Tecnologia Blockchain
2.6 Tipos de Blockchain
Figura 2.9: Tipos de Blockchain
Existem essencialmente três tipos de blockchain:
• Blockchain Público;
• Blockchain Privado;
• Blockchain Federado/Consórcio.
Estes três tipos de blockchain apresentam características muito distintas no que toca à autori-
zação que os utilizadores têm e à centralização da rede.
Assim, antes da análise dos três tipos de blockchain importa analisar quer a autenticação quer
a centralização da rede.
Autorização
Relativamente à autorização as redes podem-se classificar em dois tipos:
Permissionless
Uma rede sem permissão é uma rede aberta onde qualquer utilizador pode entrar, ler, gravar
e verificar transações uma vez que não há uma autoridade central. Embora as transações pos-
sam ser lidas por qualquer utilizador, também é possível bloquear quaisquer tipo de informações
confidenciais [14].
Este sistema faz sentido quando ninguém quer usar um terceiro confiável (TTP). A confiança
entre os pares é estabelecida através do mecanismo de consenso acordado por ambos [15].
Para além de deixar que todos os interessados entrem na rede, há algumas características deste
modelo que são importantes, tais como:
2.6 Tipos de Blockchain 21
• Descentralização: O sistema deve ser descentralizado para que nenhuma entidade possa
derrubar a rede ou censurar partes dela. Este aspeto depende dos seus membros ,uma vez
que as redes sem permissão são baseadas em algoritmos de consenso. Qualquer tipo de
alteração na rede pode ser alcançada, desde que 50% + 1 dos participantes concordem com
isso.
• Transparência: É uma característica necessária para que os participantes sejam encorajados
a confiar na rede. Por este motivo é que uma rede transparente precisa de fornecer livre
acesso aos seus participantes.
• Tokens: Esta é também uma característica muito importante, dado que é graças a este incen-
tivo que os participantes continuam interessados em continuar a trabalhar na rede. O valor
destes tokens pode crescer ou cair, dependendo da relevância e o estado do blockchain a que
pertencem. Podem ser tokens de valor monetário ou tokens de utilidade.
• Anonimato: Tanto os mineiros como os outros participantes podem permanecer anónimos.
Em certos casos, e por questões legais, têm que fornecer algumas informações pessoais. Por
exemplo, o Bitcoin não oferece um anonimato absoluto porque a identidade do usuário está
indiretamente ligada aos endereços dos quais eles têm as chaves privadas.
Permissioned
Neste caso, os utilizadores necessitam que a autoridade central lhes conceda permissões para
ler, gravar e/ou verificar transações. Neste tipo de rede, o consenso é obtido de uma maneira mais
rápida e eficiente porque nem todos os utilizadores têm acesso a gravar dados.
À semelhança das redes permissionless, as redes permissioned também têm características
relevantes, como, por exemplo:
• Descentralização Variável: A qualidade da descentralização depende dos participantes da
rede. Estes encontram-se livres para negociar e para decidir o nível de descentralização da
mesma.
• Transparência: Depende da maneira como o blockchain e as relações comerciais são criadas.
Os blockchains privados não necessitam de ser transparentes, no entanto podem optar por
fazê-lo, dependendo da organização interna dos negócios.
• Anonimato: Oferecem um controlo de acesso mais controlado. Alguns blockchains priva-
dos, apesar de "privados", armazenam toda a informação relativa às transações e às opera-
ções realizadas pelos usuários.
• Tokens: Pode ou não haver troca de tokens monetários, depende da natureza da rede de
negócios.
22 Tecnologia Blockchain
• Administração: É decidida pelos membros da rede de negócios. Não há necessidade de
utilizar algoritmos de consenso, uma vez, que toda a rede deve concordar com a mudança.
Centralização
Em primeiro lugar é necessário definir o que é uma rede. De forma sucinta, é um sistema resul-
tante da ligação de muitos sistemas conectados uns aos outros que permite compartilhar recursos
entre eles.
Figura 2.10: Centralizada vs Descentralizada vs Redes Distribuídas
A maneira como estes sistemas estão ligados entre si é que pode diferir (Figura 2.10). Existem
tipos diferentes de rede como as centralizadas, as descentralizadas e as completamente distribuí-
das.
• Centralizada
Como sistematizado na Figura 2.10, nesta rede, e como o nome indica, há um elemento
central, chamado de dono. O proprietário da rede centralizada é o ponto de contacto de
todos os outros sistemas, responsável pela partilha de todas as informações e o único que
possui cópia das transações. Precisamente por ser o único, com uma cópia dos recursos, é
que qualquer pedido de acesso leva a um delay significativo. Sendo que o ponto central das
operações é também considerado o único ponto de falha.
• Descentralizada
Em contraste com uma rede centralizada, uma rede descentralizada apresenta vários propri-
etários. Estes proprietários possuem todos uma cópia dos recursos o que elimina o problema
do ponto único de falha.
Com vários proprietários, se um falhar não compromete a rede toda, uma vez que a infor-
mação pode ser acedida a partir dos outros nós.
2.6 Tipos de Blockchain 23
• Distribuída Uma rede distribuída é uma rede descentralizada ao extremo. Este tipo de rede
extrema evita a centralização por completo. A ideia principal por trás deste tipo de rede é a
de que todos têm acesso e todos têm um acesso igual [16].
Atualmente as duas redes mais conhecidas e utilizadas são as públicas e as privadas. Muitas
das vezes estes dois tipos de redes são confundidos devido a algumas semelhanças, tais como:
• São redes peer-to-peer descentralizadas onde cada participante possui uma réplica de um
ledger composto por todas as transações compartilhadas;
• Mantêm as réplicas todas sincronizadas por meio de algoritmos de consenso;
• Ambos garantem a imutabilidade do ledger, independentemente das intenções de cada par-
ticipante.
2.6.1 Blockchain Público
Como o nome indica, um blockchain público é inteiramente aberto para todos os participantes
e possíveis interessados, uma vez que:
• Ninguém necessita de ter e/ou de pedir permissão para participar;
• Todos têm o direito de fazer download do código e correr em qualquer nó público no seu
dispositivo pessoal;
• Todos têm o poder de verificar o seu status atual e de decidir se querem, ou não, adicionar
blocos à cadeia.
Vantagens
• Os servidores não necessitam de manutenção;
• Protegem os utilizadores dos developers, na medida em que estabelece diversas ações que
nem os developers têm permissão;
• Não têm necessidade de verificação por parte de terceiros [17].
Por outro lado, tem como inconvenientes a necessidade de um grande poder computacional e o
elevado consumo de energia elétrica.
Atualmente, a rede pública de blockchain mais conhecida é o Bitcoin mas existem outras como
o Monero [18], Ethereum [19], Dash [20] e Dogecoin [21].
24 Tecnologia Blockchain
2.6.2 Blockchain Privado
Em contraste com um blockchain público, num blockchain privado as permissões de escrita
estão atribuídas a uma organização. As permissões de leitura podem ser públicas ou restritas a
certos participantes.
Vantagens
• Quem comanda o blockchain pode a qualquer altura reverter transações, modificar saldos,
alterar regras, etc;
• Os validadores são conhecidos;
• As transações são mais baratas, uma vez que apenas precisam ser verificadas por alguns nós
que podem ser confiáveis, o que possibilita um processamento elevado. Não têm necessi-
dade de ser verificados por milhares de nós;
• Maior privacidade dado que as permissões de leitura são restritas;
• Facilidade em manipular documentos.
Por outro lado, o risco de ocorrer uma quebra na segurança é muito maior. A Multichain [22] e
MONAX [23] são dois exemplos de redes de blockchain privadas.
2.6.3 Blockchain Federado/Consórcio
Neste tipo de redes o processo de consenso é, como o nome indica, através de um consórcio.
Por exemplo, um conjunto de dez instituições bancárias, em que cada uma opera um nó e das quais
seis devem assinar cada bloco para que este seja validado.
Relativamente ao direito de leitura este pode ser público ou restrito para participantes.
Vantagens
• Custos de transação reduzidos;
• Reduz a redundância de dados;
• Simplifica o manuseamento de documentos legais e elimina os mecanismos de conformi-
dade manuais [17].
Atualmente, a R3 (bancos) [24] e EWF (Energia) [25] são duas empresas que usam blockchains
de consórcio.
Sistematizando temos a Tabela 2.5 que compara os três tipos de rede blockchain principais.
2.7 Blockchains vs Centralized Databases 25
Público Privado Consórcio/Federada
Gestão da Rede Descentralizada CentralizadaHíbrido
(Múltiplas organizações)
Acesso Qualquer utilizador(não necessita permissão)
Apenas para membrosUtilizadores qualificados
através de aprovação
Segurança Mecanismos de consensoParticipantes pré-aprovados
Consenso em várias partes
Participantes pré-aprovados
Consenso em várias partesVelocidade de
Transação Lenta Leve e rápida Leve e rápido
Número deUtilizadores Milhões Dezenas a poucas centenas Centenas de milhares
Benefícios
Elevada segurança(transações verificadas
por toda a rede)
Transparência(transações públicas e anónimas)
Eficiente(verificação realizada apenas
pelo proprietário da rede)
Privada
Eficiente
Privado(o acesso a escrita e leitura
é controlado)
Não há consolidação dopoder de controle
DesafiosIneficiente
(todos os nós têm de verificaras transações)
Consolidação do poder
Difícil colaborar comdiferentes organizações
Tabela 2.5: Blockchain Público vs Privado vs Consórcio/Federado
2.7 Blockchains vs Centralized Databases
Tabela 2.6: Permissionless vs Permissioned vs Central Database [4]
Como referido, a implementação e a manutenção de soluções baseadas em blockchain apre-
sentam, ainda, um custo e um risco elevado, tanto ao nível humano como ao nível computacional.
O facto de o blockchain armazenar muitas cópias ao longo da rede e de o número de pedidos
processados ser elevado faz com que o desempenho seja menor e mais lento.
A decisão de escolha de soluções baseadas em blockchain, nem sempre é fácil, atendendo a
outras opções existentes. Assim, a escolha requer uma análise cuidada dos requisitos do sistema.
A escolha que muitas das empresas fazem quando surge esta questão é a de adotar os dois
tipos, isto é, equilibrar os problemas de desempenho, aproveitando os benefícios do blockchain,
26 Tecnologia Blockchain
não armazenando todos os registos de dados no blockchain, mas apenas a hash do registo. Isso
serve para determinar, com um alto nível de confiança, se os dados foram comprometidos.
Uma decisão precipitada pode levar ao risco de grandes perdas de dinheiro. Existem diversos
fluxogramas nos quais algumas empresas de consultadoria se baseiam, entre eles, o mais utilizado,
é o do Departamento de Segurança Interna dos Estados Unidos (DHS) - Figura 2.11).
Figura 2.11: Blockchain Vs Base de Dados [26]
2.8 Blockchain Frameworks 27
2.8 Blockchain Frameworks
Tendo em conta os diversos trabalhos desenvolvidos nesta área, não é necessário, na maioria
dos casos, construir um blockchain de raiz. Esta secção serve para entrar em detalhe e explicar
alguns dos frameworks mais importantes e a sua aplicabilidade em casos específicos.
Ethereum
A Ethereum é uma plataforma descentralizada capaz de executar smart contract e aplicações
descentralizadas (DApps), tendo por base a tecnologia blockchain. É uma plataforma que imple-
menta uma linguagem de programação Turing-complete que por sua vez permite a existência de
código armazenado na norma de "contratos"[27].
Hyperledger
O Hyperladger é fruto de um projeto iniciado em 2005 pela Linux Fundation e é nem mais
nem menos que um hub para o desenvolvimento de blockchain industrial em código aberto [28].
Atualmente este projeto colaborativo abrange mais de 100 membros dos mais diferentes seto-
res de atividade:
• Tecnologia da mobilidade (Airbus e Daimler)
• Empresas IT (SAP, IBM, Fujitsu, Intel e Samsung)
• Instituições financeiras (American Express, BBVA e BNP Paribas)
• Startups especializadas em blockchain (Blockstream, Factom e Consensys)
Atualmente a estratégia do Hyperledger passa por promover uma vasta gama de tecnologias de
negócios, framework, bibliotecas, interfaces e aplicativos. A Hyperleger é o anfitrião dos seguintes
projetos:
• Sawtooth Hyperledger (conjunto modelar desenvolvido pela Intel que usa um novo algo-
ritmo de consenso chamado Proof of Elapsed Time (PoET));
• Hyperledger Iroha (projeto criado em parceria com algumas empresas japonesas para faci-
litar a incorporação de frameworks num blockchain);
• Hyperledger Fabric (projeto liderado pela IBM. Trata-se de uma implementação plug and
play para o desenvolvimento de blockchain a grandes escalas com uma grande flexibilidade
de permissões);
• Hyperledger Composer (BBN, Blockchain Business Networks);
28 Tecnologia Blockchain
• Hyperledger Explorer (desenhado para facilitar a criação de aplicações Web user-friendly);
• Hyperledger Indy (coleção de ferramentas, bibliotecas e outros componentes para identida-
des digitais baseadas em blockchain).
Corda
Corda é uma plataforma blockchain de código aberto usada para registar, gerir e sincronizar
contratos e transferir valor. A nova proposta da Corda baseia-se na utilização de um consenso
plausível por notários conectados que fornecem garantias independentemente do algoritmo que
usem [29].
ShipChain
Embora seja conhecida pelos benefícios no Supply Chain Management, esta plataforma é pro-
jetada como uma permissioned Ethereum side-chain. É também apresentada como uma plataforma
específica para redes de transporte marítimo [30].
BigChainDB
BigchainDB é um banco de dados descentralizados open-source que se destina à transição
digital de ativos. Possui grandes velocidades de transação comparativamente a outros blockchains
contemporâneos por possuir o seu próprio algoritmo de consenso [31].
Modum
A Modum oferece diversas soluções de última geração para a inteligência e para a Supply
Chain através da criação de ecossistemas digitais com tecnologia de sensores IoT e blockchain,
para diversas aplicações. Por exemplo, sensores de temperatura e de humidade para garantir certi-
ficações governamentais nas empresas farmacêuticas ou alimentares [32].
IOTA
IOTA é uma plataforma blockchain que tem como objetivo principal a criação de um ecossis-
tema seguro e descentralizado para a Internet das Coisas (IoT). Esta plataforma parte do princípio
de que, à medida que mais dispositivos comuniquem entre si, mais rápido as transações são reali-
zadas entre os mesmos, dado que, em vez de haver uma cadeia de blocos relacionada aos blocos
2.8 Blockchain Frameworks 29
anterior e seguinte, há um sistema que funciona como uma grade de blocos inter-relacionados
[33].
Quorum
O Quorum é uma versão do Ethereum mais focada no ambiente empresarial. O objetivo do
Quorom é fazer o mínimo de modificações possíveis no cliente Ethereum para facilitar a sincroni-
zação de novas versões. O Quorum foi também concebido para qualquer aplicativo que exija um
processamento de altas velocidades e de alto rendimento de transações particulares dentro de um
grupo permissioned de participantes conhecidos [34].
Ripple
A plataforma Ripple serve para os utilizadores enviarem dinheiro, usando o poder do block-
chain. A Ripple, alega que: "connects banks, payment providers, digital asset exchanges and
corporates via RippleNet to provide one frictionless experience to send money globally"[35]. A
empresa afirma também que possuem o melhor algoritmo de consenso (Ripple Consensus Algo-
rithm) que lhe permite ser a melhor plataforma blockchain orientada a ativos financeiros e a que
apresenta as melhores velocidades de transação [36].
Capítulo 3
Casos de Estudo por Setores
A tecnologia blockchain apresenta, como referido no capítulo anterior, diversas vantagens de
utilização e, como tal, pode ser aplicada em diversos negócios, independentemente da dimensão,
do objetivo, do setor e dos tipos de processos presentes.
Nas seguintes secções são abordadas algumas das empresas analisadas, categorizadas nos se-
guintes setores:
1. Setor Agricultura
2. Setor Automóvel
3. Setor da Administração Pública
4. Setor da Educação
5. Setor da Saúde
6. Setor dos Media
7. Setor Energético
8. Setor Financeiro
9. Setor Gaming
10. Registo de Propriedade
11. Filantropia e Ajuda Humanitária
31
32 Casos de Estudo por Setores
3.1 Setor Agricultura
Apesar da tecnologia blockchain ser considerada uma tecnologia emergente, tem-se verificado
um significativo aumento de investimentos em blockchain.
A aplicação dessa tecnologia neste setor pode garantir a rastreabilidade e também melhorar a
transparência e a eficiência dos agentes em toda a cadeia, desde os agricultores até aos consumi-
dores.
Atualmente, a maioria das empresas recorre a uma base de dados ou a material impresso para
armazenar e gerir todos os dados relacionados com a segurança, sustentabilidade e burocracias
[37]. Esta estrutura resulta em custos operacionais muito elevados, alto potencial para corrupção
ou erro (humano e/ou tecnológicos).
A WHO estima que uma em cada dez pessoas adoece todos os anos devido ao consumo de
alimentos contaminados [38].
Existem diversos casos de utilização desta tecnologia neste setor, tal como existem empresas
específicas viradas para cada objetivo. O foco da maioria das empresas nesta área pode ser dividido
em:
• Rastreabilidade (ex: Grass Roots and ripe.io)
• Otimização da Food Supply Chain (ex: Agrichain)
• Transações (ex: Agridigital and AdriLedger)
• Seguro de colheitas (ex: ETHERISC and WorldCover)
Rastreabilidade- Ajuda a diminuir o desperdício alimentar- Disponibiliza toda a informação desde a produção ao transporte-Melhora a relação consumidor/produtor
Otimização daFood Supply Chain
- Permite uma melhor otimização das quantidades e dos preços- Possibilita a encomenda de quantidades mais racionais- Facilita a rapidez na troca de informações
Transações- Permite comodidade e rapidez nos pagamentos- Implica menos taxas de transação
Seguro de Colheitas- Regista as partes envolvidas, o preço, a data, a localização e a qualidade- Possibilita a segurança de documentos- Aumenta a visibilidade da supply chain
Tabela 3.1: Possíveis vantagens da aplicação da tecnologia no setor da agricultura
3.1 Setor Agricultura 33
AgriDigital
No negócio relacionado com a agricultura, na maioria dos casos, os agricultores assumem o
risco de entregar (vender) as suas colheitas a um comprador e esperar algumas semanas para que
o pagamento seja realizado.
A AgriDigital é uma empresa australiana com uma plataforma de gestão de mercadorias base-
ada na nuvem, que conecta agricultores e participantes da cadeia de valor. Esta plataforma é capaz
de criar um ativo programável (token) para representar uma mercadoria física desde um produtor
até um comprador. Cada transação realizada nesta plataforma é rastreada de forma imutável com
todos os dados referentes à mesma (localização, custo, tempo, etc.) anexados a esse token, e os
pagamentos que ocorrem em tempo real por meio de smart contracts.
Nesta plataforma quando um agricultor entrega os seus bens a um comprador ocorre de forma
quase instantânea uma "troca atómica". O token digital representa os bens transferidos no exato
momento em que o pagamento é realizado.
Grass Roots Cooperative
A Grass Roots, cooperativa agrícola sediada em Arkansas (USA), tem como objetivo e/ou
compromisso melhorar as ligações diretas entre produtores e consumidores, bem como aumentar
a transparência e a rastreabilidade.
O objetivo passa por dar ao consumidor de produtos alimentares da Grass Roots a experiência
mais personalizada e transparente possível.
Em parceria com a empresa Provenance e com o apoio da Heifer USA lançou no final de 2017
um aplicativo que permitia a qualquer utilizador comum, fotografando um código barras, rastrear
um pacote de frango embalado. O consumidor teria assim a certeza de que o produto não tinha
sido falsificado ou adulterado.
34 Casos de Estudo por Setores
3.2 Setor Automóvel
Atualmente a industria automóvel enfrenta grandes desafios, desde as recalls em massa às
falsificações de materiais. O blockchain pode ter impacto na indústria automóvel em diversos
sentidos:
• Otimização de recall dos veículos: Dado que todas as partes do veículos são vinculadas a
um número VIN (Vehicle Identification Number) exclusivo, apenas os veículos com essas
partes específicas em estado defeituoso são recuperados (ex: AMO).
• Loyalty-Based Microtransactions: Registam todas as compras e informações do cliente que
depois lhes permite criar e distribuir materiais de marketing personalizados para um cliente
específico (ex: loyyal e a DAV).
• Transferência de Propriedade: Aumenta a velocidade e a transparência do processo de
transação de veículo (ex: BIGCHAIN).
• Seguros: Automatiza os processos de criação ou renovação de seguro, bem como todas as
informações do motorista, desde acidentes, multas e distância percorrida (ex: GEM e a One
Car Payment).
• Financiamento automático: Independentemente de o pedido de compra ser de uma em-
presa, de uma pessoa individual ou de um dealer o processo é praticamente automático,
desde a transferência de dinheiro até ao preenchimento de todos os dados para que o negó-
cio seja efetuado (ex: Mahindra).
• Supply Chain Management: Consiste em rastrear todo o processo dos materiais desde a
compra das matérias primas até ao fabrico do carro. Isto permite garantir que não haja
materiais falsificados no meio do processo (ex: Car Vertical e a Toyota).
3.2 Setor Automóvel 35
Car Vertical
A Car Vertical é uma startup que tem como objetivo principal resolver o problema de a trans-
parência sobre o histórico dos veículos ser quase nula [39].
Quando uma pessoa compra um veículo novo, considerando que as marcas são totalmente fiéis
e vendem produtos 100% fidedignos, a pessoa sabe exatamente o que está a comprar. Que nada
foi danificado, partido ou reparado.
O mesmo não acontece com a pessoa que compra um veículo que teve 2, 3 ou 5 donos. Esse
novo dono nunca terá acesso ao histórico do seu “novo” veículo, nem, assim, saber se o número
de quilómetros anotado é o real, se tem peças substituídas ou reparadas de acidentes, se tem peças
falsificadas ou ainda se possui ou não todos os airbags. Mesmo que as companhias de seguros
tenham todos, ou quase todos, os acidentes que o veículo sofreu esses dados nunca são fornecidos
ao novo comprador.
Este é um dos problemas que a Car Vertical se compromete a combater. Possuindo 15000
ETH, a empresa criou uma plataforma onde a história de cada veículo é registada no blockchain
e onde ninguém consegue manipular ou falsificar os dados. A empresa afirma também que vai
recolher o maior número de informações sobre o maior número possível de veículos para que
qualquer novo utilizador consiga, numa situação futura, aceder ao histórico do seu veículo. Outra
funcionalidade presente na plataforma da Car Vertical é a procura de carros roubados [40].
AMO Fundation
A AMO é uma plataforma que recolhe, processa e analisa toda a informação de carros e dos
seus respetivos proprietários [41]. A empresa propõe ao mercado um ecossistema onde todas as
informações são encriptadas e posteriormente transacionadas, com o consentimento dos utilizado-
res, para as grandes empresas do setor.
Isto implica que todas a informações dos utilizadores, fabricantes e prestadores de serviços
relevantes estejam sob controlo centralizado de empresas específicas.
Esta foi uma das primeiras empresas a propor a utilização de VIN’s, Vehicle Identification
Number, para recalls direcionados e para que tanto os utilizadores como as marcas saibam as
peças que foram trocadas pelos proprietários [42].
36 Casos de Estudo por Setores
3.3 Setor da Administração Pública
Alguns dos benefícios referidos, tais como a maior transparência, a redução de fraudes (negó-
cios paralelos), a partilha ilícita de dados, favorecem o desenvolvimento de aplicações de extrema
importância para a administração pública, entre as quais:
• Votação Eletrónica: Para impedir a realização de dois votos pela mesma pessoa ou sim-
plesmente impedir a falsificação de um voto;
• Gestão de Informação Pessoal: Permite a gestão e armazenamento de toda a identidade
dos cidadãos;
• Controlo de Acesso: Controlo de acesso lógico e físico a diferentes serviços públicos com
a possibilidade de rastreabilidade dos registos;
• Controlo de Ativos: Implantação de sistemas de controlo de ativos em diferentes níveis de
administração com a possibilidade de manter um histórico de vida dos ativos registados.
Finlândia e Estónia - Bitnation
A Bitnation [43] é uma plataforma que procura oferecer voluntariamente a todos os cidadãos
do mundo (qualquer um se pode tornar membro da Bitnation) os serviços que qualquer governo
disponibiliza, mas de um modo descentralizado (Mattila, 2016). Esta plataforma desenvolveu o
Bitnation Refugee Emergency Response (BRER) [44], que fornece identificações de emergência,
em situações de necessidade, permitindo o acesso à assistência social e aos serviços financeiros.
Foi neste contexto que, em 2017, a Finlândia solucionou a chegada de inúmeros refugiados. Para
tal, foram entregues aos refugiados cartões de débito pré-pagos, aos quais foram associadas as suas
identidades, recorrendo à tecnologia blockchain, permitindo-lhes, assim, o acesso aos serviços
acima referidos.
A Bitnation colabora ainda com o programa e-Residency [45] na Estónia, que permite aos
cidadãos, tanto da Estónia como de fora, aceder aos serviços locais, através de um cartão de
identificação que contém arquivos incorporados e usa uma criptografia de chave pública de 2048
bits. Assim sendo, possibilita-lhes a gestão de negócios fora do país, eliminando burocracias, com
impactos, também, ao nível empresarial.
3.4 Setor da Educação 37
Votem
Votem é uma empresa sediada em Cleveland que trabalha para o governo do estado de Montana
na emissão e na rastreabilidade de votos móveis e on-line emitidos por eleitores deslocados.
Este projeto visa combater a grande taxa de abstenção, seja dos que estão longe do estado como
oficiais militares aos que não querem sair de casa, por preguiça ou por razões de saúde. Desta
forma as pessoas conseguem transformar as suas cédulas de identificação em formato eletrónico
e votar quando as eleições estiverem a decorrer. A grande vantagem da utilização do blockchain
neste caso é a rastreabilidade instantânea e o facto de tornar os votos únicos e impossíveis de editar.
Outra vantagem é o facto de todos os votantes verificarem se o seu voto foi lançado e contado.
Em Montana, de acordo com análises pós-eleitorais da empresa, 99% dos votantes que usaram
o novo sistema mostraram interesse em repetir o procedimento nas próximas votações. O objetivo
da Votem passa por aplicar esta plataforma a todos os estados dos EUA e abranger a totalidade dos
seus votantes.
3.4 Setor da Educação
A aplicação da tecnologia blockchain na educação tem como objetivo fornecer aos alunos e
aos docentes registos mais seguros, imutáveis e de fácil verificação. É uma forma mais eficiente
de aceder aos registos, de reduzir a carga administrativa e ainda de diminuir os custos associados
a essas verificações.
Através desta tecnologia é possível registar todo o percurso académico desde o ensino básico
até ao doutoramento, bem como impedir que determinadas pessoas tenham o privilégio ou a pos-
sibilidade de adquirir um diploma sem frequentar um determinado nível de ensino, como, aliás,
ficaram conhecidos alguns casos mediáticos de políticos [46].
Edgecoin
A Edgecoin foi uma das primeiras organizações a ter como foco principal a área da educação.
A plataforma por ela criada permite o registo de informações pessoais relativas ao percurso aca-
démico de cada pessoa, desde escolas frequentadas, cursos realizados, notas específicas, trabalhos
importantes e artigos publicados [47].
38 Casos de Estudo por Setores
Com toda esta informação detalhada a organização tem como objetivo:
• Eliminar a criação de diplomas fraudulentos;
• Facilitar a verificação de diplomas;
• Traduzir e comparar de forma automática os cursos em diferentes locais no mundo com
vista a melhorar a verificação, a aprovação e a agregação dos níveis de aprendizagem;
• Informatizar e automatizar toda informação de percurso académico, de modo a facilitar a
procura e as ofertas de trabalho.
3.5 Setor da Saúde
No caso concreto da saúde, o registo de dados e o sigilo médico são fatores postos em risco
pelo tradicional método de armazenamento físico formato de papel ou pelo armazenamento físico
de dados digitais. Estes métodos foram viáveis durante muitos anos, mas apresentaram desde
sempre os mesmos problemas: a perda de dados, a realização desnecessária de exames (muitas
vezes repetidos), o elevado tempo de espera de uma consulta ou o extravio de uma simples ficha
médica e ainda, e não menos importante, a fuga de informação pessoal, como é o caso de moradas,
e-mails, números de telemóvel e de telefone, e até de diagnósticos médicos.
Além disto, a falta de comunicação entre os profissionais e até mesmo entre profissionais e pa-
cientes é uma lacuna do sistema nacional de saúde (português, por exemplo). Estas lacunas podem
ser ultrapassadas pela introdução de um serviço à base da tecnologia blockchain, que protegerá os
dados com a importância devida, prevenirá escândalos e fugas e ainda eliminará a distância entre
o plano profissional e o plano público.
O Blockchain veio para resolver problemas que afetam o sistema atual, como a dificuldade e o
tempo de acesso a determinados registos médicos. Esta nova tecnologia permite, então, que, tanto
os médicos, como os farmacêuticos e os próprios pacientes possam consultar todas as informações
a qualquer momento, pois possibilita a criação e partilha de uma única base de dados, sendo estes
fornecidos pelos diferentes especialistas nesta área. Assim, acaba por haver uma maior segurança
dos dados, aos quais se pode aceder, se necessário e se o paciente permitir.
3.6 Setor dos Media 39
Para além disto, outra vantagem da utilização do Blockchain é a de os médicos terem a possi-
bilidade de despender mais tempo da consulta no atendimento e tratamento do paciente do que na
procura dos seus dados pessoais.
Modum.io
Esta tecnologia é utilizada para o controlo e monitorização de informação pessoal de utentes.
Além desta, existem outras aplicações para controlo de produtos para a indústria farmacêutica,
como por exemplo, a supply chain.
De acordo com as normas de transporte de produtos farmacêuticos na União Europeia, todos os
medicamentos têm de ser acompanhados por provas de que não tenham sido expostos a condições
que possam ter comprometido a sua qualidade. Isto exige um controlo rigoroso para as empresas
que realizam os transportes dos mesmos e que são obrigadas a guardar todos os registos de tempo,
trajeto e temperatura das suas entregas.
A Modum oferece uma solução tendo por base a tecnologia blockchain que permite a estas
empresas de transportes poupar tempo e evitar falhas no manuseamento das informações. Assim
todos os dados dos transportes são gravados num blockchain Ethereum que garante total transpa-
rência, responsabilização e integridade da informação.
Caso exista alguma falha num sistema de refrigeração e a segurança dos medicamentos seja
posta em causa, as entidades envolvidas recebem, de forma quase instantânea, um alerta a informar
da anomalia.
3.6 Setor dos Media
Tal como acontece em outros setores e com outras indústrias, o setor da publicidade apresenta
alguns desafios, seja pela existência de anúncios fraudulentos ou pela dificuldade que as empresas
têm em recolher e partilhar a informação dos seus clientes para obterem uma publicidade direcio-
nada.
Com o uso desta tecnologia, os anunciantes podem desfrutar de sistemas com transparên-
cia e criptografia elevadas. Para além disso, as empresas conseguirão, através do cruzamento de
informação de visualizações dos seus anúncios, ajustar a publicidade a cada público alvo, econo-
mizando dinheiro e tempo, aumentando, assim, a rentabilidade.
40 Casos de Estudo por Setores
Para além de traduzir num enorme benefício para as empresas, o uso desta tecnologia, pode
também deixar os consumidores mais descansados devido às suas características, as quais possi-
bilitam uma maior proteção de dados.
AdCoin Click
A AdCoin Click é uma das plataformas digitais baseadas em blockchain mais utilizadas e mais
conhecidas na atualidade. Esta plataforma trabalha tanto para anunciantes como para editores
e permite que ambos trabalhem em conjunto em prol da melhor publicidade possível [48]. A
plataforma apresenta ainda um token privado que possibilita que os anunciantes e os editores
efetuem transferências financeiras instantaneamente sem o envolvimento de terceiros e sem custos
adicionais.
Um dos projetos da empresa que obteve mais destaque este ano foi um plug-in de anúncios do
WordPress que permitirá aos editores individuais maximizar as receitas de tráfego [49].
3.7 Setor Energético
Assim como no setor das telecomunicações, a tecnologia blockchain pode ajudar as concessi-
onárias de produção de energia na redução dos custos operacionais e na oferta de novos serviços.
Apresentam-se, de seguida, algumas possíveis áreas de impacto:
• Financeiro: A utilização de smart contracts permite a realização de medições e de paga-
mentos automáticos, o que pode facilitar a criação de plataformas para micro pagamentos e
pagamentos pay-as-you-go (ex: Grid+).
• Marketing e Vendas: Através do registo de todas as informações dos utilizadores será
possível praticar preços e realizar publicidades mais inteligentes, com base nos horários de
maior consumo.
• Automação: A automação e o controlo dos sistemas de energia descentralizada e micro-
redes (micro-grids).
• Aplicações Smart Grid , Medição e Transferência de Dados: A criação de aplicações
para dispositivos móveis com a possibilidade de comunicação, de transmissão e armazena-
mento de dados. A utilização de sensores na rede possibilita a criação de plataformas de
3.7 Setor Energético 41
monitorização e controlos dos consumos dentro de uma habitação ou de uma empresa (ex:
Electron).
• Gestão de Redes: O uso da tecnologia blockchain pode auxiliar na gestão de redes descen-
tralizadas, serviços de flexibilidade e gestão de ativos.
• Segurança: Utilizando as propriedades de criptografia e de imutabilidade desta tecnologia
todas as informações pessoais de utilizadores e transações são confidenciais.
• Transparência: Esta é uma das áreas que sofre maior impacto com a aplicação da tecno-
logia, independentemente do setor. No setor energético não é exceção pelo simples facto
de ser possível tornar todos os processos transparentes e os ficheiros partilhados de forma
imutável e de livre acesso (ex: Grid Singularity).
Grid Singularity
A Grid Singularity, como indicado acima, opera na gestão de dados. Com vista a combater
o facto de a maioria das empresas atuais deste setor não analisarem nem compartilharem dados
para reduzir custos e otimizar o lucro, o trabalho da mesma reside na criação de uma camada
blockchain onde todas as transações são armazenadas com segurança. Esta plataforma tem como
objetivo possibilitar a outras empresas que não os usuários finais, o desenvolvimento de aplicativos
em cima desta plataforma, por exemplo:
• Gestão de smart grid’s;
• Validação de trocas de energia;
• Plataformas para micro pagamentos.
Isto permite que qualquer consumidor seja a qualquer altura um vendedor de energia. Para que
essa transação seja bem-sucedida, todas as partes envolventes devem concordar com os padrões e
valores limites de mercado [50].
42 Casos de Estudo por Setores
3.8 Setor Financeiro
A tecnologia blockchain contribui fortemente para a transformação diária do setor financeiro
de diversos modos. Os seus principais motivos de usos e os benefícios são:
• Menor número de intermediários: Ao serem retirados os intermediários, as transações,
para além de serem mais rápidas e mais seguras, tornam-se mais facilmente rastreáveis.
• Mitigação de fraudes: Uma vez que toda a informação presente na cadeia do blockchain
não pode ser alterada, torna-se impossível a adulteração de contratos, de pagamentos e dos
registos de acontecimentos antes realizados.
• Smart Contracts: Por serem automatizados, de execução praticamente instantânea e de fácil
verificação, o seu uso reduz drasticamente as burocracias legais e permite a realização de
grandes transações financeiras de modo simplificado.
JP Morgan Chase
A JP Morgan Chase é atualmente umas das maiores empresas do mundo e do setor financeiro.
Por sua vez é uma das empresas a nível mundial que mais tem investido na investigação e no
desenvolvimento de plataformas sobre a tecnologia blockchain. Um dos trabalhos que obteve
maior destaque e sucesso foi o designado Quorum.
Como referido, o Quorum é uma plataforma, baseada numa distributed ledger e em smart con-
tracts, direcionada para empresas do setor financeiro que necessitam de uma enorme velocidade
de processamento e de um elevado rendimento de transações.
Em Maio de 2019, a Microsoft juntou-se à JP Morgan de modo a associar o Quorum como a
base para o seu sistema Azure Cloud. Os planos da Microsoft passam por, num curto espaço de
tempo e com esta mesma plataforma, simplificar e automatizar todos os processos envolvidos na
compra e venda de jogos na Xbox [51].
3.9 Setor Gaming 43
3.9 Setor Gaming
Na indústria de jogos, a tecnologia blockchain tem a capacidade de mudar a forma como
interagimos e experimentamos jogos, bem como oferecer a possibilidade de criação de novas
plataformas para troca, compra e venda de jogos ou de componentes para os mesmos. Para além
disso, o blockchain permite criar ativos tangíveis que os jogadores possuem de forma exclusiva e
armazenados numa carteira pessoal. Os jogadores têm a possibilidade de controlar tanto os seus
jogos como os seus ativos.
Este é um setor que, para uma grande parte das pessoas, passa despercebido, mas que, na
realidade tem dimensões enormes. Por exemplo, em 2018, 2,2 biliões de pessoas jogaram jogos
de computador diariamente, mas apenas um terço comprou os jogos de forma legal. De acordo
com um relatório publicado pela Newzoo [52], as receitas globais de jogos, em 2018, rondaram os
134,9 biliões de dólares.
MobileGo
A MobileGO (MGO) é um token inteligente destinado à plataforma Esport que tem em vista
incentivar os jogadores para a lealdade e para a participação através de recompensas. Este token
apresenta várias vantagens, tanto para os jogadores, que veem facilitada a entrada em torneios
descentralizados, como para os próprios editores de jogos, que são pagos de um modo muito
mais rápido, seguro e sem burocracias. Depois dos tokens MGO serem retirados, os utilizadores
têm todo o controlo sobre os seus ativos podendo posteriormente convertê-los em criptomoedas
populares como o Ethereum ou Bitcoin.
Atualmente uma das plataformas mais conhecidas no mundo com mais de 500 milhões de
jogadores, a Xsolla, está a implementar o uso dos tokens MGO e prevê-se que se torne responsável
por cerca de 30% do volume de faturação mensal da Xsolla ainda este ano. É interessante referir
que a Xsolla atinge mensalmente, em média, uma faturação de cerca de 100 milhões de dólares
[53] [54].
Aplicações nos eSports
No âmbito dos eSports a aplicação da tecnologia blockchain difere naturalmente do foco de
cada empresa, e tem como objetivos:
• A configuração de torneios e a distribuição dos respetivos prémios (ex: First Blood [55]).
44 Casos de Estudo por Setores
• A criação de plataformas de recrutamento e gestão de novos jogadores e equipas, usando
smart contracts, que garantem as relações financeiras contratuais (ex: Dream Team [56]).
• A criação de ferramentas para monetização automática para os streamers com base no nú-
mero de publicidades e de espetadores (ex: Play2Live [57]).
3.10 Registo de Propriedade
Atualmente, e em diversos países e continentes, há muita falta de informação no que se refere
aos proprietários de terras. Como tem sido explicado, o blockchain possui características únicas
que podem proporcionar um melhor armazenamento e certificação de informações, bem como
permitir uma maior segurança jurídica a baixo custo.
Os registos de propriedades foram criados como uma forma de medir a riqueza económica
numa época em que os prédios faziam parte dos ativos mais valiosos que alguém poderia possuir.
Atualmente, pode-se afirmar que a realidade, é bem diferente dado que a posse de terras é conside-
rada como uma forma de poder económico, uma salvaguarda contra a deslocação ou exploração e
até mesmo como uma base cultural, especialmente para comunidades isoladas e povos indígenas.
Os registos de propriedade de terras baseados na tecnologia blockchain tem como objetivos
principais:
• O armazenamento e verificação de títulos;
• A realização de transações mais eficientes.
Embora o foco tenha sido mais dirigido para as vantagens e consequências benéficas do uso
desta tecnologia, a realidade é que também existem algumas dificuldades, como, por exemplo, a
necessidade de ser digitalizada toda a documentação que, neste momento, se encontram em papel
ou ainda a necessidade de conetividade de Internet em lugares de acesso remoto. Por outro lado, o
mapeamento é talvez o maior desafio para a implementação do blockchain no setor de registo de
propriedades.
A Chromaway é uma das 33 startups suecas mais promissoras de 2019, que tem como objetivo
manter títulos de propriedade e registos legais de transações de propriedades numa plataforma
baseada em blockchain [58]. O seu projeto já foi testado na Suécia onde obteve grande eficiência
e neste momento apenas está à espera de ser aceite legalmente para que possa ser estendido e
obrigatório em todo o país. Um segundo teste foi realizado na Índia onde a maioria dos títulos de
propriedades não se encontram registados legalmente.
3.11 Filantropia e Ajuda Humanitária 45
Ambos os projetos tinham como objetivo principal o armazenamento dos títulos num sistema
público, verificável e imutável, com vista a reduzir a fraude e a corrupção. Um dos objetivos da
empresa é legalizar toda a informação que é colocada no sistema para que depois, de forma legal,
possa ser utilizada, por exemplo, em tribunal quando existirem processos de disputa.
Num futuro próximo a Chromaway tenciona enriquecer a informação dos terrenos através da
adição de coordenadas, fotos e ainda verificação de terceiros (vizinhos por exemplo) [59].
3.11 Filantropia e Ajuda Humanitária
A falta de transparência é um dos motivos que dificulta a doação e a ajuda, uma vez que
provoca nos doadores uma grande falta de confiança sobre a aplicação dos fundos.
De acordo com um estudo realizado pela Fidelity Charitable, 41% dos doadores afirmam que
mudaram as suas doações devido ao feliz aumento de informação sobre a aplicabilidade e a efi-
cácia dos mesmos [60]. A blockchain tem o potencial de transformar as doações de caridade e a
distribuição de ajuda humanitária [61] [62] :
• aumentando a transparência;
• reduzindo custos por meio da desintermediação;
• possibilitando novos mecanismos de monitorização e rastreabilidade do impacto.
Uma das principais vantagens na utilização desta tecnologia para a filantropia ou ajuda huma-
nitária é que a mesma permite que uma doação seja rastreada em cada etapa, do doador para o
destinatário, e registar cada ação realizada por cada intermediário.
Ixo Fundation
O controlo e a validação dos financiamentos atribuídos a projetos e/ou a instituições é um
processo muito caro e trabalhoso para os doadores, sejam estes os governos ou empresas privadas.
A Ixo Foundation é uma organização sem fins lucrativos sediada na Suíça que, desde a sua
criação, trabalha na construção de um protocolo blockchain de código aberto para a economia de
impacto. Um dos primeiros projetos coordenados pela Ixo Fundation, financiado pelo Fundo de
Inovação da UNICEF e pelo Innovation Edge, foi a Amply. A Amply permite aos educadores
do ensino pré-escolar, através de uma aplicação móvel, registar de forma segura a frequência e
46 Casos de Estudo por Setores
o aproveitamento escolar das crianças que o frequentam. Com estes dados de participação, o
governo decide a dimensão e as escolas que podem receber subsídios.
Até à data, a Amply já foi testada em 77 centros com 2700 crianças cadastradas e já digitalizou
mais de 55000 registos de frequência [63].
Neste momento o projeto que está a receber maior atenção por parte da Ixo e por parte do
público em geral consiste em usar sensores IoT para originar créditos de carbono como tokens de
carbono provenientes de fogões de queima limpa, ao mesmo tempo que analisa os benefícios e os
efeitos prejudiciais relacionados com a saúde.
O objetivo da Ixo passa agora por aplicar esta tecnologia a muitas outras áreas de impacto
ambiental e padronizar os dados desse impacto criando depois um Global Impact Ledger (GIL)
[64]. Este protocolo permitirá que todos os projetos, grandes ou pequenos, auto certifiquem os
seus impactos ambientais e se candidatem a capitais globais para financiamento social.
Disberse
Ano após ano são doados largos milhões de dólares para os países em desenvolvimento. Uma
das grandes dúvidas e, ao mesmo tempo, um dos grandes desafios que os doadores enfrentam é o
de assegurar a transferência e a eficácia da sua utilização. Durante o processo de transação, cerca
de 10% dos fundos são perdidos em taxas de transação e em taxas de câmbio flutuantes, isto sem
mencionar as perdas de intermediários e a corrupção. Combinando estas ineficiências com a falta
de transparência em todo o processo, o risco de uso indevido aumenta, o que faz elevar a falta de
confiança por parte das organizações doadoras [65].
O desafio principal da Disberse é resolver esse problema através da sua plataforma de gestão
de fundos, que gere os mesmos de forma transparente, eficaz e, segundo afirma a empresa, de
modo eficiente. Esta plataforma permite aos doadores singulares, governos e ONGs transferir e
localizar os fundos em toda a cadeia, desde o doador ao beneficiário [66].
O primeiro projeto a ter como base esta plataforma foi a Positive Woman que a usou para
reduzir as taxas de transferência de fundos monetários para projetos educacionais na Suazilândia
(África) em 2,5%. Com esta poupança a instituição garantiu a ajuda a mais 3 estudantes num ano
[67].
O projeto piloto bem sucedido e a prova de conceito são uma indicação encorajadora de que
o Disberse será capaz de se expandir para outras organizações sem fins lucrativos e, por meio de
custos reduzidos, garantir que os fundos chegam ao destino e no tempo certo.
Capítulo 4
Processos de Negócios
Um processo de negócio (business process) é composto por uma ou mais atividades que, no
fim, podem resultar no atingir, de uma meta organizacional, como, por exemplo, um serviço ou
um produto para um cliente. Por norma, um processo apresenta as entradas sempre bem definidas
e apenas uma saída possível. São consideradas entradas todos os processos que, de certa forma,
contribuem para o valor agregado de um serviço/produto.
Estes processos podem ser categorizados em processos de gestão (Management Processes),
processos de suporte (Supporting Processes) e em processos operacionais (Operational Proces-
ses), ou também chamados de processos primários.
As entradas de dados podem ser executadas manualmente por funcionários ou de forma auto-
mática por sistemas informáticos. A possibilidade de realizar os processos de forma automática
será abordada mais à frente, onde serão dados vários exemplos de aplicações e os seus benefícios.
Diversas definições de um processo de negócio foram encontradas na literatura:
• “A set of logically related tasks performed to achieve a defined business outcome
for a particular customer or market.” , Davenport [68].
• “Business process is a collection of activities that take one or more kinds of
input and create an output that is of value to the customer.”, Hammer & Champy
[68].
Analisando as definições dadas por Davenport e Hammer & Champy, pode-se definir um business
process como um conjunto de atividades executadas por trabalhadores e pelas suas interações, que
tem como objetivo final atingir uma meta antes definida e criar valor.
47
48 Processos de Negócios
4.1 Ciclo de Vida dos Processos de Negócio
O ciclo de vida do processo de negócios é mostrado na Figura 4.1 e consiste em 4 fases
organizadas de maneira cíclica com as suas devidas dependências lógicas. Embora esta estrutura
cíclica esteja conectada por setas, isso não implica uma ordem temporal direta de execução.
Figura 4.1: Ciclo de Vida de Gestão de Processos
Design & Análise (Design & Analysis)
É a fase em que são realizadas múltiplas análises para identificar, rever, validar e representar
os processos de negócio. Nesta fase são também utilizadas técnicas de modelação e simulação de
processos de negócio, algo que corresponde mais à componente do "Design".
Configuração (Configuration)
Depois de o processo de negócio ser projetado e verificado o mesmo deve ser implementado
de acordo com um conjunto de políticas e procedimentos. Existem duas maneiras para que tal
aconteça: usando apenas os trabalhadores ou usando um sistema de gestão de processos.
4.2 Tipos de Processos de Negócio 49
Encenação (Enactment)
Após a configuração, o processo é iniciado e o sistema inicia a monitorização da execução para
garantir que todas as atividades inerentes ao processo são executadas, de acordo com as restrições
dadas no respetivo modelo.
Avaliação (Evaluation)
Nesta fase, as informações obtidas durante a fase anterior são processadas e avaliadas para
averiguar a qualidade dos modelos de processos de negócios e a compatibilidade do ambiente de
execução.
4.2 Tipos de Processos de Negócio
Como foi referido anteriormente, existem três categorias de processos de negócios que, quando
são executados em conjunto e de forma otimizada, tornam um modelo de negócios eficiente [69].
4.2.1 Processos Operacionais/Primários
Os processos operacionais são também chamados de processos primários por serem, como o
nome sugere, processos básicos, mas, ao mesmo tempo, extremamente importantes e fundamen-
tais para os negócios, uma vez que é através dos mesmos que a empresa garante a entrega de
serviços/produtos aos seus clientes [70].
Existem diferentes tipos de processos primários de negócios, entre os quais:
Vendas
As vendas são, sem dúvida alguma, um processo primário para uma empresa, dado que é o
principal gerador de receitas para um negócio. Sem vendas uma organização não se consegue
manter em atividade.
Atendimento ao Cliente
Depois de uma ordem de compra efetuada por um cliente é essencial que haja alguém que
processe o pedido e que o execute. Para além de processar o pedido também é essencial para um
negócio haver alguém disponível para tirar dúvidas, esclarecer e ajudar os clientes que necessitam,
bem como de assegurar o serviço pós-venda.
50 Processos de Negócios
Finanças
À medida que as vendas vão sendo realizadas e que a empresa começa a faturar, é necessário
haver um departamento que lide tanto com o dinheiro que entra como com o que é gasto/investido.
Este processo é fundamental, seja para detetar gastos descontrolados, seja para delinear estratégias
de investimento.
Operações
As operações enquanto processo, podem envolver desde a gestão de stock à alocação de traba-
lhadores para entregas ou gestão de trabalho. A partir do momento em que as vendas começam a
existir, este é um processo primário e prioritário para o bom funcionamento de uma empresa [71].
Produção
Considerando as vendas, o atendimento ao cliente, as finanças e as operações, é obrigatório
considerar a produção como um processo de negócio primário. O processo de produção engloba
o planeamento, a validação e o fabrico do produto.
4.2.2 Processos de Suporte
Como o nome indica, estes são "apenas"os processos de suporte e não agregam valor dire-
tamente transferido para o cliente final. No entanto, são estes processos que proporcionam um
ambiente adequado para o funcionamento dos processos primários referenciados [71].
Contabilidade
O departamento de contabilidade lida essencialmente com a autenticidade das transações e
registos financeiros na organização. Compete ao departamento de contabilidade garantir que os
ativos e os passivos são espelhados e mantidos correta e fielmente no balanço patrimonial.
Gestão
Embora o processo de gestão esteja sempre inerente na organização de uma empresa, este é
considerado um processo de suporte, pois é fundamental e, além do mais, considerado um dos
alicerces para o desempenho e para o crescimento de uma empresa.
4.3 Modelos para Design de Processos de Negócio 51
Recursos Humanos
Sem um departamento de recursos humanos a empresa continua a trabalhar, no entanto, à se-
melhança dos processos de gestão, os recursos humanos podem garantir um futuro promissor a
uma empresa. Cabe a estes processos analisar as falhas internas e arranjar novas pessoas, interna-
mente ou externamente, para colmatar os setores mais fragilizados.
4.2.3 Processos de Gestão
Estes tipos de processos são semelhantes aos processos de suporte que não agregam valor di-
reto ao consumidor final. Os processos de gestão são responsáveis pela orientação, monitorização
e análise dos negócios diários. São também responsáveis por coordenar as atividades dos proces-
sos primários/operacionais com os processos de suporte, de modo a tornar o negócio mais eficaz
e eficiente.
4.3 Modelos para Design de Processos de Negócio
Existem diversos modelos direcionados para o design de processos de negócio e para diversos
setores. Nesta secção serão abordadas os mais utilizados.
4.3.1 SCOR
O modelo SCOR (Supply Chain Operations Reference), criado pelo The Supply Chain Coun-
cil, é uma parte de uma framework criada pela APICS e, como o nome indica, é direcionado para
a supply chain.
Este modelo utiliza blocos de processos para descrever as cadeias de abastecimento, sejam
elas simples ou complexas [72]. Para descrever e representar todas as atividades de negócios
relacionadas com a satisfação final do cliente, o modelo é organizado de acordo com os seguintes
processos principais de gestão (Figura 4.2):
• Plan: Processo responsável por analisar toda a cadeia de valor, desde as necessidades dos
clientes até à produção e entrega de produtos.
• Source: Responsável pela compra de matérias-primas e pela infraestrutura em toda a cadeia
logística.
• Make: Cuida de todos os assuntos relacionados com a transformação da matéria-prima no
fabrico do produto final.
52 Processos de Negócios
• Deliver: Responsável pela criação, manutenção e atendimento de pedidos de clientes. É
também responsável pela entrega dos produtos, armazenamento e gestão dos canais de dis-
tribuição.
• Return: Analisa e gere todos os produtos devolvidos.
• Enable: Permite que os processos interajam entre si e que consigam gerir o seu alinhamento
com outros processos.
Figura 4.2: Supply Chain Operations Reference (SCOR) - SCOR Version 12.0 [72]
4.3.2 PCF (APQC)
A Process Classification Framework (PCF), desenvolvida pelo American Productivity & Qua-
lity Centre (APQC), é uma taxonomia de processos de negócios multi-funcionais com o objetivo
de permitir a comparação do desempenho organizacional dentro de organizações e entre elas [73].
Este modelo consiste num conjunto de processos de negócios e numa linguagem universal para
permitir um benchmarking universal e um framework dinâmico que direcione as organizações para
uma melhoria contínua e uma melhor adaptação às mudanças do mercado.
Este modelo foi criado para ser implementado independentemente do setor, localização ou
tamanho do negócio. Como é possível verificar na Figura 4.3, o PCF encontra-se dividido em
doze categorias diferentes de processos empresariais.
4.3 Modelos para Design de Processos de Negócio 53
Figura 4.3: Doze níveis de processos do PCF [74]
4.3.3 eTOM
O eTOM, enhanced Telecom Operations Map (mapa avançado de operações de telecomunica-
ções), é um modelo destinado aos processos de negócios ligados à indústria de telecomunicações.
Descreve os processos de negócios necessários para os fornecedores de serviços e define como os
utilizadores participantes devem interagir entre si [75], [76].
Este modelo, baseia-se em três grandes áreas de processos (Figura 4.4):
• Estratégia, Infraestrutura e Produto (azul);
• Operações (laranja);
• Gestão empresarial (cinzento).
4.3.4 COBIT
A COBIT (Control Objectives for Information and Related Technologies), criada pela ISACA
(Information Systems Audit and Control Association) [78], é uma modelo focado na gestão de
processos ligados à tecnologia de informação (IT).
54 Processos de Negócios
Figura 4.4: Modelo eTOM [77]
Este modelo possui uma série de recursos:
• Framework: Organiza os objetivos e as boas práticas relativos aos processos inerentes à
gestão das tecnologias de informação.
• Descrição de Processos: Os processos são categorizados nas áreas responsáveis (planea-
mento, construção, execução e monitorização).
• Objetivos de Controlo: Fornece todos os requisitos a serem considerados na gestão dos
processos.
• Diretrizes de Gestão: Fundamental para a gestão de responsabilidades e para a avaliação
de desempenhos e objetivos.
Cubo de COBIT
O Cubo de COBIT é usado para explicar de forma gráfica quais os processos, requisitos e
recursos de IT e a maneira como os mesmos se inter-relacionam.
Como se pode observar na Figura 4.5, as faces do cubo encontram-se divididas em etapas.
Na face frontal do cubo os processos IT encontram-se subdivididos em: domínios, processos
e atividades.
4.3 Modelos para Design de Processos de Negócio 55
Figura 4.5: Cubo de COBIT [79]
Neste âmbito, os domínios são categorizados pelos seguintes objetivos:
• Planeamento e Organização;
• Implementação;
• Entrega e Apoio;
• Monitorização e Avaliação.
Capítulo 5
Potencial de Aplicação no contexto daSupply Chain Management (SCM)
Numa sociedade cada vez mais consumista onde os bens de consumo, sejam eles essenciais
ou de entretenimento, são fabricados e pedidos continuamente em grandes quantidades, as sup-
ply chains são levadas ao limite e sentem a necessidade de crescimento e de gestão constante.
Aliadas a estas necessidades, as empresas são obrigadas a utilizar as melhores e mais avançadas
tecnologias, que lhes garantam a segurança, gestão e credibilidade possível.
5.1 Caracterização da Supply Chain
As supply chains podem ser utilizadas em quase todos os negócios independentemente do setor
em que operam e por norma englobam todos os processos e atividades, desde a recolha da matéria
prima até à entrega do produto final. Uma determinada supply chain pode incorporar diversas
entidades, como transportadoras, fornecedores, fábricas e centros de distribuição [80].
Figura 5.1: Exemplo simplificado de uma supply chain de vestuário [81]
O fluxo numa supply chain nem sempre é arborescente como representado na Figura 5.1, uma
vez que há sempre, e a toda a hora, decisões e ações a serem tomadas em paralelo. Ou seja, um
esquema mais realista de uma supply chain seria como representado na Figura 5.2, onde estão
representados todos os caminhos possíveis para as informações/produtos.
57
58 Potencial de Aplicação no contexto da Supply Chain Management (SCM)
Figura 5.2: Exemplo de uma supply chain de vestuário [81]
As atividades e processos resultantes de ações realizadas pelas entidades antes mencionadas
podem incluir: recolha de matérias primas, armazenamento, fabrico, montagem, distribuição, etc.
Como se pode reparar o SCM é responsável por toda a coordenação e colaboração entre as en-
tidades e, portanto, a gestão do fluxo de informações e recursos entre elas é muito importante. Por
se tratar de uma informação tão confidencial e importante, é também relevante que seja mantida a
qualidade e a segurança de todas as entidades e informações presentes.
Problemas no Setor
O problema mais comum e mais generalista que ocorre ou pode ocorrer frequentemente numa
supply chain é a facilidade com que um evento inesperado pode causar atrasos em toda a cadeia. Os
eventos mencionados nem sempre ocorrem como planeado, o que pode causar também problemas
de sincronização nos processos e nos sistemas de informação de uma empresa [81].
O facto de a privacidade e a segurança serem duas das características mais valorizadas nas
empresas torna a partilha de informações cada fez mais difícil e com mais burocracias.
Aumentar a qualidade e implementar a possibilidade de partilha de informações relativas à
proveniência e à rastreabilidade dos produtos é outro dos objetivos diários das empresas que tra-
balham na área das cadeias de abastecimento. Uma vez que todas estas informações são muito
limitadas pelas entidades participantes, a visão global dos produtos é quase inexistente.
5.2 Da Supply Chain para o Blockchain 59
5.2 Da Supply Chain para o Blockchain
Um dos motivos pelos quais a transferência e a disponibilidade de informações é reduzida é o
uso de softwares antiquados que não têm em atenção os problemas modernos como é o caso das
falsificações de produtos. Com os requisitos a serem alterados frequentemente cabe às empresas
implementar novas tecnologias para os satisfazer.
As propriedades intrínsecas à tecnologia blockchain abordadas na subsecção 2.3, podem ser
uma boa solução para que muitos dos problemas mencionados sejam anulados. Essas propriedades
permitem, por exemplo:
• Menos erros humanos: Com a possibilidade de automatizar as entradas que antes eram
colocadas de forma manual com recurso à IoT e/ou a outros processos automatizados;
• Maior segurança na transferência de dados:Todos os dados são encriptados e imutáveis
o que torna mais fácil a deteção de tentativas de fraudes na rede;
• Maior rastreabilidade: Seja dos produtos, de informações ou de erros a tecnologia permite
melhorar toda a rastreabilidade dentro do sistema;
• Aumento da confiança do consumidor: O consumidor, ao ter a possibilidade de aceder a
toda a informação sobre o produto cria, de uma forma natural, uma ligação mais forte com
o comerciante;
• Redução de custos: Através da possibilidade de efetuar todos os pagamentos sem a pre-
sença de terceiros ou com trocas de informações automáticas.
5.3 Objetivos Principais de Implementação da Tecnologia Blockchain
As características de maior relevo e com mais importância a ter em conta numa supply chain,
para que não seja posta em causa a qualidade do seu serviço, são:
• Velocidade de entrega: Este é, sem dúvida um dos focos principais, uma vez que, quanto
mais cedo o produto for entregue, mais cedo o cliente pode satisfazer as suas necessidades.
Independentemente do cliente apenas querer satisfazer as suas necessidades uma semana
depois da encomenda do produto ou de ter uma certa urgência, quanto mais cedo a entrega
for concluída melhor será a relação cliente/vendedor.
Isto aplica-se não só ao cliente final, mas também a qualquer empresa que forneça produtos
e/ou serviços a outras empresas, seja no papel de fornecedor, de fabricante ou de distribuidor.
60 Potencial de Aplicação no contexto da Supply Chain Management (SCM)
• Rastreabilidade: Durante a supply chain os produtos sofrem muitas alterações: alguns são
perdidos, outros danificados, falsificados ou até nem são registados. O facto de muitas infor-
mações relativas ao fabrico e transporte dos produtos não serem controladas nem registadas
leva a uma enorme desconfiança por parte do cliente.
Para além disso, esta falta de controlo faz com que a segurança de muitos produtos não seja
garantida (ex: produtos alimentares sensíveis ou produtos farmacêuticos que facilmente
perdem as suas propriedades essenciais quando expostos a temperaturas inadequadas) ou
que a saúde dos clientes finais seja posta em causa.
É essencialmente por estas razões que se justifica que todos os produtos, independentemente
da indústria, devam ser rastreados desde a sua origem até à entrega ao cliente, passando pelo
registo de todos os transportes e transformações ocorridas.
• Transferências de Dados: A transferência de dados dentro de uma empresa ou para com
uma entidade externa é muitas vezes posta em causa devido ao formato dos documentos,
softwares e protocolos específicos. Tudo isto porque as empresas ou até mesmo departamen-
tos internos não partilham da mesma plataforma, que conduz, muitas vezes, à (in)evitável
realização de trabalho manual desnecessário.
• Segurança: Este é talvez um dos pontos mais importantes e que mais preocupa as empresas.
As informações numa supply chain são altamente confidenciais e devem ser controladas para
que apenas as entidades confiáveis possam a elas ter acesso.
Devido à concorrência entre empresas, um simples detalhe sobre um produto a ser lançado
pode-se traduzir em perdas de milhões de euros. Este é mais um dos motivos pelos quais
muitas das informações têm de estar seguras.
5.4 Análise de processos seguindo o modelo SCOR
Sendo o objetivo principal deste capítulo a análise do potencial de aplicação da tecnologia
blockchain na SCM, é necessário realizar, em primeiro uma análise de todos os processos existen-
tes e, posteriormente, analisar em qual deles é que esta implementação pode ser benéfica.
Como referido na subsecção 4.3.1, o modelo SCOR foi especialmente desenvolvido para as
cadeias de abastecimento. E, portanto, foi o modelo utilizado.
5.4.1 Hierarquia dos processos no modelo SCOR
O modelo SCOR pode ser considerado simples e abstrato quando visualizado de forma abstrata
e em baixa resolução. Conforme mostrado na Figura 5.9, o modelo foi projetado para suportar a
análise da supply chain em diversos níveis:
5.4 Análise de processos seguindo o modelo SCOR 61
• Nível 1 - Nível Principal: Define o foco principal, o conteúdo, e o objetivo da SC. (Plan,
Source, Make, Deliver, Return e Enable).
• Nível 2 - Categorias: Define a estratégia das operações e as capacidades inerentes aos
processos. (ex: Make-to-Stock, Make-to-Order, Engineer-to-Order,...).
• Nível 3 - Elementos: Define a conFiguração individual de cada processo, os inputs/outputs
e as capacidades. (ex: Receber produto, Verificar produto, Realizar pagamentos,...).
• Nível 4 - Nível de Implementação: Descreve as atividades e as implementações realizadas
ou a realizar relativas à performance do processo. (kaizen, lean, six sigma, benchmarking).
Figura 5.3: Hierarquia dos processos no modelo SCOR, adaptado de SCOR 12.0 [72]
62 Potencial de Aplicação no contexto da Supply Chain Management (SCM)
5.4.2 Análise das necessidades dos processos e cálculo do potencial de utilização
Nesta subsecção serão analisadas de forma mais aprofundada as categorias dos processos e os
processos subjacentes com vista a concluir sobre as suas dificuldades e necessidades.
Nas tabelas seguintes, são enumeradas, ao lado esquerdo, em forma de lista, algumas das
propriedades que a implementação da tecnologia blockchain pode trazer a um sistema. Na parte
superior, estão apresentados, com a simbologia utilizada no modelo SCOR (Anexo A), as catego-
rias (Nível 2) pertencentes a cada nível de processo (Nível 1). Na matriz interior da tabela estão
assinaladas com um “X” as propriedades que são importantes e a ter em conta no processo corres-
pondente, onde um traço (-) significa a inexistência de dificuldade e/ou de necessidade, um “X”
indica que a categoria apresenta apenas algumas e por fim a utilização de “XX” indica que essa
propriedade é uma forte dificuldade e/ou uma necessidade para a categoria em questão.
É importante reforçar a ideia que foram analisados os processos que compõe as categorias
assinaladas. Por exemplo, a categoria sP1 (Plan Supply Chain) é composta por quatro processos
(Figura 5.4).
Figura 5.4: Processos pertencentes à categoria sP1 (Plan Supply Chain) [72]
Plan
PlansP1 sP2 sP3 sP4 sP5
VerificabilidadePública
XX XX XX XX XX
Integridade X X X X XImutabilidade X X X X XRedundância X X X X XHierarquia X X X X XTransparência - - - - -Privacidade XX XX XX XX XX
Tabela 5.1: Dificuldades e necessidades inerentes ao nível Plan
sP1 - Plan Supply Chain: Responsável pelo desenvolvimento e planeamento de alternativas de
ação em períodos de tempo especificados, tendo em conta os recursos, os requisitos e as restrições
da suplly chain.
5.4 Análise de processos seguindo o modelo SCOR 63
sP2 - Plan Source: Responsável pelo desenvolvimento e planeamento de alternativas de ação em
períodos de tempo especificados, tendo em conta os recursos materiais necessários para satisfazer
os requisitos da supply chain.
sP3 - Plan Make: Responsável pelo desenvolvimento e planeamento de alternativas de ação
em períodos de tempo especificados, tendo em conta os recursos de produção necessários para
satisfazer os requisitos de produção.
sP4 - Plan Deliver: Responsável pelo desenvolvimento e planeamento de alternativas de ação em
períodos de tempo especificados, tendo em conta os recursos de entrega necessários para satisfazer
os requisitos de entrega.
sP5 - Plan Return: Responsável pelo planeamento estratégico ou tático das alternativas de ação
ou tarefas de tempo especificados, tendo em conta os recursos de retorno e os ativos necessários
para satisfazer os retornos sejam eles imprevistos ou não.
Source
SourcesS1 sS2 sS3
VerificabilidadePública
X X X
Integridade XX XX X XImutabilidade XX XX XXRedundância - - -Hierarquia X X XTransparência X X XPrivacidade X X X
Tabela 5.2: Dificuldades e necessidades inerentes ao nível Source
sS1 - Source Stocked Product: Engloba os processos de pedido, de receção e de transferên-
cia de matéria-prima, sub-conjuntos, produtos e/ ou serviços com base nos requisitos de procura
agregados. O objetivo do "source-to-stock"é manter um nível pré-determinado de stock para de-
terminados materiais e/ou produtos.
É importante salientar que em nenhum dos processos inerentes a esta categoria são trocadas
informações ou detalhes acerca do cliente ou do pedido do mesmo. O pedido do cliente nunca é
64 Potencial de Aplicação no contexto da Supply Chain Management (SCM)
trocado com o fornecedor, anexado ao pedido geral, ao produto ou a qualquer plataforma de gestão
de produção.
sS2 - Source Make-to-Order Product: Engloba os processos de pedido, de receção e de trans-
ferência de matéria-prima que são solicitados apenas quando existe um pedido por parte de um
cliente. A intenção de produzir para satisfazer as encomendas (make-to-order) é manter o stock
solicitado (e/ou configurado) apenas e só para satisfazer pedidos específicos de clientes.
O produto é pedido, recebido e identificado em stock usando a referência do pedido do cliente.
Para além disso o produto é, através da referência antes referida, rastreável ao longo de todos os
processos de abastecimento.
sS3 - Source Engineer-to-Order Product: Responsável pela identificação e seleção das fontes de
abastecimento, pela negociação, validação, programação, pedido e receção de peças, montagens,
produtos ou serviços especializados, que são projetados, solicitados e/ou construídos com base
nos requisitos ou especificações de um determinado pedido do cliente.
Make
MakesM1 sM2 sM3
VerificabilidadePública
- - -
Integridade X X XXImutabilidade X X XXRedundância - - -Hierarquia X X XTransparência X XX XPrivacidade X XX XX
Tabela 5.3: Dificuldades e necessidades inerentes ao nível Make
sM1 - Make-to-Stock: Esta categoria é responsável por agregar valor a um produto ou serviço,
através do fabrico dos mesmos. Por norma os produtos para stock são enviados já acabados ou
como "produtos para uso"e, através de uma previsão de vendas, a produção destes produtos é
iniciada antes de qualquer pedido.
É importante salientar que em nenhum dos processos inerentes a esta categoria são trocadas
informações ou detalhes acerca do cliente ou do pedido do mesmo. O pedido do cliente nunca é
trocado com o fornecedor, anexado ao pedido geral, ao produto ou a qualquer plataforma de gestão
de produção.
5.4 Análise de processos seguindo o modelo SCOR 65
sM2 - Make-to-Order: Esta categoria é responsável por agregar valor a uma entrega específica,
seja ela um produto ou um serviço. Os produtos e/ou serviços são concluídos, construídos ou
configurados apenas em resposta a um pedido do cliente. A referência ao pedido do cliente é
anexada à ordem de produção / serviço, anexada ou marcada no produto, entregue após a conclusão
do processo de fabricação e referenciada ao transferir o produto para entregar.
O produto é rastreável em todo o processo de adição de valor, como feito para um pedido
específico do cliente.
sM3 - Engineer-to-Order: Esta categoria é responsável por agregar valor a um produto ou ser-
viço, através do fabrico dos mesmos. O Engineer-to-Order requer que as instruções de trabalho
sejam definidas ou refinadas, e as instruções de roteamento de material possam ser adicionadas ou
alteradas.
Deliver
DeliversD1 sD2 sD3 sD4
VerificabilidadePública
X X X X
Integridade X X X XImutabilidade X X X XRedundância - - - -Hierarquia X XX X XTransparência X XX X XPrivacidade XX XX XX X
Tabela 5.4: Dificuldades e necessidades inerentes ao nível Deliver
sD1 - Deliver Stocked Product: Responsável pela entrega dos produtos que estavam em stock. O
intenção deste tipo de entrega é ter o produto já disponível para entrega ao cliente antes do pedido
do mesmo ser recebido e assim proceder a uma entrega muito mais rápida e evitar que o mesmo
procure outro lugar.
sD2 - Deliver Make-to-Order Product: Responsável pela entrega de produtos e/ou serviços for-
necidos, configurados, fabricados e/ou montados a partir de matérias-primas, peças, ingredientes
ou subconjuntos padrão, em resposta a um pedido específico. Ao longo destes processos uma
referência ao pedido do cliente é trocada com o processo de fornecimento ou agregação de valor
e anexado ou marcado no produto/serviço. Os produtos em stock são rastreáveis pelo pedido do
cliente recorrendo a métodos de rotulagem e gestão de inventário.
66 Potencial de Aplicação no contexto da Supply Chain Management (SCM)
sD3 - Deliver Engineer-to-Order Product: Engloba os processos de recolha, resposta e armaze-
namento de recursos para um pedido que possua requisitos ou especificações exclusivas e entrega
de um produto ou serviço que é parcial ou totalmente projetado, redesenhado, fabricado e/ou mon-
tado a partir de uma lista de materiais que inclua uma ou mais peças personalizadas.
sD4 - Deliver Retail Product: Responsável por adquirir, vender e realizar merchandise de pro-
dutos que se encontram numa loja de retalho.
Return
ReturnsSR1 sSR2 sSR3 sDR1 sDR2 sDR3
VerificabilidadePública
X X X X X X
Integridade X X X X X XImutabilidade XX X X XX X XRedundância - - - - - -Hierarquia X X X X X XTransparência XX X X XX X XPrivacidade XX XX X XX XX XTabela 5.5: Dificuldades e necessidades inerentes ao nível Return
sSR1 - Source Return Defective Product: A devolução e a determinação de um produto defei-
tuoso é feita conforme definido pelas reivindicações de garantia, através de recall de produtos,
produtos em não conformidade com o assinalado no ato de venda, etc. Esta categoria engloba toda
esta análise e define a veracidade do pedido de devolução.
sSR2 - Source Return MRO Product: O retorno dos produtos de Manutenção, Reparo e Revisão
(Maintenance, Repair and Overhaul (MRO)) ou ativos de empresas para fins de manutenção,
reparo ou atualização, conforme definido pelos Planos de Manutenção ou a ocorrência/antecipação
de risco de falha.
sSR3 - Source Return Excess Product: Responsável por acompanhara devolução de todo o
stock antigo e/ou de produtos obsoletos, conforme definido pelos termos e condições do contrato
realizado ente cliente e fornecedor.
5.4 Análise de processos seguindo o modelo SCOR 67
sDR1 - Deliver Return Defective Product: A devolução e a determinação de um produto de-
feituoso é feita conforme definido pelas reivindicações de garantia, através de recall de produtos,
produtos em não conformidade com o assinalado no ato de venda, etc. Esta categoria engloba toda
esta análise e define a veracidade do pedido de devolução.
sDR2 - Deliver Return MRO Product: O retorno dos produtos de Manutenção, Reparo e Revisão
(Maintenance, Repair and Overhaul (MRO)) ou ativos de empresas para fins de manutenção,
reparo ou atualização, conforme definido pelos Planos de Manutenção ou a ocorrência/antecipação
de risco de falha.
sDR3 - Deliver Return Excess Product: Responsável por acompanhara devolução de todo o
stock antigo e/ou de produtos obsoletos, conforme definido pelos termos e condições do contrato
realizado ente cliente e fornecedor.
Enable
EnablesE1 sE2 sE3 sE4 sE5 sE6 sE7 sE8 sE9 sE10 sE11
VerificabilidadePública
XX - XX X - X X - - - -
Integridade XX X XX X XX X X X X XX XImutabilidade XX X XX XX XX XX X X X XX XRedundância X X XX - - X XX X - - XHierarquia X X XX X X X X X X X XTransparência - - X X - XX X - X X -Privacidade XX XX XX XX XX XX XX XX XX XX XX
Tabela 5.6: Dificuldades e necessidades inerentes ao nível Enable
sE1 - Manage Supply Chain Business Rules: Engloba os processos responsáveis por estabele-
cer, documentar, comunicar e publicar regras de negócios relativos à suppy chain. As regras de
negócios podem ser aplicadas a pessoas, processos, comportamento corporativo e a sistemas de
computação numa organização. São implementadas para ajudar a organização a atingir os seus
objetivos e, ao mesmo tempo, manter a conformidade com as políticas e leis internas e externas.
sE2 - Manage Supply Chain Performance: Definição de metas de desempenho para métricas
da supply chain. Este processo descreve todos os níveis e versões de gestão do desempenho da
cadeia de suprimentos.
68 Potencial de Aplicação no contexto da Supply Chain Management (SCM)
sE3 - Manage Supply Chain Data and Information: Engloba os processos de recolha, manu-
tenção e publicação de dados e informações necessárias para o planeamento, operação, medição e
gestão da supply chain.
sE4 - Manage Supply Chain Human Resources: Engloba os processos responsáveis pelo desen-
volvimento, administração e manutenção de uma organização de pessoal permanente, temporária
e subcontratando pessoas, com as qualificações certas, em apoio aos objetos de negócios e ob-
jetivos da supply chain. Nesta categoria é também realizada uma identificação das habilidades
necessárias e disponíveis na organização, determinando as lacunas nas habilidades e nos níveis de
competência, identificando as necessidades a melhorar, as lacunas de recursos e os recursos em
excesso.
sE5 - Manage Supply Chain Assets: Engloba toda a programação, manutenção e disposição dos
ativos da supply chain desenvolvidos para a execução da mesma. Isso inclui a instalação, o reparo,
a alteração, a calibração e outras atividades necessárias para sustentar a execução da supply chain.
sE6 - Manage Supply Chain Contracts: Gestão e comunicação de acordos contratuais e não
contratuais em apoio aos objetivos de negócios e objetivos da supply chain. Isso inclui todos os
contratos relacionados às operações da supply chain, incluindo aquisição de materiais e serviços,
níveis e práticas de reposição de stock, metas de desempenho, planeamento e tomada de decisões,
logística e entrega, troca de dados e visibilidade.
sE7 - Manage Supply Chain Network: Definir e gerir a pegada geográfica e de atividade da
supply chain. Define a localização das instalações e as atribuições de recursos, redes de distribui-
ção, fornecedores, clientes, materiais, produtos, capacidades e/ou capacidades para estes mesmos
locais.
sE8 - Manage Supply Chain Regulatory Compliance: Engloba os processos de identificação,
colheita, avaliação e integração de requisitos de conformidade normativa em processos, políticas
e regras de negócios padrão da supply chain. Também inclui gerir o cumprimento voluntário de
padrões e certificações.
sE9 - Manage Supply Chain Risk: Nesta categoria são identificados e calculados os potenciais
risos presentes na supply chain. Para além disso são também realizados planos para mitigar estas
ameaças ao funcionamento da cadeia.
5.4 Análise de processos seguindo o modelo SCOR 69
sE10 - Manage Supply Chain Procurement: O "procurement cycle"(ciclo de aquisições) é o
processo cíclico dos principais passos ao adquirir bens ou serviços. Os conceitos nesta categoria
foram desenvolvidos em conjunto com os padrões de aquisição delineados pelo Chartered Institute
of Procurement & Supply (CIPS).
sE11- Manage Supply Chain Technology: Engloba todos os processos responsáveis por definir,
implementar e gerir a ativação da tecnologia envolvida no planeamento, execução e gestão de
desempenho da supply chain.
Conseguirá a tecnologia blockchain satisfazer as necessidades e eliminar ou atenuaras dificuldades dos processos presentes na SCM?
A seleção das dificuldades e/ou necessidades de cada processo foi feita com base nas propri-
edades do blockchain discutidas na subsecção 2.3 para que, após uma análise profunda sobre os
processos existentes em cada categoria, desde os seus intervenientes, das suas métricas até as suas
atividades, fosse possível, de uma maneira quase direta, fazer a ligação e entender o potencial que
a utilização da tecnologia pode ter.
Observando as tabelas anteriores facilmente se compreende que cada processo apresenta ca-
racterísticas diferentes e que por sua vez levam a dificuldades e/ou necessidades díspares. Por
exemplo, qualquer categoria presente no nível de planeamento (plan) não apresenta qualquer grau
de importância perante a transparência, algo que é compreensível visto que os processos envolven-
tes apenas trabalham com informação interna à supply chain e não há a necessidade nem permissão
para que alguém externo consiga aceder ou acrescentar informação.
Através da Figura 5.5 é possível ver que diferentes níveis de processos atribuem diferentes
importâncias a cada fator. Por exemplo, a privacidade foi sempre um dos fatores com mais impor-
tância e a redundância um dos que apresentou menos.
Figura 5.5: Importância de cada parâmetro em cada nível
70 Potencial de Aplicação no contexto da Supply Chain Management (SCM)
O total de pontos possíveis caso a importância de cada fator em cada categoria fosse o máximo
("XX") seria de 448 e foram atingidos os 246 pontos (Tabela 5.7), o que resulta numa nota média
geral de importância de 1,1 (de 0 a 2) que indica um bom potencial para a utilização da tecnologia
neste caso de análise (Tabela 5.8).
No de Categorias 5 3 3 4 6 11 32Plan Source Make Deliver Return Enable Total
Verificabilidade Pública 10 3 0 4 6 7 30Integridade 5 6 4 4 6 15 40Imutabilidade 5 6 4 4 8 17 44Redundância 5 0 0 0 0 9 14Hierarquia 5 3 3 5 6 12 34Transparência 0 3 4 5 8 7 27Privacidade 10 3 5 7 10 22 57Total de Pontos Concedidos 40 24 20 29 44 89 246Total de Pontos Possíveis 70 42 42 56 84 154 448Percentagem de Pontos Concedidossobre Pontos Possíveis
57.14% 57.14% 47.62% 51.79% 52.38% 57.79%
Nota Geral (0 a 2) 1.14 1.14 0.95 1.04 1.05 1.16Tabela 5.7: Tabela de geral de análise
Total de Pontos Concedidos 246Total Pontos Possíveis 448Percentagem Pontos Conseguidos 55%Nota Média Geral (0/2) 1.10Tabela 5.8: Cálculo da nota média geral
Tendo em conta que o fator da redundância apresentou em 21% das categorias uma importân-
cia de 0, e se retirarmos este mesmo fator para as contas da nota média geral, a mesma sobe para
1,21 (Tabela 5.9).
Total de Pontos Concedidos na Redundância 14Total Pontos Possíveis 64Percentagem de Pontos Concedidos 21.88%Total de Pontos Concedidos 232Total Pontos Possíveis 384Nota Média Geral (0 a 2) 1.21
Tabela 5.9: Cálculo da nota média geral sem o parâmetro da redundância
Analisando a percentagem de pontos concedidos sobre pontos possíveis e a nota geral para
cada nível observa-se que o potencial de utilização para o nível make é o baixo comparativamente
com os outros níveis. Isto deve-se ao facto de ser responsável por cuidar "de todos os assuntos
relacionados com a transformação da matéria-prima no fabrico do produto final", subsecção 4.3.1.
5.5 Simulador para o Potencial de Aplicação no âmbito da Tecnologia Blockchain 71
Por outro lado, é possível verificar que o nível Enable é o que possui maior potencial de
utilização algo que de certa forma é lógico dado que é composto essencialmente por processos
que gerem, criam e transferem documentação.
Apesar de os processos que fazem parte desta categoria trabalharem com informação sensível
e terem uma grande responsabilidade no desenvolvimento do produto na supply chain, onde a
segurança e a imutabilidade são necessidades inquestionáveis, não
Na Figura 5.6, é possível observar que a privacidade e a imutabilidade são os dois parâmetros
com mais importância. Tendo em conta o matching já realizado concluí-se que estas são também
as propriedades da tecnologia blockchain onde os processos irão tirar mais proveito.
Figura 5.6: Análise por parâmetro de avaliação
É importante ter em conta que a análise realizada, mesmo considerando que o modelo SCOR
é especificamente destinado para uma supply chain, depende de caso para caso. Isto é, uma sup-
ply chain destinada para o mercado de roupa ou uma que trabalhe no mercado de pedras raras
pode apresentar graus de importância diferentes, tanto nas suas necessidades como para as tuas
dificuldades.
5.5 Simulador para o Potencial de Aplicação no âmbito da Tecnolo-gia Blockchain
Precisamente por considerar que as avaliações antes realizadas possam ser suscetíveis de opi-
nião, foi desenvolvido um simulador em Excel para que qualquer empresa, que utilize ou que pense
em utilizar o modelo SCOR, consiga medir, através de uma análise mais pessoal, o potencial da
utilização da tecnologia para o seu modelo empresarial.
Nesta plataforma o utilizador pode alterar o método de avaliação antes usado (de 0 a 2) para
o intervalo que entender e deverá preencher as tabelas que antes foram preenchidas com núme-
ros dentro do intervalo de avaliação escolhido, caso não aconteça a/as células preenchidas serão
identificadas a vermelho (Figura 5.7).
72 Potencial de Aplicação no contexto da Supply Chain Management (SCM)
Caso o utilizador entenda que uma categoria não deveria ser avaliada ou que a mesma não está
presente no seu modelo apenas terá de deixar a coluna relativa a essa categoria em branco.
Se apenas forem avaliadas algumas necessidades de uma categoria será também dado um
alerta que tal não é permitido, o utilizador deverá preencher as avaliações relativamente a todos o
parâmetros ou deixar tudo vazio.
Ao lado de cada tabela é apresentado num gráfico de barras o somatório da pontuação de cada
parâmetro de avaliação (Figura 5.7).
Figura 5.7: Amostra 1 do Simulador
Neste simulador é também dada a hipótese ao utilizador de colocar pesos para os níveis de
processos, independentemente de os colocar, no final são apresentados os cálculos do potencial
para as duas hipóteses, uma com os pesos indicados e outra com os processos todos, independen-
temente da categoria, a valerem o mesmo (Figura 5.8).
5.6 Exemplo de Implementação Blockchain
A tabela de processos, presente nos anexos, disponibilizada pela APICS [82] apresenta uma
lista de processos, categorizados pelos focos principais antes referidos (plan, source, make, deliver,
return, enable).
Após uma análise cuidada de todos os processos e das ligações/dependências entre eles foi es-
colhido para exemplo de implementação a categoria sE3 (Anexo A) que engloba todos os proces-
sos de recolha, manutenção, e publicação de dados e informações necessárias para o planeamento,
operação, medição e gestão da supply chain.
Exemplos dos dados que são e que podem ser trocados:
• Dados chave: dados básicos relativos aos clientes, fornecedores, matérias-primas, listas téc-
nicas, receitas, produtos, trabalhadores, processos e ativos necessários para a supply chain.
5.6 Exemplo de Implementação Blockchain 73
Figura 5.8: Análise Final do Simulador
• Dados transacionais: dados associados as compras, vendas, movimentos de materiais, ope-
rações de agregação de valor, stock, recolha, embalagem, envio e entrega de materiais e
produtos.
• Dados "Inteligentes": dados de sensores normalmente utilizados para IoT.
De seguida serão expostos, sobre a forma de imagens, o resultado e o funcionamento com a
implementação da tecnologia blockchain em sintonia com os processos antes referidos:
74 Potencial de Aplicação no contexto da Supply Chain Management (SCM)
Funcionamento do ponto de vista externo da cadeia
Figura 5.9: Cadeia Simplificada
Cadeia detalhada e representação das ações de cada utilizador
Figura 5.10: Ações tomadas por cada utilizador
Ações tomadas por cada utilizador e possibilidade de exportação para PDF
Figura 5.11: Histórico de ações na cadeia e possibilidade de exportação para PDF
5.7 Outras possibilidades de implementação 75
Finalização do processo
Figura 5.12: Esquema de finalização do processo
Comprovativo blockchain final
Figura 5.13: Comprovativo blockchain final
5.7 Outras possibilidades de implementação
Para além do armazenamento de informação, existem ainda outras possibilidades de imple-
mentação da tecnologia no exemplo anterior, por exemplo, a possibilidade de incorporar:
• Criptomoedas: Para a realização de todos os tipos de pagamentos, desta forma os interveni-
entes da cadeia excluem a possibilidade de um intermediário para a realização dos mesmos
pagamentos.(por exemplo, processos sS1.5, sS2.5 ou sS3.7 que correspondem todos à auto-
rização de pagamentos ao fornecedor)
• Smart Contracts: Possibilitaria a automatização de alguns processos.(por exemplo, pro-
cesso sD1.2 e sD2.2 que corresponde à receção e processamento dos pedidos)
Capítulo 6
Conclusão
Este capítulo resume as conclusões que foram sendo atingidas à medida que o trabalho foi
sendo desenvolvido, bem como as contribuições do mesmo. Como resultado das contribuições
dadas, são expostos possíveis trabalhos futuros.
6.1 Visão Global
Para facilitar uma visão geral do trabalho realizado, é importante relembrar os objetivos e as
questões de investigação:
• "Que tipo de processos poderão usufruir do potencial subjacente à tecnologia de
blockchain?"
• "Quais as propriedades da tecnologia blockchain que mais podem contribuir
para a melhoria da eficácia e eficiência dos processos de negócio?"
A tecnologia blockchain tem um enorme potencial e, para responder às questões de investigação,
foi importante um trabalho introdutório de estudo e análise das suas funcionalidades, propriedades
e o que já existe e pode ser aproveitado pelas empresas.
Através de uma análise cuidada por diversos setores e onde foram expostos alguns casos es-
pecíficos de algumas das empresas estudadas, é possível entender o potencial da tecnologia inde-
pendentemente do setor, localização e dimensão do negócio.
Por outro lado, o custo desta tecnologia continua a ser um problema. No entanto, este deve ser
visto como um investimento, atendendo às inúmeras vantagens como a imutabilidade, segurança,
privacidade, confiabilidade, encriptação de registos, transparências monetárias e ainda criação de
contratos inteligentes.
Posteriormente, foi avaliada a implementação da tecnologia no caso específico da supply
chain, após uma análise aos problemas no setor e às características do blockchain a que se po-
deriam recorrer para colmatar estes problemas.
77
78 Conclusão
Complementarmente, foi realizado um estudo sobre as plataformas de análise e gestão de
processos intraorganizacionais.
Para o caso específico da supply chain foi realizada uma análise aprofundada, segundo o mo-
delo SCOR, das categorias e dos processos existentes dentro de uma supply chain. Analisando
todas as métricas, atividades e entidades envolvidas em cada processo foi possível classificar, em
diferentes parâmetros, a importância que estes apresentavam para cada categoria. Parâmetros que,
por sua vez, eram iguais às propriedades da tecnologia blockchain discutidas na subsecção 2.3.
Desta forma foi possível qualificar a importância e realizar um matching entre as dificuldades
e/ou necessidades de cada processo com o potencial de utilização da tecnologia blockchain.
Atendendo à subjetividade que o processo de análise poderia ter, existindo a possibilidade
de ser diferente de empresa para empresa e de pessoa para pessoa, foi realizado um simulador
para que qualquer empresa, orientada segundo o modelo SCOR, consiga analisar o potencial da
tecnologia.
Por fim, foi realizada, sobre a forma de esquemas, uma simulação de como funcionaria a
tecnologia e os processos numa supply chain.
O estudo realizado sobre o blockchain e a análise de processos permitiu conhecer as potencia-
lidades e mais valias para as empresas, bem como o forte potencial que esta tecnologia apresenta
no que toca a satisfazer as necessidades e a colmatar as dificuldades inerentes aos processos de
negócio.
6.2 Trabalho Futuro
O trabalho realizado foi de natureza exploratória e abordou essencialmente a componente teó-
rica sobre a tecnologia blockchain. Por não ter sido o foco desta dissertação, mas ter despertado
interesse, um trabalho futuro seria, sem dúvida, integrando, por exemplo, num doutoramento, o
desenvolvimento de uma prova de conceito prática (programada) e a implementação da mesma
num caso real. Em termos mais práticos passaria por explorar melhor as frameworks de desenvol-
vimento, os tipos de blockchains existentes e os algoritmos de consenso.
Outro trabalho a desenvolver, de certa forma para completar o trabalho desenvolvido no ca-
pítulo 3, e tendo em conta que apesar dos modelos existentes cada empresa apresenta uma or-
ganização de processos diferente, seria entrevistar empresas de diversos setores e com diferentes
dimensões no mercado, com vista a explorar melhor o enquadramento das lacunas destes setores
com as vantagens de utilização do blockchain.
Reforçando a ideia presente no primeiro parágrafo, o objetivo seria aplicar a prova de conceito
numa empresa e tirar as respetivas conclusões.
Por fim, um dos próximos objetivos passa por colocar e melhorar o simulador desenvolvido
através do contacto com empresas e com profissionais na área do blockchain.
sP - P
lan
sS - S
ourc
esM
- Mak
esD
- Del
iver
sP1
Plan
Sup
ply C
hain
sP2
Plan
Sou
rce
sP3
Plan
Mak
esP
4 Pl
an D
elive
rsP
5 Pl
an R
etur
nsS
1 So
urce
Sto
cked
Pr
oduc
t
sS2
Sour
ce M
ake-
to-
Orde
r Pro
duct
sS3
Sour
ce En
ginee
r-to
-Ord
er P
rodu
ct
sM1
Mak
e-to
-Sto
cksM
2 M
ake-
to-O
rder
sM3
Engin
eer-t
o-Or
der
sD1
Deliv
er S
tock
ed
Prod
uct
sD2
Deliv
er M
ake-
to-
Orde
r Pro
duct
sD3
Deliv
er En
ginee
r-to
-Ord
er P
rodu
ct
sD4
Deliv
er R
etail
Pr
oduc
t
sP1.1
: Id
entif
y, Pr
ioriti
ze
and A
ggre
gate
Su
pply
Chain
Re
quire
men
tssP
1.2:
Iden
tify,
Prio
ritize
an
d Agg
rega
te
Supp
ly Ch
ain
Reso
urce
ssP
1.3:
Balan
ce S
uppl
y Ch
ain R
esou
rces
wi
th S
C Re
quire
men
tssP
1.4:
Esta
blish
and
Com
mun
icate
Su
pply
Chain
Plan
s
sP2.1
: Id
entif
y, Pr
iorit
ize
and A
ggre
gate
Pr
oduc
t Re
quire
men
tssP
2.2:
Id
entif
y, As
sess
and
Aggr
egat
e Pro
duct
Re
sour
ces
sP2.
3:
Balan
ce P
rodu
ct
Reso
urce
s wi
th P
rodu
ct
Requ
irem
ents
sP2.4
: Es
tabl
ish S
ourc
ing
Plan
s
sP3.1
: Id
entif
y, Pr
iorit
ize
and A
ggre
gate
Pr
oduc
tion
Requ
irem
ents
sP3.
2:
Iden
tify,
Asse
ss
and A
ggre
gate
Pr
oduc
tion
Reso
urce
ssP
3.3:
Ba
lance
Pro
duct
ion
Reso
urce
s wi
th P
rodu
ctio
n Re
quire
men
tssP
3.4:
Esta
blish
Pr
oduc
tion P
lans
sP4.
1: Id
entif
y, Pr
iorit
ize
and A
ggre
gate
De
liver
y Re
quire
men
tssP
4.2:
Id
entif
y, As
sess
and
Aggr
egat
e Deli
very
Re
sour
ces
sP4.
3:
Balan
ce D
elive
ry
Reso
urce
s and
Ca
pabi
lities
wi
th D
elive
ry
Requ
irem
ents
sP4.
4:
Esta
blish
De
liver
y Plan
s
sP5.1
: As
sess
and
Aggr
egat
e Ret
urn
Requ
irem
ents
sP5.
2:
Iden
tify,
Asse
ss
and A
ggre
gate
Re
turn
Res
ourc
essP
5.3:
Ba
lance
Ret
urn
Reso
urce
s wi
th R
etur
n Re
quire
men
tssP
5.4:
Esta
blish
and
Com
mun
icate
Re
turn
Plan
s
sS1.1
: Sc
hedu
le
Prod
uct D
elive
ries
sS1.2
: Re
ceive
Pro
duct
sS1.3
: Ve
rify P
rodu
ctsS
1.4:
Trans
fer P
rodu
ctsS
1.5:
Auth
orize
Su
pplie
r Pay
men
t
sS2.1
: Sc
hedu
le
Prod
uct D
elive
ries
sS2.
2:
Rece
ive P
rodu
ctsS
2.3:
Ve
rify P
rodu
ctsS
2.4:
Trans
fer P
rodu
ctsS
2.5:
Au
thor
ize
Supp
lier P
aym
ent
sS3.1
: Id
entif
y Sou
rces
of
Sup
ply
sS3.
2:
Selec
t Fin
al Su
pplie
r and
Ne
gotia
tesS
3.3:
Sc
hedu
le
Prod
uct D
elive
ries
sS3.4
: Re
ceive
Pro
duct
sS3.
5:
Verif
y Pro
duct
sS3.
6:
Trans
fer P
rodu
ctsS
3.7:
Auth
orize
Su
pplie
r Pay
men
t
sM1.1
: Sc
hedu
le Pr
oduc
tion
Activ
ities
sM1.2
: Iss
ue M
ater
ialsM
1.3:
Prod
uce a
nd Te
stsM
1.4:
Pack
age
sM1.5
: St
age P
rodu
ctsM
1.6:
Relea
se P
rodu
ct to
De
liver
sM1.7
: W
aste
Disp
osal
sM2.1
: Sc
hedu
le Pr
oduc
tion
Activ
ities
sM2.
2:
Issue
Sou
rced
/In-
Proc
ess P
rodu
ctsM
2.3:
Pr
oduc
e and
Test
sM2.4
: Pa
ckag
esM
2.5:
Stag
e Fin
ished
Pro
duct
sM2.
6:
Relea
se Fi
nish
ed
Prod
uct t
o Deli
ver
sM2.7
: W
aste
Disp
osal
sM3.1
: Fin
alize
Pro
duct
ion
Engin
eerin
gsM
3.2:
Sc
hedu
le Pr
oduc
tion
Activ
ities
sM3.
3:
Issue
Sou
rced
/In-
Proc
ess P
rodu
ctsM
3.4:
Prod
uce a
nd Te
stsM
3.5:
Pa
ckag
esM
3.6:
St
age
Finish
ed P
rodu
ctsM
3.7:
Relea
se P
rodu
ct
to D
elive
rsM
3.8:
W
aste
Disp
osal
sD1.1
: Pr
oces
s Inq
uiry
an
d Quo
tesD
1.2:
Rece
ive, E
nter
, an
d Vali
date
Ord
ersD
1.3:
Rese
rve I
nven
tory
an
d Det
erm
ine
Deliv
ery D
ate
sD1.4
: Co
nsol
idat
e Ord
ers
sD1.5
: Bu
ild Lo
ads
sD1.6
: Ro
ute S
hipm
ents
sD1.7
: Se
lect C
arrie
rs a
nd
Rate
Shi
pmen
tssD
1.8:
Rece
ive P
rodu
ct
from
Sou
rce
or M
ake
sD1.9
: Pi
ck P
rodu
ctsD
1.10:
Pa
ck P
rodu
ctsD
1.11:
Load
Vehi
cle
& Ge
nera
te
Ship
ping
Doc
ssD
1.12:
Sh
ip P
rodu
ctsD
1.13:
Re
ceive
and
Verif
y Pro
duct
by
Cus
tom
ersD
1.14:
In
stall
Pro
duct
sD1.1
5:
Invo
ice
sD2.1
: Pr
oces
s Inq
uiry
an
d Quo
tesD
2.2:
Re
ceive
, Con
figur
e, En
ter a
nd
Valid
ate O
rder
sD2.
3:
Rese
rve I
nven
tory
an
d Det
erm
ine
Deliv
ery D
ate
sD2.4
: Co
nsol
idat
e Ord
ers
sD2.
5:
Build
Load
ssD
2.6:
Ro
ute S
hipm
ents
sD2.7
: Se
lect C
arrie
rs an
d Ra
te S
hipm
ents
sD2.
8:
Rece
ive P
rodu
ct
from
Sou
rce
or M
ake
sD2.
9:
Pick
Pro
duct
sD2.1
0:
Pack
Pro
duct
sD2.1
1: Lo
ad P
rodu
ct
& Ge
nera
te
Ship
ping
Doc
ssD
2.12:
Sh
ip P
rodu
ctsD
2.13:
Re
ceive
and
Verif
y Pro
duct
by
Cus
tom
ersD
2.14:
In
stall
Pro
duct
sD2.1
5:
Invo
ice
sD3.1
: Ob
tain
and
Resp
ond t
o RFP
/RF
QsD
3.2:
Ne
gotia
te an
d Re
ceive
Con
tract
sD3.
3:
Ente
r Ord
er,
Com
mit
Reso
urce
s &
Laun
ch P
rogr
amsD
3.4:
Sche
dule
Inst
allat
ion
sD3.
5:
Build
Load
ssD
3.6:
Ro
ute S
hipm
ents
sD3.7
: Se
lect C
arrie
rs &
Ra
te S
hipm
ents
sD3.
8:
Rece
ive P
rodu
ct
from
Sou
rce
or M
ake
sD3.
9:
Pick
Pro
duct
sD3.1
0:
Pack
Pro
duct
sD3.1
1: Lo
ad P
rodu
ct
& Ge
nera
te
Ship
ping
Doc
ssD
3.12:
Sh
ip P
rodu
ctsD
3.13:
Re
ceive
and
Verif
y Pro
duct
by
Cus
tom
ersD
3.14:
In
stall
Pro
duct
sD3.1
5:
Invo
ice
sD4.
1: Ge
nera
te
Stoc
king S
ched
ule
sD4.
2:
Rece
ive P
rodu
ct
at S
tore
sD4.
3:
Pick
Pro
duct
fro
m ba
ckro
omsD
4.4:
St
ock S
helf
sD4.
5:
Fill S
hopp
ing C
art
sD4.
6:
Chec
kout
sD4.
7:
Deliv
er an
d/or
in
stall
sR - R
etur
nsE
- Ena
ble
sSR1
So
urce
Ret
urn
Defe
ctive
Pro
duct
sSR2
So
urce
Ret
urn
MRO
Pro
duct
sSR3
So
urce
Ret
urn
Exce
ss P
rodu
ct
sDR1
De
liver
Ret
urn
Defe
ctive
Pro
duct
sDR2
De
liver
Ret
urn
MRO
Pro
duct
sDR3
De
liver
Ret
urn
Exce
ss P
rodu
ct
sE1
Man
age S
uppl
y Ch
ain B
usin
ess
Rules
sE2
Man
age
Supp
ly Ch
ain
Perfo
rman
ce
sE3
Man
age
Supp
ly Ch
ain D
ata
and I
nfor
mat
ion
sE4
Man
age
Supp
ly Ch
ain
Hum
an R
esou
rces
sE5
Man
age
Supp
ly Ch
ain
Asse
ts
sE6
Man
age
Supp
ly Ch
ain
Cont
ract
s
sE7
Man
age
Supp
ly Ch
ain
Netw
ork
sE8
Man
age S
uppl
y Ch
ain R
egul
ator
y Co
mpl
iance
sE9
Man
age
Supp
ly Ch
ain R
isk
sE10
M
anag
e Su
pply
Chain
Pr
ocur
emen
t
sE11
M
anag
e Su
pply
Chain
Te
chno
logy
sSR1
.1:
Iden
tify D
efec
tive
Prod
uct C
ondi
tion
sSR1
.2:
Disp
ositi
on
Defe
ctive
Pro
duct
sSR1
.3:
Requ
est D
efec
tive
Prod
uct R
etur
n Au
thor
izatio
nsS
R1.4
: Sc
hedu
le De
fect
ive
Prod
uct S
hipm
ent
sSR1
.5:
Retu
rn
Defe
ctive
Pro
duct
sSR2
.1:
Iden
tify M
RO
Prod
uct C
ondi
tion
sSR2
.2:
Disp
ositi
on
MRO
Pro
duct
sSR2
.3:
Requ
est
MRO
Ret
urn
Auth
oriza
tion
sSR2
.4:
Sche
dule
M
RO S
hipm
ent
sSR2
.5:
Retu
rn
MRO
Pro
duct
sSR3
.1:
Iden
tify E
xces
s Pr
oduc
t Con
ditio
nsS
R3.2
: Di
spos
ition
Ex
cess
Pro
duct
sSR3
.3:
Requ
est E
xces
s Pr
oduc
t Ret
urn
Auth
oriza
tion
sSR3
.4:
Sche
dule
Exce
ss
Prod
uct S
hipm
ent
sSR3
.5:
Retu
rn
Exce
ss P
rodu
ct
sDR1
.1:
Auth
orize
Def
ectiv
e Pr
oduc
t Ret
urn
sDR1
.2:
Sche
dule
Defe
ctive
Re
turn
Rec
eipt
sDR1
.3:
Rece
ive D
efec
tive
Prod
uct
(inclu
des v
erify
)sD
R1.4
: Tra
nsfe
r De
fect
ive P
rodu
ct
sDR2
.1:
Auth
orize
MRO
Pr
oduc
t Ret
urn
sDR2
.2:
Sche
dule
MRO
Re
turn
Rec
eipt
sDR2
.3:
Rece
ive
MRO
Pro
duct
sDR2
.4:
Trans
fer
MRO
Pro
duct
sDR3
.1:
Auth
orize
Exce
ss
Prod
uct R
etur
nsD
R3.2
: Sc
hedu
le Ex
cess
Re
turn
Rec
eipt
sDR3
.3:
Rece
ive
Exce
ss P
rodu
ctsD
R3.4
: Tra
nsfe
r Ex
cess
Pro
duct
sE1.1
: Ga
ther
Bus
ines
s Ru
le Re
quire
men
tssE
1.2:
Inte
rpre
t Bus
ines
s Ru
le Re
quire
men
tsE
1.3:
Docu
men
t Bu
sines
s Rul
esE
1.4:
Com
mun
icate
Bu
sines
s Rul
esE
1.5:
Relea
se/P
ublis
h Bu
sines
s Rul
esE
1.6:
Retir
e Bus
ines
s Ru
le
sE2.1
: In
itiat
e Rep
ortin
gsE
2.2:
An
alyze
Rep
orts
sE2.
3:
Find R
oot C
ause
ssE
2.4:
Prio
ritize
Ro
ot C
ause
ssE
2.5:
De
velo
p Co
rrect
ive A
ctio
nssE
2.6:
Ap
prov
e & La
unch
sE3.1
: Re
ceive
M
ainte
nanc
e Re
ques
tsE
3.2:
De
term
ine/
Scop
e W
ork
sE3.
3:
Main
tain
Co
nten
t/Cod
esE
3.4:
Main
tain
Acc
ess
sE3.
5:
Publ
ish In
form
atio
nsE
3.6:
Ve
rify I
nfor
mat
ion
sE4.
1: Id
entif
y Skil
ls/Re
sour
ce
Requ
irem
ent
sE4.
2:
Iden
tify A
vaila
ble
Skills
/Res
ourc
essE
4.3:
M
atch
Skil
ls/Re
sour
ces
sE4.
4:
Dete
rmin
e Hiri
ng/
Rede
ploy
men
tsE
4.5:
De
term
ine
Train
ing/
Educ
atio
nsE
4.6:
Ap
prov
e, Pr
iorit
ize
and L
aunc
h
sE5.1
: Sc
hedu
le As
set
Man
agem
ent
Activ
ities
sE5.
2:
Take
Ass
et O
ff-lin
esE
5.3:
In
spec
t and
Tro
ubles
hoot
sE5.4
: In
stall
and
Confi
gure
sE5.
5:
Clea
n, M
ainta
in
and R
epair
sE5.
6:
Deco
mm
issio
n an
d Disp
ose
sE5.7
: In
spec
t M
ainte
nanc
esE
5.8:
Re
inst
ate A
sset
sE6.1
: Re
ceive
Con
tract
/Co
ntra
ct U
pdat
essE
6.2:
En
ter a
nd
Dist
ribut
e Con
tract
sE6.
3:
Activ
ate/
Arch
ive
Cont
ract
sE6.4
: Re
view
Cont
ract
ual
Perfo
rman
cesE
6.5:
Ide
ntify
Pe
rform
ance
Issu
es/
Oppo
rtunit
iessE
6.6:
Id
entif
y Re
solu
tions
/Im
prov
emen
tssE
6.7:
Selec
t, Prio
ritize
an
d Dist
ribut
e Re
solu
tions
sE7.1
: Se
lect S
cope
an
d Org
aniza
tion
sE7.2
: Ga
ther
Inpu
t an
d Dat
asE
7.3:
Deve
lop S
cena
rios
sE7.4
: M
odel/
Sim
ulat
e Sc
enar
ios
sE7.5
: Pr
ojec
t Im
pact
sE7.6
: Se
lect a
nd A
ppro
vesE
7.7:
Deve
lop C
hang
e Pr
ogra
msE
7.8:
Laun
ch
Chan
ge P
rogr
am
sE8.1
: M
onito
r Re
gulat
ory E
ntiti
essE
8.2:
As
sess
Reg
ulat
ory
Publ
icatio
nssE
8.3:
Id
entif
y Reg
ulat
ory
Defic
iencie
ssE
8.4:
Defin
e Rem
ediat
ion
sE8.
5:
Verif
y/Obt
ain
Licen
sesE
8.6:
Pu
blish
Re
med
iatio
n
sE9.1
: Es
tabl
ish C
onte
xtsE
9.2:
Id
entif
y Risk
Even
tssE
9.3:
Qu
antif
y Risk
ssE
9.4:
Evalu
ate R
isks
sE9.
5:
Miti
gate
Risk
sE10
.1:
Deve
lop S
trate
gy
and P
lansE
10.2
: Pr
e-Pr
ocur
emen
t / M
arke
t Tes
t and
M
arke
t Eng
agem
ent
sE10
.3:
Deve
lop
Proc
urem
ent
Docu
men
tatio
nsE
10.4
: Su
pplie
r Sele
ctio
n to
Parti
cipat
esE
10.5
: Iss
ue IT
T / R
FQsE
10.6
: Bi
d / Te
nder
Ev
aluat
ion a
nd
Valid
atio
nsE
10.7:
Co
ntra
ct A
ward
and
Impl
emen
tatio
n
sE11
.1:
Defin
e Sup
ply
Chain
Tech
nolog
y Re
quire
men
tssE
11.2
: Id
entif
y Tec
hnol
ogy
Solu
tion
Alte
rnat
ives
sE11
.3:
Defin
e/Up
date
Su
pply
Chain
Te
chno
logy
Road
map
sE11
.4:
Selec
t Tec
hnol
ogy
Solu
tion
sE11
.5:
Defin
e and
Dep
loy
Tech
nolog
y So
lutio
n sE
11.6
: M
ainta
in an
d Im
prov
e Tec
hnol
ogy
Solu
tion
sE11
.7:
Retir
e Tec
hnol
ogy
Solu
tion
80
Referências
[1] Bitcoin - Open source P2p money. URL: https://bitcoin.org/en/.
[2] Marco Iansiti and Karim R. Lakhani. The Truth About Blockchain. Harvard BusinessReview, (January–February 2017), January 2017. URL: https://hbr.org/2017/01/the-truth-about-blockchain.
[3] Jan Mendling, Schahram Dustdar, Avigdor Gal, Luciano García-Bañuelos, Guido Gover-natori, Richard Hull, Marcello La Rosa, Henrik Leopold, Frank Leymann, Jan Recker,Manfred Reichert, Ingo Weber, Hajo A. Reijers, Stefanie Rinderle-Ma, Andreas Solti, Mi-chael Rosemann, Stefan Schulte, Munindar P. Singh, Tijs Slaats, Mark Staples, BarbaraWeber, Matthias Weidlich, Wil Van Der Aalst, Mathias Weske, Xiwei Xu, Liming Zhu,Jan Vom Brocke, Cristina Cabanillas, Florian Daniel, Søren Debois, Claudio Di Ciccio,and Marlon Dumas. Blockchains for Business Process Management - Challenges and Op-portunities. ACM Transactions on Management Information Systems, 9(1):1–16, Febru-ary 2018. URL: http://dl.acm.org/citation.cfm?doid=3146385.3183367,doi:10.1145/3183367.
[4] Karl Wust and Arthur Gervais. Do you Need a Blockchain? In 2018 Crypto Valley Con-ference on Blockchain Technology (CVCBT), pages 45–54, Zug, June 2018. IEEE. URL:https://ieeexplore.ieee.org/document/8525392/, doi:10.1109/CVCBT.2018.00011.
[5] Tien Tuan Anh Dinh, Rui Liu, Meihui Zhang, Gang Chen, Beng Chin Ooi, and Ji Wang.Untangling Blockchain: A Data Processing View of Blockchain Systems. arXiv:1708.05665[cs], August 2017. arXiv: 1708.05665. URL: http://arxiv.org/abs/1708.05665.
[6] Merkle tree, February 2019. Page Version ID: 884587907. URL: https://en.wikipedia.org/w/index.php?title=Merkle_tree&oldid=884587907.
[7] Kiyun Kim. Modified Merkle Patricia Trie — How Ethereum sa-ves a state, June 2018. URL: https://medium.com/codechain/modified-merkle-patricia-trie-how-ethereum-saves-a-state-e6d7555078dd.
[8] L. M. Bach, B. Mihaljevic, and M. Zagar. Comparative analysis of blockchain consen-sus algorithms. In 2018 41st International Convention on Information and Communica-tion Technology, Electronics and Microelectronics (MIPRO), pages 1545–1550, Opatija,May 2018. IEEE. URL: https://ieeexplore.ieee.org/document/8400278/,doi:10.23919/MIPRO.2018.8400278.
[9] Giang-Truong Nguyen and Kyungbaek Kim. A Survey about Consensus Algorithms Usedin Blockchain. page 28.
81
82 REFERÊNCIAS
[10] Bhabendu Kumar Mohanta, Soumyashree S Panda, and Debasish Jena. An Overviewof Smart Contract and Use Cases in Blockchain Technology. In ResearchGate. URL:https://www.researchgate.net/publication/328581609_An_Overview_of_Smart_Contract_and_Use_Cases_in_Blockchain_Technology.
[11] Bisola Asolo. Blockchain Oracles Explained, May 2018. URL: https://www.mycryptopedia.com/blockchain-oracles-explained/.
[12] Nuno Filipe Tavares. Using Blockchain and Smart Contracts in a reverse auction syndicatede-procurement platform. page 68.
[13] Matthäus Wander. English: Graphic of data fields in Bitcoin block chain. Simplified depic-tion: some fields are missing., June 2013. URL: https://commons.wikimedia.org/wiki/File:Bitcoin_Block_Data.svg.
[14] Marko Vukolic. Rethinking Permissioned Blockchains. In Proceedings of the ACMWorkshop on Blockchain, Cryptocurrencies and Contracts - BCC ’17, pages 3–7, Abu Dhabi,United Arab Emirates, 2017. ACM Press. URL: http://dl.acm.org/citation.cfm?doid=3055518.3055526, doi:10.1145/3055518.3055526.
[15] Permissioned vs Permissionless Blockchains: Understanding theDifferences, July 2018. URL: https://blockonomi.com/permissioned-vs-permissionless-blockchains/.
[16] Torp Port. Centralized vs decentralized vs distributed networks +Blockchain, July 2018. URL: https://medium.com/@torp_port/centralized-vs-decentralized-vs-distributed-networks-blockchain-f895416dc22.
[17] The 4 Types of Blockchain Networks Explained. URL:http://iltanet.org/blogs/deborah-dobson/2018/02/13/the-4-types-of-blockchain-networks-explained.
[18] Monero: Home. URL: https://getmonero.org/index.html.
[19] Ethereum Project. URL: https://www.ethereum.org/.
[20] Dash. URL: https://www.dash.org/.
[21] Dogecoin. URL: https://dogecoin.com/.
[22] MultiChain | Open source blockchain platform. URL: https://www.multichain.com/.
[23] Monax Industries. URL: https://monax.io/company/.
[24] r3.com. URL: https://www.r3.com/.
[25] What We Do – Energy Web Foundation. URL: https://energyweb.org/what-we-do/.
[26] Dylan Yaga, Peter Mell, Nik Roby, and Karen Scarfone. Blockchain technology overview.Technical Report NIST IR 8202, National Institute of Standards and Technology, Gaithers-burg, MD, October 2018. URL: https://nvlpubs.nist.gov/nistpubs/ir/2018/NIST.IR.8202.pdf, doi:10.6028/NIST.IR.8202.
REFERÊNCIAS 83
[27] Ethereum Project. URL: https://www.ethereum.org/.
[28] Hyperledger – Open Source Blockchain Technologies. URL: https://www.hyperledger.org/.
[29] Mike Hearn. Corda: A distributed ledger. page 56.
[30] The ShipChain Ecosystem · Shipchain. URL: https://docs.shipchain.io/index.html.
[31] BigchainDB 2.0 Whitepaper • • BigchainDB. URL: https://www.bigchaindb.com/whitepaper/.
[32] Solutions | modum.io. URL: https://modum.io/solutions/overview.
[33] Academic Papers. URL: https://www.iota.org/research/academic-papers.
[34] Quorum | J.P. Morgan. URL: https://www.jpmorgan.com/global/Quorum.
[35] Ripple - One Frictionless Experience To Send Money Globally. URL: https://ripple.com/.
[36] Brad Chase and Ethan MacBrough. Analysis of the XRP Ledger Consensus Protocol. ar-Xiv:1802.07242 [cs], February 2018. arXiv: 1802.07242. URL: http://arxiv.org/abs/1802.07242.
[37] Blockchain for Agriculture and Food: Findings from the pilot study.
[38] Food safety. URL: https://www.who.int/news-room/fact-sheets/detail/food-safety.
[39] carVertical – VIN Decoder & Car History Report. URL: https://www.carvertical.com/en/.
[40] How Blockchain will Change the Automotive Industry,July 2018. URL: https://www.asynclabs.co/blog/how-blockchain-will-change-the-automotive-industry/.
[41] AMO Foundation | Discover value in your driving | Homepage. URL: https://www.amo.foundation/.
[42] AMO Labs Official Blog. Introducing AMO Blockchain,April 2018. URL: https://medium.com/amo-blockchain/introducing-amo-blockchain-d3d9612b2796.
[43] Bitnation. Documents. URL: https://tse.bitnation.co/documents/.
[44] BitNation Emergency Response -. URL: https://refugees.bitnation.co/.
[45] What is e-Residency | How to Start an EU Company Online. URL: https://e-resident.gov.ee/.
[46] Por que razão Relvas perdeu a licenciatura. URL: https://expresso.pt/sociedade/2016-06-30-Por-que-razao-Relvas-perdeu-a-licenciatura.
84 REFERÊNCIAS
[47] edgecoin.io. About - Edgecoin.io | Learn more about Edgecoin. URL: https://www.edgecoin.io.
[48] AdCoin | Global Blockchain payment solution for online advertising – GetAdCoin.com.URL: https://www.getadcoin.com/.
[49] Prana Adi Saputra. AdCoin Plugins for Woocommerce and WordPress,October 2018. URL: https://medium.com/@pranaadisaputra/adcoin-plugins-for-woocommerce-and-wordpress-de3efbae095d.
[50] Grid Singularity. URL: https://gridsingularity.com/.
[51] J.P. Morgan and Microsoft announce strategic partnership to drive enterprise adop-tion of Quorum, May 2019. URL: https://news.microsoft.com/2019/05/02/j-p-morgan-and-microsoft-announce-strategic-partnership-to-drive-enterprise-adoption-of-quorum/.
[52] Newzoo Cuts Global Games Forecast for 2018 to $134.9 Billion;Lower Mobile Growth Partially Offset by Very Strong Growth in Con-sole Segment. URL: https://newzoo.com/insights/articles/newzoo-cuts-global-games-forecast-for-2018-to-134-9-billion/.
[53] Xsolla using MGO tokens. URL: https://xsolla.com/blog/en/payments/156/xsolla-adds-new-crypto-mobilego-mgo.
[54] MGO Token Is Now the Preferred Currency for Game Pu-blishers, February 2019. URL: https://hacked.com/mgo-token-is-now-the-preferred-currency-for-game-publishers/.
[55] FirstBloodTM | Competitive esports & Online Gaming Tournaments. URL: https://www.firstblood.io/.
[56] DreamTeam - The Ultimate Teambuilding and Skill-Growing Platform. Start with yourDream Team. URL: https://dreamteam.gg/.
[57] Play2live is the first full-blown decentralized streaming platform for gamers and esports fans.URL: https://play2live.io/en/.
[58] Jonas Askergren Anna Orring. Karta: Här finns Sveriges mest lovande startups –vinnarna på 33-listan 2019. URL: https://www.nyteknik.se/tekniknyheter/karta-har-finns-sveriges-mest-lovande-startups-vinnarna-pa-33-listan-2019-6958538.
[59] ChromaWay. URL: https://chromaway.com/.
[60] Key insights into the future of philanthropy. URL: https://www.fidelitycharitable.org/articles/future-of-philanthropy-trends.shtml.
[61] Michael Pisa and Matt Juden. Blockchain and Economic Development: Hype vs. Reality.page 49.
[62] The decentralisation of good | Blockchain, DAOs and future of charity. URL:https://www.cafonline.org/about-us/blog-home/giving-thought/the-future-of-doing-good/the-decentralisation-of-good.
REFERÊNCIAS 85
[63] UNICEF Innovation Fund Graduate: Trustlab – Stories of UNICEFInnovation. URL: http://unicefstories.org/2018/04/11/unicef-innovation-fund-graduate-trustlab/.
[64] GIL_ixo. URL: https://ixo.foundation/faqs/.
[65] Blockchain experiment in humanitarian aid, July 2017. URL: https://startnetwork.org/news-and-blogs/blockchain-experiment-humanitarian-aid.
[66] Disberse | Working with leading donors and aid agencies. URL: https://disberse.com/our-work.
[67] Leading charities look to blockchain to reduce losses and track... Reuters, July 2017. URL:https://www.reuters.com/article/us-aid-blockchain-idUSKBN19X0A1.
[68] Mathias Weske. Business process management: concepts, languages, architectures. Sprin-ger, Berlin ; New York, 2007.
[69] Types of Business Processes - Primary, Support and Management Process, January 2018.URL: http://www.q3edge.com/types-business-process/.
[70] What is business process? - Definition from WhatIs.com. URL: https://searchcio.techtarget.com/definition/business-process.
[71] 8 Types of Business Processes from Start to End of Business, February 2019. URL: https://www.marketing91.com/8-types-of-business-processes/.
[72] Supply Chain Council. SCOR 12.0 supply chain operations reference model. The SupplyChain Council, Place of publication not identified, 2017. apics.org/scor.
[73] Productivity and Quality with Performance Measures & Metrics - APQC, January 2014.URL: https://www.apqc.org.
[74] American Productivity and Quality Center (APQC) (2012). PROCESS CLASSIFICATIONFRAMEWORK. Version 6.0.0 edition. URL: http://www.apqc.org/.
[75] Business Process Framework (eTOM), December 2017. Page Version ID: 814907812.URL: https://en.wikipedia.org/w/index.php?title=Business_Process_Framework_(eTOM)&oldid=814907812.
[76] TM Forum - Accelerating Industry Transformation Through Collaboration. URL: https://www.tmforum.org/.
[77] Figure - Business Process Framework (eTOM), December 2017. Page Ver-sion ID: 814907812. URL: https://en.wikipedia.org/w/index.php?title=Business_Process_Framework_(eTOM)&oldid=814907812.
[78] COBIT 2019. URL: https://www.isaca.org/cobit/pages/default.aspx.
[79] Business Process Framework (eTOM), December 2017. Page Version ID: 814907812.URL: https://en.wikipedia.org/w/index.php?title=Business_Process_Framework_(eTOM)&oldid=814907812.
86 REFERÊNCIAS
[80] Rhonda R. Lummus and Robert J. Vokurka. Defining supply chain management: a his-torical perspective and practical guidelines. Industrial Management & Data Systems,99(1):11–17, February 1999. URL: https://www.emeraldinsight.com/doi/10.1108/02635579910243851, doi:10.1108/02635579910243851.
[81] Gender-based violence in global supply chains: Resource Kit. URL: https://gbv.itcilo.org/index.php/appendix/show/id/4.html.
[82] APICS. QUICK REFERENCE GUIDE - SCOR V 12.0. URL:http://www.apics.org/docs/default-source/scor-p-toolkits/apics-scc-scor-quick-reference-guide.pdf.
Recommended