Project Planning Package – Arena Solutions Arena PLM (On Premises)

How it Works

Fill out the form below for your project planning estimate. The form does not have a “beginning or end.” The form is constantly calculating, so feel free to make constant changes and the application will auto-adjust.

Details

  • Vendor Name: Arena Solutions (See for Vendor Rating)
  • Software Category: PLM/BOM Management
  • Company Headquarters: 110 Marsh Drive, Suite 200 Foster City, CA 94404
  • Site: http://www.arenasolutions.com
  • Contact number 650.513.3500
  • Delivery Mechanism: SaaS or OnPremises (but primarily sold as SaaS) To see the On Premises Project Planning Package, click here.

Finished With Your Analysis?

Once complete, go to this link to see other analytical products for Arena Solutions.

References

Risk Book

Software RiskRethinking Enterprise Software Risk: Controlling the Main Risk Factors on IT Projects

Better Managing Software Risk

The software implementation is risky business and success is not a certainty. But you can reduce risk with the strategies in this book. Undertaking software selection and implementation without approximating the project’s risk is a poor way to make decisions about either projects or software. But that’s the way many companies do business, even though 50 percent of IT implementations are deemed failures.

Finding What Works and What Doesn’t

In this book, you will review the strategies commonly used by most companies for mitigating software project risk–and learn why these plans don’t work–and then acquire practical and realistic strategies that will help you to maximize success on your software implementation.

Chapters

Chapter 1: Introduction
Chapter 2: Enterprise Software Risk Management
Chapter 3: The Basics of Enterprise Software Risk Management
Chapter 4: Understanding the Enterprise Software Market
Chapter 5: Software Sell-ability versus Implementability
Chapter 6: Selecting the Right IT Consultant
Chapter 7: How to Use the Reports of Analysts Like Gartner
Chapter 8: How to Interpret Vendor-Provided Information to Reduce Project Risk
Chapter 9: Evaluating Implementation Preparedness
Chapter 10: Using TCO for Decision Making
Chapter 11: The Software Decisions’ Risk Component Model

Enterprise Software TCO Calculator – Arena Solutions Arena PLM (On Premises)

How it Works

Fill out the form below for a your customized TCO calculation, as well as each of the supporting cost components that make up the TCO. The form does not have a “beginning or end.” The form is constantly calculating, so feel free to make constant changes and the application will auto-adjust.

Details

  • Vendor Name: Arena Solutions (See for Vendor Rating)
  • Software Category: PLM/BOM Management
  • Company Headquarters: 110 Marsh Drive, Suite 200 Foster City, CA 94404
  • Site: http://www.arenasolutions.com
  • Contact number 650.513.3500
  • Delivery Mechanism: SaaS or OnPremises (but primarily sold as SaaS) To see the SaaS TCO, click here.

Finished With Your Analysis?

Once complete, goto this link to see other analytical products for Arena Solutions.

MUFI Rating & Risk – Arena Solutions Arena PLM

MUFI Rating & Risk – Arena Solutions Arena PLM

MUFI: Maintainability, Usability, Functionality, Implement ability

Vendor: Intuit Quickbooks Enterprise (Select For Vendor Profile)

Introduction

Arena Solutions is highly concentrated in the high tech industry where it provides a solution that can be leveraged to tie together companies, with their suppliers, subcontractors, and their contract manufacturers.

Application Detail

Arena PLM is a SaaS-based system that has a very sophisticated set of functionalities that enable collaboration between people inside of a company as well as between people inside the company and outside, in fact, it is the best collaborative application that we have reviewed. It is also one of our top-rated user interfaces. Arena provides a very fine level of control of the participation.

Arena Files Associated

Arena PLM allows the user to get to wherever they need to go quickly. For instance, there are easy to use tabs and drop downs along the top of the user interface. The main work areas have a large number of links, that can take the user to what they are looking for. There are breadcrumbs along the top, allowing the users to move anywhere in the sequence of the process.

If a company wants to collaborate with an outside entity, it does not have to provide access to the entire bill of materials with that entity. Instead, the entity will typically only see the portions of the bill of materials that are pertinent to them. For instance, there may 20 suppliers that supply 65 parts and subcomponents for what is a finished good to the customer company. However, when each supplier logs into to Arena PLM, they will only be able to see and work with their parts and subcomponents, they will not be able to see other suppliers or other components that make up the finished good.

Because of Arena PLM’s archival capabilities, it allows companies to manage their BOM as a true strategic asset. Many new products that a company introduces are not new at all but are based on older products, with some slight alteration. The easiest way to begin the design of a new product is to copy over an old product BOM, and then make changes to the parts of the product BOM (which may be a very small subset of the overall BOM) that will make the product considered a “new” product. This BOM copy can be performed quickly in Arena PLM, and all of the associated data is copied as well, including the suppliers for each BOM, costing, etc. Maximum reuse of this nature allows a company to introduce new products at minimal effort. Companies can choose to use the application fundamentally or too deeply analyze the application for historical information. Arena Solutions sees their software as having the potential to be used in the following way.

Over time, Arena becomes the repository for institutional knowledge: records of how certain design challenges were solved, how iterations of innovative technology were developed and how the product development process was handled. – Arena Solutions

Arena Revision Cross Out

Notice the revisions above. This shows the user what has been changed, the old number, along with the revised number.

­Version control is one of the most important aspects of BOM management. A good BMMS not only keeps all the BOM information in synch but can also alert people when their BOM has changed.

Indented BOM

Through Arena’s redline functionality, you cannot miss a change and inadvertently order the wrong part. You can easily compare two revisions of a BOM and see how they differ. “3 Tips for Effective Product Revision Control and Communication,” Arena Solutions, 2011

Arena Review Board

Even when an OEM has an internal engineering change order procedure, the CM is often not involved early enough to respond efficiently to the change. For small and medium-sized manufacturers, the conventional method to communicate BOMs and changes is still manual, utilizing phone, fax or e-mail. The fact that these manual ECOs are so arduous often drives people to cut corners in the documentation, communication, or gathering input to evaluate the impact of the change.  “Collaborative Tools for Product Development: A New Approach,” Arena Solutions, 2011

Indented BOM

This is of course incredibly important. It’s much easier to review changes that are made apparent to the user than asking them to catch what has changed by looking through a list. Many engineering and design projects had run into snafus because someone missed a critical revision when they were scanning many line items looking for what had changed. With this capability, users don’t miss changes and get the wrong part as a result. BOM revisions can also be compared.

Engineers are often asked to release designs earlier and earlier even when they are not ready. They must work hard to pass the right and correct information to manufacturing so their design can become a reality. With a complete and accurate engineering bill of materials, the hand-off to manufacturing will be made much smoother.  – Engineering Bill of Materials: The Ins and Outs – Arena Solutions 

In addition to the benefits noted by Arena Solutions, I have observed other benefits, which I have listed below:

  1. A quality BMMS reduces the BOM management required for both ERP systems and external planning systems if a BMMS is not in place.
  2. A quality BMMS manages BOM information in a far superior way to any ERP or planning system. Primarily, all changes are made in order with excellent BOM management data functionality and then copied over to the ERP and planning systems.
  3. A well-controlled EBOM, and by extension a BMMS, helps prevent errors from reverberating down the line.

