The ECM Platform versus Department Needs pitch

So you are all set with your talk track to your next potential client, you have your ECM slides ready to go, some product roadmap details, email archiving configuration details, maybe even some data growth slides to scare them into needing to do something sooner rather than later.

Good to go! Or so you think…but who is your audience?

Great if your audience is the IT department but as budgets become more constrained in companies it is the business who are approving spending. So how do we communicate the right message to a business audience. Many times in the past I have had to present to both an IT and a Business audience which may be made up of Procurement, Finance, Legal and other departments. It is difficult to keep all departments interested during a pitch and certainly our previous slide deck won’t win anyone over other than some technical questions from IT.

Below is a typical slide (unsure of source) showing how we the various components of an ECM platform can come together to address the various business units needs. Again something IT may get excited about but to Joe our Finance Manager and Brendan in Procurement this doesn’t exactly answer their questions or help them with their goals.

So back to understanding out audience. What are the pain points and challenges that various department heads face today or even better what are the ‘hot buttons’ for the C-Levels as ECM platforms aren’t cheap and signing off $100,000’s isn’t a business decision that is taken lightly. Let’s think about who may be at our meeting and the challenges their department faces:

Procurement:

– Contract negotiation is headache with multiple versions of contracts being emailed and red-lined

– Wouldn’t it be nice to know the existing contracts that are up for renewal in the next 60 days so negotiations can start early and avoid the last minute rush

 Engineering:

– Manual retrieval of drawings takes too long

– Can’t find the latest product specifications

 Legal/Audit:

– Legal holds are killing us – more resource and money spent trying to find and produce the right data – if we can find it!

– All this data needs to be kept – where to store it? Keeping backups after backups

Membership Services:

– Escalating overtime costs as of our application backlog

– Enrollment process cycle times are too long

Customer Service:

– Wait times are too long and we are losing customers

– We are unable to find the latest update information – our members get frustrated as we need them to resubmit information

Finance Manager:

– AP department may be missing discounts on early payments

– Even worse maybe the company is late on their payments hence incurring penalties

…and so on, and so on.

To summarize, know your audience and keep it simple and relevant to them. Split the time during a presentation equally between the various departments, representatives that attend. Think more about the department or the vertical being addressed and how that sits on top of the ECM platforms as opposed selling ECM.

 

 

ICC Lists: Importing existing lists

It can be time consuming in IBM Configuration Manager to add value after value to a list. The great news is that there is an easy way to import your lists from system CSV exports or spreadsheets. All we need to do is generate an XML file similar to the following format for all the values and hey presto Bob’s your Uncle!

<valueList>

<value sortIndex=”3″>

<!–[CDATA[value3]]>

<!–[CDATA[This is the third item in the list.]]>

<!–[CDATA[3]]>

</value>

<value sortIndex=”1″>

<!–[CDATA[value0]]>

<!–[CDATA[This is the first item in the list.]]>

<!–[CDATA[0]]>

</value>

<value sortIndex=”2″>

<!–[CDATA[value2]]>

<!–[CDATA[This is the second item in the list.]]>

<!–[CDATA[2]]>

</value>

</valueList>

More details can be found in the IBM Content Collector v3 Infocenter

Below is a short video to demonstrate the steps required.

Harmonizing the Big Bucket Approach.

It has always been the challenge for Records Managers to create records policies that have the right balance. Too few record types leads to a loose model with a high risk of information not being classified correctly and not being found in the future or worse still getting destroyed before it should be. On the other end of the scale, records policies that are too complicated, with too many record types defined become complicated for the end user but also a nightmare to maintain.

The trick is getting the balance between too few and too many records types. I appreciate there is more to it than that but one approach that works in some circumstances within various ECM systems is not too go overboard on the Document Types/Classes. Too many Document Classes can lead to a headache when administering so apply the big bucket approach.

Eg, Banking

