实施Fiori LaunchPad的组织，无论是否有S/4 HANA，都在开始一段奇妙的新旅程。摆脱传统的菜单驱动导航提供了一个设计新用户体验的巨大机会，公有云市场，提供信息来驱动用户行为。实际上，这就是新业务流程的交付，这正是SAP digital transformation的意义所在。

但这并不是免费的，有着长期规划SAP项目历史的组织以前从未为这种类型的用户体验设计做过预算。实践和思维过程都是新的，因此您现有的团队成员不知道如何去做。他们可能学习速度很快，而且才华横溢，但通过Fiori Launchpad交付转换不仅仅是打开东西，也不仅仅是询问用户他们需要什么——更多。因此，如果潜在的好处是巨大的，你真的想使用初学者吗？

从一开始就有很多问题。设计Fiori LaunchPad需要什么？我们能自己做吗？SAP提供什么现成的服务？我们应该使用预先交付的SAP目录和角色吗？我们如何决定需要10000个应用中的哪一个？我们如何最好地提供Fiori的好处，同时使事情在未来易于维护？

开始

在你的沙盒中打开一切：所有SICF节点，所有网关服务。打开Fiori搜索，打开S/4HANA中驱动分析应用程序所需的BW片段。通过阅读Fiori应用程序库，你无法找到你需要的内容，而只能自己查看。

在这个阶段，使用预交付的目录、组和业务角色–开始构建自己的应用程序还为时过早但不要给你的用户每个角色，因为这对性能有很大的影响。因此，为你的分析师定义功能用户，商业大数据分析，并映射到SAP角色。

现在你可以开始查看10000多个应用程序了，好消息是你不需要查看10000个应用程序。首先，其中80%的应用程序实际上是在HTML GUI中运行的SAP事务，具有Fiori主题：它们与SAPGUI中可用的事务完全相同。剩下的20%中，有些应用程序显然不需要—也许您没有运行HCM或PLM等，有些应用程序显然需要—例如FactSheets和重用组件。其余的都是简单金融所需要的，其他的都是在可管理的范围内分为不同的功能。所以在这个阶段，你的分析师应该能够弄清楚哪些应用肯定超出了范围。

第二个任务是确定需要什么：你不太可能需要所有的8000个t代码应用，什么叫云，但是分析师应该能够设计什么样的SAP事务需要与Fiori应用程序一起使用。

目录设计

目录可以用于不同的目的，但可以以相同的方式进行维护，因此准确地描述不同类型的目录非常重要：

[1]技术目录。这些目录由SAP提供，通常在后端服务器中，并复制到前端服务器。它们包含基本的磁贴定义和相关的目标映射。

[2]业务目录。这些目录更符合用户的角色，并引用技术目录中的磁贴定义。SAP交付的业务目录包含磁贴定义和磁贴/应用程序所需的所有相关目标映射。

第一步是定义您自己的业务目录。这有两个目的：

由于目标映射与用户的技术角色密切相关，因此从安全角度来看，在更精细的级别上管理这些映射是非常有用的。在这种情况下，您需要定义具有磁贴定义且没有目标映射的业务目录，再加上存储目标映射但没有磁贴定义的安全目录，十大淘客软件排名，这样前端服务器上的角色可以在更精细的层次上与后端服务器上的角色匹配，但实际上，它涉及到定义业务目录，然后通过引用技术目录中的定义添加平铺定义和目标映射的练习。

提示：仔细设计自定义目录的命名约定，您将得到相应的奖励。

其他事务

使用预先交付的t代码应用程序是不够的：您将需要额外的tile来调用SAP没有提供tile的事务。实际上可能有数百个这样的应用程序–有很多SAP事务没有预先交付的tile。此外，您将需要为您构建并要启动的任何自定义事务提供tile通过LaunchPad。除此之外，您可能还需要为特定的角色风格定义Tile。最后，您可能已经使用Stelo、Fiori元素或其他应用程序开发工具交付了您自己的自定义应用程序。

所有这些都是通过使用"应用程序描述符"工具定义您自己的技术目录来实现的，然后您可以参考将平铺和目标映射到您的业务目录中的方式与预交付的平铺完全相同。这是一项简单的任务，但您可能会花费大量时间：如果需要500个平铺，则仅为这些平铺选择500个图标非常耗时！

提示：在可能的情况下，不要在多语言场景中维护瓷砖上的文本，而是引用事务中的文本，因此您不需要翻译所有瓷砖文本。

组设计

到目前为止，所有内容都是由功能范围驱动的。从现在起，设计转向用户体验。这是一个不经认真考虑就很容易出错的问题，这是所有好处所在。