Manual for the Design and Implementation of Recordkeeping Systems (dirks)

Вид материала

Содержание

Example: Consequences of not keeping records
Analysis of business activity
Example: The Personnel function

Подобный материал:

1 ... 16 17 18 19 20 21 22 23 ... 71

Summary of Step C

Step C is concerned with finding and documenting the recordkeeping requirements that exist either for your whole department/section, or in relation to particular functions, activities, processes or business systems. These may be broad requirements relating to the jurisdiction or environment your department/section operates within, or may be specific to your particular business. Such requirements may be explicit or implicit.

Documentary sources and interviews provide information on recordkeeping requirements. You need to collect and analyze these sources so you can identify your:

business needs
regulatory obligations, and
community expectations.

You also need to:

define the type of requirement (ie what it is requiring you to do in terms of creation, capture, disposal, access, form, content and/or quality) so that you can plan whether and how to satisfy it
map requirements to your functions and activities (your BCS if you have completed Step B) so the business context of the requirements is clear.

If there are recordkeeping requirements your department/section does not wish to satisfy, perhaps due to cost or other difficulties they impose, you will need to identify the exposure to risk if these evidential requirements are not addressed. The main product of Step C, then, is set of requirements the department/section has agreed to meet (which may be limited according to the scope of your project).

Why should you do Step C?

Opportunities from knowing your requirements

Step C is a crucial step in designing a recordkeeping system. If you know exactly what your recordkeeping requirements are you can ensure:

you make effective use of records management resources
your department/section is meeting its requirements and conducting business in line with best practice.

Step C can assist you to obtain:

an understanding of the requirements to create and keep records as evidence in relation to specific business activities
an appreciation of the level of exposure to evidence-related risks (such as failures in accountability, legal action)
a basis for designing tools that can facilitate good recordkeeping
a benchmark for assessing your current systems (Step D)
a basis for determining the range of recordkeeping strategies which best enable your department/section to meet their recordkeeping requirements (Step E), and
the basis for developing functional specifications for recordkeeping systems, including software products (Step F).

Consequences of not knowing your requirements

If your department/section is not aware of its recordkeeping requirements it might:

unnecessarily keep records it doesn’t need to maintain, which is inefficient and costly
fail to create records that it is required to keep, or
keep records for insufficient periods of time, which will expose the office to certain risks and prevent business being conducted effectively.

^ Example: Consequences of not keeping records

If a corrective services agency did not keep records of prisoners, they would be compromising their ability to meet their core functions and would expose themselves to significant adverse community reaction, as well as compromising public safety.

How is Step C scalable?

Relate to the project scope

Step C is essential to most DIRKS projects because it provides the benchmark to measure systems against. The only time it need not be completed is if you already know your department/section's recordkeeping requirements in detail and know the risks of not meeting them. However, Step C can be scaled down for particular projects. See Doing your DIRKS project for how Step C specifically applies to particular projects.

Existing frameworks to map requirements to

You may already have frameworks in existence derived from Step B: ^ Analysis of business activity or from existing recordkeeping tools such as classification schemes or retention schedules. These will give you the structure to map your recordkeeping requirements to, so you can scale down your examination of recordkeeping requirements to a particular function.

^ Example: The Personnel function

In Step B: Analysis of business activity there was reference to the Australian Local Government council that had decided to analyze the business conducted within their human resources function. Their aim was to improve their current practices and to identify their recordkeeping requirements and determine their levels of compliance. They chose to use the function of PERSONNEL and related activities from the Keyword for Councils thesaurus as a basis for their business classification scheme.

In Step C they could focus on finding recordkeeping requirements relating directly to the personnel function, or broadly affecting it, and exclude the requirements that did not have implications for this function.

When frameworks do not exist

As discussed in Step B: Analysis of business activity, if your department/section's core functions are not covered by a classification scheme of any kind, it is not advisable to try to analyze a core function or system in isolation. You should at least roughly map your core business functions and activities and consider issues that may affect them before trying to concentrate on the recordkeeping requirements relating to one function or system.

The reason for this is that:

you need a broad perspective of the boundaries of the function or system and how it relates to, and impacts on, other business activities being performed
you may discover when taking a broader view that there are other areas of high risk that may warrant priority in subsequent stages of the design and implementation process. These areas may correlate to particular recordkeeping systems, business activities or business units.
if you analyze one function or system in isolation, without a broader map, you may inadvertently cross boundaries of other functions and may miss requirement and risk identification. These omissions may force you to revise your analysis later.

See Sources for Step C for more information about other sources that can save you time and effort in your project.

Blog