Classification & Structure Definition.

A classification tree is an structure where we divide information not from the unit or department where it comes from, but from the nature of the information, like contracts, purchase orders, letters, requests, financial reports, manuals, etc. Classifications are key because they can be used as the “controller” and to store aditional metadata concerning each type, meaning many of the rules legal and otherwise can be consolidated in it’s classification. Another aspect that can help you handle better documents is the flow of uploading them, or the number of steps needed to add a particular document. For Example, a Purchase order might follow a different path than the contract for legal services because it involves different sets of groups.

We call retention to the rules defined for each type of information that you want to store. For example, a contract might have the following rules:
• Remain active for 1 year.
• Remain passive for 3 months
• Archive 10 years.
• Cannot be deleted without approval.
• Modifications should be notified to owner.
Information can be treated as a living thing, having 3 main stages called Active, Passive, and Archive or Deletion stage. With this method, information can remain up to date, be more useful, and the overall organization can improve the performance of the system.

I believe classifications can serve tremendously in organizing information and making more useful a central database used as a repository, in parallel with a folder structure and a logical one. Classifying should give you as well a way to customize metadata (Additional fields) so that you can sort and retrieve more easily information. It gives you flexibility and power to configure your information in many different ways.

Again, the key is in your policies and procedures, making sure that a broad vision is set, and a clear mandate given so that teams can implement a complete repository.

Basic Structures

There are 4 basic structures that handle everything in a repository.

1. Physical

2. Classification

3. Logical

4. Users/Groups/Roles

We have the folder structure where we could follow the way the organization is structured to implement it. Then we have a classification structure which provides us with a way to customize the various types of files we use. A quick example: In legal documents you handle much of the bulk using MS word format. So only classifying by the type of office file would not give us any meaningful benefit as in this case mostly all are of the same type. We need to create types based on the documents themselves, like contracts, letters, approvals, etc; each type can define the retention period and a set of rules the owner requires like for example which medium you want it stored, or how long should it be kept in active mode before sending it to archival, etc. Custom fields can be added to a type so that sorting and searching can be more powerful and flexible at the same time. The folder view should allow you to view not only its contents, but any classification type defined in the objects it contains. This provides you with a mechanism of displaying each node differently depending on its contents. Music and math files should be displayed differently.

The logical structure is targeted more to the “How do I do this” type of question. It does not reflect the groups in the organization but the most important tasks needed to be performed by teams of people. Examples: How do we buy something? What is the process of acquiring insurance? How do we close a deal legally? How do we ask for services? Who is the expert in IT and databases? All of these questions can be put together in a simple structure to help others find their way without getting into the intricacy and complexity businesses create.

The way I’ve been learning how the last structure should work follows a simple rule. Things should be guided by the role more than the name of the person. So this is what it will look like:

Groups

Roles

People

Groups should have a setting where it tells the system not to go in to big loops by looking down more than 2 levels. What that means is that we can create groups of groups, and they can fall into a deadlock, so by creating a group which is clearly marked as a group only, then the system know where to stop looking for permissions (More on this later). Then roles should define the name, any rules applicable, and especially who is your proxy or backup. The major benefit about this method is that we can have the organization chart embedded into the system nicely, so processes can be created more easily based on groups and roles.

Repository Types

Historically and after observing the way people see things, we have on one side the Library type which I call it Passive archiving, where you have books and publications (Physical items typically)stored in a single place (Public and private libraries follow this method), and you have a single database to find the title of the book, author, genre, etc. It’s features are: Information is in archival mode usually for ever, when searching you are always searching the entire collection, information does not have a cycle, needs tuning when classifying records and it does not posses a structure. The limitations are:

1. There is no way to find topics inside the material or full text indexing.
2. Searches can be long and complicated. There is usually a “middle man” that is the expert in searching, called the librarian.
3. There is no permissions structure.
4. Usually records are of the same type.
5. Cannot be customized easily.

