OpenPages Object Model Overview

OpenPages Object Model Overview
IBM Business Analytics and Optimization – OpenPages Boot Camp OpenPages Object Model Overview 1

Let me introduce myself
Sharath Athrey Lead Consulting Engineer Facilitator notes: Please add a short bio and your photograph to this slide before you make the presentation. OpenPages Boot Camp OpenPages Object Model Overview

Objectives At the end of this session, you should be able to:
Recognize IBM OpenPages Shared Object Model core object types Identify parent / child object type associations Describe the object types associated with the following IBM OpenPages Modules: Financial Control Management (FCM) Operational Risk Management (ORM) Policy and Compliance Management (PCM) IT Governance (ITG) Module Internal Audit Management (IAM) Facilitator Notes: Review the module objectives with participants. OpenPages Boot Camp OpenPages Object Model Overview 3

Agenda Tutorial Introduction to Object Model Types 15 mins Tutorial
Financial Controls Management (FCM) Object Model 10 mins Tutorial Operational Risk Management (ORM) Object Model 15 mins Tutorial Policy and Compliance Management (PCM) Object Model 15 mins Tutorial IT Governance (ITG) Model 10 mins Tutorial Internal Audit Management (IAM) Model 15 mins Facilitator Notes: Review the module agenda with participants. Q&A Question and Answer 10 mins OpenPages Boot Camp OpenPages Object Model Overview

OpenPages Key Features
FCM ORM PCM ITG IAM A set of object types are licensed for use with each Module. The object model diagrams show the key objects and relationships for each of the default modules. Facilitator Notes: This slide serves as the answer to the questions on the previous slide. Slide Text: Object Types - The set of object types that are licensed to be used with each Module. Also shows the object type icon for each object type. Object Model Diagrams – These diagrams show the key objects and relationships for the Platform and for each of the Modules. Object Type Associations - A list of each parent / child object type association for the Platform and per Module, also indicating which associations are disabled by default. Object type associations lists each parent / child object type association for the Platform and per Module. OpenPages Boot Camp OpenPages Object Model Overview

OpenPages can be configured to reflect what a company does or wants to do with information management and reporting. OpenPages ‘containers’ hold specific data. The containers are called Object Types. Object Types contain Metadata or data about data. Processes Name: Joe Business Entity Date: 23Nov2010 Losses Facilitator Notes: n/a Slide Text: Before the OpenPages application can start helping connect the dots, the application needs to be configured to reflect the way your company does, or would like to do, information management and reporting. The first step is to identify how your data will be represented within OpenPages. Companies should inquire: How does your business concepts fit into the OpenPages structure? OpenPages provides many “containers” or Object Types to hold specific types of data, for example: Information about your business locations (Business Entity) Information about your business processes (Process and Sub-process) Information about business losses (Loss Event, Loss Impact, and Loss Recovery) Each container comes with pre-defined metadata to which you can add or remove Metadata is simply defined as data about data. An example: A name field is metadata; “Joe” is the data. The date field is metadata; “Nov ” is the data. OpenPages Boot Camp OpenPages Object Model Overview

There are two kinds of object types: Primary and Secondary
Primary or ‘First Class Objects’ define the way OpenPages data will be organized to reflect a business’ use cases. Secondary or ‘Second Class Objects’ can have a child relationship to any or all primary object types. Facilitator Notes: n/a Slide Text: There are two kinds of object types, primary and secondary. Primary object types may also be referred to as “First Class Objects.” Primary object types define the business process within the OpenPages application and have a clearly defined parent-child relationship with other primary object types that together create a hierarchical structure. These relationships define the hierarchy of the module and the way OpenPages data will be organized to reflect business use cases. Secondary object types can have a child relationship to any, or all, primary object types. Secondary object types may also be referred to as “Second Class Objects.” OpenPages Boot Camp OpenPages Object Model Overview

This relationship is described as either ‘Parent’ or ‘Child.’
Each object type has a relationship with one or more other object types. This relationship is described as either ‘Parent’ or ‘Child.’ Parent Child Relationship shown graphically. Relationship shown in OpenPages. Facilitator Notes: n/a Slide Text: Each object type has a relationship with one or more other object types. This relationship is described as either “parent” or “child.” For example, the Business Entity object type is considered a parent of the Process object type. Conversely, the Process object type is considered a child of the Business Entity object type. An object type is a container with metadata about a specific category, such as Risk or Process object, or a custom form. This relationship can be illustrated graphically (typically used for design discussions and documentation purposes) or displayed in the OpenPages application. OpenPages Boot Camp OpenPages Object Model Overview

OpenPages uses ‘Parent / Child Associations’ to describe the relationship between object types.
An important part of configuring OpenPages is to define all object type associations. Facilitator Notes: Slide Text: OpenPages uses the term Parent-Child Associations to describe the relationships between object types. An important part of configuring OpenPages is to define all object type associations. The object types enabled and available for your use will be determined by the OpenPages Solution you purchased. Configuration changes made to the object type are global in nature and impact all users and Cognos reporting capabilities.

