Maintenance

EDBOK Guide

What is Maintenance?

Maintenance as a process represents a continuing activity to sustain the production system throughout its operational life, covering update through decommissioning.

Maintenance activities include those necessary to operate, correct faults, and address enhancements in a production system that includes hardware, application software, proprietary software or a combination. It also includes the documentation of these processes.

Processes

An operational environment consists of all elements that ensure the smooth running of all business processes. These processes and their maintenance involve all software application and their supporting structure, which may be computerized or human.

Included in maintenance elements are:

• The application, including operational code, documentation of processes, instructions to operators with error conditions.
• Operational staff that may need to take an active role in starting applications, as opposed to automated start, or provide responses that cannot be automated.
• Supporting staff who responds to questions and problems. This is likely to be a layered approach, with a Help Desk in their predefined role as the first line of support performing triage. Secondary support may be the staff with access to documentation to explain the problem. If they cannot respond, a third level includes application specialists and developers.
• Hardware, including printers, inserters, finishing and mailing equipment present a more nuanced problem. They represent mechanical devices requiring regular maintenance beyond the remainder of the Information Technology universe. Where some devices have an MTBF, Mean Time Between Failures, that is measured in years and may last longer than the expected utilization of that device, mechanical devices usually require attention based on usage and time.

The Lifecycle Effect

Maintenance requirements, while always present, are not static. Applications, software, and the business processes that support them move in lifecycles, some longer than others. To ensure that all maintenance requirements are met the business objectives for maintenance operations must be clear. Attaining the business objectives is more important than delivering every technical function, but it is necessary to include the following items in maintenance objectives:

• The project parameters – longevity, start and end dates.
• The application and archiving strategy, which must include what data retrieval is required (not necessarily caused by a disaster).
• Methods for continuing upgrade and correction.
• The standards that would set a future disposition date.

The maintenance process must be structured to ensure that every facet is documented and managed. This includes:

• Change requests and controls, covering:
• the system (with underlying software and hardware),
• the applications, and
• the documentation that will be updated.
• Change testing with incorporation into the operation.

While in theory every process should work perfectly, in reality controls are required to ensure that maintenance is viable. Common controls include:

• Version controls – particularly where multiple versions are in use simultaneously, either on the same or separate platforms, with their differences identified and maintained.
• Usage transition controls between versions, so that older versions can be decommissioned.
• Compatibility – forward and backward. While newer versions may have additional capabilities. Though upward compatibility would seem reasonable, there should be no assumption that all the capabilities in an older version will be ported to the new one; upward and backward compatibility must be verified. In addition, no assumption can be made that new functionality will be retrofitted to earlier versions.
• Compatibility of all facilities carried upward with the older version.
• Help support to cover all versions in operation.

When Does Maintenance Happen?

Maintenance may be required for many reasons, from a failure in a specific point in the process to undefined failures. To ensure acceptable performance, operations may require maintenance on any single process or group of linked processes on a regular basis. Separately, performance systems may have maintenance points designed into the Lifecycle. Those maintenance points may be called out in a response or process delivery agreement such as a Service Level Agreement (SLA).

To perform an analysis of identified problems that trigger maintenance operations, especially when a problem is not classified as a true failure, requires some additional tools. They include:

• System Metrics and Key Performance Indicators selected by the installation to represent the performance characteristics most important to management. These may be generated automatically based on the more detailed measurements below or prepared as part of a summarized report.
• Support monitoring utilities to measure operational performance. Additional equipment based on the results will result in a new set of measurements. With measurement, load balancing is possible.
• For processors this usually represents utilization and response time.
• For printers this represents up time, utilization and throughput,
• For ancillary devices such as storage mechanisms, traffic (quantity and size) and response time are measured.
• System Availability reports provide the usable hours, identifying failures and repair activity. They may also provide business metrics such as time from job arrival to delivery to its final process.
• Job tracking, audit and reconciliation should be addressable from the statistics.
• Process defects should be identified and followed, usually in a report that lists these problems with a target resolution date.
• Review meetings with suppliers’ service organizations to address any problem and performance issues.
• A report similar to the defect entries to inform follow-up meetings.
• Recommendations.

Documentation Support

Documentation Maintenance must be part of any operational plan.

• Developing and updating documentation in a reliable manner, ensuring that changes to the system or application are entirely mirrored by the documentation at time of implementation is essential for proper operation.
• Ensuring that the documentation accessed matches the version in operation for each environment. Where multiple versions are active, identification is essential.
• Ensure this documentation is available to the Help Desk and searchable.