On the other side we have Active Filing, which came about with the Internet. The features we find in this side are: There is a structure (Navigational) and it can hold more than one like classifications, user permissions, etc. It is more dynamic, we can create cycles so that information goes from one state to another, Active-Passive-Archival. In this form we have a lot more interaction from people, sharing and collaborating on office documents. There is usually a full text index and you can search for information based on the structure. Classification is usually the key for handling document types and their retention. Ideally, with a retention scheme, the system can move back and forth information from one side to another. I like to view this system with the two types working in harmony, the passive archiving handling the bulk of data and heavy storage, and the active side handling the most used and active documents for quick retrieval. Its limitations are: 1- Not good for very big containers. 2- More complex to build.

Detail.

In passive mode, we use something like a bag of candies; we throw every candy in, and expect to find them in one place. So it is central by nature. These posses a problem for multiple locations, where you need to replicate the data. (The active scheme works well for combining central with distributed approaches). Working with our bag, requires deep knowledge on the tool we use for searching inside the bag. Why? Because the results might not give us exactly what we are looking for. Results can be extremely long and complicated to filter. You might not have the ability to change the resulting records in one shot; this again depends on the tool and the vendor. Some vendors like working with you, some do not even pay attention, so you have to foresee how much support you can get or buy.

In summary, libraries are a good tool only when the records and fields are static, or you do not have multiple types of documents.

There is a need to reform the way libraries are seen today so that they can include a more flexible approach, the active mode I described above. This way, we can integrate both into a “Live system”, and the end goal of having this methodology is to be able to cycle the information. This means that information gets created, is active for a period of time, but then it falls into a passive mode and if obsolete, then it should be deleted, but if it has some value, it should go into archival mode, and depending on the legal requirements for retention, you can store it for a number of years or for ever. Media used in big jukeboxes (used to handle the bulk of data) can survive for many years, some to even 100 years, probably more than what we will be around.

What is a Repository?

The following sections, will address specifically how do you implement the concept of structures in a repository. If you are not part of a similar project, you might want to skip to creativity and innovation.


The first thing you need to do when trying to go from one point to another is to define where the initial point is, or A taking A-B. This means creating an information map to know where everything is, and how much effort and materials will consume the task of migrating.
The green section is about identifying the different systems holding your information. Identify possible conflicts with duplicated documents and/or special needs in processes requiring more than one group that are to be migrated at the same time. It can provide valuable statistical information about the growth trends, habits, and current activity in all your systems.
In this diagram we follow the elements in our framework Data-Processes and eventually Collaboration. It is always recommended to have a cleaning and consolidation phase before designing your repository; it can give you a fresh start instead of trying to do it later down the road.

After many implementations is safe to say you will need a strong mandate for this sections to be carried on by your employees. So do not be afraid of asking for this mandate to your CEO or president because this is where leading the way makes a very important fact for the project to succeed.
What I am recommending in this diagram is to have a repository first and then your business processes. Why? Because many business processes may require you to have the repository at hand prior to implementation plus it makes it easier for you to do it while you are doing the repository design first.

In my experience I have found out that some groups (I wont name anyone) have the expectation that a consultant will come with a magic formula to convert the mess they have into something clean and pristine. I had the sense that for some reason they think "one solution fits all" will work in their company. Another type of thinking is asking consultants who else has the same solution or implementation. In reality, these projects are each very different to implement because each company or institution is different, how? in the way they conduct business, the way they store information, in their culture. What you need is to assess each organization and come up with a plan based on the assessment and not from some past experience that seemed to work which is important but it cannot be assumed will work for everyone.

What is a repository?

What is exactly a repository? From the dictionary we read “a facility where things can be deposited for storage or safekeeping”. In technology, a repository is a central place where you can store a variety of objects. One requirement is that the policies and procedures you envision for your company in the digital age need to be clearly defined. Now to the question –Do we make it centralized or distributed? To make thinks simple to manage, you want to centralize, but if you have multiple locations (As a multinacional company does), then you need to combine it with some sort of distribution, so that each location can access rapidly your data. So my take is that the solution must meet both schemes but not at the same levels. The other issue with central repositories is that not every one is online all the time (e.g. Airport-airplane, train) or at least not today, maybe in the short future yes as we see these areas been converted into online hubs.

As it was said in the first section, policies and procedures are a must for you to develop correctly a repository so make sure you have them (they do not have to be complete and extensive) before going any further. I strongly recommend automating those policies.

The structures in a repository can be divided into 3 groups.

Physical Classification, Views, Permissions.

