Aligning IT investment and Business - IBM · Aligning IT investment and Business The role of...

®

IBM Software Group

© 2009 IBM CorporationDr Tariq Aslam

Aligning IT investment and Business

The role of requirements management, portfolio management and enterprise architecture

Productivity, Governance, Innovation

IBM Software Group | Rational software

2

AGENDAAGENDA

Critical Business Challenges

Aligning IT with Business

IBM Solution

Q & A

Success Stories


3

Organization is not aligned with vision/mission/KPI.Organization is not aligned with vision/mission/KPI.

Companies have difficulty understanding the impact of a change.Companies have difficulty understanding the impact of a change.

Organizational structure or capabilities do not match with the technology we Organizational structure or capabilities do not match with the technology we acquire.acquire.

After the restructuring either the business processes do not work or After the restructuring either the business processes do not work or technology fails.technology fails.

Operational/business processes are inefficient.Operational/business processes are inefficient.

Companies procure system that do not integrate.Companies procure system that do not integrate.

Critical Business Challenges/PainCritical Business Challenges/Pain


4

We have no visibility over the critical systems, suppliers and capability.We have no visibility over the critical systems, suppliers and capability.

We define requirements after the system delivered.We define requirements after the system delivered.

How we ensure people know how to carry out a task assigned to them.How we ensure people know how to carry out a task assigned to them.

How we ensure critical user requirements are implemented .How we ensure critical user requirements are implemented .

How can we validate our requirements and ensure error free delivery of our How can we validate our requirements and ensure error free delivery of our system.system.

How can we maintain system after the delivery.How can we maintain system after the delivery.

Critical Business Challenges/PainCritical Business Challenges/Pain

How to go from “AS IS” to “TO BE” status.How to go from “AS IS” to “TO BE” status.


5

Portfolio overview

Enterprise Architecture

& Frameworks

EXECUTION DOMAIN

Analysis& Design

Configuration & Change

Management

Implementation

Quality Management

Iteration Management

Requirements Definition

& ManagementProduct, Project & Portfolio

Management

Measurement & Reporting

Production/Operation

BUSINESS DOMAIN

ELM


6

Enterprise Architecture is the description of the current and/or future structure and behavior of an organization's processes, information systems, personnel and organizational sub-units, aligned with the organization's core goals and strategic direction.

The primary purpose of creating an Enterprise Architecture is to ensure that business strategy and IT investments are aligned. As such, enterprise architecture allows traceability from the business strategy down to the underlying technology.

Enterprise Architecture relates more broadly to the practice of business optimization in that it addresses business architecture, performance management, organizational structure and process architecture as well.

Enterprise Architecture Helps


7

ENTERPRISE INFORMATION ENTITIESENTERPRISE INFORMATION ENTITIES

Vision StrategicObjectives

Initiatives

Process Groups

Process Maps

Challenges& Opportunities

Policies

Technology

Departments

Roles Responsibilities

NetworkData

Applications

Hardware

Drives

Mission

Translates into Executedthrough

To overcomeOr take advantage of

Executed by

Responsible for

Composed of

Executed by Based on

Belong to

Use

Run onUse

Linked to

Abide by

Uses

Planner

Designer

Owner

Developer

PerspectivesUses

Organizations create and consume information as part of their planning, management, execution and delivery activities on continuous basis.

Bridging the Gap with Business Alignment and OptimizationBridging the Gap with Business Alignment and Optimization


8

DEFINING THE ENTERPRISEDEFINING THE ENTERPRISE

Business Architecture

Information & Applications Architecture

Infrastructure Architecture which is being processed

on a given platform / server / equipment

Providing business services that .....

Are automated by a service (functionality) of an application...

which uses the component(s) of a system.....

Are implemented by processes that.....

Are executed through activities that.....

A Business Strategy is Executed by…

Bridging the Gap with Business Alignment and OptimizationBridging the Gap with Business Alignment and Optimization


9

What is EA Planning


10

.

“If you don't know where you are

going, any road will take you there”

Lewis Carroll


11


Métier

Applications & Systems

Information & Data

Strategy

Business

