It’s fashionable to have a corporate wiki installed at the own company. But often – to speak a word of truth – this wikis are not more than a burial ground of vague project memos. This isn’t a big surprise, because often corporate strategy on innovate wikis into company’s every day life, comes in a simple triple jump: (1) buy some software, (2) get a one-day workshop, (3) write a binding memo to employees to use that wiki. Leaving the process in such a kind, wikis are developing the way that is inherent for them: run riot (optimistic case) or run dry (normal case).
But wikis are extensive and powerful instruments in corporate life. You can plan, communicate, document and control everyday corporate processes with them – within a common environment. So wikis are less a chunk of software, they are more the potential future working environment, where employees are “living in”. So, as careful as we are furnish our offices, we should also setup our virtual working place: The corporate wiki.
Andreas Heilwagen points out some tips on innovate corporate wikis right at “Computerwoche”
clear rules and responsibilities
do not start with empty wikis
so called “champions” have to smooth the way
change your mind on information processing
be careful with vendor-specific plugins
do not outsource to professional information brokers
everybody should be able to edit (nearby) every page
get your pages connected intern and extern
always create useful information which others can reuse
Following my statement at the beginning, I would add:
get a clear definition about the fields you want to use the wiki for
identify company’s surplus in having a wiki
see which tools and services bring some very personnel benefit for the employees
It’s the preparation phase which is essential in the quaetion on how effective the work with a future corporate wiki can be. Vienna based Semantic Web Company exemplary runs through such a preparation phase this days. Getting data, using tools like storytelling, personas and usage scenarios, this may end in a “well equipped working environment of the future” – the corporate wiki.
Virtuoso+DBpedia+OntoWiki together with several industry relevant uses cases – that´s about the formula of the OntoWiki project, which was launched yesterday in Leipzig.
Sören Auer and his team from AKSW at Uni Leipzig are the coordinators of this EU funded project which supports the development of innovative software products. All industry partners are SMEs which offer services for different fields like E-learning, E-tourism or Business Intelligence. Leipzig and OpenLink Software will work on an integration of OntoWiki & Virtuoso.
The first day of the meeting was, of course, dedicated to socialize and get to know each other. The mixture of the project team turned out to be well chosen – and in the evening we flew at higher game: We had a nice overview over Leipzig standing on the highest building of the town.
On the second day of the meeting Orri Erling, Program Manager at OpenLink Software, came up with an idea which is pretty forward: Why shouldn´t we provide OntoWiki as a Linked Data Browser, e.g. on top of DBpedia etc.? One possible outcome of this project.
Some other use cases which make already use of the existing OntoWiki system were demonstrated: Take a look at Vakantieland (…and start to plan your holidays in the Netherlands) and also at LinkedGeoData where a nice user interface can be tried out.
The Kick-Off Meeting will proceed with two workshops dedicated to semantic technologies and to Application Development with the OntoWiki Framework. Thanks to Sören and his team for the excellent hosting of this event!
KiWi – Knowledge in a Wiki session, pt. 2: This afternoon, we turned to the Logica use case, which is dedicated to the development and optimization of KiWi as a knowledge management tool specifically tailored to the needs of project management.
Regarding the use case requirements: As Daniel Grolin, a process expert and business architect at Logica (formerly WM Data), pointed out, what is most required at the moment is an application for designing processes, i.e. for designing the ways that people do things. This can be a painful process, in particular if one group of people (consisting of process designers) thinks about the ways that another group of people (e.g. the project managers) are going to do certain things – a collaborative approach should be able to
1) alleviate this challenge
2) generate commitment among the involved parties.
The primary users will be on the one hand the process engineers, and on the other hand the project managers who are the recipients and users of these processes.
In his presentation, Daniel Grolin chose one of four scenarios in which KiWi would ideally be employed: the risk analysis process – which is a vital process for Logica, as the outcomes of this analysis influence the decision whether or not a project will be accepted. From an architectural point of view, KiWi is going to mediate between the process guidance column – which consists of process and workflow features – and the final work product, i.e the result of a process, in this case the report of the risk analysis.
In practice this means that if, for instance, a user has selected the risk analysis process, the Kiwi core system and enabling technologies will provide concepts related to risk analysis, supporting the user in the tagging process. Wiki technology is already being used in the industry, said Daniel, but what is lacking at the moment is the integration of structure, and this is also where he sees the potential of KiWi as a knowledge management tool, and as a means to move easily from unstructured to structured information (by the way, if you are interested in using wikis in the enterprise, I also recommend this article: Wikis for Knowledge Engineering, and in Global Businesses).
Karsten Jahn (Aalborg University) then gave us a preview of a possible user interface (i.e. not of the screen design, but the functionalities) which seeks to address one particular problem: Many companies use many different, sophisticated tools which operate fine on their own, but are not integrated (i.e. there is no communication or exchange of data between them). With KiWi, the aim is to develop a tool that is going to be able to cover all features and processes currently being taken care of by individual tools, to allow for an optimum of data integration.
To conclude, Rolf Sint (Salzburg Research) showed us screens of the current configuration of KiWi for Logica’s needs – the example below is related to the risk analysis process outlined by Daniel Grolin above.
Semantic MediaWiki is being featured in issue 12/2008 of the German popular computer magazine iX in an article about wiki engines. It’s the only semantic wiki among those presented, and although it is an extension of MediaWiki (which underlies Wikipedia) – which is also in the article – it is discussed separately and thus receives quite some emphasis in the article. iX has featured Semantic MediaWiki before, more precisely in an article dedicated to it in 11/2007. It’s well-deserved, I think, considering the many sites which use Semantic MediaWiki.
It’s good to see that the visibility of Semantic Web is also growing outside academia and involved industry.
Sorry for still writing about last week, but the TRIPLE-I conference had far too many interesting topics to offer for me to be already through with them – promise, this blog post about wikis will be the last TRIPLE-I post.
An interesting use of wikis was introduced with the Moki plugin for Semantic Media Wiki, developed as a side product of the APOSDLE project. APOSDLE (EU-project leaders love their acronyms;-) aims to develop an Advanced Process-Oriented Self-Directed Learning Environment, which in plain language is a platform to support the process of learning at work. In the course of this project, a model of the enterprise knowledge had to be developed that was to be the collaborative result of domain experts within the enterprise and external knowledge engineers. The APOSDLE image video below conveys a sense of the complexity of the knowledge to be represented.
But on to Moki: As wikis are an ideal, readily available tool for collaboration, the simple solution was to build a plugin (Moki) for Semantic Media Wiki that allow to structure and engineer the domain knowledge. Moki is a hierarchy builder that supports drag and drop so that categories and relations can easily be fitted in place – the special benefit of using Semantic Media Wiki was that the structure of the generated knowledge can be exported in Semantic Web compliant formats. Apart from the browser, no further software is required.
The APOSDLE website doesn’t yet offer any information about Moki, but a description can be found in the conference proceedings: Collaborative Knowledge Engineering via Semantic MediaWiki, by Chiara Ghidini, Marco Rospocher (who gave the presentation), Luciano Serafini, Viktoria Pammer, Barbara Kump, Andreas Faatz, Andreas Zinnen, Joanna Guss, Stefanie Lindstaedt.
For those looking for good arguments for setting up a wiki in a global business environment: Peter Kemper’s keynote was the perfect primer for that. Peter, a Knowledge Management portfolio manager at Shell’s IT-Department, gave some insights into the process of their conversion to wikis. Before there were wikis at Shell, they had global discussion forums, connecting 20,000 people around topics and questions, which were intensively used – the question whether wikis should be adopted or not alone generated 800 responses in these forums.
Instead of going for team wikis, Shell opted for the encyclopedic approach and a wiki that would be accessible to anyone at Shell, and for using MediaWiki – which was, interestingly, the first open source software ever used at Shell. Peter Kemper named scalability and the lean architecture as prime arguments for MediaWiki, and they have indeed not had any technical hiccups so far. It was also an asset that people, being used to Wikipedia, know how to use the MediaWiki interface.
Examples of uses case with which the feasibility of wikis within Shell were tested were: Drilling salt, Geology of the Atlantic Margin, and Production Chemistry. Before that, the main media for maintaining and passing on knowledge had been emails and Powerpoint – not exactly because these were considered appropriate for knowledge management, but because of the effects these media had had on the communication within Shell:
With the advent of email, People wrote less and less memos. Less and less reports were sent to the archive, because people kept powerpoint presentations. If that same information, previously locked in emails and powerpoint, went now into wiki, it would finally be accessible to everyone in the company.
Peter Kemper allowed us a glimpse of the information their wiki held, for instance, about the Atlantic Margin – as geological structures are described, most of the information relies on images. It would be a nightmare to maintain this kind of information in Powerpoint! No offense meant: Powerpoint is good for presentations but not for creating and maintaining a knowledge base. According to Peter, with wikis Shell achieved six times the productivity in comparison to using Powerpoint, in particular due to the linkability of content.
Wikis also turned out to be the superior solution for the integration of curricula from an internal learning environment, as wikis support the modular structure of a learning curriculum. Furthermore, they are also a good means to sustain communication in the time between workshops or team meetings.
At shell, they even use wiki for instance for the translation of contracts into the requirements of day to day procedures – a typical contract in the business that Shell is in has around 400 pages, and it is probably not very likely that a single person is going to read (and immediately understand) the entire contract. In this regard, the wiki also serves as a tool to translate lawyer-readable prose into transparent instructions (and there are probably many more ways in which wikis can be used to support business processes, a statement also put forward by Rolf Sint from Salzburg Research; see his 12 seconds statement below).
A noteworthy detail about the integration of wikis in Shell’s IT architecture: If a user logs onto the wiki for the first time and goes beyond the disclaimer, a new wiki account is automatically created that is identical with his or her windows account – this is not about checking on people, Peter Kemper said, but about creating organisational transparency.
On the one hand, this reveals whether there are organisational units within Shell where the wiki is not as intensively used as elsewhere, meaning that these units probably have specific needs which need to be addressed first. On the other hand, people can (and do) also contact each other via the wiki, e.g. one can contact the person who created an article if one is on need of further information.
About stimulating content production: 60% of Shell’s employees will go into retirement over the next eight years, and with them knowledge that is needed in the company. They even asked and paid former employees to come out of retirement to work on the wiki – that’s what I call commitment to content creation and knowledge preservation.
The Shell wiki already has more than 40,000 registered users (with 150,000 employees in the company, plus contract staff). What is interesting regarding user activation is that the number of active users stays relatively the same, even if the number of users in total increases. Peter Kemper’s account for this was that content comes in waves, meaning that users are activated in those areas where fresh knowledge is generated.
Kemper distinguished three types of users: content owners who create content from scratch; content editors who often just correct syntax or make things ‘look nicer’; and information consumers. Kemper rejected the term ‘lurkers’ for information consumers as looking for information is an activity in itself.
Sweet Tools is a comprehensive collection of tools and applications for the Semantic Web. It is maintained by Mike Bergman with help from the Semantic Web Company. [more]
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=74edc5c4-14aa-49f3-9689-4a5b99fec3c0)
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=60f45bfd-fee9-417f-aef4-ad150b92ea5c)
For those looking for good arguments for setting up a wiki in a global business environment: ![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=7b16d276-2e6b-4abd-bd58-97939cba58d2)