Permissions can be further subdivided in Users, Groups and Roles.
The way we find what we are looking for relies heavily on how good your search technology is combined with how flexible is the tool to handle the results in different ways. I call it the FIND engine. Combining search results with spreadsheet functions gives you a lot of power. Imagine having results from Google or other search engine in a spreadsheet format, where you can sort, expand, filter, etc. Those familiar with Excel and working with this layout, would understand the kind of power I am referring to. The problem with search, is that not all “High quality” pages are always in the first batch of results. And depending what you are looking for, this method might help you greatly I finding what you are looking for.

Repositories - Map

The following sections, will address specifically how do you implement the concept of structures in a repository. If you are not part of a similar project, you might want to skip to creativity and innovation.


The first thing you need to do when trying to go from one point to another is to define where the initial point is, or A taking A-B. This means creating an information map to know where everything is, and how much effort and materials will consume the task of migrating.
The green section is about identifying the different systems holding your information. Identify possible conflicts with duplicated documents and/or special needs in processes requiring more than one group that are to be migrated at the same time. It can provide valuable statistical information about the growth trends, habits, and current activity in all your systems.
In this diagram we follow the elements in our framework Data-Processes and eventually Collaboration. It is always recommended to have a cleaning and consolidation phase before designing your repository; it can give you a fresh start instead of trying to do it later down the road.

After many implementations is safe to say you will need a strong mandate for this sections to be carried on by your employees. So do not be afraid of asking for this mandate to your CEO or president because this is where leading the way makes a very important fact for the project to succeed.
What I am recommending in this diagram is to have a repository first and then your business processes. Why? Because many business processes may require you to have the repository at hand prior to implementation plus it makes it easier for you to do it while you are doing the repository design first.

In my experience I have found out that some groups (I wont name anyone) have the expectation that a consultant will come with a magic formula to convert the mess they have into something clean and pristine. I had the sense that for some reason they think "one solution fits all" will work in their company. Another type of thinking is asking consultants who else has the same solution or implementation. In reality, these projects are each very different to implement because each company or institution is different, how? in the way they conduct business, the way they store information, in their culture. What you need is to assess each organization and come up with a plan based on the assessment and not from some past experience that seemed to work which is important but it cannot be assumed will work for everyone.

The way forward

Main strategies needed to create and implement a solution. Here they are:

1. Capturing Knowledge: Information + Experience. This is you Key Goal and main topic of discussion in the book.

2. Giving users multiple access points to information. Having just one way of dealing with documents and other objects is not recognizing that we all people work in different ways, so not everyone will feel comfortable searching and working in only one way.

3. Giving users a powerful “integrated” search engine. I like to call it the Find engine, something flexible and powerful enough that allows you to "play"with results, and find valuable information.

4. Creating policies and guidelines to host a Document Repository.

5. Fitting to the Organization. Not the other way. This means all to often people look at the tools not aware that the tools are the ones that need to conform to our way of working , not the opposite. Yes, we may have to enhance our processes, but not all at the same time, it could be very distracting and time consuming.

6. A KM system should match the way people work and help them achieve their goals.

7. The system should match the organization's structure. By modifying the way you are structured, that on itself is a major change. You should be very careful on how to approach changes, because remember that you work and are part of a system, and changes in the structure are critical. The suggestion is to try and work with what you have, and once you implemented the technology, make small changes.

8. Business processes must be matched as workflows.

9. Fostering continuous practical training. People need to be reminded once in a while about certain features of a given technical environment. Training people to "learn" how to work with and use a system does not mean the system "will" be used. Reality shows that people will forget mostly everything by the 6th day their training passed. It is important to coach them and hold their hand in the beginning so that change does not scare them enough to prevent a successful transition.

• Creating an information map:

• Knowing how many, how big, which types of files your organization currently holds is crucial for you to measure implementation efforts on a Repository. Knowing were point A (Where you are) will better guide you on the detail required at this particular project. When you create a map, there are policies required that get created along, like how many files do we want to keep per type, or how should we delete obsolete files, etc. Your process for transitioning point A to point B is as important as defining the target.

• Create Rules and guidelines for grant related information and other e-documents for users to follow.

