How to Understand the Brightwork Software Category Analyses

Executive Summary

  • Brightwork Research & Analysis covers multiple categories of enterprises software.
  • Before reading each vendor or application area, start by reviewing our analysis of the software category.

Introduction

Each category analysis provides an overview of the basic features of the software category. This includes:

  • The problem that the software is designed to address.
  • How applications in a particular category tend to be designed.
  • An explanation of the history of the software category.
  • How the category is related to other enterprise software categories.
  • Major trends in each category.
Software CategoryLink
Big ERPBig ERP Category Analysis
Small and Medium ERPSmall and Medium ERP Category Analysis
Category AnalysisFinancial Application Category Analysis
PLMPLM Category Analysis
Demand PlanningDemand Planning Category Analysis
Supply PlanningSupply Planning Category Analysis
Product Planning and SchedulingProduction Planning Category Analysis
BI HeavyBI Heavy Category Analysis
BI LightBI Light Category Analysis
CRMCRM Category Analysis

Software Selection

  • Want Help with Software Selection for your Business?

    It is difficult for most companies to perform software selection without outside advice. It is impossible to obtain honest software selection support from consulting companies. We offer expert and unbiased remote software selection support.

    This article is free, we do not answer questions for free. Filling out this form is for those that have a budget. If that describes you, just fill out the form below and we'll be in touch asap.

Software Category Analysis – Demand Planning

Introduction

When forecasting applications were first developed external to the ERP system, a narrow spectrum of applications was developed for demand planning and these were primarily designed for the statistical forecasting process. However, statistical forecasting is only one of several forecasting processes, and over the years the variety of demand planning applications has increased significantly. Therefore, attempting to force all of a company’s forecasting needs through a single application is no longer necessary or desirable. The diagram below represents the various forecasting processes:

Major Forecasting Processes

A common mistake companies seem to make is trying to use statistical forecasting packages to manage the other forecasting processes. Part of the reason that companies do this is because both the major vendors (who tend to only offer statistical packages) and the major consulting companies incorrectly advise companies that statistical demand planning software can be used to manage non statistical process forecasting. This analysis package will primarily be focused on statistical forecasting applications, but where the application can branch out into other areas, we will point this out.

It is important to understand where demand planning fits among the different supply chain applications, as shown in the graphic below.

Common Supply Chain Application Categories Demand Planning

Demand planning one of the major categories of supply chain software. When companies implement an external supply chain planning module to be connected to their ERP system, they most often start with demand planning.

If you read most forecasting books they tend to focus very heavily on the mechanics of forecasting. They talk about forecasting methodologies (simple exponential smoothing, regression, etc.), however not enough get into the business process or how forecasts are used in real life. The first wave or generation of applications leveraged the ability to place not so sophisticated and quite sophisticated forecasting methods in software. These applications had high failure rates because they were generally not designed to be easily implemented or easily maintained. Applications in this category are what we refer to as first generation advanced planning products. A good marker of a first generation advanced planning forecasting application was if it expended most of the development effort in the application of complex methods and would often have a proprietary forecasting algorithm. During the period when first generation the prevailing wisdom was that the application mostly came down to how complex forecasting methods could be applied in an automated fashion. This period in software, which has been the dominant software development approach lead to some very bad habits. In fact, there little evidence that sophisticated mathematics can improve the forecast of difficult-to-forecast products, and this is a problem. Some studies do not show improvement from more advanced methods, but firstly the improvement is never very large, and secondly other studies come by later to contradict the original studies. In addition, complex methods should have to exceed a higher bar. Academics can apply complex methods in a laboratory environment over a few products far more easily than can be done by industry. This fact, along with the point that sophisticated methods are much more expensive for industry to implement than simple methods, is rarely mentioned. This point is made very well by J. Scott Armstrong:

Use simple methods unless a strong case can be made for complexity. One of the most enduring and useful conclusions from research on forecasting is that simple methods are generally as accurate as complex methods. Evidence relevant to the issue of simplicity comes from studies of judgment (Armstrong 1985), extrapolation (Armstrong 1984, Makridakis et al. 1982, and Schnaars 1984), and econometric methods (Allen and Fildes 2001). Simplicity also aids decision makers’ understanding and implementation, reduces the likelihood of mistakes, and is less expensive.

This idea, that forecasting software just came down to most sophisticated forecasting algorithm has been incredibly durable, especially since the research into this area clearly demonstrates that when actually implemented (that is not in a controlled academic environment where only a small number of items are being forecasted), more complex methods have a hard time defeating simple methods. The major limiting factor that companies face in leveraging forecasting functionality? That would be getting these types of applications to be understandable and to work consistently. That is making them easier to use. Unfortunately, statistical forecasting software vendors do not tend to compete on the basis of how easy their applications are to use, instead the competition tends to center around the sophistication of the mathematics that is within the forecasting methods. Having covered this subject extensively and worked in the field for quite a few years, we can say with confidence that simply having sophisticated mathematical forecasting algorithms/methods within the application is nowhere near enough to obtain consistent forecast accuracy. This leads many companies to have a false sense of security with regards to their statistical forecasting application – and it leads to companies asking themselves “We have statistical forecasting software, why can’t we get a decent forecast?” A certain cynicism has crept into statistical forecasting – however, forecasting is a disciplined endeavor and many implementing companies are not used to performing the type of data accuracy and discipline and testing that is required for forecasting. Forecasting vendors have also been responsible for overselling the ease by which a forecast can be improved by a system without the required work. Finally, many forecasting software vendors have been let down by major consulting companies who seem to primarily be able to staff IT resources for forecasting – that can configure the system, but lack very much experience or an understanding of forecasting beyond textbook knowledge.

Attribute-based Forecasting

Attribute-based forecasting is one of the most important developments since enterprise demand planning software began being used. I know this is a big statement to make, but I make it based upon research into the history of demand planning and in light of my research I am quite confident that my statement is true. After one uses an application capable of attribute-based forecasting, it’s difficult not to come to the same conclusion. And perhaps most interesting is the fact that attribute-based forecasting is still only used in a minority of companies (even though so many vendors say their applications are good at dealing with attributes). Attribute-based forecasting can allow different groups and departments to perform forecast aggregation as they are interested in seeing the data, and does not require that one single static hierarchy be used for all users. With attribute-based forecasting systems, the implementation approach for forecasting and analytic projects, which currently focuses on the technical details of complex database setup, can be changed. Instead of explaining the concept of realignment and spending seemingly endless hours debating what the “one” static hierarchy should be, that time can now be refocused onto determining and explaining how the business can get the most out of the forecasting application. This is an enormous benefit to forecasting system implementation projects, which have tended—along with many other supply chain planning software implementations—to become overly technical affairs with more emphasis on meeting deadlines and IT objectives than on adding value to the business.

Is the Word Out on Attribute-based Forecasting?

I cannot find a good explanation for why the term is searched for in search engines so infrequently. According to SEOMoz.com, the number of searches typed into Google per month for either the term “attribute forecasting,” or “attribute-based forecasting” or other derivations of these terms is negligible. There few Internet articles on this topic as well. Even a search through Google Books does not bring many results (this is usually a very comprehensive way to search for a topic). Attribute-based forecasting may not be used that commonly now; but I predict it will be in the future.

Forecast Disaggregation

Every statistical forecasting vendor that I am aware of states that they can perform forecast aggregation and disaggregation; however, there is a large gap between statistical forecasting vendors in terms of capability. This functionality is too important for clients to simply accept the statement from a vendor that “our product can do that.” In fact, aggregation and disaggregation should both be extensively demonstrated and tested by the company’s planners prior to selecting an application for purchase, in order to discern how easy the aggregation functionality is to use in competing systems. Aggregation and disaggregation capability cannot be an afterthought. Instead these capabilities must be designed into the application from the database layer up. The following quote on this topic is instructive.

Demand Sensing

We point out all trends in each software category that we cover, the valid and invalid. One of the invalid trends that we have been tracking is called demand sensing. The information on the definition of demand sensing is currently and primarily controlled by software vendors. Demand sensing did not come out of the academic community, so there have been few unbiased descriptions of what demand sensing is. Demand sensing is the adjustment of forecasting inside of the lead-time of the product, and therefore when the supply plan cannot respond. If our lead-time is 2 weeks, then demand sensing means changing the forecast less than 14 days out. Demand sensing is the adjustment of forecasting inside of the lead-time of the particular product, and therefore when the supply plan cannot respond. Because demand sensing changes the forecast within the lead-time, demand sensing cannot be considered a forecasting approach. To understand this, its important to understand that while broadly speaking a forecast is a prediction of a future event; in practical terms a forecast is a prediction of a future event that is given with sufficient advanced notification to be worthwhile. For instance, a forecast could be improved for a football game by waiting until 1/2 the game is over. However, when half the game is over, it’s too late to place a bet on the game. Therefore the forecast is not particularly useful because it occurs within the lead-time of when a some benefit from be received from it. The forecast of the game could be further improved by waiting until the minute before the game ends, but again its hard to see how anyone would accept this as a forecast. One could not want to compare the forecast accuracy of a person who forecasts games while in progress versus those that forecast the game before the game begins. This of course brings up the topic of demand sensing and forecast accuracy “improvement.”

So Where Does Demand Sensing Belong?

Instead, it is a method of creating the illusion of improving the forecast accuracy by change the forecast in way that can never translate into an improvement in supply chain performance. This is extremely appealing to any demand planning group that cannot meet its forecasting goals (which is not to say they are realistic or unrealistic).  Interestingly, the vast majority of articles on demand sensing describe it as a method of improving the forecast, and categorize it as a forecasting approach. While its true that forecast accuracy can be improved by waiting until the last minute, this is blurring the line of what forecasting actually is. Vendors and IT analysts like Gartner have completely confused the issue by combining demand sensing with demand shaping.

The list of basic things that most companies cannot do in their forecasting systems is often amazing. A company that should start with doing proven things like those above to improve the forecast, will instead choose to go with the latest “trend,” and buy demand sensing software. They prefer to use an approach that is untested and has no academic research to support the contentions that the vendors in this area (notably Terra Technologies and SAP) make about it.

Software Category Summary

All companies would like to improve their forecast accuracy. Forecasting continues to be one of the great areas of opportunity within companies. Many companies are still using some combination of ERP (which is not a good platform for forecasting) combined with Excel. This is a difficult way to improve forecast accuracy. There have been many mistakes made on demand planning projects, and gaining value from a demand planning application means analyzing those mistakes and adjusting the implementation methodology. Application of the same approaches will lead to the same outcomes.

