6 steps to IT documentation

IT asset management – what it is and the best way to get started?

In IT documentation, the relevant data of all important IT components are recorded centrally and in a structured way. The question remains: What is relevant data? And what are the “important components”?

It depends on the perspective. More precisely: on the user group. Each group of users in the company has different priorities. As an IT administrator, you need flexible technical documentation. First and foremost, you want to know which devices are available. You are interested in what software is installed on them and whether the patch level is up to date. You value flexibility and depth of detail in order to store a version or a model designation. And you will see in a moment that this is not the only perspective on IT documentation.

IT documentation is more than just inventory

What belongs to an IT documentation?

At first glance, the term “IT documentation” seems unambiguous. In practice, however, it is used extremely flexibly. You will often read the term in connection with a monitoring or discovery solution. These tools usually only provide part of the necessary information.

IT documentation is about recording your IT. However, it is much more than just a list of devices and equipment. Good IT documentation tells you much more about your IT landscape. Think about locations, software licences and responsible persons, plus invoices and contracts. This data belongs in your documentation. And you will unearth a real treasure trove of information when you put it into context.

IT documentation should enable the IT team to see exactly what is happening at any time.

  • where a unit is located
  • which parts of the network it accesses
  • what software is installed on it
  • how this software is licensed
  • which services the device provides or requires
  • who is responsible for the operation of the unit
  • who uses the device
  • which maintenance contracts have been concluded
  • when and by whom which changes were made to the unit in question

Unite this information in a central IT documentation to derive real knowledge from the before unstructured data.

Why should you document (your IT)?

First and foremost, you create and maintain IT documentation to ensure you have an up-to-date overview of your IT landscape. Only if you know what you have will you be able to plan future investments sensibly. However, there are very tangible reasons why IT documentation is indispensable.

IT equipment failures

With IT documentation, in the event of a malfunction, you know immediately who is responsible for the faulty system. You also know what needs to be done to rectify the fault as quickly as possible. In addition, you can immediately see which other processes and systems are affected. You are thus in a position to bridge failed systems at short notice in order to keep your infrastructure operational. In such a case, one also speaks of emergency documentation.

Within the scope of this emergency documentation, the filing of restart plans is also provided for. In these plans you will find exact information about which steps are necessary to bring defective systems back into operation.

Costs

With IT documentation, you have an overview of maintenance and licence contracts as well as the status of each individual device. Imagine the costs of still paying licence and maintenance fees for decommissioned equipment. Link contracts and licences directly to the asset. When decommissioning, you have all the information you need to holistically remove equipment from your infrastructure.

Changes

IT is subject to change throughout its life cycle in order to remain efficient or align with the goals of the company. When you make changes, it is essential to have an overview. Which other systems or departments are affected?

The smallest careless changes can have far-reaching consequences for processes, systems and services. If you lack an overview, expensive failures are inevitable.

Legal obligations

Many entrepreneurs and business managers are not aware that there are also concrete legal requirements that make IT documentation mandatory. Examples of such standards are the IT Security Act and the Regulation on the Operation of Critical Infrastructures (KRITISV). The General Data Protection Regulation (DS-GVO) also basically makes it necessary to document internal IT.

The Law on Control and Transparency in Business (KonTraG) should be mentioned here. This law obliges companies to take measures that identify risks to the company’s continued existence at an early stage. Of course, this also affects corporate IT and is therefore relevant for almost all companies.

How to start your IT documentation

“How should I start? What do I even need to document?”

These questions are always in the room at the beginning of the project. The answer is: “Determine what you need and reduce your documentation to these requirements”. This sounds simple in theory. In practice, numerous obstacles get in the way. Let’s embark on the journey to your IT documentation together.

Different users, different requirements

Departments who are interested in IT documentation

First and foremost, you will be documenting for your own area of responsibility: IT. IT professionals have a penchant for detailed technical data collections. However, bear in mind that far more people and departments in the company will have an interest in IT documentation. And not all users need the same level of detail.

