1. ADVANCED ELECTRONIC RECORDS MANAGEMENT
July 13, 2011: Nashville, TN
Arian D. Ravanbakhsh
Office of the Chief Records Officer
National Archives and Records Administration
2. Outcomes
2
Describe the positive factors that promote collaboration between
RM and IT staff
Identify legal requirements and policies that impact Federal
information requirements for electronic records
Recognize where to insert RM requirements into the planning,
development, and implementation of information systems
Develop and implement an enterprise-wide electronic records
management pilot
Demonstrate awareness of current issues in electronic recordkeeping
as well as emerging technologies and their implications for web-
based records management
Describe best practices in ERM
3. The IT and RM Worlds
3
Effective Records Managers must understand the
technical functions and processes within an agency.
4. Overcome Barriers
4
The realities of the current
relationships between the
IT and RM worlds…
5. Integrated Information
5
There must be a multidisciplinary approach
integrating RM, IT, and the users who create the
records.
6. Problems
6
Problems generally arise
from the fact that records
management has become a
distributed responsibility
across the agency.
7. More Problems
7
IT builds the system—but does not
manage the content.
RM manages content—but the system
may be lacking some necessary tools.
8. Solutions
8
Integrate RM and IT
Ensure that electronic
records can be
located, shared, and
accessed agency-wide
Records and
information,
as well as tools, must
be
managed by RM and
IT working together
9. RM Staff Must…
9
Understand how technologies affect electronic
records
Know that they are key players
Realize that records management requires
technological skills and understanding far beyond
document tracking
10. Records Management Staff Skills
10
Records management staff should posses the same set
of skills:
Process mapping
Analytical thinking
Speaking IT’s language
Managing projects
Familiarity with the Systems Development Life Cycle
11. How Would You Define the Term?
11
RM and IT professionals use many of same words,
but they mean different things
archive
archive
13. IT and RM Connection Points
13
IT systems development
Capital planning, IT architecture, and
strategic plans (Clinger-Cohen/ITMRA)
Electronic signatures (GPEA)
Transfer of permanent electronic records
to NARA (E-Gov)
E-mail
Electronic recordkeeping
14. IT and RM Points of Disconnection
14
Different perspectives on the word “records”
Different perspectives on lifecycle
15. Building Alliances
15
No one can develop and promote a records
management program in isolation; it requires allies
Top management must be convinced that records are
essential agency assets and managing them is vital
Good communication is key to working
collaboratively across the organization
IT and RM must both meet the needs of internal and
external stakeholders
16. New Skills for Working Together
16
Electronic records management
Communication
Risk assessment and management
Business process design
Systems analysis
Requirements development
Project management
18. Recordkeeping Requirements
18
Poor documentation may result in an unresponsive
Government that cannot account for its actions
Even in the short term, lack of documentation causes
problems
The solution is to develop, implement, and enforce
recordkeeping requirements
NARA uses the term “recordkeeping requirements” to
refer to the statements in statutes, regulations, and
agency directives that specify which records are to be
created and maintained.
19. Legal Requirements
19
Federal Records Act
Clinger-Cohen Act
Government Paperwork Elimination Act (GPEA)
E-Gov Act of 2002
Office of Management and Budget (OMB)
Circular A-130
OMB Circular A-11
20. Federal Records Act (44 U.S.C. 3301)
20
Gives the Archivist of the United States the authority to
provide guidance and assistance on the management of
records.
21. Clinger-Cohen Act (40 U.S.C. 1401)
21
Requires that investments in systems include a cost-benefit
study on the use of electronic recordkeeping functions to
manage the electronic records.
22. Government Paperwork Elimination Act (P.L.
105-277)
22
Makes Government information more available electronically
and relieves the public reporting burden.
Generally, GPEA states that electronic records will be and are
being created under this Act and that, in addition to the e-
records themselves, e-records required for verification are
also being created.
23. E-government Act of 2002 (44 U.S.C. 3601)
23
Identifies initiatives to integrate agency operations and IT
investments. Eliminates redundant systems and improves
customer service.
Example: Travel systems. From independent in every Federal
agency to GovTrip
24. Office of Management and Budget (OMB)
Circular A-130
24
Requires agencies to plan for managing information
throughout its lifecycle, and to train personnel to do so.
25. Office of Management and Budget (OMB)
Circular A-11
25
Requires establishment of performance goals for IT; provides
guidance on preparing budget submissions.
Exhibit 53: Agency IT Investment Portfolio
Exhibit 300: CPIC and Business Case for Each Systems
28. Freedom of Information Act (FOIA)
28
Any person has a right to gain access to Executive
Branch agency records
Some records or portions of them are protected from
public disclosure either by one of nine exemptions, or by
one of three special law enforcement exclusions
If a FOIA request is received, you cannot destroy any
information related to the request
29. Privacy Act
29
For the purposes of the Privacy Act, a record is defined
as any item, collection, or grouping of information about
an individual that is maintained by an agency, including:
Education Medical
Criminal Employment
if that information contains any identifying information
These records need to be maintained in a secure
environment
30. Electronic Records Policy Working
30
Section 207 of the E-Government Act of 2002
Tasked NARA to lead ERPWG in writing:
Barriers to the
Effective Management
of Government Information
on the Internet and
Other Electronic Records
31. ERPWG Identified 4 Barriers
31
1. Records are not managed as business assets.
2. RM is not viewed as critical.
3. There is a lack of training, tools, and guidance for
Federal staff.
4. RM and IT disciplines are poorly
integrated in Federal agencies.
32. Solutions to Identified Barriers
32
To overcome the barriers, Federal agencies must
manage their records from the moment of creation
34. Recognize Where to
Insert RM Requirements
34
Records management
must start early—
at the concept or
planning stage.
35. Typical Tasks in the System
Development Process Lifecycle
35
System conceptualization Unit development
System requirements and Software integration and
benefits analysis testing
Project adoption and project System integration and testing
scoping Installation at site
System design Site testing and acceptance
Specification of software Training and documentation
requirements
Implementation
Architectural design
Maintenance
Detailed design
37. SDLC Phases
37
Product Plan and Initiation Phase
Concept Phase
Requirements Definition
Preliminary and Detailed Design, Development
Integration and System Test, Development, and
Acceptance
Production and Upgrades, or Retirement and
Rollover
38. Evaluating a Proposal
38
Declare documentary materials as records
Capture records in a secure repository
Organize records for efficient retrieval
Limit access to records to authorized users
Preserve records for their entire lifecycle
Allow for disposition of records based on
approved agency schedules
39. Guidance for Your System
39
Your agency is planning a new IT
system to handle its records, and
needs to include RM:
Where do you go to find out
the requirements?
Who will build them into the
system?
Are there existing COTS
packages that fit your
requirements?
40. Help from Two Sources
40
DoD 5015.2
Endorsed by NARA
Extremely technical
Provides baseline for RMA
ISO 15489
Recognized around the world
Provides information on
trustworthiness of an electronic
record
41. DoD 5015.2
41
Design criteria standard for electronic records
management software applications (RMA)
Includes mandatory and non-mandatory
requirements
Provides minimum RM requirements based on
NARA regulations and 44 U.S.C. 2902
Fluid document
Always being updated
42. Beyond DoD 5015.2
42
1. Determine ERM scope.
2. Review infrastructure/IT architecture.
3. Review agency records and information resources,
management guidance, and directives.
4. Review additional standards.
5. Review requirements.
6. Classify requirements.
7. Involve stakeholders in review.
43. Beyond DoD 5015.2 (cont’d.)
43
1. Determine ERM scope.
Ask what the system will and will not manage:
E-mail Paper
Office automation software Web content
Electronic forms
Identify and consult with stakeholders
Review existing systems to determine:
What system creates or contains records? What types of
records? What legacy systems will be integrated or
migrated?
44. Beyond DoD 5015.2 (cont’d.)
44
2. Review infrastructure/IT architecture.
Find out about:
Network servers and system software
Security
Desktop applications
Standard desktop configuration
At what level will the system be administered?
45. Beyond DoD 5015.2 (cont’d.)
45
3. Review agency records and information
resources, management guidance, and directives.
RM policies
IRM policies
Security policies
Disposition and
retention schedules
46. Beyond DoD 5015.2 (cont’d.)
46
4. Review additional standards.
Reach beyond your agency
for best practices within the
industry
Model Requirements for the
Management of Electronic
Records (MoReq)
AIIM Standards Committee on
Integrating Records
Management and
Document Management
Requirements
Reports by Doculabs on ERM,
EDM, and ECM systems
ISO 15489-1: Information and
Documentation—Records
Management
47. Beyond DoD 5015.2 (cont’d.)
47
5. Review requirements (created after steps 1–4).
Does it:
Describe a system functionality?
Express a single idea?
Map clearly to specific organizational goals?
Map directly to business processes or policies?
Describe user’s needs?
Is it:
Testable? "Keep,
Too vague?
eliminate,
Too implementation-dependent?
or revise"
requirement
48. Beyond DoD 5015.2 (cont’d.)
48
6. Classify requirements.
Assess the functionality of each additional
requirement as to whether:
The system cannot function without it
It provides significant savings in time or resources
It smoothes the path for the end user
It provides the Records Manager with useful tools
It reduces risks to future access to the information
50. Beyond DoD 5015.2 (cont’d.)
50
This step-by-step approach will allow you to develop
requirements that:
Support business process
Make best use of resources
Harmonize with current system
Produce system with tangible benefits
52. Records Management Application Considerations
52
Adequacy of existing agency record schedules
Amount of IT support available
Technical awareness (training) of agency staff
53. Piloting an RMA
53
Piloting it rather than installing it
Will allow the agency to ensure that its RM
requirements are sufficient
Is useful for complex projects where
Implementationrepresents significant change
User acceptance may be difficult to obtain
Allows for real-world testing in a controlled
environment
54. Three Phases of Pilot Projects
54
Preliminary
Conducting the pilot
Testing and evaluation
55. Defining the Purpose and Goals
Goals for overall Goals for ERM pilot
ERM initiative
55
56. Conducting the Pilot
56
Check assumptions:
Findout if your preliminary assumptions regarding
hardware, software, and service level were accurate
Develop tools to facilitate:
Documentation
Communication/knowledge transfer
Metadata processes
Select an office to serve as testers
Install the application
Document user experiences
57. Testing and Evaluation
57
Some problem areas to avoid:
Holding out for perfection—causes delays; increases costs
and the impatience of users
Too many changes based upon individual user requests with
little or no analysis of the impact of those changes
Lack of user involvement—or, on the other hand, too much
user involvement
Unrealistic schedule for product
Erroneous cost/benefit assumptions
Lack of management support
59. Where Next?
59
Component-based Architecture
A component is a self-contained business process or
service with predetermined functionality that may be
exposed through a business or technology interface.
60. Emerging Technology
60
Web 2.0 is:
A second generation of web design
Rise of social networks
Facilitating communication and collaboration
Commonly dubbed “social media”
61. RM/Appraisal Concerns
61
What constitutes the “record”
Method and frequency of capture
Applicability of existing schedules
74. What Does NARA Say?
74
Managing Records in Web 2.0/Social Media Platforms
http://archives.gov/records-mgmt/bulletins/2011/2011-02.html
Managing Records in Cloud Computing Environments
http://archives.gov/records-mgmt/bulletins/2010/2010-05.html
Report on Federal Web 2.0 Use and Value
http://archives.gov/records-mgmt/resources/web2.0-use.pdf
76. Contact Information
76
Arian D. Ravanbakhsh
Email: arian.ravanbakhsh@nara.gov
Personal: @adravan on Twitter
Notes de l'éditeur
\n
\n
When developing requirements and an overall records management program, it is necessary for an effective records manager to have the understanding of all of the functions and process within an agency. This is necessary for learning where records are created, how they are maintained, and how long they are needed.\n\nWhile we know that the RM must have this knowledge, barriers often exist between the RM and IT worlds that make it difficult to get this vital knowledge.\n
To overcome the barriers to managing information assets, agencies and programs must address the realities of the relationship (or the lack thereof) between IT and RM worlds and cultures.\n\nThe critical problem is that agencies and program are generally not managing the records from the moment they are created and in accordance with appropriate policies and procedures.\n
RM and IT are often not integrated in agencies as cornerstones of an integrated information management strategy. There is often a lack of understanding of the importance of each discipline to the other’s successful operations, particularly as agencies rely more on electronic records and the applications and systems that produce them to conduct agency business.\n\nAs IT has moved beyond data management to document management (and in some cases, has moved on to enterprise content, or knowledge, management), there is now a convergence of responsibilities between RM and IT that has not been recognized by senior agency managers. Agencies must realize that capturing the institutional knowledge of an agency demands a multidisciplinary approach integrating RM, IT, and the users who create the records.\n\nImportant to have a team approach.\n
Problems for Records Managers generally involve the fact that modern records management has become a responsibility distributed across the agency. Records Managers must expand their understanding of the current business environment beyond their experiences with paper records (which involved situations in which RM and IT integration was not critical), and focus more on the best ways to manage content in all formats (e.g., using new technologies, processes, and procedures).\n\nAlso, RM staffs generally do not have the necessary technical training and experience to talk with IT staff about their operations, and as a result, are often unable to translate records and information requirements into specific system requirements that IT can implement.\n\nRecords management responsibilities have become distributed across the agency, largely due to the rise of IT networks—every user has a “delete” key. \n
On the other hand, IT is often focused on building and deploying systems, not on managing the information within those systems as business assets that need to be maintained for as long as needed. This means that records management controls are not built into electronic systems, web sites, e-mail and office automation applications, and all other tools developed or maintained by IT. In cases in which IT is the only one involved, only the tools—not the content—are being managed.\n\nWhen RM and IT aren’t integrated, the authenticity, reliability, and integrity of records and information may be undermined, and the agency may not be able to defend its records and its RM processes when necessary. Two obvious problems arise if agencies are involved in litigation, or must produce records pursuant to Freedom of Information Act (FOIA) requests. \n
To build institutional knowledge, agencies need to integrate RM and IT to ensure that electronic records and information can be located, shared, and accessed agency-wide whenever needed. Agencies must recognize that the records and information, as well as the tools, must be managed with the RM and IT programs working together. \n\nAs noted earlier, there needs to be more collaboration between RM and IT, since the responsibilities for managing agency information assets are now shared. RM staff should be included with the IT staff during agency capital planning processes for new and enhanced electronic systems.\n
RM staff must understand how technologies affect electronic records, such as hardware- and software-dependent records.\n\nRM staff must also know that they are key players in teaching IT the value and usefulness of information. \n\nUltimately, IT and RM staffs need to understand that records management requires a level of technology comprehension beyond mere document tracking, a level which requires the expertise of both staffs.\n
It is important that all records management staff possess the same set of skills, including process mapping, analytical thinking, the ability to speak IT’s language, leading meetings and facilitating discussions, managing projects, and familiarity with the Systems Development Life Cycle (SDLC). \n\nMost important, RM staff should possess strong writing and oral communication skills, especially the ability to explain records management concepts without jargon, in a way that ties records to the business process they document. Analysis of business processes will document transactions where records can be identified and requirements can be defined.\n\nIt is essential to be familiar with terms as they are understood by IT staff, and to be able to clearly communicate terms as they are understood by RM staff.\n
Records management and IT professionals use many of the same words, but they do not always have the same meaning.This is a case of everyone speaking English, but not all using the same dictionary.\n\nFor example, the word archive:\n\n–IT—A collection of computer files that has been moved from central magnetic disk storage to another location (either for backup purposes or for storage on less expensive storage media), from which it can be recalled to online status if needed.\n\n–RM—A collection of noncurrent organizational records retained permanently. In the case of Federal records, they are removed permanently from an agency and transported physically (in an acceptable format) to NARA. At that point, NARA assumes legal responsibility for the preservation of the records because of their continuing or enduring value.\n
Record:\nIT—A collection of data items (sometimes called fields), each of which contains an item of information (such as a date or name) about a specific subject or activity. Sometimes referred to as a database record.\nRM—Any book, paper, map, photograph, database record, e-mail message, image, or other documentary material, regardless of physical form or characteristics, that is made or received by a Federal agency and is evidence of the organization’s activities, or has informational value.\nDocument:\nIT—A word-processing text file, completed form, voucher, or other representation of stored information.\nRM—Structured or semi-structured information (such as a book, memo, letter, or map) that has a predictable structure and can be accessed and read by people.\nFile:\nIT—In data-processing, a collection of records. In computer applications, an entity of information that has a unique name, a particular format, and, usually, a specific file name suffix.\nRM—An accumulation of business materials arranged according to a plan and related to each other in some way (e.g., a case file).\n\nBackup:\nIT—IT archival and tape backups—usually two types, “operational” and “project.” For operational backups, IT wants to be able to restore systems that fail and provide the restoration of the files, e-mails, and databases that are corrupted or have failed. The project backups have the same purpose, but are usually associated only with a unique system or group of systems that are themselves associated with an ongoing project.\nRM—A duplicate of a record or of groups of records used primarily for the protection of information in case of loss or destruction of the original; to be stored off-site under appropriate environmentally controlled conditions.\n
\n
Points of Disconnection Between IT and RM\nDifferent perspectives on the word “records”\nDifferent perspectives on lifecycle\n\nRM records lifecycle: the lifespan of a record from its creation and receipt to its final disposition. Usually described as having three stages: creation, maintenance and use, and disposition\n\nIT Systems Development Life Cycle (SDLC) definition: phases of development of an electronic information system\nTypical stages: initiation, definition, design, development, deployment, operation, maintenance, enhancement, and retirement\nSignificant step in several stages: the definition, development, and refinement of the data model that includes the records being created or managed\nImplications of lifecycle differences\n\nThe records lifecycle often exceeds the SDLC.\nWhen it does, the agency needs to retain the record for a period of time longer than the life of the electronic information system.\nThis presents special challenges, such as maintaining the trustworthiness of the record when migrating from one system to another.\n
In the modern office, no one can develop and promote a records management program in isolation. Overcoming communications problems is a task for allies, not rivals.\n\nIt is vital to convince top management that the records management program will be beneficial to the agency, and it is vital to get their support. Building alliances with others will go a long way toward ensuring that your records management program will succeed.\n\nGood communication is part of building alliances. Using your skills of active, empathetic listening and appropriate and timely communication, you can build an effective working relationship that maximizes your own and your allies’ resources. Your communication skills and strategies will be essential in building rapport and eliminating obstacles to effective interaction.\n\nEstablishing clear objectives and responsibilities and developing a consensus are important success factors in working in effective teams. The objective for defining responsibilities, authorities, and inter-relationships is to establish and maintain a records and information management regime that meets the needs of internal and external stakeholders.\n
Every employee needs records management competencies. A “network” approach to managing agency records and information permits each staff member’s relevant expertise and interests to be applied regarding the creation, maintenance, and use of records. For example, unless each stakeholder participates in RM, business assets can be difficult to locate, cannot easily be shared, and are at a risk of being lost. Good networks of communication are essential.\n\nThe 21st-century workplace exerts an almost constant pressure to update skills in order to keep up with careers and functions that are evolving. Career development is a necessary concern to both RM and IT.\n
\n
In conducting business, every Federal agency creates a great number of records in a variety of media. The quality of those records varies from agency to agency and program to program. If information is not captured in records that are accessible in organized files or electronic recordkeeping systems, it will not be available when needed later. Poor documentation may result in an unresponsive government, or a government that cannot account for its actions, or both.\n\nConducting Government business without adequate documentation increases the possibility that, in time, not all relevant facts will be available, or interpretations may be distorted. This is even true in the short term.\n\nNARA uses the term “recordkeeping requirements” to refer to the statements in statutes, regulations, agency directives, or other issuances that specify which records are to be created or received and maintained by agency personnel\n
\n
\n
\n
\n
\n
\n
\n
Exhibit 53 of OMB Circular A-11 allows each agency and the OMB to review and evaluate the agency’s IT spending and to compare it across the Federal Government. The Exhibit consists of four parts and captures an entire Agency IT Investment Portfolio (all IT investments).\n\nEach agency submits one Exhibit 53 to OMB with its overall budget submissions. The exhibit maps to the function of the investment, not to the function of the program or mission of the agency\n\nExhibit 300 of OMB Circular A-11 must be developed for major investments. The Exhibit 300 business case is a high- level summary of the investment’s current justification and management plans, including a project plan, benefit-cost analysis, alternatives analysis, acquisition plan, risk management plan, human resources management plan, enterprise architecture, and IT security plan. In the case of IT investments that are proposed or underway, this information is used by the operating unit, the agency’s Capital Investment Technology Review Board (CITRB), and OMB to determine whether investment funding should be recommended or continued.\n
\n
The Freedom of Information Act (FOIA) generally provides that any person has a right, enforceable in court, to gain access to Executive Branch agency records. Some agency records (or portions of them) are protected from public disclosure by one of nine exemptions, or by one of three special law enforcement record exclusions. The E-FOIA Amendments of 1996 (E-FOIA) were developed to update the FOIA and include e-records references. NARA now has an office that serves as an ombudsman for FOIA in the government, the Office of Government Information Services (OGIS). OGIS resolves disputes that arise from FOIA requests.\n
The Privacy Act (PA) seeks to ensure that when the Government collects personal information about people, the Government manages and protects that information properly. The definition of a record is different under this Act. Key points include:\n\nUnder the Privacy Act definition, a record is “…[a]ny item, collection, or grouping of information about an individual that is maintained by an agency, including, but not limited to, his education, financial transactions, medical history, and criminal or employment history and that contains his name, or the identifying number, symbol, or other identifying particular assigned to the individual, such as a finger or voice print or a photograph.” These records need to be maintained in a secure environment.\n
The Electronic Records Policy Working Group (ERPWG) was formed to meet the mandates of Section 207 of the E-Government Act of 2002 (Pub.L.107-347). NARA led the ERPWG in developing recommendations to ensure effective management of Government information on the Internet and other electronic records.\n\nThe ERPWG report, “Barriers to the Effective Management of Government Information on the Internet and Other Electronic Records,” identified four barriers faced by agencies attempting to manage electronic information.\n
There is no understanding, particularly by agency staff at the desktop, of the concept of lifecycle management that ensures that information and records will be managed effectively as business assets for as long as needed.\nRecords management is either not incorporated into business processes, or not incorporated early enough, particularly as these processes are automated. Records management is not perceived as supporting the agency mission. Instead, agencies view it as an afterthought—an administrative support function performed at the end of a particular process when the records are no longer needed for current business and are eligible for disposition.\nBecause the benefits of strong records and information management practices are not apparent to management, the records management function is one that has little clout and is not provided with the resources to achieve its goals.\nAgencies must realize that capturing the institutional knowledge of an agency demands a multidisciplinary approach integrating records management, IT, and the users who create the records and information.\n
The ERPWG submitted their “barrier report” to ICGI (Interagency Committee on Government Information). ICGI recommended a Government-wide, coordinated information and records management strategy to assist agencies in overcoming barriers and in meeting their information and records management responsibilities in the current environment.\n\nICGI’s three major recommendations are:\n1.Support agencies through effective leadership and clear records management guidance.\n2.Create the RM profile in the Federal Enterprise Architecture.\n3.Improve accountability for records management.\n
\n
Good records management and recordkeeping practices for new IT systems begin at the earliest point of development, usually in the early concept and planning stages, and continue on, through traditional Capital Planning or Systems Development processes.\n
Professional systems developers and the customers they serve share a common goal of building information systems that effectively support business process objectives. To ensure that cost-effective, quality systems are developed which address an organization’s business needs, developers typically undertake these activities\n\nThis list is based on the Center for Technology in Government report Models for Action Project: Developing Practical Approaches to Electronic Records Management and Preservation, 1998, SUNY University at Albany, and by reference to Kal Toth, Intellitech Consulting, Inc. and Simon Fraser University; the list is partly created from lecture notes: Software Engineering Best Practices, 1997\n
This is a graphic representation of the steps in the SDLC.\n
Product plan/Initiation phase: Identify and validate an opportunity to improve business accomplishments of the organization or a deficiency related to a business need; Identify significant assumptions and constraints on solutions to that need; Recommend the exploration of alternative concepts and methods to satisfy the need.\n\nConcept phase: This phase will determine whether an acceptable and cost-effective approach can be found to address the business need, with high confidence that technology can support it. Identify interfaces, data and business requirements, and basic ERM requirements. Establish system boundaries, identify goals objectives, critical success factors, and performance measures. Evaluate costs and benefits of alternative approaches to satisfy the basic functional requirements. Assess and mitigate project risks. Complete Business Process Redesign. Develop high-level architecture, process models, and data models, and a concept of operations\n\nRequirements Phase: Further define and refine the functional and data requirements. Complete component selection. Develop detailed data and process models. Define additional functional requirements that are not easily expressed in the data and process models. Further refine the high-level architecture and logical design. Continue to identify and mitigate risks. \n\nPreliminary Design: Design, develop and test the system, update plans to deploy the system. Complete business transition planning, and identify and initiate business transition activities. Hopefully, initiate the records scheduling process. \n\nIntegration and system test, development and acceptance: This phase is completed when the Technical Review Board conducts the Production Readiness Review confirming that the AIS is complete, correct, fully tested, and ready for the Deployment Phase to begin. During this phase, the records schedule should be completed and approved.\n\nProduction: At this phase, the system is certified operational and deployed in the agency for business purposes. The system should be evaluated regularly against the mandate to serve the agency’s mission and meet business needs. New systems should be developed when legacy systems cannot be successfully or effectively upgraded, and the process will begin again.\n
\n
Imagine your agency is planning a new, enterprise-wide IT system for handling all its records. You know it has to include records management.\nWhere do you go to find out the specific records management requirements?\nWho will build those requirements into the system—the system analyst? The contractor? You?\nAre there existing Commercial Off-the-Shelf (COTS) packages that can handle your agency’s requirements?\n
\n
\n
\n
The goal of this step is to gather basic information about what the system will and will not manage. It may not be practical or cost-effective to manage all the records in all formats. You should identify the various types of agency-specific records that are created and their formats. \n\nIn addition, identify stakeholders who will need to be consulted on how the system will create, capture, maintain, disseminate, and dispose of records generated in the course of agency business. \n\nFinally, identify your agency’s existing systems. Most organizations have existing systems that create or store electronic records, and most of these are not designed to provide basic recordkeeping functionality, such as file plan organization and disposition. Once these systems have been identified, the decision to migrate or integrate them into an ERM system may generate additional agency-specific requirements. Review existing systems \n
Agencies should have an enterprise-wide IT architecture that provides the baseline for the existing infrastructure and lays the foundation for future improvements. Any ERM system must fit within the existing infrastructure, and the organization must incorporate ERM into the enterprise architecture.\n
\n
\n
\n
\n
\n
\n
\n
\n
A successful pilot test will allow the agency to ensure that their current records management requirements are sufficient for a software solution.\nThe pilot allows the agency to test the system design in a real-world, controlled environment with actual production users performing their normal routines and tasks. This permits the validation of the system design, as well as the identification of any modifications to procedures that the solution may require. Pilots are particularly useful for complex projects such as ERM, when the software is new (either to the agency or the market), implementation represents a significant change in the way staff works, and user acceptance may be difficult to obtain. A pilot will provide the practical experience necessary before introducing an ERM solution agency-wide.\n
\n
Defining the purpose and goals is essential for the success of the pilot. These are not the same as your goals for the overall agency ERM initiative. For the pilot, the goals should be related solely to the product under evaluation. \n
\n
Keep in mind that failure of the pilot is not always a negative. The goal of a pilot is to evaluate a product, and to develop an objective analysis of the results and an assessment as to how to, or even whether to, proceed with full deployment of that product. \n\nIf the decision is made to proceed with an ERM system, the pilot process provides several key outcomes:\n\nBetter-trained staff in terms of records management processes and understanding as to the importance of ERM to the agency\nWell-developed technical, managerial, and production processes\nAn improved implementation plan\nRevised cost estimates and a realistic schedule for agency-wide deployment\nSupport of management and users\n