Define the Enterprise Strategy, goals and

Objectives : What to do, and how to do it?

Business Processes : support the strategy,

Operational organization

The Applications support the Business,

implement the business functions in the IT systems

The Information is key for the organization :

It is the fuel that drives the architecture

Infrastructure that supports the IS:

-Technical components: servers, networks, etc.

-Technology: platforms, etc.

Network & Infrastructure


12

Gartner EA Tools Magic Quadrant

IBM System Architect

positioned at the front of the

Leaders Quadrant.


13

Network Topologies

Capture and Model all Domains of the Organization

Behavior (UML Support)

Organizational Charts

Matrix Views

Application Models

Data Models Goals Objectives Class Diagrams

Process Models

Business Process Modeling and Analysis

Application and Service ModelsNetwork

Infrastructure

Relational Data Modeling

System Architect – NO 1 in Magic QuadrantSystem Architect – NO 1 in Magic Quadrant


14

Visio

In The

System

Architect

Repository

Disparate

Data

CMDB

Excel

CSV IDL

VisioXMIDDL XML

Rose

Becomes

Managed

Information

Business Strategy Organization & Process Applications and IT

Create an Organizational BlueprintLeverage Your Existing Information

Create

Roadmap



15

Simulate and Optimize Processes

Analyze resource utilizationAnalyze resource utilization

Determine cost structuresDetermine cost structures



16

Time Lapsed Visualizations As-Is/To-Be Transition



17

What if Analysis

WHAT part of the organisation will be

affected IF this process step is removed in the future state?



18

Impact AnalysisImpact Analysis


19

Impact AnalysisImpact Analysis


20

BUSINESS PROCESS ANALYSIS EXTENDED FOOTPRINT - ERP

Business Domain

Composed of

Business Flow

Business Scenario

Occurs in Different

Business Activity

Executed Through

Position

Executed By

Department

Belongs To

Business Process

Composed of

Policies

Complies with

System

Executed Using

Server

Runs On

Information

Uses

Application

Part OfConnected To

Network

Vision

Mission

Drives

Strategy

Executed Through

Owned by

KPI

Measured By


21

BUSINESS PROCESS DECOMPOSITION SAMPLE MODELS

Business Domains

Process Hierarchy Scenario Flow

Business Procedure Procedure Step

Application Mapping


22

With SA you can see key EA components supporting Enterprise strategies & goals!

With SA you can manage key EA components as projects and initiatives!With SA you can see key EA components dependent upon specific technologies!

Visualize the OrganizationVisualize the Organization

ApplicationsApplications DataData

Orgs &Orgs &PeoplePeople

Enterprise Strategies & Enterprise Strategies & DirectionDirection

Business Processes & ServicesBusiness Processes & Services

IT Infrastructure & ServicesIT Infrastructure & Services

Projects & Projects & InitiativesInitiatives

Bridging the Gap, Bridging the Gap, thethe IBM Solutions… IBM Solutions… System ArchitectSystem Architect®®


23

Portfolio overview


& Frameworks

EXECUTION DOMAIN

Analysis& Design


Management

Implementation

Quality Management




Management



BUSINESS DOMAIN

ELM


24

What Happens When You Lack Effective Portfolio Management

A reluctance to kill projectsMany projects added to list

A total lack of focus

Too many projects - resources thinly spread. Projects in a queue.

Quality of execution suffers.Higher failure rates

Weak decision pointsPoor Go / Kill decisions

Too many low value projects:-Tweaks and modifications-Good projects are starved

Too few stellar product winnersMany ho hum launches

No rigorous selection criteriaProjects selected on emotion,

politicsWrong projects are selected Many failures

No Strategic criteria for project selection

Projects lack strategic directionProjects not strategically aligned

Scatter gun effortDoes not support strategy

No Portfolio Management Means…

Immediate Result End Result: Poor New Product Performance

Slide 20


25

Spider Diagram (Projects by Type with Dependencies)


26

Spider Diagram (Projects by Project Lead)


27

Dashboard


28

Table View (Export to Excel)


29

Add a Project


30

Workflow Example 1


31

