top of page

Package Evaluation, Selection & Implementation

The compilation of potential packages that exhibits functionality similar to the required functionality by means of GAP Analysis.

PESI Manual

Package Evaluation, Selection & Implementation Definition

PESI

The projects associated with the establishment of a package solution all exhibit a similar structure. Although the efficiency of the project execution may vary, or the definition of the various phases and their deliverables may be vague, or addressed somewhere else as a sub-phase, it is fair to assume the following phases:

PESI Definition.png

Package Evaluation

The compilation of a list of potential packages that exhibits functionality similar to the required functionality. This is usually obtained by researching the competitor environment and in some cases by direct Request For Proposal (RFP). The RFP typically contain a superficial description of the company profile and required functionality. Hopefully, some sort of business analysis has been performed prior to specifying the package requirements.


The actual evaluation concerns the suitability of the package as a solution and not the entire offering surrounding the package, i.e. stability, vendor offering, product direction, etc. A mapping of package functionality, procedures and data-definition (semantics) usually suffice in this phase resulting in a short list of potential packages. This process is better known as gap analysis and delivers the areas or issues that need be addressed if the business is striving for a total solution. The short listed packages has proven their suitability as an application solution, however no research or attention has been given to the suitability as a total business solution, i.e. the packages on the short list seem suitable only in isolation.

Package Selection

From the short list, each candidate package now has to be measured in context of the total vendor offering, typically the applied criteria are things like support guarantees, vendor reliability, product direction, upgrade procedures, etc. Obviously, the offering yielding the highest performance in this exercise is selected and negotiated for purchase.


Of vital importance, however seldom performed, is the determination of severity of the package gap. A simple interface gap to a legacy investment could pose enormous development costs if for instance the technology to bridge the gap is not market-available. True to the old saying of a chain is as strong as it weakest link, the package gaps need qualification.

Package Implementation

This almost always takes place in project-mode. The project is traditionally defined by the implementation team and business forfeits a substantial amount of control. The usual project management aspect is introduced and more or less governs the deployment of package functionality and modules as suited most comfortably to the implementers. The criticality of selected functionality is seldom addressed and is usually deployed in terms of the architectural inter-dependency of the package.


Phases in this project are conceptual designs, detailed designs, prototyping, acceptance testing and production. In most projects of this nature, the responsibility in terms of design resides with the implementation team who gracefully discards the business specifications after implementation.


Objectives, milestones and measurement objectives are defined from a resource management perspective
and not from a business support view.

User Training

The package is implemented and users now have to gain proficiency in package use and maintenance. The vendors are best equipped for user training as all the product knowledge and training needs resides with them. Users are scheduled and receive training, again on the package in isolation. Ideally the needs of users in terms of the business should be incorporated in the training programme. The associated benefits would justify almost any investment in combined training; business awareness would be promoted, an understanding of the impact of user actions is gained and the package as support tool in the context of the business minimise individual threat.


Although minimal in definition, this framework provides a good basis for defining an improved approach - some issues have been mentioned. Integration aspects are also addressed within this framework definition.

Package Product Risks, Pitfalls & Considerations

Package Product

Continuity

The requirements analysis, package evaluation, selection and implementation, training and maintenance is performed in discrete steps. Selection, as sometimes practised, is not always preceded by evaluation. Similarly, implementation is not always preceded by implementation design. This implies that the deliverables from a particular phase is not necessarily an input to the next. If this is the case we could expect an amount of duplication in terms of analysis and research in the respective phases. In principle, any specification, deliverable or work document produced in any of the phases should be applicable and useably applicable to any of the phases. Lack of continuity is the primary reason for the loss in
specification, lack in re-use and overlooked implementation design, all of which has an undesirablefinancial implication.


In short, if an analyst depicts the distribution packaging process, the same depiction should be used by evaluators, selectors, designers, implementers, trainers and support staff. Thus, continuity is ensured - not present in most approaches.

Maintenance Costs

The culprit being package complexity, one would expect a higher investment in analysis & design to be the norm. Consider the following reality: The sales event in a system is architecturally dependent on the definition of products, co-products and product qualities which in turn is dependent on the definition of quality types. Now, imagine that on completion of the package implementation the quality officer realises that the perceived definition of quality types is not correct!. Not surprising the most feared words in any package implementation is: ‘I have been thinking’. As a result of the overlooked analysis subject, the definition of product qualities, pricing procedures and possibly products has to be changed. This has an immense effect on the project cost and morale.


The reality is, thorough analysis has to be performed prior to even evaluating the package solution. A higher expenditure at the onset is therefore introduced, compared to maintenance cost however, the total at the end of the line is substantially reduced.

Graphically, the scenario can be depicted as:

Cost of package selection.png

Compromise in terms of Strategic Differentiation

Probably the strongest argument against package solutions is strategic differentiation. In an application architecture that has such a high level of integration, how can one ensure that the package, when implemented in my environment will accommodate the factors that differentiate me from my competitors, when they happen to implement the same package?


