Maybe software should be packaged like this?  Photo: Tetra Pak Package Portfolio, by Tetra Pak, CC license

A “packaged application” is software already built, coded, tested, used by other enterprises in your industry, and hopefully a solution that will meet most of your needs.  In general I recommend using packaged applications (why re-invent something?)

But a packaged application is not ready-to-use, in any sense of the word. The word “packaged” is kind of a misnomer. You won’t find a warehouse management system in a shrink-wrapped box on the shelf at Best Buy. A packaged application is simply one whose features and functions match in general terms what you want the software to do, but which still needs to be configured for your business. Configuration (also called setup) involves a lot of work and expense.

Much of the time involved in configuration is not in setting up all the data and parameters, but in deciding what data and parameters to set up. What data do you want to/have to set up for each customer? Should employees be “suppliers,” so that you can reimburse them for travel expenses? Do you want to manage your inventory levels according to min/max parameters or days on hand, or some other way? In most enterprises, decisions like these aren’t made by one person – groups of people get involved, and all those meetings and explanations have to be scheduled, and someone has to herd everyone into a decision. Not a quick process.

Packaged software is an annuity business. A software company survives in the long run because it is able to collect annual maintenance and support fees from its customers while providing custom development services and a stream of version upgrades. The support fees can be 20% to 25% of the original cost of the software license, so to the software firm, it’s like selling a new system to the same customer every four or five years. In exchange for the fees, the customer gets access to support desks, can have the software firm make modifications to the system usually on a time-and-materials basis, and automatically gets some upgrades and patches (or fixes) as well as user guides and maybe some technical documentation.

Recurring support revenue is highly profitable for vendors selling packaged applications. It is not unusual for big packaged software vendors like SAP, Oracle, and JDA to have this type of revenue represent 60+% of its sales while incurring only 5% or 10% of its operating expenses.

If you are selecting a packaged application, understand that your vendor will try to sell you the traditional on-premise solution, in which you will own and host the software while paying the vendor for additional licenses, upgrades and custom developments, plus the annual maintenance fees of 20% to 25% of the original license cost, which, on a license costing $500,000, for example, would be $100,000 to $125,000 per year.

And therein lies one of the most debated and disruptive topics in the software market today: the move away from the traditional on-premise (also referred to as perpetual license) model to a service or subscription-based model.  It is not exaggerating to say that the perpetual license model has in a way been the drug, the stream of highly profitable revenue, sustaining the software industry the past two decades.  Stay tuned.

All your apps are in the cloud(s) now.  It’s OK.  Photo: Paul VanDerWerf, Potts Harbour, Hartswell, ME.  CC license. 

Hyperscale computing (HC) may sound like something only NASA and Google need.  But any business doing any kind of commerce with web sites can potentially benefit, as can brick and mortar companies who are highly dependent on 24 x 7 x 365 operations and no longer want to buy and maintain servers.

Hyperscale computing is computer processing power and storage that can be scaled up or down instantly, in large amounts.  Hyperscale computing relies on distributing computer tasks to multiple servers (distributed computing). You could do this on your own, duplicating your server environment and buying extra servers and the software needed to distribute tasks, but all of this is already available in the cloud, by many reputable firms, at costs that are not only low but predicted to go lower.

Why should you care?  Here are two scenarios where you might benefit:

1. Your product is sold at brick and mortar stores as well as your own web site.  Your retail customers (stores) use your primary site to place orders and as a selling tool in their stores.  You frequently promote your products to generate sales, so traffic and transactions on your site fluctuate a lot.  In this case you have to manage high traffic in a high- responsive way, and you need alternatives for backup if your primary servers fail.  Again, you can manage the hardware physically, but the most efficient way will be to virtualize your servers with scaleability built in, which is the whole purpose of hyperscale computing.
2. You don’t sell a thing online but your 24 x 7 x 365 operation is highly dependent on e-commerce with other companies and your own ERP system, the hardware for which is hosted by you or by an external company. Most companies have redundancy backup internally, or they make sure that apps or services they use are hosted by firms that also have redundancy backup.  But what if your vendor has the traditional one or two server backup, and one or both of those fail?  As companies more and more adopt SaaS for applications solutions, they can’t just assume that their SaaS vendor has adequate backup/scale-up capability.

