Saep 1050

Engineering Procedure
SAEP-1050 26 October 2005

Guideline for Disaster Recovery Plan
Development for Decision Support System
Process Control Standards Committee Members
Alqaffas, S.A., Chairman
Al-Assiry, N.Y., Vice Chairman
Al-Ansari, J.A.
Al-Awami, L.H.
Al-Bawardi, K.M.
Al-Brahim, R.A.
Al-Eisa, J.F.
Al-Ghamdi, H.M.
Al-Khalifa, A.H.
Al-Marhoon, W.K.
Asiri, B.M.
Busbait, A.M.
Chen, G.C.
Dunn, A.R.
Fadag, I.H.
Grainger, J.F.
Green, C.M.
Hirezi, G.J.
Jansen, K.P.
Rajab, A.A.
Rambo, Z.A.
Trembley, R.J.
Saudi Aramco Desktop Standards

Table of Contents
1 Scope............................................................. 2
2 Conflicts and Deviations................................ 2
3 Applicable Documents,
Acronyms and Definitions.............................. 2
4 Responsibilities.............................................. 5
5 Instructions.................................................... 5
Appendix A - DSS Applications' Architecture..... 10
Previous Issue: 31 July 2000 Next Planned Update: 1 November 2010

Revised paragraphs are indicated in the right margin Page 1 of 10
Primary contact: Hussain A. Zahir on 873-1153
Alternate contact: Rayan H. Hafiz on 873- 7040
Document Responsibility: Process & Control Systems Dept. SAEP-1050
Issue Date: 26 October 2005 Guideline for Disaster Recovery Plan
Next Planned Update: 1 November 2010 Development for Decision Support System
1 Scope
1.1 Introduction
This Saudi Aramco Engineering Procedure (SAEP) provides guidelines for
Disaster Recovery Plan Development for Decision Support Systems (DSS).
1.2 Definition
This procedure establishes a guideline that identifies the resources, actions,
tasks, and data required to develop a plan for the recovery process of a Decision
Support System (DSS).
1.3 Purpose
This procedure sets forth instructions required to develop a well- documented
plan to make sure it follows a consistent format and allows for future
maintenance of the plan in order to minimize potential economic loss and
decision-making during a DSS disastrous event.
Saudi Aramco will implement DSS in several different sites that vary in their
Process Automation configurations and roles. Accordingly, this document'
scope is written broad enough to guide each DSS site to develop an effective
disaster recovery plan.
1.4 Timing
Operating organization shall have developed a Disaster Recovery Plan for all
existing DSS infrastructure in their facility as well as shall update this plan to
reflect newly installed DSS components within three months of DSS startup or
upgrade.
1.5 Application
The Disaster recovery plan which based on this procedure is required for all
Aramco facilities with process automation infrastructure.
2 Conflicts and Deviations
See SAEP-302
3 Applicable Documents, Acronyms and Definitions
3.1 Applicable Documents
SAEP-302 Instructions for Obtaining a Waiver of a
Mandatory Saudi Aramco Engineering
Requirement
3.2 Acronyms
DSS - Decision Support System
IT - Information Technology
Page 2 of 10
P&CSD - Process and Control Systems Department

SAEP - Saudi Aramco Engineering Procedure
SAPMT - Saudi Aramco Project Management Team
3.3 Definitions
DSS: the Decision Support Systems (DSS) is an application and integration
architecture that have the ability to collect and transform raw data and
information to KPIs, meta data and added value data that are used by a set of
analysis and modeling tools with the capabilities of predication, knowledge
management and integration to provide web based decision dashboard, self
generated advisories and execution templates in fully automated electronic
environment. Following are the applications under the DSS scope grouped by
business layer. Any application in this list is a component of DSS by itself
(Appendix A is showing the DSS Applications Architecture diagram):
• Manufacturing Management Layer:
1. Archiving of Operations Management Application
2. Knowledge Elicitation and Capturing
3. Quality Management Application
4. Mass/Energy Balancing and Reconciliation
5. Environmental Management Application
6. Advanced Process Control (APC) KPIs
7. Real-Time Optimization (RTO) Advisory
• Production & Asset Management Layer:
1. Energy Management application
2. Performance Management Application
3. Oil Movement & Tracking Application
4. Operator Training Simulation Application
5. Expert Operation Assist Application
6. Model based Fault Diagnostics
7. Reliability and Asset Management Application
8. Safety Management Application
• Margin & Supply Chain Management Layer:
1. SAP Maintenance KPIs
2. SAP Cost KPIs
Page 3 of 10
3. Planning & Scheduling Applications

