Skip navigation

Obsolete inventory was always one of my favorite supply chain topics. Nothing starts the finger pointing faster than a reference to obsolete inventory. The beauty of it is that everyone's hands are dirty and thus everyone feels just in their accusations.


In my experience, the blaming usually began in purchasing and took the path of least resistance through the organization. Ultimately, a member representing each implicated group, purchasing, production scheduling, demand planning, product management, engineering, and sales, would get together in a room in order to determine what went wrong (i.e. who was really to blame) and hopefully to come up with a plan to use at least some of the inventory.


Rick Pay recently wrote an article on obsolete inventory " Consider This — Avoiding Obsolete Inventory" He identifies the root cause of obsolete inventory as uncertainty in supply and demand and then goes on to identify three tools to help:
1) Sales and operations planning (S&OP)
2) Auto-replenishment systems
3) “Ramp-up/ramp-down” discipline


I would add to Rick's root cause; I believe that it is our inability to respond to the inherent uncertainties in supply and demand that ultimately are to blame for obsolete inventory. I agree that the tools and disciplines identified by Rick will definitely help reduce obsolete inventory as long as they are approached in a manner that allows for easy simulation and collaboration between different scenarios.


I was fortunate to be part of a successful S&OP implementation that positively impacted many aspects of my organization. One of the noticeable side-effects was that the subject of obsolete inventory shifted from the blame game to a more civil collaboration. In fact, with the right tools, potential obsolete inventory was identified ahead of time followed by agreed upon action plans


Obsolete inventory went down, but almost as important to the individuals involved was the fact that they agreed and understood the reasons for any obsolete inventory that was created on their watch. The mystery had been solved.


Drop us a comment if you want to share your obsolete inventory story? Let us know how you are winning the battle with obsolete inventory.


Originally posted by jnafis at

Most manufacturing enterprises have a formal approach to planning and executing production. However, it seems that at a practical level, there is some combination of planning and executing as well as expediting (working to recover to meet late or potentially late demand).


I think that most of us would agree that ideally, we would have a sound plan where there is accurate demand (forecast and/or actual), adequate resources and capacities are in place both in-house and at suppliers, and all the supply chain is on board and executing to the plan. In reality, there is a lot of expediting that occurs, at least in my experience (the extent of whichdepends on the industry and the complexity of the products and the supply chain.) A lot of manufacturing companies even have a formal position with a job title something like "Material Expediter" or "Production Expediter" (although the actual job descriptions candiffer fromwhat I am describing).


What I have found in working with some customers who do a lot of expediting, is a basic lack of maintaining data accurately in their formal ERP/MRP system. A lot of the "planning" tends to occur off-line in Excel spreadsheets or other tools. This may work in some isolated areas, but from an overall enterprise perspective, much of the supply chain does not have visibility into these off-line plans. I correlate this to Project Management on a large project where there is no up to date project schedule that the entire project team can work to. Team members work tasks that they are directed based on meetings, phone calls and other types of somewhat ad-hoc communication.


This can be somewhat effective, but not having the formal MRP system reflecting the current plan disables the capability to orchestrate the entire supply chain and efficiently execute the plan. This leads to a lot of expediting rather than planning and executing. Why don't we always keep the formal MRP system up to date? There are lots of reasons, including:

  1. too time consuming;
  2. off-line tools are easier and more flexible; and
  3. certain processes or functionality is not supported in the formal system.


Anexample of # 3 above, is provided in a blog post from a colleague of mine called Do YOU have enough Supply? This describes a process to allocate limited supply to demands that recently, seems to becoming more prevalent in certain industries. A process like this may not be supported in the formal MRP system, so it is likely done off-line. Changing or enhancing the MRP system to support new functionality generally takes some significant time and money, and usually has to compete for priority with other fixes and enhancements needed.


I know that many of you willagree that this expediting approach is far from ideal, and also may say “not us, not me”. But I also know from experience that this occurs and sometimes with some very practical reasons. In situations like this, what can help solve the problem is a system with capabilities in a couple of key areas:

  1. Detect and report data integrity issues in the MRP system for clean-up
  2. Easily configurable to support additional planning functionality
  3. Available for sharing and collaboration across the supply chain


I would like to hear any insights, experiences and suggestions you may have regarding this expediting versus planning situation.

