Machine Learning Archives

The Arms Race to Leverage Machine Learning in Supply Chain Planning

Business Intelligence | By Steve Banker • 10/24/2017

Artificial intelligence (AI) is hot. Crunchbase reported that over the last year over $4 billion in venture capital has been invested in AI firms just in the US. In the supply chain realm, the branch of AI known as machine learning is where most of the activity is, particularly for software suppliers offering supply chain planning (SCP) applications. Arnaud Hedoux, the Director of Marketing for Demand & Supply Chain Planning Solutions at Dynasys, a QAD company, made the point that “The adoption of machine learning is the key driver in the ‘arms-race’ between software vendors to achieve differentiation.”

Supply Chain Planning has long been an application that has relied on Ph.D.s in operations research (OR) or statistics to build the math that powers these applications. Thus, few planning supplies are buying third party machine learning technologies to embed in their solutions. The planning vendors have built, and are building, machine learning solutions into their SCP applications.

But what is machine learning? Some of the SCP companies I talk to have been too modest in taking credit for their activities in this area. If they can’t label their solution as being based upon a computational technique generally associated with machine learning, they are apt to say their solution has “characteristics” of machine learning, but is not truly a machine learning application.

I think they are being too modest.

Adeel Najmi – the Senior Vice President for Products at One Network Enterprises, who holds a doctorate in Industrial Engineering and Operations Research from Berkeley – agrees. “Learning occurs when a machine takes the output, observes the accuracy of the output, and updates its own model so that better outputs will occur. Any machine that does this is using machine learning. It doesn’t matter if data science methods are used or not. It does not matter if neural networks or some other form of supervised or unsupervised learning technique is being used. It’s important not to get bogged down on the specific technique. What matter is if the machine is itself capable of learning and improving with experience.”

*Machine Learning has been used to Improve Forecasting for over a Decade*

By this definition, when it comes to demand planning, some companies, like JDA, have been applying machine learning to demand forecasting long before AI became hot. JDA figured out how to let the machine automate this process, over a decade ago. Today, several other supply chain solution providers are doing the same thing.

Over time, many more data inputs have been introduced into the demand planning process, and many companies are doing far more forecasts. For example, instead of just doing a monthly forecast in the eastern half of the country, some companies are doing forecasts at the product/store level at daily, weekly, monthly and longer time frames. For a product being forecast daily at the store level, it may be that algorithms applied to the POS data stream have the most predictive power. Forecasting that same product at the warehouse level on a monthly basis, an algorithm applied to warehouse shipment history and warehouse ordering patterns has more predictive power. A forecasting engine with machine learning, just keeps looking to see which combinations of algorithms and data streams have the most predictive power for the different forecasting hierarchies. When if finds it can improve the forecast, it either changes the model or suggests to the planner that the model should be changed in a specific way.

The new AI startups are looking for customers with novel problems they can work on. Interestingly, the established planning companies are finding themselves pulled into machine learning projects from their established customers. As one example, Sujit Singh, the Chief of Operations at Arkieva, explained to me how they were now using machine learning techniques to predict which production machines were likely to break down based on the length of the product run, count of unique products being produced and the specific products that ran on particular machines, to improve production planning. On the demand front, Arkieva is taking market basket analytics, historically something retailers did, and applying these techniques to improving demand plans for business to business companies.

In short, supply chain planning software companies, with their cadre of operations research Ph.Ds who have been modeling complex problems for decades, may be better poised to solve many complex business problems than the hot new Silicon Valley firms.

Machine Learning in the Digital Supply Chain isn’t New

Demand Signal Repositories | By Steve Banker • 10/23/2017

Machine learning has become hot this year and suppliers are investing research and development into using machine learning in the supply chain. But in a conversation with Michael Farlekas and John Lash – the CEO and VP of Product Marketing at E2open respectively – I was reminded of the fact that machine learning in the supply chain is not a new technology. Last year E2open acquired Terra Technology. Terra has been using machine learning to power their demand management and demand sensing applications since 2004. Their customers include Procter & Gamble, Unilever, AkzoNobel, and several other global, multinational companies.

For machine learning to work well, it needs to be a big data application. In this case in addition to doing forecasting based on historical sales, companies leverage other data sets such as their retail customer’s point of sale, recent shipments of products from their warehouses to their stores, the retailer’s orders, syndicated data, and store inventory. Many of these data sets are accessed daily, or even several times a day, so the dynamic nature of demand is captured to a much higher degree than traditional forecasting techniques.

E2open also acquired Orchestro last year. This is a demand signal repository solution which harmonizes retail Point of Sale (POS), syndicated, internal ERP, and 3rd party data into a common view of demand. In other words, the Orchestro solution makes it much easier to access demand sensing retail data sets.

