Advice

by Alan Marrott Alan Marrott No Comments

System Support Costs— YOU CAN CONTROL THEM!

 

Three considerations before you buy:

Your business plans to purchase a mission critical enterprise software solution, what should you know?  Will the software meet your objectives?  How long will it take to implement the new system?  What will it cost?  Let’s focus on the last question.  There are three costs tied to the purchase: the software application, system configuration and future support fees.  Typically, the primary focus of software contract negotiation centers around the application cost.  That is often thought to be the largest financial commitment.  Less apparent and perhaps more costly, however, are the unanticipated cost overruns tied to application implementations, and the inevitable support required to update and maintain the system.

Many financial executives will tell you that what frustrates them the most about software purchases is the budget-busting cost overruns to implement and support them.  Before you agree to pay anything for a software system, you should lock in all costs to purchase, implement and support that system.  Some  vendors will likely argue, however, that this is not possible.  They will cite the many nuances, unique needs and unknowns each business or customer brings to the project.  That argument should generate the question, “Is that the vendor’s, or the potential customer’s problem?”

Know what you are purchasing:

Would an informed purchaser by anything knowing that it wouldn’t work?  Would you buy a new computer if you knew that it would only work “most” of the time?  Would you buy a new phone if you had to pay additional monthly fees to update the software behind it?  Would you purchase a new-build home if, after agreeing to the price of the home, it took several months longer to build than promised?  Would you agree to pay a higher at the time of closing for unexpected work?  Would you move into that house knowing that some of the appliances didn’t work, the roof leaked, and the foundation was already beginning to crack?  If not, why purchase a software application you can’t install in the time allotted, for a set cost, and will perform all the functionality it was promised to support?  Unfortunately, that happens every day.

Properly informed purchasers understand the importance of locking down both the benefits expected and the costs to achieve those benefits.  So, how can you accomplish that when you negotiate the terms of a software application agreement?  The contract should ensure full satisfaction of system operations for the price negotiated.  Next, the implementation cost should be set as a fixed price, regardless of the unknowns encountered during the process.  You would expect a vendor knows its business well enough to anticipate those.  Any deviation from that price must require the purchaser’s pre-approval, and allow the purchaser to kill the project if no approval is secured.  Finally, ongoing support costs should be offered as a set price, not based on fluctuating hourly support fees.  Beware of vendors who offer support, and bill by the hour.  That scenario creates inevitable cost uncertainties.

Hourly support fees serve two purposes.  They generate ongoing revenues due to product imperfections and limitations, while creating the false sense of comfort that help is just a phone call away.  Secondly, it reveals a vendor’s lack of confidence in its own product.  After all, if a product can accomplish all that it professes to support, those costs should be predictable.

Take control:

The solution to control these variable costs is straightforward.  First, ensure sure that you purchase a product that provides the correct solution (proof of concept) https://glocent.com/2020/02/.  Second, insist that the vendor support the application’s performance with a full guarantee.  Third, settle for nothing less than a support plan similar to Business Process Management as a Service (BPMaaS).  This ensures complete support for a fixed price.  Learn more about this support model at https://glocent.com

 

Don’t fall into the intentional trap of buying something that may never work, will cost more to implement and maintain than the purchase price, and will leave you feeling frustrated as long as you are forced to use it.

by Alan Marrott Alan Marrott 29 Comments

Five Justifications for Requesting a Proof of Concept

Incentive Compensation Management involves strategies and variables unique to every business.  Proofs of Concept ensure that these are effectively addressed when automating that process.

 

Unique business conditions, strategies and operations

    1. Packaged software solutions can be very useful, until they aren’t. When it comes to process automation, exceptions do become the rule. If your unique needs are not supported, how useful can the product possibly be?
    2. Expose empty sales pitches. Sales professionals typically follow a standard pitch. Don’t allow those pitches to distract you from your strategic objectives. After the pitches are made, confirm how your objectives will be met.
    3. WYSIWYG: What you see is what you get. If a vendor can’t show you what you need to see, don’t expect that it will magically provide what you want. If a vendor can’t demonstrate how its solution can meet your specific requirements it never will, or it will cost you a lot to make it possible.

Mitigate risk

    1. Successful change management requires effective Risk management. System users who experience failed or disappointing results soon realize that lost money may not represent the greatest risk. Lost time, damaged morale, and loss of trust usually prove far more consequential than wasted money.
    2. Leveraging a proof of concept should expose risks that can lead to unexpected consequences. If specific functionality can’t be demonstrated during the evaluation process, negotiate a specific cost for creating it. Decision makers should be able to enter into an agreement that prevents surprises. It’s your money. Protect it.
    3. Too often, packaged solution purchasers consider the size of a vendor when selecting a solution. Why? One reason used to justify this self-defeating approach is, if things don’t work out, you can sue a vendor with deep pockets. Rather than plan for the worst, effective decision makers should focus on purchasing the best. Entering into legal entanglements for months or years following a failed implementation just introduces new risks. A better strategy is to ensure that your selected system works before you buy it.

Effective collaboration

    1. Successful system implementations begin with purposeful collaboration. Often times, relationships between a vendor and potential customer change once an agreement is signed. Working through a preliminary implementation, by creating a proof of concept that demonstrates how a system supports your key functionality, can provide insights into what to expect in a long-term relationship.
    2. A proof of concept can benefit all parties. The vendor quickly discovers how actively a prospect will support the implementation process. The prospect gains insight into the capabilities of the packaged solution, and how willing and cost effectively the vendor addresses functionality gaps.

Successful Implementation

    1. When properly constructed, a proof of concept should guarantee a successful implementation. It should end with one clear conclusion. It works!
    2. A failed or delayed implementation creates a bad first impression that may not be easily overcome. Taking time to create a meaningful proof of concept minimizes destructive surprises following a product rollout. A system’s credibility can be lost during the initial days of your users’ experience.
    3. A properly designed proof of concept creates a useful roadmap for a successful implementation. Standard functionality is confirmed, missing functionality is identified, and the effort to fill the gap can be quantified.

Partnership founded on confidence and trust

    1. Glocent’s (http://glocent.com) objective and track record reflect a commitment to complete and enduring client satisfaction. We won’t implement Glocent unless we are confident that it fully supports your incentive management operations both in the present and the future.
    2. One of our international clients has used Glocent for over eleven years. Its satisfaction with the results led to a reference that generated another client, which has remained a happy customer for nine years, and just recently, another customer that began using Glocent last year.   Without genuine trust and confidence, such long-term relationships do not occur.
    3. Another Glocent client succumbed to pressure to adopt a sales performance management solution from one of the deep-pocket vendors after it skillfully tossed out a myriad of bells and whistles during the sales cycle. Eighteen months later, the former client called and asked for help. Glocent was back in full operation within weeks. The legal battle over the failed implementation took years to resolve.
No situation justifies acting blindly or making an uninformed decision. Time and effort spent before a decision is made are typically far less costly than the consequences that follow a bad one….
Top