The collective of all configured object type associations is known as an Object Model.
Object Models in OpenPages has an impact on links, overview visualizations, reporting framework, and Cognos reports. Facilitator Notes: n/a Slide Text: The collective of all configured object type associations is knows as the Object Model. The Object Model has an impact on several things within the OpenPages system: Links between records in the OpenPages database “Overview” visualizations of database records The generated reporting framework Ability to create meaningful Cognos reports Using the enabled parent-child associations configured in each Object Type page you can create an Object Model hierarchy map. The map should show all configured primary object type parent-child associations in your OpenPages Object Model. You should also note any secondary object type associations either as a sidebar or as part of the map itself. NOTE: If a configured parent-child association is not being used in your OpenPages system it should be disabled. OpenPages Boot Camp OpenPages Object Model Overview

The Shared Object Model diagram illustrates the core object types and additional object types available for all modules Facilitator Notes: Optional: Ask the participants for a green check mark if they have seen this diagram before. Click the red x if they have not seen this diagram before. Slide Text: This diagram contains objects and associations that are available to all default solutions. Dotted lines indicate associations which are disabled by default. OpenPages Boot Camp OpenPages Object Model Overview

Business Entities Business entities are abstract representations of your business structure. Facilitator Notes: Slides were designed to orient participants on how to comprehend these object model diagrams; providing them an opportunity to transfer that understanding to the other, more complex, diagrams they will see later in this module. Slide Text: Business entities are abstract representations of your business structure. A business entity can contain sub-entities (such as, departments, business units, or geographic locations). The entity structure that you create depends on your business needs. For example, you could create a parent entity for your business headquarters, then a sub-entity for each location or department. You may also want to represent both a legal entity structure and a business entity structure. Business entities are also used to organize library data such as risk and control libraries, or regulatory content (for example, laws, regulations, and standards). When setting up your business entity hierarchy, you should work with your OpenPages consultant as the structure of your business entities will greatly impact the type and quality of the information that can be extracted from the application. OpenPages Boot Camp OpenPages Object Model Overview

Processes and Sub-processes
Processes represent the major end-to-end business activities within a business entity that are subject to risk. A Sub-process is a component of a process. Facilitator Notes: N/A Slide Text: Processes represent the major end-to-end business activities within a business entity that are subject to risk. The processes will typically reside in areas such as financial reporting, compliance, information security, and so on. A sub-process is a component of a process. It is used to decompose processes into smaller granularity units for assessment purposes. OpenPages Boot Camp OpenPages Object Model Overview

Risk and Risk Assessment
Risks are potential liabilities. Risk assessments give you the ability to evaluate and report on potential liabilities for a set of business entities or processes. Facilitator Notes: N/A Slide Text: Risks are potential liabilities. Risks can be associated with, for example, business processes, business entities, or compliance with a particular mandate. Each risk has one or more controls associated with it that provide safeguards against the risk and help mitigate any consequences that may result from the risk. You can use the Risk object to categorize risks; capture the frequency, rating, and severity of inherent and residual risk data; and view reports that help identify your top risk items. Risk assessments give you the ability to evaluate and report on potential liabilities for a set of business entities or processes. You can use the Risk Assessment object—that contains the names of the assessor and reviewer, the time-frames for the assessment, and the status of the assessment—to manage your risk self-assessment process. OpenPages Boot Camp OpenPages Object Model Overview

Control and Control Objective
Controls are policies and procedures to help ensure that risk mitigation responses are carried out. A Control Objective is an assessment object that helps define the risk categories for a process or sub-process. Facilitator Notes: N/A Slide Text: Controls are policies and procedures to help ensure that risk mitigation responses are carried out. Once you have identified the risks in your practices, you need to establish controls (such as approvals, authorizations, verifications, and so forth) that remove, limit, or transfer these potential risks. Controls should be designed to provide either prevention or detection of risks. Controls are usually associated with tests that ensure a control is effective. The Control Objective is an assessment object that helps define the risk categories for a process or sub-process. Many customers don’t use the Control Objective because it’s used for a very specific purpose, to define the COSO compliance categories that the controls are intended to mitigate. For example, control objectives can be classified into one or more categories such as Compliance, Financial Reporting, Strategic, Operations, or Unknown. Once a control objective is identified, the risks belonging to that control objective can then be identified and defined. In most cases, each Control Objective will have one Risk associated with it. OpenPages Boot Camp OpenPages Object Model Overview

