i2 Technologies Archives

Takeaways from JDA User Conference

Logistics Software Vendors | By Steve Banker • 05/26/2010

I attended the JDA user conference last week, FOCUS 2010 , which took place at Caesars Palace in Las Vegas. JDA completed its acquisition of i2 Technologies at the end of January, and what was most interesting to me was to see how the merger was proceeding.

Historically, i2 and JDA have had very different cultures. i2 tackled some of the most complex supply chain problems from some of the largest companies in the world. At i2 user conferences, you would hear customers talk about high risk, high reward five year transformation plans. i2 was exciting, but also a bit dangerous. Some of these customer transformations did not succeed. Some of the complex solutions i2 developed were not sellable to other customers, or maybe only to a few other customers. And, not surprisingly, some of those one-off solutions were the equivalent of beta solutions, glitch prone and not fully usable.

JDA’s culture is centered on being a “software” company. The company has little to no interest in developing one-off solutions. JDA is interested in repeatability, maintainability, and high customer satisfaction (the company claims 97 percent customer satisfaction).

Overall, I thought the conference showed that the merger is proceeding well. A few points of evidence:

JDA has retained key i2 personnel, people who I greatly respect, and they are in positions of authority.
JDA has developed a roadmap to converge its existing and acquired product sets. Existing products from JDA and i2 will continue to be supported. Eventually, a converged product will emerge that contains the best features and functions of both solution sets. Meanwhile, certain products from JDA and i2 have been designated as the “go to market” products—i.e., the products that will be sold in new sales situation.
JDA has a coherent convergence plan for its multi-echelon inventory optimization and transportation suites, the product suites that we track most closely. The “go to market” products in these suites are the ones that we believe to be superior, and some of them came from i2.
There is evidence of cross pollination. Traditionally, i2 has been strong in high tech, while JDA has been strong in consumer goods and retail. The convergence product teams I talked to had ex-i2 folks as well as legacy JDA folks involved. These teams are looking at the product sets from a cross-industry perspective and some interesting ideas are emerging as a result. Further, JDA has some good merchandising and category management solutions. I believe that in CPG, category management and supply chain management are beginning to merge based on increased availability of downstream data that needs to be leveraged by both groups.
JDA has rebranded itself as “The Supply Chain Company.” I used to view them primarily as “The Retail Company.”

However, some challenges still remain. Here are two concerns, one perhaps self-serving:

JDA’s vision is to have supply chain solutions that span from the factory to the retail shelf. A demand signal repository (DSR) is a key solution component to make this happen. However, DSRs are an emerging, messy solution likely to be bought only by category leaders and the number two company in a category. In other words, this solution is not the repeatable “off-the-shelf” software that fits the JDA development and maintenance philosophy. However, if JDA continues to lack a DSR product, Oracle is likely to emerge as the leader in shelf-level collaboration.
Analysts and the press were barred from more than a third of the sessions. I could not help but wonder: what are they hiding or embarrassed about? This is the only user conference that I’ve attended where analysts were barred from sessions. If competitors can attend these sessions, why not analysts and the press? I was told that keeping analysts out of a session is the carrot used sometimes to get an end user to speak. But that explanation does not fully explain what was going on because many of the sessions we were banned from were led by JDA personnel and had no end users speaking.

In conclusion, May is user conference month in the supply chain software industry and I’ve attended several so far. This conference had more good supply chain end user stories than the others I’ve attended.

How to Best Describe Demand Signal Repositories

Consumer Packaged Goods (CPG) | By Steve Banker • 12/14/2009

Angélique Moon, Director of Product Management for Consumer Goods at Oracle, briefed me recently on Oracle’s Demand Signal Repository (DSR) solution. At the end of the presentation, Ms. Moon and I bemoaned the fact that the vocabulary used to describe these types of products is not very good. Shortly after, I had a similar conversation with Razat Guarav, the SVP of Sales at i2 Technologies (both Oracle and i2 are ARC clients). For me, this topic goes beyond semantics. If the products and applications in this area are not properly named, then many supply chain professionals will not understand what they do. And what they do is the next frontier of value chain management in the consumer goods value chain.

Ms. Moon made the point that the term “demand signal” focuses you on the demand data you are using. The term “demand sensing” is similar in that regard. However, for most companies, the most important demand signal they sense (i.e., demand data they consume) is point-of-sale (POS) data. Almost all consumer goods supply chains make use of demand signals; unfortunately, most of them use shipments from their distribution centers (DCs) to retailer DCs as their demand signal. We’ve known for years that using shipment data for your demand forecasts leads to the bullwhip effect.

