6 Misconceptions about JD Edwards Blend

JD Edwards Blend Infographic

They say first impressions last, and that seems never truer than when it comes to the impressions of the JD Edwards Blend module. Issues and shortcomings with the module that were around in the beta and first release of Blend are still raised and commented on today, some 15 or so years later. It appears the first impressions of Blend were shared far and wide in the early days of the module and despite considerable development and improvements since then, they linger as misconceptions today.

I will address six of these I hear most often.

1. “There are too many screens and clicks needed”

This is perhaps the most common complaint about Blend. And one of the most legitimate complaints off the shelf. However, since the original release, several “speed function” applications have been added to reduce the number of screens and tabs.

What Oracle has really done in the last few years, though, is to focus on improving the User Experience by delivering a suite of “personalization” tools. Rather than address individual modules, screens, or workflows, which risks never satisfying everyone, they have developed tools that allow each winery or even user within a winery to personalize screens to suit their process. For example, we have used this to reduce the number of fields on a screen to only those relevant for a given process and consolidate separate tabs of fields onto one tab, so no additional clicks are needed.
The introduction of Orchestrator has been even more of a game changer. Entire screens can be replaced, either within JDE or by outsid e systems, from Excel to web apps, and everything in between. Orchestrator can be used to “communicate” with JDE, following all of the JDE business and logics rules, to enter, retrieve or update data in JDE. This truly allows each organization to tailor the data input experience to their processes. This combines the power of a sophisticated blend system with whatever front end interface or process the customer desires.
If you’re running Blend already, and this is a complaint in your organization, we recommend reviewing the highest pain point processes and corresponding JDE applications to map out ideal processes and see if a combination of personalization (first choice) and then Orchestrations can simplify the interface and match the processes more closely.

2. “It runs all weekend”

There were certainly performance issues in the early releases of Blend, and, to be honest, it took Oracle too long to address these, but they largely have been addressed today. Over the last several years Oracle has put a lot of effort into tweaking the structure and tuning the performance of the perhaps infamous dependency chain engine so that it now performs fine. It’s a sophisticated engine that delivers complexity beyond many other systems, and in some high data volume instances there certainly is some response latency during processing, but it’s not a “go and make a cup of coffee” scenario.

If you’re experiencing longer than expected processing time, we recommend having your IT or CNC resources conduct a tuning exercise over your environment; very long processing time is no longer “normal.”

3. “Blend is not easy to implement”

So, yes, it is true that implementing JDE and the Blend module is a significant undertaking. JDE is a true large-scale Enterprise Resourcing Planning (that’s what ERP stands for) system, like SAP. Being an enterprise-scale system comes with pros and cons. On the con side, they are a bigger effort to implement than small standalone applications. However, on the pro side, if implemented correctly, they can be an end-to-end (in the case of wineries, grape-to-bottle to order to cash) integrated system, in the true sense of what a system should be: you don’t have one application for your winemaker and another for your accountant.

JDE is also almost endlessly configurable (see elsewhere for a discussion on that) which again comes with a con, that configuring takes time to get right, and a pro, that it can be configured to meet each individual winery’s needs. Many standalone applications have little or no configurability options; you take what you’re given and adapt to that model.

While this might seem obvious, it is even more important with a large scale ERP implementation: we strongly recommend that you engage experienced JDE, JDE Blend and wine industry experts to help you implement. 

Wine is not widgets and Blend is not Manufacturing – make sure your implementation team and consultants know that!

4. “There aren’t (m)any out-of-the-box reports”

In terms of traditional reporting (i.e., add the filters, click “run,” get a report that can be printed, etc.) this was and is true. Originally, JDE went in a different direction, looking to provide in-system query applications that can viewed online, personalized, and, if desired, be exported, rather than formatted run and read reports. An application like Inventory Vessel View can be queried, reviewed, have filters changed, and re-queried, indefinitely all within the one interactive live screen rather than having to re-run a report multiple times. If data then needs to be analyzed or printed for formatting, it can then be exported and manipulated in Excel or similar tools. While this doesn’t provide the pre-canned reports of some systems, it is arguably more powerful in terms of providing live, real-time data for review.

Additionally, with the advent and growing adoption of tools such as PowerBI that allow a winery to quickly create the reports and dashboards that support their key metrics, the value of generic reports is probably dropping over time. These tools can allow for reports to be quickly built based on each winery’s specific needs, incorporating other data from outside the winemaking system when needed.