Test Plans and Test Results
Test Plans are descriptions of the mechanisms used to determine whether or not a control is effective. A Test Result is the information obtained from running a test plan. Facilitator Notes: N/A Slide Text: You can determine the operating effectiveness of a control by conducting one or more detailed tests of a control and then documenting the results. Test Plans are descriptions of the mechanisms used to determine whether or not a control is effective. A test result is the information obtained from running a test plan. OpenPages Boot Camp OpenPages Object Model Overview

Issue, Signature, File, and Link
An Issue / Action item documents a concern associated with any object type. A Signature indicates agreement that an object meets your approval. The File object embeds a reference file into OpenPages. The Link object embeds a reference to a URL into OpenPages. Facilitator Notes: N/A Slide Text: Although issues typically result from areas where internal controls are not properly implemented or designed, you can use the Issue object to document a concern associated with any object type. An issue is resolved through one or more Action Items. You can use an Action Item object or a series of related Action Item objects to form an action plan. Each Action Item can be assigned to a user for resolution, and progress can be tracked from the detail page of the parent Issue. Once all Action Items for an Issue are complete (an assignee sets the value to 100 percent), you can close the Issue. A signature generally indicates agreement that the object meets your approval. It has no enforcement powers, and does not prevent the item from being modified after approval has been given. An object with a signature has a signature icon next to the signer's name on the Signatures tab. Depending on your system configuration, signatures (with or without associated locks) can be applied to an object in the following ways: - Manually from the detail page of an object. - Automatically through a workflow task Some combination of both automatic and manual. If signature locks are configured on your system, when you sign off on an object, the object and all its associated child objects are locked and cannot be modified until you either revoke your signature or an administrator unlocks the object. The File object type is used to embed a reference to a file (such as a document, flow chart or spreadsheet) in the OpenPages system, and associate it to one or more relevant objects. The Link object type is used to embed a reference to a URL in the OpenPages system, and associate it to one or more relevant objects. OpenPages Boot Camp OpenPages Object Model Overview

Additional object types available to ALL Modules
Questionnaire, Section, and Question are used together to implement questionnaires. Preference objects hold variable values and the Preference Group objects group them together. Risk Evaluation objects capture risk measurement values. Control Evaluation objects store control assessment data. Risk Assessment Evaluation objects store risk assessment data. Facilitator Notes: Slide Text: Questionnaire, Section and Question are three objects that are used together to implement questionnaires. The Preference Group object is used for grouping Preference object instances together. Without this grouping object, each Preference object instance would need to be associated separately to each of the relevant Business Entities. The group object helps to minimize the associated maintenance. The Preference object is a child of Business Entity, and is used for holding variable values that can drive reports, workflows and computed fields (it has entity-specific variable values which enable different behavior for the same workflows). For example, to determine the behavior for review and approval workflows (EX. who the appropriate users are for each level of review and approval, and what the thresholds are for determining how many levels of review and approval are required). Risk Evaluation objects are children of Risk objects and they are used to capture risk measurement values for trending purposes. Often reporting periods do not line up with risk evaluation cycles and so Risk Evaluation objects can be used to capture multiple evaluation cycles within a single reporting period. Control Evaluation objects are similar to Risk Evaluation objects except that they are instantiated as children of Controls. They store control assessment data. Risk Assessment Evaluation objects are similar to Risk Evaluation objects except that they are instantiated as children of Risk Assessments. They store risk assessment data. NOTE: It’s not recommended to discuss the following objects because only a handful of customers use the objects. A Milestone represents a significant point in the development of your project. You can tie Milestones to specific dates, or use them to signify the completion of a portion of the entire project. Milestones can contain other Milestones or Milestone Action Items. You cannot associate a Milestone with other objects in the object hierarchy. A Milestone Action Item is a specific objective that must be completed in order to reach a Milestone. In general, all Milestone Action Items associated with a Milestone must be completed in order to reach a Milestone. When you are assigned a Milestone Action Item object, it is displayed (if configured) in the My Milestone Action Items section of your Classic Home Page. OpenPages Boot Camp OpenPages Object Model Overview

Financial Controls Management (FCM) Object Model 10 mins Tutorial Operational Risk Management (ORM) Object Model 15 mins Tutorial Policy and Compliance Management (PCM) Object Model 15 mins Tutorial IT Governance (ITG) Model 10 mins Tutorial Internal Audit Management (IAM) Model 15 mins Facilitator Notes: Review the module agenda with participants. Tutorial Recap and Quiz 10 mins Q&A Question and Answer 10 mins OpenPages Boot Camp OpenPages Object Model Overview

OpenPages Object Modules
Facilitator Notes: This is an organizing framework of the OpenPages modules / object models that will be discussed in this module. OpenPages Boot Camp OpenPages Object Model Overview

