Skip to Content

Putting everything together – the finished Personas project

I’ve written a few blogs now about the various techniques I’ve used while building our Personas project. It is about time I wrote about what happens when you put them all together.


We started with a target group of users in mind. These users are in our Estates department, which is responsible for the maintenance of the University campus. They are maintenance-focused people, but also have some financial responsibility. They are people who either currently don’t use SAP or who have tried to use it but have been scared off. Either way they now ask others when they need information from our SAP ERP system, and we wanted to get them back on the system and doing this for themselves. Our first step was to talk to them about what they wanted to be able to get from SAP, and to others in the department about what these users should be wanting to get from SAP (not all users were existing SAP users, and so didn’t know how to answer the question). This gave us a list of things to build and was mostly about look-up of various things (cost collectors, functional locations, services orders, purchase orders) and some simple reporting. The overall idea was to design a “launchpad” on the main SAP home screen so that when these users logged in they saw something like this rather than the usual SAP menu:




From here they can lookup:

  • cost collectors (cost codes, as we call them) by code or by description, and run commitment and actual line item reports for them
  • purchase orders by code or by vendor
  • job dockets (our name for service orders) by number or description, and get a list of purchase orders for them
  • functional locations by code or description, and get a list of service orders for a selected location.


Some of these functions, if you run them in standard form, need to be given various organisational magic tokens (plant, purchasing group, order type, etc.) if the results are to be restricted just to things interesting to our Estates department. Because these screen flavours are built specifically for this one department, such values can be defaulted behind the scenes so that the users don’t need to know them.


That’s pretty much all they need to do, and all this happens without having to rummage about in the SAP menu or knowing a transaction code, or that transactions even exist. Everything they need either happens directly on this screen or is accessible from the screen’s buttons.


How does it work in practice? Let’s look at the sections one by one, starting with the “Cost codes” section. First, you can put any type of cost collector (cost center, internal order, wbs element) in the cost code field, press <ENTER> and get the code’s description, and the “Display” button will take you to the appropriate master data display transaction. If you don’t know the code but know part of the description, the “Find” button will help you find it – searching across all type of cost collectors in one go. Finally, you can run some line items reports. Obviously the “Commitments” and “Actuals” buttons run the line item report appropriate for the type. They also fill in the most common date range – start and end of the current financial year – although that can be overridden if necessary. Let’s see all that in action:




The purchase order section is similar. Type in a PO number and hit <ENTER> and you get some details of the PO, enough for you to know if you’ve got the right one and maybe enough to avoid looking any further – delivery status, for example. Searching for POs is interesting. When trying to find a PO, people here generally start from the vendor, but often what our users call a vendor doesn’t always exactly match what SAP calls a vendor. We therefore need a fuzzy match on vendor, and to build a list of POs for all matching vendors. Note again a sensible date range is defaulted, which can be overridden if you need to look further back. Here it is in action:




And that “OPeRA” button? That’s just an easy-to-find link to our e-purchasing system.


Job dockets (service orders) and functional locations work in the same way – quick lookups and fuzzy searching. One interesting feature here is how the two have been linked. Looking up a service order also shows you the corresponding functional location, from which a single button click can take you to a list of all other service orders raised against the same location. That makes it easy to find duplicates and more importantly recurring faults that need some more serious attention than just fixing yet again. And that’s just one click from entering the initial service order number – much faster than doing the same thing in SAPgui. Again, let’s see that:




So far this has mostly been about making information easy to find, and has been about building a “launchpad” screen rather than just simplifying standard SAP transactions. For this group of users, that is what was required. But I have one example of simplifying a transaction that makes a huge difference. Service orders contain a lot of information, for good reason. Service Management is used in many different and sometimes complex applications, and while probably nobody needs all of the information on a service order, it isall needed by somebody. And the service order display transaction IW33 therefore needs to display it all, somehow, resulting in the standard version being very complex. It turns out we need very little of it, but what we do need is scattered throughout the transaction and beyond. This video shows what is needed in SAPgui to get to all of the information our users need from a service order:



That’s a little time consuming, obviously. We can do better. By typing the service order number into our Personas launchpad screen and hitting “Display” we get this. All of the information needed is grabbed from the various places visited in the above video and presented in one screen. No menus, no tabs, no drilling out to the service notification. So much easier.




And that’s it. All in all, pretty simple, at least on the surface! There are a couple things to note about all this:

  • all of the screens/transactions you can reach from the launchpad have Personas versions. Sometimes they have been simplified just a little, sometimes a lot, but they will always have the Warwick branding and a consistent look and feel. Note that there is no transaction code box anywhere.
  • In the videos here, the “Basic View” flavour, the standard version of each screen, is visible. Our Estates users do not have that. They only have the Personas versions of each screen.
  • there is a little custom development hiding behind all this. In particular, the fuzzy searching for cost collectors and purchase orders does not exist as standard SAP functionality and so some custom ABAP reports were written.


Most importantly, though, this was all designed and built to make it easier for our users to do their job. They were involved throughout the design process and this was built to work they way they think, as much as possible. The easier the system is to use, the more likely it is to be used, and used properly.


