Enterprise Resource Planning Blogs by Members
Gain new perspectives and knowledge about enterprise resource planning in blog posts from community members. Share your own comments and ERP insights today!
Showing results for 
Search instead for 
Did you mean: 
Active Contributor
This blog is the 4th in a series looking at OrgAudit (aka DataQualityConsole), 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; the second looked at building the business case and the third part looked at the  standard functionality.  Now let’s look at some of the technical aspects of implementing OrgAudit.
For the purposes of this blog I refer to OrgAudit 4.0 build 0901005700, which is the build released onto SMP by SAP in November 2012.  For details on how to download the installation package please refer to the video guide available on YouTube.  Within the download package you will find the applications, SAP components and documentation.  If you are starting your implementation, I would always recommend using the latest available build version (as of 23rd April, 4.0 SP1 is available on SMP).  If you are a Nakisa Partner then refer to the Partner Portal, otherwise simply request the latest build via OSS using application area XX-PART-NKS-VSN and specifying the OrgAudit application.


OrgAudit can only be implemented in the “Staged” approach; this means that the data structures used by the OrgAudit application are held in an intermediate database.  The database is populated in a five stage process.
  1. Base data is extracted from SAP to allow the visualisation of the organisational structure.
  2. The base data is transformed into the data structures required by OrgAudit to carry out the visualisation.
  3. Base data for the auditing process is extracted from SAP
  4. The base audit data is transformed into the data structures required by OrgAudit to carry out the HCM data audit.
  5. The data is audited based on the rules configured in OrgAudit.
The error information (current and historical) is also stored in the application database.

Installation Pre-Requisites


SAP ERP 4.7 ext. 220 onwards is supported for OrgAudit.  The SAP component pre-requisites are detailed in the “VSN40_Environment_Checklist.docx” included with the documentation in the SMP package.
The Nakisa Add On and Transport package are required for OrgAudit (as per all SOVN/STVN applications), but they are the same for all applications.  So if you are using a 4.0 SOVN/STVN application already, then no additional install is required.  The 4.0 Add-On passwords can be found in OSS note 1748016.

Application Server

Consult the compatibility matrix and master guide documentation to confirm your environment meets the hardware and software specifications.

For 4.0 the supported application servers are NetWeaver CE 7.2 (EhP0 SP1-SP05) or NetWeaver 7.3 – see PAM for information on supported operating systems for your chosen NetWeaver version.  For sizing, I recommend referring to the Capacity Planning Guide PDF (documentation can be found on SMP, under Release & Upgrade Info -> Installations & Upgrade Guides -> SAP Solution Extensions -> SAP Talent / Org Visualization by Nakisa -> Release 4.0).


A database is required to hold extracted & processed data, rules configuration and errors.  The compatibility matrix for 4.0 lists the supported databases as Oracle (10g/11g), SQL Server (2005/2008/2012) and DB2 (9.1/9.5/9.7/9.8).

As you may recall, the database holds extracted data for visualising the org structure as well as both the current and historical audit data.  Since this historical data is cannot be re-generated, I’d recommend backing up the database periodically to avoid losing this data in the event of a significant problem with the database.


A SOVN Org Planning licence is required to use OrgAudit.  If you have already purchased the licence, then you can obtain your licence key (also known as the “serial” file) by raising a message on SMP under application area XX-PART-NKS-LKY. If necessary, you can refer OSS note 1257386for detailed guidance on how to raise this message.

Initial setup

You can follow the steps in the “How to setup SOVN OrgAudit application” blog post in order to work produce a very basic setup of the OrgAudit application.

Extraction Steps

OrgAudit contains more extraction steps where data is retrieved from SAP (in two separate steps) and manipulated (again in two separate steps) before being audited.  For the initial population, the quickest and easiest approach is to use the job running options available in Admin Console.  I always do this for the first run to ensure each step completes successfully and to obtain some timings.

So, what are all these steps running? And how long do they take?

I have an inquisitive mind for technology so I wanted to understand each step and which configuration files were used.  Also to give you some indication, I’ve estimated the approximate timings for each of the staging steps based on my experience.
SectionApprox. TimingsXMLFile
Staged - Extraction

~40 mins

per 10,000 employees


Staged – Join

~1 minSAPExtractor\extractorSchema\joinConfiguration.xml

Audit - Extraction

~60 mins

per 10,000 employees




Audit – Join

~1 minSAPErrorsExtractor\downloadErrorsSchema\joinConfiguration.xml

Audit – Run Audit

~5 min

per 10,000 employees


Audit – Save Audit

Between 1 min and 1 hour

depending on the number

of errors to save




So, depending on your company size and number of rules configured overall expect to take 1-2hrs per 10,000 employees (or 6-12mins per1,000 employees).

When using the AdminConsole, at the end of the “Audit – Run Audit” step, you will see a pop up where you can preview the audit (this step does not happen in the automated scheduled extractions). Previewing produces a PDF document which you can save if required:

Scheduling Extractions