Typical Approach	Simplified
Document Classes: Loan Application Loan Review Loan Risk Document Loan Investigation Loan Approval Loan Policy Loan Acceptance Letter Loan Statement Loan Notes Mortgage Application Mortgage Review Mortgage Risk Document Mortgage Approval Mortgage Policy Mortgage Guarantors Mortgage Acceptance Letter Mortgage Yearly Statement Mortgage Notes	Documents Classes: Loan Document Mortgage Document Document Categories: (ChoiceList) Application Review Risk Document Investigation Approval Policy Acceptance Letter Statement Notes Guarantors Yearly Statement

As I mentioned this doesn’t suit all use cases but hopefully the concept gives some ideas for those challenging Records Management, Document Classification, Records Policies and Categorization projects. The big time saver in this approach is only having to maintain a Choice List/Field Lookup rather than creating separate docclasses for each document type but you also need to pay attention to your fields/properties as they need to be set at the document class level and be applicable to all your categories.

When migrating clients from shared drives to ECM/DMS systems it is always easy to apply the above approach but more challenging if they already have a electronic repository. Generally, those with existing repositories that have grown over time you can find lots of opportunity to standardize their records policy although this is difficult to do in an existing system. Hopefully, they have a migration on the cards in the future 😉

Making the switch from navigating to searching with help from ICC and Regex.

Many companies are still making that transition from shared drives (who has never had a S:\ or H:\drive!?!?!?) to Document Management System (DMS) or full blown Enterprise Content Management (ECM) systems. There are many reasons for making the switch from overloaded hardware to new business demands but a key point in many of these systems is how the end user uses the system.

Lots of shared network drives are a prime example of content chaos with no naming or folder standardization and users left to create their own folders. However, some more well thought out network shares have a semi-structured foldering system with maybe  a base template of a folder structured which is copied and pasted for new projects, claims, matters or applications.

 

Whatever the structure or lack of it on a shared file system it is generally a case of users having to browse for the content they are after. What happens if you can’t find that vital document you worked on 3 months ago? You always have the option to search but then you are presented with the dozens if not hundreds of hits the full text search brings back. I think of this type of use case as discovery – users are having to discover what they are looking for rather than being able to pinpoint it straight away. More on this topic here at a previous post: Difference between search and discovery.

With this in mind it is important for our end users to realize that any migration to a new DMS or ECM system demands a different way of working – hopefully a smarter and more efficient way of working. Although, sometimes DMS or ECM system are implemented badly and mimic the folder browsing approach which seems crazy in today’s world with the content explosion. Saying that I am sure there are cases for the old style folder browsing such as case management solutions that have adhoc document collections.

We have established the source system disadvantages, the benefits are new target system will bring and determined that we have a semi-structured foldering system which could be used to place some categorization and property values to our content in the new system. Up steps IBM Content Collector (ICC)!

I am no expert with ICC but I love it’s module design and flexibility it provides for ingesting content from a variety of sources to a repository. You don’t need to be a programming genius to achieve some great results but how do we determine index information based on folder names in document file paths? In short we are looking for patterns in a string and what better way that using Regular Expressions….groan I hear you sigh! I was never a fan of Regular Expressions mainly because it looked like hieroglyphics however after spending sometime on a number of projects and getting into the weeds I have changed my mind and realize how powerful they can be. Saying that I will likely forget everything I have learnt in a couple of months.

Below is a screenshot of how to build Regular Expressions into your ICC Task Route. I haven’t detailed the Regular Expressions used as that is a topic all on its own but will post again on typical expressions and how they can be combined with ICC Lists to provide some powerful lookups.

What HASH do you prefer?

De-duplication of files is a common function of ECM systems but how does it work?

You can have two files that have exactly the same content but potentially different file names yet systems are able to determine that these are duplicates and to act appropriately. In many cases we don’t want the same content duplicated as it doesn’t lend to effective storage management. In the email world we can even utilize the compound model which splits the email from the file attachment and de-duplication can happen at both levels – on the email and on the file.

The technique used to make these comparisons is known as cryptographic hash algorithms or ‘hashing’. There are two main types of hash algorithmic:

1. MD5 – has been available for many years and hence is wide spread in the industry today. It is frequently used for checking data’s integrity similar to our de-duplication discussion. The one flaw that MD5 has in today’s world is that it isn’t as secure (128 bit) as the more recent standards due to a flaw being discovered in the algorithm.

