Application package software, which is licensed from third-party software providers to fulfill a specific business purpose, has been in use for decades. While the software has matured, implementing and benefiting from third-party application packages remains a challenge. There have been numerous claims made about the value and benefits of using application packages; some are accurate, some are not.

To cut through the marketing hype and rhetoric, Cutter Consortium conducted a survey of application package users that focused on their expectations and experiences. This article provides an analysis of these survey findings along with related conclusions on the successes and challenges in deploying application software packages. It also presents a set of recommendations for organizations needing to streamline future package selection and deployment initiatives.

WHAT IS APPLICATION PACKAGE SOFTWARE?

Application package software, or simply an application package, is a collection of software programs that have been developed for the purpose of being licensed to third-party organizations. Application packages are generally designed to support commonly performed business functions and appeal to multiple types of user organizations. Although a package may be tailored to a user's specific needs through parameters or tables, the software itself is not individualized to a given organization in the same way that custom-designed, custom-coded software would typically be tailored.

Read the complete issue!

Download your complimentary copy of Fitting Off-the-Shelf Applications to Meet Your Needs and discover the benefits of adopting application packages, the required software changes, and some of the common difficulties. Read It Now.

Examples of application packages include accounting systems, human resources software, and enterprise resource planning (ERP) software. Application software, within the context of this discussion, does not include all-purpose tools such as Excel, Quicken, or Word. Spreadsheets, databases, and word processing software are all-purpose tools that perform application functions -- in the hands of sophisticated users.

APPLICATION PACKAGES: A BRIEF HISTORY

Application packages perform business-specific functions, as opposed to operating system or environmental software such as IBM's zSeries operating system or Windows NT. Most important is the fact that while operating or environmental software upgrades are typically transparent to the business community, application package upgrades are not.

Application packages first became available during the mid-to-late 1960s when financial accounting and payroll software was made available for lease from companies such as McCormack & Dodge. Early application packages focused on accounting or financial solutions. Application packages eventually offered manufacturing, customer management, human resources, and various other functions.

Many of theses systems were designed using the same principles as inhouse legacy applications. Early packages focused on a single function within a corporate or government hierarchy, such as accounting, and were built using older software languages and programming techniques. This has caused application packages to become inflexible and increasingly hard to fine-tune to customer requirements.

Application packages must be integrated into inhouse application and data architectures. As a result, inhouse programming teams have had to modify application packages, and this has resulted in difficulties in reintegrating vendor upgrades back into the package software. Falling behind current releases of a given package increases the challenge of upgrading packages exponentially.

Over the past decade, a variety of ERP packages were released that appealed to executives frustrated with inadequate responsiveness from inhouse programming teams. Many times, the decision to acquire and install these packages is driven by senior management, based on promises from vendors stating that the package will provide a low-cost way to rid themselves of legacy systems while delivering new business functionality. The promise of application packages, however, is contrasted by reality in many situations -- as our survey shows.

SURVEY BACKGROUND AND ANALYSIS APPROACH

The survey was commissioned to determine the benefits and challenges associated with deploying and integrating application packages. There were 76 respondents from a wide range of industries, government agencies, and nonprofit centers. The main goal of the survey was to cut through the anecdotal discussions about packaged software and expose the realities of what organizations are actually doing when it comes to deploying and benefiting from application packages.

The approach taken in analyzing the application package survey involved comparing the perceptions and expectations of what organizations thought a given application package could provide versus the actual results experienced by respondents. This focus included:

• Adaptability of the business to align the package with business processes
   
• Ability of IT to integrate the package with other applications and related data
   
• Overall success in terms of implementing and benefiting from the package
   
• Customization requirements versus the perception of how much the package would need to change prior to implementation
   
• Overall satisfaction with a given package from a best practice perspective
   

APPLICATION PACKAGE CATEGORIES

The survey sought to determine which types of application packages an organization has licensed and deployed. Application package categories represented in the survey range from enterprise software to more specialized, off-the-shelf offerings (see Graph1 in the Survey Data section):

• ERP software is a cross-department, enterprise-wide package that provides an integrated set of functionality to user organizations. This is the most commonly used software, used by 70% of survey respondents.
   
