ERP. On Demand

Understanding SaaS Enterprise Applications

In spite of the proliferation of discussion about cloud computing, there is still an enormous amount of confusion and misperception about Software as a Service (SaaS) deployment options for enterprise applications. This is often fueled by industry ”experts” and the solution providers themselves using the same terms with different definitions of cloud, SaaS and multi-tenancy. While it is important for buyers and users of enterprise applications to understand the terminology being bandied about, it is even more important to be asking the right questions to make sure their specific goals and requirements will be met. It’s less about the labels and more about the characteristics that are needed to meet these objectives.

Cloud versus SaaS

There is still much confusion over cloud and Software as a Service (SaaS) delivery models and the more discussion in print and online, the cloudier the issue becomes. This confusion prompted Mint Jutras to conduct an online survey to assess the level of understanding of SaaS and determine preferences for deployment models for a variety of enterprise applications. Many use the terms “cloud” and “SaaS” interchangeably, but indeed they are not the same. Therefore in this recent survey of representatives from over 300 participating companies, Mint Jutras was very clear in defining how the two terms would be used in the context of the study. The distinction is quite simple and need not be over-complicated.

As a prelude to the survey and for our purposes here, we use the following definitions:

  • Cloud refers to access to computing, software, storage of data over a network (generally the Internet.) You may have purchased a license for the software and installed it on your own computers or those owned and managed by another company, but your access is through the Internet and therefore through the “cloud,” whether private or public.
  • SaaS is exactly what is implied by what the acronym stands for: Software as a Service. Software is delivered only as a service. It is not delivered on a CD or other media to be loaded on your own (or another’s) computer. It is accessed over the Internet and is generally paid for on a subscription basis. It does not reside on your computers at all.

Using these definitions, we can confidently say all SaaS is cloud computing, but not all cloud computing is SaaS.

 Multi- versus Single-Tenant

Much of the discussion and debate over SaaS enterprise applications focuses on whether the SaaS applications are single- or multi-tenant solutions. In spite of the escalated level of chatter over this distinction, 57% of our survey respondents admit they do not understand the difference between the two. While 34% don’t seem to care (leaving that for others in their company to worry about), 23% admitted to not understanding but asked, “Please explain.”

Because subsequent questions asked about preferences between these two “flavors” of SaaS, it was important to present definitions of both. Again we kept it simple and we did not lead the survey respondents (or the reader here) with a conclusion that one is better than the other. You will find some industry observers that passionately insist SaaS solutions must be multi-tenant in order to be “true SaaS” and some offer quite a long laundry list of conditions that must be met before they will anoint a solution to be what they consider truly multi-tenant.

The definitions presented were much simpler:

  • Multi-tenant SaaS: Multiple companies use the same instance of (hosted) software. Configuration settings will vary per company and data is protected from access by other companies (tenants).
  • Single-tenant (or Multi-instance) SaaS: Each company is given its own instance of the (hosted) software.

These were presented to all survey participants, but for those who indicated they knew the difference, we went on to ask if they would agree with our definitions. The majority (65%) fully agrees with this definition. An additional 31% generally agrees but might slightly modify or add more qualifications. But when asked to present their own definitions we discovered more confusion. Some confuse multi-user applications with multi-tenancy. Others confuse access (presumably through cloud computing) over a distributed environment with SaaS and some voiced opinions on one or both but did not define either. Yet a certain level of understanding is a prerequisite for making good decisions.

Decisions, Decisions: How to Deploy Enterprise Applications

So how are decisions about deployment options made today? For many this is not a singular decision that is applied to all different types of application. Forty-one percent (41%) say the decision will vary from application to application even though many have “standards” defined for either all applications or selected applications (see sidebar). But “standards” can mean different things including which packaged software is selected, master data management, as well as deployment options. The vast majority (93%) feels these standards do however have some impact on deployment options that are chosen and about half (49%) feel SaaS options make standards easier to implement and enforce.

Conflicting Views: The Experts Versus the Consumer

Many experts today insist on multi-tenancy, however this choice has more impact on the vendor than the consumer of the software. Maintaining a single copy of the software instead of a separate instance for each customer means far less cost and effort for the solution provider. These savings can translate to lower cost and/or more innovation for the end user of the software but many of those end users only see the limitations, which they assume multi-tenancy imposes. Few have defined either multi- or single tenancy as a preferred option and single tenancy seems to have a slight lead in consideration.

But is that because they assume limitations of multi-tenancy that may or may not be real? And while the “experts” might be pushing multi-tenancy, is that really the question users should be asking?

Presumably the added efficiency of multi-tenancy allows the solution provider to focus more resources on improving the technology and developing more features and functions, which directly benefits its customers. That translates to more innovation delivered. But if the solution provider makes the same solution available on-premise, the frequency of releases may be constrained by its customers’ ability to upgrade frequently. So perhaps instead of asking whether the solution is multi- or single tenant, the better question is, how frequently is the software updated?

Is there a perceived downside to multi-tenancy? Yes, there can be. Many assume that a multi-tenant environment equates to “plain vanilla” applications that cannot be modified or tailored to their own needs. That may have been the case years ago when customizing software meant modifying source code, but today’s modern technology allows a tremendous amount of configuration and personalization without ever going near source code. So perhaps instead of asking whether the solution is multi- or single tenant, the better question is, what level of configuration, tailoring and personalization is supported?

