3.2 E-records management
3.2.1 Integration of e-record-keeping functionalities into business process systems
E-record-keeping functional requirements are about the organisation’s focus on the outcomes required to ensure records are managed properly. The choices made on how the e-records are
52
managed will influence the extent to which each organisation must consider the amendment for inclusion within a business system (Government records 2016; ICA 2008). Organisations and institutions should understand the basis for designing systems that will capture and maintain e- records and the benchmark for measuring the performance of the existing systems. Similarly, the organisation should ensure that user requirements including user acceptance are considered because such requirements are significant factors in successful implementation. The Parkerian Hexad Model asserts that an organisation should focus on their people (personnel) for they are the creators, users, and maintainers of the system. The systems should be able to link e-records to business activities, retain records of past actions and fix the content, context, and texture over time;
thus, helping in maintaining records authenticity, reliability, integrity, availability, confidentiality, usability, and accessibility at any time as discussed in section 3.3 and 3.6 (National Archives of Malaysia 2011; Parker 2002; Upward 2001) .
The design, development and implementation of a records management systems may involve a series of phases. For example, the Design and Implementation of Record-keeping Systems (DIRKS) which originated from the cooperation activities between the State Records Authority of New South Wales and the National Archives of Australia that provides an eight-phase instruction including preliminary investigation, analysis of business activity, identification of record-keeping requirements, assessments of existing systems, strategies for record-keeping, design of a record-keeping system, implementation system and post-implementation (State Records Authority of New South Wales and National Archive of Australia 2001; 2003). It is worth to note that because business process and records systems are not static, the phases may be revised periodically. According to ICA (2008), designing, developing and implementing of a system commence with planning and establishment of a project charter (this phase involves but is not limited to identifying and validating an opportunity to improve business accomplishments of the organisation or deficiency related to a business need, identifying significance, assumptions and constraints on solutions to the need and recommending the exploration of alternative concepts and methods to satisfy the need), which may be initiated as a result of business improvement activities, changes in business functions or advances in information technology, or may arise from external drivers such as laws and policies, the establishment of new strategic directions for the government or the pursuit of opportunities presented by external organisations. Planning is the second phase where the needs of the system and proposed concepts for the new or modified system are further
53
analysed in order to inform the development of a ‘vision' of how the business will operate once the approved system is implemented — other high-level requirements are those of security (that the nature of the security certification and accreditation activities and record-keeping are further refined based on threat and risk assessments). Thirdly, the requirement analysis phase is where all functional user requirements are formally defined and delineated in terms of data, system performance, security and maintainability requirements for the system. At this phase, all the requirements are defined to a level of detail sufficiency for systems design to proceed. All requirements should be measurable and testable and relate to the business need or opportunity identified in the initiation phase. Documentation related to user requirements from the planning phase are used as the basis for further needs analysis and the development of detailed user requirements. Consequently, in this phase, the system is defined in more detail concerning system inputs, processes, outputs, and interfaces. The phase also focuses on determining what functions must be performed rather than how to perform those functions.
The fourth phase called design is where the physical characteristics of the system are specified, and detailed design prepared. Here, the operating environment is established, significant subsystems which consist of inputs and outputs are defined, and processes are allocated to resources. Everything requiring user input or approval is documented and reviewed by the user.
Organisations also must account for the functional requirements for record-keeping and other related requirements for instance management, procedural and technical that would have been identified in the previous requirements analysis stage. Similarly, record-keeping design specifications should be woven seamlessly into the physical and logical design specifications (inclusive of data architecture and data models for the system). The fifth phase which is implementation- the activities of this phase translate the system design produced in the design phase into a working information system capable of addressing the system requirements. The implementation phase contains activities for building the system, testing the system and conducting functional requirements qualification testing to ensure the system functional processes satisfy the functional process requirements. An important step prior to installation and operating the system in a production environment is to subject the system to certification and accreditation activities. Maintenance becomes the sixth phase where the system is monitored for continued performance in accordance with user requirements and required system modifications are incorporated. The operation is assessed if the system can be effectively adapted to respond to an
54
organisation’s needs through in-process reviews to determine how the system can be made more efficient and effective. This means changes to the record-keeping requirements (that is driven by new laws, changing business requirements in the design of business process among others) must be accommodated in the monitoring, and change process activities undertaken during this phase.
Thus, new users will require training and ensuring that user needs are met, and the system continues to perform as specified in the operational environment. When the modifications are changed and identified as necessary, the system may re-enter the planning face.
Review and evaluation, which is the last phase as explained by ICA (2008) occurs in two sub- phases. The first is the perspective of the business system itself. In-process reviews are conducted at each phase of the systems development life cycle to ensure that the activities undertaken in any given phase achieve their pre-defined goals and meet their performance targets. Such in-process reviews must be supported by agreed performance measures and assessment methods. For example, if the capability of the system to generate, capture and manage records is to be measured, then performance measures for record-keeping and methods for carrying out assessments of record-keeping capability must be developed, applied and wherever possible, integrated in the performance measures and assessment methods employed in the in-process reviews conducted at each phase of the systems development life cycle. The second perspective is the methodology employed to develop the systems- this must be effective, efficient, and complete among others.
The evaluation of the methodology can occur at the conclusion of the business systems project or as part of the overall general assessment of the development and management of business systems.
Again, record-keeping considerations, including performance measures and other criteria, must be developed and integrated into the tools and techniques employed to assess business systems development generally.
Despite systems being in place in many organisations, a study by IRMT/IDRC (2011) established that in ‘too many' cases ICT systems were being introduced without incorporating the essential processes, controls, and standards needed to regulate the creation, capture, access, and safeguards on a long-term basis of electronic/ digital records. ICA (2008) advices that e-records management systems must capture the content, structure, and context of e-records to ensure they are reliable and an authentic representation of the business activities or transactions in which they were created or transmitted. Moreover, e-records systems should be integrated with business applications that
55
generate e-records, so that the records can be captured within the e-records management systems.
The e-records systems should also provide for possibilities of access options to e-records offline and online (Ambira 2016). These systems which are primarily software-based methodologies used to manage e-records should also be guided by organisational business procedures and activities (Ngoepe 2014). System software may include the capabilities of integrated document management system, records information management software, document imaging system, digital repositories, electronic document and records management system (Codafile 2015; New South Wales Government 2012).
Australian National University policy (2015) and Moi University ICT policy (2011) explain that universities’ systems should include among others student administration system, research data management and repository system, hostel booking management system, examination and clearance system, integrated financial management system, electronic repository, human resource management system, health records management information system, library information system, and research information system. Therefore, e-record and information systems should ensure e- records are accessible, available and always remain unchanged to enhance accountability, integrity confidentiality and control to mention a few (Omotosho and Emuoyibofarhe 2014).
3.2.2 Policies, guidelines, regulations, and standards in records management and security