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.
- Recommendation: Future Sahana deployments should include metrics
to indicate whether the goals of the deployment are being achieved.
- Recommendation: The Sahana core team should integrate website
usage statistics into the Sahana platform to facilitate monitoring
impact.
- Recommendation: The Sahana community should develop a list of
universal metrics that deploying organisations can adopt and adapt.
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.
- Recommendation: The Sahana community – and especially LSF –
should support the Indonesia group to establish Sahana within Indonesia.
A demonstratable success in Indonesia will ensure that Sahana is taken
seriously by other countries in the region, and will also enable Sahana
to shift from disaster response to disaster preparedness, with much
greater potential impact on the humanitarian needs of people around the
world.
Download doc file format
Download doc file format on attachment bellow.