2. SHA – SHA1 was the original hash function design by the National Security Agency which was more secure (160 bit) than MD5. It was consequently updated to create SHA2 and more recently SHA3.

The general guideline when it comes to hash keys is to use SHA2 since it is the most secure. This does apply to security focused use cases such as saving a password but the reality for many systems focusing on de-duplication is to use the original MD5 hash algorithm.

How to sell Social Software.

Social Software, Social Platforms, Social ECM, Social Connections ….call it what you will, it is certainly a growing market and many companies are ‘dipping their toe in the water’ to help enhance collaboration or simply introduce collaboration in their organization.

Why you need Social Software – the pain points:

There are various benefits to transitioning to a social platform other than just having the latest and greatest Web 2.0 software with all the bells and whistles.

1.  How do organisations attract the best young talent today?

Those upcoming stars that are fresh out of university want to work at organizations that are leading edge and tech savvy. Even today’s teens are more computer savvy than their previous generations. They are pushing collaboration to the next level – chatting with 3 or more friends at a time in real time on their instant messenger or multiple instant messengers. They are permanently connected with their smart phones to family, friends and colleagues. They blog, they updates wiki’s with ideas and coursework from their university tutors. Practically, all teens have facebook, twitter, pinineterest and foursquare accounts to post miniblogs, arrange events, share pictures, locations and much, much more.

So what happens when these tech savvy teens joining the leading Corporates of today and discover they go back a step in time with thick applications, out of date email systems, no instant messaging or not being able to find work colleagues or documents due to the silos of information.

2. Tacit Knowledge.

Those employees that have been the longest in the organization are also likely to have the most knowledge about your services, products, partners and the organization itself. All this tacit knowledge is in jeopardy of disappearing overnight as these long-term employees decide to retire or even worse move onto another organization.

3. Remote offices.

Organizations with multiple remote sites particularly large national or international organizations struggle with the connectivity of employees at these sites working in the same knowledge domains. Proposals, case studies, initiatives and projects are regularly duplicated across offices without any knowledge that the other remote offices or departments have the same goals or could learn from the other offices and employees experiences. Imagine the very person to help you design your Hierarchical Storage Management (HSM) system is sitting in an office on the other side of the world already prototyping a solution. The lack of insight and visibility into what is happening across the ENTIRE company and being able to tap in to those skills and expertise of others leads to duplication of effort hence wasting time and efforts.

4. Email as Document Management.

Email as your document management and daily collaboration tool causes a number of issues and this is not uncommon in many organizations. Overloaded inboxes, duplication of content, sharing, versioning and discovery issues. Email is definitely a key communication tool in organisations today but the ability to socialize a document or presentation with peers and identify key individuals to input effectively requires a different approach. Sharing your work, documents, findings to the wider organization allowing them to be discovered from keyword searching as well following up with key people who collaborated on the project just isn’t possible with an email culture.

The Leap:

So we know the pain and we can see we need a smarter way of working across the domain silos, remote offices, various age ranges of employees and to get away from emailing everything. The question is are organisations and its employees ready to change their day to day communication mind set and start to work differently. It isn’t just a matter of implementing the latest and greatest Web 2.0 technology; it is also about having the right mindset and commitment to use the new tools. Today you email people you know, tomorrow you create a new community to post your document and invite those who can help.

Sounds easy but it isn’t. The biggest challenge in implementing social software is getting users to change their mindset of collaboration.

Targeted Approaches:

Social software isn’t as much in need in small organizations or those organization that are hub-centric (ie: working out of one main office). However, large organizations especially multinationals that have many remote offices are sure to have a number of firm-wide initiatives, national projects, department or domain focused programs that require collaboration from employees across different sites. A key indicator are documents being heavily emailed around various offices due to no shared file locations across sites maybe due to network routing, security or connectivity limitations.

