INNOVATE. INTEGRATE. TRANSFORM.

Business Solutions with SAP

ERP Software: Are Modifications Always a Bad Idea?

January 22nd, 2010 by

Business and Technology CoordinationSoftware modifications must be discouraged but sometimes they make perfect business sense. Remember, software exists to support the business, not the other way around.

As an inexperienced project leader back in the 1980’s, I once informed an executive at a large aerospace manufacturer we were going vanilla with our enterprise software implementation. Absolutely NO software modifications or enhancements allowed I proclaimed! His response stayed with me and still rings true today…

“Steve, you mean to tell me we are going to allow a one million dollar software package dictate how we run a fifteen billion dollar business?” I was lost for words. Finally I said, “if we modify the software, future upgrades could be more difficult to implement”. His response “so what, I need to run my business”.  The lesson is…..you need what you need. Software is intended to support the business, not the other way around.

Make no mistake; if you can really go vanilla do it. I am not encouraging software modifications because they take time and cost money. However, regardless of what the sales people tell you, no software package is infinitely flexible and configurable. At the same time, we all know software must address the key business requirements. This “zero tolerance for modifications” philosophy is fine for those that do not have to live with the software limitations. So what is a project manager to do?

In many cases, software modifications are not a huge deal when properly controlled and managed.  After all, no one writes a single line of custom code until at least the project manager and the executive sponsor say so. In other words, proposed modifications should be well defined, business justified (vs. alternatives) and then approved by senior management (with a full understanding of project impact).  When executives approve a mod in this manner, they have made a conscious decision to expand scope, incur additional cost and extent the project schedule. There is nothing wrong with this since they did it for good business reasons.

The religion that software modifications are universally evil comes mainly from the software industry. In fact software vendors can make you feel like a criminal when you sheepishly tell them you modified the software (dumb old me). The reason is vendors want clients to upgrade their software and do not want mods or anything else to get in the way. The idea is to sell the client related software and plenty of consulting services with each upgrade.

While software modifications increase the difficulty of software upgrades, in many cases this issue is over-blown. This is particularly true when keeping the number and complexity of mods under control. First, whether we like it or not, many organizations never upgrade their software. Others may do it only once over the entire life of the system. Also, there are upgrade tools available today that make the process of retrofitting custom code much easier. Finally, do not assume the promise of future software functionality will replace the need for mods. Even if the functionality is delivered, do not be surprised if mods are required to make it work for your organization. Software vendors use buzzwords to describe functionality but when you take a hard look; many times the functionality doesn’t go far enough.

I will not discount the fact that some software vendors refuse to address customer issues associated with modified programs, and for good reasons. However, most vendors will assist when the issue is critical and push comes to shove. Also, keep in mind that some vendors will fully support custom modifications as part of their business strategy. Furthermore, the risk of compromising support from the vendor becomes less of an issue when enhancements are designed to minimize the impact on existing code and tables. Finally, no custom code should go into production unless it is thoroughly tested and then tested again (and maybe again).

Always schedule and budget with the understanding that some mods could occur. Do not have a line item called “software modifications” (this is politically incorrect and sends the wrong message-again no one is encouraging mods). Bake it into miscellaneous, contingency, or related project line items.

~~~~~~~~~~~~~~~~

Editor’s Note: 

Steve Phillips runs another blog at the IT Toolbox and offers some really great insight on doing technology projects.  Visit his site for more info.

http://it.toolbox.com/blogs/street-smart-erp

Related Posts:

Why Indexed KPIs are Critical for Business Performance and Success

January 21st, 2010 by

As I’ve written before not every metric for business or processes is a KPI.  Too many IT systems and too many companies define a departmental goal as a Key Performance Indicator creating unnecessary friction between other departments or areas of the company.

By using a weighted index you significantly reduce, and in some cases eliminate the competing requirements.

As part of a continuing effort on using key performance indicators for building a strategy focused organization I’m offering this illustration.

Fictitious Company ABC Inc. KPI Example

Let’s take a simple but very common example of how Key Performance Indicators are misused in business.  Using some very generic and very simple numbers to illustrate the problems with all of these “goals” being called Key Performance Indicators we will look at widget company ABC Inc. 

ABC Inc. has what they call a “KPI” metric for Production throughput of 100 units.  The production manager is given a goal to boost that metric to 110 units for a 10% increase in productivity.  This is what is measured and this is how the department is provided bonus incentives.

ABC Inc. has current on hand inventory of $1,000.00 and they likewise want to reduce inventory carrying costs by 10% or to $900.00.  Again, reducing on hand inventory is what warehousing is measured on and provided incentives for.

