People often ask us what the exact motivation behind Peakboard is and why we believe the world needs Peakboard. This first blog post will tell a little bit about our background and development.

The initial idea for Peakboard goes back further than usual in the digital world, almost 20 years back to 2002. After successfully dropping out of my physics studies, I was a permanent developer at the well-known German company Würth. Although the structures there were those of a major corporation, there was a strong willingness for pragmatic innovations around logistics. Of course, this meant streamlining and optimizing internal logistics processes, but it also meant a constant flow of innovations aimed at the customer – in my case, major clients from the industrial sector. The boss at that time had the idea of what we called the NASA cockpit.  By the way, that is what it’s still called today. Large monitors should be set up to display key logistics figures in real time. If visitors were guided through the halls, they could be impressed with the numbers on the dashboard. Additionally, it was supposed to give employees an understanding of the complex logistics machinery and provide a general overview. The NASA cockpit will be remembered by everyone who was involved as a very, very time-consuming project. It consumed several months of programming work that could have been compressed into a few days or even hours using Peakboard.

The second origin of the Peakboard idea lies with Theobald Software, Peakboard’s parent company. Their software is typically used in traditional architectures for business intelligence. In a nutshell, data is extracted from operational systems such as SAP, prepared, aggregated, enriched, stored in a data warehouse, loaded multidimensionally in-memory, and then displayed in an analysis environment such as Tableau, Qlik, or Power BI at the very end of this extensive journey. What has been established for the classic analysis of key figures does not apply if you want to manage or optimize an operational process directly.
There are two important reasons for this: The first reason is that the displayed data must be as up-to-date as possible. It cannot be older than a few minutes or even seconds and, depending on the use case, there should be no time offset at all (e.g. in a machine control system). The second reason against a classic BI approach is agility. The before mentioned approach requires a certain amount of structural planning. Each change must be followed up in several steps (extraction, preparation, storage, etc.). This, of course, is deadly to any agile process optimization and leads to confusing workarounds instead of promoting agility to gain a competitive advantage. We have all heard the phrase “we’ll leave that for now; we need the IT-department to do that” – a death blow argument.

There are certainly many arguments in favor of Peakboard, but these two – the benefit of real-time information and the value of agility – best represent the Peakboard idea and why it is simply not enough to use a discarded PC that you plug into a monitor.