Think of it this way, in simple terms: what you used to think of as big computers in some refrigerated room running all your stuff is now available online, not only in the quantity that you want, but with much more capacity and speed and at much lower cost; but more importantly agile enough to expand instantly as needed, or failover automatically — both data and software — to a redundant environment in cases of disaster, virus, or overload.

Photo by Meredith Cook at Breckenridge, CO on a “blue bird” day, a clear day following a fresh snowfall.  It’s unrelated to SaaS or Cloud (or is it?); just nice to look at.

SaaS and cloud are starting to be used interchangeably (“we’re looking for a cloud solution”) but they really are not the same thing.

Software-as-a-Service (SaaS) is: software that is made available for use based on access to features, time, number of transactions, number of users, or a combination of variables.  A ‘cloud’ is simply a server – a computer you don’t own or maintain – that sits somewhere other than in your building, that you access to run applications or store data.

SaaS describes a type of software, cloud describes a type of platform.

So you can see it’s possible to take applications that you own, and put them in ‘the cloud,’ and also possible to use software you don’t own, but pay for based on usage, that is sitting in your data center with all your other applications.

But there are more important distinctions.

Type of Software-as-a-Service: Is it software that only you access (single tenant), or is it an application that many other people or companies use (multi-tenant)?  Multi-tenant is generally lower cost, but with less specialized functions for your particular enterprise.  Is it truly SaaS, or just a full cost, configured-for-you application hosted by someone else whose costs have been spread out monthly over 5 years to look like a SaaS solution?  True SaaS works like a subscription: sign up, pay by month and use it; when you no longer need it, you cancel.

Type of Cloud: Is it a private or public cloud, or a hybrid?  A private cloud is a single tenant environment (your enterprise) where you control access and have firewalls for security and where you can define the hardware.  A public cloud is where you are paying for a part of an existing cloud server environment; here, you “rent” space and the advantage is flexibility, low cost, and the ability to scale capacity up or down based on your needs.  Hybrid clouds offer both private and public spaces for you to use.

Let’s look at examples; in both cases we will use the scenario of a manufacturing company selling to major retailers in the U.S. and Canada.

True SaaS:  You contract with a company that offers tools for analytics (software) together with point-of-sale (POS) data for your products for your largest retail customers.  You pay by month to access and analyze POS data. The costs vary depending on how many report levels you want to see.  You access the application via internet, anyone in your company can use the service, and you can cancel at any time.

True Cloud: For purposes of experimenting with business intelligence applications, you purchase database space from a vendor, at a cost that varies depending on how much space you use.  You can scale up or down in terms of the storage you need.  You can connect to this space with a variety of tools for transporting  data and you can install and remove applications easily.  For running your business day to day, you can host your most critical applications in this cloud, and have in reserve an identical cloud with servers ready to take over in cases of disaster or over-capacity of your main servers.

Before you accept at face value the terms ‘cloud’ or ‘SaaS,’ make sure you understand what the vendor is telling you. Ask for details and explanations.  What the vendor thinks is cloud or SaaS can certainly be different from what you expect.

Image by reynermedia, CC license

Finance and accounting functions were among the first to be automated through software. The sheer volume of numbers and calculations, reporting requirements, tax filings and payroll mechanics, plus the fact that nearly every business has to engage in these activities, made the area perfect for software.

When just these basic functions are needed, not much distinguishes one finance application from another. They all post transactions to a cost center and sub ledger account, they all capture sales and costs and calculate required P&L and balance sheet data, and they all provide reports. They might distinguish themselves in terms of ease of use or report writing, or banking account integration, or cash management, or some other aspect.