Right away there is an immediate conflict between production and inventory management.  If either of those areas gets out of synch it can create a bit of a mess.  You are trying to increase production throughput while pressuring inventory control to reduce stocks.  Now, let’s look further. 

ABC Inc. has a delivery department that is provided incentives to ship orders complete, 100% correct first time.  Now there is a conflict between shipping and production as well. 

Because production is narrowly provided incentives for throughput they will naturally try to optimize their scheduling to ensure greatest throughput, not necessarily the best process for fulfilling customer orders.  Production scheduling and customer service and inventory management and shipping are now in conflict because their “KPI” measures are at cross purposes–, they have competing goals.  Because inventory management has stock levels driven down there is insufficient stock for effective production builds.  Production suffers while the ability to ship full trucks is also negatively impacted and you incur additional freight, shipping, and handling costs. 

KPI Analysis for Success

This type of example is COMMON throughout business all over the world.  It is routine in business to have these competing goals, where incentives are provided, which many companies (and even software vendors, consultants, etc.) call key performance indicators.

The fictitious company  illustration could be continued to any number of process areas of any business in the country.  The idea is that if everything is a KPI then you create unnecessary competing demands and in some cases “mutually exclusive requirements” that can not be fulfilled. 

Many times one department will meets it goals and another department which is a dependent area in the same process chain will not, then you have a mess.  For example if production meets throughput requirements but inventory management is unable to reduce on hand stock you could end up in an inventory buildup problem.  Production capacity is increased while stock reduction is not improved.  Production may increase capacity by producing the “easier” products that do not line up well with customer orders and then shipping gets backed up.  Or shipping / customer service and inventory management may drive production requirements and then reduce production throughput meaning that while the orders that get shipped are at 100% complete, far fewer orders are shipping and revenue is dropping.

A KPI Index is the Answer to the Metrics and Goals Many Call Key Performance Indicators

As you can see from these examples a weighted index of each of these measures combined into a single KPI is more meaningful.  If bonuses or incentives are paid on the overall increase in the indexed KPI rather than the discrete departmental goals (other than possible merit awards) you are more likely to create inter-departmental cooperation.

Let’s say as a business you have a low backlog but high inventory carrying costs.  You may wish to weight each of the departmental goals accordingly.  This way you are still moving toward improvements in each area but are focusing attention on the areas that matter.  In this example you may wish to weight your on hand stock and 100% order fill rate higher than your production throughput.  By doing this you are providing the correct index for the overall business needs. 

By using the index and tying pay for performance programs to the index rather than a discrete departmental measure you cause the company to pull together in the same direction.  Instead of having disjointed goals which sometimes conflict with other departments each area would automatically pull together to push the overall KPI index higher.  If full truck deliveries are weighted higher than inventory reduction and production throughput then all areas would focus on that issue together.  However since they are also measured together, and since their measurement also contributes to the overall KPI score then these departments would try to find ways to achieve their own goals with an eye toward the higher scoring area(s).  This would encourage more teamwork and innovative process thinking rather than the silo focus that departmental goals create.  In other words creating the indexed KPI also creates cooperative dependencies between departments.

By using indexes and weighting them according to the importance to the business you are directing your company’s energy where it is the most meaningful.  Together with this you may wish to craft and communicate a policy that the weighting for each area will be revisited and may change either quarterly or annually depending on business needs and circumstances. 

It is important to keep in mind that if your KPI(s) are used for any type of pay for performance program that you communicate reasonable expectations of weighting changes.  Without that clear communication and expectation setting in the beginning you will quickly lose your employees’ trust and undermine your KPI initiative.




Popular Searches:


  • indexed metric
  • indexed metrics
  • kpi indexing system
  • mckinsey group 4 kpi critical for business

Related Posts:

Achieve Breakthrough ERP, SAP, or IT Project Success: 1 of 4

January 18th, 2010 by

Series Introduction Note:  The next 3 parts of this series contain step by step instructions and pointers on managing the RFP process (Part 2), conducting the vendor selection (Part 3), and then how to use the blueprint process to correct any discrepancies and lay a solid foundation for succes (Part 4). 

 R3Now.com - Breakthrough ERP, SAP, or IT Project Success

If you are an IT decision maker and you’re tired of pressure to achieve results that your system vendors or integrators can’t seem to deliver, use these steps to get the most for your money and achieve breakthrough results. Much of this article can be applied to any major project effort your company undertakes.  While some of the suggestions offered here can seem harsh or difficult from a people management perspective they can make a huge difference in your career prospects, credibility, and any future budget requests. 

