Building and Implementing Successful Taxonomies

6 downloads 302 Views 273KB Size Report
For all the importance assigned to taxonomies, few studies have shed .... transfer, and write-off), Claim No., and Accid
Shedding Light on

Building and Implementing Successful Taxonomies records taxonomy is a corporate-wide schema for the identification, retrieval, and disposition of all business records. It provides an easy-to-use system that allows people to easily store and retrieve the documents they use in their day-to-day business. (See the sidebar on page 43 for an example.) Although the term is often used in a limited sense to describe the hierarchical classification structure to be used for storing documents or records, in the modern and technological environment, it should certainly include more.

A

For all the importance assigned to taxonomies, few studies have shed light on what taxonomy design methods are effective, how much should be spent on the design, or how to make designs more successful. A September 2010 survey, “Records Classification Systems – Taxonomies,” included approximately 4,000 members from the United Kingdom (UK), North America, and Records Management Association of Australasia ListServes. The survey results, which included more than 170 responses worldwide, provide clues about how to improve taxonomy design methods and implementation planning to significantly increase their success rate.

James Connelly, CRM Ontology (Relationships)

Records Taxonomy

Classification (Heirarchy & Clustering)

Naming (Thesauri and Metadata)

Taxonomies should comprise classification schemes and relationship models, as well as detailed naming conventions, as the figure shows. With the advent of enterprise content management (ECM) tools, we can now easily manage “function-based” groups of records within repositories

42

MAY/JUNE 2011 INFORMATIONMANAGEMENT

that allow for proper disposition and, at the same time, we can display the documents or records in user-friendly structures that can include personalized taxonomies, faceted relationships, or business team-related arrangements. Along with policy and procedures, a taxonomy is one of the most crucial el-

ements of a records program. In fact, it is a linchpin. Once it is built, other key program elements can be established, including a records retention schedule and disposition program, a vital records program, and a program to manage personal information banks. Without a taxonomy, these elements are difficult to establish and maintain.

What were the main reasons your organization decided to build a records classification system/taxonomy? (Respondents could select more than one reply.) Improved Records Control or System Improved Lifecycle Management Following RM Best Practices Enterprise Content Mgmt. Implementation Mission-Critical

73% 62% 60% 52% 49%

Productivity Improvement Improved Hard Copy Management Improved File Server Management Cost Savings Needed to Improve SharePoint

35% 31% 26% 22% 18%

Providing Rationale for Building a Taxonomy It is interesting that the most commonly selected rationales, “better access and control” and “improved lifecycle management,” are traditional and embody basic records management principles.

Access and Control

During the design of a taxonomy, it is common to identify all business records in the data-gathering process. Simply knowing their location and ownership gives an organization better control over existing records. Also providing a structure to simplify storage and retrieval enhances access to individual records or documents.

Improved Lifecycle Management

A taxonomy is always the foundation of a records retention schedule. Legislation and policies often mandate recordkeeping for records that support specific business functions. By grouping similar business functions, it becomes easier to assess the need for retention, select an appropriate retention period, and make retention periods and “event triggers” more consistent throughout the organization.

Business Case Rationale

