Thursday, May 14, 2015

ISO/TR 15489-2 Information and management -- records management -- part 2: guidelines

I reviewed the first part a few days ago. Let's take a look at the second part:





So this TR is an implementation guide.

  • We start out with policies and responsibilities. We have to develop policy statements and articulate responsibilities.
  • We need to involve senrior management, RM professionals, business unit managers, designated staff, and -- ultimately -- all staff.




  1. Preliminary investigation
  2. Analysis of business activities:
    1. documentation describing org's business and bus processes
    2. Business classifications scheme (functions, activities, transactions)
    3. Map of org's processes that show where records are produced
    4. Possible tools include: thesaurus of terms, disposition authority that defines periods and disposition actions
  3. Identification of reqs for records:
    1. A list of all sources containing records reqs relevant to the org
    2. A list of regulatory, business, general community reqs to keep records
    3. Risk assessment report endorsed by mgmt
    4. Formal document that sets out requirements to keep records
  4. Assessment of existing systems
    1. Inventory of existing bus systems
    2. Report on the extent to which they address org's reqs for records
  5. Identification of strategies for satisfying records reqs
    1. Nature of org, including goals and history
    2. Types of business activities
    3. Way it conducts bus activities
    4. Supporting tech enviro
    5. Prevailing corporate culture
    6. External constraints
Strategies may include:
  1. Adopting policies and procedures
  2. Developing standards
  3. Designing new system components
  4. Implementing systems
Products may include:
  1. List of strategies
  2. Model that maps strategies to reqs
  3. Report for senior mgmt recommending overall design strat
  1. Design of a records system:
    1. Designing changes to current systems, processes, and practices
    2. Adapting or integrating tech solutions
    3. Determining how to incorporate these changes
Products might include:
  1. Design project plans, tasks, responsibilities, etc.
  2. Reports detailing the outcomes of periodic design reviews
  3. Documentation of reqs changes, signed off
  4. Design descriptions
  5. System business rules
  6. System specs
  7. Diagrams of architectures and components
  8. Models representing views: processes, data flows, data entities
  9. Specs to build or acquire tech components
  10. Integration plans
  11. Training and testing plans
  12. System implementation plans
  1. Implementation of a records system
    1. Detailed project plan
    2. Documented policies, procedures, and standards
    3. Training materials
    4. Documentation of the conversion process and ongoing migration procedures
    5. Documentation for quality systems accreditation
    6. Performance reports
    7. Reports to management
  2. Post-implementation review:
    1. Analysis to determine if records have been created and organized
    2. Interviews with stakeholders
    3. Surveys
    4. Examining documentation developed during earlier phases
    5. Observing/checking operations
Deliverables:
  1. Assessment methodology
  2. Audit of the performance of system and process
  3. Report to management with findings and recommendations
  • Necessary instruments:
    • Classification scheme based on business activities
    • Records disposition authority
    • Security and access classification scheme
  • Other tools:
    • Thesaurus
    • Glossary
    • Regulatory framework analysis
    • Business risk analysis
    • Organizational delegation authority
    • Register of employees and system user permissions