Originally posted by mjeffrey at

I came across this article by Colleen Crum, a principle with Oliver Wight Americas. In it, she outlines a compelling argument about how critical leadership involvement is to S&OP. I couldn't agree more.


Over the past few years, I've talked to many people who have had varying degrees of success implementing S&OP. One theme was consistent, however, the successful implementations had full senior management support and involvement. As Colleen points out in her article,


"[success].. cannot happen without senior leadership involvement in the process. Involvement means just that – active, high-profile involvement, and not just lip service support".


One person I met at a S&OP conference a few years ago told me about the struggle they were having implementing S&OP at their company. They were trying to implement S&OP as a "grass roots" movement without executive involvement. Their approach was to try to implement S&OP, prove success to the executives and try to grow the process organically. They'd been at it for the better part of a year, but still hadn't broken through. I admire their dedication but I'm afraid that they won't be successful.


Why is leadership involvement so important? Let's think about what S&OP is about. It's a process that aligns all parts of company into a common direction. Sometimes, the direction that is best for the company may not be favourable for a given group. Sometimes, it takes the GM (or CEO, or president (insert your leader here)) to settle a disagreement. Without that arbiter, without someone to make that final decision, it can be very difficult to get results from your S&OP meetings.


Once your executive team is involved how do you keep them involved? Above all, be prepared. The executive team is busy and their time is very valuable. The executive S&OP meeting should be a review of performance metrics and a blessing of the new S&OP plan. If your meeting takes more than an hour you are at risk of losing executive involvement. If there are issues, have the issues clearly articulated and have alternative solutions ready for the meeting. The pre-sales and ops meeting is the place where the tradeoffs are made, alternatives evaluated and preferred solutions prepared for the executive meeting. In my days putting together the S&OP plan, there were some months where we had multiple pre-sales and ops meetings before we presented to the executive team.


I've had the privilege of being involved in the sales and operations activities at a company where the executive team was truly involved in the process. When a major long term material shortage threatened our supply chain, the sales and operations planning process was the tool used to navigate that challenge. When a major customer's union went threatened to strike (we had visibility to the strike risk several months in advance), sales and operations planning was the tool used manage that risk. In fact, sales and operations planning is the tool that managed that company.


Would you call your S&OP implementation a success? What factors would you contribute to the success of your S&OP implementation? Comment back and let us know!

Originally posted by jwesterveld at

Is the era of blockbuster new products over? Has the balance shifted to a new paradigm of competition based on process and efficiency?




Just a reminder of next week’s webinar:




Part 1: Pharma 2020 – Maintaining competitiveness and operational advantage in a rapidly changing environm ent
Tuesday May 25th 2010, 11:00am ET
Live Webinar









Key topics will include:


  • Optimization of inventory and manufacturing capacity across multi-tiered global pharmaceutical operations
  • Driving working capital efficiencies
  • Enhancing supply chain agility and flexibility to integrate and align supply and demand




Registration is complementary.



Originally posted by lsmith at

I recently read the article " Coming Dominance of On-Demand Supply Chain Software" by Dan Gilmore and it got me thinking about the history of SCM software implementations and where the industry is going. Just on a lark I Googled "failed supply chain software implementations" and got 33,000 hits. To me that is an indicator that this is a hot topic. The past years have been a wasteland of high profile failed implementations with such companies as Nike, Waste Management and Hersey (to name a few). Obviously all the failures were for very different reasons, but a failed supply chain software implementation can have a dire impact to a manufacturing company, such as not being able to manufacture or ship new product! What could be worse than that? Make no mistake about it, the business problems that supply chain software solve are difficult and complex, so perhaps it is time for a change.


I agree with the author that the future of supply chain software is on-demand. But the real question is why?


I personally think it stems from the fact that companies no longer want to risk huge, costly, time intensive implementations of software with no predictable end result. On-demand software can offer the customer a whole new future.


Low up front software costs (no huge multi-million dollar investment), no hardware cost and generally speaking the subscription pricing is user-based so customers have the ability to try the software with a few users, get some user adoption before committing to a huge roll-out across the organization. This helps to de-risk the investment. And honestly, customer executives would no longer have to potentially put their job on the line for a supply chain solution.


