Recent surveys have shown that the business is increasingly involved in managing the IT department because it is more important within the strategies. Therefore, it is essential to be more productive and deliver the information required by the business department.
In the previous installment, we talked about two critical keys within the IT organization, based precisely on the definition of what services to provide and the right way to manage them – definition of IT services and single touchpoint. Today we will see that inventing the wheel daily is not a valid path to productivity.
Knowledge generation and use
There is a proverb within incident resolution: every closed incident must generate knowledge or use knowledge. When the incidents we handle in our department do not have either of these two outputs, it means that our department is dedicated to inventing the wheel every day.
Knowledge within an IT department is everywhere; in many companies, it is never valued. From the moment you start to design a service, implement it and get to the moment of operation, you are generating knowledge that will be important today and much more in the future. But, usually, it is seen that in the developed services, the information generated is not documented, stored, and transmitted, which always leads to a high dependency of the developers on the projects and also to a high level of mistrust, which will not allow the evolution of the supported services.
If we document, index and train from the beginning of the services, we will make it possible that the service does not stop working and, even better, that it can evolve. Furthermore, we will ensure that the information is not concentrated in a single person, that the evolution is open to different points of view, and that past mistakes are not repeated in this or other services.
Below is a set of guidelines to achieve this:
- It is necessary to generate service architectures, identifying the components, integrations, data, and formats in detail. Similarly, it is vital to identify where the data come from and what they are transformed into and then determine where they are going. This will allow, in the presence of changes, to know what can be affected inside and outside. As a result, services will be replaceable without major implementation traumas.
- Mapping should be made between the technical and business inventory, allowing business changes to be easily captured technically. This will help the department always to be aligned and be a facilitator. In addition, it can provide information on the use of business services and statistics on the loss of money in the event of possible unavailability or failures.
- Documentation must reflect any modification made to a service. Thus, if a new component is introduced or a data changes format, the company will always know why it was done, for what business reason, and what implications it has within the operation. This will prevent services from evolving without control and will always allow using the knowledge generated to support decisions.
- As we have already mentioned, we must solve every incident with the help of documented knowledge, or we must generate new knowledge. The incident process is responsible for maintaining functional services, which is why knowledge is necessary. For example, suppose the team in charge of maintaining the services is unclear about what the business is looking for with the service, what kind of data flows through it, with whom it connects and how it transmits information. In that case, it will hardly be able to provide a quick solution to a failure, it will not understand why a service is a priority, and it will not know how many people are affected by it. This is why it is vital that the incident management group is trained in the service, as well as in the platforms, and that they have documents to which they can resort in case of failures. That way, they can enter a KMDB -Knowledge Management Database-, search for previously solved cases and see if those situations are helpful. If no previous cases are found, they can look for physical, component, or data architectures and provide new solutions, which we should document for future occasions.
- Finally: from eagerness, nothing remains but weariness. Knowledge generation and use should not be the whim of a few within the department. It should be everyone’s responsibility, from top management down to the lowest profiles, should be reflected in each of its members. Solving quickly, without documentation, will only waste valuable time in the future. Implementing fast, without documentation, will allow no one to understand why things were done. Designing fast, without documentation, will only allow the connection to the business to be lost and all change to be torturous.
In general terms, this will allow the IT department to help the business and support the tendency to be a strategic piece within the scaffolding of the business. This is a task that definitely requires the work of everyone, without exception, and a discipline that, in the short term, will begin to be rewarded in the business.
Writed by Luis Pulido
CEO
BPS