Browse Category by Use Case

WikiFarm: Software for centrally administering several wikis.

CCO Public Domain via Pixabay.
CCO Public Domain via Pixabay.

Administering several individual wikis is technically intricate because all too often, a confusing “wiki chaos” develops, which is difficult to take care of. In this area there is already a concept which has proved itself: the wiki farm.

Several wikis can be created, archived or deleted quickly and easily by using a wiki farm.  When creating wikis, the user has the option to create an empty wiki or to clone what is known as a “master wiki”. Such a master wiki can be already filled with content (e.g. handbooks), or contain files and configuration data, all of which can be transferred and supplied.

From a technical point of view, by using the farm concept, one can provide several wikis with just one wiki installation. The wiki software is only installed and saved once on the server and all the wikis use this installation together.

We have had an increasing number of enquiries from customers over the last few years for whom the best possible solution is provided by a wiki farm.  Many have the problem that a single wiki is no longer sufficient, because they need to reflect the most differing topics, languages and permissions concepts. In such cases, we always recommend the use of several wikis via our wiki farm solution.

Why does one need several wikis?

By providing several wiki instances within one organisation, we can ensure that data and permissions structures are absolutely separated. While access to information can be controlled within a wiki by assigning permissions for separate namespaces, this harbours risks and gaps. The basic software MediaWiki does not recognise the regulation of access by namespaces and presents loopholes which an experienced user might make use of. On top of this, there is the risk of errors creeping in when permissions are assigned, making data available for non-authorised users. This can have fatal consequences, particularly in divisions with sensitive information like personnel, research and development or management.

Creating new individual wikis is also especially useful in project management. In general, projects with wikis can be excellently organised and monitored by including, structuring and keeping up to date the content of the project or data like the points of contact and costs, schedules and milestones or the current status and the to-do list.  The security obtained by separating the data makes it possible to share a project wiki with, for example, external service providers or customers, so you can work together and exchange ideas without risk. When a project is concluded, then the wiki can be archived so that the information and data can be made available again if needed at a later time.

Single wikis are not intended to implement multilingualism. There are differing concepts around for solving this, but using separate wikis for each language is still the most elegant and cleanest option (see Wikipedia). This is an indispensable requirement for companies working across the globe, which can be optimally fulfilled with WikiFarm. BlueSpice even has its own special features here. Linking individual articles in different languages is done with InterwikiLinks. In such cases, BlueSpice automatically adds a menu for navigating between languages (see fig. 1).

Figure 1: Navigating in a multilingual wiki
Figure 1: Navigating in a multilingual wiki

Because multilingualism is just as much a hot topic and just as involved as before, we will devote a blog entry just to this topic so we can give more detail.

How does a wiki farm pay off?

So that the creation and maintenance of a number of wiki instances can be managed quickly and simply, there are farm solutions with which organisations and users can practically “host” as many single wikis as they want.

We have developed the technical basis of the BlueSpice farm solution a great deal further, and tailored and optimised it with a view to the individual use-cases of our customers. Not only MediaWikis, but also BlueSpices can be administered by the solution.

The great advantage of using a wiki farm is that the systems are simpler to maintain, which reduces the costs. Patches, updates and upgrades are only carried out in a single system but are available in all wikis of the farm.

Wikis with a limited “lifespan”, like project wikis, are better organised in a wiki farm: if there are processes and tasks that occur again and again, they can be put in a prefabricated structure in the master wiki and content which repeats can be populated. As soon as one needs to, one can clone this wiki so the project can begin immediately. After finishing the project documentation, the wiki is archived in such a way that it is no longer active. The information contained within it, can still be recalled at a later date.

Farm management is configured to be very clear (see fig. 2). Along with a description, keywords can be assigned to individual wikis. The list of wikis can be sorted, filtered and grouped according to different criteria. This makes all wiki instances simple to keep an eye on, and redundant wikis and unused relics can be avoided.

Figure 2: A clear overview of several wiki instances in the farm administration.
Figure 2: A clear overview of several wiki instances in the farm administration.

Putting together the biggest advantages of a BlueSpice WikiFarm, we have:

  • 1 click installation for new wiki instances
  • Very little effort needed to update and upgrade
  • Provision of standardised content via master wikis
  • Data security because content and rights can be separated
  • The clear presentation, sorting and filtering of wikis