• Human resource management (HRM) software manages internal payroll, benefits, insurance, and other functions related to administration of inhouse staff. HRM software is in use by 45% of respondents.
   
• Customer relationship management (CRM) software addresses customer management functionality and is primarily used by customer-facing departments. CRM software has grown in popularity and is in use by 40% of the respondents.
   
• Supply chain management (SCM) software supports the complex supply chain management function and is commonly deployed by manufacturing and other organizations reliant on third-party goods and services. SCM software is in use by 16% of the respondents.
   
• There are a variety of other specialty products on the market. For users of any of these products, the survey included a category called commercial off-the-shelf software (COTS), in use by 28%.
   

SURVEY PROFILE

The makeup of survey respondents includes a wide range of organizations: manufacturing firms (16%), government agencies (12%), financial institutions (12%), publishing/media firms (10%), consulting companies (12%), transportation/distribution providers (6%), healthcare (3%), and other industries.

In addition, respondents provided input for varying cross-sections of their organizations. For example, 30% of respondents represented their departments, 22% represented a single division, and 46% represented the entire company. IT organization size ranges from very small (fewer than 50 employees) to very large (more than 1,000). However, 37% of respondents have between 50 and 500 IT professionals, while 12% have more than 500 IT professionals. (For more details on survey demographics, including location and revenue, see page 22.)

The respondent profile indicates that application packages are in use by companies and government agencies that range from very small to very large. These organizations cross a variety of industries and regions that have large inhouse support infrastructures as well as smaller support structures. In other words, application packages are not limited to organizations of a particular industry, demographic, or size.

APPLICATION PACKAGE DEPLOYMENT EXPERIENCES

This section discusses the experiences of the organizations that implemented one or more application packages. This analysis is focused on responses from those that either deployed or attempted to deploy a package and the issues they encountered.

The first question used to qualify respondents was to determine the degree to which an organization has deployed an application package (see Graph 2). Twenty-eight percent of respondents have either fully deployed an application package or its core package functionality, while 25% have partially deployed package functionality. Another 4% have deployed packages that were later pulled from production, while 3% have failed in their attempts to implement a package. The remaining 12% have never deployed a package. (Note that these 12% did not enter responses in the remaining survey questions.)

This sampling not only provides the foundation for the remainder of the survey but also suggests an important aspect of package utilization. Only 28% of respondents fully deployed an application package. This is evidence of the fact that organizations do not fully utilize application packages. This means that management expectations should be adjusted to realize that, for whatever reason, a company may only utilize a portion of the capabilities contained within a given package.

Implementation Challenges

The implementation challenges associated with application packages are best exemplified by the degree of modifications required to the package. While the business process and organizational alignment issues are addressed later in this article, the physical customization of a package can be driven by many factors. When asked about the degree of customization required, only 2% of respondents did not change the package at all, while another 10% only modified it slightly (see Graph 14).

On the other hand, nearly one-quarter of respondents modified their packages a great deal, while another 54% modified them somewhat. When asked whether their organizations had planned to make these changes, only 14% of respondents said they had anticipated extensive changes, while another 36% expected moderate changes (see Graph 16). In comparison to the 78% that applied a great deal or moderate changes to their packages, only 50% expected to apply this degree of change to their packages.

The survey additionally sought to determine when these changes were applied, as shown in Graph 15. Close to half (44%) of the respondents applied all or most of their application package changes prior to implementation. Another 47% say that they applied changes both before and after implementation. Only 9% applied all or most of their changes after implementation. From a planning perspective, this is an indicator to management that package customization is typically required prior to the deployment of a given package.

When asked if the degree of package customization exceeded expectations, nearly half of respondents (49%) say that the changes exceeded what was anticipated and what was budgeted for the project (see Graph 17). Another 45% believe that the changes were about what was anticipated/budgeted, while only 6% think that the changes were less than anticipated/budgeted. These findings show that the perception of senior management that packages can be dropped into an organization with little change is typically inaccurate.

These findings additionally show that management must be more realistic about the degree of package changes required and must build these requirements into plans and budgets. Further, management should increase budgetary allocations for package implementations in many cases to reflect the reality that almost half of survey respondents spent more than they had anticipated on package deployment.

Integration Challenges

