Category Archives: maintenance

Third Party Providers

Leave a reply

Happy New Year!

I saw an interesting article today that high-tech vehicles were posing problems to some mechanics.  The mechanics claim that they can’t afford the thousands of dollars that are necessary for them to obtain the specialized diagnostic tools for each auto manufacturer.  The manufacturers are claiming that they’re trying to protect their intellectual property.

Sound familiar?  Yup, it’s exactly like the issues Frank Scavo and Ray Wang have written about with regards to third-party software providers being blocked from performing various maintenance/implementation tasks by the contracts and software licenses and services agreements of certain primary vendors.

On the automotive side, it’s apparently gotten to be such an issue that there’s a congressional bill called the Motor Vehicle Owners Right to Repair Act of 2009.  The stated purpose of this Bill is to “protect the rights of consumers to diagnose, service, maintain, and repair their motor vehicles”.  What’s really interesting are the Bill’s findings, among which say that:

  • Motor vehicle owners are entitled to choose which service provider will diagnose, service, maintain, or repair their motor vehicles.
  • Promoting competition in price and quality… will benefit consumers.
  • Only service technician with the necessary tools and information can access the computers to perform diagnosis, service, maintenance and repair…

And the requirements of the Bill, specifically:

  • Duty to Make Tools Available:  The manufacturer of a motor vehicle sold, leases or otherwise introduced into commerce in the United States must offer for sale to the motor vehicle owner and to all service providers on a reasonable and non-discriminatory basis, any tool for the diagnosis, service, maintenance, or repair of a motor vehicle, and provide all information that enables aftermarket tool companies to manufacture tools with the same functional characteristics as those tools made available by the manufacturers to authorized dealers.
  • Replacement Equipment: The manufacturer of a motor vehicle sold, leased, or otherwise introduced into commerce in the United States must offer for sale to motor vehicle owners, and to all service providers on reasonable and non-discriminatory terms, all equipment for diagnosis, service, maintenance, or repair of a motor vehicle.

The only thing the Bill protects for the manufacturer are things that are actual trade secrets.

Wow.  Of course, there are a LOT of people (and more specifically, a lot of trade association and advocacy groups) behind this Bill.

Could you imagine what would happen if this passes and someone realizes that software in cars isn’t that dissimilar to plain old enterprise software?  If only there was a trade association group for buyers of enterprise software apps.  😉

But let’s talk about the other side of the issue for a moment.  Do consumers have a right to have third-party companies provide service?  A right?  No.  I don’t think there’s a right to be able to have third-party providers.  [Keep in mind, when we’re talking about rights, we’re talking about things equal to “life, liberty and the pursuit of happiness…”.]

Absent a right, should third-party providers still be allowed/encouraged?  I’m really torn on this.  On one hand, I’m all in favor of things that inspire commerce.  I like behaviors that create business, allow more people to work… and of course, things that drive down costs and dissipate apparent monopolies.  On the other hand, an individual or organization who creates something should be able to protect their idea/invention and not have to give up the secret sauce simply so that other people can benefit.  But there seems to be a line somewhere that once you cross it should allow for third-party companies to fill available niches.  Maybe it’s where the original vendor is no longer able to provide a quality-level of service.  Maybe it’s a situation where the original vendor is charging exorbitant rates.  I’m not sure.

Anyone have a solution?

Advertisement

As the year draws to a close

Leave a reply

Hopefully, most of you are done with work for the year.  But for those of you about to close end of year, firesale-type deals in the remaining 6 days of the year (the end of the year is even a Thursday, so you don’t have to “work” a weekend if this is your fate), here is a list of articles on how to get the most out of your transaction time:

Start with fundamentals on negotiation.  Think outside the box.

Then go through the basics on firesales.  If you want more, buy the Firesale Concall Recording.

Understand pricing, and when it might pay to avoid maintenance costs.

Start your deals from good templates.

And, lastly, consider the reasons for agreeing to renegotiating deals.

To my faithful readers: Thank you for listening to me for another year.  I hope you have a very joyous holiday season and a happy New Year.  See you in 2010 (unless something really awesome in the licensing world happens between now and then).

This Week on The Web 2009-09-13 (my birthday edition)

Leave a reply

It happens to be my birthday weekend and between eating some great food, playing Guitar Hero with my wife and hanging with the family, these are the things that happened around the web this week – maybe you already read about them, maybe you need to again – there were some REALLY great discussions going on.  Come join the party on twitter (follow me here and you’ll join the conversation live.)