Overall this software category has several very compelling applications, and also a growing application where we are not sure how it will develop in the future.

The links to the specific research you have paid for is included at the beginning and end of this Software Category Analysis. You will only be able to access the pages that apply to your subscription.

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

Software Category Analysis – Financial and Accounting

Introduction

Something very interesting is happening in the space for stand-alone financial systems. And that is that even the largest buyers now have superior solutions available to them outside of ERP system financials. This is a fact, but is still little known among enterprise software buyers, most who still adhere to the incorrect notion that ERP systems offer the best financial and accounting functionality.

Quickbooks was the originator of the stand alone financial system, and has been fabulously successful, and has a very high client satisfaction level. Many people do not know that Quickbooks runs quite a few companies of surprising size that have essentially outgrown Quickbooks – because they started with the application before they began to grow, and never switched to a new financial/accounting system. However, other more heavy-duty stand-alone financial systems have risen to prominence. These application integrate very easy to supply chain and CRM systems, and have the potential to change the game in the ERP space.

A New Better Era For Financial and Accounting Applications

The applications profiled in this section have a level of user satisfaction, and a level of usability that ERP systems cannot match. Furthermore, the discrepancy is quite large and is widening because the stand along financial software vendors are innovators, while most ERP vendors are not. Secondly, some of these financial software vendors are quite new – which means they have exceeded the financial systems in ERP systems in a very short period of time. If the difference is already so great, our prediction is that it will only continue to grow.

Some of these new stand alone financial application are doing things that the financial systems in ERP suites never thought to do, and are allowing the buyers that use them to actually be better managed. For instance, the statistics on everything from how quickly money is collected, to revenue recognition to how sales is tracked is better in these applications than in ERP systems. The major consulting companies have been giving the advice to their clients that implementing an ERP system are the best route to better financial performance. However, the research into ERP system implementations over a period of three decades has proven this to be untrue. The question for the present and which will only increase in the future, is how much do companies intend to accept their performance to be reduced by continuing to use ERP based financial system?

Another major benefit of this category of applications is that none of the major consulting companies have consulting divisions that focus on implementing them. These companies do not get their sales leads from major consulting companies – which means the cost of implementation is far lower and the likelihood of project success is substantially higher than if a major consulting company is involved in the implementation. This is shown in our TCO estimation when one compares stand along financial applications to ERP applications.

Strong Innovation

Financial Force and Intacct are software vendors to keep one’s eye on. In addition to its leading financial application, Financial Force has introduced a very nice application, which is essentially a complete solution for consulting management called Professional Services Automation.

Professional Service AutomationThis application leverages Financial Force’s financial functionality by planning items like bill-ability, consulting revenues – in fact all the requirements to manage a consulting entity in one application.

Software Category Summary

The stand-alone financial application category has at least three excellent choices for small, medium and large buyers. While there is no research on the financial returns of these applications, they are so superior to what is currently used, that is ERP financial modules, that the likelihood of a strong ROI is properly implemented is quite high. The news on these applications is slow to get out, because buyers will not hear about them from their consulting company. However, once a detailed comparison is performed for what they can do, they become easy decisions.

MUFI Rating & Risk

See the MUFI Ratings & Risk below for each application in the Finance & Accounting software category.

[table “43” not found /]

 

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

Software Category Analysis – Production Planning and Scheduling

Introduction

Production planning and scheduling software has many more software vendors listed for it in some sources that we think actually qualify for the title. This is because many ERP vendors say that they can perform production scheduling, when in truth most ERP systems provide functionality which is just good enough to impress executives during the sales process, but not actually good enough to use. In fact, of all of the ERP systems that we cover, only Process Pro and Rootstock meet our standard in terms of having basic functionality in this area.

Most of the ERP applications work off of simple MRP for production planning and scheduling combined with a simplified scheduling screen. However, MRP is really only designed to create the initial production plan, and at the very least production planning and scheduling software should have heuristics. (for instance, Rootstock has a scheduling algorithm) Many ERP software are attempt to try to cover as broad of an area as possible, but this ends up with dissatisfaction once the system is live. This has been a constant feature in the production planning and scheduling space, which is why so many companies still rely upon Excel to perform production planning.

In practice the cost savings from effective production planning and scheduling are such that it typically makes sense to purchase a specialized application to do the job, therefore a well-managed software selection and implementation will often result in a good return on investment.

The Opportunity of Multi-plant Planning