Problem Resolution Support

Support must be part of any operational plan. Designated support normally takes the form of a Help Desk operation with access to all required environmental information and documentation, plus a track of past problems. Once resolved, each problem and resolution must be documented, available for review by the Help Desk staff, and usually review by the users. Expert advice should be available on call.

Training Support

Training and scheduling to support the changes must be put in place.

• A prerequisite: maintenance must assume that users attain self-sufficiency; therefore a training plan must be implemented before going live.
• Quality documentation allowing trainers to be self-sufficient to perform knowledge transfer improves the prospect of success.
• New business opportunities and/or issues must be documented as applications go into production.
• The operational environment must be prepared for new applications.
• The Help Desk must have a process for resolution.

Equipment Maintenance

Equipment Maintenance is distinct category. It is the glue to the entire operation; it is also the one area that management will immediately trace back to when a failure occurs. It is often contracted to the manufacturer, supplier, or certified 3rd party.

The class of maintenance depends on the device:

• On failure: Relates to devices with a Mean Time to Failure (MTTF) that exceeds the useful life of the device.
• Preventive Maintenance: Scheduled actions based on usage and/or elapsed time. This equates to the actions that car manufacturers recommend for your automobile. Today, production printers must be in this category.
• Predictive Maintenance: The most recent approach, it requires evidence gathering and sophisticated assessment to determine when to take action. This is more likely to be used in factory maintenance of critical machinery.

There are known strategies to avoid disruption:

• Assume there is sufficient equipment during planned maintenance, the strategies reflect unexpected outages.
• Failover or fallback – a planned procedure that supports the use of secondary equipment. An essential component is continuing access to the data to ensure continued operation.
• Secondary equipment may work at a degraded level. The decision to use this path is based on the economics of a possible outage.
• How much will it cost in lost revenue, damage to the image of the corporation or government and the cost to recover the operation?

Cost management and budgeting is an integral part of the tactical and strategic activity to ensure the operation meets the goals set out by management.

• To bill users you need the ability to track usage, agreed upon standards and where possible, incentives to drive workloads to light periods. This approach should address Service Level Agreements (SLA), which should pay a premium for guaranteed service.
• In print, supplies create an additional component. Whether it is the printer consumables such as inks, toners or ribbons, or the distribution elements such as paper, envelopes, inserts and the postage process, these costs represent a major expenditure that require detailed accounting and attention.
• Warehousing the supplies and distribution elements is a major activity, often taking space that is multiple times the operational printer area.

Software and Application Maintenance

Upgrade of the processes is a recurrent activity. Whether for the underlying infrastructure or the business application, the ability to make changes without impacting production is a must. To ensure this is possible there should be a test environment mirrored on the production that can simulate the operations.

• Changes range from application updates to regulatory changes that have mandated “go live” dates.
• In print and on the web, updates may address marketing tailored to customers. These include adding color, messaging, forms replacement and rebranding.
• Tests range from unit/component modification, which will compare the current activity against changes through a full test. A full test must cover anticipated volumes.
• Stress tests are essential where changes could generate loads for which the environment was not designed.

Improvements in production processes should be part of maintenance:

• automation of various steps currently performed manually,
• continuous improvement, lean or Six Sigma goals to eliminate waste and improve efficiency respectively, and
• adding controls to print output such as bar codes for integrity improvement to QR codes to encourage customer action.

Decommissioning

Decommissioning an application or system should invoke a formal process that must cover:

• the organization’s current needs, usually set by Executives,
• planning for the possible disruption to current users on the system being decommissioned,
• where existing capabilities will be handled; some users may lose flexibility such that they demand the continuation of the older system/version,
• continuation - a costly process with duplication not only in staffing but possibly in data, which is generally unacceptable,
• recognition and response to relevant legal statutes to ensure that the data and access is maintained through the normal end of life should there be active litigation,
• housekeeping for all administrative activities included in the maintenance of the system being decommissioned,
• necessary material removal,
• cancellation of access,
• unique items, particularly in legacy applications that were not subject to current standards during development; a particular consideration that arises is the staff that built the system without full documentation standards in place may have left the operation,
• transition to the new environment / system; this new system may be an existing application that was run in parallel,
• data management and transfer,
• assurance that users can transfer to the new environment with procedures to assist the transfer, and
• documentation relating to the transfer provided.