MY #SITSP TALK ON SAP FIORI

First of all: relax. No, I'm not going to just share some slides here. But I spoke at #SITSP last week about SAP Fiori, and instead of just sharing my slides with the local participants (like I usually do), this time I decided to write a blog post and publish it here.

But SAP Fiori isn't breaking news anymore, specially here. So why do I feel like it's a good idea to send these KB of HTML to your computer mobile device right now? Well, when someone wants to learn SAP Fiori (and I say this from my own experience as well), they usually start by googling it, then they end up here, then buy a book and even take some classes either in OpenSAP or Learning Hub. But once they do that, they usually enter this strange "Limbo" zone, where you feel like you already got the joke, but not enough to go ahead and start implementing it.

I believe that a lot of you who's already experienced been there as well at some point. That's usually the part where documentation doesn't help that much anymore. You have to learn from experience. Experience that you don't have yet. Oh, if at least you could get some tips from someone who's just stepping out of this Limbo...

Thats what my talk focused on. I wanted to start this discussion and share advice while learning from other's experiences as well. So, if you're in the Limbo right now, sit back and enjoy the reading. If you already passed through it, please help us here . Also, share it with your friends in the Limbo as well.

Well, my talk focused on four tips on implementing standard SAP Fiori apps, plus one on designing new ones. Here they are:

#1 Choose your apps wisely

As experienced SAP professionals, we are used to large and complex projects. Every new module or solution required months of project effort to implement it. SAP Fiori isn't. I know that we advertise it a lot with it's more than 800 apps. But I know it can be overwhelming. So, spend time learning using the SAP Fiori App Library. Learn to use the filters, to read the app documentation, and to showcase it to your potential (either internal or external clients) whenever possible. Use SAP Fiori Demo Cloud for it whenever possible.

For instance, if you're using ERP 6.0 EHP7 with ORA/ASE/etc, you can filter the apps that work with Any DB. The number goes down from 800+ to about 160. If you filter by your backend and specific modules, you'll end up with about a dozen apps to evaluate. Also, do realize that you must focus on the apps that will provide instant-value to the company. That's why a lot of people start with approval workflows, HCM or sales apps.

Once you mix what your company needs, what SAP solutions it currently uses, and what apps are available, you'll have about a handful of apps to choose from. I personally recommend up to 3 apps to begin with. It will help you keep your project schedule and costs short.

#2 On-premise / Cloud

Now that you know what apps you'll want, it's time to decide the way to go: on-premise or cloud? This choice is more subjective, since it relies on each company's current scenario. Usually, if you already have enough free hardware and no problem securing your landscape to enable external access to it, then on-premise is usually the way to go for these first projects (at least here in Brazil). On the other hand, if you're short on hardware, or your company has it's datacenter and/or IT staff offshored, then the Fiori Cloud Edition can be simpler to get started with. One thing that you'll need to keep in mind while choosing the apps in tip #1 is that SAP Fiori Cloud Edition doesn't provide the 800+ apps. So, do check if the app is available.

#3 Pay attention to the pre-requisites

Now that you're sure about the apps, it's time to go deep. Learn everything you can about these apps. It usually means:

• Read the App Documentation in SAP Fiori App Library 
• Read all the SAP Notes related to it 
• Read marketplace documentation about it 
• Search SCN for topics about it 

Thats how you'll learn that Approve Requisitions rely on SBWP workflows, not ME54 items. This useful info will prevent you from extending the project from 5 weeks to 8. Thats how you'll know that you'll need ESS configured in order to use most HCM apps. This could make your project even longer, which is not a good thing, specially if you're working in a "fixed-price" project, or the simplest POC.

#4 Focus on the "quick-wins"

Specially if it's the very first SAP Fiori project. Remember: this project will set the tone for SAP Fiori at your company. If you did a good job implementing the right apps (meaning, useful apps with a solid productive process), the users will ask for more and more from SAP Fiori. However, if you choose an app that isn't important to your company, people will associate that to SAP Fiori. The same will happen if you face issues during the implementation phase, even if they're not directly related to SAP Fiori. For instance, if you're trying to make the users adopt SAP Fiori for PO approval, try to keep the same release strategies. Changing company policy at the same time may cause the "it was good before this went live" effect. This is not good. You want to make it as smooth and nice as possible.

Developing your own apps

Finally, it might be that the solution you're looking for isn't available in the 800+ apps. Then you'll need to develop your own. If that's the case, consider the UX principles for SAP Fiori:

It means that, instead of thinking about the solution as we always did (complex and multiple-screen-featured transactions or reports), realize that you almost always split it into several SAP Fiori apps. One way of doing it is to start with the process diagram.

Then, when designing the software solution, consider the steps and roles involved. Try to think what's the simplest way to complete each step, from that role's perspective. This will eventually bring you to several apps, broken down by roles, like this.

And, of course, map those back into the process flow, so that we can make sure everything is covered.

Please note that you can create very good mock-ups and prototype a lot using tools like SAP Build andAxure as well. This is important, as these new concepts are even harder for a key user to understand before he or she goes through a couple of projects like this one. I mean, it's very different from simply writing down "lets make an ALV" to the spec.

Source: MY #SITSP TALK ON SAP FIORI