The ladies and gentlemen from the accounting department will have little interest in technical data. Here, things like maintenance contracts, orders and invoices become important. If you ask customer support, you will receive different information. Here, instructions and manuals are very important. And if you ask your IT manager, he will ignore many of the details that are important to you. He needs a quick overview of the big picture for his daily work.

Our tip: Get representatives from all departments around the table at the start of the IT documentation. Involve all future users of the data in the project.

Set the right priorities

IT documentation: Who needs what?

Documentation awakens the hunter-gatherer. This inevitably leads to you documenting too much or the wrong thing. In the end, you have included things in the documentation that you will never need again.

Our tip: Talk to the people involved. Ask the right questions. Gather all the requirements before you start the project. Then you are on your way to IT documentation that offers real added value to everyone.

Think about the processes

If existing IT documentation atrophies, there is a good reason for it. The most common: confidence in the accuracy of the data is lost. At some point you came across outdated or inaccurate data in the documentation. This was the point at which the IT documentation became worthless to you. And this is what happens to administrators and IT managers every day all over the world.

The goal is reliable documentation. You need well thought-out processes to ensure that the information it contains is up-to-date. This requires knowledge of how to maintain the data and a good dose of discipline. This discipline cannot be installed. It is a human factor that must be learned.

Top-Down or Bottom-Up?

IT-Dokumentation: Top-Down oder Bottom-Up

When you start with your IT documentation, you have several possible approaches. If you first start with the basic infrastructure and work your way up, we speak of the bottom-up approach. You look at your IT landscape from the bottom up. Start with the assets on which everything is built: sites, buildings and rooms.

Another approach looks at IT from the top. You start with the vital IT services. Then you document their components. You work your way down until you get to the physical infrastructure. In this case, you document according to the top-down principle.

Both methods have their justification. To achieve quick results and document all important parts of the IT landscape, the top-down method is recommended. To build up your IT documentation comprehensively, we recommend the bottom-up method. We look at this here.

IT documentation must be consistent

That is the mantra of documentation. Consistency ensures trust. It’s not just about the trust you yourself have in your own IT documentation. It is above all about the trust of the other stakeholders.

Define the depth of information

If you record a certain piece of information for a single asset, you also record it for all other assets of the same class. This means that if you record the IP address of a server in the IT documentation, you do the same for all other servers.

What happens if you don’t?

The documentation is not only for your own work. All the people you work with benefit from it. People rely on the information and expect it to be complete. If your employees find the IP address of a server in the IT documentation, they expect the same for every other server. If this is not the case, they lose confidence in the data.

Set yourself small and realistic goals. Try to achieve these goals step by step. It is sufficient to record the IP address and host name of all servers as a first step. But when you do this, do it for all servers

The IT documentation must meet your requirements

Avoid being a hunter-gatherer. Find out what requirements your daily business entails. Define which questions need to be answered. Determine which information you need. Record the results of these considerations in a configuration management plan as a guideline for your employees and for yourself.

What happens if you document too much?

The mass of data cannot be kept up to date. Another disadvantage of too much data: Relevant things get lost in the mass of incidental things. You will be hard pressed to find the important things.

Plan and organise your IT documentation carefully . Please keep two things in mind:

  • Documentation takes time
    Plan the time needed in advance. Make sure that your employees and bosses accept this fact. Do not argue about the additional time needed.
  • Include your documentation in your processes and projects.
    Is there a guide for setting up new servers? Include the necessary documentation. Are new Exchange servers set up by external consultants? Inform them how they will be included in your IT documentation. Let them know your exact requirements.

Technical and operational documentation

These two belong together. With your documentation you create a place where you bring both together. Technical details are the minimum. But how and why was something installed?

Keep this data asset- or service-orientated. You do not keep the MX DNS records of a new email server in the email server context, but in the DNS server context. If you have linked information like this, always have additional service documentation available. In this, you record how and why these configurations belong together.

