At DoubleBlaze, our BlueYonder consultants started out deploying their pricing solutions over 12 years ago and are the BlueYonder premier partner for implementing their pricing solutions. We frequently work with retailers to help solve pricing problems, offering advice, building case studies, and architecting the best path forward. While retail price optimization and price list management software are strong suits in our practice, we also focus on their other solutions for retailers including demand planning, category management, and warehouse management.
BlueYonder Demand Planning
BlueYonder (formerly JDA) Demand Planning is a solid tool for managing retail forecasts. BlueYonder has two flavors of demand planning currently, the traditional planning tool based on their Supply Chain Planning and Optimization (SCPO) platform and the newer Luminate tools based on machine learning. A little bit of history is that a few years ago, JDA recognized they were falling behind in the use of machine learning tools so they acquired a small company out of Germany called BlueYonder that was strong in machine learning. They liked the name so much they adopted it for themselves and are now known as BlueYonder. The legacy BlueYonder company from Germany had a long history in machine learning which allowed JDA to leap forward in their use of the technology. At DoubleBlaze, we service both the traditional BlueYonder Demand & Fulfill as well as Luminate Demand Edge.
Category Management Consulting
The BlueYonder Category Management platform that we in the community call Cat Man handles all category management functions including space planning, planograms, and assortment optimization. The solution allows you to deliver better assortments, create better floor plans and planograms, and ensure you have the right products at the right stores in the right place to increase your margins. The system also helps maximize inventory and reduce carrying costs. At DoubleBlaze, we help retailers and CPG customers with new implementations, train employees on the solution, and update or enhance their current implementation.
BlueYonder Warehouse Management
The BlueYonder Warehouse Management System (WMS) is the third pillar in our extended BlueYonder retail planning focus. The BlueYonder solution handles the base use cases such as picking, packing, shipping, receiving, etc. as do most of the solutions on the market today. But it also handles more complex use cases such as slotting, yard management, and real time inbound/outbound processing. As with the other solutions, DoubleBlaze can handle new implementations, go lives, or enhancements.
New Projects or Enhancements
Whether you are starting a new project or need simple enhancements, our BlueYonder consultants can help. We can provide turnkey implementation services or staff augmentation with project managers, solution architects, functional and technical consultants. Schedule a meeting with us if you have an opportunity.
Lead Time Calculation is Hard
What’s in a delivery date? Turns out a lot in today’s complex supply chains making lead time calculation very difficult! As discussed in our previous blog article Intersection of Price Product and Availability, customers want to know what product they’re getting, how much it costs, and when they can get it. Each of these questions are answered in increasingly complex ways as manufacturers, distributors, and retailers optimize their operations, supply chains, and diversify their customer touchpoints.
Specifically here, we’ll touch on delivery date or lead time calculation and available-to-promise (ATP). Delivery date comes into play before the order has been promised when a customer is trying to finalize an order. As supply chains optimize, there aren’t as many finished goods in the system so determining delivery dates is more complex than simply checking inventory. Also, in times of limited supply, goods may be tied up with contractual obligations on service levels and allocations. Throw in build to order or mix options, and the myriad of permutations is even harder to predict. Finally, there are transportation issues that could delay or complicate the answer.
When we previously did this for a computer manufacturer, the permutations were so complex, we simply took a statistical average for lead time and used that, then when they couldn’t deliver on time, they’d notify the customer and take the customer satisfaction hit or make them happy by delivering early. But when you’re a manufacturer selling to assemblers or selling through eTailers like Amazon or Ebay, they take delivery dates more seriously and if you miss your date there could be severe consequences.
Accurate Delivery Dates
So how do you limit your inventory exposure and also get an accurate delivery date back to customers? Here are some of the ways we approach it:
- Standard Lead Time – As mentioned above, a standard lead time is the easiest to simply put on a product. This is not always the most accurate or desirable method because it means you may have to keep more inventory than needed to maintain service levels. In this case, we typically estimate the lead time by looking at past deliveries and then tweak that on products that are quicker to deliver or take longer using rules.
- Available to Promise – Available to promise is a complex mix that combines current orders with delivery dates, service levels, on hand inventory, and future deliveries. Taking all these factors into consideration is difficult when you have a complex supply chain. There are a couple products we use including BlueYonder’s Order Promiser and SAP IBP (formerly APO) that can accurately model all these moving parts and provide a good date. With these systems, you also have the ability to move orders or delay them given service levels or a customer’s willingness to wait.
- Allocated Available to Promise – Building on ATP, in industries like semiconductor, there are also allocations to consider and limited supply. These commitments complicate the delivery date answer because you may have firm orders further out that you’ve reserved inventory for, but need to satisfy an order now. The AATP engines can see that you have replenishment orders pending and allow you to consume current inventory expecting that you will be able to satisfy the future orders with new inventory.
- Build to Order – Build to order needs a special mention because it complicates the process even more. With build to order or configure to order we typically model the most constrained parts and don’t worry about the other parts that have more availability. We have used the standard lead time method on the constrained parts in the past, such as processors for computer manufacturers, but have also used an ATP engine with the constrained parts. Both methods work and it depends on the situation as to what we would recommend.
Customer Service and Lead Time
In all cases, customers and customer service people need the ability to query the ATP engine for availability or delivery dates when either taking orders, changing orders, or checking order status. Customer service people also need the ability to make decisions like shifting availability when possible or pushing orders out when a customer allows it. In large enterprises, these decisions must also happen in real time so that customers can make their own decisions. As supply chains get more efficient and customers get more demanding, order promising quickly outgrows a customer service reps ability to simply check inventory and these ATP engines can fill that need.
What Next?
If calculating lead time and delivery dates is a problem for you, we can help. Whether you are using SAP, Oracle, some other ERP, or planning tool, we can extract the data and model your supply chain. For more information or to discuss how we can help, please schedule a call!
One of our customers initiated a new program to sell through eTailers. As mentioned in another blog article, you have to get the product data to the eTailer, receive orders, and then foster growth. In this article, we’ll talk about how we got product, price, and inventory information to this customer’s channel partners.
When tasked with this problem, we first went through an evaluation process, and then a vendor selection process. Ultimately, the vendor we settled on was Akeneo. The Akeneo platform was born out of the founder’s experience with Magento. They saw that there was complexity managing the data that went into the eCommerce system. So, they created Akeneo to address the challenges. We’re up and running now and we are building a sustainable model for servicing the channels. This starts with automating the process for getting product, price and inventory data to the eTailers.
Overall, Akeneo is a solid product. It’s open source so you have access to the code to make changes and it’s pretty easy to modify. For this customer, the high level process was straightforward: Import products, prices, and inventory positions into system; update data; and then export in format for channel partner.
It was a little different than Akeneo’s original intention which assumed you were getting the same product data out to the omni-channels you serviced such as web, print, mobile, etc. Our use case was different in that we were getting product data out to lots of different eTailers. The products weren’t always the same, the descriptions weren’t always the same but could be, and the prices and inventory weren’t always the same. So, we had to make some modifications.
The baseline Akeneo workflow provided a solid foundation of features we could build on to support the operations. The basic premise is the same – data is imported, data is modified, and data is exported. In the Akeneo interface, these steps are defined as Collect, Enrich, and Spread.
Collect. The first step is to import the data. In this case, we had a few different sources of data – all flat files – which were delivered to a secure FTP server every morning. From there, we had different profiles of import scripts in Akeneo. These imports are scheduled daily using the internal Akeneo cron utility. There is some custom processing we had to do on import such as concatenating several fields together, but it was simple enough to do in PHP. We also had to modify the import scripts to preserve manually overwritten data which we will talk about more in the Enrich step. We added a pull from an external secure FTP site to move the files to the local server and we added a number of error conditions that are reported during import. The scripts run daily and there is a lot of data that changes, so these additions were critical to making the process work in production.
Enrich. Once the data is imported, we enrich it. Akeneo’s base functionality has most of features we needed in that you can view and change product details, you can see historical changes, you can create product classes (which they call families) to determine what attributes are required, and you can categorize the products in one or more catalogs. All necessary things for managing product data.
For us, the imported data can change frequently and we had to have a process to preserve manually overwritten data, otherwise we would have had to re-enter the manual data after every refresh. We also wanted to utilize Akeneo’s internal history function to show when an attribute had a manual override so that a manager could go back and research who had made changes. We accomplished this by adding additional ‘preserve’ attributes that mirrored the standard attributes and then added custom code that modified the history.
The next change we made was to modify the Available functionality. We added a toggle on the data grid to add or remove the part from the channel and the ability to mass update the parts to toggle the Available field. We use the attribute to indicate if the product is available in the channel and only export those parts during the export.
Next, Akeneo has global attributes and channel based attributes. For us, we don’t always use the same data across channels, but can. So, in the edit screens we added an ‘Apply to all channels’ button for the attributes that could. You can modify the value, then if you want it to apply across all channels, you click the button and it copies the data.
Another feature was to only export a partial list of parts in an export profile. Some of the channels only want net change for product descriptions, but then a full export of pricing and inventory. So, we modified the data grid to allow us to send a partial list of exports to a selected export profile.
Finally, we added price and inventory reports that would show us prices and inventory across all channels. We needed a single place to go to view prices and inventory across multiple channels and Akeneo does not provide that functionality in the base install.
These were all straightforward changes that we implemented in the PHP code which were done in weeks not months.
Spread. Once the data is finalized, it has to get to several different channel partners including eTailers like eBay, Sears, and Amazon. Each of these eTailers has their own data requirements and delivery nuances. For example, eBay requires the data in a zipped, tab delimited file format. They require a file for product information and a separate one for price and inventory updates. For automated updates, Sears requires the data in an XML format and sent via an HTTP API. To complicate things further, some vendors require minimum or maximum characters on different fields. All of this is handled by the export process.
Akeneo has export profiles which we use for all the different file formats. Each channel partners has one or more export formats that mirror the files they require. For example, eBay has two export profiles – one for product data and a separate one for price and inventory data. We took the process a step further and added ‘delivery’ functionality. Once the data is exported, it is then packaged for delivery to the respective channel. In the case of eBay, the files are zipped and then ftped to the eBay servers which are automatically imported at a specified time interval.
Summary. All in all, Akeneo provided a solid base from which we expanded the functionality for our specific needs. The tried and true technology stack of PHP and MySQL, while might not be the most exciting technology, is very mature and easy to change. We made the mistake of chasing new technologies initially and it bit us in the wallet. It was much more expensive than it needed to be, was difficult to modify, and difficult to find people that knew the technology stack. Akeneo was much quicker –from start to finish took 3 months – and we’re on to the next step of helping them increase sales in these channels.