If you are able to identify three key initiatives that match the foregoing criteria then you have your pilot project. Notice I say pilot, as you are destined to fail if you build out a large scale deployment and expect the users to start using it overnight. Begin small, prove how socializing content works on these smaller firm-wide projects. Once you have a success story then you can begin to sell the benefits to other areas – pick your departments and users wisely to help grow your social platform into your organization. Also you need to start with a pilot not a Proof Of Concept, POC as your early adopters won’t want to upload content if it is going to wiped and rebuilt or replaced in the near future. A pilot will be extended into a full fledged system so no content is lost.

Another tip to ensure your identified social projects have a successful pilot is to include fresh, young users into the initiative. New employees that are young and internet savvy will find it easy to use the new platform and apart from being enthusiastic and willing they can also act as sponge to soak up that tacit knowledge from older employees that may not be so convinced about socializing content.

Big ECM Challenges

There are many areas to consider with a large scale enterprise deployment of an ECM repository. Some of the main areas include:

• Performance
• High Availability
• Indexing
• Backup & restore
• Disaster Recovery

In today’s world, the content explosion has meant that many companies now struggle to manage the systems, databases, file systems and applications. Environments that were architected and built several years ago met the current needs at that time but today are struggling for resources and capacity. Architects, Service Managers or Application Owners now find themselves with the difficult decision whether to upgrade, migrate or implement a tactical solution to keep services running while keeping another eye on the big picture and strategy. It can even be a case of waiting for the business to determine their priorities and budgets for the year(s) ahead.

Performance:
One area that I have seen this repeatedly in the FileNet/CM8 world are large FileNet Object Stores or CM8 ItemTypes. Rarely there is thought given to the long-term future of these when they are initially created. Some organisations perform periodic capacity planning and can often determine when things are going to get nasty well in advance.

Since database storage is only recommended for objects smaller than 10KB and smaller quantities we can turn our attention to file storage areas. Best practices state that you shouldn’t have more than 5000 objects per file system directory and on creating a new file store object store in FileNet there are 2 options: Small and Large. In essence there difference between these is the number of folder levels created when completing the wizard interface. Small object stores create 3 levels of folders and hence tailored for less objects in comparison to large object stores with 5 levels supporting over 60 millions documents.

So how to do we tune our object stores to for optimum performance. Knowing what we have just learnt there is the ability to divide our content into a number of object stores based on the number of objects. Using storage policies we can even roll over object store use based on the number of documents added or on date ranges. With the correct capacity planning in place then physical and logical splits on ECM repositories can be planned. It is commonly a case that organizations will split content into departmental buckets due to business applications and security generally being closely linked. Other reasons to split object stores maybe retention or legally driven.

So once we have our content split into smaller logical buckets and assigned the correct storage policies to allow roll over of content in storage areas as time continues we then need to turn our attention to the complimenting database storage which holds our meta data.

Generally, the performance tuning of databases occurs once the system has been used for a period of time and the usage can be determined as it is difficult to tune a ‘green fields’ install without any content and benchmarks of the user activity. Usually, only larger companies can invest in the time, effort and cost associated in load and performance testing has taken place in advance of a project or build. As a rule of thumb reviewing those frequently called queries and long running queries can be a good place to start your database tuning. However, either of these initial testing scenarios should not be the end of the tuning activity and regular reviews should be conducted to ensure the database performance remains at an optimum and regular tweaks are made to compensate for the usage or query pattern changes that may occur due to seasonal activity and of course growth. There are various approaches for performing such load and performance reviews depending on the underlying database system. In MS SQL Server there is the Enterprise Management Studio Performance Dashboard and in IBM DB2 there are a series of system tables to help establish long running queries.

High Availability
Often High Availability, HA and Disaster Recovery, DR get confused and although different DR approaches can rely heavily on HA. Firstly, there are different levels of HA that an organization should understand before rushing into making a decision. On understanding these levels then these should be mapped to what the business SLA’s are to determine the most suitable solution.

Generally, there are 4 approaches to system fail-over:

• No Fail-over:
  • Recovery Time – Unpredictable
  • Cost: None to low
  • User Impact: High
