Leavers and joiners policy ideas?

[Former Member]

Hi,

I'm looking for slick ideas around managing a leavers and joiners policy so that if John Smith leaves I can replace him across all Projects, Contracts and RFx with Fred Bloggs. The key here is ensuring the audits remain in place so that we can track who actually makes the changes.

I've tried several tests but can't find a way that updates all records with the new details. Maybe I'm missing something.

The only other route is to export all records, replace the Owner or collaborator names and reload. But this is quite a task once a week for 1000 active users.

Ideas, solutions appreciated.

J

[Former Member · Accepted solution]

Hi Jethro - Following up on my previous reply, below is the script I developed for my prototype.

Regards,

Rob

// This script will update the owner of the business document
// where the current owner is the "from owner"
import com.sap.eso.api.projects.*;

fromOwner = doc.getExtensionField("FROM_USER").get();
toOwner = doc.getExtensionField("TO_USER").get();

// Find the projects for the from owner
projHome = IBeanHomeLocator.lookup(session, ProjectIBeanHomeIfc.sHOME_NAME);
projList = projHome.findWhere("DOC_OWNER_USER_OBJECT_ID = " + fromOwner.getObjectId().toString());

// Get the audit messages collection
auditMsgs = doc.getExtensionCollection("AUDIT_MSGS");

// Indicate how many projects were found
auditMsg = auditMsgs.create();
auditMsg.set("AUDIT_MSG", "Found " + projList.size() + " projects to update");
auditMsgs.add(auditMsg);

// Iterate over the projects and change the owner
if (projList != null)
{
    iter = projList.iterator();
    while (iter.hasNext())
    {
        // Work with the bean now
        projBean = iter.next();
        projHome.upgradeToEdit(projBean);

        // Now change the owner
        projBean.setDocumentOwnerUserReference(toOwner);

        // Finally, save
        projHome.save(projBean);

        // Add an audit message
        auditMsg = auditMsgs.create();
        auditMsg.set("AUDIT_MSG", "Updated project " + projBean.getDocumentId());
        auditMsgs.add(auditMsg);
    }
}

// Add logic below for additional object types (e.g., RFx, Auction, Master Agreements).

[Former Member · Accepted solution]

This is a very nice concept for people who are leaving the firm.

What about approvers / groups that are going on holiday and need to be replaced by someone else? We often have people who are leaving on holiday. There is no standard way of setting delegations so that your backup needs to approve / reject a project in your place. Anyone ever tried to implement something for that?

[Former Member · Accepted solution]

Excellent thanks Rob.

[Former Member · Accepted solution]

I'm hopeful that this will make it into the SAP development pipeline as also a request I've come across several times. In reality this ends up being handled by a request to a local or central admin team to unlock the workflow and reassign another approver.

If you're talking projects then the common issue to date is that the whole of a Project record is locked once submitted for approval.

These two issues I see being handled through Change Management, Training and Support models (with agreed and clearly defined SLAs).

Regards

Jethro

[Former Member · Accepted solution]

Hi Brian -

With respect to workflow, a solution that has been used in the past is to include an extension on the user account object that represents the substitute (the extension is of type user account object reference). When a user leaves on vacation, they are obliged to set their substitute.

The workflow beanshell scripting would check if there is a substitute before adding a user as an approver. That is, if Rob is identified as the approver in the beanshell scripting, the scripting would check to see if Rob has a sustitute and add that person instead as the approver.

This solution only addresses workflow process started after the substitute has been set in the system. Any in process workflows cannot be altered.

I hope this helps.

Rob

[Former Member · Accepted solution]

Hi Rob,

thanks. That's something I haven't thought of but it sounds like a great solution. It is indeed to bad that it will only affact the new workflows and not the existing ones but still...

[Former Member]

Hi Jethro -

As you have indicated in your post, the out-of-the-box solution provided with E-Sourcing requires use of import files to change the ownership of business documents. This works, but can be labor intensive for frequent changes. As a result, I investigated using the extensibility features of E-Sourcing to provide an easier to use option. I will explain in this reply the basic approach and provide some of the script definition beanshell code I used in a prototype that I prepared.

The concept that I used for my prototype involves the configuration of a "owner change" object which has fields for the "from user", the "to user", and an audit trail. When it is time to handle a "leaver", a new owner change object would be created which identifies the from/to users and an action is taken to change any Projects, RFx, Auctions, or Master Agreements to have the "to user" as the owner wherever the "from user" is currently the owner. In addition, I included a short audit log in the owner change object that lists all of the objects that were changed. In addition to the audit log provided by the owner change object, a "change history" record is created with the business document update. That message appears as:

This document's owner changed to: Robert Stevenson

For my prototype, I utilized the User Defined MasterData 1 object, added extensions to it for the from/to users, and configured the user interface using page customizations. I included the beanshell script as a toolbar action on the object.

Upon completion of the prototype, I did think of an additional enhancement where the owner change object would also include checkboxes to indicate which objects should be updated (projects, rfx, auction, and contracts).

I think the approach outlined is a good one in that the process is controlled by a single object accessed from setup and the details are logged for audit purposes. The use of extension definitions and scripting is not extensive due to the convenient IAPIs provided with E-Sourcing.

NOTE: Due to issues with large posts in the SDN, I will post the sample code in the next reply.

I hope this reply is useful.

Regards,

Rob