Many finance applications are simply bookkeeping systems; if you want real analysis you’ll need to extract data to Excel, Business Objects, or another analysis and reporting tool. My own experience with both Oracle and SAP bears this out: even these leading finance packages are mostly concerned with accounting and financial, not management reporting.

Oracle and SAP both have what they call “business intelligence” capabilities, but they are contained in separate modules that must be purchased and integrated with the core software. So companies can easily spend millions implementing SAP or Oracle, and still find themselves extracting data into Excel spreadsheets for basic business analysis.

My experience is that most finance applications lack budgeting and financial modeling capabilities. It is one thing to know that your prior month results were over budget because of rising fuel prices, and quite another to project the future profit impact of different oil price scenarios. At what point would it make sense to switch to alternative fuels, to pass on some of these increased costs, or to buy oil futures as a hedge? A typical finance application won’t help you to answer these questions because they mostly record and categorize costs based on what already happened, not what might happen in the future.

Yes, there are “what if” modeling applications available on the market, but as a stand-alone application they aren’t very useful, since you have to enter all of your data, as if you’re using an Excel spreadsheet. The modeling application needs integration with your ERP to be most effective. Your ERP is the source of all kinds of data needed for financial modeling: production costs, formulas, material costs, transportation costs, revenue by product, as well as cost standards and budget information. This data changes frequently based on business conditions, competition, labor costs, and many other factors.

Microstrategy, Oracle Hyperion and Cognos are leading names in the financial modeling and analytics areas, but other, smaller firms are emerging. Netsuite, the ERP-in-the-cloud vendor, offers an add-on financial modeling application. Netsuite’s web site states that the modeling application features these capabilities:
• Dynamic formulas and assumptions
• “Actuals” data incorporated into new forecasts
• Workflow management
• Planning of full financial statements
• Unlimited versions for “what-if” analysis
• Multi-dimensional models for complex sales and product planning
• Multiple currency budgeting
• Graphic drag-and-drop report builder
• Multi-version variance reporting (vs. budget, vs. plan, vs. forecast)

A3 Solutions is another, smaller firm offering financial modeling applications, either on-premise or as Software-as-a-Service. A3 uses the Excel spreadsheet as the user interface, claiming it is the friendliest environment for creating what-if scenarios, and provides tools to link multiple sources of corporate data and manage modeling versions dynamically and virtually through its Spreadsheet Automation Server. A3 claims McDonalds, Honda, Toyota, T. Rowe Price, and American Airlines as clients. Simplicity, speed of implementation, and low cost are A3’s main selling points.

Once you have the “system of record” stabilized in a strong finance application, as well as good controls over product, customer, and sales data, you can start to think about these higher-level analytical tools. Define a standard model for delivering analytics, put someone in charge of the data, and tightly control the “official” analyses that are produced.

Image by lofrev.net

It’s getting harder to determine which software vendors have what capabilities. This is because:

• The number of technology startups has increased;
• Big software companies have been acquiring other firms to increase the breadth of their capabilities;
• Established firms are rapidly making changes to their suite of applications – adding capabilities so quickly that it’s difficult to land on a static evaluation and comparison vs. other vendors.

The branding of specific functionality continues to proliferate. Firms don’t define their software’s features all the same way – they give them a brand name, which only adds terminology that is unnecessary and gets in the way of a clear comparison of features.

Firms are offering products and services that overlap what other firms offer, making it more difficult to weed out who truly offers what you want.

It used to be that, if your company needed software in some form – packaged or custom – it was “installed” on a server. Then a “client” for the software – a relatively small piece of software – was installed on desktops so that the software on the server could communicate with the user on the desktop.

In between the two was a local-area network (LAN), which is jargon for a wired connection. In this configuration, a user could launch the client software on a PC, and the client would, via communication over the LAN to the server, enable the user to fully use all the features of the software.