Conclusion

If you would like to create and manage several wiki instances in the twinkling of an eye, WikiFarm is exactly the right solution for you. Even when operating just a second (Media)Wiki, the software’s architecture and administration interface save time and costs.

 

A part of the exchange station for abrasive materials from ASIS GmbH
View Post

Collecting and distributing an organisation’s knowledge: Knowledge management and QM at ASIS GmbH – a use case

A part of the exchange station for abrasive materials from ASIS GmbH
A part of the exchange station for abrasive materials from ASIS GmbH

ASIS GmbH from Landshut works in the area of automation technology. This medium-sized company is focused on surface engineering for the car industry. ASIS develops and produces, amongst other things, painting and grinding finishing systems. They currently have about 120 employees.
I spoke with Jana Timinger, Technical Editor at ASIS GmbH, about how knowledge and quality management have changed as the firm has grown.

Ms Timinger, ASIS has experienced many changes in the last few years. What challenges have these changes brought with them?

We have grown from 70 employees to 120 in just a few years. As well as this, we have two locations, and many members of staff who work a great deal out and about, or at customers’ premises. This means that we always have to consider the question: How we can organise teamwork over these distances properly, for example for projects in which planners from several locations collaborate. Put most generally: How can we keep all members of staff informed of important information on a regular basis, and how can documents be centrally accessible and findable? Our previous data storage structure was not ideal for meeting these challenges.

What made you want to find a system to meet these challenges? And what were your requirements for such a system?

The first thing that set us off was quality management. For this, we had documents in a type of intranet. This was not particularly convenient, and we were not happy with it because things were often filed twice and our members of staff could not access the documents easily. In addition, our technical departments wanted to be able to keep their knowledge centrally so that it was available for everyone in that department, but also for everyone across the company. Word documents disappear too easily and too quickly somewhere on the server – they are not really able to be found again.

Now, our quality management is completely documented in the wiki and we have set up subportals for our individual departments, in which the technical departments can place and stress relevant information and news.

The quality management portal in the wiki
The quality management portal in the wiki

We also had, previously, an organisational handbook in word with company-internal rules, pictures of employees and suchlike. This has been brought completely into the wiki too.

The main requirement we had for the new solution was that it was easily accessible for anyone who needed to read it. Being able to find documents and information again needed to be much better (for example via a full text search) and it was also particularly important to prevent data being saved redundantly. We also wanted that everyone who wanted to contribute could do so without barriers being in their way.

ASIS has used the wiki software BlueSpice since Summer 2014. Which departments are involved and who is responsible for the wiki and its contents?

We have a person responsible for the general care and organisation of the wiki, who is also the point of contact for other members of staff. That is me.

Our IT department deal with the technical part, of course, but the system needs very little effort to maintain after the implementation. The technical departments, like, for example, electrical and mechanical design engineering, however, create content independently, content which they want to document and simply make known more widely within the company.

Of course, any member of staff can also suggest content which he or she would like to have in the system – and naturally, every member of staff can also place material there themselves. We have consciously decided on a very flat rights system so that theoretically every member of staff in every area can contribute to every area except for quality management. Writing is also allowed from one department to another because it is often the case that, for example, a member of the software department has knowledge which is also interesting for design engineering.

And the last area, for the present, is administration, which looks after the contents of the organisational handbook.

Am I right in saying that you have taken quality management under your wings?

That’s right. We are certified under ISO 9001, and I look after the documentation for quality management. We have moved this area to the wiki completely. We use Semantic here and almost completely avoid Word documents as in the wiki we can read metadata like ‘creator’ and ‘inspector’ easily and in an organised way, and evaluate it. This is a significant improvement. One can get an overview with just one click. This is also excellent for auditing. And maintenance will be significantly easier in the future.

Many companies do not make good estimations about the effort and planning involved in the introduction of such a system. Could you describe the phases to me please, from the planning right up to the current situation today?

Well, from the determination of the criteria and requirements up to the first workshop with Mr Heigl from Hallo Welt! and the final decision to use the wiki software BlueSpice was about three months. After this there were about two months in which the solution was realised technically and the first user training sessions took place. Alongside this training for the key users, we also carried out internal training in order to involve lots of members of staff as soon as possible so that they could get to know the system. After this, we transferred existing content into the wiki. This took about 3-4 months as we had to transfer some areas completely into the wiki, for example the whole of the quality management and administration areas. We tried to make the existing documents and procedures unnecessary as quickly as possible so that everything really can be found in the wiki and Word and Excel documents are superfluous.

