<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.2.1" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: Forrester Report: Knocking The NOC: Enter The New Operations Center</title>
	<link>http://itsm.glennodonnell.com/2009/06/18/forrester-report-knocking-the-noc-enter-the-new-operations-center/</link>
	<description>Glenn O'Donnell's IT Service Management Blog</description>
	<pubDate>Sat, 31 Jul 2010 17:49:28 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.2.1</generator>

	<item>
		<title>By: Douglas W. Stevenson</title>
		<link>http://itsm.glennodonnell.com/2009/06/18/forrester-report-knocking-the-noc-enter-the-new-operations-center/#comment-3407</link>
		<author>Douglas W. Stevenson</author>
		<pubDate>Fri, 24 Jul 2009 22:49:27 +0000</pubDate>
		<guid>http://itsm.glennodonnell.com/2009/06/18/forrester-report-knocking-the-noc-enter-the-new-operations-center/#comment-3407</guid>
		<description>I actually got to read it...

C3I, while it establishes a chain of command and deals with span of control, you really didn't lay out the principles behind C3I. It isn't the top down structure that you propose that makes C3I work, its the fact that the decision making is done at the lowest level possible and that the information needed for effective C3I is based upon Situational Awareness.

Guidance?  We need to be empowered.

The NOC actually began earlier than the 90s.  Networking was not a new innovation and it was not so immature as you tout.  SNA networks abounded and they are VERY STRUCTURED.  Telco networks in like manner. AT&#38;T Datakit... Remember.

It wasn't always called the NOC. In fact I've seen a multitude of names.  In AOL, there were 64 NOCs distributed around the world. Boeing's Banana was an excellent Operations Center. Again, you're hung up on a name.

Where is the Service Desk?

I think your model is askew here.  In the most effective Operations organizations, "Help Desks" that just route calls need to go away. Have folks that are customer facing that cannot solve problems is a HUGE waste of money. Having Generalists that only know ITIL is making the problem much worse.  I want folks that can think on their feet, go through incident resolution and work arounds VERY QUICKLY, and have great customer skills.

When Incidents become problems or an incident takes too long, then escalate. Drive as much knowledge and problem solving at the first interface with the customer, as you can.  Triage and SME and even Engineering Teams need to make problems into incidents by documenting the process and knowledge around restoration.

I don't want IT Operational automation tools experts on the desk! DOH!  I want them EMPOWERIN G Level 2, 3 and 4 personnel to share knowledge and process down to the lowest level necessary to make the decisions.

Dude. In your 3 levels of incident escalation.What are you talking about?  In ITIL, an Incident is a problem that has a known corrective action or workaround. A Problem is an incident that requires further diagnosis / investigation to correct the issue.

I don't get the "Breadth" of technical skill.  As technical folks mature, they get exposed to alot more problem sets, situations, and technologies.  Like me - I can admin a box, perform a vulnerability test, analyze sniffer traces, or diagnose BGP issues. (Not to mention I might know a wee bit about enterprise management applications.)

Dude, I think your paper is so far off the mark.... I think it is misleading, uninformed, and frankly dangerous.  In the wrong hands, this mentality could literally destroy an IT organization.</description>
		<content:encoded><![CDATA[<p>I actually got to read it&#8230;</p>
<p>C3I, while it establishes a chain of command and deals with span of control, you really didn&#8217;t lay out the principles behind C3I. It isn&#8217;t the top down structure that you propose that makes C3I work, its the fact that the decision making is done at the lowest level possible and that the information needed for effective C3I is based upon Situational Awareness.</p>
<p>Guidance?  We need to be empowered.</p>
<p>The NOC actually began earlier than the 90s.  Networking was not a new innovation and it was not so immature as you tout.  SNA networks abounded and they are VERY STRUCTURED.  Telco networks in like manner. AT&amp;T Datakit&#8230; Remember.</p>
<p>It wasn&#8217;t always called the NOC. In fact I&#8217;ve seen a multitude of names.  In AOL, there were 64 NOCs distributed around the world. Boeing&#8217;s Banana was an excellent Operations Center. Again, you&#8217;re hung up on a name.</p>
<p>Where is the Service Desk?</p>
<p>I think your model is askew here.  In the most effective Operations organizations, &#8220;Help Desks&#8221; that just route calls need to go away. Have folks that are customer facing that cannot solve problems is a HUGE waste of money. Having Generalists that only know ITIL is making the problem much worse.  I want folks that can think on their feet, go through incident resolution and work arounds VERY QUICKLY, and have great customer skills.</p>
<p>When Incidents become problems or an incident takes too long, then escalate. Drive as much knowledge and problem solving at the first interface with the customer, as you can.  Triage and SME and even Engineering Teams need to make problems into incidents by documenting the process and knowledge around restoration.</p>
<p>I don&#8217;t want IT Operational automation tools experts on the desk! DOH!  I want them EMPOWERIN G Level 2, 3 and 4 personnel to share knowledge and process down to the lowest level necessary to make the decisions.</p>
<p>Dude. In your 3 levels of incident escalation.What are you talking about?  In ITIL, an Incident is a problem that has a known corrective action or workaround. A Problem is an incident that requires further diagnosis / investigation to correct the issue.</p>
<p>I don&#8217;t get the &#8220;Breadth&#8221; of technical skill.  As technical folks mature, they get exposed to alot more problem sets, situations, and technologies.  Like me - I can admin a box, perform a vulnerability test, analyze sniffer traces, or diagnose BGP issues. (Not to mention I might know a wee bit about enterprise management applications.)</p>
<p>Dude, I think your paper is so far off the mark&#8230;. I think it is misleading, uninformed, and frankly dangerous.  In the wrong hands, this mentality could literally destroy an IT organization.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
