Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: CAnivitti
New Today: 8
New Yesterday: 86
Overall: 139907

People Online:
Visitors: 50
Members: 2
Total: 52 .

Languages
Select Interface Language:


Major ITIL Portals
For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone

Related Resources
Service related resources
Service Level Agreement
Outsourcing

Note: ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.


The Itil Community Forum: Forums

ITIL :: View topic - ITIL Implementation Plan Draft
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

ITIL Implementation Plan Draft
Goto page 1, 2  Next
 
Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion
View previous topic :: View next topic  
Author Message
query
Itiler


Joined: Feb 02, 2006
Posts: 41
Location: Sydney, Australia

PostPosted: Mon Jul 10, 2006 2:20 pm    Post subject: ITIL Implementation Plan Draft Reply with quote

So I finally got my Foundation Certificate and it looks like ITIL Implementation design will be the next big thing. Here's a very rough / quick draft of my plans of Implementing Service Support Component for my employer at the moment. I'm sure I have missed a few things at this stage, but in any case for starters, what do you guys / girls think?


1. Conduct ITIL Inhouse Training covering Service Support with IT Service desk Team and IT Manager
2. Design of CMDB
3. Design of Service Support Management Components to link into CMDB
4. Service Support Management Procedure
5. Assignment of Service Support Management Tasks, Responsibilities and Controls
6. Service Support Management Components Build
7. Service Support Management Components Implementation

Each one of these index items will have different branches discussing all the subtleties of this implementation, but I didn't want to put in too much as this stage as not to confuse anybody. Any questions? Please feel free to ask, I will clarify Smile
Back to top
View user's profile
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Tue Jul 11, 2006 8:37 am    Post subject: Reply with quote

Query,

May I please ask what your estimated resource counts, timeframes and costs will be for each step? Also, how big is the organization you're rolling it all out to?

Regards,
_________________
[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
query
Itiler


Joined: Feb 02, 2006
Posts: 41
Location: Sydney, Australia

PostPosted: Tue Jul 11, 2006 10:55 am    Post subject: Reply with quote

Guerino1 wrote:
Query,

May I please ask what your estimated resource counts, timeframes and costs will be for each step? Also, how big is the organization you're rolling it all out to?

Regards,


There are no estimated costs at this stage. Most of the costs will be development costs (I.e. time of the developers) and so far this has been taken into account by the management. Once the designs for CMDB and Service Management Componentes are finalised, the costs will be a little bit clearer.

Now, the timeframe is a different issue all together. Even though this is a project, it's medium priority and subject to be overtaken by higher priority projects. However, to get a rough estimate I view it in the following manner:

1. Conduct ITIL Inhouse Training covering Service Support with IT Service desk Team and IT Manager - 2 Weeks to prepare Inhouse Training Material and 3 weeks to finalise training with all of the relevant people / teams.
2. Design of CMDB - Group discussion and facillitation. Teams will agree on extra additions required for the current basics. IT Manager will accept the design. I think maybe 4 - 8 weeks
3. Design of Service Support Management Components to link into CMDB - As above, with extra 4 - 8 Weeks
4. Service Support Management Procedure - Document that summarises the Operations of the Service Support, another 4 weeks
5. Assignment of Service Support Management Tasks, Responsibilities and Controls - Discussion with IT Manager and relevant groups, I estimate 2 Weeks
6. Service Support Management Components Build - Will Depend on availability and work load of developers
7. Service Support Management Components Implementation - Really, this will be an ongoing proccess which will involve build of awareness of ITIL Implemntation with users and every one involved. I am looking at newsletter announcements announcing the completed goals as well as benefits.

Our organization is 200 people.

Hope this clarifies it a little, am I missing something? Smile
Back to top
View user's profile
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Tue Jul 11, 2006 1:26 pm    Post subject: Reply with quote

Query,

I'm going to provide you with some information that I've learned from experiences I've had, both, with past employers and current customers who've implemented ITIL solutions. You can choose to accept or ignore what I offer but I strongly recommend you, at very least, seriously think about all of it.

Please find details, below...

query wrote:
There are no estimated costs at this stage. Most of the costs will be development costs (I.e. time of the developers) and so far this has been taken into account by the management. Once the designs for CMDB and Service Management Componentes are finalised, the costs will be a little bit clearer.


If your CMDB is going to be a simple spreadsheet based CMDB, then it shouldn't take you 4 to 8 weeks, as you can probably find some basic templates to leverage.

If your CMDB is going to be an application, you're about to embark on a very long, expensive, and painful journey. You may even be making a very bad business decision. A real CMDB will need the following:

1) A database
2) A machine to run the database on
3) Batch Jobs to load the database based on compiled files
4) Agents that write to the CMDB
5) Developers for the Database
6) Developers for the Batch Jobs
7) Developers for the Agents
8 ) A presentation and business logic tier for the CMDB, which will possibly be written in Java or .NET
9) Developers for the engine and its business logic
10) Developers for the presentation tier
11) You will most likely require a dedicated Software Application Server
12) You will most likely require a dedicated hardware server for the Software Application Server, as you won't want to run the two on the same machine.
13) You will need Business Intelligence/Reporting tools to create relevant reports.
14) This will require dedicated Business Intelligence/Reporting expertise, meaning developers.
15) You will need a significant amount of storage for all the files you will use for uploading to or downloading from, not to mention for backups, and to accommodate CMDB growth, both for historical trending information as well as inventory of information as your enterprise grows.
16) You will need to document the application to conform to best practices.
17) You will need to maintain the entire application for bug fixes and new features, as you grow, requiring multiple ongoing releases over multiple years.
18 ) If it needs to be HA and/or Mirrored, then you will need to add in those costs, as well.

A third option, which you didn't seem to mention, was to look at Vendor CMDBs, which will be far more elaborate than anything you will deliver, and which will outpace your own design, very rapidly and cost effectively. They will also be up and running in a fraction of the time of anything you can deliver, yourself.