On the other hand, creating a business case for taxonomy development appears necessary. Expenditures on taxonomy development do not appear adequate for such a critical component of an organization’s RM infrastructure. (See the section on costs and budgeting.) It would be logical also to play up the improvements in productivity. A simple return on investment (ROI) study would show that an intuitive taxonomy would considerably reduce the time taken to store and retrieve documents. Here is an example using assumptions: Assume that each staff member creates about 800 documents a year (a little more than 3 documents x 250

A Taxonomy Example For the purpose of this example, assume that there are only two major business functions involved in managing vehicles: fleet management and risk management. A functional breakdown may look like the following: Fleet Management

Risk Management

Use (logs) & ownership (by business unit)

Vehicle insurance (policies) (by policy #)

Maintenance of vehicles (by year & make)

Vehicle accidents (by accident date)

Vehicle disposal (by disposal date & VIN)

Vehicle claims (payments) (by VIN)

Metadata elements that may be captured with respect to vehicles may include both “common” and “unique” identifiers: Vehicle Identification Number (VIN), Year of Manufacture, Make, Model, Year of Acquisition, Year of Disposal, Disposition Status (e.g., sale, transfer, and write-off), Claim No., and Accident Date. Series Structure Each records series may require folders and documents to be kept in different order. Vehicle maintenance may be kept by vehicle “Year of Manufacture” and “Make” for ease of reference, whereas vehicle accidents may be kept by “Incident/Accident Date.” This is why user involvement is so crucial in taxonomy design. Each business function must be approached and discussions held to help determine what hierarchical order will assist them in conducting business and in retrieving information. Metadata Each records series may need different metadata, but if common metadata can be found and used, the opportunity exists to ensure that all documents related to a specific vehicle can be easily located. In such a case, should there be an injury accident and litigation, legal discovery would be simple. Common metadata can be used within “folder names” in both hard copy and electronic environments or “document names” within a server environment. Naming conventions such as these are critical to successful implementations. Ontologies Note that the responsibility of records analysts does not end with the structural design. It needs to be carried on to metadata elements so content management systems can be taken advantage of with respect to workflow or real simple syndication (RSS) feeds. With proper metadata and naming, the relationships between records series can be maintained. In the above example, if “Year of Manufacture,” “Make,” and “Model” are used as naming conventions in ALL series, searches across the entire taxonomy will allow for easier identification of all information related to a specific vehicle, which could be crucial if there was litigation related to an injury accident. workdays). Each document will have to be stored, so there will be 800 storage actions. If only 20% of documents are ever retrieved, there will be 160 retrievals. With an inadequate classification system, it could take as long as two minutes to name and store each document, and it could easily take 10 minutes to retrieve a document. An intuitive system will certainly take less time to use. A conservative

estimate is that for each of the 960 combined storage and retrieval actions, 15 seconds can be saved, for a total savings of 14,400 seconds – which is 240 minutes, or four hours, per year. At an average wage (including benefits) of $30 an hour, each employee would save $120 each year, so an organization of 1,000 people would potentially save a total of about $120,000.

MAY/JUNE 2011 INFORMATIONMANAGEMENT

43

Choosing a Classification System Type It is perhaps a tribute to ISO 15489 that functional classification continues to be the choice of most organizations. But in the last few years, the survey shows a trend toward hybrid systems.

Function-Based Taxonomies

Function- and activity-based systems do assist records and archives staff in managing records over long periods of time. They also ensure that all aspects of a business are included within the taxonomy. But, there are limits to strict functional systems. An analysis of the survey results shows that functional designs are quite effective when implementing large-scale ECM projects in large organizations. It appears that the uniformity of the functional design at high levels creates consistent classification across large organizations. However, it is also evident that smaller and unique business units may not gain much advantage from the ECM project, as these broad functional classification systems appear to cause problems at more granular levels.

Hybrid Taxonomies

In the late 1990s, the limitations of functional systems became apparent in systems that had been recently introduced. This was readily apparent in matrix-based organizations (i.e., those with a number of diverse business functions), but it was even more so in case file systems where a number of business functions related to a particular project, activity, or case file. Taxonomies for projects or programs that are matrix-based may need considerable adaptation. Also, case files, which may not be linear in nature, may cause problems for strict functional designs. For example, when a purchasing organization’s business unit needs to acquire new software, it may conduct

44

MAY/JUNE 2011 INFORMATIONMANAGEMENT

a needs analysis; do market research; prepare a request for proposal; interview prospective vendors; analyze proposals; negotiate contracts; acquire and test software; and finally approve a purchase. Although there are eight distinct business functions, documentation is often retained by purchasing managers in a “projectbased” folder for ease of reference while the software is being acquired. In such a situation, the taxonomy may need to adjust its top-level functions, while retaining function activity structures within a “case” file. Note that ECM solutions can allow for function-based libraries while allowing individual business units to view documents from a number of functions within a case file folder. This allows for a modified or personal taxonomic display while retaining official records within a strict functional structure.

Subject-Based Taxonomies

Subject systems were popular in the 1970s and 1980s. These were based on library or encyclopedic-style systems where records are grouped by topic rather than by function. In the sidebar example, the risk management function of the organization managed vehicle insurance, accidents, and claims. In a subject-based system, the topic might be “vehicles,” and all six records series cited would be grouped together irrespective of who was using the records or how the records were being used. The advantage of subject-based systems is that they are easier to understand. But, often they lead to clasTypes of Classification Systems Which type of classification system does your organization use or wish to develop? Function-Based Hybrid-Based (function, subject, project) Subject-Based Project-Based

52% 38% 10% 1%

sification errors and poor retention schedules. Also, they tend to be arbitrary and are frequently changed by new staff that prefers to use their own terminology.

Choosing an Approach to Building Taxonomies From these results and participant comments, it is evident that designs are following an in-house process similar to the business process analysis that was used in the 1980s to assist in the design of computer systems. What methodology was used to develop the classification system? Proprietary (in-house) 37% Proprietary (consultant) 15% Adapted Existing Classification System 14% DIRKS (interview approach) 13% DIRKS (user focus groups approach) 12% Other 10%

Gathering Background Data

Considerable effort is required to gather background data. Designers must have access to organization charts, job descriptions, websites, business models, and strategic plans to help them understand the business functions of the organization they are trying to assist. Several participants also commented on the support received from their IT groups as the design work parallels and often complements business architecture designs. Shelf or high-level inventories are needed to identify all hard copy records, volumes, subject areas covered, existing identification schemes, and naming conventions. Electronic inventories should identify folder structures, document volumes, and storage space used. This volume information is crucial for planning and costing implementations. Armed with such information, designers frequently conduct interviews to determine what business functions are supported and how documents

should be stored. An interview can certainly elicit information as to business functions, but it can also introduce designer bias. The classification system often changes from supporting users to supporting the records management program, as reflected in this survey comment, which represents a common refrain of many participants: “The classification system was designed by records managers for records managers, but unfortunately does not provide actual business value to anyone else in the organization. … It is not merely a matter of change management and helping staff learn a new way of working in adopting the classification scheme, it actually works quite actively against the information flows within the organization. We are now just starting to implement our EDRMS … systems, which use the classification scheme, and it has become a problem – the classification scheme will probably work on the EDRMS system, which is managed and controlled centrally by records managers, but on the more dispersed systems, including the file-share network drives, it will struggle.” Insistence on meeting the needs of the records community leads inevitably to failure or, at best, tepid acceptance of the new system. This survey shows that relying on user-based focus groups involving management, professional, and technical staff is a more effective process than one-on-one interviews. By working with three or four people from a business unit, the process becomes inclusive and, in some cases, empowers the users. A designer can control structure and format but still give the business unit the opportunity to build its own system.

Adapting Taxonomies

It was somewhat surprising that a

considerable number of organizations adapted existing systems from similar organizations. Although some may see this as a time-saver, it is more likely to render the taxonomy unacceptable to staff, who may say such things as, “I wasn’t consulted,” “That’s not the way we do things in this company,” or “I don’t understand the reasoning behind this design.” A key element of taxonomy design is obtaining buy-in. Those indiviuduals who don’t involve users in the process and give them the opportunity for input will not have their cooperation during implementation. On the other hand, having knowledge of other organizations’ designs should be part of the research. This allows designers to offer users alternatives, design options, or different ways of organizing their records. But, to take a model and impose it on an organization is often a recipe for failure.

Budgeting for Design and Implementation A cross tab review reveals that larger organizations (more than 5,000 staff) either planned to or did indeed spend more on their taxonomies (greater than $100,000) and to that end were quite successful with both design and implementation. However the average organization, with a staff of 1,000 to 5,000, spent less than $25,000 on either design or implementation. The caveat appears to be that organizations should understand that designing a taxonomy is not a clerical process. It includes business process analysis, use of communication strategies and tools, and legislative and compliance reviews, as well as engaging management, professional, and technical staff in a work-altering project.

Design Costs

To complete a design properly in a large organization (i.e., 1,000-plus people) may involve a project coordinator, two or three teams of designers, each

of which could include a subject matter expert, as well as an assistant who can ensure that the design is transcribed properly and that individuals’ needs or concerns are addressed. During a design process or focus group, the designer is often fixed on the task or the results that are being developed and can neglect individual concerns, which can result in an overlooked individual becoming a thorn in the side. Each business unit may require several days of data gathering, as well as about a half-day focus session and several days to compile the design and provide follow up to portions of the design that are complex. If there are 30 to 40 business units, this could amount to 500-plus person-days of work. Using a mix of existing staff and, perhaps, consultants, could amount easily to $150,000 worth of effort. This survey suggests that timeframes and budgets for taxonomy designs should be commensurate with the anticipated productivity gains and value-added improvements that a well-designed and user-accepted taxonomy offers. In other words, if the ROI anticipates productivity gains of $100,000, an organization should be prepared to pay at least that for design and a similar amount for implementation.

Implementation Costs

Implementation costs within a server structure are usually low. It takes a team of two usually less than a half-day to work with a business unit to convert its electronic files to a new system. Although some folder or document-naming changes may take longer, they can usually be assigned to clerical staff to ensure the completeness of the change-over. The methodology for such conversions, although technical, is usually simple to arrange with IT staff. Hard copy implementations normally take one linear foot of records

MAY/JUNE 2011 INFORMATIONMANAGEMENT

45

per day with a good classifier at the helm. If case files are involved, speeds of three linear feet per day can be reached. Much of this estimate depends on the complexity of the records, as well as the skills of the assigned staff. So, for every 1,000 linear feet to be converted, assume at least 600 days of implementation time. Determining how much should be converted brings up the issue of legacy data.

Legacy Data Costs

Of all the survey results, this was the most surprising: 40% of respondents said they were leaving legacy data behind. Of the remainder, 26% were spending $50,000 or more. From a simple cost analysis, it is not surprising that organizations would feel this way and have tried to minimize how much information needs to be brought forward into a new taxonomy. As long as legacy data is accessible, there may be no problem. For example, if electronic records are moved into a searchable archive drive and past hard copy is carefully boxed, listed, and labeled – and if these repositories can easily use the newly developed records retention schedule – there may be little need to bring forward all the records. However, there are still dangers. Litigation is often a concern, and since legal discovery processes involve all records, avoiding the implementation of legacy data could be fatal to some organizations. It is clear that some form of risk assessment must be done. At minimum, each records series should be reviewed. Anything that could put the organization at risk should be assessed as to the cost of bringing it forward versus the potential for financial risk should the organization be unable to produce the document in the event of litigation. Quite simply, the value of bringing forward documents/records to a new structure or system must be balanced against the costs of such an exercise.

46

MAY/JUNE 2011 INFORMATIONMANAGEMENT

Implementing a Taxonomy Fifty-eight percent of replying organizations indicated that their plan was to deploy their taxonomy across the entire organization. Although most organizations were simply planning their roll-out, 20% of organizations said they had completed their organizationwide roll-outs. Once a design has been completed, it is important to validate the design and roll it out to each business unit as soon as possible. Delays in implementation can adversely affect the use of the new classification system. In fact, many anecdotal comments indicated that many of these roll-outs were bumpy at best. Many expressed frustration at the “stop-and-start” nature of the project. Difficulties in implementation can usually be traced to one of three things: planning, validation, or training.

Planning

In the section “Budgeting for Design and Implementation,” there is considerable information as to time, effort, and resources required in an implementation project. Most organizations underestimate the extent of such a project. At the outset of implementation, the designers should be able to provide a list of supportive business units. Also there should be a list of those business units most in need. From these lists, plan which business units to address and in what order, and then communicate this to all staff so they know when to expect the implementation teams. Delays must also be communicated to all staff. Periodic status reports are an integral part of communication strategies. There should also be a large project “task map” prominently displayed that identifies each business unit and the status of each implementation – from the completed design, to the validated design, to the initial training, to the support and follow-up needed to ensure a successful implementa-

tion. Delays should be noted and the reason for the delays addressed in a “lessons learned” meeting at the end of each business unit implementation.

Validating the Taxonomy

Will the taxonomy work? This is such a fundamental question that it is astounding that few organizations focus on this. The most commonly identified validation method indicated was to send a copy of the taxonomy to a business unit and ask them to review it. Testing the classification structure in a pilot project or sending it to managers was not as effective as a full review process. Remember that most users are not sure what to look for in the taxonomy. If the structure is returned for review, ask the focus group or business unit to identify perhaps three to five commonly used documents. For each document, ask the focus group or business unit whether or not it is immediately apparent where these documents would be stored or found. If difficulties are encountered, it is often a result of inadequate or incorrect naming. Adapting records series names at this juncture can significantly improve the implementation success rate. How was the records classification system validated? Returned to Business Units Returned to Focus Groups Pilot Implementation Managerial Review None

Training Approach

31% 27% 18% 15% 9%

Training is of fundamental importance when introducing a new taxonomy. Survey respondents used a variety of approaches, but business unit training followed by individual and personal support was the most common approach (27%). Those 12% of respondents who used the “train the trainer” ap-

proach had much more successful implementations than other approaches on their own. (As with many of the statements in this article, this was determined by filtering the responses of each approach and reviewing the success rate of implementations.) In this process, an individual from each business unit is given extensive training in the new system so he or she has in-depth knowledge of the new structure and a good understanding of: n Why records or documents are grouped the way they are n The relationships between records series n The retention periods for groups of records n The reasoning behind the selection of the retention period That person becomes the “trainer” for that business unit, conducting the introductory session and following up with each staff member. This approach essentially creates a “super user,” a “champion,” or a “go-to” person in each business unit to help anyone who is having difficulty finding or storing documents.

Identifying Critical Success Factors It is interesting to note that 65% of the “World” users rate their taxonomy development and implementation process as “excellent,” “very good,” or “good,” while just 55% of “North American” users did. There are a number of reasons for this.

Early Involvement in Recordkeeping

The British Empire of the 19th and 20th centuries had a tremendous impact on “records keeping” across the globe, and, in particular, the use of registry (records) offices introduced formal records keeping to many governments. As a result, global records classification system management has been slightly ahead of North American systems

for some time. More specifically, Australia was a key driving force in the development of ISO 15489-1 Information and Documentation – Records Management – Part 1: General, the international standard for recordkeeping. Both Australia and the UK were quick to adopt the standard’s strong recommendation for functional classification schema, and their longer experience with taxonomy designs and implementations has apparently led them to a better knowledge of what works and what doesn’t. Also, the survey revealed key differences in the approach the World took in designing and implementing taxonomies versus those North America took.

User Participation and Management Involvement

The need for user participation is clear; the global figure of 71% of users participating in the design vs. 43% in North America is telling. By filtering responses, the survey shows that organizations had a 65-70% success rate where user participation was a success factor. By filtering responses again, the survey shows that organizations had a 75-80% success rate where management involvement was a success factor. In a more detailed question regarding management involvement, almost 60% of respondents said they had received management approval of their taxonomy outline before proceeding with design and implementation. When both user participation and management involvement were identified as critical success factors, the success rate jumped to 85%. Although employing a communications strategy and design validation did not significantly increase the success rate of taxonomies much above 85%, it appears these approaches also contribute to the success of projects.

Communications Strategy

A communication strategy involves more than sending a periodic newsletter to tell people what is happening. It must include change management techniques and allow the project to respond to business units where problems occur. It should also focus on successes and the satisfaction of users. Through peer pressure, organizations can move stalled implementations forward.

Design Validation

If users are not convinced that the new system can work and is working, they will subvert the system. Sending a design for review is useful, but working with groups to look at specific examples of records and document retrieval is better. This will allow the team to adjust terminology so it reflects what users expect. Also, it allows designers to assess the ability of users to “browse” the structure.

Summing it Up One survey respondent listed the following five critical success factors: 1. A detailed roadmap or implementation plan 2. An executive steering committee, chaired by an executive sponsor 3. Committed and budgeted resources, both capital and human 4. External and unbiased subject matter experts/consultants 5. Detailed training/communications/ change management strategies Although reflective of an individual organization’s approach, this is a wonderfully concise explanation of how to succeed in designing and implementing a taxonomy. Editor’s Note: View the survey in its entirety at http://content.arma.org/ IMM. Jim Connelly can be contacted at [email protected]. See his bio on page 51.

MAY/JUNE 2011 INFORMATIONMANAGEMENT

47