Also, Ibelieve on-demand software companies have to provide better customer service than traditional on-premises licensed software because the software vendor is constantly trying to earn and retain a customer's business. There is no perpetual forever license. The software company must listen to customer needs and adapt to them or face the customer going off subscription. As everyone knows, the supply chain industry is dynamic so the way to solve a problem today can be different tomorrow. Wouldn't you want to work with a vendor that would actually listen to your customer requirements and put them into the product rather than to have a bunch of custom code the vendor won't support? I think you get more of that with an on-demand software vendor.


The author also made a very interesting comment " Increasingly, you will be able to try the software before you buy it! What a dramatic, game changing impact that will have." Just think about that for a minute. What a huge statement.If all those companies who had failed supply chain implementations could have just tried it before they made a huge investment would it have made a difference? For some, yes and others maybe not, but the key point is that consumers of supply chain software can be more educated prior to embarking on a software implementation.


What would be even more provocative would be a company who is willing to not only let you try the software for no cost, but also perform the implementation with no initial services fees and no cost at all if you don't like it… That would really change the game, the customer could completely de-risk their supply chain software decision. Now that would be bold.

Originally posted by mrupert at

The supply chain is tightening up again. We are hearing about this in high tech and automotive and most likely in other industries as well. While we never seem to avoid the cyclical nature of demand and supply, it is refreshing to see the level of interest in making good decisions with limited supply.


In working with clients, I have never seen so much interest in supply allocation options, demand prioritization and customer segmentation. Companies are realizing that the FIFO approach to customer demand isn't good enough anymore. However, you do find some companies that think that they need VERY complex rules. Supply chain doesn't have to be complex to be effective. In fact, I would argue that the opposite is true.


Companies all want to maximize revenue and minimize stock levels. I believe that global competition has also had a significant influence on the need for supply allocation options. If you can't satisfy everyone on time, which customers are most important and what impact will not satisfying some customers have on your business? Many companies have top tier customers that represent such a significant portion of their business that they always need to satisfy. Other companies are rewarding their customers with the best forecast accuracy.


Supply is being allocated at either the finished good level or the material component level. If you are managing the finished goods side of the business, you may need a combination of automated supply allocation rules and also the option to manually allocate or create firm allocations to distribution centers or regions.


There is no one rule however for supply allocation. These are collaborative decisions that need to be supported by software but not decided by software.


What has been your experience with limited supply? How are you solving this today and do you need a better way? I would be really interested in hearing your comments.

Originally posted by cmcintosh at

Before I start on the body of my blog posting, let me state unequivocally that I believe, no, that I know, that computers and software have a huge role to play in decision making and execution in a wide range of business functions. After all, I have worked in the software industry for the past 25 years. I am also not one of those wacky people who think that machines are going to take over the world. However, I am one of those people who believe that humans have unique skills that no machine is able to match currently, particularly the ability to evaluate nuance, uncertainty, and risk. Computers and programs, on the other hand, are capable of processing huge amounts of data far more quickly than humans, but they always assume that the data they are fed and the algorithms/heuristics they are using to analyse the data are absolutely correct. In other words, computers are hopeless at evaluating nuance, uncertainty, and risk.


All too often we don't put processes in place which couple the human ability to evaluate nuance "intelligently" with the machine ability to evaluate vast amounts of data "dumbly". All too often we confuse efficiency with effectiveness, and pursue efficiency over effectiveness, exemplified by the use of the term "machine intelligence".


Nothing brings this out more clearly than the recent stock market behaviour. All the "quants" were quick to identify "human error" initially. Not only did they say it was human error, but it was female error. I'm surprised they didn't suggest she was a blond too. After all, we know how they confuse their B's with their M's. How ridiculous! Now that calmer analysis has taken place, it would seem that nothing of the sort happened, and not by a female either. There is a very interesting article — I am sure there must be many more out there — in the Wall Street Journal (WSJ) by Aaron Lucchetti titled "Exchanges Point Fingers Over Human Hands" that analyzes what really went on last week Thursday. Lucchetti makes no bones about the fact that this is a man vs machine tussle:

"In the man-vs.-machine argument for financial markets, proponents of technology say machines do it faster and cheaper. Those in support of human involvement say people can use their experience and pull the emergency brake when the computers, or their programmers, make mistakes.