Financial Controls Management (FCM)
Reduces the time and resource costs associated with ongoing compliance for financial reporting regulations. Facilitator Notes: There is a slide like this one that proceeds each new Object Model. You should pause here, if time allows, to ask participants to use the Raise Hand option or Text Chat to ask questions. Slide Text: IBM OpenPages Financial Controls Management (FCM) reduces the time and resource costs associated with ongoing compliance for financial reporting regulations. FCM combines powerful document and process management with rich interactive reporting capabilities in a flexible, adaptable easy-to-use environment, enabling CEOs, CFOs, managers, independent auditors and audit committees to perform all the necessary activities for complying with financial reporting regulations in a simple and efficient manner. OpenPages Boot Camp OpenPages Object Model Overview

FCM Object Model Facilitator Notes:
Ask participants to use the Whiteboard mark-up tools to indicate the different object types present on this diagram that were not present on the Shared Object Model diagram. Make note to the learners that there are no new or different “additional object types” or “children objects” for FCM. OpenPages Boot Camp OpenPages Object Model Overview

Object Types SPECIFIC to FCM
Accounts correspond to the line items on a financial report. A sub-account represents a smaller, more targeted line item that is part of a larger parent account. Facilitator Notes: The colored band on the side of this slide represents which Model is being discussed. One will appear for each Model. Slide Text: Generally, accounts correspond to the line items on a financial report, although not necessarily on a one-to-one basis. Each account is affected by recurring processes. These processes can introduce risks that must be documented during the financial controls documentation project. A sub-account represents a smaller, more targeted line item that is part of a larger parent account (or of another sub-account). Each sub-account object can be associated with parent account or sub-account objects. The Assertion object is used to link Control objects to Account (or Sub-account) objects. F C M OpenPages Boot Camp OpenPages Object Model Overview

Operational Risk Management (ORM)
Automates the process of identifying, measuring and monitoring operational risk, by combining all risk data into a single integrated module. Facilitator Notes: You should pause here, if time allows, to ask participants to use the Raise Hand option or Text Chat to ask questions. Slide Text: IBM OpenPages Operational Risk Management (ORM) automates the process of identifying, measuring and monitoring operational risk, combining all risk data – risk and control self assessments, loss events, scenario analysis, external losses, and key risk indicators (KRI) – into a single integrated module. ORM combines powerful document and process management with a monitoring and decision support system that enables organizations to analyze, manage and mitigate risk in a simple and efficient manner. OpenPages Boot Camp OpenPages Object Model Overview

ORM Object Model Facilitator Notes:
Point out to participants the ‘core spine’ of shared objects. Tell participants to notice the way that the diagram has shifted to focus more on Risks. OpenPages Boot Camp OpenPages Object Model Overview

Object Types SPECIFIC to ORM
Risk Assessment Evaluations store risk assessment data. KRIs provide leading or lagging indicators for potential risk conditions. Scenario Analysis are used to identify and measure specific kinds of risks. Facilitator Notes: N/A Slide Text: Scenario Analysis is an assessment technique used to identify and measure specific kinds of risks, in particular, low frequency, high-impact events such as earthquakes, recessions, or power grid failures. Risk Evaluation objects are children of Risk objects and they are used to capture risk measurement values for trending purposes. Often, reporting periods do not line up with risk evaluation cycles and so Risk Evaluation objects can be used to capture multiple evaluation cycles within a single reporting period. Control Evaluation objects are similar to Risk Evaluation objects except that they are instantiated as children of Controls. They store control assessment data. Risk Assessment Evaluation objects are similar to Risk Evaluation objects except that they are instantiated as children of Risk Assessments. They store risk assessment data. KRIs are components of the risk monitoring process and are used to provide leading or lagging indicators for potential risk conditions. Each instance of a KRI within the organization can have unique target and threshold limits. Risk Evaluations capture multiple evaluation cycles within a single reporting period Control Evaluations store control assessment data. O R M OpenPages Boot Camp OpenPages Object Model Overview

Additional Object Types SPECIFIC to ORM
ORX Loss objects are used with scenario analysis and capital modeling. Cost Center objects group loss events under a business entity. Loss Events track operations losses. A Loss Impact is a financial or non-financial consequence of a loss event. Loss Recovery objects track the processes associated with regrouping damages from a loss event. Facilitator Notes: N/A Slide Text: ORX Loss objects can be imported from the ORX external loss database, for use with scenario analysis and capital modeling. Loss Events are used to track operational losses that may occur in any part of an organization. Loss Events are typically stored under the Business Entity where the loss occurred. The Loss Event objects are used to track, assess, and manage the related internal loss data. You can add multiple impacts and recoveries for each Loss Event using the Loss Impact and Loss Recovery objects. A loss impact is a financial and / or non-financial consequence resulting from a loss event. Loss Impacts track different types of impacts triggered by a Loss Event, such as legal liability, asset loss and damage, or business interruption. There can be multiple Loss Impacts associated with each Loss Event. Loss Recovery objects are used to track the processes associated with recouping damages that result from Loss Events. Cost center objects are used to group loss events under a business entity. In many cases, firms want to track where loss events occur at a fine granularity (EX. cost center level) but do not want to represent all of the organizational layers as business entities. O R M OpenPages Boot Camp OpenPages Object Model Overview