If you go with spreadsheets, you're being prudent, realizing that you need to start somewhere but that you are not an expert in CMDBs. This means that as you outgrow the spreadsheets and your executive management believes in your implementation they will "buy" a real CMDB from specialists.

If you do not go with spreadsheets and you decide to build your own CMDB, please be ware. Please realize that you and your organization are far from experts on designing, building, and maintaining CMDBs. As a result, you will be entrenching your organization in a very limited and non-scalable design that will be "VERY LIMITED" in functionality. As a result, it has a very high probability of meeting the needs of only a handful of stakeholders and there is a very high probability that most other stakeholders will not only avoid it but also publicly shun it. The first group to do this will be any software developers you have in-house, as they will be the first to realize that you haven't really built a CMDB but nothing more than an inventory database that doesn't meet their own needs. Please be aware that anything less than what was specified above is not a really a CMDB but a little database application that will not scale and will most likely cause your organization a great deal of grief.

I haven't even gotten into the requirements for a truly adequate CMDB. The requirements list is "huge" and you'll need to be able to do things like the following, at a minimum:

1) You must be to track any and all dependencies between anything and everything in the CMDB. This includes multiple dependencies and circular dependencies.
2) You must be able to visually render any and all dependencies between anything and everything.
3) You must be able to distinguish between sources and targets and understand the relationships types between them.
4) You'll need to be able to go back in time, as your CMDB will need to give you past configurations to compare to current configurations.
5) You'll need to be able to track histories and create and render trends.

There's so much more. The list of enormous.

Quote:
Now, the timeframe is a different issue all together. Even though this is a project, it's medium priority and subject to be overtaken by higher priority projects. However, to get a rough estimate I view it in the following manner:

1. Conduct ITIL Inhouse Training covering Service Support with IT Service desk Team and IT Manager - 2 Weeks to prepare Inhouse Training Material and 3 weeks to finalise training with all of the relevant people / teams.


I recommend you double these estimates.

Quote:
2. Design of CMDB - Group discussion and facillitation. Teams will agree on extra additions required for the current basics. IT Manager will accept the design. I think maybe 4 - 8 weeks


A good design will take a competent design team close to a year. We've seen this in multiple organizations. And this isn't even for one that's good enough to resell.

Quote:
3. Design of Service Support Management Components to link into CMDB - As above, with extra 4 - 8 Weeks


I don't know what you mean by this. Can you please elaborate?

Quote:
4. Service Support Management Procedure - Document that summarises the Operations of the Service Support, another 4 weeks


At a minimum. Possibly double, by the time it's all done and vetted out.

Quote:
5. Assignment of Service Support Management Tasks, Responsibilities and Controls - Discussion with IT Manager and relevant groups, I estimate 2 Weeks


Quote:
6. Service Support Management Components Build - Will Depend on availability and work load of developers


This will take approximately three to four times the design time, as your teams will need to build, deploy, and test, multiple times.

Quote:
7. Service Support Management Components Implementation - Really, this will be an ongoing proccess which will involve build of awareness of ITIL Implemntation with users and every one involved. I am looking at newsletter announcements announcing the completed goals as well as benefits.


Again, this should take at least three to four times the design time.


Quote:
Our organization is 200 people.


This means you have a significant number of Assets that you will need to cover in the CMDB. You will also need to integrate (at a minimum) Incidents, Problems, Products, Changes, and Releases into the CMDB from your other systems.

Every organization we have worked for, worked with, and/or spoken to about implementing any part of ITIL has always estimated and planned way low, when compared to the reality of what it actually cost them and required from a resource and time perspective. As a result, every single project initiated by these companies has had some form of cost and/or time overruns or has fallen very short of a satisfactory implementation, leaving organizations in a position to own and manage solutions that are far from their original visions. By the time we get in, they're usually disillusioned and/or disgusted with the whole effort. Please be VERY careful.

I know this all sounds very rough but I don't want you to be in a position of falling short of what you promised your organization. ITIL processes, themselves, will be hard enough to deploy and champion throughout an organization. Throwing in the design and implementation of pieces of infrastructure to support it will most likely turn the odds against your success.

I hope this information helps.

Regards,
_________________
[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
query
Itiler


Joined: Feb 02, 2006
Posts: 41
Location: Sydney, Australia

PostPosted: Tue Jul 11, 2006 2:30 pm    Post subject: Reply with quote

Guerino1 wrote:
Query,

I'm going to provide you with some information that I've learned from experiences I've had, both, with past employers and current customers who've implemented ITIL solutions. You can choose to accept or ignore what I offer but I strongly recommend you, at very least, seriously think about all of it.



Wow, some real food for thougt here Guerino1. Thanks for that.

Okay, where do I begin.

Guerino1 wrote:
If your CMDB is going to be an application, you're about to embark on a very long, expensive, and painful journey. You may even be making a very bad business decision. A real CMDB will need the following:

1) A database
2) A machine to run the database on
3) Batch Jobs to load the database based on compiled files
4) Agents that write to the CMDB
5) Developers for the Database
6) Developers for the Batch Jobs
7) Developers for the Agents
8 ) A presentation and business logic tier for the CMDB, which will possibly be written in Java or .NET
9) Developers for the engine and its business logic
10) Developers for the presentation tier
11) You will most likely require a dedicated Software Application Server
12) You will most likely require a dedicated hardware server for the Software Application Server, as you won't want to run the two on the same machine.
13) You will need Business Intelligence/Reporting tools to create relevant reports.
14) This will require dedicated Business Intelligence/Reporting expertise, meaning developers.
15) You will need a significant amount of storage for all the files you will use for uploading to or downloading from, not to mention for backups, and to accommodate CMDB growth, both for historical trending information as well as inventory of information as your enterprise grows.
16) You will need to document the application to conform to best practices.
17) You will need to maintain the entire application for bug fixes and new features, as you grow, requiring multiple ongoing releases over multiple years.
18 ) If it needs to be HA and/or Mirrored, then you will need to add in those costs, as well.


