2Know Magazine: Sharing KM Knowledge
2Know: Sharing KM Knowledge
March 2015 - Magazine No. 186
March 2015 - Magazine No. 186
Edition:
Written By David Rozental

Everybody learns lessons. Everybody wants to improve their lesson learning.

Researches and lesson learning were always intertwined with Knowledge Management. The connection between lessons, organizational learning, organizational memory and learning from past experiences create this tight relationship. In today's market there are several lesson learning methodologies: the drilling method, the increasingly popular AAR method as well as many other methods and versions. All methods share the same purposes:

  • To reproduce successes.
  • To prevent recurrence of mistakes.
  • To avoid reinventing the wheel.

The common denominator of everyone involved in this field is the fact that regardless what method they choose, it's always important to search for the root causes. During the lessons learning activity, the team members should invest in finding the causes for the gap between the organization's predictions and reality. It is customary to attempt to reach the root causes at this point. Root causes are defined as the basic causes that led to the situation debriefed. Preventing the root causes would in effect prevent the whole situation from happening.

So, what's the problem?

When a team debriefs an event and attempts to understand its causes, there is usually a tendency to halt at a very high level of answers. This abrupt stop at a relatively superficial and trivial level will usually yield basic and trivial lessons and produce corrective activities and not the desired preventive activities.

Typical causes that are discovered in debriefs include:

  • Lack of training.
  • Human error factor.
  • A lack of procedures.

These factors are usually just a superficial symptom of a larger systematic problem. Therefore, we must search deeper and reach the root cause.

There are several methods and approaches for analyzing root causes, the most popular one is the good old "5 whys" method. This simple method assists us in "peeling away the layers" of symptoms and reach the root cause. It consists of asking "why?" five times. The method was developed by Taichi Ono, a Japanese businessman who is a key figure in the LEAN field. Ono is considered the founder of the Toyota Production System.

It's important to emphasize that 5 is not a 'holy number'. We must ask the number of questions required in order to discover the root cause, whether 5, 6, 8 or 3. The 5 whys method assists us in finding the problems in the process, and 5 levels as a rule of thumb, usually brings us to the root cause.

When does one eventually stop asking?

When one reaches a factor beyond one's control or when a factor beyond the sequence of facts and symptoms has been detected. We have then reached the root factor.

 

Example:

What happened?         The car wouldn't start.

Why?                           The battery ran out.

Why?                           The alternator malfunctioned.

Why?                           The alternator belt tore.

Why?                           The alternator was worn.

Why?                           The car wasn't taken care of in time.

The car care is a diversion from the sequence of facts and is a first reference to a process. We have reached the root cause.

 

To conclude, peeling the events away and reaching the root causes is a perquisite for quality lessons learning. Utilizing the 5 whys method or others can be indeed helpful.

.

 

 

 

 

 

 

 

 

 

Written By Lior Moran

Till 20 years ago, finding information was a complex mission. Most of us remember it as an effort: you had to go to the library, search through encyclopedias and turn to other people for answers. Nowadays, we still search for information, only there is the internet which has made searching for information an effortless action. With the click of a mouse, we receive endless information. Now that we have all this information, we must navigate through it and locate the relevant information within the page or document, in the shortest time possible. People like skimming, they don't have the time to read the full text they are presented.

This is where "internal accessibility" comes into play.

Internal accessibility deals with providing a user with the means necessary for optimal navigation in a document or knowledge page he/she is presented, in order for him/her to optimally comprehend its content.

Several methods are used in order to provide internal accessibility:

  • Smart documents-An orderly organization of the document and creating the document smartly: opening the document with an organized document map followed by information nuggets derived from it. For more information regarding the method:

http://www.kmrom.com/Site/Articles/ViewArticle.aspx?ArticleID=1085

  • Templates- Using uniform templates for documents/knowledge pages can assist the user in navigating through the document and save time spent on the cognitive effort of understanding the content.
  • Icons: Using icons and tags can assist the user in understanding the context and relevance of the information.
  • Highlighting: Internal highlighting and tables are very important as they organize the information structurally, making it more appealing. Furthermore, information presented in this manner is usually short and concise, and as such is more effective than full passages.
  • Pictures: Inserting pictures lightens up the atmosphere and provides the text with an informal appeal (which does not mean it is actually informal).