Policy and Compliance Management (PCM)
Reduces the cost, complexity and cumbersome nature of compliance with multiple regulatory mandates and corporate policies. Facilitator Notes: You should pause here, if time allows, to ask participants to use the Raise Hand option or Text Chat to ask questions. Slide Text: IBM OpenPages Policy and Compliance Management (PCM) is an enterprise compliance management software solution that reduces the cost, complexity and cumbersome nature of compliance with multiple regulatory mandates and corporate policies. OpenPages Boot Camp OpenPages Object Model Overview

PCM Object Model Facilitator Notes:
Because this is such a complicated diagram, you should use your Whiteboard mark-up tools to highlight each portion as you discuss it. OpenPages Boot Camp OpenPages Object Model Overview

PCM ‘Regulator Interaction Management’ Object Types
The Regulator object allows organizations to create a single inventory of all Regulators with which they interact. The Regulator Interaction object manages tasks associated with external regulators. The RI Category object organizes and tracks the progress of individual sections or categories of a complex interaction. The RI Request object organizes and tracks individual requests, reviews, and approvals of pre-work and onsite tasks part of a complex interaction. Facilitator Notes: N/A Slide Text: The Regulator object is part of the Regulator Interaction Management capability and provides the ability to for organizations to create a single inventory of all Regulators with which they interact. Regulators are typically created in a reference Library Business Entity. The object is a child of Business Entity and can be associated to Mandates and Regulator Interactions. The Regulator Interaction object is part of the Regulator Interaction Management capability and provides the ability to manage the interactions, communication, internal work, review, and approvals associated with external regulators such as inquiries, submissions, filings, exams, and audits. For complex interactions such as exams and audits, customers can use a three-tier object structure (Regulator Interaction, RI Category and RI Request) to manage and track the overall interaction, each section of the interaction, and the individual requests. For simpler requests and inquiries, customers can use the Regulator Interaction object by itself to manage the request details and response details. The RI Category object is part of the Regulator Interaction Management capability and is used as the middle tier of the three-tier object model (Regulator Interaction, RI Category, and RI Request). The object is used to organize and track the progress of individual sections or categories of a complex interaction such as an exam or audit. The RI Request object is part of the Regulator Interaction Management capability and is used as the bottom tier of the three-tier object model (Regulator Interaction, RI Category, and RI Request). The object is used to organize and track the individual requests, reviews and approvals of pre-work and onsite tasks as part of a complex interaction such as an exam or audit. The Regulation Applicability object is the child of Business Entity and parent of Mandate. It typically resides in the Organizational Business Hierarchy and is used to assess and track the Regulatory Impact of a Mandate in the Library on a Business Entity. The Regulation Applicability object assesses and tracks the Regulatory Impact of a Mandate in the Library on a Business Entity. P C M OpenPages Boot Camp OpenPages Object Model Overview

Key Performance Indicators
KPIs are used to provide leading or lagging indicators for potential risk conditions. Facilitator Notes: N/A Slide Text: KPIs are components of the risk monitoring process and are used to provide leading or lagging indicators for potential risk conditions. Each instance of a KPI within the organization can have unique target and threshold limits. P C M OpenPages Boot Camp OpenPages Object Model Overview