Another potential concern over multi-tenancy is the perceived loss of control over the upgrade process. Indeed in a multi-tenant environment, the customer often has little control over the timing of the upgrades. However is there really a negative impact? If the solution provider bears the burden of the effort associated with upgrading and innovation is delivered in such a way that the customer may optionally choose to take advantage of an enhancement – or not – then there is no down-side and a lot of up-side.

Yes single tenancy potentially affords you more control over the timing of an upgrade, but there are other ways to exert control. Some vendors will actually support multiple versions in a multi-tenant environment. So perhaps instead of asking whether the solution is multi- or single tenant, the better question is, how is the upgrade process engineered and executed and/or whether all enhancements are designed to be “opt in,” only visible to the users when the customer chooses to turn them on?

These are just some examples of how to ask the right questions to make sure the SaaS solution, whether it is single or multi-tenant, meets your needs. Watch for more highlights about SaaS enterprise applications to make sure you are asking the right questions.

Tagged , , , , , ,

Turning the SAP TechEd messages upside down for the SME

This year’s SAP TechEd was the first to feature an SME (Small to Midsize Enterprise) track. As we wrap up Las Vegas (next stop Madrid), it is time to reflect on the real relevance to SME of the themes and messages presented at TechEd. Much of the event was an excellent presentation of technology, followed by some ideas and examples of how you might use that technology.  That is the way IT departments in large enterprises might approach their IT strategy and budget. And, after all the intended audience for the event was IT in general and developers in particular. But typically there aren’t any developers in small companies and most SMEs have very limited IT staffs. So really the SME audience at TechEd was the partners that service those SMEs.

While these partners were very well represented, can they effectively carry the message to their customers? In order to do that, those partners will have some translating to do, because that’s not how an SME “thinks.” SMEs don’t go looking for technology. They go looking for solutions to their business problems. So can we – and more importantly, the SAP partners turn the messages from TechEd upside down and still make them work for SMEs?

Fellow analyst Laurie McCabe did a great job highlighting the key themes for TechEd (HANA, mobility, cloud / on demand). None of these themes are new. While that makes it harder for those of us in the press and analyst community to find something new and different to “report,” this is actually a good thing for customers and partners alike. Instead of dealing with a different “message du jour” generated for each major even (which some vendors are known to do), SAP is continuing to firm up the foundation upon which they will deliver. The bad news is that some of these promises take a lot of time and effort to deliver, so sometimes it seems like we talk for a long time about what the future deliverables will be without actually seeing them. And while some SMEs might be slower out of the gate to embrace technology as part of the solution, once they do, they are no less impatient to get on with it than larger companies.

So let’s start with the mobility theme. An executive from an SME may not be orchestrating a large, multi-national global enterprise, but they are managing increasingly distributed environments. The Mint Jutras 2011 ERP Solution study found even small companies (those with revenues under $25 million) managed an average of 2.7 operating locations and this number grew along with revenues:

  • Small companies (revenues less than $25 million) : 2.7 operating locations
  • Lower mid-market ($25m – $250m) :                          5.0 operating locations
  • Upper mid-market ($250m – $1 billion):                     8.3 operating locations
  • Large enterprise (revenues exceeded $1 billion):     10.1 operating locations

And executives from smaller companies are just as likely to blur the lines between business hours and personal time, perhaps even more so because of the number of different hats they might wear in managing a small business. In our untethered world of mobile connectivity, we all become more tethered to work even in the “off hours.” And the older generation is now learning from younger generations and becoming more comfortable with specialized mobile consumer “apps.” So mobile access to enterprise data and functions is just as relevant for SMEs as it is for large companies, whether they realize it or not.  

And this access needs to be flexible. In the past large corporations were likely to issue standardized devices (usually a BlackBerry and usually primarily for email, phone and calendaring). Today employees in companies both large and small are buying their own devices and using them for both personal and business purposes and also expecting to do more with them. This creates a need for mobile device management and SAP has a solution for that (Afaria), but this is going to be a tough sell into a small company. Yes, they want mobile access, but they want “apps” not tools to build apps and manage devices and aren’t necessarily willing to pay for that.

In response, SAP is developing mobile apps and recognizes they must model consumer apps. That means they must be smaller in scope and more directly applicable to a particular function. No training required for the user interface and limited training required for the business process it is intended to perform. In some ways these requirements are similar to any business application intended for SMEs. Multi-purpose, horizontal applications, particularly ERP, must accommodate many different functions, and different types of businesses with similar but different business needs. This often introduces a level of complexity that SMEs simply can’t effectively cope with. Some respond by over-simplifying and implementing a solution with limited functionality. But this leaves the business underserved.

Many of these apps that we expect to see delivered by SAP in early 2012 will be mobile analytic applications. These should be of particular interest to SMEs, particularly those that have invested in ERP but have not ventured beyond traditional ERP reporting. By definition, ERP is neither a single purpose nor a simple “app.”  In forming the system of record of the business, ERP is the repository for potentially huge volumes of data that remains largely untapped.

Very often decision-makers themselves rarely, if ever, touch ERP directly, but instead rely on subordinates and/or traditional reporting from ERP for input to decision-making. Not only does this introduce latency, turning real time data into historical data, in relying on traditional reporting, decision-makers have a choice of looking at data in the aggregate at a summary level (that is too high for real conclusions) or wading through so much detail it is impossible to see the big picture. The ability to start at a summary level and drill down to successive levels of detail is becoming more common as a feature within ERP, but being able to do so through a mobile device is very rare. And that might just be the ticket to connecting the executive decision-maker directly to the data on which good decisions are based.

