Good day my dears!
After a looong silence of some months I’m back in SCN blogging business. I had lots to do somewhere else, and also lots to blog somewhere else. That’s life when one has only one conscious CPU core in the brain…
I just came back from a leadership summit in Orlando last week, combined with a short visit at SAPPHIRE after so many years of not attending.
The best thing about such events is the chance to meet very interesting people, including new friends, good-old-friends, new colleagues and good-old-colleagues. One of those good-old-colleagues, with whom I shared a cab to the airport on my way back to Frankfurt (we were 3 people, not counting the driver, to share the cab, so that at least this particular trip was environmentally acceptable…), told me about one of the projects he is working on at the moment at SAP. It is about collecting, prioritizing and releasing meaningful customer requirements for SAP standard products as part of short and dynamic release cycles and SAP Support Packages. They work in tight collaboration with ASUG, DSAG and SAP User Groups in general.
This is a great initiative form my point of view. In my old times at SAP it was sometimes a cumbersome process to manage customer driven requirements for SAP products. We had long and inflexible lists of requirements, and more often than not they represented big data graveyards… My colleague mentioned that for practical reasons they do not keep requirements for more than one year. Once they finish a customer requirements project, they start anew, and “delete” the requirements which did not make it to get developed after all…
Such strategy is from my point of view not only more practical, but also philosophically better than “keeping all requirements forever”. It is like letting your ToDo lists grow forever or your Idea Management Database grow forever… It makes no sense to do that, it rather bothers people’s creativity, innovation potential, and freedom, and it uses too many IT resources, including Hard Disk, Flash Disk, RAM, and superfluous CPU time (the sum of lots of small contributions may get bigger than we think), which translates into wasted money, electricity, energy for cooling, natural resources, operational overhead, needless backups, needless archiving…
This does not change with HANA… We should not save data forever, only because it is possible and apparently cheaper than before. In some scenarios, more Intelligence in Business may partly come from “dark data” which now can be addressed with HANA, but the opposite can also be true: Overflow of data and over-information may lead to stupidity, paralysis, and wasted energy, rather than intelligence.
Let’s be a bit stingy with data! Information needs to be destroyed from time to time in order to release new ideas, new concepts, new innovative energy, and new, fresh data!
Founder and Managing Director