>
> Within the industry today there are many ways of transferring the
> information from one vendor to another.


While "the industry" may have ways of accomplishing this physically, the
assets DO NOT BELONG to either the former or current service provider and it
makes no sense to transfer custody of them irrespective of what business
transactions take place without full notification to and involvement of the
owning organization.


In many instances there is a lot of animosity on the part of the vendor
> who loses the account, and in some cases on the part of the departing
> customer.


This is one of the reasons for a full accounting, but there should be no
personal issues taking place here, it's a business thing, right?  You have a
contract or agreement, it comes to an end, or changes... period.  If there
is any animosity, [ill will or resentment tending toward active hostility *:
* an antagonistic attitude] that's a personal and non-business related
'situation'.


On the data side I would like to put together a protocol that addresses
> the transition from one vendor to another (a churn protocol).


Again I'll state that it's not the vendors place to determine how to
transition ownership of these assets from one party to another.  The assets
belong to the customer and they're entitled to a ful accounting of their
assets prior to, and following, any change of physical custody.  And if
assets are identified as missing, they should be addressed by the
responsible party at the time.  The client STILL has a contract in-force
with the provider who has physical custody, even if they sell out to another
firm and it's their responsibility to address this prior to transfer.


Unfortunately there does not appear to be much interest on the part of the
> industry to address this issue.



That may be directly related to how the industry views the contractual
obligation for managing the assets they are entrusted with.


The anwers on this list to the questions I have asked are much in line
> with the way I view how things should be done.
>
> The answers from the industry have been considerably different.



I think this is directly proportionate to the level of responsibility one
has for the assets in question.  The client has an obligation, usually under
law, to ensure the information is retained for specified periods of time and
can be made available as required by a regulating agency or other governing
body.  They make a conscious decision to entrust the storage of these
infrequently accessed, but required to be retained for compliance purposes,
information assets to a third-party.  They perform some base analysis of the
ability of a firm to adequately manage, store, and protect these assets and
enter into a contractual obligation for services with them. Until they elect
to discontinue this paid arrangement, the expectation is that the third
party will provide the level of service agreed to in the contract.  Is that
unreasonable?



> So my question to you all as a group is:
>
> If there was a well designed churn protocol for information management.
> Would customers view a vendor more favourably if they agreed in a contract
> to follow this protocol?
>
> Would people consider writing this protocol into RFPs?



I think you will receive a resounding NO from this audience.  I can't think
of too many instances where anyone would find churning agreeable, especially
when you look back at what happened to Prudential in the late 1990s for
their practices of churning without informing clients what was taking
place.

http://www.insurancejournal.com/news/national/2000/08/04/11270.htm

Granted, this was insurance investment and people's livelihood we're talking
about, but in many cases these information assets are the life blood of an
organization, and they want their management protected.

Larry
-- 
Larry Medina
Danville, CA
RIM Professional since 1972

List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance
To unsubscribe from this list, click the below link. If not already present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of the message.
mailto:[log in to unmask]