Das Wichtigste in Kürze:
- Bedeutung des Change Managements: In der dynamischen IT-Welt ist ein effektives Change Management entscheidend, um IT-Systeme regelmäßig und sicher an neue Technologien anzupassen, was letztlich Produktivität und Sicherheit steigert.
- Herausforderungen und Komplexität: Komplexe, gewachsene IT-Infrastrukturen und Mitarbeiterwiderstände erschweren den Wandel; strukturierte Change-Prozesse minimieren hierbei Risiken und Ausfallzeiten.
- Docusnap als Unterstützung: Die Software Docusnap bietet gezielte Werkzeuge, um IT-Dokumentationen für Change Management zu optimieren, was Prozesse transparenter und leichter nachvollziehbar macht.
When you deal with IT documentation, there is nothing more time-consuming than documenting the daily changes. There are always minor or major adjustments of the configuration and the hardware and software in use. The bigger the company, the larger the number of changes. The documentation of these tasks also depends on how changes are handled at your company in terms of organisation. If you use change management for this purpose, you can base your efforts on an existing structure. Congratulations, this is quite a big advancement.
For all IT departments who still rely on the principle of hope when performing configuration or hardware changes, the perspective is not that good. You need to find a way to make your technicians remember that they must document the changes they made. Otherwise, the documentation will never be up-to-date. If no change management is in place, the responsible manager will not know about all the required tasks. So, how to check if the documentation is up-to-date or not?
This documentation must become an integral part of day-to-day business
No matter what your situation is like at the moment, a viable solution must be found. Some of the steps can be automated by using a documentation tool such as Docusnap. Software can help you keep the inventory database of your IT systems, i.e. the CMDB, as much up-to-date as possible. Some network plans can also be updated automatically, but not all of them. Some of these IT relations must be modified manually. Communicate the processes required for this purpose and allow the system admins the time required for the documentation. Also keep in mind that newly purchased software licenses and new maintenance agreements will not get into the database by themselves, i.e. all related changes must be entered manually.
Document your change management in a ticketing system
If a ticketing system is in use at your site, e.g. from RT, Helpline, or Matrix42, you have probably already addressed the topics of IT service management and ITIL. Maybe a change management process has already been implemented or you are currently doing so? Congratulations, this is very good decision. In this case, simply take the tickets you created in the Change category and assign them to an IT system or an IT service as defined in the service catalogue. This can be done by the responsible IT staff member when processing the ticket. By filtering the tickets appropriately, you obtain an uninterrupted history of all changes made to the corresponding system. Based on this history and a basic inventory of the IT system, you can always track its current state.
It might also be a good idea to always export the tickets of the Change category so that they will be available in emergency cases. A problem of many ticketing systems is that they are tedious to install. It takes quite some time to rebuild these systems from scratch, and in some cases, you might even need an external service provider for this purpose. If, however, this information is required immediately in an emergency where the systems are not available, you will not have the time for a complete reinstall. Yet, this situation should be assessed within the framework of risk management.
Another option for documentation: the service catalogue
If you would rather refrain from integrating the ticketing system, you can always rely on your service catalogue (if you have one) and document the changes directly in the appropriate service file. In case you created your service catalogue from within the IT Concepts module of Docusnap, enter your changes there. This ensures that the information will be available quite quickly, even in an emergency. Remember that you should make sure anyway that the Docusnap database is always available, even in such cases. This is the benefit of using a documentation system. To be honest, some efforts are required to document the changes directly in the service catalogue. If you made a change as recorded in the ticket, then you must document it in the service catalogue, i.e. you will have to switch applications. This is not the most elegant solution, but it has some advantages.
Change documentation for individualists
If there are no mechanisms for structured update or change processes for your computing systems, you should take action immediately. Otherwise, you are wasting a lot of potential in your company, and in case you have to face reviews or audits, good luck! How do you want to provide information on elementary components of your network? IT documentation is not an end in itself, but a requirement, e.g.for auditing purposes. Chaotic management is not a viable way.
Depending on the prerequisites existing in your network, you need to find and define feasible procedures.
Some hints on your way…
- If the effort involved in change documentation is too strenuous, your staff will hardly ever accept it. But no matter what the situation is like, they will complain about this task anyway, so you can ignore that because it has to be done.
- Automate the documentation of configuration changes as far as possible. Docusnap collects data on entire permission structures and configurations of Windows operating systems, SQL, SharePoint, and Exchange Server. The same is true for entire permissions structures on the file servers and – what is most important – the Active Directory database.
- The responsible manager must verify if the staff members really document their work. In this context, it might be a good idea to introduce check lists for configuration changes that must be signed by the person responsible for the system. If somebody confirms by signature that the change has been documented, it is more likely that this really happened.