Currently, we have 1,337 articles in the wiki and we are very happy with this “first version”. However, we still have a lot we want to do – there is still a lot of content which sooner or later should be relocated to the wiki. We have some clean up operations lined up for this, and working out what is best to be put in the wiki. By the way, it’s quite funny but one of the most popular pages in the wiki is the cafeteria plan and the telephone list.

What has changes with the wiki over the year it has been running?

It is very helpful that the material is kept in one place, as for most questions that people have, you can refer them to the wiki. There are, for example, IT tips in the wiki already, so that the standard questions do not have to be constantly answered individually. This saves time and avoids annoying people. A lot of information and things which seem like details, such as pictures of our members of staff, are now much more easily available via this location. The contents of the organisational handbook are also enhanced by the wiki and are looked at more often.

It is also very good that employees who are travelling also find out what has happened when they return, what the news is – a lot of information is now visible when before it often disappeared. Also, previously emails were often sent which, of course, would not reach colleagues who joined later. So the wiki is a point of reference for many questions which new colleagues have.

What lessons have you learned during the introduction and implementation of such a knowledge and quality project?

It was good that we transferred content very quickly and discontinued the other systems at the same time – this allowed us to avoid doubling. It also forced the people to look in the wiki. Unfortunately it is now still the case for some people that while they write in the wiki, they still save a “safety document” on the server – we need to prevent this more effectively.

The acceptance of the wiki is generally good. Almost all read the wiki, but writing is something else. Many still have inhibitions about writing in the wiki, because they are worried that the article might be too long or too short, or they are worried about making things worse or something similar. But when they have learned it once, the staff do use the wiki too. For this reason, I carried out targeted individual training for members of staff in key positions. And we continue to train our people to make them more familiar with the system. In particular, the departmental managers play an important role as they should set an example. And employees should not have to justify themselves when they document important knowledge in the wiki.

The year that has just passed, the first with the wiki, was very intensive. What is lined up in the future? A break?

Oh no, certainly not. Now we have the QM audit lined up, and then, above all, we will focus on the conversion to the new ISO standard. In parallel, we should bundle further content in the wiki so that more areas on the server can be decommissioned. And I will consider further how I can bring more people into the wiki, for example there is the newsletter from the general management in which, amongst other things, new employees are introduced. We could replace this with the blog which comes with the wiki. The wiki should be lively and this means it must continue to be regularly cared for.

We wish you continued success, and thank you for the interview.

The blog replaces many internal emails
View Post

Knowledge management and handbooks in the financial sector: A wiki with blog for the Saalfeld-Rudolstadt district savings bank

“Finally, more time for business thanks to the Web 2.0 – The Saalfeld district savings bank cracks open its knowledge silos and finds a new way to deal with rules” by Christian Sauer (summary of the progress report by Nathalie Köpff).

It is well-known that many things in Germany are over-regulated. Instead of supporting creativity and entrepreneurial thinking and action, too much regulation blocks the big picture and leads to redundancy, or in extreme cases to contradiction. The introduction of the Web 2.0 breaks open knowledge silos, helps colleagues share newly-acquired knowledge, in a central place accessible by all, for example in the intranet. Members of staff should have an information platform available which motivates their active cooperation, adding discernible value.

Online organisation handbook and open documentation

The Saalfeld-Rudolstadt district savings bank wiki meets both requirements. One part of the wiki satisfies the statutory and supervisory editorial requirements. This area fixes the procedural rules for business operations. Amongst other things, there is an open area in which the staff can freely document their knowledge. A blog provides support for the system, giving a non-binding form of transmitting information.

The main page of S-Pedia links to important innovations
The main page of S-Pedia links to important innovations

The backing of the management was indispensable to guarantee a wide enough basis for support and initiative. Furthermore, users were needed who really see the need, and last but not least a suitable provider. To get the project of the ground, one has to concentrate on the users, as they will be working with the system later on. For this reason, members of staff from the most diverse divisions of the company were integrated into the planning process right from the start. Taking the requirements of the users into account early on, avoids acceptance problems later on and developments missing the users’ requirements. In the case of the district savings bank, the first job was to determine the central activities clearly and specify a name for the platform: S-Pedia.

