3 Reasons a CIO Should Care About Twitter — CIOUpdate.com

Senior IT executives / CIO's can also benefit from Twitter, according to CIOUpdate.com . The relevant observations excerpted below are a nice complement to my recent post Re: Should Project Managers Twitter? . So here are some of the potential business benefits of Twitter which (when balanced against the known Twitter security/privacy issues) can make sense for many organizations:

3 Reasons a CIO Should Care About Twitter — CIOUpdate.com: "...If all the buzz in the mass media isn’t enough to get you interested in Twitter, here are three solid business reasons why CIOs should devote some time to learning more:

1. Get Targeted Insights Faster - ... Some of the smartest people I meet haven’t devoted themselves to publishing or publicity that gets them a high Google ranking. But they are willing to share their experience and make themselves available for legitimate conversations.
Enter Twitter. Anyone can post their 140-character question, idea or comment on any topic. While the stream is uncensored and unfiltered, it is highly searchable. And because responses come in real time, it’s a channel that is particularly suited for time-sensitive information.

2. Participate in Social Media Innovation - ... the availability of Twitter’s API may present a direct opportunity for you and your company’s brand and products. Is there a way to utilize Twitter to support customer service (see @ComcastCares), promotions, order tracking, etc?

3. Expand Your Professional Network: ... as Twitter participation stabilizes will a valuable professional community emerge? There are some early signs that a viable CIO community exists on Twitter. At this point, I’ve identified over 70 CIOs across 20 industries. You can keep tabs on the growing community at http://www.ciodashboard.com/cio-twitter-dashboard . ..."

A Pragmatist's Guide to Structuring IT Asset Data, Scott Parkin, eWeek, 2008-01-18

A nice article describing the real-world ILM challenges for IT asset management. The ITSM benefits of of linking the asset's service-incident history to the incident-management system, including hard and soft costs per outage, seem significant. However, this does not seem common among the vast majority of the COTS helpdesk systems I have seen over the years, and certainly not among the Service Management modules of major ERP systems, let alone with integrated continuous auto-discovery/maintenance of all hardware and software assets found on the network... sigh....

Here is a snippet from the full eWeek article :

"... Track initial acquisition costs, including asset purchase, required peripheral or supporting devices, operating system and software (as needed), and service contracts:

Most of this data will come from purchase orders; some will need to be calculated as a pro-rata share of a bulk purchase or license agreement.

For new purchases, update your purchasing process to include calculating and tracking this data in your asset record; for existing assets you will need to create a project to go back and aggregate/calculate this information and add it to your asset records.

Track ongoing maintenance costs, including annual service contracts, upgrade or replacement parts and the costs associated with Service Desk incidents for each device.
Ideally, this information is collected at the time of purchase or service and is immediately attached to the asset's service history record as a function of your established process. You should update your Incident management process to support this, whether you update the asset record manually or through automated technology.
This can be the single most daunting task in the mix; extracting and aggregating historical data for existing assets is a gargantuan task. Many organizations choose to simply start tracking this data as of a specific date and leave existing data unstructured. This is a good method for those organizations that are resource-constrained and willing to wait for highly qualified data.
Identify replacement costs for hardware, software and infrastructure elements. Remember to include both disposal costs for existing assets and install/deployment costs for new assets.
For commodity items such as end-user hardware (desktop, laptop) and software, these costs should be predictable within a range and will tend to be updated once a year as new contracts are negotiated.
For high-impact or high-value items, the cost of purchase may only be a small part of the total costs, and those costs may be difficult to estimate. This data is intended for planning purposes and should be reviewed at the time of planning, so supply a best estimate with supporting documentation to be used as a starting point for further research, not as an authoritative declaration.
The key benefit here is being able to quickly view approximate costs for individual assets, to aggregate that data by department or cost center and to use that data in research and planning efforts...."

5 Steps to Measuring COE Value -

some nice graphs, and good review of the basics of service management best practices, not really limited to the context of that specific ERP product (ps - for the acronym-challenged: "COE" means Center of Excellence):

5 Steps to Measuring COE Value: "...The most common metrics have already been defined in the form of KPIs and by the Information Technology Infrastructure Library (ITIL), a set of best practices for IT service delivery. Be sure to make use of ITIL practices to define incident and change management processes, as necessary. Once you have selected the metrics and established the benchmarks, create an operational dashboard to track your progress. One of the global support metrics my organization tracks is incident resolution. “Sample Dashboard Graphics,” below, illustrates two ways to measure the support burden: incident by business unit and by time-to-resolution. These examples aren’t particularly granular. Typically, I drill down to get answers; my business partners only want to see results and progress. Any businessperson can understand these charts, the trends they represent, and what they mean...."

CA Introduces End-User Self Service BlackBerry Administration | RIMarkable

An interesting concept... however ROI appears unclear unless this would obviate lots of ongoing blackberry support (i.e. why bother with Yet Another System to manage, unless it is beyond the initial setup on BES etc...)

CA Introduces End-User Self Service BlackBerry Administration | RIMarkable | The official, unofficial BlackBerry Weblog: "...The key point here for BlackBerry end-users is that they can go buy a new device, go to a web page, and hook their BlackBerry up to their work email without having to call the helpdesk."

Change Management/ITIL/Root Causes - Information Security Magazine

Nice perspective on ITIL, and the ideal goal of proactively identifying root-causes for meaningful followups:

Seven Winners, One Mission - Information Security Magazine:
"'...we shouldn't be doing security for the sake of doing security. We should be doing security because we're running a business,' Riggs says. Service management is a Reuters-wide mandate, one spawned three years ago as a regimen of strict best practices based on the popular U.K. ITIL standard. Riggs is also working to integrate IT security as a global discipline into ITIL best practices. 'As a company we've been banging the drum about customer service, and we're pushing hard to ensure things are done in a systematic, disciplined way to make the customer experience even better,' Riggs says. Reuters' customers measure performance in hundredths or thousandths of seconds; latency is not tolerated. Thus it is dogged work tracking a complex environment of real-time data feeds, historical databases and an infrastructure of 30,000 switches, routers and more than 1,300 firewalls. A standardized service management approach is the only logical means of keeping such complexity reined in, Riggs says. In addition, the company has unified operations and security around incident, problem, configuration, change and release management processes. For example, Reuters' security analysts examine every security incident--whether it caused a disruption or not--to understand a root cause of the management behavior that failed and why a service was not resilient. Finding the root cause allows Riggs' team to apply that information elsewhere and mitigate future events. Modeling exercises, meanwhile, allow them to anticipate problems in the event of future incidents or scheduled network changes, which can number hundreds per week.

"You always expect your infrastructure to come under attack. But if it fails, you have to understand the real underlying root cause. Was it a network design problem, a third-party quality failure, capacity overrun or did it fail because of a configuration problem?" Riggs says. "We want to pinpoint this as well as any aggravating factors and triggers...and then see where we may be exposed elsewhere and fix it before it causes customer pain."

Riggs has tried to instill that uniformity up and down Reuters' supply chain as well.

"I treat them as a virtual extension of my team, and expect them to behave in a certain way." Riggs says. "That's what I expect of the products they deliver...."

----------------
Now playing: Jimmy Buffett - Island
via FoxyTunes