Tuesday, January 17, 2017

BPI Technique - Application Portfolio Analysis - APA

BPI Technique - Application Portfolio Analysis - APA

Description

  • A method to assist project team in gaining an understanding of the quantitative and qualitative level of automation of an organization (i.e. as part of a complete Information Technology Assessment). This analysis addresses not only institutional information systems, but also the following:
  • Professional automation (office automation, Computer Aided Design etc.)
  • Process automation, robotics, etc.
  • External information systems
  • Infrastructural systems (telecommunications, data bases, security, etc.)
  • The determination of the quantitative level of automation gives insight into the degree to which business processes or business functions are supported by IT, while an analysis of the qualitative level of automation gives a clear view of both the functional and technical levels of satisfaction of this support.

When To Use

  • Typically, this technique is used as one part of an “As-Is” Technology Assessment. In connection with the financial analysis of the IT environment, the results of this research provide senior management with insight into the evaluation of the automation possibilities within the business model and the current state of IT support of the business functions.
  • The technique can be used as a stand-alone analysis—i.e. as a “Quick Scan”—with, naturally, less accuracy than if all the elements of the more-comprehensive Information Technology Assessment are also included.

Approach

  1. Determine the quantitative level of automation
    1. For the evaluation of the quantitative and qualitative level of automation, identify the general and industry specific business functions for which IT-opportunities exist. Then use this inventory to draw up a business.
    2. Model, so the applications supporting the different business processes or business functions can be mapped.
    3. Make an inventory of the existing applications and other forms of automated support such as personal computer use, PC-tools such as spreadsheets, etc.
    4. Have the users’ organization determine, by the means of interviews and workshops, which parts of the business functions can be supported by IT (i.e. are able to be automated) and which parts should at all times be carried out manually (or in any other way).
    5. Determine to what degree IT is actually supporting the areas it could be supporting. In this way, map three fields for the parts that can be automated of each business function :
      1. That which can be automated, but for which, currently no automated system exists (i.e. an opportunity)
      2. That which is intended to be supported by IT and for which IT systems are developed (i.e. attempted coverage)
      3. That which is actually supported by IT (i.e. effective coverage)
    6. Be aware that the functional quality (ease of use, accuracy of information, etc.) determines the difference between the attempted and the effective coverage. In the end, the level of automation for all business functions can be represented graphically.
  2. Determine the qualitative level of automation, by means of questionnaires and interviews, subsequently determine how effectively the business functions are supported by automation.
    1. Make a distinction between the technical and functional quality of the application. Be aware that users form an opinion on the functional quality, with regard to aspects such as:
      1. Reliability of information
      2. Reporting and request possibilities
      3. Ad hoc reporting
      4. User friendliness.

Examples

The following example illustrates how a Functional Quality / Technical Quality matrix (FQ/TQ) can capture and present key issues uncovered as part of the Application.
In the example below the result is given of an application portfolio analysis. Each circle represents an information system, while the size of the circle gives an indication of the size of costs to the system. This portrayal gives insight into whether systems are in good condition, should be redeveloped or replaced, or do not meet user requirements (despite being technically adequate).
Finally, connections are made between qualitative findings and demographic characteristics of applications such as age, size and complexity, used technologies and programming languages etc.
FASR.png
Image 1-5.png
Image 2 of 5.png
Image 3-5.png
image 4 of 5.png
Image 5-5.png
AP 1-10.png


AP 2-10.png
AP 3-10.png


AP 4-10.jpg
AP 5-10.png
AP 6-10.png
AP 7-10.pngAP 8-10.pngAP 9-10.pngAP 10-10.png

No comments:

Post a Comment