Section 4.2.2 looks interesting: Business activity classification. As I've noted at length before, this is actually very hard to do.

  • The first level reflects the business function
  • Second level is the activities
  • Third level is really activity refinements or groups of transactions
  • The first two levels are typically prefaced with a verb; the third, maybe not.
  • Development has to be consistent with thesaurus principles:
    • Terminology from business functions, not org units
    • Specific to the org
    • Consistent and standard
    • Hierarchical
    • Unambiguous
    • Discrete groupings
    • Developed in conjunction with records creators
    • Maintained to reflect business changes
  • We get into authorized headings, thesaurus construction as per ISO 2788
  • There are some guidelines on how to determine the disposition authority
  • Security. Typical restrictions pertain to:
    • Personal information/privacy
    • Intellectual property rights/commercial confidentiality
    • Security of property (physical, financial)
    • State security
    • Legal and professional privileges
  • To develop access classification:
    • Identify legally-enforceable rights and restrictions
    • Identify areas of risk of breach of privacy
    • Identify security issues
    • Ranks the areas of risk of breach to security according to value and likelihood
    • Map identified areas of risk and security to business activities
    • Identify appropriate levels of restriction for areas of highest risk to the lowest
    • Link restrictions to thesaurus or activity classification system
  • Section 4.3 is records management processes:
    • Capture
    • Registration
    • Classification
    • Access and security classification
    • Identification of disposition status
    • Storage
    • Use and tracking
    • Implementation of disposition
  • Description depends on scope. For example, individual docs only have to be described by the individual; a business unit only needs details relevant for that business unit; public domain requires good references as per ISO 690… who knew there was an ISO standard for bibliographic reference?
  • Registration must include:
    • Unique ID
    • Date and time of registration
    • Title or abbreviated description
    • Author, sender, or recipient
  • Registration could include:
    • Document name or title
    • Text description/abstract
    • Date of creation
    • Date and time of communication and receipt
    • Incoming, outgoing, or internal
    • Author (with affiliation)
    • Sender (with affiliation)
    • Recipient (with affiliation)
    • Physical form
    • Classification
    • Links to related records
    • Business system from which the record was captured
    • Application SW and version on capture
    • Standard of records structure (SGML, XML, etc.)
    • Templates required for interpretation
    • Access
    • Retention period
    • Structural/contextual info for management
  • Classification:
    • Identify the transaction/business activity
    • Ensure that it is appropriate given business unit, etc.
  • Indexing terms:
    • Format/nature of the record
    • Title or main heading
    • Subject content of the record (business activity)
    • Abstract of record
    • Data associated with transactions
    • Names of clients or organizations
    • Handling or processing reqs
    • Attached docs not otherwise identified
    • Uses of records
  • Access/security:
    • Identify business process
    • Identify owning business unit
    • Security classification
  • Storage and handling considerations:
    • Volume and growth rate of records
    • Use of records
    • Records security and sensitivity
    • Physical characteristics
    • Retrieval requirements
    • Cost of storage options
    • Access needs
  • Continuing retention: copying, conversion, migration
  • Transfer considerations.
  • Evidential weight: "if the integrity of a record is called into doubt in court by suggestions of tampering, incompetence, improper system functionality or malfunction, the evidential weight or value put on the document by the court may be lost or, at least, reduced, to the detriment of the case."
  • Training methods:
    • Employee orientation and documentation;
    • Classroom training
    • On-the-job training and coaching
    • Briefing sessions
    • Leaflets and booklets providing how-tos
    • Computer-based presentations
    • Help text in computer system
    • Training courses provided by education institutions

ARMA TR24-2013 Best practices for managing electronic messages



