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.
(c) airservices
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
(c) canstockphoto.com
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
inn346qut 
Nice informative post Alex,
I agree that a staggered implementation approach is the way to go, starting new projects off on the right foot will make adoption a bit easier. One key suggestion that goes hand in hand with your suggestion of having information sent via email be updated into wiki by Air services employees, is for the company to Select a ‘Champion’ for each page to encourage the use and integration of the wiki.
And let’s hope that perfect world isn’t too far around the corner 😀
Hey Keith,
thanks for the comment 🙂
I tried to address the point of ‘champion’ by doing an early coordination with the external partners because in this case the wiki is primarily for them to work in. So the champion would actually be the person, responsible for the coordination with the respective service provider. His job would be to drive adoption on their side. And yeah I totally agree that is one of the most important factors to make it a success.
Hi Alex.
Good post. I am glad to see that you explored the perspective of airport as a aviation service. In the end people go to airport to travel or pick-up/drop-off someone else, and in my view, any E2.0 strategy for airports should involve aviation services (e.g. flight traffic, departures/arrivals, weather, etc).
I’ve seen a lot of strategies exploring a perspective where the airport consolidates a lot of brands under the airport such as restaurant/caffees, book stores, airlines companies, car rental, etc. However, in my view, those are secondary services.
If an airport really need a strong E2.0 presence, using blogging, micro blogging and social media to improve their reputation among customers, they should think seriously about sharing aviation information.
Is that make sense?
Charles
(http://charlestontelles.wordpress.com/)
Hey Charleston,
thanks! But I have to say this is pure coincidence… I’m INN and Airservices is our case study because one of my team members works there 😉 To your question: I think that the importance of aviation information really depends on the context. I mean for airlines and other business stakeholders they are certainly important. However, normal travellers don’t really care about them, so the channel would have to be appropriate.
Cheers, Alex
I really like the approach you’ve proposed, the benefits you’ve outlined make a compelling case.. I wonder if you could workshop the most important searches for the external providers. It would be great to identify keywords or key information that they use regularly or that they would like to have access to but don’t currently. I suspect they will have a different view to the airservice employees, and this might help build support for adoption. It would be an interesting exercise to identify some tags upfront to encourage employees to tag their entries in a way that turns the data into valuable information. As always a great post!
Hey Amanda,
thank you for the feedback!
You have a good point there. The information required by others to work efficiently is often very different from your own expectations… Detailed analysis of the external service providers requirements should definitely be part of the implementation process! I tried to cover this point by referring to the importance of communication from the beginning of the project on. Your example demonstrates this perfectly. However, I didn’t consider the implication for user adoption… totally agree with you though, good insight!
Cheers, Alex
Pingback: Bringing it all together: Enterprise 2.0 – Airservices Case Study Part III « inn346qut
Hi Alex, great post on the use of Wiki. As much as we love Microsoft Outlook in fulfilling our daily activities, it is not a collaborative tool. Information are often duplicated (cc’d), not up-to-date or restricted to a specific audience in the recipient list. Wiki on the other hand provide a far greater benefit for team collaboration. It can act as a single source of truth and available to users with access to the page. It requires a cultural change to move from the traditional emailing method to the collaborative world of wiki. I think Airservices will definitely benefit from using wiki if they give it a try.
Great, post you’ve almost completely 100% support Wikis within this business, I agree with you as well that most companies should look into using wikis if they already are not. Good blog
Carefully thought out post and well structured too:) !, and good points brought up as well. There are problems associated with not being able to trust %100 of what is posted on Wiki’s – being user contribution, and on top of that if you want to implement a Wiki in to your company it would be hard to start up user collaboration and contributors. There may also be some problems with adopting internal Wiki’s because what one person may find relevant and useful another may not and deleting wars may come in to effect ( although that’s why monitors and Wiki restrictions are there for).
But all in all I think its a must with companies like Airlines or Airports because there are so many things going on and your dealing with a big industry which means you need to take on the new like implementing Enterprise 2.0 and social media, and a Wiki would be a perfect way to start for employees to get the hang of things :).
Hey Mihi,
thanks for the feedback 🙂
I actually thought about the point “not being able to trust the content” but came to the decision to more or less dismiss it. I mean where is the difference between the wiki and an email content-wise if you are basically the only one with write access? If you are the one contributing you can obviously manipulate the content anyway you want… And all changes are recorded anyway so I don’t really see this is a problem in this context.
The case of adoption is always a tricky one, though. I hope I addressed it adequately in this post. But my basic idea and strategy would always be a simple one: Make it easy to use, provide obvious benefit, demonstrate it to people and most important of all make a case for change. Why should change happen now? What is the purpose? That should appeal to the rationalist in us and makes it hard(er) to refuse the change.
What do you think? Btw. only had a quick look at your blog, but it looked pretty good! A shame I didn’t see it before… gonna check it out soon 🙂
Cheers, Alex
Oh true! Good point about the “where is the difference between the wiki and an email content-wise if you are basically the only one with write access?” it’s just like internal emailing or a corporate Yammer but more legit and official in a way.
I completely didn’t know about Wiki recording all edits and modifications until I tried to track someone down for deleting my contribution on a class Wiki once (Oh so very handy btw) haha.but again great post, choc full of information and all points were raised.
🙂 thanks heaps! if you check it out(Oh and apologies for my poor grammar in my posts, it’s a working process >< haha)
Pingback: Wicked Wikis! « AURELIE @QUT
Hey alex !
I like the post, The one thing that struck me was your point about employees being reluctant to change, and it is one of the bog issues ofr any company. streamlining a process will almost always involve change, to which employees will object, but as you said, wikis are a simple and userfriendly way of implementing a reliable platform for rapid exchange of information. However, having been rather reluctant to join into the wiki craze myself, I do understand people who would just rather rely on their trusted email system…