PCM ‘Regulatory Change Management’ Object Types
Mandates represent external items (laws and regulations) with which organizations need to comply. Sub-Mandates represent external (or internal) sub-items with which the organization needs to comply. Requirements represent the normalized “things you need to accomplish” in order to comply with all of their associated Sub-Mandates. The Regulatory Change object supports the ability to track, access, and communicate the impact of regulatory changes. Facilitator Notes: N/A Slide Text: Mandates represent external items with which organizations need to comply, such as laws, regulations, and standards. Out of the box the configuration directly supports content provided by Deloitte and UCF, and can be adapted to support content from other vendors. Typically, Mandates are represented in a Library Business Entity structure, and are not replicated throughout the system. Sub-Mandates represent external (or internal) sub-items with which the organization needs to comply. Out of the box the configuration directly supports content provided by Deloitte and UCF, and the configuration can be adapted to support content from other vendors. Typically, Sub-Mandates are represented in a Library Business Entity structure, and are not replicated throughout the system. Sub-Mandate is recursive, but Deloitte and UCF content use exactly one level of Sub-Mandate. Requirements represent the normalized “things you need to accomplish” in order to comply with all of their associated Sub-Mandates. Requirements accomplish two primary purposes: They translate the often difficult and wordy legalese of Mandates or Sub-Mandates into plain English, and they leverage the commonality across multiple Sub-Mandates. For example, there may be many Sub-Mandates across numerous Mandates which are all telling you to have strong passwords. A single Requirement can document the details of the strong password needs. By complying with this single Requirement, IT can satisfy many Mandates or Sub-Mandates. Out of the box the configuration directly supports content provided by Deloitte and UCF, and can be adapted to support content from other vendors. Typically, Requirements are represented in a Library Business Entity structure, and are not replicated throughout the system. The Regulatory Change object is part of the Regulatory Change Management capability. It supports the ability to track regulatory changes (change or guidance to an existing regulation or a new regulatory requirement), assess the impact of a change on the organization, communicate the change internally to the appropriate people and drive internal processes in response to the change. Regulatory Changes typically reside in the Library Business Entity, and are associated directly to the Mandate that changed. It then has multiple Regulatory Tasks associated to it; one for each Business Entity impacted by the respective Mandate. The Regulatory Task object is part of the Regulatory Change Management capability. It facilitates the change management process associated with a Regulatory Change. A Regulatory Task is created in the Organizational Business Hierarchy and assigned to an individual in each of the Business Entities impacted by the Mandate that was changed. The object is then used to track and monitor if an action is required as a result of the change (i.e. revise policy, control assessment, training, and so on) and the progress of the action. The Regulatory Task object facilitates the change management process associated with a Regulatory Change. P C M OpenPages Boot Camp OpenPages Object Model Overview

PCM ‘Policy Awareness Capability’ object types
The Employee object captures employee information. Policies represent internal guidelines within an organization. Procedures represent the 'what', 'where', 'when', and ‘how’ of how policies are implemented in an organization. The Attestation object captures an employee's affirmation that they have read and understood a policy. Facilitator Notes: N/A Slide Text: The Employee object is part of the Policy Awareness Capability. It is used to capture information about individual employees such as the name, title, , region, department, status, and so on. Information from the employee profile is then matched against the Attestation Requirements defined on a Campaign to determine which Employees need to attest to each Policy. Employee data is typically derived from an HR system export, loaded through Online FastMap, and resides in the reference Employee Business Entity. It is a best practice that the Employee Name field matches the user's username. Policies represent internal guidelines generally adopted by the Board of Directors or senior governance body within an organization. The text of a Policy can either be stored in standardized fields on the object or as an attachment to the object. Policies typically have a distinct lifecycle from Draft to Published to Expired, as well as a review and approval process. Draft policies typically reside in the Organizational Business Hierarchy, while Published and Expired Policies typically reside in reference Library entities. Policies are also often mapped to applicable Mandates in the Library to which they relate. Procedures represent the 'what', 'where', 'when', and ‘how’ of how policies are implemented in an organization. The text of Procedures is typically stored in the fields on the object. Typically, Procedures are represented as children of a Policy and reside in the same entity structure as its parent Policy. The Attestation object is part of the Policy Awareness capability and is used to capture an employee's affirmation that they have read and understood a policy. An attestation's primary parent is the Employee record and the secondary parent is the associated Campaign. The Campaign object is part of the Policy Awareness capability and is used to manage the project management aspects of an awareness campaign. It is also used to define the requirements or criteria that identifies which employees need to read and attest to each Policy. This is done through a series of fields. Campaigns are typically created in the Published Policy Hierarchy. The Campaign object manages the project management aspects of an awareness campaign. P C M OpenPages Boot Camp OpenPages Object Model Overview

IT Governance (ITG) IT Governance (ITG) Aligns IT services, risks and
policies with corporate business initiatives, strategy, and operational standards. Facilitator Notes: You should pause here, if time allows, to ask participants to use the Raise Hand option or Text Chat to ask questions. Slide Text: IBM OpenPages IT Governance (ITG) is an enterprise IT Governance solution that aligns IT services, risks and policies with corporate business initiatives, strategy, and operational standards. ITG allows you to manage internal IT control and risk according to the business processes they support. In addition, ITG unites multiple silos of IT risk and compliance to deliver improved visibility, better decision support, and ultimately enhanced corporate performance. OpenPages Boot Camp OpenPages Object Model Overview

IT Governance Facilitator Notes: N/A
OpenPages Boot Camp OpenPages Object Model Overview