A second challenge related to implementing an application package is the impact to the surrounding environment. The survey found that 31% of respondents expended a great deal of effort integrating application packages with existing inhouse applications, and another 46% spent some effort on existing systems integration (see Graph 12). In addition, over half (53%) spent a great deal or at least some effort on integrating a package with other application packages.

Another 45% of responding organizations expended a great deal or some effort to integrate a package with middleware applications, while an additional 36% spent a great deal or some effort to integrate the package with business process automation software. Finally, 42% of respondents had a great deal of difficulty in integrating existing data into a package, while another 39% experienced some difficulty. This is an essential step with almost any package, and these findings indicate that data integration challenges are nontrivial.

Even more revealing was the fact that 34% of the surveyed organizations found these migration and integration tasks to be extremely difficult (13%) or quite difficult (21%), as shown in Graph 13. Another 37% found at least some difficulty in integrating an application package into the existing systems environment. Five percent of respondents found that integrating a package was not a difficult task.

These findings expose one package implementation challenge that can be extremely difficult but that management may not have anticipated. Integrating an application package into complex computing environments layered with legacy systems and data stores, other packages, middleware, and business process automation tools is not a trivial exercise. These findings further suggest that management may not have fully mapped the capabilities of the packages that have been required with the existing IT environments into which these packages must be integrated.

USER BENEFITS: EXPECTATIONS VS. REALITY

While implementation challenges are important from a planning and budgeting perspective, the functionality and usability of an application package from a business perspective is even more critical. This section discusses the perceived business benefits anticipated by organizations and compares and contrasts these perceived benefits with the results achieved by the organization as the application package was deployed.

Projected Business Benefits of Package Deployment

Based on the survey findings, the main objectives of buying an application package are to improve organizational performance and to ensure consistent quality across the business. These findings are based on the percentage of respondents citing the following survey items as important or very important (see Graph 4). Note that the percentage of respondents for each category is shown in parentheses:

• Desire to improve organizational performance (90%)
   
• Quality assurance across the business (85%)
   
• Benchmarking against functional best practices (50%)
   
• Security and integrity of the data resource (72%)
   
• Benchmarking against industry best practices (37%)
   
• Fear that competition is leaving you behind (29%)
   

These findings indicate that organizations are seeking productivity and quality improvements across lines of business with an eye toward capitalizing on industry best practices and improving overall security and systems integrity. This is reinforced by the fact that a related finding indicates that the adoption of best practices motivates 70% of the respondents to seek package-based solutions (see Graph 3).

Respondents were asked to share what they consider to be best practices based on several survey selections (see Graph 5). Responses suggest that superior business processes that will be implemented through using the software is a key factor (60%), along with having software templates to avoid "reinventing the wheel" by building custom applications (60%). Other factors include bringing external practices into the organization by using the application package (39%), regulatory factors (33%), and risk management (31%).

Actual Benefits of Package Deployment

As shown in Graph 6, a great deal or quite a lot of the actual benefits gained from package deployment include operational efficiencies (51%), customer satisfaction (34%), strategic advantages (33%), revenue collection/generation (32%), cost reduction (27%), and resource reallocation (24%). These findings show that gains in operational efficiencies and customer satisfaction are very real for organizations that deploy application packages. Given these findings, management should strongly consider these benefits as key justifiers when building the business case for an application package.

When asked of the usefulness of a best practices model as embedded in the application package, respondents indicate that the following are either very useful or quite useful (see Graph 7):

• Improving internal operations (55%)
   
• Facilitating business process automation or integration (53%)
   
• Facilitating cross-organizational collaboration (46%)
   
• Improving customer resource management (38%)
   
• Improving strategic data management and use (36%)
   
• Improving knowledge production and management (32%)
   
• Improving supplier/distribution chain management (30%)
   

These findings further confirm that improving internal operational efficiencies is a benefit of deploying application packages along with business process automation and organizational collaboration across business lines. These second two items are related so there is no surprise that they ranked close to each other.

These findings additionally support the notion that packages are useful for managing customer resources and strategic data management. Ranking slightly lower, however, are the best practice benefits related to knowledge management and supplier/distribution chain management. Clearly, the internal operational gains are a bigger advantage over external customer- and distribution-related gains.

Application Package/Business Process and Organizational Alignment