• Cold Fail-over:
  • Recovery Time – Minutes
  • Cost: Medium
  • User Impact: Medium
• Warm Fail-over:
  • Recovery Time – Seconds
  • Cost: Medium to High
  • User Impact: Low
• Hot Fail-over:
  • Recovery Time: Immediate
  • Cost: High
  • User Impact: None

Both HA should be driven by the business and be based around their SLA’s as well as the budget deemed appropriate. It can also depends on the use case. A 24 x 7 online banking website would generally demand a hot fail-over compared to an internal holiday request system. In short,  warm and hot fail-overs are not cheap to implement in large ECM systems and hence the decision to implement HA should not be taken lightly.

Indexing:
As data repositories continue to grow consideration needs to be given to the ability to search for valuable information as what use is a repository if you can find what you are looking for. Metadata searches are a relatively easy problem to tackle. As previously mentioned as metadata database grows then consideration should be given to those searches that are performed most frequently or return large result sets. There are tools on the market to assist with this but much can be achieved by using those features delivered OOTB with databases such as DB2 or MSSQL. DB2 have inbuilt IBMSYS tables to assist in determining long running queries were as MS SQL Enterprise Studio provides an easy to reporting interface which provides those most frequently ran queries as well as ranking the run time for the top 10 queries executed. DB2Explain and DB2Optimizer tools are also key tools to any DB2 DBA and should be used frequently in large deployments to ensure the system is running efficiently and tweaked as necessary with data usage and growth.

Managing keyword or content searches can be more challenging. Indexes can typically grow larger than the content it is based upon and unlike content can also very fragile. Indexing tasks are I/O intensive due to the process in generating the associated index files. Lots of temporary files are generated which can be seen as unusual activity to AV products. Ensuring AV software isn’t scanning your index directories is advisable as well as disabling Windows Indexing services. Space is also a key concern as running out of drive space during the index process is also likely to lead to a corrupt index. So we now know what to look out for or what to avoid to proactively protect our repository indexes but what if the inevitable happens? What can we do to restore our search services in the minimum amount of time to the business?

IBM FileNet’s latest version of Content Search Services, CSS has several useful features which have all matured from the early days of it being Verity or Content Search Engine, CSE after the IBM acquisition. The latest CSS provides the ability to not only schedule indexing for out of hours processing but also the ability to auto-rollover indexing area means our indexes are now broken down into manageable chunks. Having these manageable chunks mean that more flexibility and efficiency can be given to our backups, restores and DR processes.

Backup and Restore:
When does big data get too big? When you can’t restore it within your SLA’s then your data is too big and you have an even bigger problem!
The underlying components of the majority ECM system being the file system objects and corresponding databases the general approach is to ensure that these components are restored and rolled forward to a specific point in time so they are all synchronized. Obviously, in a Business Continuity, BC scenario the time to restore a service versus the data accuracy needs to be determined. This is generally dictated by the SLA with the business as an example in the case of a banking system the accuracy of data is imperative as opposed to a client services application which may be loosing new business every minute their ECM system is down.
Below is a diagram highlighting the relationship of the various components of an ECM system and the dependency on each other to be synch for a full up-to-date system restore.

Two terms to be familiar with when it comes to backups and restore are Recovery Time Objective, RTO and Recovery Point Objective, RPO. Both these objectives should be set by the business in the business continuity plan and then the appropriate infrastructure put in place to support them. Below is a high level example of Recovery Time Objectives, RTO and Recovery Point Objectives, RPO:

Client Name	Users	System Usage	Priority Ranking	RTO	RPO
Company XYZ	~900	Document Mgmt Sys	2	4 hours	1 Hour

Sub-System	Priority Ranking	RTO	RPO	Sub-System Depends on	Sub-System Required by
DB2	1	30 mins	5 mins	O/S & Hardware	Company XYZ
WebSphere	1	30 mins	0 mins	O/S & Hardware	Company XYZ
FileNet	1	1 hour	30 mins	WebSphere & Storage	Company XYZ
Client Lookup	3	½ day	½ day	DB2 & FileNet	Company XYZ

