This weeks blog post is a continuation of the Airservices case study introduced in my last blog post and once again part of an team effort to analyse and improve the enterprise 2.0 capabilities of our case organisation. This post focuses on the opportunities and risks created by wikis in the context of collaboration with external parties in a B2B setting. If you are interested in other use cases of wikis, you should definitely, check my other team members posts out: wikis & rosters, wikis & shift changes, wikis & knowledge management, wikis & adoption strategies.
Airservices is a government-owned provider of reliable support services for the aviation industry, such as aeronautical data, telecommunications, navigation services and aviation rescue and fire fighting services. These services clearly demand the highest degree of stability, reliability and accuracy, so how could wikis (you should read the article if you are unsure what wikis are – ironically a link to wikipedia) be a good fit for anything in this organisation? Aren’t they a collection of information created only by its users? Users who maybe don’t know everything? Users who can make mistakes?
Yes, to all of the above but they are also a lot more versatile and useful than you might think. They…
- are really simple and easy to use: “Ward Cunningham, the developer of the first wiki software, WikiWikiWeb, originally described it as ‘the simplest online database that could possibly work.'” (wikipedia)
- don’t require much resources (free software, low hardware requirements)
- are perfect for collaboration, as everyone is working on the same data, eliminating out of date files
- have a simple versioning system integrated
- allow easy access to all of the information (only a browser and internet connection required)
- are open source and can be modified to suit corporate needs
So how can these capabilities be used to enhance collaboration with external parties? One of the most important tasks of the technical devision within Airservices is to keep the services running reliably. However, not all services that are required for Airservices to function properly are running in-house as some services are contracted from external parties. Sometimes these services have to be shut down for maintenance purposes and it is important for employees to know exactly when these planned outages are happening so that appropriate actions can be taken. At the moment this is completely done within Microsoft Outlook:
- External service providers send an email with information regarding the planned outage
- These emails are sorted into a special folder
- The date and information gets entered into the Microsoft Outlook calendar for the technical divisions team email account
This procedure sounds easy enough and not too complicated but is this really the best way to do this task? Do we really need to do this via email? What if someone other than the technical team would need the information? What if the external partners could see when other services have planned outages and had the ability adjust their own downtime in a way that it’s not interfering with them? What if additional information (e.g. feedback) could be gathered in one place and improve the outage procedure in the future? What if a secure wiki would be used to collaborate with the external service providers?
However, besides these highly desirable opportunities created by the use of a wiki in this context there are also certain hurdles associated with its implementation, the biggest of all being: How do we facilitate user adoption?
To make people participate in any type of new or changed process demonstrating the need for change and the improvements that the changes provide is paramount. So, just creating a wiki and telling employees to work with it is not going to cut it. We have to provide employees with a thought out solutions that is obviously better. In an ideal world this would be pretty easy. Give all of the external partners write access to a a general and a special service provider section of the wiki, where they can provide all relevant information and interact with Airservices employees and read access to the rest of the wiki, so that they know what the other service providers are up to. A plugin for the wiki would then automatically generate the calendar for all Airservices employees to use as they please. This…
- would reduce the number of emails sent by 100%.
- would be really cheap in implementation and maintenance.
- free up Airservices employees to more important work by outsourcing most of the work to the external service providers and limiting Airservices involvement to management by exception.
- would make it for external service providers easier to coordinate their outages as they can use the information in the wiki without having to wait for replies by overworked Airservices employees.
- would gather all relevant information regarding outages of external service providers in one place, making it easy for new employees to get to know the procedures and the pitfalls associated with them.
- would not minimise the inherent risk of faulty information created by users through the restriction of write access to certain parts of the wiki
Sadly, we don’t live in a perfect world and employees and the external service providers especially will be reluctant to change existing processes even though I just demonstrated how beneficial such a system could be. That’s why communication with all involved stakeholders should be facilitated from the very beginning of the implementation project. If the project is developed and introduced in coordination with the external stakeholders adoption should come more naturally.
However, I would still recommend a transition phase after implementation in which all of the information relating to outages and outage notices sent via email should be added to the wiki by Airservices employees (manually or automated). This would create a good foundation of useful information and further demonstrate the usefulness of the approach to external service providers. After this transition phase external providers would keep the ball rolling themselves and the involvement of Airservices employees could be reduced to a minimum.
That’s it for todays post and I hope you enjoyed it. I know it’s a creative, maybe even unorthodox strategy for the use of a wiki but I still believe there is some merit to it. If you have a different opinion or even better ideas as to how to use a wiki in this context send me a comment 🙂
Cheers Alex aka inn346qut