To conclude, using these tools may assist users in navigating through a document/page/item and comprehending its content in the clearest way.

Note: if one does not reach the content, he/she will obviously not have the chance to comprehend it. So why waste time and effort on finding it, if the result will be ignoring what is read?

Internal Accessibility is critical for reaching specific information, understanding it and using it. Therefore, it is highly recommended.

 

 

 

 

The review is based an article by Linda L Briggs published in TDWI.

In her article, Briggs suggests tips and methodologies for collecting requirements for Business Intelligence based on an interview she conducted with Jonathan Giager, Vice president of Intelligent Solutions. I wish to analyze the recommendations and enlarge their range of appliance. While the tips offered were intended for BI, they are suitable for KM, almost with no change at all.

 

Hereby are presented the main points stated in the article:

The difference between a KM/BI Project and a traditional project when collecting requirements:

  • It is more complicated to define a final destination and choose people suitable for involvement in the project.
  • The requirements appear during the project's run. It is useful to use a prototype for collecting the requirements.
  • Defining the project is not clear enough, even if the users know exactly what they want; the details are usually unclearly defined in the first stages of implementation.
  • The project is harder to justify as benefits are in many cases only long term benefits. It's harder to get assigned a budget.

 

Main properties of KM/BI requirements:

BI requirements share some common properties- they must be as clear as possible, and the main component of the project is not the information supplied, rather the final product, i.e. the business value, which is not supplied by the data/information/knowledge itself, rather by its usage.

 

Collecting requirements and the importance of the data:

There are two types of organizations-those who have a data manager/knowledge manager and those who don't.  Organizations that have a data manager can choose people suitable for involvement in such a project and thus make correct decisions. Organizations that don't have a data manager face an extremely difficult challenge: not making the wrong decisions regarding the data. These organizations should aspire to hire a data manager.

 

Tips for analysts/KM consultants before collecting requirements:

The most important thing is listening to the business user. If interviews were used for the purpose of requirement collection, it is important to prepare the questions and prepare the interviewers for following questions in case the business user isn't supplying all the required data. The goal is to develop a synergy between the business user who is familiar with the business and the analyst who is familiar with the BI abilities.

 

The challenge in collecting requirements using interviews

A BI architecture correctly built is flexible to the discovery of further requirements in the future (assuming we reached the correct level of detail). The analyst/consultant's skills are critically important in this case, as he/she can predict requirements the business users cannot.

 

Dealing with requirements evolving during the project's duration

This is a common phenomenon as analysts/consultants can't predict all requirements as these evolve with usage. A great technique for dealing with a situation like this is using a prototype suitable for the initial requirements, yet equipped with technology that enables inserting further requirements during the project's run.

 

Knowledge and skills required for requirement collection for a KM/BI project:

Analysts/consultants should know to ask the right questions, differentiate between good and bad information, ask further questions according to the information they receive and know how to interview. Also, they must have a set of analytical & data skills, and obviously a familiarity with BI. The most important knowledge required is business knowledge: what promotes business, business objectives and business environment & competition.

 

Is finding the right analysts a challenge?

It is a challenge to get the analysts to fully understand the business in order to utilize the content and get the real business value out of it. The problem is that business organizations do not always know how to deal with what the BI/KM can supply, especially in the fields of business analysis and dashboard application.

.

In conclusion, it's safe to say that BI projects and KM projects are complex right from the start, during the requirements collections phase, and also later on- when running the project and expanding it. The phase of requirements collection itself requires extensive knowledge. Therefore, it is recommended that organizations  strongly emphasize choosing analysts/KM consultants that can ask the right questions and realize if the information they received from the business side is sufficient for creating business value and not only pure content. In KM/BI projects, the ultimate value of the project is revealed only after the assimilation of the knowledge (in KM projects) or after the analysis of the data (in BI projects). Therefore, it is sometimes initially difficult to justify the ultimate business value.

  

Nevertheless organizations should not give up. KM and BI are greatly needed. As difficult as they can initially be- they are later on satisfactory and can produce real business value.

 

Written by Rom Knowledgeware
Fax 077-5020772 * Tel 077-5020771/3 * Bar Kochva 23 st., Bnei Brak Postal: 67135