Recently I’ve been working on an S/4HANA implementation, and one interesting outcome was the number of transactions that were required as Fiori tiles which were not already included in the pre-delivered SAP catalogs.
This included things as simple as VA01, in order to call the (webgui) transaction directly rather than through the filtering transaction ‘VAX1_VBTYP’. It included all the transactions where SAP personas flavors have been defined. It included all the custom transactions. It added up to hundreds of tiles – and that’s the learning I’ve taken – an effective Fiori LaunchPad involves a mix of SAP-provided and customer-defined tiles.
When designing the LaunchPad experience, some these transactions were provided as links rather than tiles in order to manage space, and to provide prominence for the commonly-used apps and transactions. The result is great – it gives the users everything they need through the Fiori LaunchPad experience.
However, I’m not happy with the result. Simply providing users with a webgui, and a Fiori tile to launch the SAP transaction, doesn’t represent an enormous step forward for me. It’s just a different – albeit improved – navigation tool.
The benefits of S/4HANA come from digital transformation – and that requires real process change. That’s why analytics is so important: Users in the new world need to start from analytics, which in turn drives their behaviour. The analytics tiles and overview pages are absolutely core to this. Providing users with lots of plain tiles, or tiles with (let’s face it, meaningless) SAP icons, doesn’t empower new processes or insights or behaviour.
But here we are, in a world where S/4HANA is the new standard, and that standard requires the addition of (possibly) hundreds of additional tiles in order to deliver complete roles through the Fiori LaunchPad. But those additional tiles hold back organisations from deriving the benefits of S/4HANA. There’s a logical bind – it’s like S/4HANA is delivered with a pair of handcuffs. And so this must be an issue for every S/4HANA customer.
The solution is through the creation of dynamic and custom tiles, which can include rich information and analytics. But that’s not so easy: Every custom tile is like a mini Fiori app, designed in WebIDE, bound to a custom SAP Gateway service. Few organisations are going to have the budget to develop hundreds of custom tiles.
So the boffins at Arch have come up with a real solution to enable fast, easy delivery of custom tiles. Crucially, this enables organisations to build their own library of custom tiles without using WebIDE, without developing SAPUI5, and without developing Gateway Services. We call it ‘Stelo Tile Builder’.
With this new tool we can better support dynamic tiles, by removing the need to build a Gateway service each time: Instead a simple function module is enough to supply the dynamic tile data.
But of course, the main value is for custom tiles. Tiles can be built directly in the Fiori LaunchPad Designer, at remarkable speed, and therefore, extremely low cost.
Here’s an example of a LaunchPad, showing a mixture of standard SAP tiles and user-defined tiles:
And now here’s that same LaunchPad, with tiles built using Stelo Tile Builder:
The analytics in the microcharts and numeric tiles are crucial, but notice also how images can enhance the user experience.