Arena PLM is an easy decision for any buyer unless they work with recipes and not bills of material. For those buyers, typically in the process industry, a recipe specific solution like Hamilton Grant will be a better fit. Buyers that choose Arena PLM can expect a fast implementation, and software that has a high ROI because it not only improves areas like engineering, but it enhances the data management for any system that uses a bill of materials, which is quite a few systems.

MUFI Scores

All scores out of a possible 10.

Vendor and Application Risk

Buyers of Arena Solutions Arena PLM have every possible advantage working their direction. Arena PLM is one of the highest rated applications we have ever rated. It is a rare situation where a buyer has the opportunity to purchase software that is both the functionality leader in its category, along with being highly implementable and user-friendly.  Finally, buyers can expect leading process consulting from Arena Solutions, so the implementation not only has a very high likelihood of being successful, it has all of the potential to completely change how the BOM is used within the buyer for the positive. Arena PLM tends to be implemented in mid-sized companies, but as the functionality leader in the space, it can be implemented at the largest companies. This means that Arena PLM can open up a tremendous amount of value that is currently poorly served by the BOM functionality within SAP and Oracle tier 1 ERP systems. Furthermore, Arena PLM has an almost perfect combined application and software vendor risk rating. This means that almost all of the risk comes from the buyer’s environment, not from Arena PLM.

Likelihood of Implementation Success

This accounts for both the application and vendor-specific risk. In our formula, the total implementation risk is application + vendor + buyer risk. The buyer specific risk could increase or decrease this overall likelihood and adjust the values that you see below.

Risk Definition

See this link for more on our categorizations of risk. We also offer a Buyer Specific Risk Estimation as a service for those that want a comprehensive analysis.

Risk Management Approach

The only implementation issues that a buyer of Arena PLM can expect to the fact are the traditional issues that face PLM/BOM management implementation projects. Arena Solutions has tended to be implemented by smaller companies – the only reason being they do not have the brand recognition of being associated with a primary software vendor. As such they have become acclimated to having their software implemented in clients with limited resources. We predict Arena Solutions will eventually be more widely recognized for its excellent software and will become a significantly more prominent company and will be implemented by larger buyers, buyers with much more resources. An Arena PLM implementation is one that any project manager should look forward to, as it has a high likelihood of adding significant value to the buyer.

Finished With Your Analysis?

To go back to the Software Selection Package page for the BI Light software category. Or go to this link to see other analytical products for Arena Solutions Arena PLM.

Solution Architecture Package – 100% Oracle Versus 100% Best of Breed Calculator

Background

It is commonly stated that tier 1 ERP systems are very advantageous, particularly for large buyers. One of the reasons that is often presented is that using both tier 2 ERP systems as well as other applications from the same software vendors saves buyers money – and in fact, that while it is well recognized that the major vendors provide inferior functionality to best of breed vendors (although the term “inferior” is rarely used), the trade off of accepting this inferior functionality is well worth it when one considers the substantial cost savings that are assumed to be available from buying most of one’s software from one vendor. This is the standard logic presented by both large software vendors and large consulting companies that are essentially their partners. Most often the single software vendor is either SAP or Oracle, but other software vendors such as Infor, which have grown through acquisitions, will make essentially the same argument to their potential buyers. Software vendors will often grow because they anticipate that the profit margins available for them if they can offer “full suites” is greater than if they provide more narrow and targeted solutions. As is explained in the SCM Focus Press book, Gartner and the Magic Quadrant: A Guide for Buyers, Vendors and Investors, IT analysts also tend to promote large software vendors as more stable and preferred vendors for their readers. In fact, because of how the Magic Quadrant is configured, the simple act of one software vendor acquiring another software vendor, will move the acquired vendor’s products up in the ranking because so much of Gartner’s Magic Quadrant criteria are simply a proxy for the size of the software vendor.

The (Lack of) Evidence for the Single Vendor Hypothesis

While the logic or reasoning presented above has been highly influential and purchasing decisions for decades, in our research we could find no entity that every demonstrated, or even attempted to quantify the total cost of ownership for following a single vendor approach versus a best of breed approach. Considering how commonly the logic of the single software vendor purchasing strategy is invoked, we found this curious. Before reviewing our quantification of this issue, several characteristics of the single vendor argument should be understood.

  1. Financial Bias: Most the entities that propose the single vendor argument have a financial bias. They are either large vendors with many applications and therefore the advice they provide to purchase as much software as possible from a single vendor (that vendor curiously enough always being them) is self-serving. The other major proponents of this purchasing strategy are large consulting companies. However, they have built their IT consulting practices around specific large vendors, and have resources trained in the applications of the large vendors. SAP and Oracle trade away a great deal of their consulting business to the major consulting companies in return for recommendations to purchase their software to the client’s of the major consulting companies.
  2. No Attempt to Provide Evidence: The single vendor argument neither has any evidence to support it nor do any studies exist to support it. Furthermore is not designed to be either proven or disproven, it is instead part of a marketing program to increase sales of the software vendor and the consulting companies, which propose the hypothesis.
  3. The Research Problem: No entity that would be traditionally relied upon to perform research on this topic would be able to perform the research without financial bias influencing their results, as they are in some way compensated by the large software vendors. For instance, even IT publications receive a disproportionate percentage of their advertising from either large software vendors or large consulting companies – both of which would push against any research which showed that the single vendor approach was less effective/more costly (etc) than a more diverse approach. Publishing such research would be an excellent way to have one’s advertising revenues cut. Entities do not publish research, which contradicts their own financial model. The one entity that could research this topic is the academic system, and there is no record of this type of research every being performed by an academic institution or published in any academic journal. This should not be surprising, academics does not investigate every issue that is of interest in industry.

This Analysis and Assumptions

This analysis is really based upon the individual application TCO Calculators that we sell as individual detailed analysis that breaks down the TCO into software, hardware, implementation and maintenance costs. This 100% Oracle Versus 100% Best of Breed Calculator brings the analysis up a level of abstraction and only lists the overall TCO of each application – but lists the TCO for multiple applications, and then compares competing solution architectures. In our individual application TCO Calculators there are inputs, which change the predicted TCO including the sophistication level of the implementation and the degree of customization among other factors. In order to produce an apples to apples comparison as well as to simplify the analysis, all applications are listed as their most simple state.

  1. Uniqueness of Analysis: This is the only analysis of this kind that we are aware exists. We believe we are the only source that compares the costs of the single vendor strategy versus the best of breed strategy in a published form.
  2. The Underlying Research: The TCO analyses are based upon rigorous and detailed analysis into each application. This is a bottom up analysis where first the TCO is estimated for each TCO component, then added per cost category, and then finally aggregated to account for the overall TCO. For those interested in the detail below that shown in this analysis for any specific application, we recommend our application specific TCO calculators. Those offerings have adjustments that can allow them to be matched to the actual implementation environment.
  3. Estimated Integration Costs: We do not break out integration costs separately. A primary reason for this is that when dealing with software vendors, they also do not break out integration costs – but instead they quote the overall implementation effort. Therefore integration costs are included in the overall TCO costs.