Machine Learning for Demand Management

Machine learning for demand management works this way. The engine is making many forecasts simultaneously in different planning horizons. So, there can be a forecast for demand for liquid detergent in a 100-ounce container to the Walmart store in Tuscaloosa tomorrow, one week out, and one month out. There can also be a forecast for how much of that detergent will be needed at the distribution center in Cullman, Alabama tomorrow, one week, and one month from now. Other forecasts are being done for other big retail customers and channels.

Machine Learning is Used for Demand Sensing in the E2open Solution

For the forecast of what is needed in the Tuscaloosa store tomorrow, it may be that the data source with the highest influence factor is point of sale and the algorithm weights it accordingly. For a forecast of how much of that detergent will be needed in the Cullman warehouse in a month, a different algorithm is used that weights the data sets such that the statistical forecast is most important, recent shipments the second most important; customer orders third, and so forth.

Then every day, all of these forecasts at all locations and all time horizons are done again.

When this was first explained to me a few years ago, my reaction was “even if you can make all these forecasts, why would you? How could you operationalize this?”

The answer is that different forecasts are used in different time horizons by different groups in the company. So, if a factory has a frozen two-week production schedule, and the new schedule starts on October 16th, the factory planner will use the aggregated daily forecasts of the actual 14 days from October 16th through the 30th to create the forecast for demand over this specific time period and based on the projected inventory, determine what products they need to produce for the next two weeks. All other forecasts are ignored until the next production run needs to begin, when they once again use the most recent forecast pertinent to their needs.

But other departments use different forecasts in different time buckets. Thus, on that same Day 0 – October 16th – the transportation department might find it very helpful to know projected shipments to all the distribution centers on October 19th to create their private fleet plan for the 19th. In this case, there is a deployment lead time of 3 days so the daily forecasts between Oct 16th and the 19th are aggregated to determine how much inventory will be at the DCs on Oct 19th and how much will need to be shipped on the 19th to maintain service commitments.

It should also be pointed out, that the machine learning engine does not rest on its laurels. It continues to monitor the accuracy of all forecasts, continues to reweight which data sets are used at all locations in all time horizons. Mr. Farlekas says that E2open has strong evidence that the more humans are allowed to change forecasts, the worse those forecasts become. In short, this is a black box solution.

This is, perhaps, why I had a hard time remembering that the E2open solution was based on machine learning. Machine learning has only become sexy in the last year or two, before that the folks I talked to at the old Terra Technology seemed a bit reluctant to explain exactly how they did what they did, because “black box” solutions were definitely not sexy.

The same dynamic is playing out in the supply planning area for the process manufacturing industry. A leading supplier recently explained to me how they use machine learning to solve a particular planning problem, but then asked me to keep that information confidential because solutions not based on “first principles” in that industry are considered inferior. They have been using this machine learning solution since 2002, but you would never know that from reading their website.

One final point, the E2open solution is a productized solution. Mr. Farlekas said that their solution is “commercial grade, our customers don’t need data scientists and the solution does not require training.”

However, as we begin to look at adding unstructured data sets to our demand models – like social media sentiment – it is a tough problem to analyze that data and transform it into ‘scored’ data that can be analyzed by the demand planning engine. I talked to Jeff Bodenstab, the VP of Marketing at the ToolsGroup, on this topic. They have just released a product called Social Sensing to solve this problem, but he admits it is early stage. They are just going through their first implementations right now. This data set will be most useful for new product introductions and promotions forecasting.

In conclusion, machine learning is a hot new topic for supply chain executives. But it’s not new.

A Practical AI Platform? What a Concept!

Business Intelligence | By Steve Banker • 08/14/2017

I recently got briefed by Spencer Askew, the CEO of Teknowlogi, about the SaaS-based AI Platform his company has introduced. In preparation for the call, I spent some time looking at their web site and then became worried that the call would be a waste of time. I’ve been coming across experts talking about how artificial intelligence (AI), machine learning, and predictive analytics are set to transform industry. This technology is being overhyped. It is as if all you must do is wave your magic AI wand and all sorts of wonderful things will happen.

But I was most pleasantly surprised by the call. Mr. Askew admitted that there are many solution providers that sell AI and then these projects turn into long and costly consulting projects. “A tremendous number of hours can be spent writing business rules and then telling a machine what it should be thinking about,” Mr. Askew said. In contrast, his firm has long and deep domain knowledge of the 3PL industry. Their solution – Tai – has prebuilt analyzers that can look at the data in companies’ various software systems to uncover improvement opportunities without a long consulting engagement.

