Archives for category: Channel Sales and Development

I haven’t written a blog in some time, I have been working on many interesting projects.  More on that later.

This week I saw that HPE has signed a definitive agreement to acquire Nimble Storage for $1B.  Nimble is a solid system and the company has done a great job bringing it to market.  Nimble did all the right things from a sales and marketing perspective.  I can understand why it is an attractive target for HPE or any other potential acquirer.  That said, here are some reasons why I question the value of this merger:

  • HPE has a hybrid SSD/HDD system (3PAR); they have spent a lot of time porting it to a smaller entry point.  There is a significant overlap between 3PAR and Nimble from a target market perspective.  BTW, 3PAR seems to be one area in storage at HPE that is growing so why cannibalize or compete with self?
  • HPE has areas of the portfolio that are really lacking in offerings.  This includes NAS/file system storage, Object storage, tier 3 bulk storage, and others.  There is growth in storage in unstructured data and virtualization.  If you want growth, go where there is growth in the market.
  • Part of Nimble’s success is its go to market strategy and execution.  HPE takes a different approach to channel than Nimble.  One consideration is whether the challenge is gaining more growth in storage is more associated with how HPE sells and markets than what products they care, at least in some areas.  If you want to compete with younger more agile firms, then try being more agile.  Agility in sales process is something other large companies lack.

Moving forward, I hope HPE  doesn’t take too long to integrate Nimble and adopt some of Nimble’s strategies.

I often write about what works and doesn’t work in the world of channels. There are new challenges we encounter daily but most can be overcome with open communications.  Of course there are always risks associated with partnerships in a reseller model and every entity wants to minimize their exposure.  In the end though, the business defines how the partnership will work and legal then works to put it into terms that are acceptable to all parties.

As an example,  if the reseller will not be providing any post sale support, there is no need to have any wording that dictates how support will be managed.

This is how most discussions work; sometimes though, we come across an organization where legal dictates business terms.  The challenge with these situations is that legal operates without business context and, therefore, often puts terms that are hard to accept for a reseller because they don’t represent reality.  I think when forging a partnership, it is best to first discuss and agree on the business terms, and then put these into legal terms.  In all situations remember, a partnership has to be a win-win for all parties, otherwise, it won’t work.

One of my biggest challenges every day is to cut through the industry noise and get to the bottom of what vendors are selling and what customers are buying.  It is a challenge because vendors message to what they think customers want to buy (not necessarily what they have to sell) and customers want to buy what they are hearing from the industry as what they need.  The reality is a lot simpler; what customers want to buy hasn’t changed in decades.

Enterprises want to leverage their IT resources to drive more business, more revenue, more profitability.  This means that IT must be more efficient, effective, differentiating, agile, and responsive.  These are the high level wants and needs.  Each organization translates these requirements into technical specification based on some criteria such as performance, scalability, cost, simplicity, risk, etc.  How these are prioritized depends mostly on the person/organization making the decision.

The noise complicates the conversation.

Enterprise need to become operationally more efficient and cut costs.  This doesn’t mean they want to buy cheap stuff.   It is about the price only when all other variables are equal.  The industry has instilled in the users the idea that cloud is cheaper and more flexible; you pay only for what you use.  There are many ways to define what cloud is, but if we take cloud infrastructure offerings, once you really look, they may not be cheaper or more flexible.  Here are two examples to demonstrate:

  • Company XYZ needs to store 1PB of data for 7 years.  It is not clear whether data will be accessed regularly or not, but there is a need for it to be secure.  Option 1 is to use cloud storage (S3, Glacier, Google Nearline).  A single location of public storage cloud is average $0.01 per GB per month.  Without accounting for egress and transaction costs, that equates to $123 per TB per year.  Over 4 years, the cost of keeping a PB in the lowest tier of cloud, in a single location would be $503,808.  Keep in mind that depending on where the cloud data center is located, you might need to concern yourself with mother nature.  If you store two copies for geographic distribution, your cost doubles to over a million in 4 years.  Conversely, you may procure an object storage system to host 1 PB of data for $400 per TB over 4 years.  The total cost of this solution would be $409,600.  Some object storage vendors support geo-dispersal which allows you to stretch the system across 3 sites with ability to sustain site failure without data loss.  The cost of such deployment would not be different than already stated $410k.  The facility costs may be off set by the lack of egress and transaction costs.

 

  • Another Example is company ABC is running a marketing campaign and requires compute and storage resources for the duration of the program, which is 9 months.  Provisioning a decent server in the cloud with a few TB of data and snapshots may cost $210/ month.  This equates to $1,890 for the duration of the project.  You might need to add a backup client for the data, but that could be another few hundred dollars.  If you had to purchase a server, it could cost you 4,500.

No one wakes up and says, I want to go cloud.  What they really want is faster and simpler way to deploy IT resources and applications, to pay for resources that they consume only and not have to pay forward, and to simplify management of their infrastructure.  Some will be willing to pay more to achieve these results, others may not.

There is a way for some to achieve these goals on premise or in a hybrid configuration.  First, identify applications that are not core to your business and can be better served via a service provider.  This could be CRM, email, or SCM.  Then evaluate your environment for places where resources can be shared among departments.  The more an organization centralizes IT services, the more efficiency can be achieved and the greater opportunity for flexibility in how resources are assigned and consumed.  The private cloud concept is exactly this, centralized IT services where end users can select what resources they need and an orchestration and management layer that simplifies provisioning and allocation of resources and tracking of consumption.