The Comparisons

Our first comparison shows all Oracle applications versus all best of breed applications. The first comparison, or Alternate One, which follows, has no ERP system, but instead uses a best of breed application in each category. In our 100% best of breed application grouping, Rootstock would perform the non-financial ERP functions, and Intacct would provide the financial functionality. Arena Solutions provides bill of materials and PLM functionality, which is much greater than any similar functionality inside of an ERP system.

Alternate One - 100% Oracle VS 100% Best of Breed (Small to Medium)

CategoryApplicationTCOUser #
Total$ 40,736,878324
ERPOracle JD Edwards EnterpriseOne$ 23,400,000200
Financial & AccountingOracle JD Edwards EnterpriseOneCosts Accounted for in ERPCovered by ERP
Inventory ManagementOracle JD Edwards EnterpriseOneCosts Accounted for in ERPCovered by ERP
Bill of Materials/PLMOracle JD Edwards EnterpriseOne*Costs Accounted for in ERP Covered by ERP
Demand PlanningSAP DP$ 2,794,90012
Supply PlanningSAP SNP$ 2,454,90012
Production PlanningSAP PP/DS$ 3,059,02510
Business IntelligenceSAP BI/BW$ 5,945,48040
CRMSAP CRM$ 5,954,48050

This analysis is for a smallish environment with a total of roughly 300 users. These are generally good value best of breed applications. As one can see the cost savings on the basis of TCO is quite significant. Now we will show the same applications for a larger environment.

*Bill of materials/PLM functionality exists in SAP ERP, but only the bare minimum necessary to support accounting and MRP. Therefore it is listed above as partially covered by the ERP system — however we do not recommend attempting to manage the bill of materials in any ERP system. 

CategoryApplicationTCOUser #
Total$ 21,791,622311
ERPN/AN/AN/A
Financial & AccountingIntacct$ 3,218,40075
Inventory ManagementRootstock$ 4,350,500100
Bill of Materials/PLMArena Solutions Arena PLM$ 1,167,47212
Demand PlanningDemand Works Smoothie$ 1,167,47212
Supply PlanningToolsGroup$ 2,726,90012
Production PlanningPlanetTogether$ 1,479,60510
Business IntelligenceTeradata$ 5,440,95640
CRMSalesforce Enterprise$ 2,191,20550

This analysis is for a small to medium sized environment with a total of roughly 300 users.

We have selected some of the better value best of breed applications. As one can see the cost savings on the basis of TCO is quite significant.

Now we will show the same applications for a larger environment.

 

Alternate One - 100% Oracle VS 100% Best of Breed (Large)

CategoryApplicationTCOUser #
Total$ 100,682,6201330
ERPOracle JD Edwards EnterpriseOne$ 59,957,378800
Financial & AccountingOracle JD Edwards EnterpriseOneCosts Accounted for in ERPCovered by ERP
Inventory ManagementOracle JD Edwards EnterpriseOneCosts Accounted for in ERPCovered by ERP
Bill of Materials/PLMOracle JD Edwards EnterpriseOne*Costs Accounted for in ERP Covered by ERP
Demand PlanningOracle Demantra$ 3,963,99630
Supply PlanningOracle Supply Planning$ 4,352,79530
Production PlanningOracle Production Planning$ 3,728,30820
Business IntelligenceOracle BI$ 20,394,651300
CRMOracle RightNow$ 8,285,492150

This analysis is for a larger environment with a total of roughly 1300 users.

CategoryApplicationTCOUser #
Total$ 63,197,5211314
ERPN/AN/AN/A
Financial & AccountingIntacct$ 9,667,936300
Inventory ManagementRootstock$ 13,340,810400
Bill of Materials/PLMArena Solutions Arena PLM$ 5,152,85284
Demand PlanningDemand Works Smoothie$ 2,665,12830
Supply PlanningToolsGroup$ 3,804,80730
Production PlanningPlanetTogether$3,531,95120
Business IntelligenceTeradata$ 19,289,704300
CRMSalesforce Enterprise$ 5,744,334150

 

There is some user aggregation on the Oracle side because multiple user licenses fall under the same overall ERP application. Again the cost savings on the basis of TCO is quite significant, although it is less of a cost savings than applying the best of breed strategy in the smaller environment.

Conclusion

According to our research following a single vendor strategy is not only more expensive than following a best of breed strategy, but is significantly more expensive. It also is important to be emphasized that this analysis included all integration costs. However, even if they had been left out, it is impossible that the costs of the best of breed strategy would have come anywhere near the costs of the single vendor strategy.

Other extremely important points – in addition to the cost analysis presented above is that the best of breed strategy results in the following attributes:

  1. 1.     Much Higher Functionality of Best of Breed: All of the large vendors score significantly below the best of breed vendors in application functionality. This is explained in our Software Selection Packages in detail. The more software that is purchased from one vendor, the more uncompetitive the overall grouping of software will be. A major reason for this is that firstly, not software vendor can be best in every software category. If a software vendor develops its applications internally, this is because a software vendor that is good at developing ERP software is never going to be the best at developing other categories of enterprise software. In the case where the software vendor acquires applications, most acquired applications tend to languish with little development, and tend to become less and less relevant as the time from the acquisition passes. This is explained in our Fake Innovators article.
  2. 2.    Significantly Lower Implementation Risk: Targeted best of breed solutions have lower risk than software purchased from a single vendor. It’s not hard to see why. Best of breed applications are a better natural fit for the implementation environment and require far less customization. The traditional way to manage risk is to listen to advice from major consulting companies and to purchase software from major vendors. This does reduce the perception of risk, or the political implications of a failed implementation as the executive can say “We bought from SAP and used Accenture – what else can one do?” However, this strategy increases the probability that any one implementation will fail, increasing the needs of the executive decision maker to have the political cover of having purchased from a major “brand.”

Our analysis leads to the conclusion that the official logic of purchasing from a single software vendor is flawed, and that it is flawed in every dimension – cost being just one dimension that it turns out to not be true.

Our TCO studies show, and it is no great secret, that vendors with the broadest product lines have the highest TCOs. Furthermore, broad product lines do not simply sit on one platform or use one database. The applications have adapters that connect the applications, in the same way that best of breed vendors have adapters. Of course the major software vendors have advantages in integration as they own all the applications when a buyer follows a single vendor purchasing strategy – but these hypothetical benefits are not anywhere near as significant as generally thought, and cannot come close to making up for the higher TCOs of large software vendors. It should not be surprising that when one purchases software from vendors that have the highest TCOs per application, that a buyer’s overall enterprise wide TCO will also be higher.

This is not to say no applications should be purchased from large software vendors – only that the proposal that buyers should purchased their applications from a single vendor in order to reduce costs and to reduce implementation risk – is not supported by research. In fact, our research shows exactly the opposite, that buyers should pick and choose the best software from the best application provider.