IT Governance Control Plan are created to represent elements that can be assessed for risk (i.e. IT Services). They are made up of a logical grouping of applicable Library Baselines. Baseline reside in the Reference Library and represent what must be compiled with a given element (or type of element) in the IT Operating Environment. each Baseline. Facilitator Notes: N/A Slide Text: Object name is RiskEntity; label is Control Plan. It is used to group multiple Baselines to represent elements in your operating environment that can be assessed for risk. They are made up of a logical grouping of applicable Library Baselines. Typically customers assess each Baseline individually for that Control Plan, as well as perform an aggregated assessment. Object name is RiskSubEntity; label is Baseline. Baselines in the Library are representative of types of elements of the IT Operating Environment. They are linked to Requirements in the Library to indicate what must be complied with for that type of element. When a Baseline is copied from the library to the business hierarchy (using a helper which is part of ITG) it copies the Baseline, creates an association back to the Requirement in the library, creates the descendent Risk, Control and Test and pre-populates the Risk/Control/Test as appropriate with data from the Requirement. A Baseline can represent the assessment of element(s) of the IT Operating Environment, instead of or in addition to representing the actual element. Process, Resource, and so on can represent the actual elements. Mandates represent external items with which organizations need to comply, such as laws, regulations, and standards. Out of the box the configuration directly supports content provided by Deloitte and UCF, and can be adapted to support content from other vendors. Typically, Mandates are represented in a Library Business Entity structure, and are not replicated throughout the system. Sub-Mandates represent external (or internal) sub-items with which the organization needs to comply. Requirements represent the normalized “things you need to accomplish” in order to comply with all of their associated Sub-Mandates. Requirements accomplish two primary purposes: They translate the often difficult and wordy legalese of Mandates/Sub-Mandates into plain English, and they leverage the commonality across multiple Sub-Mandates. For example, there may be many Sub-Mandates across numerous Mandates which are all telling you to have strong passwords. A single Requirement can document the details of the strong password needs. By complying with this single Requirement, IT can satisfy many Mandates or Sub-Mandates. Out of the box the configuration directly supports content provided by Deloitte and UCF, and can be adapted to support content from other vendors. Typically, Requirements are represented in a Library Business Entity structure, and are not replicated throughout the system. I T G OpenPages Boot Camp OpenPages Object Model Overview

Internal Audit Management (IAM)
Provides internal auditors a unique view of GRC, affording audit the chance to supplement and coexist with broader risk and compliance management activities. Facilitator Notes: You should pause here, if time allows, to ask participants to use the Raise Hand option or Text Chat to ask questions. Slide Text: IBM OpenPages Internal Audit Management (IAM) provides internal auditors with a uniquely configured view into organizational governance, risk, and compliance (GRC), affording audit the chance to supplement and coexist with broader risk and compliance management activities. As with all Modules, IAM is completely integrated with financial controls management, IT governance, policy and compliance efforts and operational risk management programs. The internal audit team has the capability to work as a fully integrated partner to business stakeholders, completely independently, or anywhere in between, as determined by the specific needs of the audit department or a particular audit being undertaken. OpenPages Boot Camp OpenPages Object Model Overview

Internal Audit Management
Facilitator Notes: N/A OpenPages Boot Camp OpenPages Object Model Overview

An Auditable Entity represents a single element of the Audit Universe. An Audit represents each execution of an “audit” against an Auditable Entity. Audit Sections represents the phases of the audit, work programs within the audit, or other components of the audit at the desired level of granularity. A Workpaper is any artifact or deliverable you want to track in the scope of an audit. Facilitator Notes: Instruct them to use the Whiteboard mark-up tools to indicate on the screen which object types are NOT enabled by default. They should show that the dotted line indicates this. Slide Text: The Preference Group object is used for grouping Preference object instances together. Without this grouping object, each Preference object instance would need to be associated separately to each of the relevant Business Entities. The group object helps to minimize the associated maintenance. An Auditable Entity represents a single element of the Audit Universe – the collection of things in the Business that might be audited. It is a child of Business Entity. Typically, an Internal Audit Business Entity Hierarchy would be established under which all of the Auditable Entities would live. Auditable Entities which are aligned with one or more elements of the Business Entity Organizational Hierarchy are typically also associated to those Business Entities. Typically, the majority of Auditable Entities represent one or more business or legal entities, but they can also represent one or more processes, long-running projects or initiatives, compliance programs, shared IT Services, and so on. Auditable Entities are risk ranked every year to determine the priority of performing an audit that year. A Weighted Risk Score is calculated and an ability to manually override the score is provided. An Audit represents each execution of an “audit” against an Auditable Entity. For example, if an Auditable Entity will be audited every two years, there would be separate child Audit instances for 2006, 2008, 2010, and so on. The Audit object is configured to be a self-contained object type, meaning that a folder will be automatically created for each instance of it. This facilitates the ability to copy template audits and audit components from a library to the audit hierarchy without object naming conflicts. Planning and Scheduling of the Audit Resources is typically done at the Audit level. High level Audit progress can be tracked by monitoring the Status values and Date values on the Audit. Key audit milestones can be tracked by adding fields on the Audit that represent completion dates for each of the key milestones they wish to track. You use the Audit object to manage the audit process across your enterprise. The Audit object identifies a holding point where you can capture information such as scope, objectives, timing information, review, execution, and approval roles. If wanted, you could track only those audits you will be undertaking in a given planning horizon, or all audits in the audit universe. Audit Sections can be used to represent the phases of the audit, work programs within the audit, or other components of the audit at the desired level of granularity. Typically organizations have a number of standard components for each audit. Template audits that include Sections for each of these standard components can be created in a Library. Planned and Actual Start and End Dates for these sections can be used to report progress on key milestones in the audits. Detailed Audit progress can be tracked by including an Audit Section that represents each milestone. Alternatively, some organizations may choose to add fields on the Audit that represent completion dates for each of the key milestones they wish to track. Although Audit Sections can be used as the basis for planning and scheduling Audit resources, most organizations will find this to be too detailed. A Workpaper is any artifact or deliverable you want to track in the scope of an audit. It can represent an engagement letter, a testing matrix, interview notes or anything else appropriate to the audit in question. The workpaper itself can be attributes stored on the Workpaper object, or it can be a Word, Excel or other type of file attached to a Workpaper object. When Workpaper is used for test evidence, it documents both the test planning and the test results. Typically, you create a Workpaper object from the detail page of an Audit Section. Workpaper objects can also be copied from a library, where they represent templates of different types of workpapers generated by an internal audit department. I A M OpenPages Boot Camp OpenPages Object Model Overview