As with OrgChart, a script is supplied for running extractions and the instructions are in the Admin guide.  To be honest, the first time I was involved in setting this up I found it very confusing.  My colleague, millard.stephen took it upon himself to dig deeper into it and wrote a wrapper script that makes it a lot easier to use.  He provided his feedback to Nakisa also so hopefully it will be easier to use in future versions because using our own scripts means they can be dropped into a customer’s build and with no further configuration they can automate the script, log activity and receive a return code of success/failure.


Configuring Rules

I can’t stress enough how important it is to go through each rule, one by one, and discuss with the business.  Ask questions like:
  • Does the rule apply?
  • Are the prerequisites for the rule met?
  • Does it apply to all employees equally (or does the filter need amending)?
  • If applicable, are the keywords set appropriately?
  • What impact does failing the rule cause, and hence what severity should be assigned to that rule failure?
Rather than weight each rule individually, I’ve found that clients typically opt to group them by component (PA/OM/CM) and severity (low, medium, high, critical) and then apply the same weighting for each combination of type and severity. E.g. all critical PA errors get 10% weighting.

Rules – How they are stored

The standard set of rule templates (from which the rules are generated) are populated into a database table (“RULES”) during initial setup from an XML file (..\SAPErrorsExtractor\rulesSchema\ruleAttributesConfiguration.xml).

Once configured, the rules themselves are also stored in the same database table (“RULES”).  If you take a look using an SQL client, you will notice the database column “TEMPLATE” is used to distinguish an entry as either a rule or a rule template.

There are 48 rule templates delivered as standard in OrgAudit 4.0.
HR AreaRule Purpose# Rule Templates
PAPersonnel AdministrationRules based around employee records14
OMOrg ManagementRules examining the integrity of the org structure33
CMCompensation ManagementRule checking if employee is in the compensation program1
Whilst it is easy to enable rules during setup, I don’t think any client will want to use all rules as they stand.  This means you have to enable them one by one, configuring each one to your own requirements (weighting, etc.) as you go.  Remember each group (OM, PA, CM) needs to add up to 100% if any rules from that group are used.

In the “RULES” table there are some additional columns which are useful to be aware of:
DB ColumnDescription
TEMPLATE0=Rule, 1=Rule Template
CATEGORYID0=OU, 1=Position, 2=Employee (see resources bundle “object_text”)

0=Critical, 1=High, 2=Medium, 3=Low (see resources bundle “Error_Priority”).

Note: Severity is set in the definition of the rule and if an object fails the rule, the error severity is set and can’t be changed from within OrgAudit.

TABLENAMEContains the database object name that the rule will use to determine if there are any errors.

As I said earlier, always use the latest available build as I know the initial SMP release contained known issues including ones affecting rule templates 3, 4, 5, 13, 22, 30 and 44 which have all been resolved by mid-April 2013.

Finally, and somewhat frustratingly, there is no tool currently available within OrgAudit, to allow you to transfer your rules configuration between environments.

Error Statuses

Each error that is recorded is stored with a status. Over time, either the end user or an automated action in the OrgAudit application itself can change the current status of an error.
Error statuses are held in a resource bundle (..\AppResources\resourcebundleconfiguration\error_status.xml) and the following statuses are available:

Status TextStatus CodeExplanation
Open0Any errors detected by the application during an audit run, or any closed or auto-closed errors manually set back to "open" in the application.
In progress1

Any errors that are currently being corrected.

This status is set manually in the application.


Any errors whose status was changed to "closed" in the application.

This status is set manually in the application, and indicates that the error has been corrected in the SAP system.


Any errors whose status was changed to "closed" in a previous audit run, but were not corrected in the SAP system before the current audit run.

This status is automatically set by the application.


Any errors whose status was not changed to "closed" in a previous audit run, but were corrected in the SAP system before the current audit run.

This status is automatically set by the application.


Any errors that you do not wish to be automatically set to auto-closed or auto-opened in subsequent audit runs.

Note that ignored errors are not displayed in the All Errors listing.

This status is set manually in the application.

The ability to change a rule’s current status is dependent on the rule’s current error status.  The following flow diagram explains.


A quick re-cap on scoring can be found in this video:

In 4.0, the score bands and group weightings cannot be configured via the AdminConsole.  If you wish to customise them you should look at the template called “Templates_Sherlock\dqc_generic_analytics_formula.xsl”.  For group weightings, search for “OM_ScorePercentage” to find the relevant areas to change.  For score bands, search for the “setColorCodeStyleAttr” to find the xsl:template to amend.


This ends my blog on the technical aspects of OrgAudit.  OrgAudit is more complex than OrgChart to implement and I recommend using a skilled resource with experience of at least SOVN, but ideally OrgAudit.  Nakisa provides partner training as either full 4.0 courses or 4.0 delta training (for those partner consultants who have previously completed 3.0 training).  For more details on training courses I’d recommend reviewing the list of available courses on Nakisa’s website and perhaps reading my “Diary of 4.0 Delta Training” for further insight.

In my next blog, I’ll get a little bit more personal and discuss my wishes for the future of OrgAudit.

Labels in this area