We have analyzed this issue from multiple dimensions and it is difficult to see how the single vendor strategy is even a serious proposal. Our best guess is that it simply began as marketing hyperbole proposed by large vendors, and developed a life of its own after this point – and is simply repeated without anyone noticing that it only would make sense if integration costs were truly enormous – and apparently without anyone noticing that the logic is simply repeated without ever evidence provided to support the claim.

Solution Architecture Package – 100% SAP Versus 100% Best of Breed Calculator

Introduction

It is commonly stated that tier 1 ERP systems are very advantageous, particularly for large buyers. One of the reasons that is often presented is that using both tier 2 ERP systems as well as other applications from the same software vendors saves buyers money – and in fact, that while it is well recognized that the major vendors provide inferior functionality to best of breed vendors (although the term “inferior” is rarely used), the trade off of accepting this inferior functionality is well worth it when one considers the substantial cost savings that are assumed to be available from buying most of one’s software from one vendor. This is the standard logic presented by both large software vendors and large consulting companies that are essentially their partners. Most often the single software vendor is either SAP or Oracle, but other software vendors such as Infor, which have grown through acquisitions, will make essentially the same argument to their potential buyers.

Software vendors will often grow because they anticipate that the profit margins available for them, if they can offer “full suites”, is higher significant than if they provide more narrow and targeted solutions. As is explained in our book Gartner and the Magic Quadrant: A Guide for Buyers, Vendors, and Investors, IT analysts also tend to promote large software vendors as more stable and preferred vendors for their readers. In fact, because of how the Magic Quadrant is configured, the simple act of one software vendor acquiring another software vendor will move the acquired vendor’s products up in the ranking because so much of Gartner’s Magic Quadrant criteria are merely a proxy for the size of the software vendor.

The (Lack of) Evidence for the Single Vendor Hypothesis

While the logic or reasoning presented above has been highly influential and purchasing decisions for decades, in our research we could find no entity that every demonstrated, or even attempted to quantify the total cost of ownership for following a single vendor approach versus a best of breed approach. Considering how commonly the logic of the single software vendor purchasing strategy is invoked, we found this curious. Before reviewing our quantification of this issue, several characteristics of the single vendor argument should be understood.

  1. Financial Bias: Most of the entities that propose the single vendor argument have a financial bias. They are either large vendors with many applications, and therefore the advice they provide to purchase as much software from a single vendor (that vendor curiously enough always being “them”) is self-serving. The other major proponents of this purchasing strategy are large consulting companies. However, they have built their IT consulting practices around specific large vendors, and have resources trained in the applications of the large vendors. SAP and Oracle trade away a great deal of their consulting business to the major consulting companies in return for recommendations to purchase their software to the client of the major consulting companies.
  2. No Attempt to Provide Evidence: The single vendor argument neither has any evidence to support it nor do any studies exist to support it. Furthermore is not designed to be proven or disproven, it is instead part of a marketing program to increase sales of the software vendor and the consulting companies that propose the hypothesis.
  3. The Research Problem: No entity that would be traditionally relied upon to perform research on this topic would be able to complete the study without financial bias influencing their results, as they are in some way compensated by the large software vendors. For instance, even IT publications receive a disproportionate percentage of their advertising from either large software vendors or large consulting companies – both of which would push against any research which showed that the single vendor approach was less effective/more costly (etc.) than a more diverse approach. Publishing such research would be an excellent way to have one’s advertising revenues cut. Entities do not publish research, which contradicts their financial model. The one entity that could research this topic is the academic system, and there is no record of this type of research every being performed by an academic institution or published in an academic journal. This should not be surprising; academics do not investigate every issue that is of interest in the industry.

This Analysis and Assumptions

This analysis is based upon the individual application TCO Calculators that we sell as individual detailed analysis that breaks down the TCO into software, hardware, implementation and maintenance costs. This 100% SAP Versus 100% Best of Breed Calculator brings the analysis up a level of abstraction and only lists the overall TCO of each application – but lists the TCO for multiple applications, and then compares competing solution architectures. In our application TCO Calculators, there are inputs, which change the predicted TCO including the sophistication level of the implementation and the degree of customization among other factors. To produce an apples to apples comparison as well as to simplify the analysis, all applications are listed as their purest state.

  1. The Uniqueness of Analysis: This is the only analysis of this kind that we are aware exists. We believe we are the only source that compares the costs of the single vendor strategy versus the best of breed strategy in a published form.
  2. The Underlying Research: The TCO analyses are based upon rigorous and detailed analysis of each application. This is a bottom-up analysis where first the TCO is estimated for each TCO component, then added per cost category, and then finally aggregated to account for the overall TCO. For those interested in the detail below that shown in this analysis for any specific application, we recommend our application specific TCO calculators. Those offerings have adjustments that can allow them to be matched to the actual implementation environment.
  3. Estimated Integration Costs: We do not break out integration costs separately. A primary reason for this is that when dealing with software vendors, they also do not break out integration costs. But instead, they quote the overall implementation effort. Therefore integration costs are included in the overall TCO costs.

The Comparisons

Our first comparison shows all SAP applications versus all best of breed applications. The first comparison, or Alternate One, which follows, has no ERP system but instead uses a best of breed application in each category. In our 100% best of breed application grouping, Rootstock would perform the non-financial ERP functions, and Intacct would provide the financial functionality. Arena Solutions provides bill of materials and PLM functionality, which is much greater than any similar functionality inside of an ERP system.

Alternate One - 100% SAP VS 100% Best of Breed (Small to Medium)

CategoryApplicationTCOUser #
Total$ 48,292,838324
ERPSAP ERP/ECC/R/3$ 27,895,000200
Financial & AccountingSAP ERP/ECC/R/3Costs Accounted for in ERPCovered by ERP
Inventory ManagementSAP ERP/ECC/R/3Costs Accounted for in ERPCovered by ERP
Bill of Materials/PLMSAP ERP/ECC/R/3*Costs Accounted for in ERP Covered by ERP
Demand PlanningSAP DP$ 4,367,87612
Supply PlanningSAP SNP$ 3,272,58012
Production PlanningSAP PP/DS$ 4,078,70010
Business IntelligenceSAP BI/BW$ 6,430,23040
CRMSAP CRM$ 2,405,95250

*Bill of materials/PLM functionality exists in SAP ERP, but only the bare minimum necessary to support accounting and MRP. Therefore it is listed above as partially covered by the ERP system. However, we do not recommend attempting to manage the bill of materials in any ERP system. 

CategoryApplicationTCOUser #
Total$ 21,791,622311
ERPN/AN/AN/A
Financial & AccountingIntacct$ 3,218,40075
Inventory ManagementRootstock$ 4,350,500100
Bill of Materials/PLMArena Solutions Arena PLM$ 1,167,47212
Demand PlanningDemand Works Smoothie$ 1,167,47212
Supply PlanningToolsGroup$ 2,726,90012
Production PlanningPlanetTogether$ 1,479,60510
Business IntelligenceTeradata$ 5,440,95640
CRMSalesforce Enterprise$ 2,191,20550