From a demand data perspective, if we used the term “store consumption” data, most supply chain folks would interpret this as POS data. However, the folks in marketing and retail sales accounts, who also need to use the data in a DSR, would likely confuse this with syndicated data. They would reserve the term “POS” exclusively for data received directly from a retailer. A term like “downstream data” could provide a clearer meaning to all. At this point, however, the term “Demand Signal Repository” is well established, so I don’t see it changing to “Downstream Data Repository” even though I think it’s less confusing.

A DSR holds downstream data, but it is the applications and analytics that reside on top of the DSR that provide better plans or responsiveness. Several DSR vendors have made the point to me that by feeding DSR data into the right kind of supply chain application, your processes become “demand driven.” So the term “demand driven” refers to the nature of a supply chain process, while DSR refers to the data.

But when most supply chain professionals hear the term “demand driven,” they think of a fast and responsive supply chain. DSR supply chain applications will improve your supply chain, but they won’t necessarily make your supply chain fast and responsive. What a company accomplishes with granular store-level demand data depends upon what type of supply chain it has and what it is trying to accomplish.

Types of DSR Supply Chain Apps and Planning Horizons (Source: ARC Advisory Group; click to enlarge)

A food and beverage manufacturer, for example, can use DSR data (POS, store inventories, shipments from retail DCs) to become more demand driven by making its replenishment process more responsive to what is actually selling in a grocery chain’s stores.

But if you are an apparel manufacturer with a supply chain that starts in China supplying retail outlets in North America or Europe, DSR data will not make your supply chain “demand driven” in the sense that it becomes more highly responsive. Lead times of three to six months will make that impossible. But DSR data (POS, store loyalty, syndicated data, etc.) will improve an apparel company’s demand forecasts. Thus, instead of speaking of “demand driven” applications, we should really speak of supply chain applications that are capable of leveraging downstream data.

Some supply chain professionals speak of “sell into” versus “sell through.” The former applies to shipments to a retailer’s DC, while “sell through” refers to when consumers take product off the shelf and but it. DSR applications, therefore, can be considered “sell through” applications. The downside of this term is that it sounds too much like a Customer Relationship Management (CRM) application.

Sell Into vs Sell Through (Source: ARC Advisory Group; click to enlarge)

Mr. Guarav refers to i2’s solutions in this area as being focused on “shelf-centered collaboration.” This is a term I like because a core part of the emerging DSR-based predictive analytics are focused on reducing out-of-stocks, detecting phantom store inventory, and discovering the root causes of both. To the extent that these analytics have workflows attached to them, for example, having merchandisers check a particular store for phantom inventory, these could also be considered “shelf centered applications,” which is the best terminology I’ve heard in this area.

Software as a Capital Expense

Cloud/Software-as-a-Service | By Steve Banker • 12/04/2009

Earlier this year, some of my colleagues here at ARC wrote a Strategic Report titled “Capital Expenditure Survey 2009” (available to ARC clients only). The report got me thinking about the differences between how hardware and software are expensed, and how those differences affect a logistics executive’s annual budget.

I talked to executives at some of our logistics software vendor clients, including i2 Technologies, RedPrairie, Manhattan Associates, and Tecsys, to see how their customers approached this issue. According to these vendors, companies typically depreciate software within three to five years, a much shorter timeframe than expensive capital equipment. However, the ROI model customers use to justify software purchases can be quite different. Manhattan Associates, for example, reports that in helping customers put together a ROI model it often shows costs versus savings, and the time value of money, over a five to seven year timeline.

How do these budgeting issues affect logistics executives? In my conversations with them, almost all report that the annual budgeting cycle involves cost targets, and these logistics costs roll up to the Income Statement.

For logistics executives with private fleets, the Balance Sheet also comes into play. For these executives, one of their annual budget exercises is to look at their trucks and decide which ones to sell based on their book value, whether a truck is experiencing excessive downtime or increased maintenance or repair costs, and the opportunity costs involved (i.e., the costs of not investing in new equipment). New trucks might have better operating performance, in terms of fuel efficiency, safety, or emissions, so the differences in performance and quality between old and new equipment can be missed opportunities for performance improvements.

So, one key difference between software and hardware is that hardware has a book value, while software does not. The book value for hardware represents the resale value, which is reduced by annual wear-and-tear. Enterprise software contracts forbid customers from reselling their software and thus the software has no book value. Basically, there is an exit scenario for hardware that does not exist for software, and the Balance Sheet exercise described for private fleets would never take place for software.

