Background

While visiting Indonesia, I met with some of the key individuals involved in the Yogyakarta response. Interviews were carried out in the first week of October 2006 over a 2-day period in Jakarta and Bali with Gajah Rachmat, Luki Lusiano, Ken Taylor and Dayu Antari, and the existing literature from URremote was reviewed for context. My discussions with them were focused on understanding more clearly how the deployment had developed, what the perceived added value of Sahana was, and where the weak points had been. In addition I was interested in learning if they as a group felt that it was worth continuing to promote Sahana in Indonesia, and adding my general understanding of the situation in Indonesia to develop the following note.

The Sahana Deployment in Yogyakarta

In early 2006 concerns that the Mount Merapi volcano might erupt led the Australian Computer Society to ask UrRemote to prepare a report on the feasibility of deploying Sahana to assist relief coordination. The report was completed just as the Yogya earthquake occurred; the Indonesian Whitewater Association and Indonesian Rescue Source deployed Sahana with technical support from UrRemote, and assistance by ACS and the Sahana core team. The deployment was handled by a field team lead by Gajah Rachmat, a tour operator from Jakarta, and a technical team lead by Luki Lusiano, a student in Bali in the department run by Dayu Antari.

Gajah was overall lead, based primarily in Yogya. Within seven days of the earthquake, seven motorbike teams with GPSs had collected points identifying affected locations, talking with village chiefs to gather lists of needs. Data collected by the teams was then communicated to the technical team by telephone or emailed spreadsheets. Luki was technical lead, based in Bali with a team of 4 working on Sahana. Their main tasks were Sahana installation, translation, data entry, technical support and general maintenance; technical support in particular required extra work for the spatial data function (described below), and the development of a script that would import spreadsheets directly into SQL to facilitate the process of data entry.

Once the data was updated, Gajah used the website as a visualization tool show potential donors in Jakarta where and what the needs were, either in person or over the telephone. This would then inform the donor choice of where to donate, although I was not able to detail the exact means by which they would donate. Gajah also demonstrated Sahana to a number of government agencies, and spoke with a range of international organisations including CARE, UNDP and UNICEF. Operations ended at the end of August, with no more data collection or transmission, and the volunteers returned to their work or study.

Findings

Technical Issues

There were no significant technical issues in this deployment. Everybody involved was happy with the performance of Sahana itself, and felt that the functions it provided were the essential ones. The technical team confirmed that setting up Sahana was easy for those with experience in installing software, but also pointed out that not everybody can operate Sahana. Luki described the need for a full-time Sahana administrator actually at the disaster location, specifically for quick data entry and liaison with actors on the ground.

• Recommendation: Future Sahana deployments should plan for the presence of technical staff in the disaster zone working alongside field teams.

• Recommendation: The Sahana core team should explore developing “good practice” for Sahana deployments, based on this and other experience.

Language

This was a critical issue, as few people in Indonesia speak English. Language was therefore the main barrier to Sahana deployment and adoption, and translation was critical. This was carried out by Luki, and a PO file was sent to the LSF team on 3 June. However neither Luki nor Gajah considered the translation to be adequate (primarily in terms of user-friendliness) and said that it needs to be completed.

This was a problem for external presentations, as it could create a poor impression of Sahana, but it was complete enough for the deployment. However the translation process took one month, which is far too late for a sudden-onset emergency such as an earthquake. This was because the translation process was difficult; it is hard to compare the web pages to the PO file to get the context necessary for translation, and therefore difficult to edit.

• Recommendation: The Udayana University team should complete and validate Bahasa Indonesian translation and re-submit to Sahana.

• Recommendation: The Sahana core team should establish a validation procedure for .po files before inclusion, including at least one external check.

• Recommendation: The Sahana community should make it a priority to translate Sahana into common languages for countries at risk of disaster.

Modules

In the Yogya deployment, only the Camp Registry and the Organisation Registry were used; the other modules were not used at all. A request for an expanded Landmark Registry was made by Gajah for use in assessing damaged buildings.

• Recommendation: The Sahana core team should include a Damage Registry for use in needs assessment, to cover primarily affected infrastructure, in the next phase of Sahana.