Together with Hallo Welt! GmbH, the following challenges were tackled

1. What content should appear?
The wiki needs to display the organisational handbook, i.e. the areas: Organisational and operational structure; company structure; human resources organisation; but also the organisation of safety, equipment and tools, and governance arrangements. As a result, there is an area which needs to fulfil stringent editorial requirements, but also an open area which is principally used as a sort of glossary at the moment. Questions are answered such as “what is a cost centre?” and “how do I calculate a interest reference rate?”.

2. How can I fulfil the legal constraints of editing?
The editorial constraints are very stringent, and the wiki solution needed to offer this. We have a solution in the form of a workflow and approval mechanism, which is only active for the organisational handbook. The company organisation can then carry out regular appraisals.

3. How can existing regulations in Office format be integrated in the wiki?
Many documents had been saved in Office formats on different disk drives. These were integrated into the wiki and are now in a central place accessible to the search function. Changes are easier to follow and the documents are heeded more than they were. This motivates the authors of the handbooks to update them and improve them.

4. Display the expertise of colleagues transparently.
A savings bank with 350 members of staff needs to be able to access information about the expertise of those colleagues quickly, so we created user profiles in which the areas of responsibility and interests of the members of staff are made clear. The name, operational unit, telephone number etc. were taken directly from the central data management system.

5. Reduce information overload and assist communication.
In discussion with users it became clear that there was an overload of information coming from non-filterable notices, reference mails and suchlike. For this reason, we integrated a blog ino the wiki; messages are now set up centrally. Users can subscribe to those sections which interest them or which are in their scope of competence. However, there are obligatory sections, such as “Information from the board of directors”. The blog developed quickly, becoming a lively communication platform with productive commentary and valuable entries in all areas of the bank in just a few days.

The blog replaces many internal emails
The blog replaces many internal emails

Lessons Learned

  • Open source software has saved us costs. This is because instead of investing money in a vendor lock-in, we have used it as part of the handling costs of useful consultancy and customisation services.
  • An experienced and competent provider is extremely important to set up the wiki so it is user friendly and meets our editorial demands, and to choose the suitable extensions.
  • In particular, the part of the wiki which needs to meet the editorial demand is extremely important. Therefore, a great deal of time needs to be planned for, in order to talk through all the existing in-house processes with the provider, so that they can build them into the wiki compatibly.
  • When importing the existing organisational handbook into the wiki, many documents could be discarded because they were obsolete or redundant.
  • What is difficult is the development of new templates and standards. Reading and navigation practices need to be harmonised with the possibilities offered by the new system. There was, however, a significant advantage to be had in article numbering as much of this numbering could be dropped, improving the readability.

Conclusion

Information can be found again; it is linked internally so that the knowledge necessary for a situation can be developed on ones own. The linking to relevant document paragraphs saves the reader from browsing through long sections of instructions. In general, communication is now different as questions are readable by all, and are asked and answered only once.

Next Steps

Almost every day brings new ideas on how we can build up the system and use it even better. For example, we want to introduce “homepages” for individual areas, which can be used specifically for marketing them. Area specific or even personal pages are to be used to replace the reference files still existing with an automatically updated version too.

The home page of transpedia
View Post

Create technical handbooks in an enterprise wiki – the TenneT TSO example

tennet-logo-180pxManaging documentation and handbooks has become one of the most common uses for wikis in companies. But how does such a platform actually look? Well, let us show you the business wiki “transpedia” from TenneT TSO GmbH.

TenneT TSO GmbH is a German subsidiary of the Dutch electricity supplier TenneT operating an ultra high voltage network (220kV and 380kV) with a total length of about 10,700 kilometres. This gives them coverage of 40 percent (140,000km²) of Germany so they indirectly supply about 20 million people with electricity. TenneT constructs and operates infrastructure for transmitting electrical energy both on land and at sea. In order to construct and maintain these far-reaching networks, they need to put guidelines in place. TenneT has been using a Hallo Welt! wiki since 2009, to maintain their technical regulations and keep them up to date. The system was upgraded to the newest BlueSpice version in 2014.