But when that happened Thursday, it appeared that some humans couldn’t react quickly enough, while those using computers just kept pushing the market lower."

I would argue that human involvement should have been used to prevent the situation from occurring, not just as an "emergency brake".

Let's start by understanding the role of the "quants" in financial organizations. A "quant" is short for a quantitative analyst. These are math and physics whizzes that have been brought into financial institutions to create mathematical models to evaluate market behaviour, particularly algorithmic trading. Algorithmic trading is a trading system that utilizes very advanced mathematical models for making transaction decisions in the financial markets. The strict rules built into the model attempt to determine the optimal time for an order to be placed that will cause the least amount of impact on a stock’s price. Large blocks of shares are usually purchased by dividing the large share block into smaller lots and allowing the complex algorithms to decide when the smaller blocks are to be purchased. The use of algorithmic trading is most commonly used by large institutional investors due to the large amount of shares they purchase every day. Complex algorithms allow these investors to obtain the best possible price without significantly affecting the stock’s price and increasing purchasing costs.


Let me come clean; I am an engineer, so I am a "quant" by nature and by training. But I had the good fortune to study " decision under uncertainty" at the PhD level. During this time I also came across " fuzzy logic". Forget the math and theory. Fundamentally what it comes down to is that some people (quants) believe that any and all systems can be modelled exactly — given enough time and insight — and that the models can then be used to predict behaviour under any other circumstances. I think this is a load of hogwash. No mathematical model is ever complete and data is never 100% accurate. However, when computers are used by humans to understand "directionally correct" decisions.

There is an interesting little snippet in the Wikipedia description of quants which I think is of particular relevance.

"Because of their backgrounds, quants draw from three forms of mathematics: statistics and probability, calculus centered around partial differential equations (PDE's), and econometrics. The majority of quants have received little formal education in mainstream economics, and often apply a mindset drawn from the physical sciences. Physicists tend to have significantly less experience of statistical techniques, and thus lean to approaches based upon PDEs, and solutions to these based upon numerical analysis."

Statistical techniques are based upon uncertainty, or randomness. Physicists in particular hate uncertainty, and spend enormous amounts of time looking deeper and deeper into atoms trying to prove that everything is predictable, if only we had the knowledge and wisdom to understand the observations. And they bring this perspective to the analysis of financial market behaviour, as pointed out in the Wikipedia quote. Einstein once made the statement that "God doesn't play dice with the universe", which he came to regret, incidentally. He was questioning the notion of randomness as opposed to determinism. Determinism is defined as understanding every event in nature as having a particular cause. Randomness defines an aspect in nature that has only a probability such as in quantum uncertainty. My engineering training was replete with this deterministic attitude which informed Einstein statement, as was the training of my fellow engineers and scientists. So the quants are in constant pursuit of the ultimate model to describe all situations so that they can predict the movement of the market under any and all conditions. This is an attitude that is very common in supply chain management too. I think it is flawed from the start.


In a separate article in the WSJ titled "Did a Big Bet Help Trigger ‘Black Swan’ Stock Swoon?", it is clear that what happened last week Thursday was not "human error", but rather "model error" in the sense that there was an over reliance on computer models, which in turn drove market behaviour.


The non-quants have been fighting back for some time since the market crash in 2008 and the whole CDO mess. A good example of this is Scott Patterson's book "The Quants: How a New Breed of Math Whizzes Conquered Wall Street and Nearly Destroyed It". It is a fascinating read, and very instructive. But also fairly predictable in the blame game. What I found most interesting was a comment by a reader of a book review of "The Quants" in the Globe and Mail. Interestingly the title of the book review is "Quants accept no blame for financial crisis". Can't be more explicit than that. The reader wrote that


"In finance, you have a lot of people in high positions who are surprisingly innumerate (MBAs and the like) – they didn’t really understand what the quants were doing but didn’t mind as long as they were making money. Let’s not forget who hired the quants in the first place! When you combine this lack of technical oversight with poor regulation, you have a toxic mix."


I believe we have a very similar situation in manufacturing operations, particularly supply chain management. Senior management doesn't really understand the complexities of operations and rely too heavily on the quants. As long as they see inventories go down and stock prices go up, all is well.