Statistical View (Project Type by Lifecycle Stage)


32

Statistical View (Project Lead by Status with Cost)


33

Statistical View (Project Lead by Status with Cost, No bubbles)


34

Project Gantt View in relation to Cost


35

Project Prioritisation


36

Projects Visualise (Cost)


37

Projects Visualise (Value)


38

Projects Visualise (5 Criteria)


39

Projects Visualise (Portfolio Analysis)


40

Projects Visualise (Balanced Scorecard)


41

Portfolio overview


& Frameworks

EXECUTION DOMAIN

Analysis& Design


Management

Implementation

Quality Management




Management



BUSINESS DOMAIN

ELM


42

Why Requirement Management is So Critical ?Why Requirement Management is So Critical ?


43

System Requirements - DOORS

System Requirements

Subsystem Requirements

Component Requirements

System

test

Subsystem

test

Component

test

Acceptance

test

validating the product

verifying the system

qualifying the subsystems

qualifying components

Stakeholder Requirements

satisfies

satisfies

satisfies

Statement of need

Operational use


44

Stakeholderrequirements

Systemrequirements

Designspecifications

Systemtests

Integration and Unit tests

Satisfies Satisfies

Acceptancetests

Tests

Tests

Tests

Example of Traceability

Designstandards

Conforms to


45

Impact analysis


Systemrequirements

Systemtests

Satisfies Satisfies

Acceptancetests

Tests

Tests

Tests



Designstandards

What if …

?

Conforms to


46

Impact coverage analysis


Systemrequirements

Systemtests

Satisfies Satisfies

Acceptancetests

Tests

Tests

Tests



Designstandards

% Complete … ?

Conforms to


47

Microsoft Word import

• Simply import into a DOORS document


48

Microsoft Word export

Document

Table

Book


49

See the explorer and document together

Navigate quickly and efficiently

DOORS views


50

Unlimited user defined attributes

Unlimited number of attributes in a spreadsheet-like view

Values can be calculated for metrics collection

Any value or attribute may be displayed in any column


51

Drag-and-drop to link within a document . . .

. . . or from document to

document

Traceability: drag-and-drop linking


52

1. 820.30(b) Design and Development Planning

Each manufacturer shall establish and maintain plans that describe or reference the design and developmentactivit ies and define responsibility for implementation. The plans shall identify and describe the interfaces with different groups or activit ies that provide, or resultin, input to the design and development process. The plans shall be reviewed as design and development evolves.The plans shall be updated as design and development evolves.The plans shall be approved as design and development evolves.

2. 820.30(c) Design Input2.1. Each manufacturer shall establish procedures to ensure that the design requirements relating to a

device are appropriate and address the intended use of the device, including the needs of the userand patient.

2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to adevice are appropriate and address the intended use of the device, including the needs of the userand patient.

2.3. The procedures shall include a mechanism for addressing incomplete requirements.2.4. The procedures shall include a mechanism for addressing ambiguous requirements. 2.5. The procedures shall include a mechanism for addressing conflicting requirements. 2.6. The design input requirements shall be documented by a designated individual(s).2.7. The design input requirements shall be reviewed by a designated individual(s).2.8. The design input requirements shall be approved by a designated individual(s).2.9. The approval, including the date and signature of the individual(s) approving the requirements,

shall be documented. 2.10. Questions.

2.10.1. Summarize the manufacturer's written procedure(s) for identification and control ofdesign input.

2.10.2. From what sources are design inputs sought?2.10.3. Do design input procedures cover the relevant aspects, such as: (Mark all that apply and

list additional aspects.)2.10.3.1. intended use2.10.3.2. user/patient/clinical2.10.3.3. performance characteristics2.10.3.4. safety2.10.3.5. limits and tolerances2.10.3.6. risk analysis2.10.3.7. toxicity and biocompatibility2.10.3.8. electromagnetic compatibility (EMC)2.10.3.9. compatibility with accessories/auxiliary devices2.10.3.10. compatibility with the environment of intended use2.10.3.11. human factors2.10.3.12. physical/chemical characteristics2.10.3.13. labeling/packaging2.10.3.14. reliability2.10.3.15. statutory and regulatory requirements2.10.3.16. voluntary standards2.10.3.17. manufacturing processes2.10.3.18. steril ity2.10.3.19. MDRs/complaints/failures and other historical data2.10.3.20. design history files (DHFs)