Essentially, it involves the handbooks Building and Construction (BuE), and Network Management and Working in the Network (NAN). These contain the internal regulations concerning the construction and operation of the technical equipment and, since 2010, have been displayed in “transpedia”.

Why was the decision made to manage the handbooks with a wiki?

Business was partitioned into two divisions: high voltage networks and ultra high voltage networks. This made it necessary to reorganise the online handbooks available on the internet at that time. This means that some thematic blocks were no longer needed, and other information needed to be reworked and made available in a similar way to what had existed before. The wiki was used to update the technical regulations as quickly as possible without engaging external services or initiating complex working processes. The approval of changes and additions was decentralised, being assigned to those responsible for the area. The wiki also offered the chance to improve knowledge management in general with the addition of a glossary.

What subjects does the wiki deal with?

The wiki has two main focuses: firstly it contains the technical regulations, and secondly it serves as a company-wide reference work.

The operating manuals contain instructions on how to handle the technical equipment, software etc.. The handbooks provide important information about servicing, construction, renewing, network management, working in the network, occupational health and safety and environmental protection. These technical regulations are regularly updated by the staff and the approved versions are binding.

The wiki’s glossary serves as a central registry and encyclopaedia. The contents which belong there can be found in the main namespace. The information in these articles is non-binding.

The home page of transpedia
The home page of transpedia

How can they be sure of quality and how is it made clear which content is binding?

The rights structure has been kept flat so that the wiki is equally open to all. There is, however, a difference between authors and editors. The editors have the right to approve handbook articles, after reviewing them. This makes this version of the article binding. This approval process ensures the validity of the data. To allow the article to be continually worked on, every user has, however, the possibility to continue to edit the article as what is known as a “draft”. However, the last approved version is shown in the read-mode. The reader can see the approval status directly in the article. This means that checks can be done “on the fly”, without having to initiate complex processes. To verify the article, it only remains to turn to the relevant committees or supervisor. Along with this, articles in the handbook have a responsible editor, so there is an obvious point of contact. Editors get, for example, their authority for approval in this way.

Everyday work in Transpedia

Internal users are logged on using LDAP / single sign on, which is currently used by many systems to save time searching for passwords. Authors are helped by being able to use page templates when creating articles. These point to individual subareas in the handbook and to the assignment of namespaces and categories.

There is a hierarchical navigation system by chapter in the handbooks. This enables the contents to be structured in the same way as in other systems but also speeds up the finding of specific information. This gives the wiki the handbook feel, promoting the acceptance of the system and supporting well-known search strategies.

The display of necessary mathematical formulae is realised by an interface with the typesetting program LaTeX. There is also a connection to a document management system (DMS). This is because the most up to date versions of the technical drawings are saved in this system. The wiki pulls the most up to date version from the DMS every night, and the corresponding contents in the wiki are kept up to date with this synchronisation. The editor is informed and can approve this version for the wiki. After being approved, this version is then part of the contents of the handbook.

During the last upgrade, MySites from Sharepoint was connected to the wiki, so readers are able to see more about the authors of a wiki article, without the need to duplicate information.

Exporting from handbooks

Many members of staff and external workers need parts of the handbook as a PDF over and over again. The sections can be collected according to need and exported. The sections are chosen, and the choice is exported as a PDF brochure including attachments, notes and approval.

Conclusion and lessons learned

As far as every-day work is concerned, the transpedia users are often tripped up by creating and formatting texts because up until now they have usually used Word for such purposes. A visual editor is, however, browser based, and one needs to be aware of the fact that a WYSIWYG editor is not Word. It is therefore advisable to manage expectations to that effect.

Instead of parallel, cyclic changes there are dynamic changes which are also documented. Due to the responsibility of various technical editors, it is quicker to get approval, saving everyone time. Assigning of editors to articles and the necessity for approval of changes was easy to communicate, however the separate approval of files was often overlooked.

Editing of the articles and establishing the system at TenneT needs system maintenance. This challenge must be further channelled (when, how, who), particularly for articles and files, which is particularly apparent when there is staff change over. The plethora of articles has been growing for four years, this and the greater necessity for keeping the articles and handbooks up to date requires ever increasing maintenance work.

