Out now! the Real ITSM book
The official Introduction to Real ITSM introduces Realitsm to the world!
Making IT Real.
Get Real.
Favourite BooksTell us about your favourite ITSM books, in print or not, obscure or well known... Who's new |
|
Recent comments- "IT exists for one reason: Visitor IT exists for one reason... Paul Wallis Real ITSM JamesFinister Fungible alexjones Information Revolution actually skeptic I agree that metrics are often useless Red Pineapple my birthday's over.... MySvcMon The analogy skeptic IT leads people to become management consultants Neil Hepburn similar thoughts skeptic Can you take us the next step? skeptic It´s right, there is no توبيكات railroads and IT Jake Absolutely Alexander Kist user v customer JamesFinister Surprisingly (or probably Michael SLA is not about the metrics! Red Pineapple Traditional SLA approach Visitor Hi,
managers need to Visitor Makes for a change Red Pineapple Distance from the coalface JamesFinister they're out of it skeptic Plaxo does not suck Michael Wilde Absolutely Louis DiMeglio I reviewed it myself skeptic Hooray! Time to Diagnose MySvcMon pretty confident skeptic we have to do it at the coalface skeptic An excellent idea JamesFinister current Worst Practice skeptic prospect pool skeptic Awards rpmason Darwin Awards Red Pineapple Sales Manager JamesFinister ITIL Vendors Scott Armstrong Feed
Popular contentToday's:All time:
NavigationBlog entries: 435
Podcasts: 48 BOKKED entries: 66 Other pages: 56 | |||||
A vendor perspective ...
Let me start with a "truth in advertising" declaration. I work for a vendor!
My personal bona fides include many years working for a major corporate entity, years running a help desk, consulting and managing developers. After all that I am a Product Manager responsible for metadata and CMDB technologies. That does not necessarily qualify me as an ITIL expert ... but it does qualify me to comment from certain specific perspectives. I expect to be subjected to the same rigorous evaluation as other commentators and to stand or fall by whatever value I add. Supposing that other commentators are equally open in declaring their interests, I think anyone who takes the trouble to write is worth a hearing.
LOL
LOL!
I am not longer working for a software vendor - but, I sure did for years - Peregrine and CA.
The vendors invest hundreds of millions and, when they started, virtually created the market - Peregrine, Remedy and others. They market and create demand for additional capabilities from the issues they collect from their customers. The software they create make it possible to do much of we do that was once just a dream because of the cost of a single organization developing the solution.
Should they reap the benefits? You bet!
Have they earned the right, to a good extent, to lead? You bet!
If you've got something to say the internet - blogging, etc. - gives you a very strong capability to have your say.
Clients are smart, they can, and do, think independently. ITIL is, in any version, much like the Pirate Code - more of a guideline. Clients apply it as they need to so that they can improve their operations.
When you think of vendors, don't think so much of the front-man hucksters up front, it's the real people in back that have the experience - and, in most cases they have very deep and broad experience. You've just not reached the right people.
I too worked for software
I too worked for software vendors for 20 years: mostly CA. Being in presales, and being a sociable type, I've had a lot to do with people from all the major vendors.
I think you overlook two points about vendors: the good guys don't rise to the top, and the hucksters are in the field being the face of the company. There are good people in every role in every company: what varies is the proportion and their ability to influence organisational behaviour.
Vendors have every right to a return on their investment. None of us are in ITSM for altruistic reasons - we'ree all here to make a living. They don't have any right to sell people inappropriate solutions, sometimes to non-existent problems.
Often people working for vendors de-humanise the customer: it is their own dumb fault for buying it; caveat emptor. If that's true then (a) all this talk of "partnering" is so much crap - sheep don't partner with wolves and (b) the community should defend itself, which is part of what this blog is about and a lot of what an ITIL professional association ought to be about [we've discussed how itSMF explicitly isn't about that, quite the opposite, because it isn't a professional association].
To address your second point, while vendors are an important voice in leading the industry, they should not be the primary one. They are focused on taking the industry in directions solely to their own advantage. This direction is biased by:
Caveat Emptor.
Some are in the software sales business, or hardware business, or some are in the process sales business (books, etc.). They sell products, one way or the other.
They are not in the customer success business. Their explicit job is to get the customer reasonably satisfied with the product they sell. There is a big difference.
It is not in the vendor's best interest – seriously – to encourage or enable solutions that suggest that their product isn’t “all that and a bag of chips.” By the way, the services organizations of these vendors still work for the vendors - the consultants who dispense advice continue to get their paycheck only when they support the product - not the customer.
Unless the company one is buying products or services from is wholly and personally dependent upon client success - as are you, as I understand it - to build their reputation and revenue, then caveat emptor.
Whether the knowledge leaders work at vendors, or training companies, or consulting firms, or are contractors - the buyer of these products and services need to understand the motivations of, and allegiance of, these "experts."
Generalizations
Corey,
While I fully support the notion of "caveat emptor" (heck, that was the title of my itSMF USA conference presentation this year), I think that your generalization of consulting services in products companies is both dangerous and misleading.
Any vendor that believes that it can just push product and not be concerned about customer success is living on borrowed time (or at least a significantly large bank account). The initial order is not *the* win -- opportunities for additional license and consulting services and maintenance renewals are.
As time passes, things change. As such, the dance between cusotmer and provider is never ending. Each needs to work ongoingly to ensure that there's a fit between what is requested and what is provided. Assumptions on either part will lead to unfulfilled expectations.
kengon
the software companies can't do it
Not sure I agree Ken. My experience is that the software companies have little solid consulting skills for any but their biggest customers. I.e. they have a handful of key people they can deploy to accounts that really matter, but for the bulk of the customer base the mega-consultants are wheeled in briefly if at all and the lion's share of "consulting" is done by dressed-up product techs.
There's a reason that companies like Pink and the hundreds of smaller pure-consulting firms make a good living: the software companies can't do it, or if they can then their ability to flog product far out-runs their ability to deliver associated services.
And don't forget margins on software start at about 30%, while margins on services peak at about 20%. Services can pay their own way but the profit is in the box.
Devil in the Details
Skep,
I agree and acknowledge that this is generally the case. The only issue that I took with Corey's statement was I felt his generalization was too broad. In the majority of cases, I think that his assessment is accurate.
I think that you are indeed correct, at least in my company, that the majority of the line personnel are solutions specialists not consultants. Over the years, the term consultant has been so twisted and tortured that it's a mere shadow of what it used to be.
Solutions specialists (or product techs, as you referred to them) have a mission -- deploy and enable the technology within the bounds of a given scope of work. That's what they should be used for and the milestone against which we should measure their (and the vendor as a whole) ability to deliver.
If we should be getting in the face of software companies for anything, I think it should be for trying to position a software solution to address more than it is capable of doing. To that end, caveat emptor is appropriate and necessary.
Both the vendor and the customer have a role in ensuring that the objectives and capabilities line up -- especially when you have multiple vendors in the mix. If a customer should idly trust the representations that a vendor makes, then they deserve whatever result they get. Ignorance of the area is no excuse, thinking through things is still required.
In most cases where problems have developed, I've found that there is culpability on both parts.
As far as margins go, I wholly disagree with your 20% number. It all depends on how the vendor is working. I think in many cases, it's substantially worse than 20%!! By the time you get through the various levels of discounting, you might be lucky to see that the billed rate is greater than the fully burdened headcount cost. The approach is what drives it. If the focus is not value added services (in the context of delivering solutions), then services are a part of the cost of sales -- regardless of whether it generates revenue. Product is king; forgetting that is a deadly sin in a product company.
kengon
when the consulting rubber hits the road
We are in agreement. I said "up to 20%" as in best case. Worst case is considerably less than zero percent return on services - it is easy to make a loss in services. therefore vendors maintain service divisions mainly to justify using the word "solution" instead of "product". As you say, product is king, and it shows when the consulting rubber hits the road.
Cary not Corey
Cary,
A friend noted that I misspelled your first name on my last post. Apologies for the oversight.
kengon