Another day, another standard. Let's see what this one says.
  • It could serve as a complement to ANSI/ARMA 19-2012, Policy design for managing electronic messages.
  • There's the standard definition of terms. I like nonrecord.
  • PDF/A is ISO 19005; PDF is ISO 32000-1.
  • Preserved messages should have (or be linked to) necessary metadata, such that:
    • Necessary metadata to render and make understandable content, context, use, and structure
    • Logical and physical structure remains intact
    • Business context (creation, reception, use) is apparent
    • Links and attachments are present
    • Hyperlinks are intact and docs available
    • Integrity of docs with threads, embedded files, and digital objects is maintained
    • Metadata is preserved
    • Header data is maintained and indexed for retrieval
    • Authorization is enforced
  • Electronic messages include email, forums/listservs, IM, SMS.
  • Components: addresses, conversational threads, receipts, subjects
  • Metadata is important. Management of metadata should be linked to the records retention policy, including:
    • Security and privacy policies that define retention of metadata
    • Mandating which metadata is editable
    • Specifying which metadata is part of the audit trail
    • Which metadata can be accessed by which entity
  • Separate storage of metadata makes access easier, but strips out context and linkages
  • Common metadata elements:
    • ID
    • Subject
    • Date/time sent
    • Date/time received
    • Sender/originator (X.500 format)
    • Prior originator
    • Addressees/Participants (X.500)
    • Location
    • Attachments
    • Message format
    • Message type (email, IM, SMS, etc.)
    • Message size (bytes)
    • Language
    • Electronic signature
    • Encryption
    • User-defined metadata
  • Records management metadata:
    • Records category
    • Classification date/time
    • Disposition even trigger (date or event)
    • Disposition certificate
    • Migrate date
    • Migration history (trail of migration events)
    • Retention schedule (pointer to schedule)
    • Access domains (credentials, possibly at the field -- not record -- level as per EU Data Protection Directive, HIPAA, etc.)
  • Records utilization metadata:
    • Access (ID of entity, including system)
    • Access events
    • Access event time stamp
    • Access restrictions
    • Access event detail
    • Annotation content
    • Hold (yes or no)
  • Section 4 gives us some details on managing organizational requirements. It notes that an Electronic Message Management (EMM) program should include:
    • Appraisal and identification of records vs. nonrecords
    • Auditing
    • Electronic systems/file formats/file plans
    • Legal holds and ediscovery
    • Media obsolescence; tech conversion and migration
    • Metadata
    • Preservation
    • Program quality improvement
    • Reg and stat requirements
    • Retention and disposition
    • Risk management
    • Search
    • Security, confid, privacy
    • Training
  • Section 5 is a review of Electronic Messages as Records. It references GARP, ISO 15489, and ANSI/ARMA 19-2012, Policy design for managing electronic messages.
    • Presumption of authenticity: "For records in the form of electronic messages, authentication techniques should be as technology-neutral as possible."
    • Digital signatures may be impossible to migrate. InterPARES recommends detaching the signature and adding information to the integrity metadata.
    • Drafts aren't generally records
    • Copies: "If a copy or duplicate exists that is not in support of business activities, but for mere convenience, it is not considered a record."
  • The records lifecycle:
    • Creation
    • Appraisal. Determine how to retain records. Value can be fiscal, legal, operational/admin, research/historical. EMM policy includes:
      • How and by whom schedules will be applied
      • Training programs
      • Periodic/random audit
    • Classification.
    • Disposition. Destruction or transfer. Destruction is described in ARMA's Contracted destruction of records and information media.
    • Preservation. ISO 14721; ISO 16363. Or Preserving Email by Christopher Prom or InterPARES 3 reports: Keeping and Preserving Email and Guidelines and Recommendations for E-Mail Records Management and Long-Term Preservation.
      • Native format like SMTP is best. Note: FRCP 34(b) mandates that ESI must be produced in "a form or forms in which it is ordinarily maintained or in a reasonably usable form or forms."
  • Records management tools should support email
  • SMTP is popular but might result in loss of data such as rich formatting or embedded objects. Other formats include MBOX and EML. XML is best. PDF/A for attachments. X.500 for address metadata.
  • Cloud storage. Consider:
    • Data location/jurisdiction
    • Data security
    • Legal
    • Cloud services (segregation, etc.)
    • RIM
    • See ARMA's Guideline for outsourcing records storage to the cloud and Guideline for evaluating offsite records storage facilities and Guideline for outsourcing electronic records storage and disposition.
  • Concerns include obsolescence, mobility and remote access.
  • Legal issues:
    • Holds and ediscovery
    • Statutes and regulations
    • Vital records
  • Specific business continuity plan. It provides good details.
  • Backups. References to NISPOM and NIST guidelines on sanitization.
  • Section 10 is audit and compliance.
    • Have people sign the EMM policy
    • Monitor usage
    • Train and include it in the handbook
  • Compliance metrics from:
    • Audit logs
    • Desk checks
    • Discovery drills
  • Section 11 is about security:
    • Confidentiality. Information is either public or its confidential. Confidential information either can't be transmitted electronically or must be watermarked "for internal use only".
    • Personal information. Good guidelines on legislation.
    • Encryption: secret key vs. public key
  • Section 12 is all about training and communication. Training should include: etiquette, RM practices and principles, security, confidentiality, privacy, copyright, statutory/legal requirements. Training should be evaluated.
  • Section 13 is about program improvement.
  • The appendix is a pretty good audit framework.






Wednesday, May 13, 2015

KMworld 2014 -- day 2