Multi-plant planning, sometimes called multi-site planning, is the ability to model and make decisions to schedule production between alternate internal production locations that can produce the same product. By definition, companies that have components and subcomponents of final finished goods that are moved between factories have a multi-plant planning requirement. And this requirement applies to all manufacturing environments (discrete, repetitive, process batch, process continuous. A company that does not have multi-plant planning requirements when they start out, will have these requirements as soon as they choose to consolidate one stage of manufacturing to a single location in order to benefit from economies of scale and economies of specialization in that manufacturing process.

Multi plant planning is a more realistic representation of the real modeling requirements within many companies. This is because factories do not merely accept raw materials and ship finished goods. Instead, many factories receive raw materials and ship out subcomponents. Other factories receive subcomponents and ship out components or subassemblies. Many possible combinations of factories are possible and always have been at least to some degree.

There is little doubt of the many companies with multi-plant planning requirements. We have experienced the requirements first-hand and in depth at one company, but have found these requirements at other companies as well – its simply that most are unaware what these requirements are actually called, that there is academic work which describes them and they are unaware that they are losing efficiency by not being able to account for these requirements. Multi plant planning is an important stage in the evolution of planning software, which is related to subcontract and contract manufacturing planning all of these planning requirements mean the planning system is indifferent to whether the manufacturing location is owned or not owned by the implementing enterprise. Companies have little in the way of information on multi-plant planning, which should not be surprising in the least. In fact, we know from our consulting experience that many companies have multi-plant requirements but are simply not leveraging the software currently available to manage these requirements. In fact, at most companies the internal discussion about doing so has not even begun. Common reasons as to why this is the case are listed below:

  1. Many decision makers in companies with multi-plant planning requirements do not know that the functionality to specifically address these requirements exists.
  2. Many companies do not include vendors with multi-plant planning functionality in their software selection initiatives.
  3. No ERP vendor makes external planning software that performs multi-plant planning. Buyers would have to be willing to choose a smaller vendor rather than simply purchasing the ERP vendor’s external planning system. This is of course a limiting factor, because buyers tend to purchase as much software as they can from one vendor, which incidentally is why the enterprise software sector is so monopolistic in nature and why so many buyers have such a poor fit between their business requirements and the applications they have purchased.

Intercompany Transfer, Subcontracting and Contract Manufacturing

As software buyers/companies have moved to more specialization in their factories (co-locating specific manufacturing in global locations), intercompany transfers have become increasingly common. Concentrating similar types of production in factories globally has been occurring for some time. Things like subcontracting, which at first glance would seem to reduce the necessity for multi-location planning, in fact increase the necessity for multi-location planning. Even in instances where third parties are involved – such as with subcontracting — the primary company or OEM often wants to plan the activities, even if they do not perform the actual execution. In fact, we now have the common scenario where planning factories — or at least partially planning factories that are not owned by the company performing the planning — are a common requirement.

As most enterprise software is not designed to accommodate these requirements, a great deal of effort is needed on the part of companies to both implement and maintain the software. The retort from many vendors might be, “but we offer supplier collaboration and subcontracting” — which is true. However, it is also true that these tend to be tricky implementations, and in some cases, such as with supplier collaboration, there are in fact few success stories.

Subcontracting

Along with multi-plant planning, subcontracting has greatly increased as a planning need within companies. Subcontracting is another form of production where there is ambiguity between the external plant and the internal locations. Another related concept is contract manufacturing, where the product is produced completely by the contract manufacturer but planning responsibility is shared. Some supply chain planning applications can plan subcontracting; however, the functionality multi plant production planning functionality can make comparisons between alternative production that is either internal or external to the company. In some circumstances, production may be outsourced; in other cases it may be planned to be produced internally. Oftentimes inflexible planning systems mean that companies are forced to make these types of decisions “strategically.” However in the software described in this book, the alternatives can be set up in the model, and the application can switch between internal and outsourced manufacturing as the situation changes.

Understanding the Segmentation Between Supply and Production Planning

SNP_Production_Horizon-2

The main area of focus of most supply chain planning vendors that develop software in this area has been not to integrate the supply planning application and production planning application. Most software vendors simply assume them to be two different things.

The weakness of this design is the natural inconsistency between the supply planning application and the production planning application. For example, SNP and PP/DS — and most other supply and production planning applications — work off of a different set of assumptions. Just setting the timings and planning horizons between these various systems is a lot of work, as is displayed by the following screen shot.

APO Planning Horizons

We have spent quite a lot of time walking implementing companies through how to integrate planning horizons and timings in SAP APO. In fact, the topic is so involved we published a book specifically on this topic titled, SCM Focus Press book Planning Horizons, Calendars and Timings in SAP APO.

In environments where there are dependencies between production, such as when a finished good in one factory is fed by semi-finished goods or components (or the components are in a third factory feeding the semi-finished goods plant – which we have seen at several companies), then the production planning and scheduling across the various plants ends up missing out on a number of planning opportunities that a multi-plant planning system could leverage.

Software Category Summary

Production planning and detailed scheduling is still an area with a great deal of potential. The software category does not have that many quality applications – and most the applications are 1st generation applications that are masquerading as leading edge applications that should probably be retired. Once again, proper selection is critical, as the ability to receive value from 1st generation production planning applications has proven to be very difficult.

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

Software Category Analysis – Supply Planning

Introduction

Supply planning uses the methods of MRP, DRP, heuristics, allocation, and optimization (both cost and inventory) in order to make the recommendations of what, when and how much to bring material into the supply network, the what, when and how much to move material between the locations of the supply network, and in some applications what, when and how much create the production recommendations. Supply planning was performed exclusively in ERP systems using the twin methods of MRP and DRP up until the mid 1990s when companies began investing in advanced planning systems. These advanced planning systems used more sophisticated methods that up until that point hardware was insufficiently powerful to leverage. These applications were introduced with great fanfare, but also had high failure rates because they were generally not designed to be easily implemented or easily maintained. Applications in this category are what we refer to as first generation advanced planning products. And a number of software vendors are still selling these applications as if they are state of the art. A good marker of a first generation advanced planning applications is if it uses a cost optimizer. During the period when first generation the prevailing wisdom was that any supply chain domain could be “optimized” with by focusing on minimizing costs. Some of the advanced planning applications have still not progressed beyond this state. Optimizers are run with constraints, which limit the result to what is actually feasible.

Constraints

When used in planning, constraints limit the solution to what is feasible, or what is actionable by the business. By limiting the solution, the time and processing spent evaluating recommendations that cannot be converted in reality are also limited.

The Real Story Behind Constrained Planning

The ability to use constraints is a major differentiator between applications in the minds of buyers. However, the ability of buyers to actually implement constrained systems is much more limited. One of the important factors in how well constraint based systems can be implemented is how easily constraints can be modified and assigned – something which buyers rarely look for. The best application at managing constraints that we have seen is PlanetTogether, which is primarily a production planning and scheduling software vendor, although they are moving into supply planning. Curiously enough, while applications like SNP can hold supply planning constraints, by far the most common constraints used in supply planning are actually production constraints. Supply planning applications can be differentiated partially based upon whether they can incorporate production constraints. When they do, and when they are used, the planning system generates both the initial production plan along with the supply plan (stock transfers and purchase requisitions).  After this point, the supply plan and initial production plan are passed to the production planning and scheduling system where the more detailed planning and scheduling is performed, and adjusted, before being passed back to the supply planning system. This is the standard approach used by the supply planning applications that can incorporate production constraints. We refer to it as the sequential approach, because first the supply plan is run, then the production planning and scheduling is run. However, after several decades of working this way, our observation the standard approach is not actually effective. PlanetTogether, a software vendor we rate as the most innovative in the production planning space, are currently developing ways in which the supply plan and production plan are created in a single planning run – something which allows production to be managed much more flexibly than in the standard sequential approach.

Choosing 2nd Generation Planning Applications

Because of the numerous implementation problems with first generation supply planning systems, we tend to score applications significantly higher if they were new – which would mean being developed on new principles within the past 10 years. This is not because we are focused on newness for simply the sake of newness, but because there have been observations about what has and has not worked in supply planning, and older applications – while they may make some changes, have difficulty in being adjusted to work a more modern and effective way. In addition to the modernity of the methods used, we give significant weight to how well the system can be adopted by users. One of the highest rated applications in this category does not actually use complex methods for generating the supply plan, but is highly rated because software vendor focused on usability and maintainability. This should demonstrate our view, which we can support with project experience, that the complexity of the mathematics used to generate the supply plan is only one measurement of the application. This is actually a consistent observation across many enterprise software categories, if not all of them that complex solutions often do not lead to good outcomes.

Inventory Optimization and Multi Echelon Planning

Several of the applications profiled in this software category section use the inventory optimization and multi echelon planning (MEIO for short) method. MEIO is an innovative use of two separate forms of optimization: inventory optimization and multi-echelon inventory optimization (but which I simply refer to as multi-echelon planning to reduce confusion). MEIO applications are an example of the 2nd generation planning applications that we just discussed. While cost optimizers are generic and adapted to different supply chain planning domains, MEIO was an attempt to adjust the optimizer for the specific environment of supply planning; each component of MEIO answers a separate supply chain-planning question.

  1. Inventory Optimization: Answers the question of how much to keep in inventory.
  2. Multi-echelon Planning: Answers the question of where to keep inventory in the supply network.

Developers of MEIO applications have very smoothly combined both sets of mathematics (which were developed separately) to work in unison during a single supply planning run. Unlike supply planning techniques that use sequential processing or calculation, MEIO calculates the service level impact of carrying one additional item at every product location combination and then sorts the list of options by their contribution to service levels and selects the best contributor. It is a powerful technology that is still only understood – beyond a high level understanding – by a small portion of the people that work in supply planning. Some important concepts behind MEIO are included in the following paragraphs.

Multi Echelon Aggregate Purchasing

While most companies have multi-echelon networks, not all supply networks are of equal complexity from the perspective of multi-echelon. The more locations, and the more echelons (regional DCs, which feed DCs, which feed forward stocking locations, etc.), the more complex the multi-echelon problem becomes, and the more beneficial the implementation of MEIO software would be. Service parts networks are known for having a high number of echelons due partially to their need for forward stocking locations that can quickly service expensive equipment, thus minimizing equipment downtime. Service parts networks have the additional complexity of needing to move repairable items to locations in the supply network where they can be serviced. Therefore, it is not surprising that one of the early innovators in multi-echelon inventory optimization was MCA Solutions, a vendor that focused on the service parts market. Unfortunately they were acquired by Servigistics. Furthermore, the earliest papers on multi echelon and inventory optimization were directed towards optimizing service parts networks, not finished goods networks.  For any application to be multi echelon, it must have the concept of effective lead time – that is instead of viewing lead time as a static input, effective lead time is situational, and dependent upon other conditions in the supply network.

Effective Lead Time

In this example, the effective lead-time is the lead-time experienced by a customer at a retail location. Note the chain effect: their effective lead-time increases as the quantity demanded increases as more demand stocks out locations higher in the supply network. The numbers here are kept small in order to improve the clarity of the explanation. A key assumption is that this is a single product supply chain.  All locations carry only one product. The example above shows that that while the actual lead time stays the same between the locations, depending upon the demand vs. what is stocked at the various locations the effective lead time changes depending upon how high the multi echelon supply chain it is necessary to go to obtain inventory. Service levels can be set at various places, which vary depending upon the particular vendor. Companies that intend to select and implement MEIO software should have the necessary internal discussions as to how and where they want to control their supply planning with service levels. The way the implementing company is current performing supply planning will if unaltered, will not be able to fully leverage MEIO’s capabilities. The decision of where to set service levels should be known prior to any MEIO software selection. Of course this means understanding the options for service levels. To this end I have listed the options below. In MEIO software, service levels can be set by the following:

  1. At the location
  2. At the product-location combination
  3. At the group location
  4. At the customer
  5. At a product mix, and
  6. *At the contract/equipment

Degrees of Serice Level Control

Where the service level can be set in the application makes a very big difference in terms of how the company can use the application as well as how powerful the application is, but also in the degree of maintenance required after the application is installed. MEIO applications can be categorized partially by how easily the service level is set and how high in the hierarchy—contract, customer, location, and product location—the service level can be set

Multi-source Planning

Multi-source planning (or multi sourcing) — the ability to have the system flexibly choose from external sources of supply — has been a consistent requirement at many companies. However, many companies have also had a problem getting multi-source planning to work the way they want it to work, and so it is not implemented as commonly because of issues with functionality robustness. Buyers must do a better job of having the software vendors actually make proof of concepts with regards to multi sourcing work if the application is being partially purchased on the basis of this.

Software Category Summary

Supply planning has a hangover from the purchase and implementation of many applications, which were overly complex, and developed and implemented by software vendors more focused on sales than on implementation success. The likelihood of receiving a very good supply plan from and ERP system is low. Supply planning systems are very important to the overall solution architecture, but the best applications cannot be found from any of the name brand software vendors. To find a good supply planning application, buyers should be looking for 2nd generation applications and software vendors who have really thought through what has and had not worked in previous approachs. Supply planning software is a complex area to analyze and it’s easy to get tied up in the complexity of some of the applications. Overall this software category has a small number of compelling applications. This is an area where buyers really understand their requirements and their tolerance for complexity before even initiating a software selection.

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

 

Software Category Analysis – CRM

Introduction

CRM is the fastest growing software categories that in enterprise software. CRM has been forecasted by Forbes to surpass ERP in revenues by the year 2017. If that occurs, that will be a fantastic accomplishment as this is the first time that any other category of enterprise software has even come close to ERP sales since ERP was introduced back in the 1980s.

This is good news and bad news regarding CRM. First, the good news is that CRM has been the test case for SaaS delivery of enterprise software. If it had not been for CRM and specifically for Salesforce, SaaS would have taken considerably more time to take hold. It should be remembered that the conventional wisdom was that no one would trust or use SaaS because it required giving up too much control – and then Salesforce went and proved everyone wrong. This is just another example of where the experts that cover enterprise software have been wrong. However, the bad news is that CRM is probably not worthy of being the next big enterprise software trend for reasons that will be explained shortly.

A Short History of CRM

CRM is an interesting software category because, before SaaS, and Salesforce, on-premises CRM had one of the failure rates of any category of application. Siebel was, of course, the market leader (Siebel was acquired by Oracle in 2005, and as is standard is now an irrelevant application), and then other companies like SAP and Oracle developed CRM applications. All of these applications failed in implementation at very high rates, and now most of the CRM market is delivered by SaaS, and it is the only category of enterprise software that is delivered this way. Why? Some have argued that CRM is a natural fit for SaaS delivery because it is a more straightforward application, and requires little in the way of computation. CRM is after all just an input-output application. However, while this is a tempting line of logic, we don’t think this can be the only reason. One could run some of the most complex and processor heavy enterprise applications in the cloud, as the server is in any case remote from the user regardless of whether the application his hosted internally or externally. For instance, if we look at DropBox – a cloud-based data hosting solution, it has a better search capability than any operating system search we have ever tested – and this is a combination of both specialized hardware as well as software for searching.

Persistent Data Quality Problems

CRM has shed much of its image as a widow maker for IT; however, when we sit with marketing and sales personnel as they show us their sales data, we see continuing data quality issues. These sessions invariably end with a statement from the marketing or sales director we are sitting with say something like “much of this data is out of date.”

We would caution buyers not to get caught up in the hype of CRM. The number one problem with CRM is getting quality sales data, and this continues even with all of the advancements in CRM technologies. All manner of data quality issues has lead to software vendors that have products that clean CRM systems such as Talend and Data Cleaner (although the focus of these applications is more on the low-level quality issues such as duplicate records).

CRM Data QualityApplications like Data Cleaner check for things like completeness in CRM systems.

Many companies are happy with how quickly they can get a CRM system operational, but a detailed review of the data quality is almost always disappointing. This is a greatly deemphasized topic by both consulting companies – particularly the major consulting companies as well as the CRM software vendors as if clients knew the real average quality of sales information in CRM systems, it would put a severe damper on CRM software sales. Of course, no one that stands to make money on CRM is going to kill the party by declaring that CRM systems offer dubious payback. Both of these entities can get away with doing this because buyers often are fooled by the participation in the CRM system or the amount of data that is within a CRM system as a measure of the success of the implementation.

The Sales Forecast Problem

A significant problem persists with the quality of forecasts that are entered into CRM systems with the vast majority of companies not adjusting these sales forecasts for bias. The bias of Sales in forecasting generally is so well known that the software vendor Right90 has developed its primary application, as well as a CRM “plug-in” that is run from the Salesforce.com platform and Oracle CRM on Demand (and can be integrated to other CRM applications as well) which is centered on managing the bias of sales forecasts. Few buyers buy this plugin or address their persistent sales forecast bias.

Bias is a constant in forecasting regardless of the forecasting environment (supply chain and non-supply chain), yet few buyers are willing to see the forecast bias inherent in judgment methods as anything beyond a cognitive bias (that is an unconscious bias or error in cognition). Forecast bias is a tendency for a forecast to be consistently higher or lower than the actual value. Forecast bias is distinct from forecast error in that an estimate can have any level of error, but still be completely unbiased. For instance, even if a forecast is fifteen percent higher than the actual values half the time and fifteen percent lower than the actual values the other half of the time, it has no bias. But forecast which is on average fifteen percent lower than the actual value has both a fifteen percent error and a fifteen percent bias.

Bias can exist in statistical forecasting or judgment methods. However, it is much more familiar with judgment methods and is one of the significant disadvantages of judgment methods. The fact that different groups in a company have different incentives is well documented. These incentives can cause the forecast to be set higher or lower than they rationally would be. Considering today’s level of technological sophistication, it is baffling that most companies don’t know the effect of the bias of different areas of their company on their forecast, much less the effect of the bias of different individuals.

On the other hand, many vendors don’t emphasize bias detection in their applications, so in many cases, companies are required to build custom reports to determine forecast bias. It is rare for software vendors to make bias identification a focal point (although consensus forecasting vendors seem to be ahead of the curve on this topic). Therefore, most companies lack software with an internal dashboard that allows the company to adjust for bias. This is where custom report building comes into play.

Companies will often implement a CRM system, but not analyze how their internal sales incentives affect the quality of information placed into the system. Measuring individuals on sales volume and service level, without measuring them on inventory or forecast accuracy will promote a natural inclination to over forecast. This is because over forecasting provides the ability to meet a higher sales volume with service level and sales volume Over forecasting is so common in this scenario that its technical name is “hedging,” which is..

“Used so that “the factory will have stuff when I want it.” This game may be played by salespersons or customers, especially when capacity is tight or for new products.” – Sales Forecast Game Playing:Why It’s Bad and What You Can Do About It

Is CRM Improving Sales Forecasting or Customer Service?

One of the interesting features of CRM that we have yet to see discussed is if CRM applications are really helping companies, why are we not seeing improvements in forecast accuracy in companies that have a CRM system? This is not a question that CRM salespeople are interested in answering.

There is little doubt that CRM systems improve visibility, but how does that visibility translate to financial benefits? It is estimated that roughly 90% of CRM systems are implemented without “significant business gains.” CRM systems are ostensibly designed to provide all types of customer information at sales, customer service, etc.. individuals fingertips. That is the hypothesis. However, two more important questions should be asked:

  1. Is CRM improving the customer experience?
  2. Is CRM customer service improving generally?

The answer to this question is easy to determine, customer service is widely acknowledged to have precipitously declined right as CRM implementations have increased.

One may question whether this is a correlation (the two just happened to be related) or causation (bad service is causing CRM implementations, or CRM implementations are leading to bad customer service) and we do not know which is the right answer. However, we do know that no CRM solution or other technology can improve customer satisfaction if the company has decided to no longer take care of its customers. For instance, Sears, once a service leader that has been in great decline in great part because of policies that wiped out its customer service, began providing iPads to sales associates – thinking this could help overcome poor pay and poor training and other incentives (that is another reflexive rule of the terminally uncreative – add iPads). This is what we refer to as Technology as Band Aid Syndrome, where technology is used to cover up bad management practices. Technology can be a good thing, but if it simply becomes a crutch for a management that is completely self-centered and is playing to Wall Street’s biases, technology can be a negative. Technologies like CRM are often used to mask the fact that the pay level for many of those that provide customer service is low and even worse to feel as if they can place enough information into the service system that they can deskill the position of customer service and outsource it or cut wages. This leads to high turn over, and moral problems. The discrepancy between what salespeople get paid (and also how much goes to advertising), versus what customer service people get paid continues to widen.

Customers have noticed. Secondly, the differential between what they are promised – both by sales, but particularly by advertising is often a yawning chasm – as advertising feel it is their right to engage in any type of deception in order to make sales go up. Again, this is not something that CRM can help solve.

Research on CRM Based Business Improvement

We were unable to find any research on CRM applications improving sales, forecasting or customer service – the types of things that CRM is supposed to improve. The CRM market is overflowing with promises but has precious little evidence to back up the claims that are made for it. This is the premise of the book Why CRM Doesn’t Work: How to Win by Letting Customers Manage the Relationship. In the book, it is explained that CRM projects often seem to become about the efficiency of processing customers rather than analyzing the sales or service process. CRM applications are often sold as Band-Aids by consulting and software vendors alike. And that beyond simply covering up sales and service policy and incentive problems, CRM is used to manipulate and extract from customers (Customer Relationship Mangement). One CRM vendor, Base CRM actually writes on this topic. In their blog post 5 Ways your CRM is Decreasing Your Productivity Base CRM author Laura Licata points out the following:

  1. Data entry is turning your reps into robots.
  2. Duplicate data is making a mess of your system.
  3. It’s so complicated that your reps get frustrated and stop using it.
  4. Inaccurate reports are causing your to make bad business decisions.
  5. It can’t keep up on mobile.

The software vendor Base CRM is attempting to get companies to buy its software, by proposing that they aren’t like standard CRM, but the information it is providing on this topic also happens to be true. Many CRM applications are not designed for everyday usability.

This brings up a very rarely asked question with regards to any software category. Normally a software category is measured on its ability to provide a positive return on investment. Some applications, like tier 1 ERP have a negative return on investment, which simply means the application will not pay back its total cost of ownership. An ERP application may have a 7 year TCO of $20,000,000 and only pay back $18,000,000 thus having a negative ROI. However, CRM is the only software category that we analyze where the question comes up if CRM actually worsens the company’s position.

CRM’s Low Average Software Quality

CRM easily has the least impressive applications of any enterprise software category we cover. The applications that impress us are normally never the big brand names – however, in most software categories we come away impressed with the thought that went into the design of the application. We are software enthusiasts and love good software. However, it was infrequent that when we were testing any of the CRM applications and came away impressed.

Nailing Down What is CRM

CRM is morphing into something that no one expected – an overall marketing platform. In just a short span of time CRM has turned from the enterprise software category one of the highest failure rates, that had the modest goal of accepting and reporting on sales information into a software category with high rates of success and which does so much more than just accepting and reporting on sales input. Most of this is due to Salesforce. They showed what was possible, and created the credibility that CRM has with companies presently. It turns out that putting CRM into the cloud-enabled all of the other functionalities that have since been added to CRM to flourish.

Software Category Summary

When purchasing something that has so little in the way of evidence that it will help your company, it makes sense to limit the expenditure to the good, but inexpensive applications. This leads to a follow-on point. This is the natural conclusion based upon the low potential of CRM systems.

Its difficult for us to see many of the CRM applications that we reviewed could make much of an impact to a company’s bottom line. There is far more potential in other software categories, and applications in software categories with a much higher potential ROI – such as PLM/BOM management software are underinvested upon. We are one of the few information sources on enterprise software that actually helps buyers prioritize their software purchases.

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

References

http://www.businessinsider.com/sears-gave-up-on-customer-service-2013-2

*http://boss.blogs.nytimes.com/2009/08/04/why-customer-service-is-so-bad/

*http://www.amazon.com/Why-CRM-Doesnt-Work-Relationship-ebook/dp/B003NX730Q/ref=pd_rhf_dp_s_cp_5?ie=UTF8&refRID=1R83Y2RG1N9RCVH0FMFG

Nguyen, Bang. Simkin, Lyndon. The Dark Side of CRM: Advantaged and Disadvantaged Customers. Journal of Consumer Marketing. 2013.

*http://blog.getbase.com/5-surprising-ways-your-crm-is-decreasing-your-productivity

http://www.forbes.com/sites/louiscolumbus/2013/06/18/gartner-predicts-crm-will-be-a-36b-market-by-2017/

Software Category Analysis – BI Light

Introduction

Business intelligence or BI was initially meant to mean the applications that could be accessed by business users. However, the term has morphed into a catchall term which covers a variety of technologies which include reporting, OLAP, analytics, data mining among others. The BI field is filled with different technologies and subdivisions, which makes it one of the more confusing software categories to drive to clarity on. In fact, this even complicated our software selection packages and software project planning analysis because while other software categories will have a single product name, most of the BI solutions offered are a variety of suites, with differently named suite applications.

The term BI had its origin in a 1958 paper by an IBM researcher where he employed the definition of intelligence. Therefore, it is really data that leads to insight – which of course is a very broad term. Everything that we now think of as BI has simply developed from that original idea, but it how encompasses specific types of applications. A BI application may or may not rely upon a data warehouse, and in fact may rely upon a data source.

BI is one of the faster growing categories of enterprise software. However, the growth is very different depending upon the category of BI software vendor. The large BI software vendors (Oracle, IBM, SAP and to a lesser extent Teradata) are seeing moderate growth, and with newer and more self service software vendors (QlikView, Tableau, Birst) seeing very rapid growth. The growth leader currently is Tableau, an application that is quite deserving of this growth.

Our Approach to Analyzing BI

As part of our research process, we perform a literature review, which means reading the reports of other analysts. In these reports we have noticed these use of many descriptors related to the data technologies employed. For instance, there is a lot of discussion of whether an application uses and in-memory database. For us, the particular approach used by the vendor is simply the input to the output of the analytics, reports, etc.. There are software vendors like SAP and Oracle that are putting data into in-memory databases in order to make a splash at conferences, that don’t have anything to do with improving reporting outcomes. SAP has made a great deal of marketing noise about its HANA in memory database, while having one of the poorest overall BI platforms and while buyer after buyer complains to us about reports that are late or never appear. Therefore, our analysis does not spend much time quoting the underlying technology as this is in our view a distraction to presenting the analysis of how these applications perform in real environments.

Heavy Versus Light Solutions

There is a great deal of debate within the BI market as to which applications fit into which categories. If we got into all of the sub areas of BI we would have to explain statistical analysis tools, predictive analytics, data warehouses, etc – and so we needed some type of shorthand to categories BI solutions. Some applications pull from of other data sources, and do not offer a data warehouse. This means they cannot be compared in terms of price or broadness of functionality with tools that can pull from data sources by are not data warehouses. However, on the other hand – there is a debate as to how necessary a data warehouse actually is. We know many buyers for which a data warehouse is overkill. The data warehouse philosophy has been prevalent for decades, but it generally did not lead to the availability of information that was predicted or promised. It essentially creates a heavy infrastructure load, which regardless of whether on is pro or anti data warehouse it is difficult to see how the following should not at least be acknowledged that

  1. The data warehouse was never able to achieve the productivity necessary to meet the promises that were made for the approach to managing data (now the debate begins as to why which is where all the arguments begin).
  2. Data warehousing projects are extremely time consuming and expensive.
  3. Many buyers are currently saddled data warehouse software and an overall set of BI applications that they are unwilling to staff sufficiently to get the value out of these platforms.

In fact, one of the tricks to getting a well priced and good performing overall BI solution find BI Heavy and BI Light applications that can work well together and that are efficient to run. This point is critical because so many BI Heavy applications or suites of applications are inefficient to actually run, and too many buyers end up with BI Heavy applications, which overwhelm their ability to support them. (Our estimations for resourcing BI Heavy applications/platforms are significantly higher both for support as well as for the implementation over BI Light applications/platforms)

Debates on the topic of data warehousing are eerily similar to a group of people who have a great deal of their career invested in a philosophy, and are reticent to admit that it has not done what it said it was going to do. It is true that centralized “single source of truth” data warehousing makes sense as a principle, but technology merits are not the only thing that counts. Data warehousing also means getting agreement from many different entities in companies that are self centered, and can easily lead to a tragedy of the commons – which as much as technology is why data marts became prominent. Furthermore, a Inmonesque data warehouse is a high standard requiring a high level of planning and discipline, and not every buyer is up to the task. These factors, which goto the limitation of the Inmonesque data warehouse were behind the growth of several areas in BI, including the analystics appliances like Exadata and Netezza.

Because we cover so many areas in enterprise software, we can see similarities in the argumentation over various technology debates, and other areas such as service oriented architecture (SOA) which was heavily hyped and did not have really any impact in how IT. This is the strong tendency to ever declare any approach to be invalid or flawed, and in particular companies that have a revenue stream, which is derived from one, or another approach will never admit that approach has not worked. They will argue instead that the approach has simply not been implemented correctly – and this can go on for decades. We refer to this as the Evergreen Syndrome. That is no IT idea – if it is profitable for some parties — ever dies, it simply fades from view.

BI Becomes More Responsive

In the last few years, and for probably the first time as a broad trend (one of the historical exceptions being Crystal Reports), software vendors have developed applications that are just as focused on ease of use as the technology. Prior to this, BI vendors have been developing difficult to use products, and then buyers have been wondering why they have low report development productivity and low user adoption and satisfaction. This shows in which BI software vendors are able to satisfy buyers. The big software vendors with “complete” solutions like Microsoft SQL Server, SAS, SAP, Oracle and IBM all score poorly in satisfaction. This leads to a very important point.

There is No Single BI Vendor which is a One Stop Shop

For many years, having a complete solution has been presented as a reason to by from one vendor over another. These software vendors have made large numbers of acquisitions and attempted to integrate these various technologies into a coherent offering – and it has not worked. The BI Heavy vendors that offer “total solutions” such as IBM, SAP, MicroStrategy are overbearing in their insistence that their solutions be used in their entirely – declaring their unwillingness to be used in conjunction with other applications that are all of course inferior to theirs. Buyers that engage any of these vendors will be beset by condescending BI consultants and sales reps that will drone on – in a difficult to monotone and interrupt manner about how their solutions have been designed from the ground up to work as a complete suite. With the exception of just a few vendors like Actuate and SAS the other BI Heavy vendors are intent on employing account control techniques to take over a buyers’ overall BI spend.

The logic for attempting to find a one stop shop is just not there. All of the BI Light software vendors can connect to literally any data source – and software vendors that propose they are providing some major value add by combining front and back end BI elements to buyers are practicing make believe. They are cutting off options for the buyer under the rubric of “adding value.” This is why buyers should not attempt to get all of their BI needs from a single vendor. The larger BI vendors as a group have a long history of misrepresenting how much training and effort is required to effectively use their applications. This is a feature that generalizes across enterprise software categories, but it has been a particularly problematic issue large vendor BI.

Heavy and Light BI

There are a variety of terms that is often used to describe different categories of applications in the BI software category. However, we categorize all BI solutions as either “BI Heavy” or “BI Light.” In many cases the BI Heavy solutions contain a data warehouse. Below we have assigned each vendor that we have classified as one of the other.

SAP Crystal Reports Introductory Series_ The Report Wizard - YouTube

Beyond this simple graphic there are still important distinctions between the applications. For instance, some vendors like Teradata, which makes one of the most heavy duty data warehouses would debate if other software vendors that we designate as BI Heavy should be categorized as such, so there is a level of debate even among this basic segmentation. BI tends to be a contentious software category with many strongly held opinions. For decades there was a strong disagreement between two different philosophies of data warehousing called the Inmon (Corporate Information Factory and Top Down) versus Kimball-Bottom Up debate (hint the Kimball data mart approach proved more attainable by most companies).  

Companies need to decide what they are actually buying, and should not simply based upon conventional wisdom or the investment one has in one or the other approach. Not all companies need BI Heavy applications. And how one evaluates a BI Heavy versus BI light application is quite different. For instance, IT holds most of the decision-making power when it comes to which BI Heavy application to choose, however, the business users should have most of the decision making power when it comes to BI Light applications. As with ERP, the tendency in buyers has been to try to consolidate requirements into one software vendor, however this is a failed strategy for BI software selection.

Most of the suites from the big BI vendors are really just a hodgepodge of applications from acquisitions. A perfect example of this is Business Objects, BI/BW and Crystal Reports (in this case two of the applications were acquired by SAP, and one developed internally). SAP frequently makes the case that these acquisitions were strategic and create synergy. In the case of Business Objects, this was a competitor that was beating BI/BW in head to head competitions. SAP was able to remove this competitor through acquisition – thus enabling it to increase the price of both applications. SAP has done very little to integrate Business Objects into the their BI “solution.” It’s just a product that is owned by SAP to enhance its monopolistic power. Is the fact some mega vendor needed to eliminate a worthy competitor and to reduce the price pressure a reason to buy an application? We don’t think so.

“Self Service” BI

One of the biggest trends in BI has been the move to so called “self-service.” The efficiency of IT with regards to report creation has been well understood to be poor, with literally applications like SAP BI and IBM Cognos pulling the life force out of the business with late reports, or reports that are provided that do not meet the business requirements. The support ratios for many applications in business intelligence are so high that they are driving buyers to applications with lower support ratios. IT is in a conundrum with respect to BI. They have a natural inclination to want to control BI, to choose the solution, but on the other hand, they are tired of being beat up for reports being late – a perpetual issue at most buyers that we interact with. However the term self-service is a heavily marketing laden term. None of the applications that are often called self-service are actually self service to the extent that they actually do not require significant training and hand holding. Applications which are described as self-service by the business press and by software vendors and IT analysts like Gartner – are simply lower support requirement applications.  It is no coincidence that applications of this type, such as QlickView and Tableau have the highest buyer satisfaction levels as well as the highest user adoption levels in BI. We have an example from one of the main self-service applications, which is Tableau.

Tableau Self Service

Software vendors tend to show finished reports like the one above. This provides a misleading impression as to the skill necessary to create these reports. Tableau is a great BI Light application, however, there are a ton of options. Tableau simplifies some of the decisions with its Show Me option in the upper right hand corner, which greys out chart types that do not apply to the data. Another major functionality which encourages self-service is the back button in the upper left corner. This allows a user to experiment and then return to the earlier state. It is also a multi-back button, so multiple changes can be made to a report and then all of these adjustments can be undone returning the report to its earlier pristine state.

However, In addition to deciding what measures or dimensions are pulled to the row and column, each measure and dimension has a drop down which changes how it is used by the application. Another factor to be adjusted is whether the data will be summed, counted, etc. All of this takes considerable experience and that is simply to create the report – there is more work in knowing what data to pull into Tableau.

Tableau Data Pull

Self service applications make a big splash about how easy it is to pull data into them. Tableau does offer many different connections to different data sources, however, have these already been setup by IT? Will IT connect to the proper IT sources? Will the business need to do some of this work themselves if IT is slow to do so?

Tableau Health Care

Notice in this report the AVG Heath Care and Average Life Expectancy is assigned to the Columns, Rows, as well as the Filters and to the Marks area.

Tableau Health Care 2

We can adjust this by placing the AVG GDP in $ measure into the column and removing the previous entry. This changes the relationship shown but keeps the overall chart the same. This was easy for us to do. This is probably the better application of self-service applications – that is having an overall report structure created, but allowing the users to make changes to what is shown in the report.

Tableau Cost Per Life Span

We consider Excel to be a true self-service application, and by that measurement, all BI applications we have evaluated fall short of that. These applications are much more powerful than Excel. However, it is certainly worth it. This report shows that the United States pays an exorbitant amount of money for it life expectancy, and that this the overpayment has very significantly increased since 2001. But one can’t have it both ways. One cannot expect BI applications that can produce sophisticated and nuanced report output, and then on the other hand expects this output to be entirely self-service.

While in the past BI Heavy applications were the most widely purchased, this is beginning to change – as is explained in this quotation from Forrester.

“However, anecdotal evidence leads us to believe that with the proper BI application portfolio classification, no more than 20% of all BI applications should fall into this restricted category. We maintain that in an ideal BI environment, 80% of all BI requirements should be carried out by the business users themselves.”

When we evaluate new implementations it is amazing to us how often the reports come in 6 months to 12 months after the application has been live. For all the talk of advanced techniques and data warehousing, it is amazing to us how poor the selection of reports actually is and many buyers. We have to question why this is not more widely understood. Why do so many journalists and IT analysts accept the promise of BI over the reality of BI? The major software vendors have large investments in BI Heavy applications/platforms and major consulting companies have major investments in resources, toolkits and training in BI Heavy applications – the consulting companies and IT analysts are doing a thorough job of hiding the obvious productivity enhancements that are being provided by BI Light solutions from their customers.

Reporting is the ultimate example of “selling the future.” In our observations BI only meets its potential when IT is taken off of the train tracks for creating reports, and simply maintains the backend, allowing the business users to build their own. There are a number of reasons we believe this, but one being a study of the history of BI, and a second being our participation in the gathering of reporting requirements for numerous projects.

Implementation Speed

Applications like QlikView and Tableau have the fastest implementation timelines in the BI area, and in fact these implementation timelines are so fast that it is curious why this is not more obvious and more embarrassing to many of the old-line BI companies. Again, we have to assume that the major consulting companies have a hand in keeping their clients from knowing about QlikView and Tableau as they would seriously cut into their BI consulting business. IBM does not want its customers to benefit from these new approaches, but instead wants to sell Cognos, and then spend many months billing its clients so its consultants can talk in circles about dimensions and keys, and dicker with one of the lowest productivity BI environments in existence.

Another interesting feature that is not discussed enough is due to these fast implementation timelines how quick the applications begin earning returns for the company. Presently, there is a narrative that is employed by BI Heavy software vendors, and it is to dismiss the implementation accomplishments of the Light BI software vendors. It goes something like this..

Sure you can buy Tableau and bring up some reports quickly, but pretty soon you will find that the application does not scale.

We have heard quotes like this so many times, it is becoming a cliché of how to try to distract buyers from the clear advantage these new applications offer. This is simply false information. Tableau and QlikView are currently implemented in companies and providing analytics for extremely large data sets. Furthermore, the feedback that we are receiving on the applications is extremely positive. Furthermore, the adoption level of several of the Light BI applications is the highest in the BI and by substantial margins. This is the most important story in BI, and buyers should not accept these attempts to poison the well by the Heavy BI software vendors, or their partners in crime, the major consulting companies.

Therefore, we have the evidence the BI Light software offerings as the best values in the market – our TCO analysis of all of the BI vendors bears this out. One strategy that we have been proposing is that companies with a BI Heavy solution already buy a BI Light solution and begin to replace some of the functionality in which the BI Heavy solution is weak and the BI Light solution is strong. Due to the low productivity of BI Heavy solutions in exactly the type of things that BI Light does well, companies should be able to recoup the cost for these solutions in IT and consulting costs, as well as delivering much more satisfied business users.

Estimating The “Live” Duration for BI

One of the complicated factors with respect to BI is how long to set the duration the application is “live.” This is the time between the go live and when the application is decommissioned. Unfortunately, BI Heavy versus BI Light applications have different average live times, because once a buyer commits to a BI Heavy application, it is more reticent to switch to a new BI platform. This is not a positive, because high application switching costs mean a higher potential of being trapped in an application that is not meeting the requirements. Plenty of buyers that we talk to are currently trapped in low productivity BI platforms/applications that were purchased without having sufficient experience with the application – often at the recommendation of a major consulting company. The reports that were promised by IT are slow to arrive, and it is a serious point of contention in many buyers. This is of course also a common problem with the number one “lock in” application in enterprise software, ERP systems.

BI Heavy applications not only take longer to go live, but take longer to provide higher percentages of the buyer’s reports/dashboards etc.. BI systems are a bit different than other enterprise software categories in that the output is delivered more over time, with increasing number of reports/dashboards becoming available as time passes. Many software vendors propose a much faster go live than we have listed in our calculations, but producing a small number of reports quickly does not means that the BI system has met “requirements” if the vast majority of reports are still outstanding at the point of measurement. Currently we use 10 years as the lifespan of BI Heavy applications and 7 years for the lifespan of BI Light. However, the longer implementation timeline of BI Heavy applications as well as this slow rise of BI Heavy output should be considered so that when a BI Heavy application is at full strength is often considerably postponed after the go live date.

The Growth of SaaS BI

SaaS BI is proving to be so efficient that companies must now make a decision whether they want a high cost on premises solution and lose out on a host of features and the productivity gained from having more and better reports. With solutions like Birst, companies are in a better position to make better decisions than in the past. Birst is a strange bird, it actually is a data warehouse, but is also in the cloud. This is another example of how the BI landscape is changing from the old rules that it used to follow.

The Growth of Mobile BI

Related to SaaS BI, mobile BI is the ability to show reports on any number of mobile devices. This is still an emerging area, and its unclear to us how prominent this will actually be versus the hype. There are several areas of industry, such as the medical industry where mobile BI is already deployed, and where its benefits are unquestioned. However, for most other industries the PC is still the dominant form of report consumption.

Future of BI

This space is ripe for more acquisitions. Oracle, IBM and SAP made major acquisitions in 2007 and as these companies do not invest in acquired products and are incapable of innovation due to their size and bureaucracy, these acquired applications are seriously out of date and are headed towards being sunset-ed. As is coved in the individual BI MUFI ratings available from the following links, several of these applications should really no longer be sold. These conglomerates can easily purchase a prime target such as QlikView, Tableau or Birst, and have leading technology for a few years. It will also allow them to kill competition and then talk about their dedication to innovation to the business press.

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

 

Software Category Analysis – BI Heavy

Introduction

Business intelligence or BI was initially meant to mean the applications that could be accessed by business users. However, the term has morphed into a catchall term which covers a variety of technologies which include reporting, OLAP, analytics, data mining among others. The BI field is filled with different technologies and subdivisions, which makes it one of the more confusing software categories to drive to clarity on. In fact, this even complicated our software selection packages and software project planning analysis because while other software categories will have a single product name, most of the BI solutions offered are a variety of suites, with differently named suite applications.

The term BI had its origin in a 1958 paper by an IBM researcher where he employed the definition of intelligence. Therefore, it is really data that leads to insight – which of course is a very broad term. Everything that we now think of as BI has simply developed from that original idea, but it how encompasses specific types of applications. A BI application may or may not rely upon a data warehouse, and in fact may rely upon a data source.

BI is one of the faster growing categories of enterprise software. However, the growth is very different depending upon the category of BI software vendor. The large BI software vendors (Oracle, IBM, SAP and to a lesser extent Teradata) are seeing moderate growth, and with newer and more self service software vendors (QlikView, Tableau, Birst) seeing very rapid growth. The growth leader currently is Tableau, an application that is quite deserving of this growth.

Our Approach to Analyzing BI

As part of our research process, we perform a literature review, which means reading the reports of other analysts. In these reports we have noticed these use of many descriptors related to the data technologies employed. For instance, there is a lot of discussion of whether an application uses and in-memory database. For us, the particular approach used by the vendor is simply the input to the output of the analytics, reports, etc.. There are software vendors like SAP and Oracle that are putting data into in-memory databases in order to make a splash at conferences, that don’t have anything to do with improving reporting outcomes. SAP has made a great deal of marketing noise about its HANA in memory database, while having one of the poorest overall BI platforms and while buyer after buyer complains to us about reports that are late or never appear. Therefore, our analysis does not spend much time quoting the underlying technology as this is in our view a distraction to presenting the analysis of how these applications perform in real environments.

Heavy Versus Light Solutions

There is a great deal of debate within the BI market as to which applications fit into which categories. If we got into all of the sub areas of BI we would have to explain statistical analysis tools, predictive analytics, data warehouses, etc – and so we needed some type of shorthand to categories BI solutions. Some applications pull from of other data sources, and do not offer a data warehouse. This means they cannot be compared in terms of price or broadness of functionality with tools that can pull from data sources by are not data warehouses. However, on the other hand – there is a debate as to how necessary a data warehouse actually is. We know many buyers for which a data warehouse is overkill. The data warehouse philosophy has been prevalent for decades, but it generally did not lead to the availability of information that was predicted or promised. It essentially creates a heavy infrastructure load, which regardless of whether on is pro or anti data warehouse it is difficult to see how the following should not at least be acknowledged that

  1. The data warehouse was never able to achieve the productivity necessary to meet the promises that were made for the approach to managing data (now the debate begins as to why which is where all the arguments begin).
  2. Data warehousing projects are extremely time consuming and expensive.
  3. Many buyers are currently saddled data warehouse software and an overall set of BI applications that they are unwilling to staff sufficiently to get the value out of these platforms.

In fact, one of the tricks to getting a well priced and good performing overall BI solution find BI Heavy and BI Light applications that can work well together and that are efficient to run. This point is critical because so many BI Heavy applications or suites of applications are inefficient to actually run, and too many buyers end up with BI Heavy applications, which overwhelm their ability to support them. (Our estimations for resourcing BI Heavy applications/platforms are significantly higher both for support as well as for the implementation over BI Light applications/platforms)

Debates on the topic of data warehousing are eerily similar to a group of people who have a great deal of their career invested in a philosophy, and are reticent to admit that it has not done what it said it was going to do. It is true that centralized “single source of truth” data warehousing makes sense as a principle, but technology merits are not the only thing that counts. Data warehousing also means getting agreement from many different entities in companies that are self centered, and can easily lead to a tragedy of the commons – which as much as technology is why data marts became prominent. Furthermore, a Inmonesque data warehouse is a high standard requiring a high level of planning and discipline, and not every buyer is up to the task. These factors, which goto the limitation of the Inmonesque data warehouse were behind the growth of several areas in BI, including the analystics appliances like Exadata and Netezza.

Because we cover so many areas in enterprise software, we can see similarities in the argumentation over various technology debates, and other areas such as service oriented architecture (SOA) which was heavily hyped and did not have really any impact in how IT. This is the strong tendency to ever declare any approach to be invalid or flawed, and in particular companies that have a revenue stream, which is derived from one, or another approach will never admit that approach has not worked. They will argue instead that the approach has simply not been implemented correctly – and this can go on for decades. We refer to this as the Evergreen Syndrome. That is no IT idea – if it is profitable for some parties — ever dies, it simply fades from view.

BI Becomes More Responsive

In the last few years, and for probably the first time as a broad trend (one of the historical exceptions being Crystal Reports), software vendors have developed applications that are just as focused on ease of use as the technology. Prior to this, BI vendors have been developing difficult to use products, and then buyers have been wondering why they have low report development productivity and low user adoption and satisfaction. This shows in which BI software vendors are able to satisfy buyers. The big software vendors with “complete” solutions like Microsoft SQL Server, SAS, SAP, Oracle and IBM all score poorly in satisfaction. This leads to a very important point.

There is No Single BI Vendor which is a One Stop Shop

For many years, having a complete solution has been presented as a reason to by from one vendor over another. These software vendors have made large numbers of acquisitions and attempted to integrate these various technologies into a coherent offering – and it has not worked. The BI Heavy vendors that offer “total solutions” such as IBM, SAP, MicroStrategy are overbearing in their insistence that their solutions be used in their entirely – declaring their unwillingness to be used in conjunction with other applications that are all of course inferior to theirs. Buyers that engage any of these vendors will be beset by condescending BI consultants and sales reps that will drone on – in a difficult to monotone and interrupt manner about how their solutions have been designed from the ground up to work as a complete suite. With the exception of just a few vendors like Actuate and SAS the other BI Heavy vendors are intent on employing account control techniques to take over a buyers’ overall BI spend.

The logic for attempting to find a one stop shop is just not there. All of the BI Light software vendors can connect to literally any data source – and software vendors that propose they are providing some major value add by combining front and back end BI elements to buyers are practicing make believe. They are cutting off options for the buyer under the rubric of “adding value.” This is why buyers should not attempt to get all of their BI needs from a single vendor. The larger BI vendors as a group have a long history of misrepresenting how much training and effort is required to effectively use their applications. This is a feature that generalizes across enterprise software categories, but it has been a particularly problematic issue large vendor BI.

Heavy and Light BI

There are a variety of terms that is often used to describe different categories of applications in the BI software category. However, we categorize all BI solutions as either “BI Heavy” or “BI Light.” In many cases the BI Heavy solutions contain a data warehouse. Below we have assigned each vendor that we have classified as one of the other.

SAP Crystal Reports Introductory Series_ The Report Wizard - YouTube

Beyond this simple graphic there are still important distinctions between the applications. For instance, some vendors like Teradata, which makes one of the most heavy duty data warehouses would debate if other software vendors that we designate as BI Heavy should be categorized as such, so there is a level of debate even among this basic segmentation. BI tends to be a contentious software category with many strongly held opinions. For decades there was a strong disagreement between two different philosophies of data warehousing called the Inmon (Corporate Information Factory and Top Down) versus Kimball-Bottom Up debate (hint the Kimball data mart approach proved more attainable by most companies).  

Companies need to decide what they are actually buying, and should not simply based upon conventional wisdom or the investment one has in one or the other approach. Not all companies need BI Heavy applications. And how one evaluates a BI Heavy versus BI light application is quite different. For instance, IT holds most of the decision-making power when it comes to which BI Heavy application to choose, however, the business users should have most of the decision making power when it comes to BI Light applications. As with ERP, the tendency in buyers has been to try to consolidate requirements into one software vendor, however this is a failed strategy for BI software selection.

Most of the suites from the big BI vendors are really just a hodgepodge of applications from acquisitions. A perfect example of this is Business Objects, BI/BW and Crystal Reports (in this case two of the applications were acquired by SAP, and one developed internally). SAP frequently makes the case that these acquisitions were strategic and create synergy. In the case of Business Objects, this was a competitor that was beating BI/BW in head to head competitions. SAP was able to remove this competitor through acquisition – thus enabling it to increase the price of both applications. SAP has done very little to integrate Business Objects into the their BI “solution.” It’s just a product that is owned by SAP to enhance its monopolistic power. Is the fact some mega vendor needed to eliminate a worthy competitor and to reduce the price pressure a reason to buy an application? We don’t think so.

“Self Service” BI

One of the biggest trends in BI has been the move to so called “self-service.” The efficiency of IT with regards to report creation has been well understood to be poor, with literally applications like SAP BI and IBM Cognos pulling the life force out of the business with late reports, or reports that are provided that do not meet the business requirements. The support ratios for many applications in business intelligence are so high that they are driving buyers to applications with lower support ratios. IT is in a conundrum with respect to BI. They have a natural inclination to want to control BI, to choose the solution, but on the other hand, they are tired of being beat up for reports being late – a perpetual issue at most buyers that we interact with. However the term self-service is a heavily marketing laden term. None of the applications that are often called self-service are actually self service to the extent that they actually do not require significant training and hand holding. Applications which are described as self-service by the business press and by software vendors and IT analysts like Gartner – are simply lower support requirement applications.  It is no coincidence that applications of this type, such as QlickView and Tableau have the highest buyer satisfaction levels as well as the highest user adoption levels in BI. We have an example from one of the main self-service applications, which is Tableau.

Tableau Self Service

Software vendors tend to show finished reports like the one above. This provides a misleading impression as to the skill necessary to create these reports. Tableau is a great BI Light application, however, there are a ton of options. Tableau simplifies some of the decisions with its Show Me option in the upper right hand corner, which greys out chart types that do not apply to the data. Another major functionality which encourages self-service is the back button in the upper left corner. This allows a user to experiment and then return to the earlier state. It is also a multi-back button, so multiple changes can be made to a report and then all of these adjustments can be undone returning the report to its earlier pristine state.

However, In addition to deciding what measures or dimensions are pulled to the row and column, each measure and dimension has a drop down which changes how it is used by the application. Another factor to be adjusted is whether the data will be summed, counted, etc. All of this takes considerable experience and that is simply to create the report – there is more work in knowing what data to pull into Tableau.

Tableau Data Pull

Self service applications make a big splash about how easy it is to pull data into them. Tableau does offer many different connections to different data sources, however, have these already been setup by IT? Will IT connect to the proper IT sources? Will the business need to do some of this work themselves if IT is slow to do so?

Tableau Health Care

Notice in this report the AVG Heath Care and Average Life Expectancy is assigned to the Columns, Rows, as well as the Filters and to the Marks area.

Tableau Health Care 2

We can adjust this by placing the AVG GDP in $ measure into the column and removing the previous entry. This changes the relationship shown but keeps the overall chart the same. This was easy for us to do. This is probably the better application of self-service applications – that is having an overall report structure created, but allowing the users to make changes to what is shown in the report.

Tableau Cost Per Life Span

We consider Excel to be a true self-service application, and by that measurement, all BI applications we have evaluated fall short of that. These applications are much more powerful than Excel. However, it is certainly worth it. This report shows that the United States pays an exorbitant amount of money for it life expectancy, and that this the overpayment has very significantly increased since 2001. But one can’t have it both ways. One cannot expect BI applications that can produce sophisticated and nuanced report output, and then on the other hand expects this output to be entirely self-service.

While in the past BI Heavy applications were the most widely purchased, this is beginning to change – as is explained in this quotation from Forrester.

“However, anecdotal evidence leads us to believe that with the proper BI application portfolio classification, no more than 20% of all BI applications should fall into this restricted category. We maintain that in an ideal BI environment, 80% of all BI requirements should be carried out by the business users themselves.”

When we evaluate new implementations it is amazing to us how often the reports come in 6 months to 12 months after the application has been live. For all the talk of advanced techniques and data warehousing, it is amazing to us how poor the selection of reports actually is and many buyers. We have to question why this is not more widely understood. Why do so many journalists and IT analysts accept the promise of BI over the reality of BI? The major software vendors have large investments in BI Heavy applications/platforms and major consulting companies have major investments in resources, toolkits and training in BI Heavy applications – the consulting companies and IT analysts are doing a thorough job of hiding the obvious productivity enhancements that are being provided by BI Light solutions from their customers.

Reporting is the ultimate example of “selling the future.” In our observations BI only meets its potential when IT is taken off of the train tracks for creating reports, and simply maintains the backend, allowing the business users to build their own. There are a number of reasons we believe this, but one being a study of the history of BI, and a second being our participation in the gathering of reporting requirements for numerous projects.

Implementation Speed

Applications like QlikView and Tableau have the fastest implementation timelines in the BI area, and in fact these implementation timelines are so fast that it is curious why this is not more obvious and more embarrassing to many of the old-line BI companies. Again, we have to assume that the major consulting companies have a hand in keeping their clients from knowing about QlikView and Tableau as they would seriously cut into their BI consulting business. IBM does not want its customers to benefit from these new approaches, but instead wants to sell Cognos, and then spend many months billing its clients so its consultants can talk in circles about dimensions and keys, and dicker with one of the lowest productivity BI environments in existence.

Another interesting feature that is not discussed enough is due to these fast implementation timelines how quick the applications begin earning returns for the company. Presently, there is a narrative that is employed by BI Heavy software vendors, and it is to dismiss the implementation accomplishments of the Light BI software vendors. It goes something like this..

Sure you can buy Tableau and bring up some reports quickly, but pretty soon you will find that the application does not scale.

We have heard quotes like this so many times, it is becoming a cliché of how to try to distract buyers from the clear advantage these new applications offer. This is simply false information. Tableau and QlikView are currently implemented in companies and providing analytics for extremely large data sets. Furthermore, the feedback that we are receiving on the applications is extremely positive. Furthermore, the adoption level of several of the Light BI applications is the highest in the BI and by substantial margins. This is the most important story in BI, and buyers should not accept these attempts to poison the well by the Heavy BI software vendors, or their partners in crime, the major consulting companies.

Therefore, we have the evidence the BI Light software offerings as the best values in the market – our TCO analysis of all of the BI vendors bears this out. One strategy that we have been proposing is that companies with a BI Heavy solution already buy a BI Light solution and begin to replace some of the functionality in which the BI Heavy solution is weak and the BI Light solution is strong. Due to the low productivity of BI Heavy solutions in exactly the type of things that BI Light does well, companies should be able to recoup the cost for these solutions in IT and consulting costs, as well as delivering much more satisfied business users.

Estimating The “Live” Duration for BI

One of the complicated factors with respect to BI is how long to set the duration the application is “live.” This is the time between the go live and when the application is decommissioned. Unfortunately, BI Heavy versus BI Light applications have different average live times, because once a buyer commits to a BI Heavy application, it is more reticent to switch to a new BI platform. This is not a positive, because high application switching costs mean a higher potential of being trapped in an application that is not meeting the requirements. Plenty of buyers that we talk to are currently trapped in low productivity BI platforms/applications that were purchased without having sufficient experience with the application – often at the recommendation of a major consulting company. The reports that were promised by IT are slow to arrive, and it is a serious point of contention in many buyers. This is of course also a common problem with the number one “lock in” application in enterprise software, ERP systems.

BI Heavy applications not only take longer to go live, but take longer to provide higher percentages of the buyer’s reports/dashboards etc.. BI systems are a bit different than other enterprise software categories in that the output is delivered more over time, with increasing number of reports/dashboards becoming available as time passes. Many software vendors propose a much faster go live than we have listed in our calculations, but producing a small number of reports quickly does not means that the BI system has met “requirements” if the vast majority of reports are still outstanding at the point of measurement. Currently we use 10 years as the lifespan of BI Heavy applications and 7 years for the lifespan of BI Light. However, the longer implementation timeline of BI Heavy applications as well as this slow rise of BI Heavy output should be considered so that when a BI Heavy application is at full strength is often considerably postponed after the go live date.

The Growth of SaaS BI

SaaS BI is proving to be so efficient that companies must now make a decision whether they want a high cost on premises solution and lose out on a host of features and the productivity gained from having more and better reports. With solutions like Birst, companies are in a better position to make better decisions than in the past. Birst is a strange bird, it actually is a data warehouse, but is also in the cloud. This is another example of how the BI landscape is changing from the old rules that it used to follow.

The Growth of Mobile BI

Related to SaaS BI, mobile BI is the ability to show reports on any number of mobile devices. This is still an emerging area, and its unclear to us how prominent this will actually be versus the hype. There are several areas of industry, such as the medical industry where mobile BI is already deployed, and where its benefits are unquestioned. However, for most other industries the PC is still the dominant form of report consumption.

Future of BI

This space is ripe for more acquisitions. Oracle, IBM and SAP made major acquisitions in 2007 and as these companies do not invest in acquired products and are incapable of innovation due to their size and bureaucracy, these acquired applications are seriously out of date and are headed towards being sunset-ed. As is covered in the individual BI MUFI ratings available from the following links, several of these applications should really no longer be sold. These conglomerates can easily purchase a prime target such as QlikView, Tableau or Birst and have leading technology for a few years. It will also allow them to kill competition and then talk about their dedication to innovation to the business press.

MUFI Rating & Risk

Our MUFI Rating and Risk rates the application and applies a risk analysis or risk factor.

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

Software Category Analysis – Small to Medium ERP

Introduction

ERP implementations are high-risk affairs. Much of the ERP functionality difficult to implement, many of the vendors are offering dated technology – that if it were not for how the word “legacy” is controlled by software vendors and consulting companies would be called legacy. (Hint, legacy is a term of propaganda, and can only every be used to label a system one wishes to replace – never to a vendor’s software.) One of the major complaints of ERP clients is that their ERP vendors have stagnated while buyers keep paying high yearly service charges.

The unfortunate, if under-reported fact is that many years after most ERP systems go live, it is difficult to demonstrate the return on investments from them. This story is of course worse if buyers buy expensive ERP systems. Of all ERP categories, tier 1 ERP are the worst values – and the common logic presented that only tier ERP systems have the functionality for the complexities of large companies is not true. The actual costs of ERP systems are covered in our TCO Estimation for ERP, as well as in our Solution Architecture Packages. Several up and coming ERP vendors are far more competitive along all the decision making criteria in which we measure and score ERP software, and the fact that it is now easy to find stand alone financial applications that are superior to the financial modules in any ERP system is taking the wind out of the shopworn “ERP is necessary” argument. Furthermore, some of the best applications are – while not the least expensive, are towards the less expensive end of the spectrum.

What the Research Says About Risk Implications of ERP

ERP implementations are generally known as risky, but this does not seem to influence the software selection process. This is unfortunate as the risks vary depending upon the application selected. Only rarely is the actual success rate of ERP implementations quoted. According to the publication The Critical Success Factors for ERP Implementation: An Organizational Fit Perspective, the success rate is roughly 25 percent. So, according to this source, 75 percent of ERP implementations are considered failures. But quoting just one study is misleading because the estimates are truly all over the map, as the following quotation attests.

“A study by the Standish Group estimates that 31 percent of projects are not successful (Kamhawi, 2007). Barker and Frolick (2003) suggest that 50 percent of ERP implementations are failures. Hong and Kim (2002) estimate a 75 percent failure rate, while Scott and Vessey (2002) estimates failure rates as high as 90 percent. Different statistics for the success or failure of ERP projects have been offered by researchers. In addition Bradford and Sandy (2002) reported that 57 percent of the companies they interviewed had not attempted to assess the performance of their ERP systems owing to a lack of empirically effective evaluation models.” – Measures of Success in Project Implementing Enterprise Resource Planning

One of the most ridiculous arguments we have heard is that (particularly from the tier 1 ERP vendors) ERP implementations are so difficult that companies that manage to pull them off gain a competitive advantage over other companies. In this incarnation, the ERP system is presented as something akin to the Ironman Triathlon where the implementing company proves its toughness by running the gauntlet. It is an interesting analogy, which as far as we aware is unique in the field of enterprise software where ease of implementation—rather than difficulty of implementation—is traditionally considered a virtue. And in fact, the argument is edging extremely close to circular reasoning: ERP is virtuous because it is difficult to do, and it is difficult to do because it is virtuous. It is also the only time we can recall that a high failure rate is presented as a positive attribute of a software category.

ERP as “Just Another Application”

This transition of ERP from the center of the IT solution architecture is almost never written about or discussed (one of the few exceptions is in an article from Tech Target, who’s reference is show below) however, ERP is not nearly as influential or critical to the IT solution architecture as it once was. After bringing about a period of relative centralization (we say relative, because many of the “legacy” systems that ERP was supposed to eliminate never went away because ERP systems lacked the functionality to replace them), solution architecture has decentralized. And every year the scope of ERP shrinks and companies bring up less ERP functionality, and look for better functionality outside of ERP systems.  In fact, CRM has been forecasted by Forbes to surpass ERP in revenues by the year 2017. This is the first time that any other category of enterprise software has even come close to ERP sales since ERP was introduced back in the 1980s.

Interestingly even when this issue has been brought to the surface, such as with the Tech Target article, the coverage is notable for what is left out. Curiously, they quote Gartner about the future, the firm that coined the term “ERP” — and has historically been one of the big cheerleaders on big ERP. Gartner was one of the pied pipers that lead companies to these bad big ERP purchases on the basis of what has turned out to lack a strategic and technological foundation. This leads to the next section. The question being which of the ERP vendors can effectively support the new reality of ERP not longer being the center of the solution architecture.

Finding Flexible ERP Software Vendors

Buyers should look at ERP systems as an a la carte menu. In our Solution Architecture Packages we compare the TCO of multiple alternatives.

Buyers have all types of options; each should be evaluated on the basis of its TCO as well as the functionality match to the buyer’s requirements. These estimators will be quite a surprise to the vast majority of buyers, because our analysis shows that the only losing strategy is to choosing the recommendation of all the major consulting companies and center their solution architecture on a tier 1 ERP system. Not doing this means the buyer comes out with a far lower overall TCO and with far better functionality – resulting in a much higher ROI.

Some ERP software vendors are comfortable not being the center of the IT solution architecture and other are not. This indisputable final outcome of ERP is the opposite conclusion to a the ERP trend as predicted by every authority on ERP (primarily SAP and Oracle, consulting companies, IT analysts). They were supposed to be the experts on this topic, but they all had a major flaw – they all had a financial bias, making their forecasts invalid. See our Software Selection Packages to learn all about the effects of financial bias on forecasting. This makes dealing with SAP and Oracle in fact dangerous for buyers because they are proposing the continuation of a strategy that calls for a large and expensive ERP system, which is the center of the IT solution architecture continually consuming a large percent of the IT budget.

This strategy has never worked as the evidence from research that has been performed shows a negative return on investment from larger ERP solutions. (Tip: any entity that proposes that ERP has a positive ROI, simply ask them to produce the independent research study) The evaluation of the research on ERP systems is explained in fine detail in the SCM Focus Press book The Real Story Behind ERP: Separating Fact from Fiction.

On the other hand, other vendors, examples being ProcessPro, Rootstock and ERPNext never operated from this point of view, and are happy to have their system implemented as part of any solution architecture strategy desired by their customers – they are not practicing account control by selling an ERP system. Instead they have always considered themselves providing low cost ERP, and just one system as part of an overall ecology than can be the center or any fit with their customer’s solution architecture that the customer desires. These are the types of ERP vendors that buyers should seek out, as they provide not only the best software in ERP, but also the best ability to partner with, rather than seeking to control their customers. Another major advantage of purchasing from a software vendor that only makes ERP software is that buyers will not relentlessly pitched other products by these software vendors sales reps.

Tier 1 ERP is in the Price Gouging Phase

Oracle and SAP have put very little back into their tier 1 ERP products for roughly 15 years, and as a result the applications are seriously dated. However, their support costs continually increase. This is the negative consequence of software “lock in.” In fact it is estimated that Oracle receives up to a 90% margin on its ERP service contracts. Many buyers have felt the pinch as the following quotation suggests.

“When you put in a $40 million or $50 million ERP package, it’s difficult to have an exit strategy without causing a lot of pain. They know that, and so they increase our costs every year,” he says. Therefore, Steinour says he would like to lay the groundwork for a more strategic approach.” – ComputerWorld

If buyers could wipe the slate clean, we have concluded it is unlikely SAP or Oracle could rebook a high fraction of the customers it currently is receiving ERP support revenues from. Interestingly, the fact that one makes oneself extremely susceptible to the power of their supplier when they concentrate their purchases with a single software vendor was not brought up by any of the supposed experts that were promoters for big ERP. Hold you breath, because one of the major logics presented by ERP vendors, consulting companies and IT analysts was that ERP systems would reduce IT costs.

The Growth of SaaS ERP

Something, which we see as a strong future growth trend, is SaaS ERP. Consulting companies and non-SaaS software vendors have been proposing that SaaS should not happen for “core” applications, however their arguments are simply conveniently connected back to their financial models. SaaS for ERP is bad for them, but it is a good idea for their clients. It’s just that they don’t have SaaS applications to sell. Because they have no SaaS applications, to sell, their advice to customers is to only use SaaS for “non core” software like CRM.

SaaS ERP should begin at the smaller end of the company size spectrum and move its way up. SaaS solutions are particularly attractive for smaller companies and even for midsized companies that have under performing tier 2 ERP applications. There are several very good alternatives. One of our favorites being ERPNext. These systems are easy for both experienced and novices to use because the business process is clearly explained right in the application.

Software Category Summary

The complete story on ERP is quite clear, it is simply not communicated to buyers because it’s more profitable to promote big ERP, rather than communicating accurate information on the topic. ERP systems never provided much of an ROI to buyers, and our research provides a logic for why when accounted for correctly, the ROI for most ERP systems has actually been negative. This research cannot be presented in a few paragraphs, but is presented in its complete form in the SCM Focus Press book, The Real Story Behind ERP: Separating Fact from Fiction. However, buyers don’t have to accept negative ROI ERP implementations, and the best way to control for this is to select better and less expensive ERP systems, which have better functionality, can be implemented more quickly, and are not so difficult to integrate to other systems that they create negative externalities on the overall solution architecture. There are several good applications to choose from that meet all of these criteria.

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

References

http://searchfinancialapplications.techtarget.com/feature/Is-ERP-technology-going-nowhere-or-everywhere