Monday, November 17, 2014

Application Portfolio Analysis

Before embarking on a Business Process Programme there needs to be sufficient preparation work carried out to create a baseline. The baseline establishes where we are today. Besides selection of an Architecture Tool there needs to be a thorough analysis of the current Application Portfolio. This will establish how the current applications meet the business needs and where there are shortcomings and what needs to do done to align the applications with the current and future business requirements.

Application Portfolio Analysis

Application Portfolio Analysis is a method to assist organisations in gaining an understanding of the quantitative and qualitative level of automation of their business as part of a complete Information Technology Assessment.
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.
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.
Application Architecture.png
The above diagram depicts a typical supply chain organisation and its interfaces to external organisations that can impact business performance. This diagram can be created for any business organisation and provides a basis for comparing the current situation with a vision of future requirements.

Description

  • A method to assist an organisation to gaining an understanding of the quantitative and qualitative level of automation of an organisation (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’ organisation 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.

No comments :

Post a Comment