This is where SAP TechEd’s other big “theme” comes into play. HANA is SAP’s in-memory computing engine which is the platform on which these mobile analytics apps are being built. Often HANA and in-memory computing in general is associated with “big data”, which is in turn associated with big companies. But HANA is as much about speed as it is big data. And with speed, it is normal to add more and more data, reaching beyond that which is normally stored in enterprise applications. Think about the enormous potential of useful but unstructured data that is floating out there via the Internet and can be retrieved through search engines and the like. But rarely will you find an SMB that is willing to invest in in-memory computing.

As a result, HANA is not yet a reality yet for most SMEs.  Currently HANA is only available as an “appliance”, which means it needs to sit outside of the SME’s ERP solution. HANA will be certified for SAP BW (BW stands for Business Warehouse) in November but BW is most often found in large enterprises.

And then there’s the cost. While SAP is not disclosing pricing, another fellow analyst, Dennis Moore has pieced together some intelligence relating to cost. Dennis projects the entry level cost for software to be about $120,000. Purchasing HANA on an appliance today brings the projected total to about $250,000 plus services. So a pilot project might start at about $300,000, which is far more than the average small company pays for an ERP solution today.

But SAP intends to “fix” this by putting HANA “inside” both Business ByDesign (SAP’s On Demand ERP) and Business One. While adoption of ByDesign is still nascent, over 32,000 companies run Business One today. By replacing its current underlying infrastructure with HANA as a platform, SAP will have brought this powerful technology to the SME for the cost of their maintenance. Those upper mid-market companies running SAP Business All-in-One, which is built on the same ERP as the Business Suite, will have the option of upgrading to HANA as a platform, but it won’t be free. However, this is still “futures” so SMEs still have plenty of time to imagine how best to take advantage of this new technology, and unfortunately many will not. But they will at least experience some performance improvements as a result, once they upgrade.

Which brings us to the third theme – SAP’s On Demand platform. It is the underlying architecture of SAP’s Business ByDesign that provides this platform, bringing On Demand capabilities even to those that might be running ERP on premise. Software as a Service (SaaS) has made tremendous in-roads in certain functional areas, like Customer Relationship Management (CRM), Supply Chain Management (SCM) and Human Capital Management (HCM) for large and small companies alike. But most companies have a long history of avoiding SaaS ERP.

The barriers of resistance to SaaS ERP are breaking down slowly. One might expect the smallest companies to be most interested in SaaS ERP, but the Mint Jutras 2011 ERP Solution Study indicated just the opposite. When asked which deployment options they would consider if purchasing an ERP solution today, the willingness to consider a SaaS ERP solution actually increased with company size. While 44% of all survey respondents would consider SaaS, only 42% of SMEs (those with annual revenues under $500 million) would, compared to 59% of larger companies (revenues greater than $500 million). Although this is somewhat counter-intuitive, this implies SMEs are more likely to take advantage of what SAP calls its Line of Business (LOB) on demand solutions – applications like Sales On Demand that are more purpose-built for a particular functional area.

This also makes SAP’s plans for an “App Store” all that much more relevant. It is anticipated that this on-line store will allow customers to buy, download and deploy both SAP and partner apps based on the ByDesign platform. This should be appealing to both customers and the partner ecosystem that has grown to sell and support the Business One product, in addition to the ecosystem growing to support Business ByDesign.

And so it would seem there is an SME-specific message to all three of these themes. The challenge for SAP and its partners is to clearly articulate the value as well as the cost and the return on that investment to these smaller companies who continue to anxiously and cautiously watch every penny.

Tagged , , , , , , , , , , , , , , ,

How are you paying for ERP? Here’s how others are.

Back in May I posted some commentary and a warning not to confuse how you buy ERP with how you deploy it. There is much written today about deployment options in general and cloud computing in particular. Although how you pay for ERP is different from the way it is deployed, the two are definitely intertwined because you will either be paying for software or you will be paying for a service or both. This service is not to be confused with the consulting and implementation services you may contract for. This is either software as a service (SaaS) or hosting services, which may also be combined with Application Managed Services (AMS), where the company hosting the software also manages the applications and perhaps even the business processes the software is used to model (e.g. Accounts Payable or Accounts Receivable). But how are companies generally paying for ERP these days?

Just to recap:

Enterprise application software is typically not bought and sold; it is instead licensed for use. It may be licensed to be used by a company, on a particular computer or by other criteria such as number of users. This is similar to consumer software. Buying it once doesn’t mean you can duplicate it and share it with all your friends, or even sometimes use it on all your own computers. For enterprise application software how you pay for that license and the term of the license can vary tremendously.

A software license can be perpetual. Early findings from our Mint Jutras 2011 ERP survey indicate that 76% of responding companies have perpetual licenses. That means you pay for it once and can use the enterprise application forever. Maybe. This used to be the case, but more and more often today a perpetual license agreement might have a stipulation that you have the right to use that software only for as long as you continue to pay maintenance to the software vendor that provides the product. In fact, if you are buying ERP today, expect this requirement to pay a recurring maintenance fee in order to continue to use the software. In our survey 62% of those with perpetual licenses have this requirement.

A maintenance agreement, which is a recurring cost, typically provides both technical support and certain innovations. Some of those innovations will be included in your maintenance fee and others may still need to be purchased. Maintenance is typically priced as a percentage of the software license and the going rate at list price today is around 22% for ERP. While anecdotal evidence tells us that most companies actually pay less than this (closer to 16%-18%) this is largely due to specially negotiated rates and older rates that have not necessarily escalated at the same pace of increased list prices. But if you are purchasing a new ERP solution, expect this to be the starting point for negotiation.