2.10.4. For the specific design covered, how were the design input requirements identified?2.10.5. For the specific design covered, how were the design input requirements reviewed for

adequacy?

Comply with FDA Design Control Guidance GMP Regulation

1. Capture design and related information1.1. Input electronically formatted data1.2. Reference external information sources1.3. Reference external documentation

2. Store design and related information2.1. Identify and tag design information as unique “design elements” 2.2. Organize design elements

2.2.1. Organize by Design Control Guidance Element2.2.2. Organize by inter-relationships

2.3. Ensure all design elements are available2.3.1. Store design elements by Design Control Guidance Element2.3.2. Store design elements and their historical values

3. Manage all user needs3.1. Identify the source of the user need3.2. Identify all user types (groups)3.3. Identify the customer (s)3.4. Profile the expected patients3.5. State the intended use of the product (family)3.6. Capture the acceptance criteria for each user need

4. Manage design input requirements4.1. Identify the source of the requirement4.2. Identify the associated user need4.3. Capture requirement description and attributes4.4. Capture acceptance criteria4.5. Assign responsibility for each requirement4.6. Manage incomplete requirements4.7. Manage ambiguous requirements4.8. Manage conflicting requirements4.9. Approve all requirements

5. Manage acceptance5.1. Ensure the acceptance of every user need5.2. Ensure the acceptance of every design input requirement5.3. Document the results of every user need acceptance test5.4. Document the results of every design input requirements test5.5. Make acceptance results available

6. Manage change6.1. Maintain history of design element changes

6.1.1. Make complete change history available6.1.2. Maintain history within and across any organizational procedure6.1.3. Maintain history within and across any project milestone6.1.4. Maintain history within and across any Design Control Guidance Elements

6.2. Capture frequency and nature of element changes6.2.1. Provide rationale for change6.2.2. Describe decisions made6.2.3. Identify approval authority for the change6.2.4. Capture date, time, and signature of approving authority

6.3. Identify impacted elements due to a change in another element6.3.1. Create backward traces to design elements within and across any organizational procedure6.3.2. Create backward traces to design elements within and across any project milestone

1.1. Identify impacted elements due to a change in another element• Traceability Reports: consistency with driving design elements• Impact Reports: other design elements affected• Links to impacted design elements1.1.1.Create backward traces to design elements within and across any organizational

procedure• Traceability Reports: Procedure Attribute

1.1.2.Create backward traces to design elements within and across any project milestone• Traceability Reports: Milestone Attribute

1.1.3.Create backward traces to design elements within and across Design ControlGuidance Elements• Traceability Reports: Linked design elements

1.1.4.Create forward impacts to design elements within and across any organizationalprocedure• Impact Reports: Procedure Attribute

1.1.5.Create forward impacts to design elements within and across any project milestone• Impact Reports: Milestone Attribute

1.1.6.Create forward impacts to design elements within and across Design ControlGuidance Elements• Impact Reports: Linked design elements

1.2. Associate changed design elements with related elements• Link Change Design Object with affected design element(s)• Traceability Links and Reports from affected design element(s)• Impact Links and Reports from affected design element(s)1.2.1.Associate design element changes with decisions, rationale, and approval authority

information• Change Decision Objects with following Attributes:• Disposition Attribute• Decision Attribute• Rationale Attribute• Owner Attribute• Management Approval Attribute

1.2.2.Provide associations within and across any organizational procedure• Change Design Object Traceability Link on Procedure Attribute• Change Design Object Impacts Link on Procedure Attribute

1.2.3.Provide associations within and across any project milestone• Change Design Object Traceability Link on Milestone Attribute• Change Design Object Impacts Link on Milestone Attribute

1.2.4.Provide associations within and across Design Control Guidance Elements• Change Design Object Traceability Link to traced design elements• Change Design Object Impacts Link to linked design elements