This system is now live. It is currently being used by just a handful of people, but training – much shorter training than if we were using standard SAP transactions – is underway and there will shortly be about 20 users of it. I’m sure there will be some tweaking and further development over the next few weeks as users get to grips with it, but I think it will remain largely as you see it here.


We’re now starting to think about our next Personas project.

You must be Logged on to comment or reply to a post.
  • Well done, well explained

    What you have described is true in any SAP environment

    I like your description of the "magic tokens" to find what you are looking for - a plant code, etc.

    Thank you for the great videos.

    We have SAP GuiXT - I wonder if we could accomplish the same as personas?

    • GuiXT can certainly do some of this. You'll need some of the the paid-for components of GuiXT to get the scripting capabilities. There are things that Personas can do that GuiXT can't, but I'm not exactly sure how close you can get. It has been a while since I used GuiXT to any great extent.


  • Hi Steve,

    Thanks for the article. Lot's of useful information and very clearly communicated.

    It is a pity that this is a separate licensed product, by SAP User as I understand it. All to simplify the SAP UI. For most companies that will mean a business case to justify it's purchase. However the productivity and usability gains would be a big positive.

    IW33 is about the most used SAP transaction where I am working at the moment, so that part hit a note as well. Perhaps a trial or demo here might be worth it.

    Cheers & Thanks, Phil G.

    • Plant maintenance has featured in more of my Personas conversations than any other part of ERP6! The simplification of IW33, from 60 seconds of clicking around to a single static screen, is one of the reasons we chose this particular group of users for our first personas project.


  • Thank you Steve...I'm looking to apply this solution in PM area especially for casual users like technicians who sometimes get frustrated with various fields and tabs in IW31...I wanted to know what version of Personas (i.e. 1 or 2) you're using here as well how easy it's to create launch pads and modify some of screens...


    • This is all Personas 1. Personas 2 doesn't support the scripting to do all of the automation involved in what I've built.

      The hard part of a Personas project isn't building the screens, it is in figuring out what to build that would work best for your users. To build from scratch everything I've described in this blog would take just a few days. The time consuming parts are the discussions with users, the resultant process and visual design and the iterative nature of it all. You don't just build it once. What you see above is probably our fourth iteration. Some parts have remained constant throughout, others have been thrown away and rebuilt.

      As for the implementation, I would say the hardest part is building robust scripts that handle errors gracefully. If you are going to build something that works nicely for your users, it should also fail nicely. I wrote a little about that here: Creating bullet-proof Personas scripts. This needs lots of testing as some failures, or screen flow variations, are very data dependent.

      Simplifying IW31 in the same way as I did with IW33 could be a big win, and may not be a big project. I would encourage you to think about a launchpad, though, to hide the SAP menu and transactions codes completely if possible. Our users like that a lot.


  • Hi Steve,

    Thanks for a wonderful demonstration. I wonder how did you manage the PO Search? I am trying to replicate the scenario you have developed, but can not figure out how did you get that PO List. I tried using PO Search in ME23N, but that got messy. Then I tried ME2L, but it returned considerably large data and my flavor became non-responsive (that is another query, but maybe later). So I am figuring a better option for this.

    Will you please throw some light on it?

    Thanks and Regards


    • Sometimes you want to do something in a Personas project that doesn't map directly to standard SAP functionality. I talked about this issue specifically here: A little bit of programming can make a big difference to Personas.

      In summary, you are right that there's no standard report that does what you need to implement that PO search. I wrote a custom ABAP report for it that worked exactly as I needed. All the fuzzy matching is done in the ABAP so the Personas part is very simple. The cost collector search demonstrated above is the same. There is no standard report that will include multiple types of cost collector so I had to write one.

      I describe my Personas project as building something that works the way the users think, and that doesn't always exactly match how SAP works as standard so occasionally you need to give it some help!


      • Hi Steve,

        A million thanks for the reply. I often considered custom development to off load complexity from Personas, but thought that might be defeating the purpose of the product !!! Now it is much clear, thanks to your response. So if we do not find a straight-forward way to do it in standard SAP we can consider using Z developments.However, I think it should not be a practice 🙂

        Once again thanks for helping out and providing guidance.



    • That is the standard SAP home screen, with the menu and the water ripples image. It has transaction code SMEN, although most people don't realise that! So, this is the first screen the Estates users see when they login. The "Estates" flavour for this transaction is their default flavour.

      I've simply taken everything off the screen and replaced it all with my custom elements.

  • Hi Steve,

    I wonder if you have come across a situation where you needed to put line breaks in a multi line "label"/"text box". I am working with ME21N and we have created a sort of a wizard with the final screen displaying a shopping basket of selected item details (from a table). While I am able to retrieve the selected item details as a concatenated string (Service No1 + Service Desc1, Service No2 + Service Desc2, Service No3 + Service Desc3 .....), I am stumped over here as I need to display each line item in a separate line. I tried using "\n" in JS but that seems to work on alerts and confirm boxes, not field labels or text boxes.



  • HI Steve,

    Excellent blog, Thank you. We are currently workin on an implemenation plan for Personas so this has come in very handy for us.

    thanks and keep up the good work.