One class of machine learning solutions looks at data inputs and the desired outcomes with the goal of learning a general rule that can then be applied to improve a process. This is the form of machine learning that Teknowlogi is pursuing. Mr. Askew gave some specific examples.

3PLs, like most companies, like to be paid in a timely manner. At one large 3PL with multiple divisions, prebuilt rules are being used to look at why some divisions are being paid on time by a customer, and that same customer is not paying other divisions in a timely manner. In this case, the desired outcome is to be paid on time. The inputs are how timely the divisions are being paid by their customers and differences in the way the different division’s accounting departments are interacting with those customers. For example, the contract may say that the 3PL should be paid in 60 days. One division is consistently paid more promptly. The division that is paid quicker may send out two email reminders in the week before the bill is due, and then if not paid on time, contact the customer two times by phone per week until paid. A division being paid much more slowly, does not send out an email reminder before the bill is due and, when not paid on time, contacts the customer only one time per month by email and phone until paid. In this case, Tai uncovers the best practice – email reminder in the week prior and then two phone calls per week until paid.

But beyond uncovering the best practice, the Tai system automates the process. The system can automatically send out reminder and dunning emails to the customer, and send reminders to designated accounting personnel to follow up by phone. Mr. Askew estimated that it required about 100 prebuilt rules to discover this accounts receivable best practice and then automate it.

Mr. Askew claimed that they have “millions” of prebuilt rules. That is probably an exaggeration. But clearly, they have predefined many, many improvement scenarios and, for these scenarios, can hit the ground running. Other accounting, IT, density pricing, and cross selling scenarios were described. Patents are pending for many of these scenarios. And while Teknowlogi has domain expertise in logistics, clearly the kinds of cross selling and accounting scenarios they are seeking to improve exist in many industries.

One final point is worth making. What they are NOT doing is pointing their analyzers at data in a single system like a transportation management system (TMS). This is good, TMS and warehouse management systems are already very good at optimizing and executing the processes under their control. Instead, the Tai platform is being pointed at a variety of systems and focused on making improvements in “grey spaces” that are currently not getting enough attention.

This is not the first AI solution I’ve been introduced to. But it is the AI solution which seems most practical.

Machine Learning with Data Overload

Business Intelligence | By Rick Rys • 08/08/2017

Today’s massively increasing collections of data improve the potential value of data analytics applications like machine learning. How can you extract useful answers and conclusions from the data you have? In industry, the “data warehouse” concept has been used to merge operational data with business data. The basic idea is to collect and organize the data before it is stored, with business intelligence-related uses in mind. If, for example, the plant manager wants to see a daily report on the factory production, the data collections and database design are structured for this purpose.

This contrasts with the “data lake” concept in which all imaginable data is simply collected and modern database programming tools like Hadoop are used to organize the data. It’s not hard to imagine that the data lake concept could collect a veritable junkyard of data in the supply chain. For example: imagine digitizing old plant and warehouse photos; scanning old and new plant design documents; and collecting old and new versions of operating procedures and the control and safety system configurations; collecting production records, raw material purchases, records on shipment transactions, product quality measurements from the lab, and the real-time streaming data from the plant control system. Now, connect to local weather databases; sprinkle in some OSHA, EPA, and local zoning regulations; and don’t forget those old VHS training videos.

Basically, the above data collection is disordered and largely unstructured, has high entropy, and would take work (programming) to make it ordered. Surely there are ways to organize and extract useful information from this junkyard of data. Buried deep in this data, you could potentially find the justification to replace a specific piece of factory equipment that limits production rate or that is responsible for off-spec product.

Just because we have a massive junkyard of data in a data lake does not mean we have the right data to answer questions like: “How do I improve production rate, reduce maintenance costs, or improve product quality in my factory”. Machine learning with neural networks is a promising technology for extracting useful models for data, but typically needs very specific data that is not likely to be found in a data lake.

An IEEE article points out that, in many cases, you need more data than your big data “junkyard” can provide. In this example, the article’s author (Jacques Mattheij) decided to build a factory that sorted tons of mixed Lego blocks he could buy at low cost into sorted Lego blocks he could sell for nearly four times as much. Perhaps he was motivated by the technical challenge more than the business opportunity. The basic idea is to use a USB camera connected to a PC that monitors a conveyor belt. The PC needs to identify each Lego block and use puffs of air to blow parts off the belt into sorted bins that contain a specific part type. The hard problem was to train a machine learning algorithm to correctly identify each unique Lego part. Considering there are more than 1,000 types of Lego blocks, rather than photograph each unique type of Lego block from multiple angles and label each photograph, Jacques found a faster way to train his neural model. Jacques started by creating training sets of some Lego types, but as he used early models to identify mixed Lego types he would correct the many mislabeled parts and use these new labelled photos to further train his model. The next test had even less mislabeled parts, which were easier to correct. This procedure continued until the rate of incorrect identifications became very small.