But perpetual licenses are not the only type offered. Instead your license might be for a specific period of time.  This is generally referred to as a “term” license. At the end of the term, you must either renew the license or discontinue use of the software. In fact the application might have the equivalent of a kill switch in it that will disable it and prevent you from continuing to use it at the end of the term.  This type of license is less common and in fact only 7% of our survey respondents indicated this was how they paid for their ERP. Effectively managing this type of license requires some license management code to be embedded in the solution and this was not always done, particularly in older legacy software. If it was not, and you don’t renew, you are in breach of contract and you might find some software auditors on your doorstep.

Subscription-based pricing is another alternative, particularly for those who are looking to expense their investment as an operating expense rather than a capital expense. About 15% of survey respondents pay by subscription. You might pay a nominal startup fee, but you avoid the big front-loaded expense of a software license. Unless this is coupled with a SaaS deployment, this does not necessarily address the up-front cost or the on-going expense of the hardware. Only 28% of the subscriptions paid by our survey respondents were SaaS-based.  Running in a hosted environment where the supporting hardware costs are embedded in the subscription fees may indeed address these capital costs and allow you to account for payment completely as an operating expense.

The findings noted come from the 2011 Mint Jutras ERP Solution study. Look for more data to be shared in the upcoming weeks. If you are in any way involved in the selection, management, maintenance or use of ERP in your company, please participate in our survey. By doing so, you will receive the full executive summary and also have access for inquiry to Mint Jutras for a 6 month period. Your contact info is entirely optional but we will need your email address to deliver your report and an access code for inquiry. Mint Jutras makes it a policy to never share contact info under any circumstances.

To participate click here: 2011 Mint Jutras ERP Solution Study Survey.

Tagged , , , , , , , , , , , , , ,

Can Your Small Business Afford ERP? Part 2 of 3

This is the second of a 3-part series exploring the question many small companies ask themselves: Can we afford ERP?  If you missed Part 1, click here.

What is holding you back?

ERP often gets a bad rap. Many industry observers focus on failed and expensive implementations that never seem to end, thereby tending to scare small companies away. The goal of ERP is often cost savings, but you initially need to spend money (and time and effort) in order to save money. Focusing exclusively on the cost of ERP, even the Total Cost of Ownership (TCO), will not overcome the initial reluctance to invest. Instead, any company (large or small) investing in ERP needs to cost justify the expenditure by estimating the return on that investment, either in terms of dollars or time to recoup the initial investment, or both.  These savings can be as diverse as the companies themselves.

Often the timing of the investment can be critical. Undoubtedly, many small companies were reluctant to take on this type of project and fund this level of investment during the economic downturn. With revenues down or stagnated, they could potentially wait until better times were upon them. But now, as companies begin once again to develop growth strategies, further delay involves further risk. Waiting until you can’t operate effectively without it can spell disaster.

Why is now the time?

There has never been a better time to consider upgrading your technology. Whether your goal is to support anticipated growth or simply to work more efficiently and productively, several market factors converge to signal now is the time.

Price and Accessibility

First of all, prices have come down, making ERP more affordable than it has ever been. Not only has the price of entry come down, but the process of evaluating alternatives no longer needs to be as disruptive as it has been in years past. Online materials, testimonials and demos and even trial software make it much easier to perform some preliminary qualification through your own research before you ever make contact with a software solution provider.

More Innovation and Functionality

But don’t make the mistake of thinking you already know all there is to know about an ERP product based on web site tours and old or presumed knowledge. In the past several years many of the top ERP solutions have made enormous strides in terms of underlying technology and that technological infrastructure brings better ease of use, faster innovation and more features and functions. The “horizontal” core functionality of traditional ERP solutions has become more of a commodity. “Horizontal” implies features and functions any business requires. But you also may need industry specific “vertical” functionality which means all ERP solutions are not “one size fits all” applications.

When evaluating options look carefully to see how that added functionality is delivered. Unless you are looking at a very narrow, niche solution, it is highly likely to serve multiple industries. Look not only at features,  but also determine how your specific needs are met and whether this introduces an added level of complexity to the solution. This need not be the case. Many solutions today can be pre-configured with implementation templates and best practices. Look for role-based interfaces and configurable dashboards and navigation trees that can be tailored to individuals.

More Configurability, Less Customization

Even horizontal solutions today come with more tailor-ability and configurability. Solutions that may have required heavy customization to meet your needs just a few years ago have undergone major transformations that will help you transform your own business. In the past you may have had to choose between adapting your business processes to match the functionality of the software, and adapting the software to conform to your current practices. Today user interfaces can be tailored to roles and individual preferences and business rules can be established to customize work flows and processes without ever having to muck around in the underlying software code.

 This is an important characteristic, even if you do not require any specific customization today. In a world where nothing is constant but change, plan on your business needs changing over time.

Case in Point: Bamboo Pipeline

This was the case for Bamboo Pipeline, one of the largest suppliers of plants to landscape professionals in the western United States, delivering over 10,000 varieties of plants and trees along with a full range of other landscape materials directly to job sites, often within 24 hours.