• Recommendation: The Sahana community should review the modules currently under development to prioritise those that have been most used in actual deployments.

Data

There were three issues with data:

Data Transmission

Transferring data from Yogya to Bali was problematic: field teams did not have easy access to the internet, and data transfer was via spreadsheet or verbal reports. One of the critical problems was context; frequently the technical team in Bali did not understand the data that they were working with, which made their work more difficult.

The hack created by the Bali team enabling direct imports from spreadsheets was critical. Internet connectivity is poor in Indonesia, particularly on the more remote islands, but the mobile network is ubiquitous, with quite widespread GPRS coverage, confirming that mobile channels are vital for field data gathering.

• Recommendation: Data import from spreadsheets must be a core function in Sahana, particularly from .xls files.

• Recommendation: Data entry through SMS or GPRS transmission from cell phones should be a priority for the next phase of Sahana.

Spatial Data

During the deployment, Gajah asked for a GIS function (based on Google Earth) to be included. When this was added and the relevant data entered, it showed the wrong locations (although he was able to use it). My analysis of this is that it is likely to be a projection problem caused by a lack of familiarity on both sides with working with spatial data, and not a problem within Sahana itself. It does however suggest that spatial data visualization (not necessarily full GIS functionality) is going to be essential for future deployments.

• Recommendation: The Sahana core team should consider GIS functionality to be absolutely critical and prioritise it accordingly in developing a Reports Module.

• Recommendation: The Sahana documentation teams should include very clear instruction on how to gather, enter and present spatial data in order to avoid common GIS problems.

Data Security and Privacy

Data stopped coming in around the end of August; at the start of September, all the data on the public system disappeared. It is still unknown why this happened; the Sahana server at Udayana had been left open for testing, and possibly somebody erased the data by accident. Proper backup procedures were in place and no data was lost; copies of the data in three locations (Udayana University, URremote in Canberra and Luki Lusiano’s home computer). This incident caused alarm and frustration, particularly for those not working in Bali; however the problem was not with the Sahana system or the backup procedures but with the communication between the two groups.

Initially, Ken Taylor thought that privacy issues (i.e. the collection and release of personal data) would be a big issue, but apparently it was not. When asked why, the interviewees said that it was probably because Indonesians are used to being asked for their government-issue ID cards; however these concerns may be more significant in Aceh and other parts of Indonesia where there is conflict.

• Recommendation: Privacy concerns must remain important for Sahana development, while bearing in mind that local deployments may not require full privacy functionality.

Internal Communication

This was problematic from the beginning. Luki and Gajah had never worked together before, and indeed have still not met each other; their only contact has been via telephone. One team is very technical, while the other is very practical; while this meant that there was a clear division of labour, it also made communication difficult. There was frustration on both sides, primarily due to poor communication on both sides; in particular there does not seem to have been any prior agreement on the expectations that each team had from each other.

• Recommendation: Future Sahana deployments must emphasise internal communication, and agree ground rules for frequency and nature of communication between team leaders.

• Recommendation: The Sahana core team should ensure that messaging capability is built into Sahana, with email and sms to individual Sahana users to enable direct communication.

Socialisation

In the week after an earthquake, it is already too late to deploy Sahana; the immediate need is in the days following the event, and this deployment was slow enough to raise questions about how suitable Sahana is for rapid deployment, particularly if translation is taken into account. As the team in Yogya found, it was difficult to introduce Sahana into processes that were already underway, and everybody involved recognized that preparedness would be an essential part of any future Sahana deployments. Preparedness in this instance was described as the readiness of people to implement Sahana, rather than the technical capacity of the platform.

• Recommendation: The Sahana core team and community should support the Indonesia groups in developing and implementing Sahana for disaster preparedness (see next section).

Impact Gajah was able to describe how he was using it to liaise with potential donors, but the wider application of Sahana for co-ordination does not appear to have happened. It is also unclear who was using the Sahana website, and what they were using it for; there is no record of visits to the site, nor any chance to interview actors in Yogya to assess their awareness of the site. Everybody agreed that it was important in future to establish who is using Sahana, how they are using it and how useful they find it.