This analysis is for a small to medium sized environment with a total of roughly 300 users.

We have selected some of the better value best of breed applications. As one can see the cost savings by TCO is quite significant.

Now we will show the same applications for a larger environment.

Alternate One - 100% SAP VS 100% Best of Breed (Large)

CategoryApplicationTCOUser #
Total$ 113,332,4251330
ERPSAP ERP/ECC/R/3$ 67,625,688800
Financial & AccountingSAP ERP/ECC/R/3Costs Accounted for in ERPCovered by ERP
Inventory ManagementSAP ERP/ECC/R/3Costs Accounted for in ERPCovered by ERP
Bill of Materials/PLMSAP ERP/ECC/R/3*Costs Accounted for in ERP Covered by ERP
Demand PlanningSAP DP$7,294,80130
Supply PlanningSAP SNP$ 5,803,72630
Production PlanningSAP PP/DS$ 4,971,07720
Business IntelligenceSAP BI/BW$ 21,892,800300
CRMSAP CRM$ 5,744,334150

This analysis is for a larger environment with a total of roughly 1300 users.

CategoryApplicationTCOUser #
Total$ 63,197,5211314
ERPN/AN/AN/A
Financial & AccountingIntacct$ 9,667,936300
Inventory ManagementRootstock$ 13,340,810400
Bill of Materials/PLMArena Solutions Arena PLM$ 5,152,85284
Demand PlanningDemand Works Smoothie$ 2,665,12830
Supply PlanningToolsGroup$ 3,804,80730
Production PlanningPlanetTogether$3,531,95120
Business IntelligenceTeradata$ 19,289,704300
CRMSalesforce Enterprise$ 5,744,334150

There is some user aggregation on the SAP side because multiple user licenses fall under the same overall ERP application. Again the cost savings by TCO is quite significant. It is less of cost savings than applying the best of breed strategy in the smaller environment. 

Conclusion

According to our research following a single vendor, strategy is not only more expensive than following a best of breed strategy but is significantly more expensive. It also is important to be emphasized that this analysis included all integration costs. However, even if they had been left out, it is impossible that the costs of the best of breed strategy would have come anywhere near the costs of the single vendor strategy.

Other critical points – in addition to the cost analysis presented above is that the best of breed strategy results in the following attributes:

  1. Much Higher Functionality: All of the large vendors score significantly below the best of breed vendors. The more software is purchased from one vendor; the more uncompetitive the overall grouping of software will be.
  2. Much Lower Implementation Risk: Targeted best of breed solutions have lower risk than software purchased from a single vendor. It’s not hard to see why. Best of breed applications are a better natural fit for the implementation environment and require far less customization. The traditional way to manage risk is to listen to advice from major consulting companies and to purchase software from major vendors. This does reduce the perception of risk, or the political implications of a failed implementation as the executive can say “We bought from SAP and used Accenture – what else can one do?” However, this strategy increases the probability that any one implementation will fail.

Our analysis leads to the conclusion that the official logic of purchasing from a single software vendor is flawed, and that it is flawed in every dimension – cost being just one dimension that it turns out to not be true.

Our TCO studies show, and it is no great secret, that vendors with the broadest product lines have the highest TCOs. Furthermore, broad product lines do not just sit on one platform or use one database. The applications have adapters that connect the applications, in the same way, that best of breed vendors have adapters. Of course, the major software vendors have advantages in integration as they own all the applications when a buyer follows a single vendor purchasing strategy – but these hypothetical benefits are not anywhere near as significant as generally thought, and cannot come close to making up for the higher TCOs of large software vendors. It should not be surprising that when one purchases software from vendors that have the highest TCOs per application, that a buyer’s overall enterprise-wide TCO will also be higher.

This is not to say no applications should be purchased from large software vendors – only that the proposal that buyers should purchase their applications from a single vendor to reduce costs and to reduce implementation risk is not supported by research. Our research shows exactly the opposite that buyers should pick and choose the best software from the best application provider.

We have analyzed this issue from multiple dimensions, and it is difficult to see how the single vendor strategy is even a serious proposal. Our best guess is that it simply began as marketing hyperbole proposed by large vendors, and developed a life of its own after this point. It is repeated merely without anyone noticing that it only would make sense if integration costs were truly enormous. This is apparently without anyone seeing that the logic is repeated merely without ever evidence provided to support the claim.

Enterprise Software TCO Calculator – Arena Solutions Arena PLM (SaaS)

How it Works

Fill out the form below for a your customized TCO calculation, as well as each of the supporting cost components that make up the TCO. The form does not have a “beginning or end.” The form is constantly calculating, so feel free to make constant changes and the application will auto-adjust.

Details

  • Vendor Name: Arena Solutions (See for Vendor Rating)
  • Software Category: PLM/BOM Management
  • Company Headquarters: 110 Marsh Drive, Suite 200 Foster City, CA 94404
  • Site: http://www.arenasolutions.com
  • Contact number 650.513.3500
  • Delivery Mechanism: SaaS or OnPremises (but primarily sold as SaaS) To see the OnPremises TCO, click here.

Finished With Your Analysis?

Once complete, goto this link to see other analytical products for Arena Solutions.

Project Planning Package – Arena Solutions Arena PLM (SaaS)

How it Works

Fill out the form below for your project planning estimate. The form does not have a “beginning or end.” The form is constantly calculating, so feel free to make constant changes and the application will auto-adjust. Details

  • Vendor Name: Arena Solutions (See for Vendor Rating)
  • Software Category: PLM/BOM Management
  • Company Headquarters: 110 Marsh Drive, Suite 200 Foster City, CA 94404
  • Site: http://www.arenasolutions.com
  • Contact number 650.513.3500
  • Delivery Mechanism: SaaS or OnPremises (but primarily sold as SaaS) To see the On Premises Project Planning Package, click here.

Finished With Your Analysis?

Once complete, go to this link to see other analytical products for Arena Solutions.

References

Risk Book

Software RiskRethinking Enterprise Software Risk: Controlling the Main Risk Factors on IT Projects

Better Managing Software Risk

The software implementation is risky business and success is not a certainty. But you can reduce risk with the strategies in this book. Undertaking software selection and implementation without approximating the project’s risk is a poor way to make decisions about either projects or software. But that’s the way many companies do business, even though 50 percent of IT implementations are deemed failures.

Finding What Works and What Doesn’t

In this book, you will review the strategies commonly used by most companies for mitigating software project risk–and learn why these plans don’t work–and then acquire practical and realistic strategies that will help you to maximize success on your software implementation.

Chapters

Chapter 1: Introduction
Chapter 2: Enterprise Software Risk Management
Chapter 3: The Basics of Enterprise Software Risk Management
Chapter 4: Understanding the Enterprise Software Market
Chapter 5: Software Sell-ability versus Implementability
Chapter 6: Selecting the Right IT Consultant
Chapter 7: How to Use the Reports of Analysts Like Gartner
Chapter 8: How to Interpret Vendor-Provided Information to Reduce Project Risk
Chapter 9: Evaluating Implementation Preparedness
Chapter 10: Using TCO for Decision Making
Chapter 11: The Software Decisions’ Risk Component Model