1.3. Mange the change process• Design Change Module• Design Change Reports• Object History• Object History Reports• Versions

1. 820.30(b) Design and Development Planning

Each manufacturer shall establish and maintain plans that describe or reference the design and developmentactivities and define responsibility for implementation. The plans shall identify and describe the interfaces with different groups or activities that provide, or resultin, input to the design and development process. The plans shall be reviewed as design and development evolves.The plans shall be updated as design and development evolves.The plans shall be approved as design and development evolves.

2. 820.30(c) Design Input2.1. Each manufacturer shall establish procedures to ensure that the design requirements relating to a

device are appropriate and address the intended use of the device, including the needs of the userand patient.

2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to adevice are appropriate and address the intended use of the device, including the needs of the userand patient.

2.3. The procedures shall include a mechanism for addressing incomplete requirements.2.4. The procedures shall include a mechanism for addressing ambiguous requirements. 2.5. The procedures shall include a mechanism for addressing conflicting requirements. 2.6. The design input requirements shall be documented by a designated individual(s).2.7. The design input requirements shall be reviewed by a designated individual(s).2.8. The design input requirements shall be approved by a designated individual(s).2.9. The approval, including the date and signature of the individual(s) approving the requirements,

shall be documented. 2.10. Questions.

2.10.1. Summarize the manufacturer's written procedure(s) for identification and control ofdesign input.

2.10.2. From what sources are design inputs sought?2.10.3. Do design input procedures cover the relevant aspects, such as: (Mark all that apply and

list additional aspects.)2.10.3.1. intended use2.10.3.2. user/patient/clinical2.10.3.3. performance characterist ics2.10.3.4. safety2.10.3.5. limits and tolerances2.10.3.6. risk analysis2.10.3.7. toxicity and biocompatibility2.10.3.8. electromagnetic compatibility (EMC)2.10.3.9. compatibility with accessories/auxiliary devices2.10.3.10. compatibility with the environment of intended use2.10.3.11. human factors2.10.3.12. physical/chemical characteristics2.10.3.13. labeling/packaging2.10.3.14. reliability2.10.3.15. statutory and regulatory requirements2.10.3.16. voluntary standards2.10.3.17. manufacturing processes2.10.3.18. sterility2.10.3.19. MDRs/complaints/failures and other historical data2.10.3.20. design history files (DHFs)

2.10.4. For the specific design covered, how were the design input requirements identified?2.10.5. For the specific design covered, how were the design input requirements reviewed for

adequacy?

Comply with FDA Design Control Guidance GMP Regulation

1. Capture design and related information1.1. Input electronically formatted data1.2. Reference external information sources1.3. Reference external documentation

2. Store design and related information2.1. Identify and tag design information as unique “design elements” 2.2. Organize design elements

2.2.1. Organize by Design Control Guidance Element2.2.2. Organize by inter-relationships

2.3. Ensure al l design elements are available2.3.1. Store design elements by Design Control Guidance Element2.3.2. Store design elements and their historical values

3. Manage all user needs3.1. Identify the source of the user need3.2. Identify all user types (groups)3.3. Identify the customer (s)3.4. Profile the expected patients3.5. State the intended use of the product (family)3.6. Capture the acceptance criteria for each user need

4. Manage design input requirements4.1. Identify the source of the requirement4.2. Identify the associated user need4.3. Capture requirement description and attributes4.4. Capture acceptance criteria4.5. Assign responsibility for each requirement4.6. Manage incomplete requirements4.7. Manage ambiguous requirements4.8. Manage conflicting requirements4.9. Approve all requirements

5. Manage acceptance5.1. Ensure the acceptance of every user need5.2. Ensure the acceptance of every design input requirement5.3. Document the results of every user need acceptance test5.4. Document the results of every design input requirements test5.5. Make acceptance results available

6. Manage change6.1. Maintain history of design element changes

6.1.1. Make complete change history available6.1.2. Maintain history within and across any organizational procedure6.1.3. Maintain history within and across any project milestone6.1.4. Maintain history within and across any Design Control Guidance Elements