Findings can be used to represent observations, which are reportable to the business, to the Audit Committee, or both. A Plan, Timesheet object type facilitates audit resource scheduling and allocation at any level. The Auditor object is used to create a pool of Auditors who can be assigned to Audits. The Audit Review Comment object type is used to provide feedback during the review process for an audit and its components.. Facilitator Notes: N/A Slide Text: Findings can be used to represent observations which are reportable to the business, to the Audit Committee, or both. Alternatively, Findings can be used to represent individual factual observations, while Issues are used to represent consolidated themes or systemic problems, which are then reported to the business, to the Audit Committee, or both. A Finding represents anything uncovered in the course of an audit that needs to be accounted for and addressed by management. You can use a finding to track management’s progress in addressing the underlying issue identified. The Issue object can be used in place of, or in conjunction with, the Finding object. A Plan object type facilitates audit resource scheduling and allocation at any level. For example, you can create a single Plan object for an entire audit, or you can create one Plan object per task for each auditor involved with the audit. Plan objects are used to determine the availability, skills, and experience required of the desired resource. OpenPages Audit Activity Views, reports, and so on are aligned with Planning at the Audit level. Plans can instead be associated to Audit Sections, in which case these components would need to be modified. Plan objects also drive time tracking – all time is tracked against Plans. A Timesheet object type is used to record weekly actual hours and expenses expended against a Plan object for an Audit. Because Timesheet objects are associated with Plans, it is easy to track deviations between planned and actual time and expenses. The Timesheet Entry interactive report should always be used to enter or modify time and expense data. For this reason, there is no Timesheet top menu item in the default IAM configuration. You typically create or modify a Plan object using the Add or Modify Plans helper, accessed from a link on the Audit detail page. Resource planning and allocating requires key information about each individual who may perform audit work. The Auditor object is used to create a pool of Auditors who can be assigned to Audits. Each user who may be assigned to audit work is represented as an Auditor instance. Auditors are then available for resource allocation. The Auditor object includes attributes for which you evaluate and select Auditors for audit engagements, such as specialties, languages, and certifications. Typically, Auditor objects are associated with the relevant component of the Internal Audit organizational hierarchy. The Audit Review Comment object type is used to provide feedback during the review process for an audit and its components. It is associated as a child to the instance of the Audit, Section, Workpaper or Finding for which feedback is being provided. I A M OpenPages Boot Camp OpenPages Object Model Overview

Financial Controls Management (FCM) Object Model 10 mins Tutorial Operational Risk Management (ORM) Object Model 15 mins Tutorial Policy and Compliance Management (PCM) Object Model 15 mins Tutorial IT Governance (ITG) Model 10 mins Tutorial Internal Audit Management (IAM) Model 15 mins Facilitator Notes: Review the module agenda with participants. Tutorial Question and Answer 10 mins OpenPages Boot Camp OpenPages Object Model Overview

Summary You have reached the end of this module. You are now able to:
Recognize OpenPages Shared Object Model core object types Identify parent / child object type associations Describe the object types associated with the following OpenPages Modules: Financial Control Management (FCM) Operational Risk Management (ORM) Policy and Compliance Management (PCM) IT Governance (ITG) Module Internal Audit Management (IAM) Facilitator Notes: Review objectives again with participants. OpenPages Virtual Boot Camp Basic Introduction to OpenPages

OpenPages Object Model Overview

Similar presentations

Presentation on theme: "OpenPages Object Model Overview"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

OpenPages Object Model Overview

Similar presentations

Presentation on theme: "OpenPages Object Model Overview"— Presentation transcript:

Similar presentations

About project

Feedback