To go back to Lucchetti's article in the WSJ, the first act in the blame game for the market behaviour last week Thursday was to focus on "human error". Clearly a first salvo from the quants. Later in the article, Lucchetti quotes Jamie of White Cap Trading as stating that


"Markets are a mix of technology and human judgment. Thursday, we saw far too much technology and not enough (human) judgment."


I could not agree more. I think I am going to print out that statement in 94 pt font and put it in a frame on my wall. I would like to see everyone in supply chain management follow my example.


All too often I see this same behaviour in supply chain management where optimization engines are thrown at a problem. I do not have too much of an issue with the use of optimization engines. What I struggle with is that there is a slavish belief that the results are accurate to the nth decimal. There is no understanding of the likelihood of achieving this optimum nor the degree to which the model is inaccurate nor the degree by which the result is affected by inaccurate data. What happened in the stock markets is a classic example of relying too much on machines in the pursuit of efficiency. The parallel's in the supply chain space where we rely too much on optimization, be that Lean or mathematical optimization. Do you know the first sign of when the quants have taken over your supply chain? It's when you hear that your data isn't clean enough after you have already spent millions implementing an ERP system and countless hours "cleaning" data.


I am not suggesting that we unplug the ERP and APS systems we have deployed over the past 20 years. I think there is a huge amount of value that has been received from the use of these tools. But they are tools. Let us treat them in that manner.


As always, I look forward to a robust debate, perhaps including some of my erstwhile colleagues.


Originally posted by tmiles at

Expiry planning adds a whole new dimension to the supply chain planning and simulation process, but in those industries where expiry (or best before) is part of their manufacturing and distribution process (pharma, food, med devices among others), the ability to generate production plans that take into account expiry is absolutely vital to creating a realistic plan.


Most ERP systems support expiry on some level, usually from a transactional point of view (what I will call simple expiry). Simple expiry allows the users to set expiry limits on a part by part basis, and the system will then calculate when a particular supply will expire. This is mainly used for 3 things in an ERP system:

  • determining when a particular supply expires so it can be scrapped and/or replaced,
  • allowing planning to determine in what order to use a supply in order to avoid scrap, and
  • to enable inventory control and shipping to determine what supply can or cannot be used in production or order fulfillment.


The problem with this expiry model is that it does not realistically model actual expiry conditions in the supply chain, as actual expiry times can be consumed by production and quality inspection lead times, perhaps through several levels in the supply chain. What this means is that supply that was projected to be available until a certain period in time will actually expire earlier, leaving an unanticipated gap in supply. This could lead to real shortages and dire consequences for customers if not recognized in time.


What simple expiry does not do is allow expiry to be driven by dependent components in the BoM, which I will call complex expiry. In this model, component parts (perhaps several levels down in the BoM), drive the expiry date of the parent part. A true expiry planning system must be able to account for the lost expiry time as the driving expiry component is processed and tested up through multiple levels in the BoM. As well, when supplies are allocated to demands, the originating demand's expiry requirements (minimum shelf life, or how long the product must last before expiring once it has been shipped) must be known when planning supply, otherwise a mismatch between the demands requirements and the supply's ability to meet them can occur. Another issue to consider is safety stock being held at multiple levels in the supply chain, as by its very definition, safety stock can exist in inventory for extended periods of time, further consuming expiry time.


In order to get a true supply/demand picture when planning or simulating in the supply chain, actual or planned supplies must be matched to their allocated demands. This can only truly be done in a CTP (Capable to Promise), bottom up analysis of the true available dates of the components, and how they affect the parent's availability. In other words, you cannot properly fulfill demand for expiring product unless you have a true picture of when your supply will be available, and when it actually expires.


A simple expiry model can be made to accommodate certain aspects of this planning model (by manually or programmatically accounting for lead times etc. in each level of the BoM in the expiry data), but without the ability to account for actual variations in the supply plan through a CTP analysis, the picture will always be incomplete.


In summary, in order to get a realistic view of your supply chain under expiry, a complex expiry model is required (and a planning tool which supports this). In order to get a true picture of scrap, gaps in coverage, safety stock requirements, batch production timing, and the financial implications associated with each, the ability to support the complex expiry model is a requirement in any planning tool.

Originally posted by mbuckley at

