MATRIMONIO DE HECHO - CLASES DE MATRIMONIO

5. CLASES DE MATRIMONIO

5.2. MATRIMONIO DE HECHO

AI1

AI1 Identify Automated Solutions

AI1.1 Definition and Maintenance of Business Functional and Technical Requirements

Identify, prioritise, specify and agree on business functional and technical requirements covering the full scope of all initiatives required to achieve the expected outcomes of the IT-enabled investment programme.

AI1.2 Risk Analysis Report

Identify, document and analyse risks associated with the business requirements and solution design as part of the organisation’s process for the development of requirements.

AI1.3 Feasibility Study and Formulation of Alternative Courses of Action

Develop a feasibility study that examines the possibility of implementing the requirements. Business management, supported by the IT function, should assess the feasibility and alternative courses of action and make a recommendation to the business sponsor. AI1.4 Requirements and Feasibility Decision and Approval

Verify that the process requires the business sponsor to approve and sign off on business functional and technical requirements and feasibility study reports at predetermined key stages. The business sponsor should make the final decision with respect to the choice of solution and acquisition approach.

Acquire and Implement

Identify Automated Solutions

AI1

MANAGEMENT

GUIDELINES

Goals and Metrics

PO1 Strategic and tactical IT plans PO3 Regular ‘state of technology’ updates;

technology standards

PO8 Acquisition and development standards PO10 Project management guidelines and

detailed project plans AI6 Change process description

DS1 SLAs

DS3 Performance and capacity plan (requirements)

Business requirements feasibility study PO2 PO5 PO7 AI2 AI3 AI4 AI5

• Percent of projects in the annual IT plan subject to the feasibility study

• Percent of feasibility studies signed off on by the business process owner

• Number of projects where stated benefits were not achieved due to incorrect feasibility assumptions

• Percent of users satisfied with the functionality delivered

• Percent of stakeholders satisfied with the accuracy of the feasibility study • Extent to which a benefit’s definition

changes from feasibility study through implementation

• Percent of the application portfolio not consistent with architecture

• Percent of feasibility studies delivered on time and on budget

Activities

• Defining business and technical requirements

• Undertaking feasibility studies as defined in the development standards

• Considering security and control requirements early

• Approving (or rejecting) requirements and feasibility study results

• Define how business functional and control requirements are translated into effective and efficient automated solutions.

• Respond to business requirements in alignment with the business strategy.

Process

• Identify solutions that meet user requirements.

• Identify solutions that are technically feasible and cost effective.

• Make a decision on ‘buy vs. build’ that optimises value and minimises risk. Activities

RACI Chart Functions

CEO CFO Business ExecutiveCIO Business Process OwnerHead Oper ations

Chief Ar chitect

Head DevelopmentHead IT Administr

ation

PMO

Define business functional and technical requirements. C C R C R R A/R I Establish processes for integrity/currency of requirements. C C C A/R C Identify, document and analyse business process risk. A/R R R R C R R C Conduct a feasibility study/impact assessment in respect of implementing

proposed business requirements. A/R R R C C C R C

Assess IT operational benefits of proposed solutions. I R A/R R I I I R Assess business benefits of proposed solutions. A/R R C C C I R

Develop a requirements approval process. C A C C C R C

Approve and sign off on solutions proposed. C A/R R R C C C I R C A RACI chart identifies who is Responsible, Accountable, Consulted and/or Informed.

Compliance, Audit,

Risk and Security

AI1 Identify Automated Solutions

From Inputs

Outputs

To

From Inputs

Outputs

To

measure measure measure

drive drive

set set

Goals

AI1 Identify Automated Solutions

Management of the process of Identify automated solutions that satisfies the business requirement for IT of translating business functional and control requirements into an effective and efficient design of automated solutions is:

0 Non-existent when

The organisation does not require the identification of functional and operational requirements for development, implementation or modification of solutions, such as system, service, infrastructure, software and data. The organisation does not maintain an awareness of available technology solutions potentially relevant to its business.

1 Initial/Ad Hocwhen

There is an awareness of the need to define requirements and identify technology solutions. Individual groups meet to discuss needs informally, and requirements are sometimes documented. Solutions are identified by individuals based on limited market awareness or in response to vendor offerings. There is minimal structured research or analysis of available technology.

2 Repeatable but Intuitive when

Some intuitive approaches to identify IT solutions exist and vary across the business. Solutions are identified informally based on the internal experience and knowledge of the IT function. The success of each project depends on the expertise of a few key individuals. The quality of documentation and decision making varies considerably. Unstructured approaches are used to define requirements and identify technology solutions.

3 Defined when

Clear and structured approaches in determining IT solutions exist. The approach to the determination of IT solutions requires the consideration of alternatives evaluated against business or user requirements, technological opportunities, economic feasibility, risk assessments, and other factors. The process for determining IT solutions is applied for some projects based on factors such as the decisions made by the individual staff members involved, the amount of management time committed, and the size and priority of the original business requirement. Structured approaches are used to define requirements and identify IT solutions.

4 Managed and Measurable when

An established methodology for identification and assessment of IT solutions exists and is used for most projects. Project documentation is of good quality, and each stage is properly approved. Requirements are well articulated and in accordance with predefined structures. Solution alternatives are considered, including the analysis of costs and benefits. The methodology is clear, defined, generally understood and measurable. There is a clearly defined interface between IT management and business in the identification and assessment of IT solutions.

5 Optimised when

The methodology for identification and assessment of IT solutions is subjected to continuous improvement. The acquisition and implementation methodology has the flexibility for large- and small-scale projects. The methodology is supported by internal and external knowledge databases containing reference materials on technology solutions. The methodology itself produces

documentation in a predefined structure that makes production and maintenance efficient. New opportunities are often identified to utilise technology to gain competitive advantage, influence business process re-engineering and improve overall efficiency. Management detects and acts if IT solutions are approved without consideration of alternative technologies or business functional requirements.

MATURITY

MODEL

Acquire and Implement

Identify Automated Solutions

PROCESS

DESCRIPTION

Control over the IT process of

Acquire and maintain application software

that satisfies the business requirement for IT of

aligning available applications with business requirements, and doing so in a timely manner and at a reasonable cost

by focusing on

ensuring that there is a timely and cost-effective development process is achieved by

• Translating business requirements into design specifications • Adhering to development standards for all modifications • Separating development, testing and operational activities

and is measured by

• Number of production problems per application causing visible downtime

• Percent of users satisfied with the functionality delivered

In document UNIVERSIDAD MAYOR DE SAN ANDRÉS (página 42-47)