Players in this market looked like this:

• The firm that wrote the software;
• The firms or independent consultants that support the software;
• The firm(s) that helped you to install, configure, test and launch the software you bought;
• The company from which you bought your servers;
• The company that supplied your LAN and wide-area network (WA)

All of this has changed. Now there are vendors that can do all of the above, without stepping inside your building, through a web portal.

How do you get what you need in this environment?

1. Find the software vendors that know your industry and understand what they offer. Software companies are usually organized according to what they call industry verticals, such as health care, pharmaceuticals, consumer goods, banking. A company with lots of clients in your industry is a good start
2. Find the software vendors that are the best for your targeted functional area such as sales, manufacturing, finance, etc.
3. Focus on the firms that are well represented in #1 and #2 above

Please choose the door through which your next software vendor will take you.  Image: Doors of Dublin, by Tim Sackton, edited to fit 569 X 368px, CC license.

Selecting a software vendor is difficult at best in the 21st century; here are some must-have criteria, in addition to, but perhaps more important than, cost and time:

Does it solve my problem? Does the software company’s system solve your business problem? Does its existing functionality match the business requirements you drafted?
Does it pay back? Do the financial benefits from the solution pay back the total cost of implementing it in three years or less?
Do I understand all of the solution’s costs? Have you accounted for initial license, recurring support fees, custom development costs for changes you want to make to the software, hardware costs, upgrades to your network bandwidth or operating systems on your current servers or PCs, the cost of the next version upgrade, the cost of consultants, of hiring backup staff for project team members, and travel?
Is the solution in line with my strategy? Does the system match your criteria for what types of information solutions you will invest in, now and in the near future?
Do I understand all of my alternatives, besides this particular vendor? Have you done your homework regarding software options available? Have you constructed an evaluation matrix and compared all the alternatives to one another?
Does my team have the time and skills to implement this solution? Can you secure near full-time people to manage this project? Is the system easy to learn? Is it intuitive? Has your team evaluated it and are they comfortable they can master it?
Do my users have the aptitude to learn it and become proficient? Can you envision your end users quickly learning to use all aspects of the software? Are there enough users who could become proficient enough to serve as key users and help other users with training and troubleshooting?
Does my team fully understand how this solution will integrate with the company’s other systems? Has the vendor demonstrated to your satisfaction the ease with which the system will integrate with your other systems? Are other enterprises already running the software with systems like yours? Try to get at least a conference call with those references to gauge the level of integration complexity.
How risky is this particular software alternative compared to others? Can the software be phased in without interrupting the business? If the solution fails or the team encounters startup problems, how easy will it be to keep mission-critical activities running?
Vendor reputation. How many enterprises are using the vendor’s software, and for how long? Get references and check them.
Can I find programming help in the open market? If you need customizations, can you readily find people to do the work? Or are you locked in to using the vendor to make all your changes?

All of this is of course after you have submitted and reviewed detailed RFPs from the most appropriate vendors.  You can build a grid or a table, with vendors/solutions across the top and your most important criteria down the left hand side, and weight the relative importance of each. The result is an overall score that points you to a solution that best fits your needs.

Image by Digital Strategy, CC license

Although EDI has been around for 20 years, lots of companies still process orders and invoices manually; that is, they receive a written, faxed, or e-mailed purchase order or invoice, then  type it into whatever software they have for tracking and fulfilling orders and paying suppliers.

If you  can’t or don’t want to get into EDI with your trading partners, there are at least two other options: buying software to image the paper documents and convert them to digital format for integration to your systems, or outsourcing the imaging and integration to a third party.

Let’s review the first option.  ReadSoft is one leading vendor offering document imaging.  The company states that it’s solutions “automate the processes of scanning, interpreting, and filing of invoice data,” and provide “seamless workflow integration with SAP, Oracle and over 50 ERP systems.”  The software enables three-way matching of invoice, purchase order, and contract.