The flip side of the business-benefits equation has to do with the adjustments that an organization must make to its entrenched business processes and organizational infrastructures.

When asked about the extent to which respondents modified organizational and business processes to fit the package, three-quarters modified their business processes somewhat (53%) or a great deal (22%), as shown in Graph 8. Only 2% of respondents did not modify business processes to adapt to the package.

A followup question sought to clarify the types of modifications that organizations enacted as a result of implementing an application package (see Graph 9). Respondents enacted process flow changes to complete business activities a great deal (30%) or somewhat (35%). Half of the respondents enacted changes to organizational roles and responsibilities, while another 36% enacted a great deal or moderate degree of changes to organizational reporting relationships. Departmental or functional changes were applied by 35% of the responding organizations.

These findings support the notion that if management plans to deploy an application package, then organizations must plan on adapting their business processes and organization infrastructures to those packages.

Organizations applied these changes both before and after the implementation of the application package: 24% of respondents made organizational changes prior to implementation, 19% made changes after implementation, and 57% made changes both before and after implementation (see Graph 10). This indicates that organizational adjustments resulting from the application package implementation project are ongoing activities that management must plan for and manage carefully.

More importantly -- as indicated in Graph 11 -- is the degree of difficulty posed by these organizational changes. If, for example, there are simply organizational adjustments needed to conform to an application package, management would be able to budget for and deliver these changes without significant business disruption. Difficult changes, however, are likely to cause more business disruptions.

A significant percentage of survey respondents claim that these changes were either quite difficult (30%) or extremely difficult and time-consuming (17%). Only 6% of respondents that applied organizational changes report that organizational changes were not difficult. This is significant when one considers that 98% of respondents applied organizational changes as a result of implementing an application package. In other words, virtually every respondent had to apply organizational changes, and almost all of those respondents consider these changes to have been moderately difficult, quite difficult, or extremely difficult and time-consuming.

User-Driven Impediments to Package Deployment

One key indicator as to the usability of an application package and its ultimate success is the receptiveness of the business community and the impediments encountered within the user environment. The survey uncovered several interesting points in this regard.

Almost half of the respondents (47%) say that users attempted to introduce "add-ons" to supplement the functionality of the package (see Graph 19). This indicates that almost half of those organizations implementing a package had users that did not feel the package was good enough in its off-the-shelf form.

An even more telling finding is that more than 60% of respondents report that users resisted the removal of existing application systems that replicated the functionality found within the package. In other words, users favored their existing applications over the functionality provided by the application package. This is a critical indicator that management may not have investigated the applicability of the package to business requirements or not understood the business requirements in the first place.

One additional challenge is the issue of user-based "shadow" systems. Over half of all respondents (51%) had problems with user-base applications written in Excel, Access, 4GL, or other custom software. These systems are rarely discussed, yet are significantly problematic given that almost all business units perform certain key functions beyond the reach of IT. These systems are an impediment to package deployment and should be identified during the initial planning and assessment for package deployment.

Realizing Application Package Benefits: At What Cost?

The bottom line for determining user benefits involves the difficulty in realizing benefits from an application package and the extent to which best practices embedded within an application package have actually helped an organization meet its goals.

Regarding the difficulty in realizing benefits, respondents report that benefits from the application package have been extremely difficult to achieve (10%) or quite difficult to achieve (30%), as shown in Graph 18. Only 18% of respondents report that it has been easy to realize benefits from their application package, while 42% report that it has been neither easy nor difficult to realize benefits from their application package.

The fact that 40% of respondents report that realizing package benefits has been quite or extremely difficult and only 18% report that it has been easy to realize benefits corresponds to earlier findings related to the degree of organizational change and package customization required.

Finally, respondents were asked to what extent best practices as embedded within the application package have helped the organization meet its goals (see Graph 20). Only 12% claim that the package helped a great deal, while 48% report that the package helped somewhat. In contrast, 18% indicate that the package did not help much or at all, while another 22% are neutral on the subject of how much the package helped meet organizational goals.

Clearly these results did not live up to expectations given the survey findings related to the degree of application package customization and the degree and difficulty of organizational changes needed to adapt business processes and infrastructure to accommodate the application package.

CONCLUSIONS AND RECOMMENDATIONS