Enough theory. Now it’s time to roll up your sleeves and get started.

The 6 steps to IT documentation

Countless projects have shown that a structured approach is advantageous when setting up IT documentation. That is why we have developed the “6 steps”. Each individual step builds logically on the others. In the end, you get comprehensive and complete IT documentation that really supports you in your day-to-day business.

The 6 Steps to IT documentation - IT asset management

Step 1: Documentation of the IT infrastructure

IT-Dokumentation: Schritt 1 - Infrastruktur

There is only one good reason not to cover the physical infrastructure: you don’t have one.

That is not very likely. That is why we start with this step. The information needed is mostly static. It is recorded once. However, many situations require knowing where an asset is located. As a first step, document locations, buildings and rooms.

Other possible locations are:

  • a workplace
  • a floor
  • a city
  • a state
  • a region

Determine the appropriate level of detail. If you run a large data centre, you usually record your IT down to the position in the rack. If you have a small computer room, the documentation is done with the capture of the room. Floor plans and room layouts prove useful for complex infrastructures.

With the locations, you have created the basis for something bigger. Your facility management will benefit from the documentation if you include workstations in it – including tables and chairs. Also think about fire extinguishers and air conditioning.

It is advisable to record operational installations in any case. Many of these systems are subject to an obligation for regular technical inspection. This applies, for example, to air conditioning systems, UPS systems and fire extinguishers. Document these systems directly with their next inspection dates.

Infrastructure documentation | 6 steps to IT Documentation – Part 1

You are probably at the beginning of your project to create an IT documentation. You may be wondering how to document IT in the right way. This project will be your main occupation during the next months. With i-doit you can even go a little further. Because you are developing a central IT documentation. This small difference has a significant impact. It opens up many interesting possibilities, but also many necessities.

In this first step on your way to IT documentation, you record the infrastructure of your IT landscape with i-doit. You will learn how to create locations and what best practices exist for IT documentation.

Step 2: Documentation of the networks

IT-Dokumentation Schritt 2: Netzwerk

The documentation of networks is one of the most important tasks. It consists of complex logical configurations. These are difficult to reproduce when systems fail or when you do not have a guide at hand. Do not skip this step. The good news is that your documentation will be that guide.

Consider:

  • The most important documents about your networks are network diagrams showing your LAN/WAN structures, routers and your Layer 2 and Layer 3 networks. Divide these into several diagrams. These parts show different aspects of your networks, e.g. a diagram of your office networks or a DMZ diagram
  • Set up IP Address Management (IPAM)
  • Document your DNS. Experience shows: the problem is always DNS!
  • Keep the routing available as a diagram and in text form.
  • It is advisable to have data about switch ports and the connected devices in a central place. There are many possibilities and tools to obtain this data automatically.

A word about firewalls

Firewalls get their own paragraph here. Not because they are of outstanding importance, but because many users document too much information about firewalls. Instead, store just the basic information as defined for active components. However, do not store all firewall rules.

There is always that one special case where someone needs an exception. This can be covered by appropriate documents (screenshots, configuration backups) in your IT documentation. Please do not transfer all data manually. This information changes too often.

Security documentation is a different subject. It is a different discipline than your IT documentation. Please take a look at keywords like “ISMS” (Information Security Management System) and standards like “ISO 27001”.

Network documentation | 6 steps to IT documentation – Part 2

In this second part of our series, you will expand the IT documentation to include networks. In addition to recording Layer-2 and Layer-3 networks, our experts will use the i-doit live system to show you how to implement IP address management. Especially in larger networks this topic is of essential importance.

Even though the topic “cabling” is addressed in this video, it should be pointed out again here that this part of the IT documentation should ideally not be implemented at such an early stage. The documentation of the cabling is a complex process that should be done at a later point in time.

What about the wiring?