It can be typical of the business to want immediate access and total up to date recovery of data but in outlining the costs that come with these demanding requests for enterprise systems then there is usually a happy medium that can be agreed upon. Once these parameters are defined then the architect needs to turn their attention on how to carve the back-end data up into manageable chunks as well as utilizing the technology to the best of its ability to provide the most efficient and up to date turn around of restored data.

Disaster Recovery:
Disaster Recovery, DR and Business Continuity, BC are often confused but have similar purposes. The difference being that DR is the continuation of a company’s vital services from a natural or human-induced catastrophe compared to BC which relates to those daily/weekly activities that take place to ensure the restoration of business functions.

Many of the same challenges that exist for high availability, backup and recovery and also indexing are true for DR due to DR procedures and plans relying on these functions. All the procedures for these functions should be brought together in a DR PlayBook which ideally should be created and walked through step by step before systems go live. However, this is seldom the case but already live ECM systems should also have DR PlayBook in place and plan to have bi-yearly/yearly DR tests scheduled during out of service hours. Enterprise systems and infrastructures are constantly changing so these scheduled tests will ensure nothing has been changed to impact your DR procedure. If it has then you can make those vital updates to the PlayBook then and test rather than discovering them during the crisis.

Summary:
Hopefully, the following has given some insight into the challenges surrounding large scale ECM deployments and the key aspects to consider and potentially how to address them although every environment is different. The one thing to consider is that a lot of these expensive head-aches and efforts go away if a cloud or potentially a hybrid (on-site/cloud) model is used. Cloud in itself is another discussion with it’s own challenges but some food for thought for now.

Assistance with Data Transfer between Countries

Most are aware that there are legal issues surrounding transferring of data between counties no more so than Canada and US. A typical example which depends on the company business is that data isn’t allowed out of Canada Eg, Mail Servers hosting Canadian users must be located in Canada mainly due to Canada having much stricter Data Protection laws in place than the likes of the US. Generally, it is always a problem to transfer data from a country that is deemed more secure to less secure target country. In the case of Canada it isn’t necessarily the internal privacy laws but more the issue with the US Patriot Act that allows unfettered access to data that is a key motivator to have the data remain behind the Canadian border. Vice versa isn’t as big a problem in the majority of cases.

Directive 95/46/EC:

The data transfer issues is also evident in Europe with such countries as the UK transferring data to less secure European Union, EU countries or even outside the Europe. However, the Directive 95/46/EC regulates the processing of personal data in the EU. The two things I take from this directive are:

1)      Processing – any operation being performed on personal data – collection, organizing, storage, updating..etc..

2)      Personal data – anything that can be readily related to a natural person – address, credit card number ..etc..

These two points raise a question in my mind:

1)      What type of data does the company want to transfer and what do they want to do with it? Eg, do they want to image files and upload them for storage to an Electronic Repository in another country?

So the EU directive may allow data to be transferred between EU countries taken on a case by case basis – I haven’t read the directive from top to bottom but guessing it will state that personal data can be transferred based on guidelines and security best practices being followed and audited. This can be complicated and lengthy to implement and prove. Also once we go outside the EU to transfer data then this is another ball game and if it is going between companies as well as coutnires then the challenge takes another twist.

Binding Corporate Rules:

Despite this, an interesting development or follow on from the foregoing directive has come about due to large multi-national corporates wanting to transfer personal data internally. This has led to the development of the Binding Corporate Rules, BCRs by the EU. In short this allows companies to transfer data in their organization between EU countries once an approval has been sought by the Data Protection Authority in the source and target countries. Unfortunately, it isn’t as simple as contacting these authorities and telling them that you are going to do this and it is logged and your data transfer can continue. A strict global privacy policy needs to be put in place that satisfies EU standards and layouts a framework on the approach being taken. This policy and framework of policies, training, audit ..etc.. then needs signed off by the leading and target data protection authorities. So again a relatively lengthy process which I would envisage with input from legal bodies having to agree on details, policies, standards, wording ..etc..