Organizing the data collection for a specific need (like production reports) is a good fit for the data warehouse concept and established relational database technology. Creating data lakes with massive amounts of data does add considerable flexibility for the types of analysis that can be done. With some programming effort, you could use the data from the lake to build the types of business intelligence applications that have been done with data warehouse concepts, but from a programming point of view you would need a good map of all the data you have, and how to access it with a query. It is possible to use data in warehouses and lakes for machine learning applications, but in many cases the data you will need is just not there.

The conclusion here is that data warehouses, data lakes, and even the real-time and historical supply chain data are all great sources of data to make useful reports, regressions, and discoveries that can help drive business efficiency. However, even the biggest piles of data will not contain all the information needed to build most machine learning applications that can bring automation to the next level. The Lego example shows that to create a useful machine learning application required the creation of new data needed to train the neural networks and some of this data was created during the development process. Successful applications of data analytics and machine learning technology work best when there is a clear vision of a problem to be solved and modern tools are deployed in a thoughtful manner.

CSX’s IoT Enabled Machine Learning Journey

Business Intelligence | By Peter Reynolds • 04/28/2016

The Internet of Things (IoT) and machine learning are both getting a great deal of attention. Many pundits say there is more substance than reality to this coverage. But one area where the ROI of IoT is clear, is in the area of predictive and prescriptive maintenance.

At the 2016 ARC Industry Forum in Orlando, CSX, a US-based rail transportation company that manages 21,000 miles of track and operates a fleet of 4,000 locomotives, presented the company’s long-term strategy for leveraging predictive maintenance to gain competitive advantage.

In 2004, CSX changed its business strategy to focus on profit drivers and the competitive advantage the company could achieve by leveraging newly available technology.

With the knowledge that the value of the company’s operating assets – mainly comprised of locomotives, cars, and track – exceeded $60 billion, cor-porate eyes quickly turned to asset utilization. With replacement costs in the neighborhood of $1 million each, locomotives represented the largest cost pool to address. In addition, the company’s rail infrastructure – with some rails dating back to 1902 – was starting to show its age.

By tracking company financial results between 2013 and 2014, the company was able to identify strong evidence of an increase in revenue and profit, which Mr. Moty attributed to asset utilization and technology enablement.

Prior to this, CSX had embarked on internal and external benchmarking ac-tivities that began when Mr. Moty attended a Berlin InnoTrans Conference where he came to the realization that Europe was much further ahead of North America in terms of enterprise asset management (EAM). CSX teamed up with ARGO, a consulting firm, to look at internal processes and uncovered surprising results.

CSX Improvement Opportunities (Based on CSX-Arco Studies)

This study revealed that CSX’s expensive locomotives typically only spent 40 percent of the time actually pulling freight; the only time the company makes money. In addition, the company learned that its employees were only productive 23 percent of the time, a staggering statistic. This internal analysis revealed over $100 million in potential savings; driving CSX to shift its focus to improving asset utilization to improve operating ratio and return on assets. This involved several parallel initiatives.

CSX successfully tied a long-term incentive program for executives to operating ratio and return on assets. This new focus on return on assets (ROA) drove CSX to develop new measures for asset performance. The company’s Asset Performance Index (API) describes how much of the time a particular asset is making money and how much time it is unproductively sitting around at a maintenance facility or terminal. The company also created a train delay index to better understand the severity of a trip failure and the cost attributable to delayed trains.

CSX’s core business is to safely and reliably transport customer goods on time. However, the company was previously plagued by operational and catastrophic failures. CSX reliability professionals knew the performance-to-failure curve all too well and since 2003 the company had experienced over $1 billion in total losses in 2,500 train derailments due to human factors, tracks, locomotives, and other causes.

CSX started its journey by initiating a series of projects designed to enable the company to effectively predict and more rapidly resolve (or avoid) issues with its extensive fixed assets (tracks) and costly rolling assets (locomotives and rail cars.) To help on this journey, CSX selected Mtell, a leading supplier of machine learning technologies for industrial assets.

Critical IoT Sensor Feeds

