what's in the word 'erp'? (Part 2)

---

In the previous blog post, I gave some historical context around the foundation of enterprise resource planning (ERP) software, how ERPs have evolved over time, and the challenges of updating ERP software to fit the world we currently live in. At the conclusion of that blog post, I stated that I’d outline and rate the four user interfaces within the Eclipse ERP software that I believe are (a) critical, and (b) not performing up to the standards I’d like to see in the market, which I outline in this post. 

​(1) Inventory Planning: Inventory planning is at the heart of what we do. Eclipse integrated the Economic Order Quantity (EOQ), which is a simple formula accounting for an item’s demand, cost, and the cost of holding an item to determine the best quantity of an item to reorder. While this is a pretty solid way of coming to a projection, I feel using just one formula is limiting. Any other third-party software would have a variety of purchasing formulas to take into account. Many options even go so far as to analyze what could be better for a particular SKU. And most software options have the capability to understand the physical size of the space available for storage, which is a pretty important factor in purchasing decisions. In Eclipse, that element is woefully absent. Lastly, the Eclipse formula doesn’t address the amount of product that domestic distributors are purchasing from overseas. Thus, the factor of just how much product can fit into a container ship and make it into your warehouse is simply not accounted for. If I were building an ERP system from the ground-up, I’d ensure the demand-planning component of that program incorporated the quantity to order, a what-if analysis, location dimensions, and container ship limitations. As I see it, those are currently big gaps to fill within the Eclipse ERP software. 

Zerion’s Rating of Eclipse purchasing function (as compared to what’s available in the wider marketplace): 5

---

(2) eCommerce: Harking back to the point I made in the earlier blog post regarding the Internet bursting out of the gates long after the Eclipse ERP software had been written, it’s obvious that customers – and in many cases, the distributors themselves – are looking to the speed and efficiency of online ordering in this day and age. This has probably never been more evident than in the times of COVID-19, as we watch the popularity of platforms such as Shopify, BigCommerce, and Amazon – not to mention stock prices – confirm the big business of eCommerce. Eclipse falls short in bringing the intel that’s available to counter employees to a broader base of remote contractors who need to know when and where something is available, and they need to know it now. Think about how the ‘experience’ of online shopping within Eclipse compares to sites such as Home Depot, Lowe’s, Grainger, and Amazon. There is really no comparison. And while Eclipse does have some eCommerce tools that have been integrated into the software over time, what’s available has obviously been pieced together, making for a clunky experience. Unfortunately, clunky doesn’t help us compete with the Amazons of the world. 

Zerion’s Rating of Eclipse eCommerce function (as compared to what’s available in the wider marketplace): 2

---

(3) Warehousing: Eclipse both excels and falls short in the warehousing arena. I have personally been completing RF installations for Eclipse distributors for over 18 years, so I have a pretty good grasp on the capabilities and limitations of the software. On a positive note, Eclipse can handle many locations for many items, providing a great deal of flexibility to ‘have’ these locations. Eclipse even allows users to move items from location to location. Eclipse does a fair job with paper warehousing and provides a solid option for wireless functionality for the majority of users. (Side note: If you have the opportunity to go from paper to RF within Eclipse, do it. It's well worth it. A good round number to budget for is approximately $3,500 per warehouse user to cover RF devices, software, and consulting work for the integration.) Flipping to the negative side, however, Eclipse users have no ability to mass-load new locations nor do they have the ability to manage the true size of the physical space at each location. Additionally, Eclipse offers users almost zero reporting capabilities out-of-the-box for those locations, and there are unfortunately no ways for users to optimize locations by rank or velocity. All in all, Eclipse keeps track of locations fairly well, but when it comes to letting users manage their locations over time, the software is just not where it needs to be. The best element of the warehousing function within Eclipse is that the software integrates everything you need to make yourself better and as good as the competition… IF you have made the move to RF.

​Zerion’s Rating of Eclipse warehousing function (as compared to what’s available in the wider marketplace): 7

---

(4) Reporting: I concede that Eclipse has made a valiant effort to provide better reporting over time; however, the reporting function in Eclipse – as a whole – is disjointed and doesn’t account for individual department needs. Let’s dive deeper into the reporting options:

• Reports on the Main Menu – These are generic, not very customizable, dated and not comprehensive. 
• Report Writer / Eclipse Reports – These reports tend to be cumbersome and technical and are generally not for the typical user. I’d go so far as to say they are outdated and pretty insignificant to the current technical community. Eclipse offers very little documentation to help users learn how to process these reports. However, these reports do extend some of the standard reports well, once a user takes the time to figure out how to use these. These reports provide the option to mass-load into the Eclipse database as well. 
• Third-Party Reporting – These Users do have some great options in this regard such as Phocas (which – to Eclipse users – is now Epicor BI). Users also have MITS as an option, and even kore Technologies, which does a good job at replicating the multi-value data into SQL. 

So why has the Eclipse reporting function made this ‘top four’ list? Once again, the reporting functions within Eclipse are not native; they were not a foundational layer built into Eclipse from the beginning. And while there are some strong options, integrating these reporting functions translates to extra work outside and away from Eclipse. Users truly do need a third party beyond what Eclipse can natively do for reporting. (And this doesn’t even address the incredibly poor general ledger and financial reporting within Eclipse… oh my!). 

Zerion’s Rating of Eclipse reporting function (as compared to what’s available in the wider marketplace): Taking the Eclipse reporting function on its own, 4. However, with third-party reporting – such as Phocas – integrated into Eclipse: 8. 

---

To conclude, as I have been saying for quite some time, there are some severe limitations within the Eclipse ERP software because the foundation of the software was built so long ago. While there have been attempts at patches and integrations to make it more user-friendly over time, the underlying structure of Eclipse is still stuck in the 90s, leaving users at a competitive disadvantage. 

I’m not sure there will ever be a competitor to enter the scene that will do all that the Eclipse customer-base needs a software platform to do at a cost that makes any move worthwhile, but if I were to write the ideal software platform in our space, it would better account for the four user interfaces listed above. A guy can dream, right?