This blog is the last in my series looking at OrgAudit, part of the SAP Org Visualization by Nakisa suite of applications that supports SAP HCM on premise Org Management. The first blog was an introduction to what OrgAudit is, the second looked at building the business case to implement it, the third part looked at the standard functionality and the fourth at some of the technical aspects in deploying and configuring the application. I’m rounding off the series by sharing some final thoughts on how I believe OrgAudit could be improved.
Note: I drafted this blog before the release of 4.0 SP1 but have edited to include references to functionality that was introduced in SP1 where applicable.
Consistency
There are a few places where I’d like to see some alignment with recent updates in OrgChart. This covers the structure and names of tabs, labelling of fields and also their contents. Examples would be the layout of the position and employee fields on those details panels, putting links into the structure tab (as per OrgChart), use of the position icons in nodes, as well as having the position boxes showing the incumbent employee’s name in at least some views.
Consistency should also be applied to the common data (position and employee fields) shown on the position details panel for the organisation structure compared to the one accessed via the position org chart.
Usability
It is interesting to see how HR professional users use the application and I think there are a few small changes that would help them navigate to the information they want to see.
One theme I’ve noticed during the training sessions I’ve run is that once the user had investigated an error deeply enough to determine its cause, then they wanted to see all objects affected by this type of error. So, it might be that a certain country’s process causes an error to occur so they want to isolate that rule in that country (or equally it could be an org unit, personnel area or company code rather than a country). OrgAudit has lots of search listings to do this, but it also offers lots of places where it tells you that there are X errors of a certain type, status or severity. What the users wanted was the ability to click the numerical value and see a list of all errors matching those criteria.
So if you are looking at an org unit details panel (see above) and it lists 843 high errors relating to OM then clicking the number 843 would show the list of those 843 errors.
I (and several users) would like to have the ability to print/export the dashboards. You can export/print org charts, export listing results, and print detail panels … but not dashboards.
I think it would be helpful to order the statuses for a given error in date descending order (newest at the top) so the user can see the history of the error in chronological order … and even better, to offer sorting by clicking the column headings.
Finally, all dates should respect the date formatting (so that if the user selects a different date format, then they should all change).
Note: In 4.0 SP1 only date is shown (time is not).
Rules
Definitions
I think the default rule definitions could be better with the text used to describe the rule, reason and how to resolve being improved and made more consistent across the rules. At each client I’ve spent time doing this for the rules they’ve chosen to activate.
Variety
Obviously, I think the application will be expanded to include further rules. This is an obvious direction for OrgAudit to take. But perhaps more importantly the mechanism for creating and tailoring rules needs to be improved … it is there, but I think it can (and probably will) be improved as the product evolves. If you have a specific idea for a rule, why not add a comment to this blog?
Configuration
I’d also like to see data extraction for rules separated a little more and associated with the enabled rules. At a recent client they used two thirds of all of the rule templates, but the audit extraction steps still extracted all tables and joined them. I did some analysis and believed there were 15 SAP tables extracted that I didn’t have an interest in; some had little or even no content at this client, but one had 1.3M records in it and took nearly an hour to extract (data they had no interest in). Ideally activating a rule would activate the extraction and join of (and only of) the data required.
Whilst some improvements were made in the rule wizard in 4.0 SP1 including abstracting out the filter configuration I think there is still significant potential to improve this aspect of the data extraction and auditing.
Administration
The rules are essentially business logic and with each client I’ve worked with, the business has been keen to have key users (e.g. an HRIS employee) view, or even administer them.
They don’t see it as an IT task, nor do they want to go through involved change management to release such a business change into production. This presents a real challenge for Nakisa to consider. Clearly there is a technical complexity in allowing such updates to be carried out by an end user. Whilst there is therefore a clear business risk, there is also a clear gain in terms of time to react and address issues by enabling HR to own and control these changes.
To deliver the right sort of functionality I believe there are four key areas to be addressed. They are presented here in what I believe to be the increasing order of complexity to achieve:
- View existing rules, the filters and keywords.
- Amend existing rules, the filters and keywords
(so they are used by the next scheduled audit). - Apply new rules from existing templates.
- Create new templates (then rules from them).
One thing you can do already is create a read only AdminConsole user (see Admin guide) which does go some way to address point 1 above but this also gives read only access to all the other configuration sections which could be rather confusing for the end user. The business view the rules setup more and more as their domain and want the ability to manage the data. A customisation is possible to restrict access to areas of the AdminConsole based on role but it would be great to see this as standard.
Migrating
The configuration choices made when activating rules (from rule templates) are stored in the application’s (“staging”) database. So when you use the normal export/import build configuration tools you will find you don’t have your rules setup in your target environment. I hope Nakisa provide a tool or mechanism within the AdminConsole to extract this configuration and import it to the target environment, so that mistakes do not occur and so that the time consuming process of manually transferring the rules can be addressed.
Application Enhancements
There are a few additional enhancements I’d like to see in OrgAudit. I know many are possible through configuration, but I’m always keen to see more come “out of the box”.
- In the organisation structure views, show the chief position icon (as per OrgChart).
- Org Unit details panel – match the business card on the Manager tab to the design and content found in OrgChart.
- From the Organization Structure, clicking on a position opens the detail panel. I’d like to see actions available to view this position in either the Organization Structure or Position Hierarchy.
- From the Position hierarchy, clicking on the positions opens the details panel. I’d like to see actions available to view this position in the Organization Structure (the ability to view in Position Hierarchy already exists here).
- In the Position Hierarchy views I don’t see any value in displaying the Employee icon and think the use of the position icons as per OrgChart functionality would be more beneficial.
- I would like to see some consistency (where appropriate) of the Position details when accessed via the different hierarchies. For example, matching the Personal tab (when accessed via Position Org Chart) with the Employee tab seen when a position is viewed via the Organization Structure.
- I’d like a way to see Ignored errors. My suggestion would be a separate listing "Ignored Errors" which would be a copy of “All Errors” listing with data filter changed from "status <> 7" to "status =7".
- Currently there is no way to change the status of an error once its status has been set as Ignored. I would like an option to open an error in Ignored status in case it was set to this state by mistake.
- I think all text searches should be case insensitive.
- Each rule has the ability to store a URL to directly link the user to the source of the error for easy correction.
This is shown on the “Error Correction” tab of the Error detail panel.
If a customer chooses to leave this blank in the rule deifnition then I would like to see this tab hidden. Of course you could hide the tab completely in the AdminConsole, but if a particular rule has no URL linked then I think it should be hidden automatically.
Summary
All of the points I’ve raised above, were shared earlier this year with the Nakisa Product Manager for OrgAudit, so hopefully they will be taken into consideration for the future roadmap and we may yet see some of these in upcoming releases.
This concludes my series of blogs on OrgAudit. I think OrgAudit has an important role to play in every SAP HCM on premise organisation. As I said in my first post, I’m yet to meet a customer who didn’t recognise that they had some kind of data problem (big or small). I also see a strong case for using OrgAudit when implementing SAP HCM to help validate any data being migrated into the new system.
I hope you have found this series useful. Please let me know how you have found the series by leaving a comment. Please also jump in with any questions or ideas you may have with regards to anything I’ve covered.
You can find me on Twitter as @BurrStephen.
- SAP Managed Tags:
