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.