All of the above are already in place.

The CRM we are running at the moment currently accomodates and is scalable enough to accomodate all of those things (The application as well as the team that supports it)

Guerino1 wrote:
If your CMDB is going to be a simple spreadsheet based CMDB, then it shouldn't take you 4 to 8 weeks, as you can probably find some basic templates to leverage.


I wasn't interested in this option because I was thinking that starting this up from scratch and then, customizing the database application in the near future would be too much work overlap. Now that you mention templates however I am interested. Is there any place that you know off where I can obtain these templates?

Guerino1 wrote:
A third option, which you didn't seem to mention, was to look at Vendor CMDBs, which will be far more elaborate than anything you will deliver, and which will outpace your own design, very rapidly and cost effectively. They will also be up and running in a fraction of the time of anything you can deliver, yourself.


I have actually already looked at these and I have found them completely the opposite, too unversatile, unsacalble and inflexible. The versions on the market at the moment need to be modified to capture all of the information we want, it is too much work, easier to start one from scrtach. Plus they are too expensive, slowly developing this inhouse under the guidance of all teams involved as well as the management will be much more cost effective, productive, in tune with Organization custom needs and will ensure that all information captured is only needed information (Not packaged or bundled with the product). We are also guaranteed to have an inhouse support plan, continuity, capacity as well as the staff with the right experience (Both Technical and Organization Operation experience).

However, having said all of that, if there is one that we have missed which is exceptionaly good (And as you noted) Scalable, then please let me know what it is and I will try it out as well.

Guerino1 wrote:
If you do not go with spreadsheets and you decide to build your own CMDB, please be ware. Please realize that you and your organization are far from experts on designing, building, and maintaining CMDBs. As a result, you will be entrenching your organization in a very limited and non-scalable design that will be "VERY LIMITED" in functionality. As a result, it has a very high probability of meeting the needs of only a handful of stakeholders and there is a very high probability that most other stakeholders will not only avoid it but also publicly shun it. The first group to do this will be any software developers you have in-house, as they will be the first to realize that you haven't really built a CMDB but nothing more than an inventory database that doesn't meet their own needs. Please be aware that anything less than what was specified above is not a really a CMDB but a little database application that will not scale and will most likely cause your organization a great deal of grief.


We are definelty aware of all the risks involved in this, don't get me wrong. This is exactly why this is going to be a team effort and you're right many of the time frames I provided are only guides, they will definetly expand once the work is fully in progress. We will not be packaging a solution based on requirements of just one or two persons the solution is based on requirements of everyone involved. It will be custom build for our own special needs which are out of scope for most market place models. However, a custom built application, or in this instance an add on to an already custom built application will not necesarily be limited and non-scalable I actually believe it will be the opposite since most (If not all) individuals involved in the implementation are the employees with the right experience on customizing the application to the organization's need and all instruction, support resources are readily available.

Guerino1 wrote:
Every organization we have worked for, worked with, and/or spoken to about implementing any part of ITIL has always estimated and planned way low, when compared to the reality of what it actually cost them and required from a resource and time perspective. As a result, every single project initiated by these companies has had some form of cost and/or time overruns or has fallen very short of a satisfactory implementation, leaving organizations in a position to own and manage solutions that are far from their original visions. By the time we get in, they're usually disillusioned and/or disgusted with the whole effort. Please be VERY careful.

I know this all sounds very rough but I don't want you to be in a position of falling short of what you promised your organization. ITIL processes, themselves, will be hard enough to deploy and champion throughout an organization. Throwing in the design and implementation of pieces of infrastructure to support it will most likely turn the odds against your success.

I hope this information helps.

Regards,.


You have actually provided a lot of valuble information here Guerino1, the type which would be very difficult to obtain anywhere else. I really thank you for your effort. Maybe, further down the line (With more experience) I too will see with you eye to eye on this.

We will proceed very carefully. However, not much has been promised to my organization. We know and understand that we are not experts and will have to go through a lot of trial and error to customize and implement this. (Which in itself is a very valuable experience I believe) The way we see it, every little, tiny bit of progress in introducing ITIL is enormously better than what we currently have now, therefore even a small, scalable solution that captures only the dire basics at first and then is continously upgraded with extra functionality in the future will provide enormous benefits to the current IT Environment. Once again, the foundation has already been laid and an entire system is ready for customization, so the only option is to proceed carefully, slowly and surely.

Thanks for your help with this Guerino1 Smile
Back to top
View user's profile
Gregt
Newbie
Newbie


Joined: Jul 11, 2006
Posts: 1
Location: Yokohama, Japan

PostPosted: Wed Jul 12, 2006 7:14 am    Post subject: Reply with quote

Do you mind if I ask which CRM tool you are using?
_________________
MBA, ITIL v3 Intermediate, PMP
Back to top
View user's profile Visit poster's website Yahoo Messenger
query
Itiler


Joined: Feb 02, 2006
Posts: 41
Location: Sydney, Australia

PostPosted: Wed Jul 12, 2006 11:00 am    Post subject: Reply with quote

Gregt wrote:
Do you mind if I ask which CRM tool you are using?


I don't mind, but I think if I do my post will be deleted. There is a strict policy against advertising here.
Back to top
View user's profile
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Thu Jul 13, 2006 6:43 am    Post subject: Reply with quote

Query,

Your listing of the CRM tool will not be deleted as long as you're not marketing it. There are many posts on the site that refer to specific tools.

On another topic... I "highly" recommend you read this post:

http:<slash><slash>www<dot>itilskeptic<dot>org/node/25

As a matter of fact, I recommend you don't even consider building your own CMDB until you've shown this article to your upper management that makes financial investment decisions for projects undertaken.

In his first line, he states:

