your checklist for process issues
Problems in the company's organizational processes are not immediately noticeable. At first, the “alarm bells” seem like random errors.
For example, two different teams find themselves working on the same task. It happens to everyone! Or an employee leaves, and with him goes all the knowledge about one of the systems. Or great ideas are endlessly postponed for later, because they encounter difficulties in implementation.
These and other similar situations are markers of problems in processes that are partially solved with the help of the knowledge base.
My name is Sasha Kamzeeva, I am the head of systems analysis at Lamoda Tech. For 8 years I have been helping to create and maintain knowledge bases in the company. In this article I will list the problems in the knowledge base that affect organizational processes and tell you how to find solutions to these problems.
The article will be useful for those who influence organizational processes in companies: managers of any level, architects, product managers, as well as everyone who cares about knowledge within the company. And at the end, I will give a checklist for self-checking and making the right diagnosis.
How are knowledge base and processes related?
Working in IT since 2010, I noticed how problems and their solutions in the knowledge base were reflected in our processes.
Before I prove this with examples, I will explain what I mean by the terms “knowledge base” and “organizational processes”.
Knowledge base — this is not just documentation, but established processes for transferring knowledge to each other through any communication channels. For example, a developer finds out with an analyst in a chat how an order is processed depending on the parameters. And this chat and the format of communication in it is a knowledge base. All chats in corporate messengers, email correspondence, techtalks, where engineers share expertise, are your knowledge base. A board with stickers in the office, where the team conducted event storming with an action sheet is a knowledge base.
Organizational processes In this article, I will generally name everything that helps to transform an idea into business value: organizational structure, planning processes, hiring, onboarding, design, development, testing, etc.
One of the most striking examples that inspired me to structure my thoughts into this article happened in 2021. We underwent a transformation of our development teams. Instead of teams that were responsible for specific systems, we switched to vTeams — cross-functional teams that gather to implement a specific task. We will talk about this in detail they told in the article. I organized a meeting with all the test engineers to discuss how to properly perform integration testing and UAT (operational testing) after all the changes. After 5 minutes of conversation, I discovered that the guys met together for the first time in a year. And this year they solved the same issues on their own, did double work: did not unite, did not transfer knowledge to each other – each fought in his own corner separately.
This is how the hypothesis emerged that Problem in knowledge base can influence organizational processes.
In this article, I have collected eight problems in the knowledge base that show that something is wrong in organizational processes. By developing knowledge sharing, working on the knowledge base in the team, you can directly or indirectly solve problems in organizational processes.
At the end, you will find a checklist for self-assessment. Take a closer look at the items you cannot check off: perhaps this is your growth area, and it is worth taking on right now, before the problems move to a higher level.
First problem: there is no knowledge base
When we say that a knowledge base helps to identify problems in organizational processes, the first question arises: what if there is no knowledge base?
For me, this is equivalent to the fact that there is no culture of knowledge transfer in the company. As a result, no synchronization between teams and within teamsBecause of this, employees can waste time on already resolved issues, as was the case with the testing engineers that I told above.
Also there is a risk of costly mistakes. I will illustrate this with a story from my own practice. We had a useful idea for our clients: to add a “Comment” field for delivery to the checkout screen. With its help, our couriers could receive detailed information on how to call the intercom, get to the buyer, and so on.
This feature was quickly implemented in client applications, but the field did not appear in the courier application for a long time: the task was constantly blocked in the delivery and order processing systems due to low priority. The first team did not expect that the field was forwarded through 6 systems, and there was no knowledge base about this, so they scheduled the task for themselves, without synchronizing with other teams. As a result, everything that the first team did had to be hidden in a drawer. We spent time and money, but did not solve the problem.
If there is no knowledge transfer process in a company, then they are lost forever. In 2016, we had an expert who knew everything about discounts. After he left, it took us six months to recreate the same knowledge. Six months without knowledge about e-com discounts is a critical time for business.
When knowledge transfer processes are not structured, it's long and difficult to onboard new employees. I had a small team. When it was growing, I spent an hour a day explaining how the IT landscape and all our business processes were structured. When we set up a knowledge base, newcomers began to cope independently. Thanks to the knowledge base, I saved months of work for my employees, because the team grew and onboarding became more voluminous.
If there is no knowledge base, then it is great to start with a simple way to store knowledge within the company – with TechTalks, small meetups where specialists from one field present reports to colleagues from other departments. This way you can easily and cheaply store knowledge within the company in a structured form.
Another bonus is the ability to reach “random” listeners. Remember the example of the shopping cart and the “Comment” field for courier delivery? If the team knew how complex our monoliths were, they would have planned the development differently.
The second problem: the knowledge base is not used
The second popular problem concerns documentation in any form: Confluence, ReadMe, tasks in JIRA. Some teams write/save something in one format or another, while others do not use what is written.
Within a company, this problem is costly: some spend time to preserve or pass on knowledge, while others do not take advantage of it. It turns out that documentation is not needed?
We also had such cases and for myself I identified the following reasons:
The knowledge base is outdated, so what's the point of accessing it? If we decide to save some data, it is important to build a process for updating it. And if the knowledge is not required, then it is ruthlessly deleted, transferred to the archive, or marked as outdated.
Inconvenient information search or unclear structure lead to poor user experience. And as a consequence, unwillingness to search for something in the documentation. Therefore, it is necessary to test the structure on users, collect feedback and work it out.
Poorly written and unclear. In this case, it is even more offensive, since a lot of time has already been invested in documentation, and because of poorly composed text/diagrams, the knowledge base will not be used. Therefore, it is extremely important to be able to clearly and concisely formulate your thoughts, to know and designate the goals of the articles, so that the reader can easily understand what is written.
They don't know about the knowledge base. This also happens, that's why it's important to talk about it, write in corporate channels, tell about it at all public events.
The third problem: there is no single source of knowledge
A popular problem is that some companies use Confluence, others use Google Docs, and others only use Notion. As a result, there is a high probability of errors in the company. It is unclear which document contains the most up-to-date information, and not all colleagues know about the existence of different sources.
We had it like this: business looked at a Google document, and IT looked at Confluence. As a result, comments, their correction and maintenance in an up-to-date state led to double costs or to an incorrect result.
Also in this case, it is necessary to ensure the safety of all documents in case of employee departure. And this leads either to loss of information sources, or to double or triple expenses, so as not to lose data.
There is only one way out: to achieve a single source of information so that the entire team looks at the same articles, the same documents. In extreme cases, decompose the information in such a way that articles in different sources complement each other, and do not duplicate each other.
The fourth marker: the lack of a unified glossary
The lack of a single glossary and division by domains, as well as the discrepancy between the internal and external glossaries, lead to the fact that we speak different languages.
Previously, teams at Lamoda could call different processes and entities by the same word – “returns”. One team talked about situations when a client bought an order, returned the goods, and now wants to get money for it. And another team perceived this as goods that the client refused at the fitting stage, without buying the order.
The processes are different, the essence is different. Until half an hour passes, until they hit a dead end, return to the beginning, redefine the terms – they will not understand that they were not talking about the same thing.
Problem 5: Lack of knowledge about organizational processes
This block is responsible for understanding and describing organizational processes.
If there is no description of roles, then there is no division of areas of responsibility. In this case, tasks that fall into the areas of responsibility of several teams can be solved simultaneously from both sides. Or they can be forgotten altogether. For example, systems analysts and tech leads have similar areas of responsibility. If this is not recorded anywhere, each of them will constantly wonder where the boundary of the areas of responsibility lies.
If there are no standards, then there is no understanding of quality. This indicates a serious problem in the organization. What does it mean to have “well-designed services within an initiative”? What does it mean to have “well-tested services” or “well-done code reviews”?
If there is no responsibility for processes, then there is no transparency and clear forecasts for deadlines for the business. It is also a fairly popular story when there is business and there is IT. Business expects IT to deliver business values rather quickly and to meet the predicted deadlines and promises. If IT cannot do this, then there is no transparency and understanding of why it is taking so long. It is even worse if the team cannot predict the deadlines at all. When there are no responsible people and a complete picture, nothing can be said to the business, which means they will not want to invest money in IT and in the development of the company.
Problem 6: Lack of knowledge about domain areas
Problems arise when there is no clear decomposition of domain areasThere is an IT department, there is an IT landscape, but no one understands how the list of products or business processes of the company is formed, what it is divided into.
If knowledge about domain areas is not updated, and changes are not recordedagreements and progress on tasks are not saved. This leads to two problems:
The teams don't have a target picture in their heads and trust in the knowledge base. Let's go back to the project with the “Comment” field for delivery. The guys had no idea that the information had to go through all the order processing systems and reach the delivery system so that sales representatives could see it. When you don't have this picture in your head, it's impossible to decompose tasks.
If employees have outdated information, there is no trust in the knowledge base. In this case, Confluence or another similar base will be perceived as a trash bin. You spend time trying to understand this flow, but it is in vain.
It is especially important to ensure that colleagues have allocated time to update their knowledge after changes. It sounds quite logical and obvious, but it is very difficult to implement. Because usually, after the release of a feature, development immediately takes on the next task.
It's a difficult process of will – to give the team time to update the data. But only then the knowledge base will be usable.
The seventh problem: knowledge of architecture
If no architectural scheme, descriptions of a system of services or contractsthe same problems as in the previous case begin, but from a different angle. The team does not have a complete picture in their heads, not just of business processes, but of the entire IT landscape – and there is no trust in the knowledge base.
We had a situation where an employee who was designated as responsible left a service that was critical to business processes. An incident occurred, and support spent more than 30 minutes looking for a solution. We spent half an hour of time that we did not have in a critical situation.
Problem 8: Safe Security
If in company there is no public access to the knowledge base or it is not easy to getyou won't have to suffer with it and waste time. The need for an answer will disappear, you will solve the problem differently.
Another example is when general information is closed. As a result, employees will not use the knowledge base at all or will open a duplicate. We discussed the problems of two sources of information above.
The knowledge base must be open. Everything that can be opened must be opened – then this source will be used, it will be updated, and this process will be established.
Let's sum it up
Below you can check yourself on the checklist. Put pluses and minuses opposite each item and count their number. If there are more pluses, you can congratulate yourself: organizational processes work well. Of course, there is no limit to perfection, but this is already a big step forward.
If there are more minuses, this is another argument in favor of change. How to change is the topic of a completely different article.
Check list:
The process of knowledge transfer is well established.
There is a person responsible for the knowledge base.
The knowledge base has one source.
The knowledge base is used.
Employees understand where and how to look for information.
Employees know how to update the knowledge base.
TechTalks are held in the company.
The company has a glossary.
The glossary is divided into domain areas.
If there are internal and external glossaries, then the terms and definitions are no different.
Colleagues use terms from the glossary.
The code also uses terms from the glossary.
The roles of organizational processes are defined and described.
Teams are aware of the roles of organizational processes.
The company has adopted standards.
Teams know these standards.
There are those responsible for organizational processes.
Teams know who is responsible for organizational processes.
Domain areas with descriptions of products and business processes have been defined.
There is a person responsible for each domain area.
Knowledge about domain areas is updated.
Colleagues have a designated time to update their knowledge after changes.
Agreements are recorded and can be found in the knowledge base.
There is an architectural diagram.
Each system/service is described in detail (responsible persons, purpose, interaction scheme, useful links).
There is a description of the contracts.
Information about the system/service is being updated.
Those responsible have time to update their knowledge of the system/service immediately.
The knowledge base is available to users, and no separate approval is required to obtain the necessary information.