On the positive side you will see from the link below there is already a number of companies that have successfully implemented BCRs and actively using them to transfer data internal between countries. Also to help speed up the BCR process a number of countries already have a mutual recognition with a framework in place – see the link below for further details.

I have included the list of Data Protection Authorities in the EU below. If you know the countries that you need to transfer data between in your organization  then a next step maybe to contact the Data Protection Authorities in these countries to determine your next steps.

Further Reading:

• European Commission
• EU Directive 95/46/EC
• Binding Corporate Rules
• EU Data Protection Authorities
• Countries with mutual recognition

Migrating Records!

Question:

How would the migration of electronic records to one system to another be handled?

Answer:

The is no one solution or approach for electronic records migration. Each records migration initiative should be treated independently and it should be recognized that these are high risk processes. Despite this there are general guidelines that can assist with the process that revolve around risk assessment, auditing and assigning ownership to the migrated records review.

Some guidelines:

• Recognition that data changes threatens authenticity, integrity and availability of records
• Requirements – essential metadata and characteristics must be preserved
• Requirements – file plan understanding for continued use in new system
• Requirements – security
• Planning – data issues
• Planning – system issues
• Disposition – a full dispostion sweep in the source system will ensure the minimum amount of records is left for migration – why migrate records that are due or already passed their retention schedule?
• Pre-migration testing – relevant technical, business and records-owners must ensure the authenticity, completeness, accessibility and usability
• Is a revised migration strategy required?
• Migration – duplicate/backup source, action plan, continued quality assessment…etc
• Perform post migration testing/sign off
  • all records migrated including those non-active and in additional storage envs
  • Entire record including metadata migrated
  • Essential characteristics migrated
  • Users/record owners signed off against authenticity, accessibility, usability & completeness
  • Perform standard reports at key stages to verify success and audit migration
• Make records of complete migration process, audit, reports ..etc
• Source records must be kept minimum of 6 months see here for more details: States Records Guidelines

In summary, any perceived indiscretion in the management of the record during the migration process can be seen as compromising the records completeness and hence its authenticity.

IBM Records Manager Myths

IBM Records Manager, RM or more recently re-branded to IBM Enterprise Records, IER is often challenged by other vendors and clients stating the following:

Challenge: Support the triggered of retention policies

• Retention policies can be triggered by events within the FileNet repository. This can even be extended further through customization to trigger retention schedules based upon external systems actions. This is generally achieved by programmatically setting the records flag in the File Plan Object Store, FPOS.

Challenge: Disposition sweeps cause performance issues when ran

• There is no doubt that disposition is a resource intensive in any RM system due to the complexity of the calculations that need performed. However the perception that it is performance impacting is often caused by greenfield installations. Many documents are loaded and mass updates take effect to mark these documents with retention schedules based on file plans this in turn means that a large quantity of document are to be destroyed at the same time when they expire. Often little thought is placed on the disposition sweep other than enabling it for a complete file plan when a green-fields implementations are initially completed.  There fore X years later the system suddenly slows down overnight due to the shear quantity of documents to suddenly destroy. Approaches to reduce the risk of performance issues caused by disposition sweep is to:

1. Set you disposition to run on different night for different branches of your file plan thus reduce the quantity of records to be destroyed into more manageable chunks.
2. Run your disposition sweeps from dedicated machines other than directly on your repository.
3. Aim to perform disposition on a folder/case level rather then on individual documents. This is a lot more efficient when the sweep runs but not always possible for all use cases.

Challenge: There are no audit reports

• IER 5.1 provide a full OOTB reporting templates based on Crystal reports. A full list of these reports can be found here:
• IER Crystal Report templates

Challenge: It is unable to provide records management for paper based records

• All version of IBM RM/ER provides support for paper based records.

Challenge: It is unable to provide records management for other repositories

• Again this is untrue. IER is able to provide records management to other repositories such as OnDemand, Documentum, Livelink..etc.. via IBM Content Federated Services, CFS. If a repository is not supported then with an understanding of the federated repository’s API a connector can be created. Further details here:
• Content Federated Services

Hopefully, the following help clarify some of the myths of IBM Records Manager/Enterprise Records.