Quote:
CMDB can't be done... At least not with a justifiable return on the investment of doing it - it is such an enormous undertaking that any organisation attempting it is going to burn money on an irresponsible scale.


He is absolutely correct and I want to stress the part about burning money on an irresponsible scale. If you convince your management to allow you to build your CMDB, you should consider whether or not you are doing it for your own personal gain versus for the good of the whole organization.

The person that wrote this article has a very realistic view of CMDBs. He backs it up with a significant amount of very obvious and valuable experience and with a significant amount of supporting reference data and useful information.

My advice is that you think long and hard about building your own CMDB. I believe you shouldn't do so. I'm betting that if you show all the information to your decision makers, they will be skeptical about doing so, too.

I hope this helps.

Regards,
_________________
[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
query
Itiler


Joined: Feb 02, 2006
Posts: 41
Location: Sydney, Australia

PostPosted: Thu Jul 13, 2006 12:03 pm    Post subject: Reply with quote

Guerino1 wrote:
As a matter of fact, I recommend you don't even consider building your own CMDB until you've shown this article to your upper management that makes financial investment decisions for projects undertaken.

In his first line, he states:

Quote:
CMDB can't be done... At least not with a justifiable return on the investment of doing it - it is such an enormous undertaking that any organisation attempting it is going to burn money on an irresponsible scale.


He is absolutely correct and I want to stress the part about burning money on an irresponsible scale. If you convince your management to allow you to build your CMDB, you should consider whether or not you are doing it for your own personal gain versus for the good of the whole organization.

The person that wrote this article has a very realistic view of CMDBs. He backs it up with a significant amount of very obvious and valuable experience and with a significant amount of supporting reference data and useful information.

My advice is that you think long and hard about building your own CMDB. I believe you shouldn't do so. I'm betting that if you show all the information to your decision makers, they will be skeptical about doing so, too.

I hope this helps.

Regards,


Thanks for more eye Openers Guerino1 Smile

I like your cautious approach to this. I read through the article you posted and even though I agree with the poster there are somethings he failed to address:

1. CMDB needs not to include every single little thing (Every single little change or release), in fact nowhere in ITIL does it say so. CMDB is the most open tool of interpretation. It needs to capture only the information required capturing for an organization (I.e. to meet the business requirements). If Business need is only to capture information of one PC so be it, CMDB will only capture information for that one PC, if Business need is to capture information of all PCs and more so be it as well. CMDB can be everything and anything (In scale and in size) as required by the Business need as long as it is centralised (One stop shop) and ITIL methods are applied for controls and management.

2. The author of this article failed to address that most organizations already have CMDBs of some sort (In a disorganized manner). How often do we hear about 1001 spreadsheets? This is a CMDB (Of sorts). Difference between ITIL CMDB and existant CMDB (of sorts) is the control and methods of management applied. If the choice of organization is between management of current CMDB (of sorts) and ITIL centralised CMDB I think ITIL CMDB justifies its own existance and beats the other one hands down.

Now you have mentioned that I should consider whether or not I am doing it for my own personal gain versus for the good of the whole organization and I don't understand how can this be anything but for the good of the organization? Consider this:

1. No investment (only time investment required). All resources are in house.
2. Centralised Management following ITIL best practice (Instead of Practice of sorts).
3. More efficient information gathering (I predict data gathering to capture 50% more with ITIL CMDB)
4. Easier search for data (To have a direct impact on Incident, change, release and problem management), I estimate maybe 30% improvement in these areas
5. Readily available one stop resource repository (All organization IT assets in one spot - benefits for Accounting department as well)
6. Basic, scalable build requiring minimal time on development (To centralise only basic data gathering as per business need)
7. Better awareness of IT Department and IT process improvement through agreements made between organization units

And there are more, these are just ones that I can think of the top of my head. In any case, isn't the above an example of benefits this improvement would have for the organization? How can this be measured in metrics of personal gain?

P.S. Could you let me know where I can find the Spreadsheet templates please? Smile
Back to top
View user's profile
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Thu Jul 13, 2006 2:09 pm    Post subject: Reply with quote

Hi Query,

Please understand that I'm not trying to twist your arm but, rather, to at least make sure you're very well informed. I agree with the majority of your plan to implement ITIL processes. I just have seen too many CMDB projects go down a bad path. And, based on what you're telling me, your plan sounds "way" too sketchy to sound like you're on a worthwhile path. If my own staff were to come to me with what you've provided me with, I'd have to reject their proposal based on inadequate details and justification. What you've provided us with raises too many red flags. Again, though, it's not up to me.

Here's some more information, based on your response.

query wrote:
I like your cautious approach to this. I read through the article you posted and even though I agree with the poster there are somethings he failed to address:

1. CMDB needs not to include every single little thing (Every single little change or release), in fact nowhere in ITIL does it say so. CMDB is the most open tool of interpretation. It needs to capture only the information required capturing for an organization (I.e. to meet the business requirements). If Business need is only to capture information of one PC so be it, CMDB will only capture information for that one PC, if Business need is to capture information of all PCs and more so be it as well. CMDB can be everything and anything (In scale and in size) as required by the Business need as long as it is centralised (One stop shop) and ITIL methods are applied for controls and management.


Actually, if you're following only ITIL's specification for a CMDB, you are instantly falling short of a complete CMDB. You are not taking into account what Software Developers need, what Sales and Marketing Resources need, what Manufacturing needs, etc. ITIL is a great idea but it's only a small piece of the bigger picture. While ITIL is a great start, it falls very short in addressing the needs of other parts of the organization and even the needs of the IT Infrastructure staff in non-production environments. If you use ITIL as the foundation for a CMDB, you will start on a design that, in my professional opinion, lacks significantly in the fundamental requirements of an adequate solution. As a matter of fact, if you want a better design for a CMDB::

- You will need to be able to inventory and describe any and all assets, technical and non-technical
- You will need to be able to track relationships and dependencies between assets
- You will need to be able to handle one-to-one, one-to-many, many-to-one, and many-to-many relationship definition
- You will need to distinguish between sources and targets
- You will need to address circular dependencies
- You will need to address implicit vs. explicit dependencies
- You will need to address capturing history
- You will need to take into account the requirements for highly distributed, large scale, multi-technology, automated software builds, deployments, instantiations, executions, tear-downs, and rollbacks.
- You will have to consider all of this within each and every environment (Dev, Integ, UAT, etc.), as well as consider automated promotion and rejection of individual and group Changes back and forth across environments.
- You will need to address the requirements of "Checkpointing" to ensure you can reconstruct historical snapshots.
- You will need to address the construction and maintenance of "graph" data structures (most CMDBs fail because they use trees).
- Etc.

ITIL's definition for a CMDB is "very" weak, at best.

On another note, if you are dead set on building your own, I recommend you get your most senior and best software development and data modeling architects to put the design together. If possible, bring in even better ones, from expert consulting organizations that specialize in such designs. In my opinion, there is nothing that puts a CMDB design on the wrong path faster than infrastructure resources trying to do data modeling and software design. I'm sure there are exceptions to this but I have yet to see a single one. Even with your best people on it, blessing from above, and a few million in investment, it has a probability of close to "1" that it will sink like a burning ship.

Quote:
2. The author of this article failed to address that most organizations already have CMDBs of some sort (In a disorganized manner). How often do we hear about 1001 spreadsheets? This is a CMDB (Of sorts). Difference between ITIL CMDB and existant CMDB (of sorts) is the control and methods of management applied. If the choice of organization is between management of current CMDB (of sorts) and ITIL centralised CMDB I think ITIL CMDB justifies its own existance and beats the other one hands down.


You're right that all those spreadsheets are a CMDB of sorts. However, they're "just inventories". They don't track relationships and dependencies, and history, etc. You don't need to build a database to keep inventories. You can do that in Excel.

If you'll remember, I endorsed that you stick with spreadsheets rather than building your own CMDB. Already you're mixing spreadsheet functionality with what a CMDB should be. They're nowhere close to each other. You're quoting ITIL's definition of a CMDB as if it is a solid set of specifications. Please be careful. Anyone that has any experience implementing ITIL will tell you that its coverage of CMDB is one of its weakest and most vague areas.

Your justification for having a centralized ITIL CMDB vs. spreadsheets is strong on one hand, because it is logical to centralize, and weak on the other, because your estimation of the real costs are way off. I have yet to meet with an executive who doesn't regret his/her undertaking of a CMDB. As a matter of fact, most will tell you that the project proposers fell very short in their cost justifications. The only people we see who support the build of the CMDB, religiously, are the developers who built it, feel personally gratified by having done so, and loyal to it. Even support and Service Desk staff will start to quickly outgrow what you've put in place and will realize very quickly how limiting it is. My professional opinion is that you're better off buying a CMDB and working around it. However, it's your call. Everything I'm reading says that you're dead set on building your own.

Quote:
Now you have mentioned that I should consider whether or not I am doing it for my own personal gain versus for the good of the whole organization and I don't understand how can this be anything but for the good of the organization? Consider this:

1. No investment (only time investment required). All resources are in house.


Sorry, I believe your business justification for #1 is highly innacurate. There is no such thing as "only time" when resources and infrastructure are involved. Those resources belong to the company and are being payed for by the company, not by you or your supervisor. You must take into account the complete hourly cost for each and every resource to get a total resource cost. This cost should include the "entire cost" or "fully loaded cost" to keep the resources in the company. In other words, take the pre-deduction gross expenses of the company and divide them by the number of resources, and by the number of business hours in a year to get the "real" cost per hour. This will mean that the cost of real estate, desks, chairs, computers, utilities, loans, etc. are all factored in. It's not cheap, my friend. It's VERY expensive. Those resources can be focused on solving real business problems that generate revenue, which is always more valuable to the bottom line, unless you have an expense bloat problem that needs to be addressed quickly. Any experienced business leader will tell you that generating more revenue is almost always a higher priority.

As for infrastructure, if it's true that you already own everything, odds say that you'll most likely be burdening your existing infrastructure with a very poorly designed and inadequate application that will consume physical and virtual resources that could be used for revenue generating solutions. You will then need to upgrade and/or swap out all infrastructure assets, multiple times, over the course of the CMDB's lifecycle.

If you are not in the business of "selling" CMDBs to customers, you are building something that has nothing to do with your company's core business. You are building a huge "expense sink" that will start to consume more and more money, time, and effort, as it grows and needs to be maintained. This means you are using your company's natural and unnatural resources to do something that goes in the opposite direction of generating money.

Quote:
2. Centralised Management following ITIL best practice (Instead of Practice of sorts).


Spreadsheets will do this for basic functionality. You will never deliver the things your bigger organization will need from a CMDB on your own. Refer back to the requirements, listed above.

Quote:
3. More efficient information gathering (I predict data gathering to capture 50% more with ITIL CMDB)


This has nothing to do with your CMDB. It has to do with your processes and your automated solutions for scraping assets, environments, etc.

Quote:
4. Easier search for data (To have a direct impact on Incident, change, release and problem management), I estimate maybe 30% improvement in these areas


I think your in over your head, here. You have not yet experienced the issues associated with advanced and integrated search. Your Service Desk will not go searching through each and every table using multiple queries and your sure as heck not going to build one query that searches the world. You will need advanced BI tools to generate reasonable reports. It's an ugly and never ending battle for most organizations. As a matter of fact, poor access to relevant data/information is the number one driver we see for organizations to classify their expensive CMDBs as useless.

Quote:
5. Readily available one stop resource repository (All organization IT assets in one spot - benefits for Accounting department as well)


You'll be lucky to get 10!% of your assets into the system.

You need to cover all non-computing assets (phones, printers, desks, chairs, monitors, switches, routers, etc.), all computing assets, all software source code, all software binaries, all software libraries, all software configurations (build, deployment, execution, etc.), all virtual software assets (live databases, live application server instances, queues, queue managers, reporting engines, portals, static and dynamic content, etc.), all people (broken down by roles and stakeholders), all documentation, all Incidents, all Problems, all Products, all Releases, all Changes, all Risks, etc., etc., etc. ITIL is at least clear in pointing out that these things should all be in your CMDB. It doesn't tell you how, though (I love that part!).

Quote:
6. Basic, scalable build requiring minimal time on development (To centralise only basic data gathering as per business need)


Sorry, I don't see anything at all that you've provided that proves this. As a matter of fact, if you do a CMDB correctly, it will be part of your core business processes, and will need to be a Tier 1 application, as all your monitoring and inventorying solutions will poor data into it for live use by reconciliation tools, Service Desk, Sales Teams, etc. I don't see anything that you're providing that even comes close to addressing all of this.

Quote:
7. Better awareness of IT Department and IT process improvement through agreements made between organization units


If you do it right, yes. If you do it wrong, no. You don't need a CMDB to do any of this. You need highly defined process, roles, responsibilities, and artifacts to do this.

Quote:
And there are more, these are just ones that I can think of the top of my head. In any case, isn't the above an example of benefits this improvement would have for the organization? How can this be measured in metrics of personal gain?


My suggestion before you take on this project is to take an advanced project planning and project cost justification course. I believe it will open your eyes to some very big things that it seems you're missing.

Remember, I'm not saying don't implement ITIL. I totally agree with that part. I'm saying don't build your own CMDB. (But you will. I hate to point this out but it's decisions like these that help keep businesses like mine running.)

Quote:
P.S. Could you let me know where I can find the Spreadsheet templates please? Smile


I will look it up and get back to you.

Anyhow, I hope this information helps, if only to look back on, for experience.

Regards,
_________________
[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Thu Jul 13, 2006 2:12 pm    Post subject: Reply with quote

Query,

As pointed out by Bob Duncan in another thread requesting Configuration Management templates, you may want to look into "FITS".

Regards,
_________________
[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
query
Itiler


Joined: Feb 02, 2006
Posts: 41
Location: Sydney, Australia

PostPosted: Thu Jul 13, 2006 7:41 pm    Post subject: Reply with quote

Guerino1 wrote:
Hi Query,

Please understand that I'm not trying to twist your arm but, rather, to at least make sure you're very well informed. I agree with the majority of your plan to implement ITIL processes. I just have seen too many CMDB projects go down a bad path. And, based on what you're telling me, your plan sounds "way" too sketchy to sound like you're on a worthwhile path. If my own staff were to come to me with what you've provided me with, I'd have to reject their proposal based on inadequate details and justification. What you've provided us with raises too many red flags. Again, though, it's not up to me..


Once again I understand your concerns Guerino1 and I really appreciate you spending time on this. As mentioned before, what I posted is very sketchy because I don't want to copy and paste 6 hours worth of information in this thread. I provided only the basics and if more information is required then it can be released (On the need to know basis)

Guerino1 wrote:
Actually, if you're following only ITIL's specification for a CMDB, you are instantly falling short of a complete CMDB. You are not taking into account what Software Developers need, what Sales and Marketing Resources need, what Manufacturing needs, etc. ITIL is a great idea but it's only a small piece of the bigger picture.


This is entirely dependant on the scale and size of the CMDB. As mentioned before the level of detail is something which is determined (And driven) by the business need, if the business need for the level of detail is small information captured in CMDB will be likewise small.

Guerino1 wrote:
While ITIL is a great start, it falls very short in addressing the needs of other parts of the organization and even the needs of the IT Infrastructure staff in non-production environments. If you use ITIL as the foundation for a CMDB, you will start on a design that, in my professional opinion, lacks significantly in the fundamental requirements of an adequate solution. As a matter of fact, if you want a better design for a CMDB::.

- You will need to be able to inventory and describe any and all assets, technical and non-technical
- You will need to be able to track relationships and dependencies between assets
- You will need to be able to handle one-to-one, one-to-many, many-to-one, and many-to-many relationship definition
- You will need to distinguish between sources and targets
- You will need to address circular dependencies
- You will need to address implicit vs. explicit dependencies
- You will need to address capturing history
- You will need to take into account the requirements for highly distributed, large scale, multi-technology, automated software builds, deployments, instantiations, executions, tear-downs, and rollbacks.
- You will have to consider all of this within each and every environment (Dev, Integ, UAT, etc.), as well as consider automated promotion and rejection of individual and group Changes back and forth across environments.
- You will need to address the requirements of "Checkpointing" to ensure you can reconstruct historical snapshots.
- You will need to address the construction and maintenance of "graph" data structures (most CMDBs fail because they use trees).
- Etc.

ITIL's definition for a CMDB is "very" weak, at best.


That which has an end must have a beginning, very true for all destination points. At the moment as you mentioned this is a great start, but it is nowhere near the complete picture which with years will be moulded into perfection. This is not a be-all-end-all product that we are planning to release for the use of thousands of people. This is simply a start of the proccess for a small team, which will with time reach maturity and destination.

I agree with everything you've posted above and all of these will be part of the destination, only the basic components will be a part of the start ( I think this is compatible with ITIL)

I am not quite sure why you would consider ITIL's defintion for CMDB as very weak, since ITIL in the same manner (Without the same level of detail) describes the need for what you've posted. Are you not a fan of ITIL? What is you preffered Process Improvement model?

Guerino1 wrote:
On another note, if you are dead set on building your own, I recommend you get your most senior and best software development and data modeling architects to put the design together. If possible, bring in even better ones, from expert consulting organizations that specialize in such designs. In my opinion, there is nothing that puts a CMDB design on the wrong path faster than infrastructure resources trying to do data modeling and software design. I'm sure there are exceptions to this but I have yet to see a single one. Even with your best people on it, blessing from above, and a few million in investment, it has a probability of close to "1" that it will sink like a burning ship.


But once again, this is a question of CMDB scale. If you have CMDB which is only capturing one component then this is something that can be built by a software developer within a day without any Resources needing to be spent. I think, my approach differes to yours in scale and capacity. I don't intend for a perfect product that will straight away be able to do everything, but a small scale function that can be expanded over time and at certain point be able to capture everything you have mentioned. I think our differences are background ones. If your employer is a software development company then I definetly agree with your approach and I think you are right for following this business model, however your business needs would be very different to ours.

Guerino1 wrote:
You're right that all those spreadsheets are a CMDB of sorts. However, they're "just inventories". They don't track relationships and dependencies, and history, etc. You don't need to build a database to keep inventories. You can do that in Excel.

If you'll remember, I endorsed that you stick with spreadsheets rather than building your own CMDB. Already you're mixing spreadsheet functionality with what a CMDB should be. They're nowhere close to each other. You're quoting ITIL's definition of a CMDB as if it is a solid set of specifications. Please be careful. Anyone that has any experience implementing ITIL will tell you that its coverage of CMDB is one of its weakest and most vague areas.


I see building a brand new CMDB as the next step up from spreadsheets. One of the main disadvantages of having spreadsheets is the amount of places where information need to be modified and managed and the amount of information that can be recorded (They are not a one stop shop like databases, They are very limited in scope and capacity) My approach is an approach of evolution along the lines of Spreadsheet to brand new CMDB Database capturing basic components and tracking very limited information to CMDB with capturing more information with higher level of detail. It doesn't have to be completed all in one go. I don't think ITIL's defintion of CMDB is a solid set of specification. ITIL's approach is do what works for you (Therefore level of detail is not discussed).

Guerino1 wrote:
Your justification for having a centralized ITIL CMDB vs. spreadsheets is strong on one hand, because it is logical to centralize, and weak on the other, because your estimation of the real costs are way off.


It is way off because the scale at the moment is very basic and limited. Once the level of detail starts to increase (With Demand) further costs will be additionally added.

Guerino1 wrote:
Sorry, I believe your business justification for #1 is highly innacurate. There is no such thing as "only time" when resources and infrastructure are involved. Those resources belong to the company and are being payed for by the company, not by you or your supervisor. You must take into account the complete hourly cost for each and every resource to get a total resource cost. This cost should include the "entire cost" or "fully loaded cost" to keep the resources in the company. In other words, take the pre-deduction gross expenses of the company and divide them by the number of resources, and by the number of business hours in a year to get the "real" cost per hour. This will mean that the cost of real estate, desks, chairs, computers, utilities, loans, etc. are all factored in. It's not cheap, my friend. It's VERY expensive. Those resources can be focused on solving real business problems that generate revenue, which is always more valuable to the bottom line, unless you have an expense bloat problem that needs to be addressed quickly. Any experienced business leader will tell you that generating more revenue is almost always a higher priority.


First of all, don't forget that CMDB is addressing a business need, it is not something that was conjured up of thin air. It is going to be developed because the business requires it.

Also, I don't think that this cost model is the best cost model for estimating costs of the organization. Because then you need to include the hours that will be "Saved" due to the implementation of this as a direct cost saving to the organization. The amount of detail of captured data as opposed to the current detail, the improvement in the efficeincy of the operations as a direct cost benefit. Once you put hypothetical costs against hypothetical cost savings in the same business model the hypothetical cost savings will win. The cost savings (I.e. generating more revenue) due to the improvement of proceess here is definetly the higher priority.

Guerino1 wrote:
As for infrastructure, if it's true that you already own everything, odds say that you'll most likely be burdening your existing infrastructure with a very poorly designed and inadequate application that will consume physical and virtual resources that could be used for revenue generating solutions. You will then need to upgrade and/or swap out all infrastructure assets, multiple times, over the course of the CMDB's lifecycle.


You only assume that the infrsatructure is poorly designed and is inadequate, but really you do not know this for a fact since you do not know what is going to be included in the design. I think you are not in the best position (Even after viewing the statistics of other customers) to make this conclusion. Once again, I personally view this as a revenue generating (Cost Saving) solution therefore I see it as a right step forward.

Guerino1 wrote:
If you are not in the business of "selling" CMDBs to customers, you are building something that has nothing to do with your company's core business. You are building a huge "expense sink" that will start to consume more and more money, time, and effort, as it grows and needs to be maintained. This means you are using your company's natural and unnatural resources to do something that goes in the opposite direction of generating money..


I'm sorry but I actually disagree with this. I think the staff employed by the organization are in a much better position of understanding company's core business and needs and the CMDB supplier simply does not know what it is (Too much experience with software developer companies). I have had a lot of experience with suppliers and their builds of a default package which were hopes that default will fit the business need of a customer without understanding the buseness needs of the customer. In most cases what you end up is asking why the package doesn't have required components and required relationships and how much it would cost to modify it. Once again, you fail to function in the amount of development work required into getting a 3rd party product in sync with the business needs...

Guerino1 wrote:
2. Spreadsheets will do this for basic functionality. You will never deliver the things your bigger organization will need from a CMDB on your own. Refer back to the requirements, listed above.


Spreadsheets lack the efficiency, scalabillity and scope of a database. But any templates available out there, will definetly be welcome

Guerino1 wrote:
3. This has nothing to do with your CMDB. It has to do with your processes and your automated solutions for scraping assets, environments, etc.


I think it does, because instead of updating / managing information in 20 different places it is updated only in one. Time saving just on this note is astronomical.

Guerino1 wrote:
4. I think your in over your head, here. You have not yet experienced the issues associated with advanced and integrated search. Your Service Desk will not go searching through each and every table using multiple queries and your sure as heck not going to build one query that searches the world. You will need advanced BI tools to generate reasonable reports. It's an ugly and never ending battle for most organizations. As a matter of fact, poor access to relevant data/information is the number one driver we see for organizations to classify their expensive CMDBs as useless.


While I agree that I may not have as much experience as you may have, I do not think that this is as difficult as you describe it. Our IT department has finalised a number of similar add ons to the CRM with a very similar functionality to the CMDB for other Organization units (Equiped with both advanced searching functions and reporting facilities). I (at the moment, without going too much into detail) see no reason why we would run into problem with this. But once again, maybe time will prove me wrong.

Guerino1 wrote:
5. You'll be lucky to get 10!% of your assets into the system.

You need to cover all non-computing assets (phones, printers, desks, chairs, monitors, switches, routers, etc.), all computing assets, all software source code, all software binaries, all software libraries, all software configurations (build, deployment, execution, etc.), all virtual software assets (live databases, live application server instances, queues, queue managers, reporting engines, portals, static and dynamic content, etc.), all people (broken down by roles and stakeholders), all documentation, all Incidents, all Problems, all Products, all Releases, all Changes, all Risks, etc., etc., etc. ITIL is at least clear in pointing out that these things should all be in your CMDB. It doesn't tell you how, though (I love that part!)..


Once again this is a question of scope. What needs to be covered is not decided by some document (It is not universal) what needs to be covered is decided by the business need, so while you say that all this, this and that are the components that need to be there the reality from the business point of view may vary quite significantly. ITIL doesn't need to tell you how to facture one or all components in because the needs will be different from organization to organization.

Guerino1 wrote:
6. Sorry, I don't see anything at all that you've provided that proves this. As a matter of fact, if you do a CMDB correctly, it will be part of your core business processes, and will need to be a Tier 1 application, as all your monitoring and inventorying solutions will poor data into it for live use by reconciliation tools, Service Desk, Sales Teams, etc. I don't see anything that you're providing that even comes close to addressing all of this.!).


Once again you are forgetting about the scope. For some organizations there may need to be an integration of invetory solutions and different teams, for others it maybe just what information is put into CMDB by Service Desk. By Basic, scalable build i did not mean integration of various tools into the app, but the fact that it is started with little and then evolved slowly over time.

Guerino1 wrote:
My suggestion before you take on this project is to take an advanced project planning and project cost justification course. I believe it will open your eyes to some very big things that it seems you're missing.

Remember, I'm not saying don't implement ITIL. I totally agree with that part. I'm saying don't build your own CMDB. (But you will. I hate to point this out but it's decisions like these that help keep businesses like mine running.)


Point taken. I think it may actually be a good idea to register for a cost justification course. I am very happy with all of the information you have provided here by the way and will come back to this time and time again to review my solution against the criteria you've provided.

You have been a great help Guerino1. Thank you for your posts and effort Smile
Back to top
View user's profile
query
Itiler


Joined: Feb 02, 2006
Posts: 41
Location: Sydney, Australia

PostPosted: Thu Jul 13, 2006 7:42 pm    Post subject: Reply with quote

Guerino1 wrote:
Query,

As pointed out by Bob Duncan in another thread requesting Configuration Management templates, you may want to look into "FITS".

Regards,


Oh, I have actually printed out the full FITS Service Support Guidelines. They too have been a great help Smile
Back to top
View user's profile
query
Itiler


Joined: Feb 02, 2006
Posts: 41
Location: Sydney, Australia

PostPosted: Fri Jul 14, 2006 11:31 am    Post subject: Reply with quote

Frank (Guerino1) I was thinking, since you are a chairman of an on deman ITIL supplier company you may want to invest or open up to an opportunity of providing to customers who are not looking for the whole package but rather a basic, cheap scalable solution that can be expanded over time? I think there is a big Niche market out there for companies which have not yet Implemented ITIL, want to implement it, but at the same time want to start slow. I think if you invest in a solution for these people, you might be cutting to yourself a big slice of the Market Share.

Just a thought (In hopes of repaying for so much wonderful information you've provided) Smile
Back to top
View user's profile
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Sun Jul 16, 2006 3:09 pm    Post subject: Reply with quote

Hello Query,

Two things...

First, I have a white paper that highlights the requirements for a fundamental CMDB system. I use it as the foundation for regular lectures and presentations that I give. If you're interested, you can contact me at Frank.Guerino@TraverseIT.com and I'll gladly get it out to you. If you're going to go down the road of building it yourself, I at least want you to be armed with as much information as possible.

Second, thanks for the feedback. This is exactly what we're offering. I don't know if you're familiar with the Cell Phone or Cable TV model, but what we're offering works along the same lines. Our users connect to our platform, through a web browser, and have very affordable access to a very large array of tools that address different areas of the ITIL specification. They pay per use, such as you would for your Cell Phone service.

What we're trying to do is offer pre-constructed and pre-integrated solutions so that our customers don't have to do so for themselves. It seems to be working and takiing off. Our clients and prospects are starting to realize that they're not in the business of building ITIL solutions. They're also realizing that they're not in the business of IT and can't compete with what we're offering. This means they're willing to acknowledge that they're not specialists in providing ITIL solutions. They are "consumers" of ITIL and that's where they get their true value. They are wise enough to understand that they want the benefits of ITIL, not the costs and the ongoing headaches of managing an ITIL implementation. They're also wise enough to understand that every time they try and implement any single piece of ITIL, they are re-inventing a wheel that has already been implemented by someone else, such as the CMDB you're going after.

The whole purpose of ITIL is to not re-invent the wheel. "That" is the gift of the OGC. They are giving us what is "common" across all enterprises and they're calling it ITIL. What companies are slowly starting to realize is that the implementation "can" be the same, just like terminology and the concepts are the same. We're seeing that the market is "finally" starting to get this.

Anyhow, we'll see how it all turns out, wont we?

Regards,
_________________
[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion All times are GMT + 10 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003 http://www.nukecops.com

Forums ©

 

Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.