The Future of Sahana in Indonesia

Despite uncertainty about how successful the Yogya deployment was, everybody who worked on Sahana believes it is a useful tool and that it will be worthwhile to continue developing and promoting it in Indonesia. Gajah reported that, after his meetings in Yogya, officials from 5 provinces (inc. South Sumatra, South Sulawesi, and Yogya) said that they would use Sahana if it performed well. The question then is how to expand the presence and capacity of Sahana to respond. This is not just in terms of technical development, but in terms of geographical coverage and in terms of institutional presence.

Geographical Coverage

It is clear that adoption by the Indonesian government is key to the success of Sahana for disaster preparedness and response. Indonesia has a decentralized government with a large amount of responsibility at the province level, and will require a combination top-down and bottom-up approaches. On the one hand, the support of government at the national level is a prerequisite for the adoption and support of Sahana using national-level resources, and inclusion of Sahana in the policy and practice of national-level organisations such as the military. On the other hand, actual implementation will need to be built at province level, where financial resources are managed and local organisations are active; demonstrating success at this level is the only way to prove to other provincial governments that Sahana is worth investing in.

This suggests that Sahana should target one or two of the more receptive province administrations and focus on their development for the practical deployment of Sahana; while at the same time maintaining a credible and visible presence in Jakarta for the purposes of advocacy and liaison.

Disaster response is usually handled at province level by Sakorlak, a standing team convened by the governor but drawn from other parts of the government, the Red Cross and, in some cases, NGOs. I was not able to confirm which government ministry has oversight of Sakorlak at the national level, if any. In Bali, Dayu has contacted the Governor’s office (with whom she has a pre-existing relationship) to explain the concept behind Sahana, and to ask for one of his staff to review it with the possibility of adopting Sahana into provincial mechanisms.

The national Red Crescent/Red Cross society is also a critical player in disaster response, supported particularly by Australian aid agencies, although its capacity varies depending on location. Dayu has also contacted the head of the Red Cross office in Bali to begin discussions.

Institutional Presence

If Sahana is promoted as part of disaster preparedness measures in Indonesia, how should it be constituted and where should it be located? It is not reasonable to expect such a project to be undertaken on a purely voluntary basis, both for practical reasons and for the credibility of the initiative, although voluntary contributions must still play the key role. Two possible approaches were discussed during the Indonesia assessment: either Sahana is hosted by a university, or network of universities; or a new organisation is created specifically to host Sahana.

The first option has a number of advantages, particularly as there is a precedent for such hosting with Udayana. In addition universities have the necessary technical expertise, and adventure clubs apparently exist within the universities that often get involved in disaster response. There is a network of universities around the country that could be engaged, although this was not leveraged by Udayana in the Yogya instance. The disadvantages are that most universities have very little financial and physical resources, and sometimes lack the political connections that would make it possible for them to approach government. In addition, students have their own studies to continue which may make volunteer contributions unreliable, and they may expect to be paid for substantial work such as customization.

The second option – creating a new organisation – has the attraction of offering Sahana a “clean slate” in Indonesia. A new organisation could create more visibility and credibility for Sahana, particularly at the government level. It will be easier for a new organisation to attract support (particularly funding) than an existing organisation like a university, and it will more flexible as it will not be bound by existing regulations. The disadvantage is that it is hard to start new organisations with any real momentum (creating an NGO is easy, delivering is harder); there is no precedent for this within Sahana, and there is no seed funding currently available (although it may be possible to find funding in the country or region.)

Both these options have the potential to succeed, but there is the question of how the wider Sahana community relates to a dedicated Sahana organisation in a specific country. “Sahana” has been used in this document with with little clarity about who constitutes Sahana and who is responsible for taking a project such as this forward. At present, such an organisation would have no formal status within the community and could not count on any additional support from the network.

• Recommendation: The Sahana community – and especially LSF – must establish clear definitions of the relations between different parts of the community, particularly roles and responsibilities during a deployment. Sahana should retain an open source model for its technical development, but this approach will not work for deployment and implementation.