4. Manpower KPIs
5. Cost Tracing & Activity Based Costing (ABC)
• Executive Disaster Support Layer
1. DSS Advisories, Decision Window & Execution Template
2. Web-Based Dashboards & User Interface
Disaster: Any event that creates an inability on an organization part to provide
critical business functions for some predetermined period of time.
Disaster Recovery: The ability to respond to an interruption in services by
implementing a disaster recovery plan to restore a DSS' critical operation
functions.
Disaster Recovery Plan: The document that defines the resources, actions
tasks, and data required to manage the business recovery process in an event of a
DSS operation interruption. The plan is designed to assist in restoring the
operation process within the stated disaster recovery goals.
Operation Interruption: Any event, whether anticipated or unanticipated
which disrupts the normal course of DSS operation.
Risk Assessment: The process of identifying and minimizing the exposures to
certain threats, which a DSS may experience
Hot Site: An alternate facility that has the equipment and resources to recover
DSS functions affected by the occurrence of a disaster. Hot-sites may vary in
type of facilities. The location and size of the hot-site will be proportional to the
equipment and resources needed.
Warm Site: An alternate processing site, which is only partially equipped as
compared to Hot Site.
Operating Organization: The department responsible for operating the facility
sometimes called Proponent.
Operator Interface: The set of Man Machine Interface, such as, CRT,
keyboard, touch screen, track ball, annunciator panel, etc., used by the operator
to operate the process.
4 Responsibilities
4.1 Process and Control Systems Department (P&CSD)
Responsibilities include:
a) P&CSD shall continue to evaluate tools/technologies, which will help to
facilitate resumption and continuing enhancement of the plan.
Page 4 of 10
b) P&CSD shall revise and update this procedure through feedback from DSS
facilities to make sure this procedure is comprehensive and up to date.
c) P&CSD shall define and identify the criticality and severity level of
loosing the DSS application.
4.2 Operating Organization
a) Operating organization shall use this SAEP to develop a disaster recovery
Plan for Decision Support Systems at their facility.
b) Operating organization shall provide P&CSD with all new findings that
are not included in the instructions section in order to update this
procedure.
4.3 Information Technology (IT)
a) IT shall continue to evaluate tools/technologies, which will help to
facilitate resumption and continuing enhancement of the plan.
b) IT shall provide PCSD with all new findings that are not included in this
plan in order to update this procedure to make sure this procedure is
comprehensive and up to date.
5 Instructions
The following steps describe how to develop a recovery plan for Decision Support
System (DSS).
5.1 Form a Disaster Recovery Planning Team
A team shall be appointed to manage the development and implementation of
the plan. The planning team shall include representatives from all functional
areas pertaining to the DSS. Key team members shall include DSS support
team, operations, engineering and maintenance. One of the important
responsibilities of this team is to define the scope of the plan.
5.2 Conduct a risk assessment
It is important to assess the impacts and consequences on each functional area of
the facility resulting from loss of DSS information and services associated with
several disaster scenarios, including natural disasters, technical and human. The
risk assessment process shall also evaluate the safety of critical documents and
databases.
DSS Applications' levels of criticality are assumed on a scale from 1 to 10 with
10 as the most critical. Their criticality is as per the following:
Page 5 of 10
Application Degree of Criticality

(Out of 10)
Archiving of Operations Management Application 9
Knowledge Elicitation and Capturing 8
Quality Management Application 7
Mass/Energy Balancing and Reconciliation 7
Environmental Management Application 7
Advanced Process Control (APC) KPIs 6
Energy Management application 6
Performance Management Application 6
Oil Movement & Tracking Application 6
Model based Fault Diagnostics 6
Reliability and Asset Management Application 6
Safety Management Application 6
DSS Advisories, Decision Window & Execution Template 6
Web-Based Dashboards & User Interface 6
Real-Time Optimization (RTO) Advisory 5
Expert Operation Assist Application 5
Operator Training Simulation Application 4
Planning & Scheduling Applications 4
Manpower KPIs 4
SAP Maintenance KPIs 3
SAP Cost KPIs 3
Cost Tracing & Activity Based Costing (ABC) 3
5.3 Explore and evaluate all recovery strategies

The most practical options for DSS operation in case of a disaster shall be
researched and assessed. It is significant to consider all aspects of recovering a
DSS application such as:
5.3.1 Databases and other data repositories
5.3.2 Software
5.3.3 Hardware
5.3.4 Network
5.3.5 Service recipients
5.3.6 Key personnel who operate and support the DSS
5.3.7 Documentation, Reference Manuals
5.3.8 Other processing operations
5.3.9 Access control list(s) and security privileges
Page 6 of 10
Depending on the outcome of the assessment of the above components