Neutralizing the vendor proposal scams, clearing the smoke and looking past the mirrors for your ERP, SAP, or technology project requires a little clarity up front before you start your vendor selection.  It is possible to achieve breakthrough business results using technology and business software systems like SAP if you approach your project with the right perspective. 

That Brown Smelly Stuff they are Selling is NOT Chocolate

Promises, promises, sales scams, smoke, mirrors, and vendor proposals, you’ve heard it all before–, the sales pitches promise you a chocolate pie but all you get is some very expensive, and very smelly, dark brown fertilizer.

What these sales pitches never tell you and never deliver on is the “how” to make all of those chocolate pies.  As former General Electric front man Jack Welch calls it “the secret sauce.”  Sure, they describe some super-special secret sauce, they tell you all about their wonderful “Willy Wonka Chocolate Factory” but they only describe a fictitious place, an imaginary state of being. 

Fairy Tales and Vendor Selection Promises

I’ve been on lots of projects where someone dreams up what I call “mutually exclusive requirements.”  These are things that are completely contradictory, they are the old “either / or” logic gates.  You can have one, or the other, but you can’t have both.  Lots of presentations have the sales person delivering tons of promises that no one can deliver on.

Then reality sets in after you’ve signed the contract and the sales person leaves.  A strange odor begins to permeate the whole project.  But this usually happens very slowly over time so that you go through the “boiling frog” syndrome.  You smell a little here and a little there, but like most people you get used to it and think this is just the way it is.  You dismiss early signs that there may be something wrong, or you chalk it up to isolated incidents.  After you transition to a live environment and it is too late you suddenly realize it was not a chocolate pie you were getting but something else that is brown and smelly. 

When someone on the project has to deliver on the sales person’s promises some members of the vendor selection team are no longer involved in the day to day project delivery of those sales promises–, even if they are they often forget everything that was promised.  They only remember a few of their pet peeves they saw or heard during the presentation.  When the sales person describes lots of what sounds like chocolate you end up with lots of brown smelly stuff that is NOT the chocolate you were promised!

After the sales pitches and the promises what you end up with are blown technology project budgets, blown technology project timelines, and buggy custom-coded solutions for “off the shelf” packaged applications.  Fear not, there ARE things that can be done to reduce these results that are so very common with technology projects.

And even if you are misled by a vendor there are still things that can be done after you start with that vendor to ensure you don’t get taken.

SAP, ERP, and Technology RFP – Getting the Most Out of Your Technology Investment

There are several opportunities in early stages of your SAP, ERP, or other technology project to lay the ground work for genuine breakthrough results.  Along with the breakthrough results these early steps can help to set the tone and foundation for a very successful on time and on budget project.  There is just no reason for companies to continue to get taken by some of the unscrupulous or questionable practices in the technology and IT marketplace.

Even after you have selected your system integrator or implementation vendor you still have several chances to make sure they deliver their very best–, the very best tools, resources, and quality of workmanship.  If you change out questionable consultants early in your project then you will set a clear expectation of the caliber and quality of resources you will accept from your vendor.  Doing this early is the best time before they can do any serious damage.

General Patton once said that “War is Hell!” and business in today’s global economy is WAR!  The question you need to ask yourself is if you are in a war in the marketplace do you want raw recruits who are going to go through boot camp at your company, on your dime?  Or do you want veteran Navy Seals, Marine Snipers, and Airborne Rangers?  Raw recruits are usually cheaper, and that experience from those veterans comes at a cost, but who do you think will give you the best chance of winning the war for marketplace position?

Let me tell you, that Marine Sniper will hit his targets at 1,000 yards, but the raw recruits will not only miss, but in doing so will also give away your position and open you up to attack.  So in the end you decide which is more important.  You decide if it is better to take your chances or to take steps to make sure you’re not paying Navy Seal prices for raw recruits.

There are three key events or timeframes early in the project when you can create the best environment for breakthrough project success.  Two of these areas have no risk and at all and one of them contains a moderate amount of risk.  These three key events are:

  1. During business case development, RFP creation, and first pass rough project scoping.
  2. The actual vendor selection process, vendor proposal reviews, and system integrator contract.
  3. During and at the end of the blueprint process.

These key events contain several ways you can take control of your own business destiny and help to ensure the technology investment you make will move your business forward.

Four Part Series:

Achieve Breakthrough ERP, SAP, or IT Project Success: 1 of 4
Breakthrough Project Success: 2 of 4, IT Vendor Proposal RFP
Breakthrough Project Success: 3 of 4, Vendor Selection and Contracts
Breakthrough Project Success: Part 4 of 4, Last Low Risk Chance for Results

Related Posts: