“Uberization” of the Service Sector

Blockchain and Distributed-Ledger-Technologies are mostly linked with disruption in the financial or legal sector. But do these technologies have the potential to affect the service sector as well? This use case should show how the implementation of a virtual factory can change and “uberize” the service sector as we know it today.

Authors: Philipp Rosenbach, Philipp Sandner, Marcel Kaiser

Current production process

Uberization is the process of changing the market for service by introducing a different way of buying or using it. As of today, the majority of all firms use similar production facilities. There is a certain factory building, where suppliers deliver raw materials. These materials are then stored in inventory, and processed through the company’s machines until the product is finalized. But what would happen if there could happen a liberalization in a factory, that the factory itself would not be owned by one certain company, but by many, and with several independent machines in it?

How to decrease the employed capital

That is what the following use case should describe. This approach would state a virtual factory wherein the interoperability of several agents would not only lead to more (cost) efficient production processes, but also to a reduction of the working capital employed in the production process, as well as an enhancement of the underlying Cash Conversion Cycle. Further aspects, which this use-case triggers are the reduction of personnel costs for the owner of the factory, breaking up production monopolies, increase of plant efficiency as well as tracking and monitoring of the supply chain.

Figure 1: The Cash Conversion Cycle

An exemplary process could be the following: A picker robot is used by platform operators (e.g. Amazon) to transport goods from the machinery of Agent A to machinery of agent B within the Virtual Factory. The robot charges itself at a low energy level at a charging station provided by another service provider. Payment is made automatically and periodically (e.g. every 10 seconds) per small chunk of energy through a Smart Contract. The machinery of agent B then would be triggered to set up the next step in the production process.

Technical requirements and feasibility

The environment needed for the use-case contains a factory, certain agents (which include service providers, machinery, interfaces, sensors, and smart oracles). Additionally, the preconditions include modularity of the production facility, compatible interfaces and protocols of the participating agents (all agents are part of a network and can exchange data. Furthermore, the interoperability of payment transactions between agents must be given.

There is a similarity between this use case and the use case of “Tokenized production tracking”, both need a broader distribution of smart oracles, as mentioned above, there has to be a correctly specified blockchain system and acceptance and usage of it.

Maintenance requirements for the factory

The maintenance of the system is needed to be discussed further. Since there is more than just an IT-system to be implemented, there is more than just a system administrator needed. Our solutions for the maintenance problem would be a centralized organ which could communicate if there are failures with the machinery of a certain company/ agent so that this certain agent could rule out the difficulties. The IT-infrastructure would be kept intact through one administrator, which would be contracted by the owner of the factory. Further maintenance services such as charging the picker robots, would be done through charging points, which would also be connected through the blockchain infrastructure.

Requirements for blockchain implementation

With regards to the question of which type of Blockchain we should first distinguish which environment we have created and how the participants stand to each other. An organized environment within a national boundary, involving large, highly trusting actors requires a different setup compared to a more diverse, asymmetric, and international environment. The latter might be more suited for blockchain implementation, ceteris paribus. The system that will be realized is required to have the ability to store data, additionally, there must be the assumption that it is a non-trusting environment. Furthermore, it has to be taken into account that smart contracts are a key driver of the whole use-case in case of blockchain implementation.

Industrial data space as a driver for implementation

An alternative approach to the issue could be an industrial data space that also offers decentralized storage of data in a multi-party framework. A data space describes an architectural model for data integration, which is characterized by distributed data storage, different data sources. It does not have a shared semantic between the parties. Known governance models could be applied and sufficient amounts of flexibility exist for the use case. However, the exact functionality of the architecture would have to be, like in the DLT scenario, carefully crafted and worked out in detail. The referenced system has been the result of the german research project “Industrial Data Space” (see this white paper).

The traceability of the products is another key factor, we have to keep in mind. The traceability should be regarded from two different points. First, the production steps have to be traceable internally so that possible errors, quality problems or just incompatibility can be explored easily. Second, more and more customers focus on the origin of their goods, especially on production conditions. Therefore public traceability must be given as well.

Market potential

For sure, with this use case, we are a little ahead of the time, but nevertheless, the market we are looking at is broad. Potentially every production facility worldwide could be operated in this way. Yet we would focus on a rather realistic scenario and include only production facilities in the regions of Europe (especially GAS and Benelux region and Nordics), the United Kingdom, the United States of America as well as Canada. In these regions, the hardware and software requirements, as well as workforce, and legal requirements are given, that such an implementation would be possible.

Within that market, nearly every production facility can be triggered by the described use case. Nevertheless, as of today, such implementation would require substantially more CapEx than it would save money and enhance traceability and efficiency. Therefore, the horizon for the implementation would be around five years and more.

Business case analysis

The cost-saving potential in this use case can be divided into personnel cost savings and the reduction of working capital. While personnel cost savings would occur through the reduction of FTEs in certain factories, as well as more efficient use of the workforce. Fewer personnel would be needed and therefore save the company money. In addition to that, with several players in one company, covering all necessary production steps, every single agent in the factory would have to send fewer employees.

The cost savings through a reduction in working capital occur from more efficient use of inventories and a reduction in accounts payables and accounts receivables. This will lead to less tied-up capital in working capital and therefore would provide more liquidity.

Remarks

This research and development project content was partially funded by the German Federal Ministry of Education and Research (BMBF) within the funding number 16KIS0906 and implemented by the VDI/VDE Innovation + Technik GmbH. The authors are responsible for the content of this publication.

If you like this article, we would be happy if you forward it to your colleagues or share it on social networks. More information about the Frankfurt School Blockchain Center on the Internet, on Twitter, or on Facebook.

Philipp Rosenbach is a project manager and research assistant at the Frankfurt School Blockchain Center (FSBC). He worked on several research and consulting topics with the main focus on industrial blockchain applications. Feel free to contact him via mail (philipp.rosenbach@fs-blockchain.de).

Prof. Dr. Philipp Sandner is head of the Frankfurt School Blockchain Center (FSBC) at the Frankfurt School of Finance & Management. In 2018, he was ranked as one of the “Top 30” economists by the Frankfurter Allgemeine Zeitung (FAZ), a major newspaper in Germany. Further, he belongs to the “Top 40 under 40” — a ranking by the German business magazine Capital. The expertise of Prof. Sandner, in particular, includes blockchain technology, crypto assets, distributed ledger technology (DLT), Euro-on-Ledger, initial coin offerings (ICOs), security tokens (STOs), digital transformation and entrepreneurship. You can contact him via mail (email@philipp-sandner.de) via LinkedIn (https://www.linkedin.com/in/philippsandner/) or follow him on Twitter (@philippsandner).

Marcel Kaiser is a project manager (project leader for iBlockchain) and research assistant at the Frankfurt School Blockchain Center (FSBC). His expertise is primarily decentralized finance (DeFi) and industrial blockchain applications. He analyzes the impact of blockchain technology on the economy in his master thesis. He speaks at public events about topics like Libra, quantum cryptography, and blockchain in general. Feel free to contact him via mail (marcel.kaiser@fs-blockchain.de), LinkedIn, or Xing.