of DSS, recovery alternatives may include:
a) Hot Site, which is an alternate facility that has the equipment and
resources to recover the business functions affected by the
occurrence of a disaster.
b) Warm Site, which is an alternate facility partially equipped
c) Quick shipping plans for vendor supplied materials and services.
d) Off-site backup of DSS software
e) Identify different backup strategies including mirroring and
clustering.
f) Capacity requirements for each alternative in terms of software or
hardware
g) Combinations of the above
5.4 Perform Data Collection
It is highly recommended that pre-formatted forms be designed to make data
gathering process easy. Recommended data gathering and documentation
includes:
5.4.1 Computer hardware and software inventory
5.4.2 Software and data files backup/retention schedules
5.4.3 Communications Inventory
5.4.4 Documentation inventory
5.4.5 Critical telephone numbers
5.4.6 Backup position listing which is a list of alternative personnel to cover
for recovery team in case the primary person is unavailable
5.4.7 Inventory of forms, master vendor list, master call list, telephone, office
supply, off-site storage location.
5.4.8 Other materials and documentation
5.4.9 Interview personal at operation facilities and evaluate the current
procedures practiced
5.5 Organize and document a written plan
5.5.1 Before proceeding with documentation of the plan, an outline of the
plan's contents shall be prepared to steer the development of the detailed
procedures. The outline can ultimately be used for the table of contents
after final revision. This approach helps organize detailed procedures,
Page 7 of 10
identify milestones, avoid repetition, and provides a road map for

developing the procedure.
5.5.2 In order to make sure that the disaster plan follows a consistent format
and allows for future maintenance of the plan, a standard format shall be
developed to facilitate the writing of detailed procedures and the
documentation of other information to be included in the plan. The plan
shall be thoroughly developed, including all detailed procedures to be
used during all stages of the disaster recovery plan. Furthermore, the
procedures shall account for ways to maintain and update the plan to
reflect any significant changes pertaining to the plan. The procedures
shall allow for a regular review of the plan by the identified key
personnel within the organization.
5.5.3 The structure of the plan's document shall use a team approach. In other
words, specific responsibilities shall be assigned to the appropriate team
for each functional area. Functional areas include administrative
functions, facilities, logistics, user support, computer backup, restoration
and other important areas in the organization.
5.5.4 Each team has specific responsibilities that must be completed to ensure
successful execution of the plan. The teams shall have an assigned
leader and an alternate in case the team leader is not available. Other
team members shall also have specific assignments where possible.
5.6 Develop testing criteria and procedures
Test criteria and procedures shall be developed to assure that all necessary steps
are included in the plan and will demonstrate its ability to recover. It shall
determine the feasibility and compatibility of backup facilities and procedures
and identifying areas in the plan that need modification. In addition, testing will
not only provide training to the team leaders and team members; but also,
provide motivation for maintaining and updating the disaster recovery plan
regularly.
5.7 Test the Plan
After the testing procedures of the disaster recovery plan have been completed, a
structured walk-through test shall be conducted as an initial test of the plan.
This will ensure that telephone numbers, reference manuals, equipment are
correct. In addition, it will provide additional information regarding any further
steps that may need to be included, changes in procedures that are not effective
and other appropriate adjustments. Results of the initial test shall be used to
update the plan. It is highly recommend that initial testing of the plan be done
after office business hours to minimize disruptions to operations. After the
walk-through test, all recovery scenarios, procedures and strategies for DSS
shall be tested.
Page 8 of 10
5.8 Approve the plan

Once the disaster recovery plan has been written and tested, plant management
shall approve the plan. Ultimately, it is management's responsibility that the
organization has a documented and tested plan.
5.9 Review, Update and Test the updated plan
Review, update, test, and approve the plan annually or whenever changes to
DSS take place, documenting such reviews in writing.
Revision Summary
26 October 2005 Major revision.
Page 9 of 10
Appendix A
DSS Applications' Architecture
Web Based Dashboards User Interface

DSS Advisories, Decision Window and Execution Templates
Planning
SAP Cost KPIs Manpower KPIs Cost Tracking/ABC
Scheduling
SAP Maintenance KPIs
Safety Management Reliability Management
Model based
Oil Movement Management Expert Op Assist
Fault Identification
EQ. KPIs & FT_ ID Energy KPIs & Fault Identification
RTO Advisory OTS, Modeling
Knowledge
APC KPIs Environment
Elicitation
Quality Management Reconciliation
Archiving & Operation Management
Page 10 of 10

Saep 1050

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Saep 1050

Uploaded by

Copyright:

Available Formats

Engineering Procedure

SAEP-1050 26 October 2005

Saudi Aramco Desktop Standards

Appendix A - DSS Applications' Architecture..... 10

Previous Issue: 31 July 2000 Next Planned Update: 1 November 2010

P&CSD - Process and Control Systems Department

3. Planning & Scheduling Applications

Application Degree of Criticality

5.3 Explore and evaluate all recovery strategies

Depending on the outcome of the assessment of the above components

identify milestones, avoid repetition, and provides a road map for

5.8 Approve the plan

DSS Applications' Architecture

Web Based Dashboards User Interface

You might also like