The business was co-founded by Matthew Fay and Mike Cornell in 2000. From the very beginning the company had an IT infrastructure and an ERP solution borrowed from another business owned by one of the founders, but it was what Mike Cornell, Executive Vice President described as a “blue screen” character based system that couldn’t handle the growing velocity of transactions that accompanied the fast growth of the early years of the company.  Bamboo Pipeline’s revenues had doubled on average every two years, making it one of the fastest growing suppliers of landscape materials in the USA. Annual revenues increased from $5.7 million in 2004 to $11 million in 2006. Revenues were projected to be in excess of $15 million projected for 2007 when the company, poised for national expansion, decided to replace its legacy ERP.

Mike Cornell and his team selected SAP Business One to support this explosive growth saying, “Modern ERP systems for small companies provide a non-trivial step up in providing efficiencies. There are explicit and implicit economies which free you up for growth and help you absorb change. The economic argument for it initially was to anticipate growth and also to anticipate what we couldn’t anticipate. “

While Bamboo Pipeline realized 47% compounded annual growth up until 2008, nobody anticipated the effects of the housing bust that accompanied the financial crisis that occurred late that year.

“At that point the role of ERP changed. Instead of fueling growth it instead became a shock absorber.  Anyone in business long enough knows that growth and decline in revenue are relatively predictable through sound business management. But what you can’t predict can produce a very rapid discontinuity in your business – the housing decline, shortage of commodities, tsunamis, hurricanes, a spike in prices.

In the absence of a system that allows you to see changes in the business and respond with state of the art precision, it’s like playing the game with one hand tied behind your back.

 “We were in the midst of trying to manage change and a decline in revenue. However, because our technology platform was configurable and adaptable, we were able to very quickly add a whole new line of business. While in the past we had simply sold to landscapers, our new Plants Express business (www.plantsexpress.com) allows us to sell direct to consumers through a partnership with Home Depot. We started with an eight store pilot and now we are in 130 stores. This went from 0% to 30% of our business and we launched it with $0 investment in technology and one new employee. If we had needed to buy new technology we probably would not have been able to do it. Nobody was lending money. Having it in place allowed us to launch this new side of the business. It removed labor capacity as an obstacle and provided efficiency for bottom line survival.”

As a result, Bamboo Pipeline preserved revenues throughout the downturn in the economy but improved margins each year. “Our technology driven business model, enabled by our ERP solution, was a large contributing factor.  It is why we are still in the game. If you find yourself coming out of the downturn but are still gun shy, or perhaps thinking about growth and wondering if the investment will pencil, a well-executed ERP system provides a shock absorber for macro-economic issues out of your control. We are now back in growth mode and just hired seven new employees.”

Ease of Use

Another reason the time is right is improvement in ease of use, particularly in those ERP solutions designed with the small company in mind. In some cases the complexity inherent in applications designed for large multi-national companies has been removed. In other cases it has been masked, effectively shielding the small company from dealing with many of the decisions and features that are the exclusive domain of large enterprise. And in other cases, complexity was never built in.

The added ease of use can often be attributed to more intuitive interfaces. Many have the same familiar Microsoft Windows look and feel that we are all accustomed to today and are far more easily navigated than the hierarchical menu structure of years gone by. As a result, less training will be required in terms of use and navigation. But don’t neglect the evaluation of business processes. And don’t neglect process standardization and process improvement. ERP can be the vehicle by which you both standardize and improve. This is where training is still required, regardless of how easy software is to navigate.

Deployment Options

Worried about having to build an IT staff? Maybe you don’t need to. Today there are multiple options for deployment, as well as options for the ongoing care and feeding of an ERP solution. With choices comes the potential for confusion. It is important to understand these various options.

Terms such as software as a service (SaaS), on-demand, hosted, and cloud computing are often used interchangeably, and yet each has its own implications and some of these approaches can be co-mingled.

Software is typically not bought and sold; instead it is licensed for use. It may be licensed to be used by a company, on a particular computer or by other criteria such as number of users. When installed at the company’s site, it is generally referred to as “on-premise.” In this case an internal IT department might be responsible for supporting and maintaining the solution. However, even with on-premise environments, basic functions such as backup, security, operating system and even business application upgrades can be outsourced.

In a hosted environment, applications are licensed but are hosted by a third-party. This may be in a separate instance on a separate piece of hardware (dedicated to your company), or in a separate virtual instance (also dedicated to your company) where the application is housed on hardware shared by multiple companies. In this case little or no IT support is required at your own site.

In a SaaS or on-demand model the software itself is neither licensed nor owned by the end user company. The software is delivered as a service and is paid for through a subscription for the service provided. Generally speaking few or no technical resources are required at your own site. Cloud terminology is often intermingled with SaaS, but reference to the cloud simply refers to the operating environment and not how the software is bought or paid for.

To the non-technical ERP users the most important aspect is that they are able to connect to the application and its data from any computer with a browser. If in fact this is possible, often times the end user does not know, care or need to know which of these deployment models are actually being used to deliver the application.

A web-enabled user interface is now counted amongst the “basics” of ERP. It is the most versatile, eliminates the need to install and support software on laptops and other personal computers and allows a small company choice in how the software is deployed and paid for.

One more installment will follow. Click here  if you would like to download all three parts in one report. Note: registration is required.

 

Tagged , , , , , , , ,

ERP: Join me in a stroll down memory lane