To be able to identify and remediate track-related issues that could cause derailments and wheel or bearing damage on the company’s fleet of locomotives and freight cars, CSX deployed a series of interconnected sensors and wayside systems that continuously study the car movements throughout the US East Coast. CSX calls these “super-sites.” As a locomotive and the entire train pass through these stationary monitoring sites, the system reads the acoustic signatures of the bearings, peak impacts/pounding on the rail (indicating out-of-round wheels), and looks at lateral forces (geometry) such as wild or hunting trucks. Automatic equipment identification (AEI) sensors count the ax-les to let rail maintenance crews know exactly where repairs are needed.

This IIoT-enabled monitoring and predictive analytics system, developed in conjunction with Mtell, helped CSX drastically reduce the incidence of derailments and wheel- and bearing-related failures. The key was to be able to catch the failure before it happens and increase the notice time by which maintenance personnel could act on the alert.

CSX also worked to improve their locomotive reliability. Two percent of the company’s 80, $100,000-plus locomotives were failing each year. CSX decided to embark on a three-phase pilot project with Mtell to determine whether oil analysis could be used to predict costly locomotive failure in time to prevent these failures.

Previously, the company had been performing simple threshold analysis on engine oil samples to alert personnel of issues and initiate workflows with some moderate success. But it suspected it could do more. The Mtell software revealed increases in iron, viscosity soot level, and anti-wear and how the percentage of each impacted the overall signature. The Mtell software further identified 18 low-water-pressure problems that were worth paying attention to. The process involved finding and “training” the Mtell software agents against failures. A new Prescriptive Performance Improvement Request (PIR) workflow was initiated, and CSX was able to successfully move from a “run to failure” operating model to a proactive preventive/predictive maintenance operating mode.

In the future, CSX will integrate all locomotive communication systems into the Mtell software. This will involve over 300 sensors for each locomotive and 1,200,000 potential data points for the enterprise.

Machine learning is not new; its roots can be traced back to before the first computer. What has changed is the use of automated machine learning, the scale of computing power, intensely powerful algorithms that process massive amounts of data, and intuitive uses for time-series sensor data from machines and manufacturing processes. Machine learning enables a new paradigm. Now, rather than having a problem and formulating an algorithm to solve that problem, we can give the machine the problem and let the computer solve it.

Shippers of course, always welcome programs like this that improve the ability of carrier partners to deliver goods on time.

What is Machine Learning? How will this Technology Change Supply Chain Solutions?

Business Intelligence | By Steve Banker • 01/04/2016

My colleague at the ARC Advisory Group, David White, wrote an interesting strategic report in which he explained how machine learning is helping support more efficient supply chains. Machine learning is being discussed more often in supply chain contexts because of the buzz created by the Internet of Things (IoT). But I was not quite sure what machine learning was.

The strategic report goes into quite a bit of detail on use cases for machine learning and discussion of the technology. I’m only going to summarize a few key points from the report here.

First of all, in one of the more interesting use cases, “machine learning techniques were applied against multiple data streams collected from an oil rig during operation. Deviations in the pressure readings for a water injection pump indicated that a seal in the pump would fail within days. This early warning enabled the seal to be replaced before it failed, avoiding the associated downtime. The owner-operator estimated that this data-driven predictive approach avoided an estimated $7.5m in losses from unplanned downtime.”

Machine Learning Can Help Prevent Unplanned Downtime

So what is machine learning?

“Three things make machine learning different than predictive analytics. Machine learning applications are self-modifying, highly automated, and embedded. That is, machine learning algorithms are designed to continuously adapt and improve their performance with minimal human intervention. Machine learning algorithms are also embedded within a process or workflow. That is, they become seamlessly integrated into the process to the point where they are invisible to the user or operator. Machine learning algorithms are in their element solving problems that are too difficult or complicated for human programmers to code.”

Examples of this include the suggestions we get about what we might be interested in purchasing when we go on Amazon, or the suggestions that Netflix provides to customer on what programs they would be interested in watching. In both cases, these recommendations are driven largely by machine learning algorithms. On Netflix, for example, as each viewer watches shows they like, the algorithm learns more about what that particular viewer likes to see.

“So reviewing our key criteria for machine learning, the Netflix recommendation algorithm is:

Self-modifying. Movie and TV recommendations change over time as the algorithm learns more about the viewer’s preferences.
Highly automated. The learning happens with minimal active intervention by the viewer.
Embedded. The algorithm is a seamless, unavoidable part of the over-all Netflix experience.”

Machine learning is not a magic wand technology, however. “Successful machine learning depends on data, lots of it, and the more the better.”

On the other hand, we are entering an era in which vast amounts of data will be generated by the Internet of Things. That, in turn, will usher in a raft of new machine learning applications, including new supply chain applications.

A complete analysis of logistics trends, technologies, and services

Archives

Login