• It is essential to provide users guidance for the sake of system efficiency. Without the BUY IN from users, you will not be successful in the long run. Period. Your users are the most important part of the entire process. You need to involve as many of the most visible as you can. Without them your efforts and cost will increase mightily.
• Most companies fail to capture their knowledge because there is no Vision and Strategy about rational knowledge, or people assume that there is one but in reality there is a paper document policy not fully translated into the digital world, or no automated policy system that helps you monitor compliance. Thinking that in today's massive libraries you can manually verify policies is not smart.

• Files/process organization.

• Streamline document creation and storage. Increase accessibility through search tools.

This theory about how things should develop in a project comes as a conclusion from projects that did not have a clear methodology for repositories. As most of the material, these are lessons learned from many projects that did not have or did know which steps to take.

Migrating your Information

We've reviewed some topics about how to solve the problem – Collaboration, knowledge, etc--. But we haven’t talked about what it takes to move from HERE (your current situation) to THERE. It is another 800 pound gorilla problem. With the number of terabytes increasing exponentially each year, it will be no easy feat to move a giant monster (data) from it’s current place to our solution. Do not worry, it should read our platform sustaining YOUR solution. No solution can solve everybody's problem, cause we are all different, including organizations.

Let's suppose you understood everything I said, and now you ask -- what's next? If you thought the tough part is over, think again. This section is about issues you will face when you look at your current situation to be migrated into the envisioned solution of tomorrow.

What are the issues?

• Silos: Information is created based on the company structure. If it is a Silo, information will be in silos too. What is a Silo? It means that your company is compartmentalized, that your departments do not talk to each other, that everyone wants to keep their information from others.
  
• Maps: The consequence of silos is that you cannot create an information map. This means links between files are non existent. We want to be able to "picture" the way information is connected to one another. Without a map, we can't.
  
• Importance: Another consequence of silos is that there is no hierarchy that tells you the importance of documents. Many times you need to make a call to find out how important it is.
  
• Permissions nightmare: In many corporations, there is no overall strategy for easy handling of permissions not to mention digital information. In many cases the non-official strategy is"Individual" permissions which means doom for any migration effort which translates into a very hard and time consuming effort to deal with access. A good way to deal with permissions is a mix between groups and roles as they are more related to other functions through out the system. The issue then becomes the synchronization of those groups and roles in your system B or target solution. Remember this when you plan for a migration.
  
• Massive amounts of information: We have today a lot MORE information than yesterday ( Big companies are already in the terabyte-petabyte range ). So the problem is not getting any smaller. Been able to massively copy, move, tag, log is key to any effort of consolidating information into a flexible platform. This section(Migration) has to be able to deal with errors, inconsistencies and unknowns in a way so that it groups them for later review. As when you look at your personal information, this is always a good time to check for information you want to delete. So filtering and sorting is crucial to let the owner find and select documents for deletion. That deletion can be temporal meaning it does not really delete until certain later date.

Because the web was created on the basis of linking documents one to another it is easier to find information because is linked. In a corporate environment we do not have that. It comes from Silos as already mentioned. We need to mimic the web in our internal structure to build the web of internal information in a corporate environment. How? Making the linkage of documents the center of all effort.

The above points have come as lessons after going through several projects dealing with repositories. In the last 10 years the projects involving knowledge tryed to implement common methods and what I have found is Knowledge Projects are very sensible to people, and the approach you take must be different from any other type of projects. They must involve the people it will affect. You need to consider The Human Factor, in order to be successful. I would say that in most cases there is a lack of understanding of where you are and where you want to go, and because it is so complex and it involves all aspects of the business, it is very challenging.

The Key

The key and value to every system is in its interrelations between it's elements. Shouldn't we create something along those lines?

I believe that the key to knowledge building is in three parts.
1. Creating the right technology based on the right concepts,
2. Finding the right sponsor.
3. Having organizations follow new learning and leadership theories, understand and implement "Systems Thinking" to ensure you can motivate people to contribute (with their knowledge) not because they have to, but because they want to.

Technology always come last to the PST system, Problem -> Solution - > Tools or Technology as opposed to popular thinking now a days where the first thing people talk when faced with a problem is .... technology as THE solution.

We need to start thinking radically different, in order to be successful at innovating and collecting people's wisdom.