I’ve been “watching” ERP (Enterprise Resource Planning) for more than three decades now. You might even say I’ve been watching it before it even existed, before it emerged on the market, when it was still a twinkle in the eye of software companies. You see, back in the 1970’s most of the software industry looked with disdain on “packaged” software. Everything was pretty much home-grown or custom developed back then. After all, how in the world could you possibly write software that would really meet the needs of a wide range of companies? Back then of course, all companies were “different” and therefore software had to be developed to meet those unique needs. Right?

The answer even back then was really, “No, of course not.” Each and every company was not really that different. Every for-profit company took orders, delivered goods or services and paid their bills. Manufacturers bought components or ingredients and made things.  Distributors moved goods. Retailers procured, stocked and sold product. Even non-profits needed to balance their books and produce financial statements.  All but the very smallest companies had payroll to meet and taxes to pay. Yet business processes were/are not identical from company to company and each had/has their own nuances. Back in the 1970’s god forbid, if a software company dared to question how things were done, or worse, attempt to change policy or procedure. If something had to change, it was definitely the software. And back then, that meant mucking around deep down in the source code. And it was even worse if the file or database structures had to change.

When you look at it from this perspective you realize just how far we have come. Back 30 years ago, data entry clerks (dare I say even key punch operators?) and data processing (the predecessors to IT) departments were the only people who actually “touched” software. The only thing management touched was the mountain of paper produced as output and that paper was green bar, continuous forms that might or might not be “burst” into individual pages. Thirty years might seem like a life-time to those in Generation X, Y or the new iY. But to Baby Boomers who entered the job market during the 1960’s and 1970’s it seems like just yesterday.

ERP has of course evolved from MRP which originally stood for Material Requirements Planning, then expanded to include more than materials and became Manufacturing Resource Planning. Somewhere along the way there was an MRP II, but at this point in history the difference “II” added doesn’t much matter anymore. Then as the footprint of the software grew to encompass other aspects of the business, MRP merged with accounting applications and morphed into ERP. It broke free of the boundaries implied by Material and Manufacturing, to be an enterprise application for all types of industries. Some struggle to define ERP today. I don’t. I define it as an integrated suite of modules that forms the transactional and operational system of record of the business. But the boundaries of ERP have steadily grown to include a broader and deeper footprint, to the point where ERP is not really confined by any boundaries.

Back in the 1970’s, nobody would have conceived how far we could go in the next 30+ years, just as we couldn’t conceive of having the same (or more) processing power clipped to our waistbands  as that which used to require raised floor, climate-controlled rooms.  So where are we going now? All the rage of course is:

  • Mobility: accessing enterprise data from those ubiquitous mobile devices
  • Cloud computing: operating ERP in a hosted environment, public or private clouds, buying Software as a Service (SaaS) and connecting traditional on-premise solutions to those in the cloud
  • Two-tier ERP strategies: does it make sense for a multi-divisional company  to standardize on one ERP, or to have one (or more) operational ERP’s coexisting with a corporate, administrative ERP?
  • Mashing up data from ERP with other applications and even external applications like Google Maps, Outlook and anything you can reach through a url.
  • Processing huge volumes of data in seconds or even nanoseconds

But the real bottom line in implementing ERP is just that… the bottom line. How does it impact cost and efficiency? What business benefits does it bring? And is anyone measuring? This is the subject of my recently launched survey.

If you have ERP, you have a chance to weigh in on how important these trends are to you and then see a summary of the results and engage in the discussion. Even if you haven’t invested in ERP yet, jump in. We want to hear about what you are doing now, what’s holding you back and what are your plans?

You might be asking yourself, “What’s in it for me?” I will share a copy of the Executive Summary of the findings with all participants and I am also offering access to Mint Jutras for questions and inquiry regarding ERP for 6 months after you take the survey. While contact info is optional, I will need your name and email address to deliver this to you. Don’t worry, this exercise is not a marketing ploy asking for your permission to share your contact info. It’s really just about the research, so don’t be afraid to have your voice heard.

Please click on our Survey link to participate.

A note to solution providers: Feel free to take the survey but ONLY IF you answer questions honestly as a user (not a provider) of ERP solutions. Or, if you prefer, pass this along to your customers. For more information on how you might participate (see and benefit from the results) please contact me at cindy@mintjutras.com.

Tagged , , , , , , , , , , , , , , ,

NetSuite ERP+CRM+Demand Planning=Better Inventory Management

Earlier this week NetSuite announced a new module for its cloud-based business management suite. Targeting wholesalers, manufacturers, retailers, and distributors NetSuite Demand Planning enables companies to forecast demand, create a supply plan and manage inventory in order to minimize stocking levels yet effectively and efficiently meet customer demand. NetSuite Enterprise Resource Planning (ERP) provides a solid foundation for inventory management. The new module extends the functionality with statistical forecasting based on historical usage, recognizing seasonal trends and suggesting optimal order points. But the module doesn’t stop there. Drawing on its strong heritage in sales force automation (SFA) and customer relationship management (CRM), NetSuite also takes into consideration sales data, pipeline and forecast.

Right now, this is an either-or proposition. You either let historical demand drive the demand plan (which then drives the supply plan), or you look to the sales forecast. Different environments will dictate which is more appropriate. For a consumer product, perhaps commodity-driven business, history is probably provides the best guidance. But in launching a new product or in the case where demand is volatile, the current pipeline is a better indicator. Of course, being able to do both brings the best of both worlds. And NetSuite Demand Planning allows you to do either, but not both at the same time, for side-by-side comparisons. While these comparisons would be nice to have, in fact companies seldom operate this way. Even today NetSuite customers could occasionally run two separate scenarios and manually compare the results in order to determine which provides a more accurate prediction of future demand. After all, we all know the only thing for certain about a forecast is that it will be wrong. It is the degree of “wrong-ness” that you need to measure and manage.

