---------------------------------------------------------------------------------
Postings in the same series:
Part II: I Think I Saw An Alert.
Part III: Beyond The Alert.
---------------------------------------------------------------------------------
This series of postings won’t be about technology at all. Many postings have covered that aspect and future postings will do so as well. This series is about the way an organization could connect/interact with OpsMgr. The way the IT department works with it. Like any other tool, a hammer is only a hammer. It becomes something much more in the experienced hands of a craftsman who uses it to construct furniture or builds a house with it. (You don’t want to see me with a hammer. At least my wife doesn’t. So that toolbox is out of my sight. And to be frankly, I am happy with it.) 
The same comparison can be made for OpsMgr. However, this is not a tool, but a set of tools, like a toolbox. This toolbox certainly has added value for any organization. When being used properly it saves organizations much costly (down)time, unavailable servers, services, processes, LOBs and enhances the overall quality of the whole IT environment to a great extend. Thus making the organization as a whole more robust and competitive.
But as with any other tool/toolbox, one MUST read the enclosed user guides and comprehend them. But this is just a part of it. When the guides are read AND understood, the other workflows and processes must be in place as well. Otherwise the added value isn’t that big at all.
Huh? What am I talking about? Let make an example. Suppose you have a hammer. You understand and know how to use it. But there are no nails. No wood. Simply because no one thought about ordering it and getting it where it is needed. Nor is there any agreement whether to construct a table, a chair or a house. These latter items (nails, wood, the order process and the agreement on what to build) can be looked upon as the processes on any IT department. Lets bring it closer to home.
An Alert pops up in the OpsMgr Console. Okay. Monitoring is working. Great! But now what?
How to go about it? Are there any processes in place to get it fixed? Or do we look the other way, hoping that the Alert, and the underlying cause which triggered the Alert, disappears out of itself? How to keep track of the Alerts and the processes? How does one know that an Alert is already noticed AND acted upon? When gets an Alert escalated? And how? When will an Alert be closed? And how? 
As you can see, none of these questions are directly related to technology but more to the way the IT departments are organized. The way ITIL/MOF is shaped/translated to everyday life.
I will certainly not pretend to have all the answers. Nor will this series cover MOF/ITIL in any detail. I mean there tons of books/online guides out there doing (or trying, one better than the other) that already and doing a better job of it than I ever will. So I won’t go there. However, in this series I will give the outlines of what needs to be in place in order to get the best out of OpsMgr/SCOM.
How many postings this series will cover? That I do not know. Just keep an eye on my blog and you will see.
No comments:
Post a Comment