Tips for Go-live (Nakisa OrgChart SP2)

[Former Member]

Hello All,

I would like to anticipate at all the activities of the go-live in order to prevent any miss. Is the first time that we implement Nakisa, so, for create an activity planning, we want to know some important tips e.g.:

1.- Transport Add-On and transport package

2.- Export the build from DEV system

3.- Import the build into de PRD system

....

Users, conections, role assignment, and so on..

All the tips you can provide me, I'll appreciate it.

Thanks and best regards

[lukemarson · Accepted solution]

Hi Emilio,

Your steps above are correct. Since all your environments should be the same then the only additional actions required should be:

1. Change your authentication source & role mapping (unless anonymous)
2. Change your connection string (SAP or database)
3. Change your root OrgUnit ID
4. Change your root Position ID (only if using Position Hierarchy)
5. Change your database for user preferences (only if using database for user preferences)

Should you have different user roles then you will also need to change these in your target Nakisa instance.

I also recommend you check this blog: http://scn.sap.com/community/erp/hcm/talent-visualization-by-nakisa/blog/2012/05/21/how-to-set-up-so...

Best regards,

Luke

[Former Member · Accepted solution]

Hi Luke

Thanks for your reply

Best Regards

[StephenMillard]

• Just to expand on one of Luke's points, you may need to change the root OrgUnit ID in two places.  One is the hierarchy, and the other is for the extract job if you are using a database to hold data for displaying an OrgChart and/or analytics.
• You might want to amend the comment against the build when you load it into production to something more meaningful.
• If you are running extract/join/analytics, you'll probably want to look at setting up a scheduled job to run it.
• This probably goes without saying, but when you amend your data connections, give them a test to make sure you can connect to the requisite systems (SAP/Database).
• If you're using SSO and had to implement verify.pse / sapsecu.dll / sapssoext.dll, don't forget to do this on the production server as well.
• Secure your admin console by changing the password.
• A bit of a no-brainer, but publish the build - i.e. the right build
• Make sure your users know where to go for help or training on how to access and use the system.
• Make sure your documentation is up to date - especially any hand over documentation for the help desk, BASIS, etc.
• Finally and probably most obviously give it a good commission test (you and expert users if possible) with different IDs to validate the functionality and access is correct for the users before announcing it is available for use.

[lukemarson]

If you're using SSO and had to implement verify.pse / sapsecu.dll / sapssoext.dll, don't forget to do this on the production server as well

FYI - This isn't relevant from SP2.

[StephenMillard]

FYI - This isn't relevant from SP2.

Isn't it from SP3 onwards that this isn't relevant rather than from SP2?  The admin guide for SP2 (p29) certainly references these files as being required.

[lukemarson]

They are referenced but not needed. Insider tip

[Former Member]

Hi Stephen

Very important the things you has mentioned..

Thanks and best regards