Incorporating demand planning into the mix of enterprise applications is not unique today and it is not unheard of to have this functionality embedded in ERP. However, when it is an embedded module of ERP, it is not as likely to include the ability to use the sales forecast, since the sales pipeline is not typically something that ERP manages. Also this functionality is just as often provided through separate extensions to ERP. Therefore the fully integrated nature of NetSuite Demand Planning is a plus. The input can come from ERP transactions or SFA pipelines and forecasts (both native to NetSuite) and the output is automatically generated purchase orders and work orders.

NetSuite has taken a workflow approach to the process, including five steps:

  1. Calculate demand (based on inventory transactions or sales forecast)
  2. Review and edit the demand plan (manual adjustments can be made)
  3. Calculate Supply
  4. Review and edit the supply plan (manual adjustments can be made)
  5. Generate work orders and purchase orders (POs) to meet the demand

In creating the demand plan, users are able to select a single item or groups of items to create the demand plan for, and in doing so can choose Linear Regression, Moving Average, Seasonal Average, or Sales Forecast. So indeed, different items can be treated differently. The system also allows you to select how much history, and how much to project into the future. Similar options are available in creating the supply plan.

Overall, the benefits to NetSuite customers, and what might make this attractive to manufacturers, distributors and retailers evaluating the solution provider include:

  • Efficiency: the implementation of a Demand Planning solution can significantly reduce the amount of time spent planning inventories. Without such a solution, companies often resort to the ubiquitous spreadsheet. While familiar and easy to work with, even if data is directly exported from ERP or CRM/SFA, once it becomes embedded in a spreadsheet and starts to travel through the process, it tends to take on a life of its own. The further away from the source and the application which will eventually execute the supply plan, the more danger in it not reflecting reality. And remember the plan does need to eventually be reflected back in ERP in order to cut PO’s and release work orders.
  • A better plan: The goal is to reduce stocking levels while improving delivery. Often these two goals appear to be conflicting. But remember, increased inventory levels, may not indeed insure better performance. Having the right inventory at the right time, in the right place is the goal.

This module, while fully integrated, does need to be purchased separately. If you are a distributor, retailer, wholesaler or manufacturer currently running NetSuite and looking for a way to better manage inventory, improve efficiencies and increase on-time and complete shipments, NetSuite Demand Planning is certainly worth a look. For those prospects considering NetSuite, this module adds functionality, broadening the NetSuite footprint and should be part of the evaluation.

Tagged , , , , , , ,

SAP Business ByDesign Status, Momentum and Plans

My very first meeting at Sapphire 2011 was an update by Rainer Zinow on SAP Business ByDesign on its status, traction and plans for the future.  The briefing was also attended by other analysts who cover (exclusively or at least in part) the SME enterprise application market. Rainer started the meeting by throwing us a curve and asking us what we wanted to hear – a refreshing change from the usual, “Here’s what we want to tell you.” My question was essentially how SAP was progressing in building the volume business ByDesign is intended to be. It looks like a lot of progress has been made but momentum is still building.

SAP now has 500 Business ByDesign customers and says it is on track to meet its goal of 1000 by year end. After the briefing I tweeted that factoid and almost immediately got a response questioning, “How long does it take to go live on #SAP ByD? Can they mathematically get to 1000 implemented by year end?” My response was (in not so many Twitter words), don’t confuse selling with implementation.

SAP never said that 1000 customers would be live. In fact one of the ByDesign customers I spoke with today (Technodyne) actually went live in 16 weeks. But my experience from talking to ByDesign customers over the past several years is that there is the same variability in implementation cycles as there is for any ERP. I’ve seen ERP go in quick and dirty, fast and solid, well-paced and methodically, or slow and painful. The time required in order to go live often has as much, if not more to do with the company doing the implementation than the solution itself.  

That is of course providing the solution is a good fit and, in the case of small companies, not overly complicated. But the whole reason SAP started from scratch in writing Business ByDesign was to reduce the level of complexity that becomes inherent in a solution that starts out as a large enterprise solution, and grows more complex through evolution. Today ByDesign is still primarily targeting companies with 50 to 500 employees which do not require highly tuned industry-specific functionality. There is one industry in which it is particularly strong (professional services) and there will be more industry specific functionality developed, but SAP never sees it becoming an option for certain industries requiring certain select functionality. Don’t expect a version for pharmaceuticals or oil and gas any time soon.

So what else can I share with you about the status and momentum of Business By Design? If you have been following SAP’s “on demand” plans you will have noticed a major strategy shift over the past year plus. Originally there were really two on demand strategies – one for SME (small to midsize enterprises) and one for larger enterprises. SAP called this the “Line of Business” (LOB) on demand applications, presumably because these other on demand solutions were targeted to specific areas of the business such as sales, procurement or human capital management. But they weren’t ERP. They extended or surrounded ERP, which for the large enterprise was largely staying on premise, or perhaps being outsourced or hosted. Originally these LOB applications were developed using a very different infrastructure than that used to develop and deploy ByDesign, with some technology acquired through SAP’s acquisition of Frictionless Software.

