SAP’s UI makeover
TAKE NOTE (Insights into SAP solutions and Emerging Technology)
SAP users are using, by SAP’s estimation, some 300,000 different input screens that were designed for different product lines, numerous product versions, different vertical industry requirements, etc. These screens were developed using approximately 20 different software tools. To overhaul this much code in its entirety is an expensive and time-consuming chore.
Fiori
SAP is taking a step-wise, measured approach using a Pareto rule (80/20) process to fix the most used application screens first. Enter 25 newly released Fiori applications. Fiori applications represent the most used 35-80% of user transaction screens within the ECC (the successor to the R3) product line.
Fiori apps have one code line and use popular web browsers to accept user transactions. IE 9, IE 10, Safari, Chrome and other browsers are supported. The software has a built-in gateway to the ECC products. Attachments to other SAP product lines (e.g., Business One) are not currently developed but may be in the future.
Fiori exists as part of SAP’s effort to “Renew” the older software that customers are using and may continue to use for some time. Given the high cost to upgrade a full SAP product installation, businesses might appreciate getting modern, newer screens (and in some situations a better input process) for common, frequently used transaction input screens.
The Fiori applications are only 9-10 weeks old at this time. Customer interest/adoption of them has been brisk, to date.
Personas
SAP has another effort underway called Personas. The goal of this work is to simplify SAP ECC input screens. Over the years, SAP has added countless new fields to its input screens to accommodate the functional needs of different verticals, various tax/regulatory requirements, etc. As a result, the screens are often full of data elements that aren’t relevant for this particular client or user. All of those extra fields simply clutter up the screen workspace and detract from the user’s experience with the solution. A case could be made that superfluous fields are counterproductive from an efficiency and effectiveness perspective.
Personas permit users to possess more streamlined screens that are personalized for their firm and role. Personas do not permit users to add all-new data fields though. Personas can combine fields from a couple of related screens into one as long as the new persona screen stays within the functional boundaries of a given transaction. So, for example, you could build a single screen persona that permits rapid entry of one-line invoices as all of the header and detail information for this simple transaction can fit on one screen and does not violate back-end processing requirements.
Personas do not change the functionality of the back end ECC system. They simply make some functions faster and easier to complete.
For more information check out our archives for the March 2013 Newsletter titled – “SAP Screen Personas , UX personalization FAST!”
Design & co-innovation center
Some SAP customers want more than software tools. They want help in graphic design and better understanding of how people really want to interact with technology.
Like Infor’s Hook & Loop , SAP has created a design center staffed with non-standard SAP types. This facility was opened in early 2011 in Los Altos, California and is humorously called AppHaus. AppHaus’ mission is to help SAP customers imagine a different and better way for their technology and people to interact. This Mercury News article has more on AppHaus.
Bottom line
UI and UX redesigns alone won’t make old products suddenly relevant again.
Software vendors that have grown via the acquisition of many different software firms also inherited those firms’ data models, technical architectures, user interfaces, screen development toolsets, etc. The retooling that a new UI brings is great but it is only the beginning of a long journey to re-tool and re-imagine what a product could and should be in an age where video, big data, analytics and, of course, cloud/mobile/social exist.
UNDER DEVELOPMENT (Information for ABAP Developers)
The SAP IDoc Technology
You have probably heard the term IDoc many times. This blog will help you understand exactly what an IDoc is and what it does.
A basic IDoc type has the following attributes – (You can display a Basic IDoc Type in transaction WE30).
The first attribute we will look at is NAME. This can be up to a thirty−character name. Custom IDoc types always start with a Z. The last two characters are the version number. After a basic IDoc type is released and you move to a newer version of the SAP system, any changes to the structure of the basic IDoc type will create a new basic IDoc type. In general, the version number is incremented by one. So in the example above we have a custom IDoc type named ZOIPRO01. If we changed this after it was released, it would be named ZOIPRO02…etc..etc. You can see SAP doing the same thing if you look at the delivered Basic IDoc Types ORDERS01, ORDERS02, ORDERS03, …. ORDERS06…etc.
Q&A (Post your questions to Facebook or Twitter and get your Questions answered)
Q.We have a need to process millions of records from a foreign system to an SAP R/3 platform, with fast processing times. We have switched from IDoc to BDC recently for performance considerations. How do IDoc, BDC and BAPI compare with one other, if I need to further boost the performance and processing turn-around time?
A. Wow! First let me say that I am completely surprised that the BDC’s are more performant than the IDocs!
That said, lets look at the principles behind each technology, as this might lead us to distill am answer to your question. What is an IDoc? Its a DATA CONTAINER first and foremost. So when an IDoc is processed the Data is unpacked by stripping the IDoc. Then some means of performing the intended process is used like a BDC or a BAPI, or in some cases SAP will execute direct updates to their tables.
A BDC simulates the user’s data entry by filling in the screens for the user via the BDC DATA internal table, then executes the SAP standard transaction as the user would.
Now lets further refine the idea of performance…. I would suggest that we could split the idea of performance into 2 buckets. Collective and individual performance.
Collective performance can be be tweaked via ALE & IDocs using parallel processing, dedicated server groups and the like. BDC, on the other hand is not as robust and scalable. This is why I was surprised to hear the BDC’s were performing better than the IDocs overall.
Individual performance is more specific to the transactions or set of transactions in the intended LUW. Do you think it is accurate to say that individual performance is agnostic to the way DATA is introduced into the system (IDoc, BDC, BAPI)? If you answered yes, then individual performance is solely dependent on the code behind the process.
Summing up …to continue to improve individual performance I believe you have a few options going forward….
(1) Buy a bigger machine (LOL ,, not kidding)
(2) Process a single IDoc using RBDMANIN via SE30 to get a better idea where time, if any, is being lost. If the problems looks like it is in your RDBMS access, you might want to add a custom index to the table.
(3) Also using ST05 to trace and EXPLAIN the BDC can isolate non-performant access paths to the data.