I also realized that many of you might have no idea what you’re seeing below.  Sorry.  These are “tweets”, 140 maximum character messages sent via Twitter.  Within the Twitterverse individual users follow others and have followers (think of it like overlapping Venn diagram circles).  To read a tweet, you have to wade through a bit of jargon used to make the most of the 140 character limitation.  “RT” for example, is shorthand for “Re-tweet” and the @____ is the username of some other individual on Twitter.  Combined together, then, “RT @_____” means that someone else wrote a tweet that I found important and I now want to forward along to my followers.  The URL’s are then also shortened by shortening services like bit.ly to make the most of the character limitation, too.  Lastly, you might see “hash” identifiers “#______” which are ways to tag tweets of a particular flavor for easy searching later and “<” which means that I am commenting on what came before it.

License Resale

1 Reply

Vinnie Mirchandani at deal architect pointed out a Ray Wang article on the resale of unused licenses.  My thoughts are in the comments on Ray’s article.  But generally speaking, regardless of what Ray suggests, you can’t do it in the US (or the rest of the Berne Convention countries) under most licenses which have express prohibitions against it (you can almost always contract away your rights).

And, even if you could, your organization probably doesn’t have tracking enough to make it possible – just remember that if you overuse your permitted license count, chances are there’s another provision in your license that allows the vendor to charge you (perhaps at non-discounted pricing) for the overage.

What I DO like about Ray’s suggestion is that idea that you should try to negotiate for a recapture of maintenance fees on unused licenses.  If you can’t resell them, the least you can do is take an annual count and only pay maintenance on the ones you’re using.  There is, of course, trouble with this thought, too – as there are some vendors that used to allow this (the last one I remember was Autodesk).  But the trouble is that you can get into a situation where you only upgrade SOME of your licenses to the current version because not all of them are currently covered by maintenance and the upgrades provided under such program.

 

Don’t Pay for Enterprise App Maintenance

Leave a reply

I completely agree with David Dobrin.  It’s hard to convince people to do it, of course.  But read his logic.  1/200th.  I think that is about the right threshold – it might even be a little low (my life insurance policy is about 1/500th… my car is about 1/166th – but doesn’t take personal injury into account… my home is about 1/1600th).

Hmmm… the more I think about this, the more I think it would be really easy to convince my clients of this.  Anyone have a counter argument?

Salesforce.com calls for End of Maintenance

Leave a reply

Below is the contents of an internal salesforce.com memo CEO Marc Benioff shared with Vinnie Mirchandani (and posted on his blog: deal architect).  I’m pasting it here for simplicity’s sake and because of the power of the message itself.

“For ten years, we’ve been driven by a simple vision: The End of Software.  Now it’s time to take on a new challenge: The End of Maintenance.

Let me tell you about a customer that I met on our Cloudforce tour. This customer currently uses Siebel software to run her call center.  She pays more than $15 million a year for the privilege of having to implement the updates that Siebel sends her.  That does not include backup. Or disaster recovery. And of course, it does not guarantee that she will be using the latest technology.  The maintenance agreement only assures her that her outdated software will continue to work.  She is paying tolls on a road to nowhere.

We can help her, and many other customers, and deliver much more for a fraction of what they currently pay in maintenance. It’s time to open up a new front in “The End of Software”– one that is long overdue.

It’s time for The End of Maintenance.

Every year, companies spend billions on maintenance fees and get relatively little in return. Maintenance fees cover updates that are mostly  patches and fixes, but they stop far short of the kind of innovation every that enterprise needs to survive.  Companies pay to keep the past working and they end up doubling down on technology that can never keep up with their needs.  The fees that companies pay have actually been rising, from something like 17% a few years ago to numbers more like 22% today. Every four or five years, companies are paying for their software all over again.

It’s time to set these businesses free and make them successful in the Sales Cloud,  Service Cloud and on our Force.com platform.

Our new mission begins at a critical time in the economy, when companies are questioning conventional wisdom as they never have before.  That, of course, extends to their IT budgets as well. The CIO is in a tough spot right now.  Corporate budgets are tightening.  And our rivals in the legacy client-server world are using this opportunities to extract more money from their customers by raising maintenance fees.  I call this phenomenon “the compression of IT” and it resonates with just about every CIO I speak with these days.

