Showstopper for Lotus Connections
by Volker Weber
Interesting technote:
Question: What procedure should be followed when an employee leaves an organization where IBM Lotus Connections is implemented?...
Answer: Once a person is entered into the Connections system they should never be removed. Doing so may invalidate the data's consistency. ...
[via twitter.handly]
Comments
This really should not be a showstopper for organizations. When an employee, contractor, consultant (including those named Volker), or other person leaves an organization, their expertise and information should not be destroyed. The individual's ability to login should be disabled, and this can be done through the LDAP directory. While deleting the user from the core user database would not be a "wrong" approach, it is not the only approach which is inherently correct. This is not a binary issue and thus your headline is alarmist.
--Daniel
Raises an important and often overlooked issue. I think it's good practice in any collaboration environment to retain the profiles of all contributors forever, not just to make the database work but because it helps others down the line understand those contributions better. E.g. "Who is this Alan Lepofsky guy that uploaded all these presentations back in 2008?"
This applies to plain vanilla Lotus Notes as well as Connections.
Of course, maintaining those user profiles should be a completely separate matter from the issue of user access, and this may be where the data model needs tweaking. Deleting a user's *account* should not equate to deleting their *profile*. The profile status should just be changed to "alumni" or some such.
I'm wondering though if Germany's tighter privacy regulations will impact how this issue is addressed.
Interesting.
You would want to keep all profiles of former employees, contractors or whomever you once let into your Connections enviroment? What do you do if you sell off a division? Keep all of those in there as well? What happens if you are contractually required to remove their "knowledge"? Or what happens if legal requirements around privacy require a deletion?
There's an issue here in the UK around the Data Protection Act. You simply should not keep personal details longer than is necessary.
The definition of necessary may be a little loose in some areas but...
In the fluffy world of knowledge management this is a non-issue. In the real world of commerce it’s a big issue.
Both Volker and Ben set out why: you can’t simply mandate that all profile data should be maintained. There are a whole host of reasons as to why such data may need to be removed from an instance of Connections. Maybe this isn’t a problem in IBM’s home country, but it most certainly is a consideration in plenty of other territories.
Of course any profile retention policy would need to respect local laws, but that doesn't change the usefulness of having the profile information available as a reference.
As for M&A activity and how it impacts these data systems, consider this just one more issue in a long list of things to negotiate.
Sadly the ideal of retaining all the fruits of collaborative systems often smacks up against politics, particularly when the democratizing effects of these systems undermine a dysfunctional management structure. To paraphrase that old saying: "Hell hath no fury like an incompetent manager scorned."
Consider yourself lucky if you can get past that obstacle to even have the discussion about whether to retain profile information.
Is this really a showstopper?
I have had a few longterm engagements in knowledge management. Judging from the discussions we had around skill profiles it would not have been a showstopper but a killer.
I assume that it would make sense to deal with the issue before you implement Connections in the enterprise. I would hope that the following way might work:
Allow people to create a profile only if they agree that:
- the use Connection is for company reasons only
- the firm would keep their information and connections in Connections after they leave the company because it would be the firms property. (usually you subscribe with your contract anyway that everything that you create will become intellectual property of the firm). As the profile would get "frozen" or set to status alumni, I would hope that it would be dealt with in a similar way as a document that the person has created for the firm - which would be the firm's property.
I would hope that this is a solution for individuals. However, no clue how this would need to be dealt with when it comes to selling parts of the firm including intellectual property.
I wonder in how far this differs from discussions around legal requirements actually retain and archive old communication and information (SOX etc.). I thought delete+erase would often be rather a no-go than wanted. For Connections or other systems dealing with contributions by individuals I would opt for something like "keep their content and contributions but strip down their profile to the bare minimium to assure privacy".
Stephan, that’s a sensible approach for sure, and would probably be acceptable to most individuals, but sadly many territorial data protection rules preclude this (as Ben Rose mentions above for the UK).
I'm not sure what the fuss is all about. It's recommended to keep the user and the data. The capital is in their content and if the user retires, leaves the company, changes jobs, gets fired etc, it is more valuable to keep their knowledge. If you want to delete, go right ahead, the technote just states the obvious that data may be lost. If I own an activity and leave the company, if you choose to delete me and my content, no surprise there will be some data loose in the Activity.
We implemented profiles pages in the latest release. That allows certain groups of profiles with a different page layout. So if someone leaves, add them to the "alumni" group so their profile page automatically reflects that person is no longer with the company and removing any other relevant information you don't want shown.
When they leave, just move their documents to the temp folder.
Ted, if you add somebody to the alumni group, will that remove their profile data, or just not display it?
I certainly hope that after 14 years of internal contribution to IBM/Lotus, my profile, presentations, blog entries, etc. did not go away. I am sure they still provide great value to other employees. My profile had links to projects I worked on, teammates I was linked to, places I stored content, etc. That should not go away just because I no longer work there.
Maybe it has been aliased to Ed Brill.
Wow. I kicked off quite a discussion!
Changing the Profile Type is a good idea for cases where you do have tacit knowledge that you want or need to keep.
This doesn't handle several cases:
1. The person still shows up in the org hierarchy. That means that employees who leave the organization still show up in views like "People Managed". After a reorg, this means a manager can have lots of 'ghosts' that will never leave their list.
2. In our case, many of the users who in the division that is leaving the system do not have any information in their Profile other than the simple info from LDAP. They don't have any knowledge in the system and I have a requirement to remove them.
I propose we need a two part solution:
1. Provide a capability to mark users as 'removed'. This would prevent them from showing up in reporting hierarchies, colleagues, or search results, but keep their records around for showing who authored content, etc. Click through to an 'ex-employee' profile type would be fine as long as they don't show in the current org info.
2. Provide a capability to detect users with no additional information such as blogs or posts, and fully delete them.
If you add someone to the alumni group or what ever you want to call it, you can setup what you want to display. While the profile data may still be there for admin purposes, users will only see what attributes have been identified for that group. You can remove the data as well.
For example, when Alan moved on :-(, the profile data can still exist, however viewing his profile could return only basic information specified by the admin like:
Name
Job Title
Organization
Last Manager
His Links
Everything else in his profile is hidden due to the his account being listed as alumni page type.
It's as always many intrests colliding. The privacy/data protection, the knowledge management, the data consistency, the obligation to hold the data available for an amount of time, etc.pp.
There is no perfect solution - maybe there should be a a choice how to adress this. In principle it shouldn't be a problem to give the customer the choice between deleting (at least personal) data (that's possible without destroying the database itself) and keeping the data.
The "alias" comment got me thinking...
Something else that would be nice to see on the alumni profile is a list of employees who either specifically replaced the departed individual or have otherwise assumed some of their responsibilities (e.g. clients). If any of those folks have also left, you might have to keep clicking through to find a current employee, but you wouldn't have to go back and re-edit the alumni profiles to make it work.
This reminds me of one of the things that I hate the most about Notes (although I like it in general...!). Why isn't there a difference between an account and the (private) data linked to an account?
Why does Windows have it (SID) and in Notes, AdminP needs to physically maintain names in various places?! Sure, we know groups, but there are workflows, document owners, notification settings etc.
If a proper structure would be used and the account data is a holy cow in Connections, then keep it for god's sake, but remove the private data linked to it.
BTW, and slightly OT, what does "keeping longer than necessary" mean in terms of tape retentions?. This will impose an interesting challenge if part of the backups should be removed.
Under Health & Safety legislation in many parts of the world there is a requirement to maintain certain employee information for several years or in some cases indefinetly when an employee leaves an organization.
For example if an employee is injured and an incident is subject to an ongoing workers compensation claim to provide ongoing treatment for an injury or illness acquired while working, the information about the employee and the incident must be retained for the lifetime of the ongoing treatment, even if the person is no longer working as an empoyee for an organization. Also, when assessing a new workers compensation claim, there is a requirement to determin if there is a pre-existing injury or not.
As some others have mentioned in their comments, changing the status of a person from employee to alumni is a common way to handle this situation.
There are different (and often conflicting) business rules, legislation and common law privacy expectations covering the retention and access to peoples records for directory services, payroll and personnel records, health & safety records etc. But is this a showstopper, I think not.
But I guess this highlights yet another difference between "public" and "corporate" social software systems.
I need to add one thing. In most environments Connections Profiles will not be the data owner for the critical information. Basic user data would come from the LDAP, management hierarchy from LDAP or HR systems and so on. So when a person leaves the company, the information should already be updated in the source systems and replicated to the profile. I'd expect the management relationship to fade away really quickly.
The profiles application should only be data owner for that tacit knowledge, a company wants - reasonably - to retain. Connections profiles is not a new HR system but an dynamic aggregation point for user data from different sources. So when the data changes in a source application, this should be reflected in the profile. Lotus Connections uses a limited use license of Tivoli Directory Integrator to achieve this.
This will not resolve all problems, but many of these problems are already there before Connections is deployed.
For those finding this thread via search, I wanted to add a link to a new and relevant OpenNTF project called "Suspend Person(s)":
http://www.openntf.org/Projects/pmt.nsf/ProjectLookup/Suspend%20Person(s)
From the description:
"We had an internal an issue of wanting to suspend people without deleting them so that they can be restored without issue when they return. Examples would be for maternity leave, extended sick leave, sabbaticals, etc.
I created an Absence NAB to store suspended person documents in. The agents all work in tandem, suspending, restoring, and deleting the accounts. Group membership is preserved, but ACLs are not. Aged accounts are deleted after ( default ) of 13 months."
