Software for a One-Man IT Department?
skywalker107 asks: "I am a one man IT department for a small Company (~100 PCs 4 Servers). I know that the bigger companies use alot of admin tools for inventory, documentation and management. Right now all of my information is spread out over documents, spreadsheets, and diagrams. The software I have tried has been poor at best and only covers one of the areas I need. What do the other small IT departments use to bring this information together and help manage the madness? Is shareware/freeware a good route? Does the open source movement have anything to fit a small scale setting?"
How about a good wiki with version control? Also, a versioning system like Subversion can be very useful for maintaining source code and configuration files.
UNIX/Linux Consulting
You're going to get 50 posts telling you to just use a wiki. That's decent for documentation but hardly the answer you need.
My suggestion is to try something like Plone. Set up document types for inventory and any specialized documentation you may need. You can set up simple workflows for processes if you want to get fancy (e.g. track computer order status). You can easily attach documents like spreadsheets as well.
I think you should look at one decent open source package you can customize a little (in Plone's case with no programming) which would encompass as much as you want to manage in one place.
Developers: We can use your help.
I kinda like MediaWiki as a searchable documentation dump -- to at least capture things and have a decent format.
Benefits:
- auto-generated table of contents at the top of each page, from very simple headings format
- can make links to flat files (html, PDFs, images, documentation that came with other software) in a separate space
- popular format for How-To's and Wikipedia provides some consistency with what users might see elsewhere
- automatically keeps track of when things were edited, which provides a rudimentary way of logging
what you've been up to day-to-day, week-to-week
- easily searchable
- users can provide their own information
- separate "talk" pages for discussion
- can see the whole history of changes
- nice presentation format for verbatim text, such as you would use to display a series of commands
- easy for users to navigate
Drawbacks:The combination of these things keeps everything in line. In particular, I'll point out that each part works together in such a way that there is only one place to check documentation (the wiki), one place to check for a work queue (the issue tracker) and one place to check for state information and discussion (the mailing list). That makes it easy to deal with, easy to delegate etc.
Also, you'll note that on a day-to-day basis, unless something breaks, there is no work required. That's huge. If the status quo requires any work at all, you'll eventually hit a scaling limit. The only thing that should require work is either a migration, an upgrade, or an expansion. And of those, upgrades should be easy to (nagios, yum and version control help there)
Well, Wikis are a rich-get-richer-poor-get-poorer proposition with respect to organization.
Our group used a wiki extensively for posting meeting notes, keeping priority lists, documenting open issues, posting reference data etc. The Wiki was good for us because it was simple, easy to learn, and we could adapt it to a wide variety of uses without having to go through a major requirements analysis and software selection. If we thought we might be able to track, say, outstanding customer issues by giving them a wiki page, we'd try it and see if it worked. By in large the simplicity and flexibility of using a wiki instead of a aresenal of special purpose software was a win for us. Until a certain manager got wind of what we were doing. In fact, we invited him to use our wiki to track what we were up to, instead of buttonholing an engineer and giving him the third degree every time he felt a twinge of anxiety on some issue or another.
The problem is that this manager likes to edit things. At first, it started with his changing fonts around and putting cute little animated gif icons of flames for items he thought were "hot". Then it proceeded to wholesale reorganization of the wiki, in the process breaking about half the document links. Finally he began to use the wiki as his private "brain dump" area, and started to demand that everyone know everything that was in it, which was impossible because he works 80 hours a week, and any time he got a hankering to edit something at a night or on a weekend, he'd satisfy it by spending a few hours shuffling wiki's content around.
Pretty quickly, everyone gave looking the wiki on a regular basis; they only went there when he browbeat them into it. This left him perplexed. He complained that we "advocated" using a wiki (which we never did, we just used it because it was convenient), and then we dropped it. When we point out that a system that changes too rapidly is useless for documentation and tracking, he's completely unable to see how what he's doing might pose a problem for other people. From his perspective, he's just making things "better organized". The more time you spend organizing, the better organized you'll be, right? Sure. And if you spend most of your time in a rush, it must mean you're punctual.
Eventually, what we did was set up a CRM system. Since this is a database application, and we've "neglected" to give him admin privileges, he can't alter the framework of the information at least. He does pelt us with regular "trouble tickets" in which he suggests all kinds of feature enhancements we should add to the CRM "if we have time". We quietly close them and continue taking care of the customers.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.