As an aside, Oracle has released role-specific dashboards within JDE, such as “winemaker” and “cellar operations,” but personally, the effort to get these to be useful for each individual winery probably outweighs the value. So, we recommend a tool such as PowerBI instead, especially as it can bring in non-JDE data as well.

5. “Need to build custom solutions to fill gaps” or “Requires too many customizations”

No computer system can satisfy everyone’s needs off the shelf. JDE’s approach, which applies generally as well as to the Blend module, to dealing with customizations is two-fold:

  • It is highly configurable; yes this means more up-front effort to get the configuration to match your processes and workflow, but most standard winemaking and cellar processes can be reflected through configuration.
  • It can be customized; while some companies insist on a no-exceptions “vanilla” implementation (i.e., no customizations at all) and others customize to a point where it’s barely recognizable and almost impossible to upgrade, we recommend a middle ground of minimizing customization and allowing “bolt-on” customizations where necessary, making JDE and the Blend module particularly powerful.

Other smaller applications usually have very limited configuration options and many allow no customizations; they are the Quicken of blend management. This “take it or leave it” approach is great when the application functionality matches your processes, but leaves you stranded when it doesn’t. JDE offers two approaches to address this as discussed above, but this has come to be seen to be a negative rather than positive. 

In part, this is because the wrong resources have been used to configure JDE and especially Blend (where knowledgeable resources are scarce but, hey, we know someone!!), resulting in process gaps and frustration or unnecessary customizations being applied. In other cases, it is because companies have made decisions to customize first, ask questions later, rather than adopting a detailed process review and solution, cost and benefit analysis before embarking down this path. 

As with the section on implementation, we recommend that getting the right resources is critical in deciding on what, if any, customizations are needed. Always look to configure first, but we also believe the right customization can be worth its weight in grapes!

6. “Oracle is not adding new functionality to Blend” 

As stated earlier, many perceptions of the Blend module are based on the first release, and in some cases, based on the JDE 8.11 Beta release that was tested at Foster’s Wine Estates Americas (FWEA, now Treasury Wine Estates) in 2006. As part of the first production release in JDE 8.12, FWEA partnered with Oracle and helped fund a suite of key enhancements that were implemented initially there and later incorporated in releases 9.0 and 9.1. So, yes, some of these key enhancements did take time to make it out to the broader community, but they are there now. 

I think it’s fair to say for a couple of years, in the mid to late 20-teens, Oracle did pull back a bit in terms of adding new functionality. However, in the last couple of years, there has been a resurgence in enhancements across the Grower and Blend modules. Additionally, Oracle’s engagement with the wine industry has increased, including with the Wine and Agribusiness user groups. Some enhancements have been “back-end” performance improvements while others have been front-end functional changes. The Blend module is part of a large ERP, so enhancements are spread across a lot of modules. But most quarterly releases over the last couple of years have contained one or more Grower or Blend enhancements, as well as benefiting from system wide tools and performance enhancements. As discussed elsewhere, Oracle is also investing strongly in the general User Experience tools, which is providing mobility, usability, and interactivity enhancements across all JDE modules, including Blend.

We have seen a re-engagement of the Wine and Agribusiness Special Interest Groups (aka User Groups) by Oracle and JDE industry customers over the last couple of years. We recommend joining and engaging in those groups, to help lobby Oracle for enhancements, hear about the latest advances, and collaborate with fellow industry customers on best practices.

Summary

The wine industry, especially in Northern California, is very close-knit, so first impressions spread quickly and can easily become lore. When JDE released the Blend module in the beta release in 2006, it was far from perfect, and those faults have become embedded in many people’s perceptions. However, JDE and the Blend module have evolved and improved over the 15 years since that beta release. It’s not a perfect system, but configured and implemented correctly, for the right scale of wine operations, it can be a powerful system and definitely worth considering.

If you’re running JDE but not Blend, or considering moving to JDE and JDE Blend, and have any of the above perceptions, we can provide a demo of the latest release and answer any questions you have. 

If you’re already running Blend and haven’t realized the benefits of some of the more recent enhancements, particularly those around the User Experience, we’d be happy do a review of your system and processes and explain where you can make improvements. 

Leave a Reply

Your email address will not be published. Required fields are marked *