Let's see what the second day (Nov 6) of Kmworld brings us:


  • Social program focused on: leader engagement, resourcing, awareness within sectors, personal brand building, quick collaboration on-the-go, on-boarding and getting up-to-speed, expertise location, informal team communications.
  • Focus on "verified groups"
  • Specific strategy for Users, Groups, and Leaders.
  • Measure success across Adoption (adoption tracking, self-serve reports), engagement (quant and qual scorecards, peer comparisons, leader dashboards), value (identify and review examples of social success, link social engagement with tangible business value, collateral to debunk negative perceptions)
  • Governance model:

  • Keys to success: invest; WIIFM; measure, inform, drive; establish partnerships

  • Next up, Sara Teitelman of PACT with Using Social Innovation to Achieve our Mission:
    • NGO in DC; 3000 worldwide staff
    • Old intranet with no ownership of community or content; reliance on email for collab and knowledge exchange
    • KM2Learn -- processes and tools for knowledge transfer, learning, etc.
    • Build on Jive and replaced SharePoint 2010



  • Introduced an Innovation Marketplace
  • Lessons: viral adoption is best; Community Manager is key; community should grow; identify departmental champions early; train but have self-help; mix in some fun; promote via lots of channels: email, posters, events, training, presentations.
  • What is the Stanford Design School approach?
  • Murni Shariff on Petronas on Institutionalizing Capability Through KM:
    • Malaysia Petroleum Management (MPM) is resource owner and manager of hydrocarbon resources; 1000 staff; mainly technical groups; young staff


  • Key components:
    • Documents
      • Explicit knowledge
      • Manuals, SoPs, shared folders, DB, etc.
    • Skills
      • Training and practice
    • Experience
      • Identify trends and patterns
      • Acquired over time
      • Related to risk management, negotiation, forecasting
    • Natural talent
      • Can only be recruited
    • Relationships
      • Relationships with experts
      • Vendors, partners, divisions, etc.
    • Methods
      • Procedures, processes, workflows, etc.
  • Knowledge mapping to create and prioritize interventions
  • Important to identify who knows what
  • Institutionalizing requires People/Skills, Process, Change Management, Tools/Technology
  • Tactics:
    • Structured interviews with experts that are taped and shared, YouTube-like
      • Identify topic and SME, develop questions
      • Conduct interview
      • Digitize/verify
      • Publish video
      • Convert into elearning format
      • Track utilization
    • Seconding/apprenticeship programs
    • Field trips
    • Onboarding
  • Establish process maps including policies, procedures, methods, templates, samples
  • Success story competitions



  • Lessons Learned database:



  • Performance metrics:
    • Expert interviews -- % participation; # sessions initiated by dept
    • Success story competition -- # submissions; # winning submissions
    • Document repository -- # growth
    • Knowledge reuse -- % videos accessed; # gaps closed; # lessons learned/success stories replicated
  • Visual communication is important
  • KSF: engaging and personlized; rewards and recognition; simple yet innovative; passion; relationship building; creativity
  • Overall, very interesting.

  • I came across something by Dexter, apparently from the FTA:






  • Restructuring to 14 Global Practice, 5 Cross Cutting Themes, One common knowledge structure
  • Really focused on the "forgetting curve" for their events


  • Introduced a continuum: data - information - knowledge - wisdom - change
  • Forum2014: collaborative, bite-sized, practical, staff2staff, small groups, bottom-up, long-term
  • Good overview of how to make a knowledge conference or event practical and sticky



  • Ratings: 4 month follow up on how much your learned do you actually use; have you used what you learn (y/n)?

There were also some presentations that didn't have handy PDFs. They are all available as PPTXs.

  • Jones presented Working out loud in Shell:
    • Huge company; 92000 employees; 60 petabytes of information
    • Needed to move from "well intentioned and guided, ungoverned hobbying" to something well governed. Looked to Fluor, Schlumberger, and Cemex.
    • RoCK: Retention of critical knowledge.
    • Tools: enterprise search, communities of practice, expertise finder, content validation, single point of access, knowledge repository, learning from experience, enterprise encyclopedia, performance dashboard
  • Stan Garfield of Deloitte gives us KM Enterprise Adoption: How to Make it Stick:
    • Links to AnswerHubs resources… looks good.
    • Three goals:
      • Simple, fundamental, measurable
      • Consistently communicate and leverage
      • Widely communicate and inspect
    • Why don't people find knowledge (from Ferdinand Fournies):
      • They don't know why
      • They don't know how
      • They don't what they're supposed to do
      • They don't trust the recommended way
      • They think their way is better
      • They think something else in more important
      • There is no positive consequence
      • They think they are doing it
      • They are rewarded for not doing it
      • They are punished for doing it
      • They anticipate a negative consequence
      • There is no negative consequence for not doing it
      • There are obstacles
  • Ben Duffy, on Unum, gives on Change in Knowledge Management Implementations:
    • He gives us some interesting stuff on how to sustain change within the organization.



  • Blaire on Energizing Organizational Learning through Narrative:
    • Story is the smallest unit of knowledge; narrative is the collection of story
    • Turning experience to story is a key part of sense-making
  • Robert Kocher of Vanguard on Improving communication and search: knowledge centers without a taxonomy:
    • Use deliberate URLs
    • Use title fields
    • Put a descriptive paragraph at the top of each page
    • Create a Description metadata field
    • Create "home" pages for related content
    • Create view of recent changes
    • Metrics:
      • Daily unique visitors
      • Top pages and visitors
      • Number of queries
      • Top queries
      • Failed queries: term or phrase, percentage abandoned

Tuesday, May 12, 2015

What is the history of the RACI chart?

We see this thing all the time. Where did it come from?