We have a better vision. We sell our customers a service and every customer is able to use the latest. Innovations are included. Upgrades are automatic and invisible. Customers’ intellectual property of customizations and extensions is rigorously preserved, and carried forward without disruption.

The service gets better, not just less buggy. That’s not what people are getting for all those fees that supposedly buy them “maintenance.”

It’s time to set these business people free: to give them the experience of being wildly successful in the Sales Cloud, the Service Cloud, and in their own unique applications that they can build on our Force.com platform. This is the time to do it, because this is when people need it: their IT budgets are tight, their business situations are critical, and their old-world software vendors are taking care of themselves instead of meeting the needs of their customers.

We’ve raised people’s expectations for better alignment of business value with IT cost. We’ve earned our leadership position in enterprise cloud computing. It’s time for us to set people free from paying more and more to get less and less. It’s time for The End of Maintenance.

Aloha,

Marc”

Internal Business Purposes

2 Replies

How many licenses to your core database software do you own?  I ask about this specific type of license because database software is typically expensive (relatively speaking) and customers license an exact quantity of licenses required based on actual use.  In other words, if you need 5 database servers (or instances), you pay for 5 licenses.

Of course, it’s never that simple.  Because your IT department usually also wants a development server for each database instance.  This makes sense – development should be done separately from production (you wouldn’t want some experiment in design to bring down your production server).  Oh, and what about testing?  This is the middle-of-the-road between development and production… where something that your developers believe is ready for production goes to receive significant QA attention.  That’s yet another set of databases.

So, now we’re talking about 15 licenses: 5 production + 5 QA/test + 5 development.  If 5 were expensive, imagine what 15 could become.

Database software developers understand this dilemma.  They know that if you’re really making use of their products, whatever you have in production has to be supported by nearly as many dev/test environments.  Back in the day, this was usually a pretty simple situation – you asked for, and usually received, “free” dev/test licenses.  I say “free” because they were never really free, they just didn’t separately price them.  You paid for them then, just as you pay for them now.  The difference is that the cost was built into the production licenses back then because the hardware wasn’t strong enough to support some of the tricks that can now be used to run multiple databases within a single hardware environment.  Once the hardware was strong enough (about 8 years ago), savvy licensees didn’t actually need 5+5+5 … they could find ways to do 5 + 3 + 2 or some other combination in something other than a 1:1 relationship.

The net result is that these same savvy licensees started asking for discounts on the initial 5 production licenses because they knew they were no longer needing the triple-play effort of that single license.  Instead, they argued, they only needed a few “extra” licenses (now really for free) because it was understood that to make use of the product, you needed these extra environments.  They just didn’t need them in the same quantities as before, so it had the appearance of being less of a freebie than before.

Software vendors reacted in the best way they could – through changes in language.  The phrase “internal busines purposes” became the expected response.  “Yes”, the vendors said, “you can have a few extra licenses – but only for internal business purposes.”  The meaning wasn’t always clear, of course, but the intent was to say that the licenses you purchased were the ones that could see the light of day (be used by regular users, etc), but that the extra licenses were only for back-room development and testing.  You were signing a license agreement confirming that you wouldn’t take these fully-functional licenses and put them into production.

No problem.

Until ASP/SaaS offerings came along.  Now you have databases that are serving data to the world 24/7/365.  Licensees still need dev/test environments… but these are now potentially available online, too.  And, in rare cases, serve as the backup production environment in the event that the usual production environment goes down.

Has this really created a problem?  No.  The case remains that licensees should have frank and honest conversations with their vendors about how they intend to use the products rather than try to sneak some form of unintended or unexplained use by the vendor.  If licensees want “free” licenses for dev/test, they should expect to see (and respect) “internal business purposes” language.  And they should discuss the possibility of needing to put a dev/test server into production in the event of a disaster.

Lastly, licensees should also remember that such licenses are never free.  Whether you have a line-item cost that shows you paying full-price, partial-price or no-price, the cost is still baked into the deal in some way.  However, one key advantage to calling out the pricing specifically for dev/test environments is the ability to get them excluded from maintenance costs – as there should be no need to pay for maintenance on a dev/test box needed to provide support for a production server.

Software Licensing Education Series – 400s Track Now Available!

Leave a reply