6.2. Capture frequency and nature of element changes6.2.1. Provide rationale for change6.2.2. Describe decisions made6.2.3. Identify approval authority for the change6.2.4. Capture date, time, and signature of approving authority

6.3. Identify impacted elements due to a change in another element6.3.1. Create backward traces to design elements within and across any organizational procedure6.3.2. Create backward traces to design elements within and across any project milestone

1.1. Identify impacted elements due to a change in another element• Traceability Reports: consistency with driving design elements• Impact Reports: other design elements affected• Links to impacted design elements1.1.1.Create backward traces to design elements within and across any organizational

procedure• Traceability Reports: Procedure Attribute

1.1.2.Create backward traces to design elements within and across any project milestone• Traceability Reports: Milestone Attribute

1.1.3.Create backward traces to design elements within and across Design ControlGuidance Elements• Traceability Reports: Linked design elements

1.1.4.Create forward impacts to design elements within and across any organizationalprocedure• Impact Reports: Procedure Attribute

1.1.5.Create forward impacts to design elements within and across any project milestone• Impact Reports: Milestone Attribute

1.1.6.Create forward impacts to design elements within and across Design ControlGuidance Elements• Impact Reports: Linked design elements

1.2. Associate changed design elements with related elements• Link Change Design Object with affected design element(s)• Traceability Links and Reports from affected design element(s)• Impact Links and Reports from affected design element(s)1.2.1.Associate design element changes with decisions, rationale, and approval authority

information• Change Decision Objects with following Attributes:• Disposition Attribute• Decision Attribute• Rationale Attribute• Owner Attribute• Management Approval Attribute

1.2.2.Provide associations within and across any organizational procedure• Change Design Object Traceability Link on Procedure Attribute• Change Design Object Impacts Link on Procedure Attribute

1.2.3.Provide associations within and across any project milestone• Change Design Object Traceability Link on Milestone Attribute• Change Design Object Impacts Link on Milestone Attribute

1.2.4.Provide associations within and across Design Control Guidance Elements• Change Design Object Traceability Link to traced design elements• Change Design Object Impacts Link to linked design elements

1.3. Mange the change process• Design Change Module• Design Change Reports• Object History• Object History Reports• Versions

User Reqts Technical Reqts Test CasesDesign

Traceability view

“End-to-end visual validation in a single view”


53

•Increases customer confidence

•Detect missing links

•Creation and deletion of links is recorded in history

Traceability through an Orphan report shows “missing” links

Traceability Verification or “Completeness”


54

Vendor Comparisons

Easily Compare Responses

Prioritize Requirements


55

Can I see all my requirements in one view?

Operational Reqs System Specs


56

What are Suspect Links?

… a change by this user here…

… shows up as a warning flag to this user here.

If documents are linked …


57

Show Compliance and help achieve successful audit

Process Steps Requirements IAEA Standards


58

Portfolio overview


& Frameworks

EXECUTION DOMAIN

Analysis& Design


Management

Implementation

Quality Management




Management



BUSINESS DOMAIN

ELM


59

Communication links between enterprise applicationsCommunication links between enterprise applications


60

Enterprise Application Bus model for inter-application communicationEnterprise Application Bus model for inter-application communication


61

Service Orchestration


62

Behavior as State Machine


63

Simulate System - requirements


64

Portfolio overview


& Frameworks

EXECUTION DOMAIN

Analysis& Design


Management

Implementation

Quality Management




Management



BUSINESS DOMAIN

ELM


65

Monitor your KPI with IBM Dashboard

Accurately monitor the right indicators to actively manage operational performance for optimal strategic results. Align performance with strategic priorities

Measure and track key performance indicators

Enable accountability and informed decision-making

Correct problems before they become critical


66

Planning to Executiong


& Frameworks

EXECUTION DOMAIN

Analysis& Design


Management

Implementation

Quality Management




Management



BUSINESS DOMAIN

ELM


67

Aligning IT investment and Business - IBM · Aligning IT investment and Business The role of...

Documents

Transcript of Aligning IT investment and Business - IBM · Aligning IT investment and Business The role of...