First, RACI is only variant of an entire animal of similar things. Its an example of a Responsibility Assignment Matrix. Gale's "New acronyms, initialisms, and abbreviations" from 1977 lists "RAM -- Responsibility Assignment Matrix [NASA]". So maybe it came from NASA?

A 1972 book called "EDP management controls" by M.D. Wadsworth also lists RAM.

Monday, May 11, 2015

ISO 15489-1

We talk a lot about it. Here it is:



  • Based on AS 4390, Records management
  • Applies to records… but not archives. Particularly relevant is ISO 9001 and ISO 14001
  • Records management includes:
    • Setting policies and standards
    • Assigning responsibilities and authorities
    • Establishing and promulgating procedures and guidelines
    • Providing a range of services relating to the management and use of records
    • Designing, implementing and administering specialized systems for managing records
    • Integrating records management into business systems and processes
  • It lists some of the benefits for RM
  • Regulatory environment includes:
    • Statues, case laws, regulations, particularly for records, archives, access, privacy, evidence, ecommerce, data protection, information
    • Mandatory standards of practice
    • Voluntary codes of best practice
    • Voluntary codes of conduct and ethics
    • Identifiable expectations of the community about what is acceptable
  • You need effective policies; should be derived from analysis of business activities
  • Responsibilities should be listed.
  • Some decent sample policy language.
  • Records a created and used as part of business activities
  • An RM programme should include:
    • Determining which records should be created in each process and what info needs to be included
    • Determining the form and structure of created/captured records
    • Determining reqs for retrieving, using and transmitting records between process and users
    • Determining retention
    • Deciding how to organize recrods
    • Assess risks of failure to retain authoritative records
    • Preserving records and ensuring their availability
    • Complying with legal and regulatory requirements
    • Ensuring records are safe and secure
    • Ensuring records are retained for only as long as necessary
    • Identifying and evaluating opportunities for improvements
    • Creating rules for capturing records and metadata
    • Ensuring business continuity for records
  • Characteristics of a records: "A record should correctly refelct what was communicated or decided and what action was taken. It should be able to support the needs of the business to which it relates and be used for accountability purposes."
  • Records should also have sufficient metadata to retain relationships between records elements, identify the business context of the records, necessary links between records.
  • An authentic record:
    • Is what it purports to be
    • Created/sent by the person purported to create or send it
    • Created/sent at the time purported
  • "A reliable record is one whose contents can be trusted  as a full and accurate representation of the transactions, activities or facts to which they attest."
  • "The integrity of a record refers to its being complete and unaltered."
  • "A useable record is one that can be located, retrieved, presented, and interpreted."
  • A records system could consider: records system design, system documentation, training, record conversion, standards and compliance, setting retention periods.
  • Documentation should be in an "Information management strategic plan"
  • A records system should:
    • Routinely capture all records within the business scope
    • Organize records in a way that reflects the business processes of the creator
    • Protect records from unauthorized alteration or disposition
    • Function as the primary source of information about activities
    • Provide ready access to all records and related metadata
  • Implementation methodology:
    1. Preliminary investigation. Documentary sources and interviews.
    2. Analysis of business activities. Create a Business Classification System (BCS).
    3. Identification of requirements for records.
    4. Assessment of existing systems.
    5. Identification of strategies for satisfying records requirements.
    6. Design of records system.
    7. Implementation of a records system.
    8. Post-implementation review.
  • Records retention requirements:
    • Meet current/future needs:
      • Retain information concerning decisions and activities
      • Retain evidence for accountability obligations
      • Eliminate records that are no longer required
      • Retain sufficient context to judge authenticity and reliability
    • Comply with legal requirements
    • Meet current and future needs of stakeholders
      • Identify interests that stakeholders might have in preserving records beyond retention period
      • Identifying legal, financial, political, social, or other gains from preserving records
      • Following regulations
  • Techniques for capture:
    • Classification and indexing
    • Arrangement in a logical structure
    • Registration to provide evidence of existence
  • "Registration" provides evidence of capture
  • Classification provides links between records, ensures consistent naming, assists retrieval, determines security protection, provides permissions, distributes management responsibility, indicates need for action, determines retention and disposition.
  • We can get guidance from ISO 5963 Documentation -- Methods for examining documents, determining their subjects, and selecting index terms.
  • We could use codes… but we don't get guidance.
  • There are guidelines for access, tracking, action tracking, location tracking, and disposition.
  • Disposition may include: physical destruction, retention within business unit, transfer to storage area, transfer to another org, transfer to managed service, transfer to a different authority, transfer to an archive, transfer to an external archives authority.
  • Destruction should be authorized, retain confidentiality, include all copies.