Documenting the wiring is time-consuming. Ask yourself if it is worth it. It is tedious to find out which switch a cable is attached to and which server it leads to. But documenting every single cable is a much bigger challenge. Remember: IT documentation must be consistent.

When it makes sense to document the wiring:

  • You are active in a corresponding industry
  • You have wiring that requires explanation
  • You work with many different people on the wiring
  • You have a large/complex infrastructure
  • You start your wiring from scratch.

Step 3: Documentation of the servers

IT-Dokumentation Schritt 3: Server

Servers are among the assets that are always documented. This is because they are usually among the most important devices you operate. The services that are significant for the company are provided there. In short: the money is earned on the servers.

Consider the following information:

  • Basics (name, serial number)
  • Physical location
  • The IT service to which the server belongs or the purpose of the device
  • Hardware (manufacturer/model and hardware information)
  • Networking (IP addresses, subnets, ports, VLAN, DNS, etc.)
  • Operating system (type, version, patch level)
  • Installed software
  • Installed server roles and services
  • Specific configurations
  • Accounts and passwords
  • Access (URLs)
  • Backup Up (How?/Where?/Cycle?)
  • Contact persons (and responsibilities)
  • Accounting information
  • Warranty Information / Support Contracts

As a reminder, IT documentation must be consistent. Set clear rules and define what data you collect. But then record it for all devices. Less is more and helps you keep an overview.

Server documentation | 6 steps to IT documentation – Part 3

In this third part of our series, we look at the documentation of physical and virtual servers and record hardware and hosts for virtual environments. Our experts will show you how to allocate resources for virtual systems and document the network connection of your servers.

An IT documentation also contains organizational information. You should always include important operational data such as contact persons, supervisors and responsibilities. This video shows you how to implement this in i-doit.

Virtual environments

The same applies to virtual servers as to physical servers. The only difference is: if you have a cluster of virtual hosts, don’t try to manually copy the exact configuration into your IT documentation. Is there an automatic process that updates your documentation about which VM is running on which host? That’s fine. Don’t try to do it manually. Things change too often and you will end up with inaccurate documentation.

Consider for documentation:

  • The same as for servers/switches/routers
  • Which VM runs on which host/cluster
  • Configuration of the virtual switches

Storage Area Networks

In any case, document your storage networks. Do this in such a way that the data is still manageable and useful for you. In most cases you will need data on which LUNs are accessed by which servers. Some people need information about FC cabling. Other people work with detailed information about the physical arrays and hard disks.

How comprehensive and detailed the IT documentation becomes is up to you. Remember our most important principle: consistency. Please take into account:

  • Basics (name, location, serial number)
  • Hardware (manufacturer/model and hardware information, hard disks and physical arrays)
  • Networking (IP addresses, subnets, ports, VLAN, DNS, …)
  • Operating system (type, version, licence)
  • LUNs and what accesses them
  • Contact persons
  • Accounting information
  • Warranty Information / Support Contracts

Administrative Informationen

These are among the most important things. If your most important server fails, the serial number of the CPU is at best third-rate. What is interesting is whether there is still a warranty on the hardware or whether the support contract is still valid – and who to call in an emergency. Please remember:

  • Support contracts
  • Contact persons/companies/dealers (including addresses, telephone)
  • Accounting information
  • Software licensing

Step 4: Documentation of workplace and client systems

IT-Dokumentation Schritt 4: Client-Systeme

Now it becomes simple, but labour intensive. If you care about workplace systems, document them.
Add everything you are responsible for to your IT documentation:

  • Client PCs
  • Laptops
  • Docking stations
  • Monitors
  • Printer
  • Telephones
  • Mobile phones

The documentation should contain at least the name, model, location, contact person and serial number of a device. The situation here is different in every IT environment. It depends on what you are responsible for as an administrator – from support to the purchase of new equipment.

Client documentation | 6 steps to IT documentation – Part 4

What equipment does an employee have in use? And which work equipment do we have to provide to a new colleague? In the fourth step, we document workplace systems. We show you how to document the complete life cycle of IT assets and record the installed and licensed software.