The system construction needed almost one and a half years at the start which meant comprehensive development work for TenneT. The upgrade, which contained further customisation and extension of the system, took another half year.

That is really nice is that we can adapt the system – you don’t have to just take it as it is. In particular, small adaptations are done quickly and reliably by Hallo Welt!. The cooperation is uncomplicated, smooth and hitch free.”
(Michael Nawratil, Asset Management, TenneT TSO GmbH)

Company wiki HAVIpedia – HAVI Logistics on their way to Enterprise 2.0

This progress report is based on an interview with Miriam Schönberg who is responsible for knowledge management at HAVI Logistics, playing the decisive role in HAVIpedia’s development. HAVI Logistics is a company providing third party logistics for the food services industries, supplying various types of companies including restaurant chains, such as McDonald’s, Nordsee and Vapiano. The company currently has 5,510 employees and 55 distribution centres in Europe.

How did the wiki develop from a departmental wiki to a company wiki?

HAVI Logistics started a departmental wiki for the IT department back in 2004. Six years later, they introduced what was then the first Hallo Welt! GmbH wiki. It was called “hallowiki”. It extended MediaWiki, which was already in place, and made the departmental wiki available to more than 200 users in our IT area in different countries.
The current main page of HAVIpedia

The current main page of HAVIpedia
The current main page of HAVIpedia

 

It soon became clear that the information in the wiki was not only interesting and helpful for IT, but also for those departments which work with the IT department. Therefore we opened up HAVIpedia in 2011 for all our colleagues in the business. In theory, since this date, every employee who has access to the firm’s network has been able to get onto the wiki, find information, and contribute too.

There are no read-only rights, as everyone should and may take part. HAVIpedia is also connected to the Active Directory which means that our colleagues log in with their normal accounts and are also registered in the wiki on the move.

How does the wiki fit alongside the other collaboration systems within HAVI logistics?

As part its development into an Enterprise 2.0 company, HAVI logistics uses several web applications for internal communication and team work. The wiki is one of four central platforms which promote the exchange of knowledge within the company. It is, however, becoming more important.

The four pillars are:

  • Firstly, the intranet in which, for example, information on the customers and strategies is disseminated. This is top down – the management keeps the employees up to date.
  • Secondly, SharePoint is used as a collaboration platform for teams and for storing documents.
  • Thirdly, MySites is for personal information for the members of staff.
  • Finally, we have the wiki “HAVIpedia” with the aim of combining and grouping information. Here, you can find abbreviations and definitions, descriptions of best practise and much more. Links take you from one system into another and so on.

Is there a core team responsible for the wiki?

No. The wiki lies in my area of responsibility; it belongs to knowledge management. Naturally, I am helped by colleagues and I can delegate certain tasks to those responsible for certain areas. I try to ask my colleagues to do tasks that are as small and concrete as possible so that I do not burden them unnecessarily. I set planning intervals for implementation which are generally sufficiently long so that I do not put people under pressure. That works well. And I have noticed that personal contact is very important to bring my colleagues on board. The wiki supports communication in essential points, but it cannot replace personal contact.

Which of HAVIpedia’s functions are particularly helpful?

From my experience, and the feedback that we have got, the most important function is the What-you-see-is-what-you-get editor (WYSIWYG). Without this, it would not work at all! BlueSpice really makes a big difference here; it lets colleagues without programming knowledge add and adapt contents without any problems.

However, a well functioning search function is also essential. Particularly when the wiki grows and gets bigger, you have to rely on the search function a great deal. Interestingly, users often have quite varied strategies when searching. One may search and use facets, another might navigate by chapter and yet another relies on categories. All these variants need to be offered to create a well functioning solution.

For this reason, and others, the most important extension, I would say, is the bookmaker. Bookmaker lets you create thematic bundles. This means you can collect together specific coherent parts as chapters, then as books. These can also be exported as PDFs. This saves a lot of time for those who are looking for something as closely related themes are directly and clearly linked. This is excellent for best practise documentation like, for example, the SharePoint documentation, which we use all the time.

What is somewhat unusual, but very useful, is our offline wiki, which plays a particularly important role in second level support. This type of offline backup lets colleagues access their most important records even when they have no internet connection.