But that all changed as SAP made some breakthroughs in the ByDesign infrastructure.  ByDesign became multi-tenant , which was an important step in turning it into more of a volume business. Then, the underlying technology behind ByDesign became the platform of choice for new on demand development at SAP including Sales On Deman, Career On Demand and Travel On Demand and others to come. Sourcing On Demand remains on Frictionless and Carbon Impact runs on a different platform (River). The development teams were consolidated under Peter Lorenz and development, support and management of the products moved to China.

The release of the SDK (Software Developer’s Kit) ByDesign Studio is also an important consideration. In the early days, while there were certainly ways to configure and tailor the solution, no customization of ByDesign was supported even though the software ran as a single tenant. But with the release of the SDK, SAP can offer customization in multi-tenancy, although with the stipulation that all customization is delivered in the context of the SDK. Additional business objects, and additional logic can be added and partners are also able to further monetize these efforts by publishing to an online SAP store. While available from the store, the customization or extension is purchased from the partner who develops it. Of course SAP takes a cut… after all it is providing the showcase and vehicle for purchase, as well as the SDK itself and it takes an active role in quality certification. And of course the software is hosted by SAP. Remember it is not licensed but sold as a service.

This ability to customize is important as Business ByDesign moves from being just a solution for small to midsize companies. SAP sees a strong market in large enterprises – not at the corporate headquarters, but perhaps in more of a tiered solution structure, satisfying the needs on divisions, business units, remote locations, etc. The first integration scenarios delivered with Feature Pack (FP) 2.6 were also important first steps in supporting this multi-tiered scenario. But even as ByDesign starts to penetrate these larger enterprises, SAP assures us it will also remain true to its heritage, as a midmarket solution. Indeed, even these larger enterprise implementations start off small, sometimes with 10 users, perhaps as a pilot. As they achieve some success, users still need to sell the solution internally. So it opens the door, but there is still the need to go back and do more selling. This is the only part that to me doesn’t lend itself to a real volume sales business. For very high volumes you need to get in and sell and then move to the next sale, and the next… all without losing the relationship with the customer that has become more and more important to SAP. The one redeeming factor is that in some cases this added selling has led to as much as an 80% penetration which is unheard of in the large enterprise (Business Suite) world.

Today SAP hosts the software in two locations: Germany and in the United States. And just this afternoon news broke of a partnership with China Telecom to provide the service in Asia. I’m sure we’ll hear more about that in the days and weeks to come. But in the meantime, SAP is fully certified to be SAS 70 Type II compliant, satisfying more stringent requirements than the Type I compliance achieved by most service organizations, including the ability to be able to sustain operation with power and with no air conditioning for 3 days. While this may not have seemed to be a requirement in the past, recent disasters and extreme weather conditions make this more relevant today.

All told, after getting off to a slow early start, momentum is building and SAP has a very good story to tell about progress made in turning the Business ByDesign business into a volume business.

Tagged , , , , , ,

Twitter Spreads the Buzz as SAP’s John Wookey departs

I’ve been watching the buzz that followed the announcement of John Wookey’s departure from SAP. Others have come and gone with hardly a mention but this departure is getting a bit more attention. Quite frankly I think it has more to do with Twitter than it does with SAP or John Wookey himself. That’s how I first learned of his resignation and I would guess most industry observers learned about it the same way. The immediacy of social media, Twitter especially, seems to spur everyone to either weigh in on the matter, or at least pass along the news. I was no exception, even though I am hardly as prolific in tweeting as many of my industry counterparts.
Ordinarily I don’t write much about organizational changes unless I believe they are somehow game changing. In fact I haven’t written a real analysis of a departure since Shai Agassi’s departure in March 2007. I did post a brief entry to my Aberdeen blog when Leo Apotheker left, but even that did not have the potential impact that Shai’s departure had. And John Wookey’s doesn’t even come close. But that is actually to John’s and SAP’s credit.
Yes John Wookey was a voice of the on-demand strategy at SAP, but let’s not forget that initially the “line of business” (which was really the large enterprise) on-demand strategy, which John was in charge of, had nothing to do with the current strategy which uses the Business ByDesign architecture as the overall on-demand platform. But today the revamped on-demand  strategy is firmly enough in place and execution has begun in earnest. I don’t believe John Wookey’s departure (or that of any SAP exec) has the potential of derailing the wheels that have been set in motion to carry through on that strategy.
Shai’s departure was much different. First of all, Shai had a far more influential position than John. Prior to his departure he oversaw the development of the SAP NetWeaver platform, SAP xApps packaged composite applications, mySAP SRM, SAP Business One, and the project that ultimately produced Business ByDesign (called the A1S mid-market initiative back then). And there was a massive reorganization when he left. I never really decided for sure whether his departure triggered the reorg or if the reorg triggered his departure.  In the end, it didn’t matter all that much.
At the time, as an Aberdeen analyst I wrote, “SAP appears to be far enough down the path of its enterprise SOA strategy to not be derailed by the departure of a single executive, even one as charismatic as Shai. The migration to its new platform and mySAP ERP [which became the basis for the Business Suite] has begun although SAP still has a long way to go to meet the publicly stated goal of 100,000 customers by 2010 [the Business Objects acquisition gave that initiative a big shot in the arm]. And SAP is in the early stages of delivering against the newly announced A1S mid-market strategy [which was made available on a limited basis as Business ByDesign in September of that year].”
Since Shai’s departure there have been a lot of ups and downs, as well as sideways motion on all these initiatives. But all of these goals have since been achieved, in one way or another. At this point I would just wish John well and will keep an eye out for where he lands. I am sure someone I follow on Twitter will tell me as soon as they know.
Tagged , , , ,