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