We all learn, but very often forget after reading, hearing them, or even learning them in classes or workshops. Why ?
From a conversation of a famous speaker in reply to a question from an audience who asked "how he can remember so many different things", the speaker replied in Chinese:
那視乎你是否能夠把學到的這些東西，加得到你的知識架構裡面，即是說，要有一個鉤，能夠鉤得到你的知識架構才有用，如果不是的話，你就會很容易忘記的。
In English, that means:
It depends on whether or not you can fit what you have learned into your own knowledge framework. That means there need to be a hook, which can be hooked to your own knowledge structure. Otherwise it will be easy to forget.
It tells me that:
- There is a structure in the brain, even though it is invisible
- It is a matter of whether the acquired knowledge can fit into the existing invisible structure
- It is a matter of how knowledge (the dots) are connected in the brain.
Of course, whether it is going to be part of your knowledge structure, there are other factors too, like:
- is it something relevant to your interests, your work, or something you want to do. If you do, there is a structure
- is it something which is useful, that you'll need it some day. By useful I mean something you need to apply in real life, or something you need to remember to react under some situations, or to help or reply others as a professional, etc.
In simple terms, what I learned from this is:
Learning and remembering requires re-organizing the knowledge to fit into our knowledge framework
Inspired from this, I also have some real-life experience, which I wish to share with those who are interested. Let's look at it from the perspective how most normal people will think.
Knowledge Structure and Why It Matters
The Initiatives
In knowledge management, we talk about the 4 aspects - people, process, technology & content. My story started about 5 ~ 6 years ago. I have been building KM systems on my own (which I call BYOS - Build-Your-Own-System), with the objectives of experimenting and experiencing a knowledge portal, combining technology with content (2 out of the 4 aspects). I came across a lot of design problems which brought me to a lot of thinking, such as:
- When and why people would wish to record their knowledge?
- How knowledge should be recorded that will make sense to them?
- What format should these knowledge content takes when I codify them?
- How in real life these codified knowledge will become meaningful to me? .....
Since then, I have been building systems, tearing them down, and re-building new ones again. Reason for that is I always found something not satisfactory and I decided to build another better ones.
Later, I found it is actually a sense-making process. Don't you think so? It is one of the common problems that most people will has. We can't think too far ahead without really see and experience it. We need a process of build-test-build-test-..., particularly in today's digital world, and we should accept it as a methodology, which I call it
BayGO - Build-as-you-GO
It is actually similar to 'agile'. Then I discovered that by combining BYOS and BayGO, it becomes very powerful. Normal people without IT background can also develop a system fitting to their own need.
The Journey of Building Knowledge Repository
After a few years working on the systems for knowledge repository, I found myself always circle around a few areas:
- It is about how the knowledge is going to be applied. This is actually the business objective which should be the main consideration, which is not only the driver, but also affects how everything is to be designed.
- Does the format of content display matters? Yes it does, because it ties to user experience, business objectives and the context of application.
- How simple, or how complicated each piece of content should be defined. Should pages be more consolidated, or be broken down to smaller pieces?
- What to be included, what not, or what different alternatives are available?
- Classifications, which is taxonomy, can ties to many different things, such as tagging, search, logics, storage, people, different context and scenarios, ... etc. It can be extremely complicated, and can be endless.
To summarize, it is all about the following 4 main areas:
- Business objectives
- User experience
- Content structure and framework
- Taxonomy
Business Objectives
Business objectives are the most important of all, because it is the initiative, motives and driving force for everything. However, the major difficulty is, in my opinion, that most of the time business objectives are not clear enough, or more often losing our sights on the way especially when problems or obstacles arise.
The motives normally come from real-life business needs, or for the purpose of solving real-life problems. To fulfill these needs, or to solve these problems, it is a matter of what approach to handle, and KM is just one of the different approaches, which is often a more long-term and sustainable approach.
Once these motives are established, the business objectives can be well defined, and that's how values of these KM initiatives are established.
The difficulty in managing knowledge is that, it is invisible. Some may argue that codified knowledge is visible. That's true too. But in real life, would it be better to be defined as information, before it is properly understood, absorbed in our brain, and able to apply even under different scenarios, and bring results. That's how people consider make-sense.
When we deal with an invisible entity called knowledge, we are bound to try different things, different methodologies, technologies and approaches. You will find a lot of good ideas but that's exactly the problem - too many ideas. This is time when business objectives become the judging guidelines and decision making factors.
User Experience
Building a knowledge repository is to deal with something invisible, but expecting it to be usable and even remarkable. That's exactly where the difficulty is. Can you see the contrast here? We are bound to meet a lot of challenges and uncertainties. I can guarantee you, even if you ask the users, they can't really satisfy you. Most people cannot tell what they really want, until they see and feel it. Even when they do, what they're going to tell you will change. Why? Because it is much easier to tell you what does not make-sense, instead of what make-sense.
That's also the challenge with traditional IT approach, in which they always requires users to provide specifications and requirements. In reality, it often drives to the result of using low-risk shelf products which are already available, visible, can be tested hands-on, and at the same time can also be customized. With this approach, you're bound to accept the pre-designed structure and workflow, which may deviate from the real make-sense expectations from the real users. This is an area the business objectives cannot define.
Now it brings the important question of what will make-sense. But what is make-sense? My experience tells me it is a feeling, a user experience, or something 'unspoken but it's there' which is difficult to express. My experience also tells me, to deal with this kind of make-sense situations, we need to allow users the time to experiment and experience it. Then they can possibly tell you more bit-by-bit. User experience is a very important determining factor which is a measurement of whether or not the project is successful or not.
Based on this, I found that the BYOS + BayGO approach makes a lot of sense. Basically it allows the user to define and workout their own system in a one-small-step-at-a-time approach, with fast and flexible prototyping tools which allows them to try, experiment and experience it. In addition, this approach also promotes unity and harmony across the team.
Content Structure and Framework
To work on knowledge content in order to make-sense, it has a lot to do with structures and formats. I would say this is the habit and behavior of most people in their mind, primarily because this is actually how people think in their brains. I am not academic nor scientist. I can only feel it, but this exactly match what the speaker said described in the beginning of this article.
If we re-visit the business objectives again, why and for what a repository is built? This goes back to the motives, and that's the values of getting things done. The next questions - what and how - will bring us to the actual working details. It is by deciding the criterias, and by designing the right format and structure of the knowledge content.
Then comes another area of complication - what is the context or user scenario that the content will be consumed, and how. When the context is different, the presentation will be different too. Sometimes it is even worse, when there will be different types of users or stakeholders, which is a typical situation in an organization.
How content should be presented, from what perspectives, the flow, the way to display, is it too long or too simple, consolidated on one page, or broken down into different pages, ... etc. All these questions will arise and require consensus. This is also where the formats and structures will come into place. Very often, content creators require flexibilities in the systems so that they can satisfy the user expectations.
While establishing these formats and structures, changes are unavoidable. In fact, a thoughtful and well-structured content will last longer, because there will be less chance requiring changes and in future.
After all, this will be a good exercise, because it is a re-thinking process to re-justify how things should be done, or any re-adjustment is necessary. It is a process of re-engineering, identification of best practices, and re-alignment of the business process.
Taxonomy
While working on knowledge repositories, at the same time you are also organizing codified content. It's like how we organize our home, our desk, our drawers. How? It is all about classification, or in broader terms it is taxonomy. It is also the bigger structure.
Coming to classification in reality, you will discover there are just so many different dimensions of classification to fit many different scenarios. It is actually an extremely complicated process. Why? If you really think about it, most classifications are based on context, which again is invisible. The context in your mind could be different from the context in my mind, even though we are using the same terms. Even wordings are important to avoid ambiguities.
I guess everybody is familiar how to organizing his desk, his room, or his cabinets, but not too many people have the experience organizing knowledge, which is invisible. We organize files, books, but what about organizing knowledge in the brain.
By going through the knowledge repository exercise, you will find that knowledge in the brain is also somewhat organized. In fact, it also help shaping the way we look at knowledge, because we become more clear what, and how things should be. It becomes a learning by experience, and this new learning corrects what was originally un-clear. Things becomes more systematic and aligned. This feeling also brings extra capacity, because you will feel easier when things are becoming simple.
An Example from My Discovery Channel
Right in the beginning when I started to build this knowledge base, my focus was, how it is going to make-sense.
This is not the first version, and for sure not the last version either. New version and new ideas is already in mind. Changes will come, but each change is another step forward.
Soon after, it becomes my assistant, like expanding my memory and capacity.
I am not a designer, but the BYOS + BayGO approach gives people the freedom, eliminates technical barrier and a worry-free environment. Basically everybody can do it, if they will.
Final Summary
The very valuable learnings in the journey is the Structuring of Knowledge, which allows me to re-think about KM in practice, about knowledge base, about why, what and how. KM practice is difficult in real life business, but this is a practical approach which make-sense. Followings are the learning:
- Working on a knowledge repository is also organizing knowledge, which shapes the structure of knowledge content in a systematic manner.
- The knowledge structuring process maps the invisible knowledge in the brain to a visible format. The final visible structure also shapes our brain because it is a learning process by itself.
- The iterative prototyping process under the BayGO approach is actually a design-thinking process. It works very well.
- The exercise can be a tool to increase capacity and is a process of self discovery.
Thanks to the speaker. Because of his reply with wisdom which resonates with my experience.
In such an exercise of knowledge repository, there are tangible and intangible benefits. Tangible benefits depends on utilization which can be collected from system. For the intangible benefits, user should probably ask themselves:
What are the impacts as a result of the practice, to the organization, to business, and to the individuals.
Last but not least, I want to emphasize that, the process is more important than the results in this type of journey.
- Log in to post comments