The lessons learned from the application package survey are significant and point to a series of recommendations that organizations can pursue to achieve greater benefits from their application package investments.

Summary

A summary of conclusions from this report is presented below:

1. The majority of responding organizations are users of ERP systems but additionally use a combination of other application packages. These include CRM, HRM, and various other off-the-shelf software packages.

2. Application packages are, according to this survey, only fully implemented 28% of the time. While this is not necessarily a sign of success or failure, executives should note that a package is unlikely to deliver or be deployed to the full breadth of capability that a given package provider may be suggesting.

3. Package customization requirements were extensive and exceeded the expectations of survey participants. This finding suggests that the time and budget allocations for package customization efforts are extending beyond the project parameters anticipated at the onset of the project.

4. Integrating application packages into complex computing environments is difficult and time-consuming. These findings could be the result of not fully mapping package capabilities to existing IT environments, including business data, existing systems, middleware technology, and business process automation solutions.

5. One telling finding is that users continue to favor their existing applications over the functionality provided by the application package. Users also like to hold on to their shadow systems that have been user-developed to surround core applications. This is likely an indicator that management may not have investigated the applicability of the package to the business requirements, or it may not have understood the business requirements in the first place that the package was to address.

6. Organizations are seeking productivity and quality improvements across lines of business to leverage industry best practices. In an attempt to meet these requirements using a package strategy, organizations had to modify their business processes in favor of the business processes embedded within the application package. In addition, respondents had difficulty implementing changes to their business processes. This finding not only signals a potential for budget overruns but also points to why only portions of certain packages are implemented and why users prefer their legacy applications over the package application.

7. Virtually every respondent had to apply organizational changes, and almost all of those respondents considered these organizational changes to be somewhat difficult, quite difficult, or extremely difficult and time-consuming. In other words, companies are being forced to change how they operate to align themselves with these application packages. This may be fine with some companies, but other organizations may have not understood that a software package was dictating how they were going to operate.

8. Realizing the benefits of these packages was a challenge for many respondents. In fact, 40% of respondents report that realizing benefits has been quite difficult or extremely difficult, and only 18% report that it has been easy to realize benefits. This corresponds to earlier findings related to the degree of organizational change and package customization required.

9. Organizations are not meeting the objectives envisioned when they initially decided to obtain an application package and are not gaining bottom-line value commensurate with the challenges associated with the implementation effort. This is the most critical finding because it suggests that there is a serious gap between what organizations think an application package can deliver and what it ultimately does deliver.

10. There are real benefits to be derived from application packages as long as organizations can manage expectations and cost-effectively deliver this value to the business community.

These findings expose the great conundrum of the application package strategy. Executives want to take advantage of best practices through the acquisition of application packages, but implementing these best practices across an enterprise tends to be more difficult, more time-consuming, and more costly than first anticipated. In addition, the business users, supposedly the beneficiaries of these best practices, are either demanding changes to these packages or resisting these packages in favor of legacy systems and user-based systems.

The bottom line is this: Organizations are making major investments to customize application packages, integrate those packages into surrounding IT environments, and adapt business processes and organizational infrastructures to adapt to these packages. Yet the benefits accrued from these investments are delivering less than what the business community had anticipated in a variety of best practice categories.

Recommendations

What can be done about this? Here are four recommendations that could address the obvious challenges of application package selection and deployment initiatives:

1. Spend more time on up-front analysis, mapping business process, organizational, data, and functional requirements for your organization to the capabilities of the package. This analysis should include a review of business processes, a current systems assessment, analysis of existing data requirements, examination of user-based applications, and a mapping of the findings to available package options.

2. Organizations must do a better job uncovering business requirements prior to package acquisition. This involves a needs analysis with the business users who will be using the application package. Too many times the business community is not involved in selecting a package or ensuring that the package maps to business requirements.

3. Management should review increasing budgetary allocations for application package selection and implementation projects. This is based on the fact that close to half of the survey respondents spent more than they had anticipated on package deployment.

4. Executives must adjust expectations of what packages can deliver and the level of investment and organizational retooling necessary to achieve these objectives.

Read the complete issue!

Download your complimentary copy of Fitting Off-the-Shelf Applications to Meet Your Needs and discover the benefits of adopting application packages, the required software changes, and some of the common difficulties. Read It Now.