Software Category Analysis – PLM

Introduction

What is commonly referred to, as PLM is one of the most confusing areas of enterprise software. Given the limited published information available on the bill of materials (BOM), one initially wonders where decision makers are getting their information about how to intelligently manage the this very important master data object.

Some History on Terminology

Several years ago the concept of PLM became very popular. SAP introduced a PLM “product,” that was not actually a product but simply a listing of pre-existing functionality that controlled life-cycle aspects of the product. The solution never existed and never made any sense, and gradually fell into the dustbin of failed SAP products that both no one seems to remember and no one discusses. I wrote on this topic back in 2009 and this article.

When PLM began to become a popular term, vendors like Arena Solutions and Siemens that had software that managed the bill of material (that of course has many life-cycle attributes) adopted the term PLM for their product. This was a problem because software that manages the BOM, but controls for life-cycle and ERP systems that also have life-cycle functionality are not in the same application category, yet they both used the same terminology. This confusion persisted for years, with vendors like Arena trying to explain the terminology they had selected. Eventually, Arena simply moved away from the term to BOM management. Unfortunately there are still many BMS vendors, like Siemens that still use the term PLM.

The nomenclature of PLM was actually an unfortunate but deliberate linguistic obfuscation made by the management at some software vendor and then copied by other software vendors. It eventually became standard terminology in the field. This decision never made any sense logically, but at any time there are illogical and terminologically incorrect marketing initiatives at many enterprise software vendors. In the enterprise software space, product sales success trumps all normal accuracy standards. This is why it is quite dangerous for company executives to read vendor literature without having it screened by content experts in the literature’s field that are paid by the implementing company, but also do not receive a financial benefit (i.e. a consulting company) from uncritically analyzing information provided by the software vendor. With the right PLM/BOM Management software, many of the old techniques that have been applied to BOMs for decades, such as modularizing the BOM, flattening the BOM or creating phantom BOMs are no longer necessary.

Standardizing the Term

The decision to standardize around the term has actually resulted in slowed development in this software category. Because the term PLM is so poorly defined, vendors who don’t really have a solution have been able to pose as if they do, resulting in a great deal of confusion for buyers. What has become evident is that many marketing professionals at software vendors have been unconcerned with even elementary accuracy, which is accuracy in terminology.

However across the software segment, it is a mixed bag with regards to terminology, as Siemens and Agile still use the term PLM to describe their applications. Unfortunately, using the term PLM to describe a single application little sense because lifecycle planning is comprised of a large swath of functionality, which is distributed throughout a wide variety of enterprise applications. For instance lifecycle functionality exists in product design systems, demand planning, supply planning and also production planning, as well as ERP and the BMMS. Demand planning applications typically have a segment of their functionality dedicated to lifecycle management, however the BOM for the most part is never part of demand planning applications.

The Lifecycle of a BOM (or Recipe)

The BOM begins its life in the design and engineering systems as the engineering BOM or EBOM. The rest of the company is usually oblivious to—and has little reason to be concerned with—the many BOMs and changes to BOMs made by design and engineering. For the rest of the organization the BOM only becomes relevant when it is approved to be an actual manufactured or ordered (in the case of contract manufacturing) product. Of course a great deal of work occurs before this happens:

  1. The product must be conceived.
  2. It must go through many design revisions and design changes.
  3. Suppliers must either bid on many of the input parts (in the case of products that are manufactured internally) or on both the input parts and the overall manufacturing (in the case of contract manufacturing).

The BOM will experience the most active changes during the engineering and design stage. During this stage, design and graphics files are included into the process and added to the BOM. Not all the information that is created in this stage is included in the manufacturing BOM (MBOM). While the BMMS represents multimedia files, the files are initially produced in a separate system, often a Computer Aided Design (CAD) system. Examples of CAD systems include AutoCAD and SolidWorks. These systems may store their data in another system called a product data management (PDM) system. The PDM can be thought of as the central organizing store for the CAD systems. Some companies have the BMMS connected to the PDM.

Multi-dimensional Relationships

One easy way of understanding the highly linked nature of a BOM and its subcomponents is to consider that one subcomponent is often part of more than one parent component. Therefore, by using a relational BOM configuration, which is different from a relational database; you can use a relational database, but still follow a restricted hierarchical model in your BOM configuration. When the subcomponent is changed in one location, it immediately affects all parent components; immediacy in that change and how it affects other BOMs is the desired end state. The goal is for all parent products (i.e., BOMs) to be updated instantly when a subcomponent is changed, regardless of the product’s life-stage. The updated part data is then sent over to the planning system, where a flag is changed to tell the planning system that the part should no longer be planned. Updating this data is as important as the algorithms you use to produce a forecast. Some of the principles discussed up to this point are demonstrated in the following screen shots in the PLM/BOM management software vendor Arena Solutions.

Arena Search Flexibility

 

In Arena, BOM, parts, suppliers, etc. can be easily searched and are easily interrelated.

Search Flexibility by Type

We can select the item...

Search for Items

…or we can search by supplier.

Search for Suppliers

The search by supplier very quickly leads to the parts supplied by the supplier. In Arena, it is never difficult to get to related objects.

While a BOM is a complete representation of a final product, it is made up of a hierarchy of parts that are all inter-related (or should I say, that is one way of interpreting or showing the BOM).

The ERP BOM Model

BOMs as implemented in ERP systems are increasingly dated and based upon a time when design, engineering, manufacturing and supply chain were all performed by one company at one location. ERP systems are by design, focused internally. Generally speaking, people do not login to the ERP system of another company, and the ERP system interacts with systems external to the company primarily through transactions such as purchase orders. In today’s environment, functions previously performed in-house are increasingly spread out across multiple companies, and ERP systems do not work very well in this environment. Furthermore, ERP BOMs have stayed static, even as the BOM functionality in the engineering and design side of the business has drastically improved. At this point, a BOM that is adjusted and reviewed by internal employees only is really an anachronism in an environment where engineering, design and manufacturing is spread out among many companies. BOMs today need to be highly collaborative and therefore a highly collaborative environment to enable the work that needs to be done. Never before has maintaining BOMs in ERP systems or spreadsheets been so out of touch with what is happening in business.

Spreadsheet Search Capabilities

When a company says they manage their BOMs or recipes in an ERP system, what this actually means is that they use a combination of ERP and spreadsheets. Searching can work pretty well on a small spreadsheet with low complexity. However, as the spreadsheet becomes larger (and BOM spreadsheets must be large unless the company makes only a few products), the ability to effectively search through them is limited. , Further limitations in performing effective searches exist if some identical parts have different numbers.

Companies will often use advanced functions in Excel, with the purpose of making the program more capable of managing the BOM. One example is the ability to search for components that are used across products for the purpose of negotiation with suppliers. Finding all of the components is a challenge, particularly when an identical component has been assigned different part numbers, meaning that applying a simple filter to the spreadsheet may not work. Advanced functions inside of Excel may be required to enable the planning engineer to perform these types of searches. However as pointed out by Arena Solutions, this solution is filled with problems.

