Subscribe to RSS
Posts Tagged ‘Configuration Management Database’
Best practices for document management systems
I recently received a question about best practices for electronic document management systems using Word 2003. While I use Word 2003, I have only used it in combination with Sharepoint as a document management system, and the docs I write in Word are usually short, internal documents, not external technical manuals. Coincidentally, I’ve heard that IT departments are using document management systems in concert with their CMDB. Text-based documents, drawings, architecture designs, all these documents are important to an IT department and any business organization. It makes sense that the CMDB would be related to a document management system, although I won’t get into any discussion about whether each document is a Configuration Item (CI) or not. 
My experience with document management is Documentum with FrameMaker, and we don’t currently do much co-authoring with people in the rest of the company. So I’ll admit first off, this request for information is outside my personal knowledge. But, I do like a good research question and I gathered together some reading items.
Here’s a summary of what’s found in this article about putting together a document management system using Microsoft tools. Your environment may vary widely from an accounting-type environment, though, but I thought these were decent overarching goals for managing documents, and I expanded on a few of them based on my experience with document management systems in general.
- Determine what documents get the “document management treatment.” Create limits on what is stored and maintained in your system so that you know what’s in there and what’s not, and you also limit maintenance and a bulging file system. Will you scan and store images of paper copies?
- Classify or group your documents together. Some EDMSes do this for you using document type, but you might also want other criteria for easy search and retrieval later. This approach also allows you to assign more than one classification to a document.
- Store the files efficiently to make retrieval easy. Your EDMS might do this on its own with little input from you.
- Retrieve as needed, using versioning if desired, which leads to the next step. Realize that indexing and keyword searching are crucial tasks for retrieval. Be sure to train users to properly tag documents for fast and efficient retrieval. You may have to create a taxonomy using standard terms for the system.
- Managing and tracking documents allows for the type of collaboration where one person can check out a document to make revisions. Other collaborative activities might include activities such as participating in active discussion groups, tracking issues associated with customer engagements, maintaining common contact information for subject matter experts on a particular document, and even assigning tasks related to a particular document. Tracking and versioning also allows for storage and retrieval of documents from a point in time which may be helpful historically.
For research like this question, one place I like to do searches is answer.google.com. There was one relevant Answer for someone who was looking for an analysis of document management software. It’s long but comprehensive. I realize you might be well past the evaluation stage for a DMS, but you might get a look at what features are offered. You can also use blogsearch.google.com to search only for blog entries on a given topic, although that particular search method did not offer much on this particular topic.
Going beyond Google, I did a search using www.bloglines.com to search for blogs about “document management systems,” and the best I’ve found so far is www.docuvantage.com/blog. Another site that offers a wide range of case studies and white papers is The Gilbane Report at http://www.gilbane.com/.
There are also lessons learned from the doc management trenches at Hewlett-Packard. It appears the author is Susan Charles, an Information Research Analyst at Hewlett-Packard. She describes the implementation of an internal document management project at HP. She discusses the challenges of the project, and what she sees as the lessons learned.
In addition, here’s a case study from a university setting. I haven’t read through it completely but it might offer some advice.
As with many best practices in technology, you want to analyze first and implement second. Spending more of your time in the up front planning and definitions will pay off when you go to populate your system with documents.
Anyone else have some advice to offer? Feel free to post a comment, or use the trackback URL to write about it in your own blog and refer to this entry.
What’s driving CMDB adoption?
Talking about the top three reasons people say they’re working on implementing a CMDB
According to Network World, in this CMDB adoption: What some numbers tell us and why article, they have found three top drivers or motivations for CMDB implementations:
1. Change and Configuration Management (also named Release, Change and Configuration Management)
2. Service Assurance
3. Problem and Incident Management
Interestingly, “Asset and Inventory” was fourth on one survey, but when asked if CMDB was going to be used for “Asset Management” instead, that category fell even further out of the list of reasons to implement a CMDB. Read the article for the full story and details.
In the IT Discovery Suite talk I went to at the BMC Forum, these are some of the items that we see are driving discovery tool needs. While not necessarily directly related to CMDB implementations, I see a coupling, and definitely our discovery tools can populate a CMDB. However, I wonder if asset management isn’t as much of a focus, and there are plenty of other pain points to choose from. In case you need a pain point. I’m guessing most of us don’t need more pain points, but here you go.
Common pain drivers
- Don’t know what assets are deployed or their inter-dependencies
- Over- and under-buying of assets
- Cost, risk of software license and regulatory compliance
- Change Control vs. Change Management
- No insight into the impact of IT health on business activities
- Long resolution times
- Missed SLAs
Common project drivers
- Inventory
- Software license management
- Regulatory compliance
- ITIL® best practices (e.g. configuration management)
- CMDB initiative
- Application & Patch Management
- Server consolidation
- OS Migration
- Root cause analysis
- Intelligent Trouble ticket generation
You can take the survey for Network World yourself. What projects or pain points are driving your CMDB projects?
Delayed report from the BMC Forum about Discovering Configuration Items (CIs)
Observations on discovery technology based on sitting in on the BMC IT Discovery Suite presentation at last month’s BMC Forum
Tools for discovering your IT assets are a new area to me, so if I get the technology all wrong, let me know. I attended this session Wednesday of the BMC Forum after having breakfast with some cool people who work in change management at Temple Inland here in Austin (Stephen, one of the brothers in the photo from this post is one of them). They all had Blackberries which seems to be the support gadget of choice — my husband the system administrator carries one as well. I’ll get back to the Blackberries as part of the IT discovery in a minute.
Mike Ramos, a technical services expert who works in Dallas, presented to about 40 attendees. He offered methods for answering the questions, What assets do I have? How are assets related? How are assets configured? An example of a customer request he’s helped with: “I need a quick asset count of the 20,000 desktops I’ve got, plus I need patch management for those 20,000 desktops in less than 3 to 4 weeks, can it be done?” His answer is “Yes, and here’s an overview of how to do it.”
BMC offers Marimba Configuration Discovery for configuration discovery when you want to gain visibility and control over IT assets, so it’s agent based. BMC Discovery Express (he also called it Dex) populates and validates the CMDB with inventory of deployed assets (agentless) using SNMP v1 or v2 (items like a switch, router, or firewall) but doesn’t know about relationship info, so the third piece is BMC Topology Discovery, which tells you the connections. I’m probably completely confused on what you can buy as a package, but your sales rep could help you figure it out, or poke around on the links I’ve embedded.
Questions and answers from this session include:
Q: Can you marry the application to the network things that you know about?
A: Yes, any topology you already know about can be configured.
Q: Can you add connections to servers in the map by hand?
A: Yes, it’s in a right-click menu.
Q: What is that Route to Value graphic?
A: The Route to Value graphic shows categories of the methods you can use to achieve Business Service Management. Marimba works in the Change and Configuration Management Route to Value, but the other two products work in the Asset Management and Discovery Route to Value. I think that just goes to show you that you don’t have to take just one route to get to value.
Q: Are there any gotchas in a VMWare or UNIX partition environment in terms of discovery?
A: As you might guess, VMWare can have issues because of the display aspect, causing you to have to customize the view, but
there is an expert module for VMWare / Citrix is due in a November patch of the product.
Q: What about discovery of handhelds?
A: There are workarounds for Blackberry and Palm devices, but PocketPC is the only officially supported discoverable device.
So that’s how I’ve returned to the ubiquitous Blackberry. I also want to let the Marimba folks know that your radio transmitter/receiver/repeater analogy is quite good in my eyes. It scales well and seems to be familiar to most people. I’ve been explaining architecture for distributed system for about five years now, and your analogies make the best diagrams I’ve seen.