My experience with ReadSoft is that it is a solid solution; although the expertise began with invoices the company also manages the purchase order side as well.  The companies that I know use ReadSoft have purchased it as an “on-premise” solution; that is, they have purchased the license for the software and installed it on a server within their organization.  It has a good rules-based engine for checking documents for certain attributes prior to integration with your main systems.

The second option is to outsource the receipt, capture, filtering, and integration to a 3rd party.  One vendor that does this is OmPrompt, a UK-based firm that is relatively small but boasts numerous marquee brand-name global companies as clients.  I also have experience with this company and indeed their solutions are solid and deliver as promised.

OmPrompt, in simple terms, works like this: your paper traffic is diverted to the company, you apply whatever business rules and filters to those documents, and OmPrompt then sends to your ERP system the proper digital files to complete the transactions.  OmPrompt handles business from around the globe, from the Middle East to China.  OmPrompt also processes EDI exchanges, and customer claims — a huge headache for many companies.

Which type of solution — on-premise or service — is better for you?  I am biased toward services rather than buying software, but you do need to consider the pros and cons in a balanced way:

The on-premise solution might be better if you want tight integration with the SAP or Oracle workflow, although the OmPrompt service can also filter invoices, claims, and POs based on your contracts and business rules.  The service-based solution removes the obligation to maintain server, operating system, licenses, users, and the core software;

Cost-wise you may pay much more upfront for the on-premise solution (license, installation, configuration, server, etc.) as well as 20-25% of the license cost each year for software maintenance.

The service option is very low-cost, after some setup fees, because you are using computing power that is shared across many clients.

Whichever option you choose, automating the manual work will bring clear returns:  reduced administrative work and solid internal controls to ensure you’re paying what you should on invoices and claims, plus the ability to standardize your inbound purchase orders or create a web portal for order capture.

Image: opensource.com

The term ‘adaptive software’ has at least two meanings: 1) software that is created with built-in capabilities to change its logic in the future; 2)  software that enhances an existing software application without significantly changing the underlying code of that application.

I have not seen real-world examples of 1) above, so I will focus on adaptive software as defined in 2) above.

The value of this type of adaptive software is in providing new functionality without the high cost of re-programming existing software applications.  Those existing applications are often referred to as “legacy” applications.  They could be five, 10, or 15 years old or older.  In some cases the company that wrote the program is no longer in business.  What do you do if you want to make changes to those applications?  In some cases adaptive software can be used.

Bob Kennedy, VP for business development at DMLogic LLC, describes in a recent article for supplychainbrain.com how adaptive software can be used to add features and functions to a warehouse management system (WMS).  He explained how companies used adaptive software with an existing WMS to create weight-check functionality and messaging and develop new screens to collect international shipping information.

I like the concept of adaptive software but a few hurdles have to be overcome, and you need to understand the limitations.

The main hurdle is access to the existing application’s database.  If you own the application and it resides on a server inside your enterprise this is probably not an issue.  But if you are part of a multi-company or multi-division enterprise all of whom depend on the application you want to adapt, you’ll need internal agreement on any changes (easier said than done!).

The limitations of adaptive software are …. not yet known, but I can guess they would start to be apparent when you try to change something very fundamental to the logic of the application.  Example?  Trying to use adaptive software to add a new unit of measure called “truck” to an existing WMS wherein you have only defined valid units of measure as “case” or “pallet.”

Having tried to find holes in the concept, I will say again I like the idea, because I think software vendors have intentionally or not created products that are too difficult and expensive to change.

Big ERP systems are a good example.  These systems are built with the back office in mind, they are workhorses and can scale as big as you want, but they are inflexible systems and they require disciplined data entry into the right screens at the right time with pristine data.