Companies often try to solve that problem by adding complexity into their Excel spreadsheet BOMs. They use tactics like item master tabs, lookup formulas, cross-referenced spreadsheets and Visual Basic programming — especially if they have an Excel guru on staff. This works as long as your Excel master keeps the connections up to date so they correctly fill in the cells. But this person is now also a single point of failure in an intricate web of files. The BOM management process is in his or her head and buried in the details of an unknown number of hidden tabs on countless spreadsheets. – “Using Excel for Bill of Materials (BOM) Management”, Arena Solutions

With a PLM/BOM management system, the search for product components is a simple query that can be performed across the entire BOM database in order to aggregate all of the components in the different products that will be required within certain time frames. The next step is to combine the forecast for each component by the number of components per BOM for all the BOMs in the BOM database, as represented by the formula below:

The Number of Final Products

X

The Number of Components Per Final Product

X

The Time Phased Forecast for the Final Product

=

 The Total Component Demand Communicated to the Supplier 

By providing the ability to perform this calculation quickly and with little effort, the PLM/BOM management system helps the user to avoid missing any of the components, translating to an improved components forecast. The more comprehensive the unit estimate, the higher the number of units, the greater the negotiating leverage and the lower the price of each component. Therefore, the ability to easily obtain this information with queries on the PLM/BOM management system results in lower costs to the company. In fact, a good PLM/BOM management system will be able to show relationships in BOMs very naturally, as the “Where Used” view below demonstrates.

Arena Where Used

The Arena “Where Used” view allows a user to quickly trace where a part is used across any BOM in the system. This showcases the strong associative linking within Arena Solutions. Finding associations like this in Arena Solutions is very natural, and does not require going to any special area within the application. The application allows a natural flow between the data elements.

While BOMs are often spoken of as being managed in spreadsheets, this is an oversimplification of what happens in reality. While the BOM’s connection logic, and naming and numbering information, is contained or modeled in a spreadsheet, many other pieces of related information necessary to understanding the BOM in its totality are kept in different files and different file formats. The user then simply uses the spreadsheet as an index to find the names of these associated files. All of this is a great deal of overhead and maintenance. While the tools to manage a BOM this way are either free or very inexpensive, the costs in time and inefficiency are quite significant.

The Need for an Application to Manage your Recipe/Formula/BOM

In the SCM Focus Press book Bill of Materials in Excel, Planning, ERP and BMMS/PLM Software provides ample evidence, which is laid out in a complete form that every company requires an application for managing their BOM/recipe/formulas. The use of these types of systems allows the company using the application to more efficiently perform the following activities.

  1. Improve design efficiency
  2. Allows for more simulation and trial and error – promoting creativity in the design process – all without the necessity of creating permanent records in process of developing new designs.
  3. Improves internal understanding and coordination on recipes – some applications like Hamilton Grant allow for manufacturer’s instructions and trial notes to be stored.
  4. Groups working in different geographies can more efficiently work as teams and coordinate their efforts. Workers that are not in the office, but which may need to provide review input can access the system remotely to provide critical and timely input.
  5. Improves the speed of recipe/formula development
  6. Allows companies to better manage their product costs
  7. Allows companies to more efficiently integrate with suppliers by sharing and providing access to either the entire recipe/formula or just to portions of the recipe/formula. In fact, these types of systems double as supplier management systems as well as product data management systems. Once product data is in a highly organized and sharable form, it has numerous uses.
  8. Related to the previous point, allows the company to work with more suppliers as the costs of interacting with any one supplier is lower.
  9. Keeps all of the ingredient, packaging, recipe, process and quality information in one place.
  10. Improves recipe/formula re-usability
  11. Improves compliance with legislative standards (which vary greatly by industry – but are quite important in food and beverage and pharmaceuticals)
  12. Simulate the effect on important indicators during potential redesigns.

We estimate that BOM/recipe/formula management applications to have the highest return on investment of any enterprise software category that we cover. A main reason for this is so many parts of the business rely upon product information and therefore can benefit from a single application. Design and engineering, supply chain, finance, supplier relations – all of these sides of the business benefit. Furthermore each side of the business, as well as external parties, are better integrated through the use of this type of application. Here is an example from one vendor of how their recipe management software works:

Recipe management can even create least-cost recipes from scratch. You can reuse your knowledge by using templates. These templates define the ingredients that can be used and the constraints on nutritional content and ingredient quantities (even for rework). –  Adifo Software

Secondly, the better applications in the PLM software category can be brought up more quickly than most of the other software categories.

Traditionally, a BOM is simply considered to be a master data object, more limited than what has been described up to this point. Whether you agree with the limited definition of a more expanded view may change based upon which software is being discussed. For example, in applications with a limited representation of the BOM, the traditional definition is correct. However, the broader definition is more applicable to advanced applications that specialize in BOM management. As such, PLM/BOM management system software has essentially enlarged what is represented by a BOM. In fact a major strength of a PLM/BOM management system is that it integrated the master data object with the other data associated with the BOM, making the PLM/BOM management system a very powerful application for understanding, storage and collaboration on the BOM.

Without understanding the definitions of lifecycle, PLM and BOM management, good decisions regarding the acquisition and deployment of the software in these categories are very difficult to make. Confusion between the different terms and functionalities prevents companies from getting the appropriate solutions to improve how they manage the BOM. When comparing “PLM” and BOM management solutions, it’s important to ask software vendors these questions:

  1. Is the solution primarily focused on managing the material and BOM objects or something else?
  2. Is the solution presented as a separate application, or as functionality that is distributed throughout the larger ERP suite?
  3. PLM and BOM management are not the same thing. Ask for an explanation as to what central problem the software is trying to solve, and then how the software solves it. For instance, the solution offered by SAP does not address BOM management and incorporates areas of functionality and a CAD application related to engineering and design, which is not part of BOM management. Some of the solutions offered in this space just don’t make any sense. They are the result of a software vendor cobbling together a product with whatever is handy, and pushing it out even though it doesn’t actually meet the real requirements of BOM management. The fact that a PLM vendor happens to be the same software vendor that makes the company’s current ERP system is not a good enough reason to select their application, particularly if they have a low probability of meeting the business requirements. Attention to business requirements detail is important for all software selections, but is of particular importance in the BMMS/PLM market.

Accessing Collaborative Software for the BOM and Recipe

BOM management requirements are inherently collaborative and outside parties in particular must be able to quickly and easily use the application. The standard has already been set in this area, and acceptance of a lower level of collaboration functionality must be well-justified.

The Differences Between BOMs and Recipes and Formulas

If one thinks of the standard discrete manufacturing BOM it begins with many parts and culminates in a single finished good item. This is shown in the graphic below:


A BOM

A typical discrete manufacturing ERP system, such as ERPNext, will have one field for the finished good, as can be seen in the screen shot below.

Lamp BOM

Here one can see that the BOM functionality in ERPNext is designed for discrete and repetitive manufacturing as one can only input a single finished good.

Fractional Input Material

Although interestingly enough, ERPNext has the second functionality required to manage recipes, which is the ability to use a fraction as an input product on the BOM. 

