Don't run IT as a business, run it as part of the business
"Run IT as a business". What a mantra. It is of course rubbish. You run business as a business.
"Run IT as a business". I've been guilty of using it in the dim dark past. If providing IT is your business, say you are EDS, then that is a special case where the mantra makes sense. But for most organisations, running IT as an internal business is counter-productive if not downright destructive. In most situations, IT is a team-member not a supplier.
Infoworld blogger Bob lewis concurs:
IT must be integrated into the heart of the enterprise, and everyone in IT must collaborate as a peer with those in the business who need what they do.
Nobody in IT should ever say, "You're my customer and my job is to make sure you're satisfied," or ask, "What do you want me to do?"
Instead, they should say, "My job is to help you and the company succeed," followed by "Show me how you do things now," and "Let's figure out a better way of getting this done."
Rodrigo Flores thinks it isn't quite right:
I can't argue with the attitude and attitude is important. Yet, ... the funding models are: the customer pays for it or there's a funding process in which different projects compete. So if the customer pays for it, then it'd like IT to behave like a business. If on the other hand, it's "free" and it's just a matter of playing smart politics, then IT has no incentive to improve efficiencies... You can't hold a LoB executive accountable for revenue, profitability, margin, and other metrics, and then tell them this large part of their cost model is off limits.
Being the level-headed moderate that I am :p I want to take the middle ground. In a large traditional organisation, Rodrigo is right that IT services should be costed, and paid for by the customers. And I still believe it is useful to define a service catalogue for the IT department and to manage what IT delivers as services to customers.
That's not necessarily true in a small organisation or in the modern cloudy organisation. In small organisations IT is not necessarily required to run as a cost centre. They might not even have a budget. IT costs are managed as part of the overall management of the organisation.
And in the modern world, IT is becoming a thin veneer over outsourced systems. In some cases, other business units may hold the contractual and payment relationships directly with those system providers - the money won't even flow through IT any more and the services won't be chosen from an IT catalogue. (Posting on this soon)
I'd add one more point Rodrigo didn't mention: IT decisions should be made based on a business case not technical criteria or opinion. But you don't have to be a distinct business-within-a-business to build business cases. In fact any business case for an IT decision should be a case for the organisation as a whole, not for IT as a cost-centre (or worse still a profit-centre).
And costing and catalogue and business cases are only part of "running IT Like a business". Running a business means focusing on your own profitability, ensuring customer success only where it is in your own interests, disclosing only that which you wish to, cutting unprofitable customers.
Being an integral part of the same organisational team means (in theory) all working for the same goals of the overall organisation, collaborating, sharing resources, taking one for the team.
Sure petty politics and base human nature means that organisational units compete and act in their own interests, but that doesn't mean we should enshrine that behaviour in a formal structure. But that's what "running IT as a business" does.
Not only that but "running IT as a business" causes IT to replicate organisational functions. This is the cause of the confusion between organisational change and IT change - there should only be one. (IT also ends up running organisational change in many organisations because the organisation is deficient, but that is a different discussion)
Likewise why does IT have Release? - it is just project rollout. Why does IT run projects? At least THAT mistake is being corrected in many organisations at last, with Programme/Project Management Office becoming a corporate function not an IT one.
It is funny that this IT Skeptic journey started 6 years ago with Alan Mayo, at the time Chief Architect at a big retailer here in NZ, saying SLAs are divisive, destructive to teaming. I think he may be right. Certainly if we take "run IT as a business" too literally we'll dissociate ourselves from our colleagues and team-mates. By all means charge them for services, and manage closely what you deliver for them, but don't treat them like they work for somebody else.
Made in New Zealand 
Comments
Run IT in the business
I think that most people had the right intention when they began to chant a simple quote "Run IT as a business" to change the thinking in their IT organization. Unfortunately, I feel it was lost on most how the details were to unfold into running an IT organization more professionally rather than as an actual business.
Here's my take on the topic for those interested: http://blogs.msdn.com/b/gabriel_morgan/archive/2011/06/09/strategically-...
Storage as a service?
Re-opening this. What do folks think of this "storage as a service" blog by EMC's Chuck Hollis?
Notable quote: "Not only does ITaaS make sense for the entire IT function: the "as-a-service" concept can be recursively applied to underlying IT disciplines, often with great results. And storage is no exception."
Can storage be a service? Pretty low level and techie. What business person wants a raw chunk of SAN? If even "applications" are too "technical" for business people to care about?
Seems like a line of thinking that some would take issue with. Me, I have no problems.
Charles T. Betz
http://www.erp4it.com
Not all consumers of a service are external to IT
Thanks for the RT, Charles, much appreciated.
We're finding that in larger organizations, the primary consumer of ITaaS is, well, other parts of IT vs. direct business users who still need higher-touch engagements.
Storage is turning out to be an exception in some organizations. The fact that some group or another might need to stash a bunch of data in a file system isn't as unusual as you might think.
Would be glad to discuss more around what we're seeing in more progressive IT shops around these thoughts.
Chuck
Running IT as a business
Over on a Microsoft blog, Nick Malik argued against Bob Lewis's post. Nick thinks we should run IT as a business.
I commented on that blog (or I think I did: in true Microsoft fashion the comment disappeared without any message. I'm hoping it is awaiting moderation. Or maybe it was because I was using Chrome):
You don't have to run as a business in order to run as a service. You don't even have to run as a business in order to charge-back your service.
Though in the small number of larger organisations that actually achieve true selling of services, their IT department is effectively becoming a separate service provider business, with all the positive and negative impacts that can have: positive efficiencies and customer focus, negative breakdown of team spirit and organisational unity
Leave the "IT" in "ITSM"
I recommend this thought-provoking article from Charles Betz:
Keep both IT and Infrastructure
I agree with Charlie that IT needs to stay in ITSM. IT is the Business only if IT is your business i.e. the line blurs if you sell IT services.
Another approach to drop IT from ITSM states that there are general Service Management principles that can be applied in any service industry. I don't believe in that. Many service industries are far ahead of IT and the challenges IT has are different. I noticed in a recent email from Ian Clayton that while he talks about general service management, he still mentions "...the challenges of a typical IT service provider organization" in his course description.
But there is also a blurred line at the second I of ITIL. Information Technology Infrastructure is not really the same thing as the whole IT, at least it should not be. In railway terms, infrastructure is the tecnology which enables trains to run. A service is a train on a specific time from place A to B, and an Interrail ticket (with which you can travel on European trains as much as you wish) is an Service Offering. A single framework for the whole railway business does not make sense, the far ends of the business are so different with completely different lifecycles. There would be confusion if a new service means:
1) a new high speed railway to be opened by 2030
2) 7:15 on Saturdays from Helsinki to St Petersburg starting next December
3) A special family package in next July
Instead of ITSM, maybe we should talk about ITISSM, Information Technology Infrastructure Service Management as a separate subject, which manages the common platform that several services use.
Aale
Service Integration
As someone who has flitted between the customer side, the IT department and IT service providers I would agree with Aale.
For many ITSM experts the lack of customer focus jumps out at them, but looking at it form the other perspective it isn't as if ITIL goes into any of the technical aspects of providing production IT infrastructure in any detail. I'm not talking about the use of specific tools here, which don't have a place in a generic framework, but areas like queuing theory and probability, and for that matter basic management accounting. Far be it for me to suggest that one reason for this is that most of those involved in Castle ITIL have little knowledge of these areas.
Let us not forget that in reality a lot of the role of service management teams is, in reality, dealing with the aftermath of failures in the basic ability to deliver and design technical services correctly, and with the consequences of deficient or ill managed contracts.
So yes, let us split ITIL, and ISO 20k into two, a service management aspect to deal with the Supplier>IT department>customer>user chain, and another to make sure the technical requirements are correctly defined, designed and delivered. Let us be very explicit about bring application management into the same framework as infrastructure, and don't forget the need for high level governance. Throw in an integrated approach to portfolio, program and project management, with all the elements sharing a common language and defined interfaces, and we might be starting to get somewhere.
In TCS we talk about this as part of our Service Integration proposition.
James Finister
www.tcs.com
http://coreitsm.blogspot.com/
Business-like not "as a business"
I totally agree with your point of view here. I incoherently blogged about it three years ago - i wonder if I can do better now.
IT in a business is there solely - and I do mean solely - to assist the business to attain it's objectives (profit, assisting community - it varies). We are a service dept - nothing more, and nothing less. We do need to be business-like - all of the *-managements need to be professionally ... well, managed. Things like financial management, supplier management etc. We need to be business-like. But we are not a business (unless you're an outsourcer - where IT *is* your business).
We support the business - when people try to tell me that they are running the IT dept as a business I wonder whether the business values the competition. Do they mean they are trying to make a profit from the host business? Are they parasitically sucking the host business dry while they try to be the enterprise?
Hopefully not - but sometimes I wonder if they are taking Skep's more satirical books as a how-to manual.
An old concern
As Terence Quinlan, former Bank of America IT finance leader and now president of the IT Financial Management Association notes, “Managing lS financially as a business does not require a profit center structure. lS can remain a cost center.”
No one who has ever written about IT as a business (and as I noted above, it's a 40 year old thought experiment) has ever gone down this road with the intention of "making a profit from the host business." These are good, careful authors with many decades of senior IT experience between them.
More here.
Charles T. Betz
http://www.erp4it.com
of course that's not INTENDED
No one writing about IT-as-a-business would intentionally be encouraging the IT dept to hurt the host-business.
BUT the risks of this happening are very real - your blog post seems to recognize this (fantastic to see such a well cited and analytic post btw).
Captive cost centers can be subject to all of the worst aspects of living under a monopoly. Driving resources away from doing whatever the business is trying to do, diverting them to meet the aims & desires of IT. There is a danger of IT losing sight of it's real mission - facilitating the outcomes the business wants to achieve.
Many of the tools relevant to running a business may aid efficient running of a dept. Which is why I prefer "business-like" as a phrase rather than "as a business".
Business IT Alignment should be ...
Synchronicity... As I have shared in a whitepaper, article and presentation, Alignment is "following", synchronicity is partnering and perhaps leading. So to me, Alignment is table stakes (pay to play) that many IT organization even fail to accomplish. To get a seat at the table, IT has to get beyond keeping the lights on and has to demonstrate true business value (in however that is defined by BOTH business and IT).
Entwinement... Sharing in business risk, something IT hasn't had to do in a long time. Before Smartphones, tablets, the Cloud, and the worst economic conditions since the late 20's, IT had it pretty good - highly immune from business risk that most other departments and parts of the business had to share. This is NO LONGER the case. IT has been forced to reactively share risk, and the progressive, forward-thinking IT organizations are getting better at identifying and managing business risk (like a business) vs. reacting and waiting for risks to appear in the business environment.
So I would tend to agree; SLA's should only look like contracts when you are dealing with MSP's, ISP's, or service providers where you don't have shared risk and shared reward. SLA's should look like simple "agreements" as the acronym states, that simply documents "Here is how we are going to work together and what you can expect" with of course the ability to negotiate if more or less is needed due to cost, quality, risk, etc.
I just gave a presentation this morning to a LIG on Business/IT Relationship repair (presented as a 12 step program). One of those steps was managing to a P&L, Income Statement and Balance Sheet vs. managing to a budget. If you know your services, costs, assets, expenditures, etc - then this excercise is easier than if you don't and budget becomes something you manage vs something that is provided to you (and reduced each year).
LOVE This topic!
John M. Clark
Running IT As A Business
Great article Skep.
Couldn't agree more. I have always advised organisations NOT to implement SLM if it is not needed. If you have internal customers who are happy with the services delivered by IT and there is a good (or reasonable) working relationship, why introduce SLM and SLAs?
The same applies for lots of things I guess. If it's not broken - don't try and fix it.
Which is why IT should be an inherent part of the business and not a part from the business. Work out what is needed to be improved from a business perspective (not an IT one) and focus on that.
Cheers
Karen
yes, businesses are fractal
The "business within a business" concept is not limited to IT. I side with Womack and Jones in Lean Thinking:
Finally, we've discovered that these value stream and product line managers, like so much in the lean world, are 'fractal'.
That is, a product line manager overseeing an entire product may work with a number of value stream managers at lower levels taking responsibility for different courses of the value stream. For example, a chief engineer (to use Toyota's term for a product line manager overseeing an entire automotive platform) works with a development leader in design, a value stream manager in the assembly plant, and value stream managers in each of the component plants working on major items assembled into the finished product. Each manager is essentially doing the same job but with varying scope—wide at the top and narrow at the bottom.
This debate is not going away any time soon. There are good reasons for viewing a problem as scale-free. There is also such a thing as the scaling fallacy (viewing a thing as fractal when, at a certain level of decomposition or aggregation, it ultimately is not...)
Charles T. Betz
http://www.erp4it.com
scaling fallacy
"the scaling fallacy (viewing a thing as fractal when, at a certain level of decomposition or aggregation, it ultimately is not...)" Yes as I read the extract I could hear Wally (of Dilbert fame) saying how he was maximising his value delivery or developing his customer service catalogue or some such.
Whenever some tiny group within IT wants to tell me they deliver "services" I can usually pop that bubble pretty quick by asking about their customer relations, cost model, catalogue, service levels, availability management, continuity plans...
Personally I think it's the 5% Club again. In the rarified heights where you live, IT-as-a-business might often make sense, but not down here. And even when it does appear a good idea you gotta ask whether it sets the wrong mindset and sends the wrong message. We all work for the same place.
a 40-year old thought experiment
Have answered with a little history of the thinking here.
That's like a business within a business
Dean Meyer has been saying for that it is really a business-within-a-business for about a decade.
www.fullcost.com
The fastest way to reach a rationalized and prices service portfolio, and catalog, is to organize around services with a budget.
The "thin veneer" is a good line.
Organizing around core services as prime contractors and supporting services as subcontractors is the way to get prepared for the increasing disintermediation that is IT's future.
Combine that with real time-driven activity-based costing capture of details, and maybe design for six sigma, throw in a little of Ian Clayton's very pertinent outside-in thinking and we may not just all get outsourced.
It is a great idea
Running IT as business within a corporation is a great idea, think about it. Just make sure that you have total monopoly and can set your prices. It is actually the only way for internal IT people to get rich. Set the prices right and let the bonuses and expences flow ;)
The downside is that the happiness will not last long.
Aale
SLA's
Well said.
I tweeted just yesterday, "I can't help but wonder if SLA's inherently cast IT as an adversary against the business by assuming best effort is not applied."
There are significant differences between partnership, alignment and integration.