Can adaptive software solutions meet this challenge?  Can they provide a user interface for complex and heavy ERP systems that simplifies keystrokes and everyday transactions?  I think so, because we have already seen that mobile and tablet applications can simplify what are basically multi-step transactions.

Read Bob Kennedy’s article here.

Image: “Computer Software Development” by Fabio Bruna, CC license

Being on the “buy side” of corporate software for many years I’ve seen numerous pitches by software vendors. A few were excellent, most were forgettable, and quite a few were incoherent. Like actress Clara Peller in the Wendy’s ads — for those of you alive in the 1980s — I was often left wondering: “where’s the beef?”

One thing missing from nearly all of these presentations: a clear understanding of what my company did and what our business needs were, not to mention how the software solution met those needs.  Nearly all the meetings with vendors centered around the software and its ability to do this or that.

Another common theme: the vendor would present a business problem — one that you may or may not have — how solving this problem is the key to business success, and how that is accomplished with the vendor’s packaged lines of code.

Some advice to software vendors:

Ask the potential customer what they hope to accomplish with your solution.  Listen.  Ask questions and clarify.  The first response you get is probably not enough information.  Once you understand the problem and how you can help then you are ready to present something.

Know the specific issues facing the customer’s industry. Is there a language used in that industry that someone in your firm is familiar with?  Many software vendors have expertise in selling to specific industries, but have few people in their organization who’ve actually worked in that industry.

Limit the accolades for your firm.  You don’t need five slides explaining how great your firm is and how many of your firm’s customers are household names.  The customer probably wouldn’t be meeting with you unless they already knew you were legit.

Most importantly — connect the dots.  Most people cannot, in their minds, translate software functionality into business benefits.  You must do it for them and you must use the language of their business to do so.  You also need to leave behind a draft business case for investing in your solution. Most people don’t know how to write a business case, for anything.

A Nike Factory store in Atlantic City, NJ.  Photo by Shabai Liu, CC license.

Background

In February 2001 Nike, Inc. announced that it would miss sales and profit targets for the quarter due to problems with supply chain software it had begun to implement the previous year. The company said that it had experienced unforeseen complications with the demand and supply planning software that would result in $100 million in lost sales.

Nike was trying to put in a system that would cut its response time to changing sales demand. These types of systems rely on algorithms and models that use historical sales data combined with human input to generate a sales forecast, which is then converted to a manufacturing plan and orders for raw materials from suppliers. It’s not easy to set up and successfully run these applications to produce optimal results. The process demands a lot of trial and error, testing, and running in parallel with the old system to shake out bugs.

As reported by CNET News’ Melanie Austria Farmer and Erich Leuning, SAP spokesman Bill Wohl, reflecting on Nike’s dilemma, said at the time, “What we know about a software implementation project is that it’s just not about turning on the software. These projects often involve really wrenching changes in a company’s business process…It involves changes in the way employees work, and anytime you make changes in the way employees are used to working, it can get difficult.”

Nike is in the apparel business, where styles come and go, and where advertising and promotional programs can spike demand, requiring the supply chain to react just in time, delivering to the market just the right amount of each style. An oversupply of shoes or other apparel will lead to discounting and reduced profits, and an undersupply will lead to lost sales. Nike ran into both of these scenarios, and its profit dropped while sales declined, resulting in the $100 million unfavorable financial impact to the company.

Inside the logic of the software Nike chose, parameters and settings must be optimally set for the most efficient quantities to be produced and distributed to the market. It’s very easy to get it wrong, and companies launching this type of application usually run a pilot for several months before they are satisfied with the recommended production and distribution plans generated by the software.

Much has been written about Nike’s experience, and much of it is valuable for any enterprise thinking about a similar project. Keep in mind, though, that this was a public spat, and both the software firm and Nike told their own version of the story for the public record. That means we don’t have all the facts. Nonetheless, I think there are valuable lessons in the Nike story, and at the risk of not getting all the facts right, I present my conclusions more to help you learn and succeed than to cast blame on any of the Nike project participants.

