I'm proud to discuss my latest project : the Alberta Internet Exchange. It mixes the concepts of Open Source and public interest really well. I have been asked to contribute to the architecture committee, and am happy to participate !
So what is an Internet Exchange, you ask... The idea is to peer member networks together, so that they don't have to traverse the Internet itself in order to exchange data. Think of it like a chat-room: interested parties can join the chat-room and exchange information, without having their data traverse the Internet & return via Des Moines or Beijing ! This video helps explain it really well. The Eurpoean IX
What makes the Internet Exchange so exciting to me is that it will be made available for the smaller Internet Serice Providers and clients alike, so that they can compete on a level playing-field with the big Telcos. This offers the users of the service abundant choice to determine which provider can best suit their needs. Most importantly, it serves the needs of Western Canada, who wold otherwise be forced to peer at Toronto or Seattle.
Sunday, November 25, 2012
Sunday, November 18, 2012
The Importance of Process
According to ITIL, a Service is made up of people, process and technology. All too often, the organization believes that they can simply purchase and implement a tool, and all of their problems will miraculously disappear. I am working with two clients, who are approaching their delivery of a Service differently.
The first client is a large player in the Energy sector. To date, they have eschewed the use of ITIL terms to define their IT Service, as it doesn't readily fit their model for doing business. How could they let IT tell them how to run their business ?
When this client wanted to clean up their IT monitoring systems, they chose to segment the work into business-identifiable Services. They presumed they could buy a tool, and their visibility into their IT Operations would magically improve. They have been profitably in business for decades, so surely their processes and people were fine ?
In examining the first Service, it became apparent that the technology they were employing was actually satisfying 90% of their needs. It seemed the issues came up after the monitoring system alerted to a problem. Multiple service tickets were generated, usually causing a firestorm of activity - usually within the wrong groups ! To exacerbate the issue, the groups weren't communicating. This meant there was almost always a large duplication of troubleshooting effort.
In the case of the first client, the processes which were initiated were the root-cause of their issues. The technology did what it was supposed to do: send an alert when a problem arose. The people simply followed the process and reacted to the alert in a timely fashion. Unfortunately the process didn't allow for communication and co-ordination of their efforts, leading to delays and confusion in the IT personnel.
The second client is a small services company. They are re-building the company from the ground up; I call it going back into startup mode. In so doing, they are examining the services they provide to their clients. From the very basest levels, they want to be able to create repeatable, sustainable & desirable solutions for their clients.
This is being achieved by turning everything they do into a "project", with somebody responsible for managing that project at the helm. Project Management 101 would tell us that the Project Manager is responsible for Resources, Timeline and Budget - does this sound like what a Management Team should be concerned about ? So whether it is a team which is conducting Research and Development on a new physical product, or the Marketing guy working on building a new web-site, everything is a project. This provides visibility into "who ?", "when ?" and "how much ?" questions.
What this also means is that the second client can begin to normalize their Operations. By treating everything like a project, they have a repeatable framework to follow. The standard body of documentation required for every project (Charter, Cost/Benefit Analysis, Project Plan, Work Breakdown Structure and Closeout Report) allows for repeatability. Need a tower built ? Here's the required artifacts. Need a portable antenna installed ? Heres the project plan.
This will allow the client to have very tight control over their operations. This leads to increased productivity of the resources, as well as predictability in their Finance department, in terms of budget and revenue. The Sales and Business Development people can look at an exisiting Project Plan and estimate for themselves roughly how long it should take to complete a project. Further, if they are simply repeating a pre-exisiting project, they can likely provide a pricing quotation on their own.
So in both cases, we are seeing how these two very different clients are approaching their issues by examining the Services they provide. And in so doing, they are recognizing the importance of having well-documented procedures for their people to follow. The technologies they employ are all but irrelevant.
Subscribe to:
Posts (Atom)