Step 5: Documentation of software and licences

IT-Dokumentation Schritt 5: Software

The tricky thing about the IT documentation of software is the sheer mass of information. If you use a discovery tool to automatically document software, you get a myriad of unwanted data. After one run, for example, you know on how many computers and in which versions Adobe Reader is installed. This is usually not desirable. Ask yourself here what you need:

  • Information about the licences?
  • Information about installed software versions (for security reasons, etc.)?
  • Information about which software is installed on which server/client?

Depending on your requirements, you should choose a suitable strategy. This may include manual documentation. This is perfectly fine if, for example, you only need the number of Office licences installed on the clients. However, it can also include an automatic determination of the installed software on each computer in the network. In any case, it is advisable to filter out the unimportant data (e.g. installed driver packages) from the outset.

Remember: store too much information, you might not be able to find the things you need again!

Software & Licence documentation | 6 steps to IT documentation – Part 5

What equipment does an employee have in use? And which work equipment do we have to provide to a new colleague? In the fourth step, we document workplace systems. We show you how to document the complete life cycle of IT assets and record the installed and licensed software.

At the end of this video you will see how to store your “Definitive Software Library” in i-doit. This repository, defined in ITIL4, contains not only the authorized versions of all software configuration elements and master copies of the respective software products, but also the associated documentation and license information.

Step 6: Documentation of IT services

IT-Dokumentation Schritt 6: IT-Services

Let’s look at the supreme discipline. Which systems work together or are dependent on each other? What does the email service need to literally do its job?

Information like this is the most important of all. Documenting your IT services should be the goal of all your efforts. But why is the documentation of IT services demanding?

  • It relies on all the other information we talked about. The IT documentation has to be there first.
  • You need to understand how things work together and be able to write this down in a way that is easy for others to understand.
  • Components of services often change. You need to find an easy way to keep the data up to date.

There is much more to say about the documentation of services. A little tip: CMDB and ITSM. This is the minimum you should do if you don’t want to deal with all the theory:

  • Write down the services you offer your users/customers at a high level (“email”, “web shop”)
  • Try to find out which assets and technical services are responsible for providing the service. Record them and refer to the documentation of each asset/service.
  • Document how the services can be accessed.
  • Document how to test the main functions of the service in a simple way. This can be a login on a website.
  • Note down all users or user groups (including contact details). Record to whom the service is provided and provide SLA information, if available.
  • Identify technical and functional contacts for the service and document them as well.

Application & Service documentation | 6 steps to IT documentation – Part 6

“I can’t send e-mail!” “I can’t access the network drives!” As an IT administrator, you are familiar with these statements. You will hear them almost every day in your organization. But do you know off the top of your head which devices, people and software are connected to the failed service?

This sixth and final part of the series deals with these IT services. Our experts show you how to document services in i-doit. We will show you how to distinguish between business IT services, application services and infrastructure services, how they are connected and how they can ultimately be assigned to specific assets.

Finally, a word about discovery tools

There are countless tools to automatically scan your networks. And these tools play a significant role because you collect a lot of important and relevant data.

Nevertheless, remain cautious and do not confuse discovery with IT documentation. These tools provide you with a lot of important information that flows into your IT documentation. They also provide a lot of superfluous information that you do not need in your day-to-day business. Which graphics card is installed in a particular server is usually irrelevant. What is important is who to call in an emergency. And discovery tools do not provide this information.

Your IT documentation is ideally a combination of manually entered and automatically determined data. And if possible, try to reduce the automatically determined data to the minimum information. It is what you really need that counts.

6 Steps to IT documentation - The practice guide

The 6 steps to IT documentation

This compact guide accompanies your start in IT documentation. In clearly structured sections you will find compact expert knowledge that will guide you competently and comprehensively through your IT documentation project. With the individual steps that logically build on each other, you will never lose your orientation in your project.