docupike - how to start#
- Know your Requirements
- Know your Users
- Know your Existing Documentation
- Know your IT
- Know your Processes
- Take your Time
- Document your Documentation
- Think Outside the Box
- Bottom Line
Often, people consult us with the following questions or similar considerations:
If I don’t have any IT documentation yet: What is the best way to start?
With how many details do I begin?
Which area do I cover first: Clients and servers? Buildings and rooms? The network?
How many categories do I have to cover to get a good overview?
…
Anyone who deals with the subject of IT documentation in depth will recognize quickly that here, as well as elsewhere, the following applies: The first step is always the hardest.
In this article we would like to map out what the reasons for these questions are and how we can answer them in an optimal way.
Know your Requirements#
It is not by chance that people deal with the subject of IT documentation. It doesn’t work on its own and doesn’t serve as an end in itself.
Either the request to establish IT documentation in the IT organization is made by the IT department itself, by more senior levels, by the management or from the outside (compliance).
Before you deal with tools like docupike, the following issues should be clarified: What targets do you want to achieve or support with IT documentation? Have the administrators lost track of the infrastructure? Does the management want to specify (IT) services to be offered to in-house departments and/ or to customers? Are there laws, standards or guidelines which stipulate that there has to be IT documentation?
There are various approaches: Top down describes how the requirements are broken down in a process from top to bottom. This also applies to the documentation: Before you elaborate on details of single IT components, you map out the full picture. Bottom up is the counterpart: Based on a detailed infrastructure, you can model services, assign maintenance contracts or create disaster recovery plans. But to some extent, the requirements come from all sides at the same time. So, before you document even one IP address or read out a server specification, you should channel these requirements and bring them into well-considered structures.
Know your Users#
One of the most important questions is: Who works with the IT documentation? Who benefits from the documentation? Both in small and in large IT organizations, it makes sense to set up a documentation team which jointly deals with all questions arising around the subject. Often, there is a documentation manager in the team who coordinates all processes concerning the IT documentation. Additionally, there usually is a person from the managerial level who operates as a sponsor and supplies resources (time and money) in order to bring the introduction of IT documentation to successful fruition. Moreover, there are various other people who actively help to shape the IT documentation or passively use it for their own purposes.
Know your Existing Documentation#
Seldom is it the case that you really start from scratch. At a rough estimate, approximately 100 percent of our customers use the rival product of docupike called Excel. Lists of IP addresses, lists of rooms and contacts, rack plans … we have seen it all documented in a two-dimensional form. Perhaps you also have other specialized tools which create the current ITSM landscape. Do you want them to be replaced by docupike? Can collected data be reused? Are there exports or interfaces? In this context, data integration is an important keyword.
But in each case, do you have to enter the data manually or can it be processed automatically?
Know your IT#
Let’s start with a quote:
You only see what you know.
Does this sound familiar? You are right; this is a quote by Johann Wolfgang von Goethe. In connection with this article, it means that administration and management will find it difficult to keep an overview of the IT infrastructure without documentation which is in sufficient detail and up-to-date.
n this context, the aim is to bridge the gap between richness of detail and abstraction. When you have to decide whether new information should be included in the IT documentation or not, ask yourself the following question: What would be the benefits of recording these details in this way, preserving them and making them available to others? Documentation which is too detailed bears the risk of becoming too much for the reader and seems to be unusable. Does every cable in the computer center have to be recorded with details about length and color? Or is it sufficient to record the port connections between active network components?
Many of our customers start with the listing of locations (buildings, rooms, racks) to map server and network infrastructures. Then the next steps follow quickly: software and services, clients and workstations, passive components (patch panels and cables).
Ergo: Each project has a defined beginning and a defined end. In between, there can and should be milestones which are achievable in practice. The same applies to the introduction of IT documentation. Which items are given a high priority; which items have a low priority?
Know your Processes#
IT documentation is only sustainable when it is always kept up to date and deeply rooted in the working processes of your employees. Only information which is up-to-date is useful. In any case, you should avoid outdated or wrong information. Before you “flip the switch” and implement your IT documentation in live operation, you should identify all processes where IT documentation is relevant. An example: when docupike is incorporated into the complete life cycle of an IT component, starting with planning, purchasing, putting into operation until disposal, it has crucial consequences for many processes (and other tools). In this connection we speak of a “leading system”.
Take your Time#
You don’t start with IT documentation tomorrow and expect it to be ready the day after. It takes time to answer the questions of who documents when, what and how. In smaller organizations, it can be faster than in larger ones until the IT documentation can go live. Several weeks or months are rather the rule than the exception. You should pay attention to the well-known magical triangle from the area of project management. Here the key points are cost, quality and time. Within the triangle is the project. Now the project manager can decide which two of the three corners of the triangle to achieve. To reach all three corners of the triangle at the same time is often very hard or even impossible. We suggest not striving for the 100 per cent mark at the beginning but instead only for 80 per cent with special attention to a high-quality.
Document your Documentation#
There’s no way around it to write down the things which are important for IT documentation: what is the design of the IT documentation? Which processes are defined? Therefore, it is a good idea to maintain a Wiki with the very same information as docupike. Fortunately, a Wiki or document management system is already present in most cases and thus can be used for this purpose.
Think Outside the Box#
Those who seek inspiration or want to draw on a reservoir of experiences don’t need to look further. Besides regional user meetings and nationwide user conferences, we offer many contact points where you can exchange views and experiences concerning docupike and IT documentation.
And when a strong (service) partner is required, we and our partners offer workshops and packages etc. which are ideally suited for the starting phase of docupike.
Bottom Line#
"So where do I start now?" It’s not quite simple to answer this question. Otherwise we could have spared you by elaborating on this subject.
In fact, the answer depends on many factors which have to be observed. Every IT organization and infrastructure is different and is subject to a good degree of dynamics. Therefore, we can’t give you a general answer. It is and will always remain an individual task to implement IT documentation. Feel free to contact us! We’re happy to help you!