As the topography of the global Pharmaceutical sector changes rapidly, alongside an uncertain macro climate, responding and reacting to current and future challenges will be the key to success.




We are delighted to be sponsoring an upcoming webinarthat will explore key issues for the global Pharmaceutical Industry and discuss the impact of these trends on supply chain development, response and go forward strategy.




Part 1: Pharma 2020 – Maintaining competitiveness and operational advantage in a rapidly changing environm ent
Tuesday May 25th 2010, 11:00am ET
Live Webinar









Key topics will include:


  • Is the era of blockbuster new products over, and has the balance shifted to a new paradigm of competition on process and efficiency?
  • Optimization of inventory and manufacturing capacity across multi-tiered global pharmaceutical operations
  • Driving working capital efficiencies
  • Enhancing supply chain agility and flexibility to integrate and align supply and demand




Registration is complementary.



Originally posted by lsmith at


Cycle counting 101

Posted by Kinaxis May 5, 2010

I was at an event last week where I met a guy who works for an electronics contract manufacturer. He was telling me about a physical inventory they were doing at the plant. Apparently the physical inventory was revealing a lot of inventory discrepancies. This surprised me because I knew the company had procedures in place to do regular cycle counts. As I dug a bit deeper, I discovered some things that made it really easy to understand why there were problems;

  1. The driver behind the cycle count was financial reconciliation. The key was ensuring that the inventory values tallied to what was on the books in aggregate. So, if part A was down a bit and part B was up a bit, overall, things balanced!
  2. There was no follow up to identify the root cause of the discrepancy. And no changes put in place to prevent similar issues from happening again. In fact, the inventory clerks would simply adjust the inventory balance to reflect the correct values.


So… what's wrong with this approach? It's all about the money, right? Right. It IS all about the money. However, how much money can you make if you can't make the parts you want to sell? How much money can you make if your profits are all eaten by the added expense of expediting? An incorrect inventory quantity on a component that costs a fraction of a cent can prevent a multi-million dollar unit from shipping on time. Take a word of advice. Get the finance guys out of the stockroom and change the focus to true inventory accuracy. A cycle count needs to ensure that the right quantity of the right part is in the right location. The interesting thing about focusing on inventory accuracy is that the financial accuracy will improve automatically. It's win win!


The other problem with this company's approach was that people were not following up to determine the cause of the cycle count discrepancies. In a former life I used to support our inventory control staff as they tried to figure out why their values weren't tallying. In many cases, the cause of the error turned out to be systemic in nature; Backflushing errors, BOM errors, incorrect allocations, etc. Fixing these prevented the same problem the next time this part was made. In some industries (electronics, pharmaceuticals. etc) , where parts could have black market value, establishing root cause is critical to ensuring that pilfering is caught and dealt with quickly.


So what are some best practices for cycle counting? Jeff Rose at Tomkins Associates put together a very informative guide to implementing cycle counting which outlines the goals, benefits and steps to implementing a world class cycle counting program. In my opinion this is a must read for anyone who manages inventory.


Do you have inventory horror stories you want to share? Inventory practices and processes put in place for all the wrong reasons? Share them with us so we all can learn!

Originally posted by jwesterveld at

And that’s a wrap!

Posted by Kinaxis May 4, 2010

I can't believe it's already been 6 weeks, but it must be true because the last " Suitemates" webisode is out — Speak E.A.S.Y.




Have you been following Bilk-Moore executives (played by notable actors Kevin Pollak and Ray Wise) as they navigate the perilous world of prison life and legal appeals?! So... was their guilty verdict overturned? You have to watch to find out!




We've had a lot of fun with this. And the fun will carry on as the videos continue to be passed around and viewed. Not to mention the blooper reel comes out next week! And the 'Elephant in the Room' contest is still open.




But while the videos were done in jest, they come with a serious message. The corporate landscape is littered with failed ERP-SCM projects. Companies no longer have the IT budgets to support large implementations of complicated licensed solutions.... nor the consulting engagements required to make all the pieces work.... or the maintenance fees that accompany it. Recently, there have been signs of a push back (and we hope we are a part of that). Those in the industry are no longer being seduced by the suites. As we have professed before on this blog, CIOs and supply chain executives deserve to have more confidence in the success of the solution, more accountability on the part of their vendor, and certainly better ROI.




