1

We recently had an audit. Big thing for us, is to create a documentation. Currently we have not much of it on paper. A few excel made sheets of info is simply not enough. Audit mentioned creating something like “Our-IT-for-dumies” document. Using this document new IT pro could learn about workplace, procedures and so on. How do you create a documentation? What are main things to focus on? What is your best practice?

8 Spice ups
2

It’s only basic info but we just signed up to Slack. We’re using the free account and treating it just like a knowledge base store. Each ‘channel’ is an area of interest (for example we’ve got 'Network Infrastructure). Within the various channels we have guides, handy powershell commands etc Basically everything except passwords of which we use KP for.

We also setup a channel to list our laptops so we know who they are with and can mark them as returned or not. Like I said, very basic but free.

Hope this helps.

2 Spice ups
3

Start with standard procedures.

For example, new employees. There are probably a dozen things that you “know” need to be set up in a particular way, but you don’t have it written down.

Similarly, (and more importantly), departing employees. Do you have a procedure which guarantees that you’ll remove ALL their access before they’re out the door?

Server & network documentation - not just the What, but the Why? Server X is set up in a slightly unusual fashion - document it, and WHY it’s set up that way.

9 Spice ups
4

Your audit group is looking for specific, versioned artifacts. Some of these are more for onboarding - a guide for new employees, policy manual - things like that. Some are for documenting your IT systems themselves, for use within IT. Probably the easiest place for you to get started there is a system inventory, followed by procedures to document common tasks.

A network share with documents is a common approach, but versioning quickly becomes kludgey, using file names with embedded dates or some similar ugliness. Better is to use a SharePoint document library or a wiki. I use Confluence for this, but any wiki with document versioning is workable. Start with a bullet list of links to subsidiary documents - maybe two lists, one for “user facing”, the other for internal IT use.
These two lists meet in the concept of a “service catalog” - the inventory not of servers and systems, but services you deliver to your users. If you can start with the service catalog that’s great, but if you’re struggling with “how do I get me a ‘documentation’” then I suspect you’ll be better served to start with hardware/software inventories, common tasks, and user manual (what are the file servers, how do you print, password complexity and rotation policy, etc).
Finally task someone on your team to be the “documentation czar”. This person may not write all the material, but at least identifies what needs to be written and ensures someone owns each artifact.

5 Spice ups
5

What size is your server and device fleet

3 server 50 PCs ?

300 server 3,000 pcs?

6

Mini tip if you’re stuggling to get going with “what to write about” - create an A-Z of things, with anything and everything on it, and use that to get you going. The you can either prioritise items from the list or you can just work through from A-Z and pick them off as you go. This concept is kind of related to the above mentioned Service Catalog

It helps to keep you moving through it as there is no structure to it other than the alphabet, it has really helped me to start getting things written down.

6 Spice ups
7

Its 10 server and 300 pcs

1 Spice up
8

Size of your team would also be relevant

9

Oh ofc :smiley: There is only 3 people. Quite a collective right?

10

Sometimes that makes good docs all the more important, as you might only have one key person per important process or topic whereas larger groups can to be more in teams and theres just “more people” for the knowledge to get to in any way, shape or form.

1 Spice up
11

I’m sensing a great deal of tedium and frustration in OP’s future…

MYSTIC-MEG_2882318b.jpg

1 Spice up
12

Create areas of knowledge, software, hardware, network, disaster recovery, policies, etc. Each department should have their own as well, covering everything relevant to the department. Within those areas break down into smaller and smaller areas (software 1, software 2, etc.) Each area should be fairly detailed, don’t make assumptions of knowledge. What you know to be obvious someone else may not. Reference other areas of documentation as needed. Keep records of old documentation and changes as well. Contacts of people who worked on specific alterations, noting what they worked on. Good documentation isn’t done over the course of 1 day, it needs to be continuously updated and maintained to stay relevant to any changes your company makes.

3 Spice ups
13

Start from the top down - policies first. Then move onto procedures, processes, changes made and inventory. Remember also that from an audit perspective its not so much that you have procedures, policies and processes documented; its that they are communicated and followed by staff.

1 Spice up
14

Been looking at ITGlue. (actually since about 6 months or so) Haven’t bit the bullet yet but this product is killer.

15

I had turnkeylinux for Dokuwiki setup in minutes, and I’ve been using that to build out some of my documentation. It is a network web server, so may not be as secure as other options, but it is on your network at least, and not the cloud. Could always do the basics/obvious on the wiki and have secured documents for more sensitive information.