Designed for the busy or on-the-go professional, the Software Licensing Education Series (SLES) is video-based training on the complete gamut of software licensing topics. Presented in a college-course level format, with topics increasing in complexity and building upon prior lessons, the SLES allows an audio-visual learner another way to gain knowledge on licensing topics.  Each video is approximately 20-30 minutes in length, so each Track contains about 2 hours of expert instruction in core software licensing topics!

The 400 Track videos include:
SLES 401 – Services Issues 2
SLES 402 – Maintenance and Support 1
SLES 403 – Maintenance and Support 2 (special 1-hour course)
SLES 404 – ASP and SaaS Issues

(500s Tracks are currently in production and will be released shortly!)

Videos are formatted for a computer or portable video player (such as an iPod) and consist of a slide-show format with voice-over instruction, so you can even learn just by listening!

Service Level Examples

2 Replies

Two weeks ago, we started talking about service levels.  Last week, we discussed how to write them and I mentioned that the best way to gain experience was to do it – repeatedly.  I stand by that statement, but if you’ve never done it before or don’t have a lot of experience in writing them, then you might need some help getting started.  So I’m going to provide you with some starting points for a few key service level metrics.  These are the ones common for software-related contracts – so they’re not going to be universally applicable to everyone or to all situations.  But they might give you a jumping off point for the creation of your own.

So, before you can measure a service level, you have to define one (or more).  As I stated before, software-related services are typically measured by two major factors: Problem Response (how quickly the vendor responds to a call for help) and Problem Resolution (how quickly the vendor solves the problem).  As two measures of time, they’re similar, but these are two independent measures – a vendor can do well with one and poorly with the other, for example.  Additionally, embedded in both of these metrics is a key definition – the concept of Severity.  So we actually have to start with the definitions and work forward.

Not all problems are created equal.  Severity is the disambiguation of a particular issues’ importance.  You should create at least three Severity levels, perhaps four, but never more.  I like four because I think that it offers enough distinction between each Severity level without becoming so nuanced as to be irrelevant.  I define Sev1 Problems as any problem resulting in a full or partial production stoppage or data inaccuracy.  Sev2 Problems are a significant production inhibitor.  Sev3 Problems are those where we can do our work, but only through manual intervention that requires significant production or performance inefficiency, or where reporting functions are unavailable.  Finally, Sev4 Problems are any condition in/of the software other than those defined as Sev1-3, which affects the service or operation of our systems or network, but does not render such system or network unusable or inoperable.

The net result is that Sev1’s are “the sky is falling” moments; Sev2’s are “holy crap”; Sev3’s are “we’re pulling an all-nighter” and Sev4’s are “I don’t like having to do something in this really wacked-out way because the software doesn’t work to the manual’s spec”.  Now, you can redefine these Severity Levels any way that you wish… but the general formula should be followed (not just because I say so… but because these are almost industry standard).  As you’ll see in a moment, the distinction between each level is also important in terms of how it impacts your metrics.  Additionally, the “missing” 5th severity level is one I simply don’t include anymore – but if you do so, it would be the “user interface” issue – the color palate that makes things hard to read, the minor nit that isn’t inhibiting in any way, it’s just an annoyance.

OK, so now that you have the Severity Levels defined, you can get back to the creation of metrics for Response and Resolution time.  As I said before, Response Time is how quickly the vendor is going to answer a call for help.  Thinking logically then, the higher the Severity Level, the more quickly the vendor should respond because the more damage delay in response would cause.  My standard starts with 2 hour response time for Sev1, 4 hours for Sev2, 8 hours for Sev3 and 12 hours for Sev4.  Remember, this is just response time – the time it should take the vendor to give you a PLAN for a resolution, not to actually solve the problem.

With Resolution Time, I’m measuring time, but I’m also measuring completeness, as Resolutions are dependent upon the problem being fully solved (hence the definition of the word “resolution”).  For Sev1 Problems, I need immediate assistance, tempered with a little understanding of how software development works.  So I ask for 100% of Problem(s) resolved in 24 hours.  I follow an almost identical geometric path as the Response Times.  Sev2’s should be resolved in 48 hours, Sev3’s in 72 hours and Sev4’s in 96 hours.

Seems pretty simple, actually.  And, in many cases, it can be.  But again, if I didn’t have a fairly thorough understanding of the software development, testing/QA and bug identification/repair process, I might be tempted to ask for unreasonable metrics, or alternatively, be willing to agree to extremely long times as well.  Again, the moral of the story is to know what you want to measure and why and go from there.  Next week, we’ll talk about what happens when someone blows a service level.