Though there are many variables that go into any buying decision, the conversation has to start with what does the business need.  Messaging the market that cloud is the only way, cloud is cheaper and faster, all SSD or Flash is the answer to all your prayers, or that you need 32 Gbps FC when you can barely fill an 8 Gbps pipe doesn’t help users make good decisions.  Instead of the hype and the noise, let’s build, package and deliver products and services that will move the enterprise forward. I seem to have an idealistic view of the world, but a girl can dream.

I have recently been working with two different universities on projects involving hardware.  In both cases, the acquisition of hardware was not new but an expansion of the existing system.  And yet, it still took us over 5 month to receive a PO.  I wouldn’t really care that it takes 5 month to process an order, but what made this challenging is that the actual buyer was running out of space and really needed this capacity to continue working. In this situation, the procurement department was standing in the way of the order.  There were all sorts of contract requirements; we spent weeks negotiating terms of a remote 4 hour install service.  Was the procurement department just following protocol or is there an unwillingness to see the bigger picture?  Are the legacy policies impeding progress in these and other organizations or are they really protecting them from harm?

The intent of the protocols set out in procurement processes is to protect the organization from undue harm and to procure the best solution for the money.  I have been working with contracts throughout my career and business context is a critical component of any negotiation.   It is here where we communication and consensus break down. It is as though we were all walking down the same road at one time, then the industry turned left but not all procurement protocols noticed.  So here are some thoughts to put business context back into the conversation:

  • Many procurement departments treat complex IT purchases the same as they treat buying commodity items like paper or pencils.  Cost typically is only one factor in an IT buying decision; the more relevant criteria may be performance, resiliency, density, and support.  Allowing the users to select the technology first may allow the organization to make better decisions overall that in the long run will save them money and headaches.  That said, we understand that there are required processes in place to ensure fair play.  The RFP process most commonly used lacks necessary detail and flexibility.  If ask a yes or a no question, you don’t get to learn how it actually works and whether it makes sense for your application/business.  An alternative approach that has worked in many situations is to instead issue an RFI to many vendors first.  This provides a response with enough detail to select two or three that fit the need the most.  There may be pricing presented in the RFI but it is not typically contractually binding.  The user may now spend time working with the various vendors to architect a solution that fits their specific need.  This also allows them to perform any POC work and speak to references.  After an extensive evaluation process, the user will be ready to proceed with a solution that has a detailed configuration and will require pricing.  This is where procurement can step in and assist.  Once they have a solution configuration, then pricing may be negotiated either directly with the supplier or through an RFQ process where the submitted quotes are contractually binding.

 

  • There is another phenomena that exists in the industry that procurement departments are either not aware of or don’t understand.  This is called channel partner commitment.  It means that if a channel partner (reseller, VAR) is working with the user on a solution, the vendor/manufacturer treats this partner as a contract sales representative of their organization.  This means that this channel partner will have the same pricing/discounts as if the user was working directly with the vendor/manufacturer.  In the background, the vendor will pay a sales commission to its channel partner.  When procurement departments spend a lot of time sending out requests for competitive quotes in these situations, they are really wasting time and resources.  They could probably get a better return on their effort by negotiating further with the partner presenting the solution.

 

  • Another mistake some procurement departments make, as do users, is think that if they go directly to the vendor they will get better pricing.  The industry has changed over the past two decades from having a few large solution providers to a diverse ecosystem of vendors, manufacturers, and software developers.  It is cost prohibitive in most cases to grow business by building out a direct sales force.  To stay competitive in the market, vendors they have contracted with regional and national reseller and VAR organizations to be the extension of their sales force.  More feet on the street without carrying full time employees.  Resellers and VARs provide a lower cost of sale to the vendor community.  What all this means is that in many cases, there is no way to buy direct from the manufacturer/vendor.  It is not to frustrate users or procurement department, it is just what makes business sense for the vendors.

 

  • Finally, I know everyone wants to protect themselves as much as possible, but please be reasonable.  Most companies/people are not out there to screw you or harm you in any way.  We all know that sometimes things happen and we all agree that protections need to be in place for when these situations occur.  That said, let’s not go overboard, be reasonable, consider what you are buying first (business context).  I have seen contracts from procurement that cover every possible situation that may occur across all products and services they may purchase.  This means that I might need to agree to terms and be held liable for situations that don’t apply.  A good example:  contract says that if the product I am selling is going to cause death of a patient due to malfunction, my organization is held liable.  Here is the problem with this.  I am just selling a storage box.  I am not developing or managing the application.  I am not making a decision whether the system is adequate from a resiliency perspective for your needs.  I don’t have any control where this system will be deployed.  Holding me liable in this situation is not logical.  The key message here is that we are all in this together.  Our goal is to do right by our customers, to go the extra mile when it matters most and in return, we want clients who value what we do for them.  We want a win win.

My hope is that the next time I work with a procurement department on a purchase of IT solutions, that there is a clear understanding, I am not selling pencils and it does matter what the end user ends up with.  Let’s work collaboratively to serve those who are both our customers.  Maybe I am a bit idealistic here, I am sure I am, but a girl can dream.