In fact, just yesterday I saw this blog post by Panorama Consulting. Based on results of a recent survey they found that



the average annual cost for companies implementing on-premise ERP packages is $6.2 million, and average business benefits realization is 37.2%. So what do these numbers mean to your business? ...In general, the total cost of an ERP system includes software costs, service costs and annual maintenance fees, which are typically about 20% of the cost of the software licenses. Based on these assumptions, when we consider an average cost of $6.2 million, an average payback period of 2.7 years, and average benefits realization of 37.2%, the model shows that the benefit loss from the ERP implementation is $4.3 million! Additionally, it takes you 2.7 years to recover these costs while it should have been only 10 months!




Enough is enough. The model is flawed. It's time for a new paradigm right? We think so. We're doing as much as possible to break the mold and move away from the old software model (the tired and failed supply chain software model in particular). We've only begun to shake things up. Don't believe it?…well, stay tuned for some bold moves ahead.



Originally posted by jsicard at

Your organization has finally accepted the fact that without process change its objectives for performance improvement cannot be achieved. Furthermore, you've also come to the conclusion that your organization may not have the knowledge, experience, or bandwidth to either identify the process changes necessary, or guide the organization to the successful adoption of those changes. Even when considering the adoption of a documented best practice, there are often organizational and other factors serving as barriers that are just different enough from the norm to create some unique challenges. So who do you turn to? Bringing in a consulting firm is an obvious consideration but based on the number of both successes and horror stories, this should be done with the same care you might exercise in selecting a marriage partner. I've personally witnessed disasters and universally acknowledged successes and it would be unfair to lay all the blame or credit at the feet of the consulting companies involved because, like a marriage, both partners have some influence on the outcome. Still, it would behove any company considering the use of consultants to carefully match needs to capabilities along with a careful consideration of the motivating factors.


Here are just a couple of key considerations;

  1. Are you just looking for strategic advice on what to do? Some consulting firms specialize on strategic thinking and the outcome of an engagement can be a well articulated change strategy along with the outline of an implementation plan. More often than not, engagements with these companies can be relatively short (although usually quite expensive), and they may not want the work associated with the lower level deployment activity or system integration. Deployment work is difficult, and for almost any project, the devil is in the details. So many things can go wrong during deployment that it seems a lot safer to stay at the advice level. I've also been led astray a couple of times when it proved that the consulting firm didn't have the implementation experience to deal with the challenges that surfaced. Even if you only want strategic advice, I still recommend selecting a firm that has a proven deployment track record because their deployment plan recommendations are likely to be more realistic.
  2. Are you looking for detailed deployment or system integration guidance? Some consulting companies specialize in this area and my personal fear (led by my experience) is that they are incentivized to lengthen the project (especially where the project is on a time and material basis). Does the advice provided by these firms really serve your best interests or theirs? What if the firm has the option of suggesting a solution approach with a 90 day deployment or one with a 180 day deployment? Will you even hear about the 90 day option? I'd suggest two things to make sure you get what you need. First, get references for the firm where the clients had projects similar to yours and take the time to ask about what they did and did not do well. Secondly, independently investigate some of the possible system or deployment options and directly question the firm on the advantages or disadvantages of these options. I've seen major consulting firms lose their trusted advisor relationships because they failed to meet some reasonable standards for unbiased advice.
  3. When selecting a consulting partner, do you know who is going to be assigned to the project? On more than one occasion I've seen consultants assigned to project activity who are poorly suited to the project because of either a lack of experience and/or knowledge. This not only increases the project cost, but introduces risks that are unwarranted. Some of the companies that have most effectively leveraged consultants perform screening with nearly the same level of scrutiny as hiring a new employee. While there are certain structures to the consulting process that help to contribute to a successful project, most of the value is delivered because of the skills and knowledge of the individuals assigned. Meeting with an experienced and knowledgeable consulting executive does not guarantee that the people assigned will meet the standard required. I would also demand project assignments that will last the duration of the project to avoid consultant rotations.


The bottom line is that you will pay handsomely for consulting whether it is valuable or not. You can increase the odds for success but not without some due diligence. And remember, not all consulting firms are created equal and few if any are suited to solve every problem.

Originally posted by kzuber at

Filter Blog

By date: By tag: