Application Life Cycle

Defining the Business Application Life Cycle

11.09.2003
Auch bei Unternehmensanwendungen geht die Planung selten über den Einkauf und die Implementation hinaus. Die Analysten von Gartner plädieren für einen erweiterten Horizont, der den gesamten Lebenszyklus umfasst. Der größte Teil der Kosten werde erst so kontrollierbar.

Too often, enterprises approach a business application deployment as a discrete project (or discrete sets of projects - one for customer relationship management, one for enterprise resource planning and one for supply chain management) that begins with the acquisition of software and ends with going live. These discrete projects maintain limited scopes. As a consequence, they limit an enterprise's ability to adequately plan for other life cycle issues that must be addressed when dealing with packaged applications as a set of business applications.

Enterprises have invested heavily in business applications - acquiring, implementing and owning them to provide efficiency and value to business processes and users. Interestingly, acquisition and implementation costs constitute less than 30 percent of total ownership costs during a five-year period. At the same time, the life cycle stages that occur after implementation are often understaffed or ignored. Enterprises must address the full application life cycle to best control spending and obtain the most from their investments.

As the application portfolio expands and these applications become more interdependent, it will be increasingly difficult for users to address each application as a discrete implementation initiative. Enterprises must view the selection and implementation of packaged applications as the start of a robust business application life cycle, as opposed to regarding them as discrete projects that are "done" after they go live. Despite the market focus and effort placed on the implementation process, business and IS organization users often find the post-implementation stage of the business application life cycle to be just as difficult as the implementation. Little effort is given to building post-implementation support models, which means that upgrades, functional enhancements and system changes are often more challenging to execute than the implementation process itself.

Functional enhancements typically address the addition of new business processes and modules to the current live system, as well as business acquisitions and mergers. All of these factors contribute to overall life cycle costs and must be considered during the vision and planning stage of the life cycle. The availability of outsourcing options adds another decision point and potential layer of complexity to most of the stages of the life cycle.

To better prepare for "life after implementation," as well as other business application issues, enterprises should think in terms of a business application life cycle, as depicted in Figure 1.

Adopting this more-holistic approach enables multiple application initiatives to be aligned under a macro business application strategy that considers business requirements, IT strategies, and the constraints and standards of the existing application portfolio. This approach also "closes the loop" at the end of the life cycle, making application retirement or replacement a viable choice. Enterprises should strive to manage the life cycle as an integrated program that consistently carries program management and change management activities throughout all phases.

The business application life cycle has four phases: strategize, evaluate, execute and manage. We describe the four phases and the subcategories within each.

1. Strategize

This set of activities enables an enterprise to accurately and adequately plan for upcoming business and technology initiatives.

Vision and planning include the identification of specific business needs and precedes the launch of software selection activities. This stage provides the "guideposts" for initiatives, including standards, methods and constraints. Activities at this stage focus on defining the overarching architecture, as well as devising application and sourcing strategies. It requires the enterprise to think about how this application will affect the way it does business in the future, including how applications will help solve business issues and what key capabilities the applications must provide to meet evolving business needs. Business case development also occurs at this time and must be predicated by baseline measurement of current business performance. Surveys of key stakeholders (users, suppliers and customers) may be conducted to identify areas that need improvement. Lastly, if outsourcing is a consideration or a strategic direction, it should be appropriately identified as such. The enterprise's appetite for outsourcing will greatly influence the subsequent phases of the life cycle.

2. Evaluate

This set of activities results in the acquisition of a business application as a response to specific business process requirements.

Software selection includes detailed requirements definition (building on the high-level requirements of vision and planning), market scan and vendor candidate determination, request for information (RFI) and request for proposal (RFP) development and issuance, bidders conference, vendor response evaluation, shortlist creation, scripted scenario development, vendor presentations and scripted demonstrations, reference checking and site visits, finalist selection, and due diligence. In many cases, enterprises will benefit from using an external service provider (ESP) during the selection process; software selection is conducted much like ESP selection, which we will address shortly.

Software negotiation and contracting include the development and negotiation of all terms and conditions for the application license and the maintenance agreements; and, when appropriate, the execution of the contract.

3. Execute

This phase involves putting the selected application in place for the business. It is important to note that the steps of this phase are not necessarily sequential. Although planning is listed after ESP selection and before ESP contracting to enable the development of a joint client/ESP work plan, these tasks need not be performed in this order. More-experienced enterprises may plan a project before seeking ESP assistance; some enterprises may not use ESPs at all.

ESP selection (if applicable): Like software selection, this includes the activities of project scope and ESP role definition, market scan and vendor candidate determination, RFI or RFP development and issuance, bidders conference, vendor response evaluation, shortlist creation, vendor presentations, reference checking and site visits, finalist selection, and due diligence. It is important to separate the selection of the application from the selection of the ESP. This will prevent qualified ESPs from being omitted from the selection process because of the application vendor they may have teamed with. When selecting an ESP, the enterprise must balance industry experience, package capabilities, technical capabilities, key resource availability, contracting flexibility and costs.

Implementation planning: The final plan for the proposed implementation project is created at this stage as a joint process that includes the selected ESP. Users should refine project scope, roles and responsibilities, assumptions, and time frames. The project charter and plan should be finalized at this time, and the program office should be launched to manage the initiative.

ESP negotiation and contracting (if applicable): Based on the agreed to project charter and plan, the ESP contract can be executed. Billing rates, staffing durations, specific ESP resources, scope change control and ESP resource turnover are key elements for consideration.

Active implementation: Although only one step in the life cycle, implementation (or deployment) is often a multiphase activity that includes package installation, gap analysis, package configuration, custom development, integration, data conversion, testing, trading-partner integration, training, piloting and cut-over. This stage also includes the design and deployment of appropriate infrastructure. The active implementation stage uses the greatest number of resources for the most concentrated set of activities and delivers the greatest amount of "real work" compared with prior and future stages and activities. This is where "the rubber meets road"; this process involves, not a paper deliverable, but the delivery of a tangible software product and the rollout and deployment of fully tested business processes.

4. Manage

This set of activities involves the expansion of processes, technologies and functionality following the completion of the initial implementation, including ongoing enhancements, upgrade considerations and retirement of systems. This phase includes end-user retraining and the measurement of process improvement and ongoing added value. Much of the work during this phase is not project-driven and, therefore, is often taken for granted as day-to-day activities.

Support: Once live, the support function must be in place to handle user problems and vendor patches, security and recovery, archiving and reporting, and an array of other post- implementation activities. This support organization must be structured appropriately and have a formal set of processes for problem resolution and knowledge management. In some cases, support will be maintained through a third party as part of a hosting agreement.

Improvement: To obtain more value from existing investments or improve conditions immediately, enterprises should seek short- term initiatives that target specific areas. Adjusting processes, refreshing user training, tweaking and adjusting configurations, and commissioning small customizations are all potential improvement tactics. In some cases, further deployment of base functions, beyond the initial implementation, is required to achieve the application's complete vision. In such scenarios, initial projects are reduced in scope to yield incremental benefits, and require an additional phase to gain full deployment.

Upgrade analysis: At a certain point in the life cycle, users of packaged applications are faced with the increasing age of their deployed version. Analysis should be performed to determine if an upgrade is available and appropriate. If retaining the application is not an option, a retire and replacement strategy must be evaluated.

Upgrade or retire: Based on the upgrade analysis, users will decide to continue with support, embark on an upgrade or pursue a replacement initiative. Upgrade and replacement decisions lead back to the vision and planning stage of the life cycle for resource allocation, business case development and further stages in a renewed life cycle.

Key Facts: The business application life cycle consists of four phases, each with certain steps that must be followed.

1. Strategize Vision and Planning

2. Evaluate Software Selection Software Negotiating and Contracting

3. Execute ESP Selection Implementation Planning ESP Negotiation and Contracting Active Implementation

4. Manage Support Improvement Upgrade Analysis Upgrade or Retire

Bottom Line: Enterprises must consider all phases of the business application life cycle to best navigate the challenges that each phase presents. Failure to include a phase, or any of the subcategories within a phase, will waste valuable resources and possibly doom the project to longer time frames, greater costs - or failure. Discrete project planning (for example, the planning of customer relationship management, enterprise resource planning and supply chain management) as stand- alone applications cannot be done in isolation. Planning must be incorporated into a life cycle of business planning that includes these phases and stages to ensure coordination to create the greatest potential for managing value and cost.

Für weitere Informationen wenden Sie sich bitte an Gartner.