There is no silver bullet solution, possible strategies include:

  • Scope differentiators outside the scope of the package solution and develop the required application support.

  • In the relevant areas, employ the package as warehouse, i.e. implement the package in a manner such that strategic applications can be deployed as an architectural layer on top of the package.

  • If the package architecture permits, invest in the customisation of the package.

The issue here is that strategic differentiators need to be considered when designing the implementation. If this is overlooked, the package may be the reason for compromising my differentiating edge.

Lack of Corporate - Wide Integration

 

Lack of corporate integration, lack of enterprise blueprint, lack of architecture, seamless integration mechanisms – are all manifestations of the same issue. Wherever there is more than one application present in the application layer we need to ensure seamless integration by deploying the applications on a common architectural foundation. This is hardly ever the case in the current package scenario. Instead, the deployment is based on the current environment definition, i.e. hardware, platforms, database architectures, etc. 

Resulting in either package discard, or the introduction of yet another layer in the environment level to ensure transparency (incidentally, a primary argument for warehousing), corporate architecture is a definite pre-requisite for package solutions.


This concept is further illustrated by means of graphical depiction:

Corporate wide.png

Premature Package Decisions

Package decisions should not be made until a comprehensive-as-possible suitability has been assessed. Needless to say, the wrong solution deliver little business benefit and even less return on investment.

Unfortunately, the reality is that the evaluation of packages is costly. To define the scenario more clearly, consider the following:

  1. Without thorough evaluation, a wrong package decision is probable.

  2. An over-expenditure in the evaluation phase may be overkill in terms of the required solution.

  3. The multitude of combinations of industry-type and package offerings does not allow for a clear definition of where to define the point where package evaluation has achieved its objectives.

The only way of ensuring that we do not overspend on evaluation and yet not derive at premature conclusions is to define our criteria correctly. In fact, the objectives of defining criteria should be to disqualify package offerings as quick as possible and as credible as possible.

Legacy Exposure

What is legacy? In a real-world definition it is those systems or applications that are reason for comments  like,


“Well, it is there - we have to protect our investment”
“Yes, I know there are more viable solutions available, but unfortunately, it is still a business critical
system.”
“If only we can we find an easy way to go live quicker on a more trendy solution, we can get rid of the
white elephant.”


Very few package-specific implementation approaches or methodologies accommodate legacy investments. Legacy is a fact of IT-life. If not addressed, we may endanger the investment, which will probably lead to the package being customised, a serious cost consideration if legacy is not accommodated, encapsulated and controlled within the package scope.

Package Inertia

The issues here are (i) the need for business change and (ii) the ability to change within the package context. A package that is in size comparable to SAP, JDEdwards or Triton has a typical implementation period of 6 to 8 months without data migration from current to target application. Imagine the effort required in terms of package change were we, as local retailer, venturing into international markets.


Multi-currency financial transaction support, shipping logistics and market knowledge bases need to be scoped for the package change. If the window of opportunity is small, i.e. we have to commence marketing abroad within one month to acquire a critical market share, the package should ideally change within the same window.


Fine in saying that a package is flexible in implementation, but is it implemented flexibly? Analogous, in countries achieving freedom of speech, it often becomes a case of no freedom after speech. Package customisability delivers flexibility in implementation, but not necessarily flexibility after implementation.


The ability to adapt the package is seldom a design objective, hence the high inertia factor.

Unrealistic Project Estimates

Estimates are mere estimates. Project definitions have the tendency to subtly hide the involved intricacies of the task at hand. One possible solution is an enhanced understanding of the exercise. The same arguments presented in high maintenance cost as pitfall, is applicable here. Too little focus is placed on the analysis and design of business and implementation.

Misaligned Package Solutions

Simply stated, the implementation has to be aligned with the strategic positioning of the business. In application, business specifications and the resultant package requirements should be defined on the ideal level in the context of the strategic positioning of the company. This is not the concern of the package implementation team, it is a statement about the context of package projects.

If alignment is not ensured the package solution will over time render itself less and less beneficial to the business. Hence, the short-term benefit delivered in package solutions of today.
 

Categorically stated, the only solution to ensure alignment is to execute the project within the context of proper business engineering exercises such as strategic positioning, business strategic alignment and the establishment of corporate-wide architecture.

Pesi Solutions.png

Lack of Package Understanding & Stakeholder Commitment

These are change management or organisational behaviour issues. Buy-in from stakeholders is a critical success factor for any package project. After all, they form the source of package requirements and the users of the solution. We need to promote an understanding of the role, benefit and positioning of the package in the business, if not, resultant project characteristics may include:

  • Incompleteness, incorrectness in package specification.

  • Incomplete criteria sets (i.e. criteria sets lacking in substantial ground for decision making).

  • Refusal in assistance with implementation.

  • Reluctance in training and usage participation.

Emphasis in solution is placed on:

  • Up-front positioning of the package as solution

  • Executive commitment

  • Dedicated Change Management

bottom of page