Key Points

Here is what I think were the main issues in the Nike project:

Complexity of the application without commensurate resources applied to making it work. Christopher Koch, writing in CIO Magazine at the time, said “If there was a strategic failure in Nike’s supply chain project, it was that Nike had bought in to software designed to crystal ball demand. Throwing a bunch of historical sales numbers into a program and waiting for a magic number to emerge from the algorithm — the basic concept behind demand-planning software — doesn’t work well anywhere, and in this case didn’t even support Nike’s business model. Nike depends upon tightly controlling the athletic footwear supply chain and getting retailers to commit to orders far in advance. There’s not much room for a crystal ball in that scenario.”

I don’t fully agree with this assessment; I think demand forecasting systems are critical to modern businesses, and if configured and used correctly, bring many benefits. Other reports said Nike didn’t use the software firm’s methodology, and if true, this would greatly contribute to its troubles. I have implemented these systems and they require precise attention to dozens of settings and flags, pristinely accurate data, and the flawless sequential overnight execution of sometimes 30 or more heuristic calculations in order to produce a demand forecast and a recommended production and raw material supply plan.

It’s also critical with these types of applications to have the right subject matter experts and the best system users in your company on the team dedicated to making the system work the right way for your business. This is where, if published reports are true, I believe Nike may have failed. It is possible Nike simply needed more in-house, user-driven expertise, and more time to master the intricacies of the demand planning application.

In 2003 I ran an ERP project that included an overhaul of supply chain systems. The suite included demand and supply planning solution software, which we would use to forecast demand, generate a production and raw materials supply plan, and determine the plan for supplying product from plants to distribution centers. Unfortunately the best system users declined to be part of the team due to heavy travel requirements, and we had multiple problems getting the parameters right. The supply chain suffered after launch as incorrect production and distribution plans disrupted the business for several months.

Combining a maintenance-heavy, complex application with an organization unwilling or unable to meet the challenge is one way to find the money pit.

A ‘big bang’ approach to the launch without sufficient testing. Despite prevailing wisdom and suggestions by veterans that Nike phase in the new application, Nike chose to implement it all at once. This immediately put at risk a large portion of the Nike business. A phased approach would have limited the potential damage if things went wrong.

A case study of the project published by Pearson Education discusses this point: “Jennifer Tejada, i2’s vice president of marketing, said her company always urges its customers to deploy the system in stages, but Nike went live to thousands of suppliers and distributors simultaneously”

The study also quotes Lee Geishecker, an analyst at Gartner, Inc., who said “Nike went live a little more than a year after launching the project, yet this large a project customarily takes two years, and the system is often deployed in stages.”

Brent Thrill, an analyst at Credit Suisse First Boston, sent a note to his clients saying that because of the complexities he would not have been surprised if to test the system Nike had run it for three years while keeping the older system running. According to Larry Lapide, a research analyst at AMR and a supply chain expert, “whenever you put software in, you don’t go big-bang and you don’t go into production right away. Usually you get these bugs worked out . . . before it goes live across the whole business.”

I can understand that Nike would want to convert a large portion of its business and supplier base at the same time. It reduces the length of the implementation and therefore the cost of maintaining consultants and support staff, and it eliminates the need for temporary interfaces to existing systems.

But a smart move might have been to launch and stabilize the demand planning portion of the software first. It’s easy for me to second guess, but Nike could have taken the forecast generated by the new system and entered it manually into their existing, or ‘legacy’ systems. After all, if the forecast is wrong, then everything downstream – the production, raw material, and distribution plan – are also wrong. I did this on two projects, and it significantly reduced risk. On both projects we launched the demand planning (DP) application and ran it in parallel with our legacy system until we were satisfied with the results, then we disengaged the legacy DP application and began manually keying the new system’s DP forecast into our legacy production, raw material, and distribution planning software.