The issue of wear-and-tear and opportunity costs takes a different form for software. Let’s take the wear and tear issue first. A company that buys a warehouse management or transportation management system would almost always purchase a maintenance contract, at least in the early years. The maintenance contract includes helpdesk support, which helps to keep the software up and running, and helps prevent downtime issues that can occur with aging equipment. If a company does not engage in periodic upgrades, the software might pass a point in time where helpdesk support is no longer provided.

The upgrades included as part of the maintenance contracts also include new functionality that allows for new performance improvements. Software maintenance and implementation services hit the Income Statement as an operating expense. While some companies I have talked to have decided to get an upgrade after every few releases (or in some cases, after every release), some companies perform an ROI analysis to determine whether the new functionality and performance improvements are worth the new costs that will impact their budget.

Based on the software’s architecture, some solutions are much easier to upgrade than others. If the software is relatively easy to upgrade, staying current is an easy decision. With other solutions, where upgrades require more costly implementation services, the upgrade decision is more difficult. This is because if you wait too long and there are many releases between the version you bought and the current release, upgrading becomes far more expensive, often rivaling a new implementation in terms of cost and time. In short, while an individual upgrade might not be cost justified when considered in isolation, there can be an opportunity cost associated with not doing periodic upgrades. From a budgeting perspective, the software’s architecture can matter greatly.

This is where the software-as-a-service (SaaS) model gets interesting. There are no capital expenses associated with SaaS, so software purchased under a SaaS contract doesn’t affect the Balance Sheet. Instead, all the costs and benefits hit the Income Statement. If the SaaS solution is single instance, multi-tenant, then there is minimal costs (often none) associated with upgrades. From a budgeting perspective, this strikes me as much cleaner. (For more on SaaS see “A Beginner’s Guide to SaaS and “More Questions about SaaS”).

An Asian Supply Chain Success Story

Inventory Management | By Steve Banker • 11/16/2009

Once upon a time there was a global, medical products company that was very unhappy with the way it was treating its customers in Asia. The company’s main customers are hospitals that use its products in emergency room surgeries. Not surprisingly, its customers wanted a high level of product availability. But this was a problem because the company’s factories are primarily located in North America and Europe, even though Asia (excluding Japan) is its fastest growing region, growing more than tenfold over the past decade. Furthermore, the company’s goal is to triple the size of its business by 2015. But how could it achieve a high product availability rate without flooding the supply chain with inventory?

Here is what the company did:

It established a Supply Chain Centre of Excellence in India to handle sales and operations planning (S&OP) and supply chain strategy for Asia. The goal was to staff this Center of Excellence with talented supply chain managers. The team’s talent was demonstrated by its use of network modeling tools, which requires very skilled practitioners, to recommend a new supply chain network. The network design gurus showed that the company could reduce inventories and write-offs by 25 percent if it had a regional distribution center in Singapore with the capability to replenish actual demand within 24 hours (order to border) to nearby countries. Actually, the fact that the company established its Center of Excellence in India surprised me. There are big tax advantages to setting up centralized supply chain operations in Singapore. I wrote a detailed article on this topic for Supply Chain Management Review earlier this year (see “The Tax Efficient Supply Chain”). However, there is very good talent available, at a much lower price, in India.
The company worked with Oliver Wight to establish an effective S&OP process across the region. It also used OPUS, an online sales analysis tool from Oliver Wight to analyze sales data (actual and forecast) across hierarchies (products, geography, customers and time periods). While I consider Oliver Wight the premier consulting organization for aiding companies with S&OP, I am not particularly impressed with OPUS, at least not in comparison to demand management solutions from vendors such as i2 Technologies, Oracle, and JDA (i2 and Oracle are ARC clients). The company, however, is using a best-of-breed supply chain planning solution for global manufacturing planning. Then again, who am I to make editorial comments? The company believes OPUS was of great aid, particularly in allowing it to compare the plan to the forward financial forecast, thereby ensuring business alignment.
In parts of its business, the company has implemented consignment and vendor managed inventory (VMI) solutions by using EDI with the hospitals. In Hong Kong, for instance, hospital orders are triggered electronically when a nurse in the operation theatre scans one of the company’s products. Depending on the inventory levels in the hospital’s warehouse and the agreed upon min/max levels, this becomes a signal to send more inventory to the hospital.
Moving forward, the company intends to adopt “perfect order” as its prime supply chain performance metric by 2011. Its version of the perfect order metric is defined as on-time, in-full deliveries of quality product with accurate invoicing to customers.

What has the company achieved so far? Product availability has improved by 15 percent, forecast accuracy by 40 percent, and inventory turns by 16 percent. So, the company is living happily ever after—at least until 2015 when it will see if its goals for revenue growth in the region have been met.

A complete analysis of logistics trends, technologies, and services

Archives

Login