What I also, personally, like is that one can see straight away in HAVIpedia when someone is having their birthday, assuming that they have entered their birthday in their profile in MySites. This is a good example of how we sometimes use data from one system to place it in the right place in another of our systems. And it is always nice to use a birthday as an excuse to get back into personal contact with a colleague or wiki author. 😉

What is happening in the wiki at the moment and what are the challenges for the next two years?

In December 2012 we completely renewed the wiki technically. We are now using the most up to date MediaWiki version and on top of this we have installed the newest version of BlueSpice from Hallo Welt! GmbH. I think it is an essential factor in the success of enterprise wikis, that they do not stagnate technically, but rather develop further and that they are not just checked and adapted regarding contents. Most people’s expectations of our system are influenced by what they know from their private use of the web and social media. Usability is decisive and has to be, I have learnt this, regularly surveyed and adapted. The challenge of updating a system which is already running, has all the content needed, but is not up to date technically, is not to be underestimated.

As we have moved the technology a decisive step forward, we are dedicating ourselves this year to the contents. At the moment, we have more than 4500 articles, now we need to see what is missing and what new contents can usefully be included now that we have opened up for all areas of the company. Until now, the articles have been mainly focused on IT, due to the history. So now we have to motivate the staff to help to broaden the range of themes. This also concerns the quality of the information on the existing articles – which is predominantly very high. For this, we need to be ruthless about cleaning up articles which do not meet these quality standards.

Another point is the restructuring process. It needs to be more clearly defined and communicated which content belongs in which system. The demarcation and assignment needs to be clear immediately. Here we have, for example, assigning articles to categories, and departments for editing. We have also learnt that the uniqueness of content is important. This means that information should ideally be given fully in one place, so that you do not have to search in many places for additional information.

You have already mentioned the factors for success. What tips could you give others from your experiences?

Oh, well there are all sorts of things. Many of them are relevant when a business is planning introducing a wiki. For example, which wiki software should I choose? From my experience, I can say that being similar to Wikipedia is extremely important for us. Our staff know Wikipedia from their everyday life. Thus, it is much easier for them to learn the structure and how to work with the wiki when we do not stray to far from what they already know. The inhibitions and worries of getting actively involved can be lowered in this way.

We do not, however, kid ourselves that everyone writes in HAVIpedia; it will always be the case that most colleagues use the information passively, i.e. by reading it. Nevertheless, I think that now we are also broadening the contents, that more staff will feel drawn to add something themselves to topics they know something about. I often here the remark “that must be in HAVIpedia,” which is a sign for me that our colleagues are getting used to using our wiki.

In 2010 we laid great store by putting the look of the wiki in the style of our corporate identity. After finding our that all of our adaptations cause a great deal of effort when migrating, we now stick to the BlueSpice standard whenever possible.

Regular “gardening” is a must. Continual support of the wiki saves long-term irritation. This includes looking through the articles to see if they have categories, and if they are correctly and sufficiently linked, and for instance adding alternative terminology so that the articles can be found more easily. It is often small but very important work. In a well structured ‘ongoing’ wiki, I calculate on about two days a month which I spend supporting the wiki. If, however, there are technical changes or, like now, significant restructuring, then the time and effort needed is naturally significantly higher, and we plan for this as a project.

Thank you very much Ms Schönberg for the interview.

Further down, you can find an extract from the article “Social software – HAVI Logistics on their way to Enterprise 2.0” from Wissensmanagement (Knowledge Management) magazine (1/2013).

If you would like to know more about HAVIpedia, we would be happy to help:
koepff@hallowelt.biz
+49 (0)941 – 66 0800

Another use case:

Wiki as a CMS – technical documentation at XTREMEtechnologies (developer and manufacturer of extreme ultraviolet (EUV) light sources for the semiconductor lithography market)

BlueSpice for MediaWiki as CMS – use case of EXTREME technologies

XTREME Technologies is using BlueSpice for technical documentation. The Wiki has been established to support processes and collaboration between technical editors, service engineers and developers. Knowledge in the case of XTREMEtech is an asset that needs to be revised and spread among workers. Anja Weinert and Martin E. Brüggemann describe the lessons learnt on their journey towards a wiki-based content management system (CMS).

If you want to learn more about this XTREME Technologies use case, please contact Hallo Welt! GmbH.
(Phone +49 941 – 660 800)