If the number of output/finished goods is limited to one, then this application will unsuitable for most process manufacturing environments. The following quotation explains why this is the case.

In food, pharmaceutical and chemical plants, many processes result in multiple outputs which looks more like an “X” structure. Take for example, a chicken disassembly process where the one chicken can produce 20-30 separate end products that can be sold or used for further processing. Another example is an oil refinery in which the raw material (crude oil) is refined into several types of product such as natural gas, rich oil, light cycle oil and decanted oil resembling a “V” structure.  – Process Industry ERP Requirements

V BOM

Recipes and Formulas

While the term “formula” is sometimes used interchangeably with the term “recipe,” a formula and a recipe is not the same thing. A formula is in fact a subcomponent of a recipe. Formulas can be completely separate objects and a formula can be a production schedule all by itself—that is it can stand separate from a recipe. In most cases a formula does not stand separately, and is combined as part of a subordinate object to a larger recipe, which contains multiple formulas. It is common to have multiple formulas within a recipe because each formula relates to the manufacturing configuration of a semi-finished good. It is also quite common for semi-finished goods to have complex formulas of their own that must be processed as part of the in-process manufacturing steps. Let us now get into how recipes are used in SAP ERP (as an example of how recipes are used in ERP systems generally). But before we do that we need to explain the concept of a production version.

Process industry companies face the same challenges with respect to managing the product information as discrete and repetitive manufacturing companies when it comes to recipe and formula variants. Many companies undermine their capabilities by attempting to manage these objects in ERP systems – to which the SCM Focus Press book Bill of Materials in Excel, Planning, ERP and BMMS/PLM Software, is focused on explaining why is an ineffective approach. The fact that process industry finished goods can be disassembled while discrete and repetitive finished goods cannot has no interaction here, because finished products are not in fact disassembled—this is merely a way to differentiate between manufacturing categories. For instance, there can be a wide variety of formulas for the same recipe. All companies face the need for costing BOMs/recipes, which are driven by finance.

The case must be made that it makes the most sense to treat recipes and formulas as if they are BOMs. Most material on this topic takes a different view, but in this chapter I hope to prove to you that there is no difference between the recipe, formula and the BOM aside from nomenclature, and that by thinking of them as different, one will tend to place unnecessary limitations on how you manage them.

Software Category Summary

We rate the software category of PLM/BOM/Recipe Management to be the highest ROI of all enterprise software categories. Client ability to implement PLM is low compared to other solution areas analyzed in this site. The first reason is the great confusion regarding what PLM actually is and bad experiences with vendors like SAP that were selling vapor as a solution. However, the low cost of the leading PLM solution vs. the financial and organizational benefits of this software make the paucity of PLM implementations one of the great value opportunities in enterprise software.

The software in this category can be implemented quickly, is relatively inexpensive, changes the entire process of how these master data objects are managed for the better and improves the efficiency of all of the applications that work with the BOM or recipe, which is quite a few applications. Selection of the right software allows for extensive collaboration on the BOM and recipe both internally and with external partners. There are several excellent applications to choose from and many buyers that are not even thinking of PLM/BOM/Recipe Management should put this software category at the top of their list.

MUFI Rating & Risk

See the MUFI Ratings & Risk below for all of the applications we cover.

Vendor NameApplication
Big ERP
SAPMUFI Rating & Risk – SAP ECC
OracleMUFI Rating & Risk – JD Edwards EnterpriseOne
EpicorMUFI Rating & Risk – Epicor ERP
SageMUFI Rating & Risk – Sage X3
InforMUFI Rating & Risk – Infor Lawson
Small and Medium ERP
SAPMUFI Rating & Risk – SAP Business One
OracleMUFI Rating & Risk – JD Edwards World
ProcessProMUFI Rating & Risk – ProcessPro
RootstockMUFI Rating & Risk – Rootstock
ERPNextMUFI Rating & Risk – ERPNext
OpenERPMUFI Rating & Risk – OpenERP
MicrosoftMUFI Rating & Risk – Microsoft Dynamics AX
Financial Applications
IntacctMUFI Rating & Risk – Intacct
IntuitMUFI Rating & Risk – Intuit Quickbooks Enterprise Solutions
FinancialForceMUFI Rating & Risk – FinancialForce
NetSuiteMUFI Rating & Risk – NetSuite OneWorld
PLM
SAPMUFI Rating & Risk – SAP PLM
Arena SolutionsMUFI Rating & Risk – Arena Solutions Arena PLM
Hamilton GrantMUFI Rating & Risk – Hamilton Grant Recipe Management
Demand Planning
SAPMUFI Rating & Risk – SAP APO DP
TableauMUFI Rating & Risk – Tableau (Forecasting)
Business Forecast SystemsMUFI Rating & Risk – Forecast Pro TRAK
Demand WorksMUFI Rating & Risk – Demand Works Smoothie
JDAMUFI Rating & Risk – JDA Demand Management
ToolsGroupMUFI Rating & Risk – ToolsGroup SO99 (Forecasting)
Supply Planning
SAPMUFI Rating & Risk – SAP SNP
SAPMUFI Rating & Risk – SAP SmartOps
ToolsGroupMUFI Rating & Risk – ToolsGroup SO99 (Supply Planning)
Demand WorksMUFI Rating & Risk – Demand Works Smoothie SP
PlanetTogetherMUFI Rating & Risk – PlanetTogether Galaxy APS Superplant
Production Planning
SAPMUFI Rating & Risk – SAP APO PP/DS
DelfoiMUFI Rating & Risk – Delfoi Planner
PreactorMUFI Rating & Risk – Preactor
AspenTechMUFI Rating & Risk – AspenTech AspenOne
PlanetTogetherMUFI Rating & Risk – PlanetTogether Galaxy APS
BI Heavy
SAPMUFI Rating & Risk – SAP BI/BW
SAPMUFI Rating & Risk – SAP Business Objects
OracleMUFI Rating & Risk – Oracle BI
SASMUFI Rating & Risk – SAS BI
MicroStrategyMUFI Rating & Risk – MicroStrategy
IBMMUFI Rating & Risk – IBM Cognos
TeradataMUFI Rating & Risk – Teradata
ActuateMUFI Rating & Risk – Actuate ActuateOne
BI Light
SAPMUFI Rating & Risk – SAP Crystal Reports
QlikTechMUFI Rating & Risk – QlikTech QlikView
TableauMUFI Rating & Risk – Tableau (BI)
CRM
SAPMUFI Rating & Risk – SAP CRM
OracleMUFI Rating & Risk – Oracle RightNow
OracleMUFI Rating & Risk – Oracle CRM On Demand
InforMUFI Rating & Risk – Infor Epiphany
Base CRMMUFI Rating & Risk – Base CRM
SalesforceMUFI Rating & Risk – Salesforce Enterprise
SugarCRMMUFI Rating & Risk – SugarCRM
MicrosoftMUFI Rating & Risk – Microsoft Dynamics CRM
NetSuiteMUFI Rating & Risk – NetSuite CRM