In many Malagasy NGOs and SMEs, the information system is not born from a strategic choice. It builds up little by little, almost without anyone noticing: one Excel file for activities, another for beneficiaries, a spreadsheet for the budget, a handful of KoboToolbox forms, Word reports, attachments exchanged over WhatsApp or email, a shared folder somewhere in the cloud. And very often, one person who is the only one who truly knows where "the right file" actually is.
For a while, this works. Then the organisation grows: projects multiply, teams change, donors ask for more reporting, data accumulates, and several people start working on the same information at once. That is when the same questions keep coming back, almost always in the same order: what is the latest version? which figure should we use? why is this total different from the one in the previous report? who edited this file? where is the original data? can we still trust it?
At this point, the problem rarely comes from a lack of tools. Most of the time, it is an information system problem.
An information system is not a collection of tools
The information system (IS) is often reduced to its technical dimension: computers, software, databases, servers, dashboards. That view is too narrow.
An information system is, above all, a coherent set of people, processes, data, technologies and governance rules, organised to produce, share and use information. In practice, it answers a series of very concrete questions: who needs this information? what information is actually needed? how is it collected, where is it stored, how is its quality controlled, who can edit or view it, how is it analysed, how does it circulate within the organisation?
And above all: what decision should it enable?
That last question changes everything. An organisation can hold a great deal of data, several databases and very handsome dashboards, without actually having an information system that works. The value of an IS is not measured by the number of tools in use, but by its ability to turn reliable information into useful action.
Five signs an information system has reached its limits
Before buying software or launching a new database, it is worth first looking at the situation as it actually stands. Five symptoms come up almost every time.
Files keep multiplying. One file per person, per project, per period or per donor: several versions end up coexisting. The real problem is not Excel itself, but the absence of rules on how information should be organised.
The same data gets entered more than once. The same beneficiary can appear in several files, the same activity in several tools, the same information requested separately by several teams. Every new entry is a new opportunity for error.
Indicators no longer mean the same thing from one team to another. One project counts 1,200 beneficiaries, another 1,350, management holds a third figure, and everyone still uses the word "beneficiary." The problem becomes semantic: what does this indicator actually cover? Without a shared definition, two perfectly well-calculated figures can remain impossible to compare.
Reporting takes longer than analysis. Hunting for files, consolidating spreadsheets, fixing duplicates, checking formulas, chasing colleagues for missing data, rebuilding the same charts every month: what is left, afterwards, is very little time to understand what the data is actually saying.
Only one person understands the system. Only they know where the files are, how the database works, which formula to use, which figure to pass on, how to produce the report. As long as they are there, everything seems to work. The day they leave, part of the organisation's memory leaves with them: a clear sign that the system rests on a person, not on an institutionalised architecture.
Before the tool, understand the system
One of the most costly mistakes is to start by choosing a technology: "we need Power BI," "we must build an app," "let's move to a MySQL database," "let's adopt KoboToolbox." These may well be good leads, but they answer a question that has not been asked yet: what organisational problem are we actually trying to solve?
A sound approach starts from needs and processes, not from software. A simple way to go about it is to map the information cycle within the organisation: from an identified need to collection, from collection to validation, from storage to processing, from analysis to decision, from decision to action, then from action to the learning that feeds the next cycle. Data only becomes genuinely useful once it can flow correctly along this chain, and every one of its stages needs to be under control, not just the first one.
The model of a genuinely operational IS
An NGO or SME with limited resources does not need to replicate the IT architecture of a multinational. It needs a system proportionate to its means, built around six dimensions.
People: who enters data, who checks it, who analyses it, who decides, who administers the system?
Processes: how does information enter the organisation, how is it validated, corrected, communicated?
Data: what data is actually needed, how is it defined, in what formats, with what identifiers to link information together?
Technology: which tools genuinely meet the need: Excel, KoboToolbox, DHIS2, CommCare, PostgreSQL, MySQL, Power BI, Tableau, Looker Studio, a custom-built application? This choice comes here, last, not first.
Governance: who is responsible for each piece of data, who can access it, what rules apply, how are changes documented, how are staff departures handled?
Decision-making: what do we want to do with this information? This is often the forgotten dimension. An IS that collects, stores and analyses data perfectly but influences no decision remains, at bottom, a simple information-production system. A good IS should contribute to steering the organisation.
Building a simple architecture, in four levels
Level 1: Collect
Collection should be fitted to the context rather than to the latest trend. Excel or Google Sheets for certain internal tracking, KoboToolbox for surveys and field collection, DHIS2 for certain institutional health systems, CommCare for more structured workflows, paper where field constraints still demand it: there is no such thing as a bad tool in itself, only tools poorly matched to a given need. In some rural areas, a solution that works offline will be more relevant than a sophisticated platform requiring a permanent network. Operational context should always guide the technology choice, never the other way around.
Level 2: Structure and store
Collected data needs a reliable place to live. For a small structure, a properly designed Excel file can suffice for a while. As needs grow more complex, a relational database like PostgreSQL or MySQL brings better data integrity, more rigorous handling of relationships and types, genuine multi-user capacity, and the possibility of integration with other tools.
Moving to a database does not automatically improve things, however: a badly designed database simply turns a visible mess into a more sophisticated one. Before creating a single table, the entities, events, relationships, business rules and actual user needs need to be understood.
Level 3: Analyse and visualise
An organisation does not need twenty dashboards. It needs the information that genuinely allows it to steer its work. For some needs, Excel is still more than enough; for others, Power BI, Tableau or Looker Studio make it possible to track trends, compare zones, spot gaps, detect anomalies and feed performance reviews.
But a dashboard is not a decision. A chart can show that an indicator is falling; it does not say why. It is often necessary to go back to the teams, the beneficiaries, field observations, qualitative data, the context. Technology makes information visible; it does not replace professional judgement.
Level 4: Govern
Governance is what turns a set of tools into a genuine institutional system. It answers very concrete questions: who is responsible for each piece of data, who can view it, who can edit it, who validates it, where is the reference version, how are changes documented, how long is data kept, how are backups made, what happens when someone leaves the organisation? Current approaches to data governance stress the need to weigh data value, the rights of the people concerned, trust, security and risk together, not any one of these dimensions in isolation.
The fundamental rule: one single source of truth per piece of information
Imagine an organisation with a beneficiary file at project level, another at MEAL level, a third at management level, and a fourth sent to the donor. Which one is authoritative? If no one can answer immediately, the organisation has a problem.
Reference sources need to be defined. That does not mean the whole organisation should have only one database: a structure can very well run several specialised systems, one for collection data, one for financial data, a geographic reference, a system of institutional indicators, a warehouse for consolidated analysis. What matters is knowing, at all times, which source is authoritative for which piece of information. The real issue, then, is not so much having "a single database" as having a coherent architecture and clearly established responsibilities.
Data quality is decided well before the dashboard
A common mistake is to treat data quality as a final step: data gets collected, and problems only surface at reporting time: inconsistent dates, duplicates, missing values, mismatched codes, commune names spelled three different ways, indicators interpreted differently from one team to the next.
Quality should instead be built in from the design stage. A few simple rules are often enough to produce considerable gains: an indicator dictionary, shared naming conventions, unique identifiers, standardised formats, entry controls, validation rules, correction procedures, a minimum of documentation, periodic checks. The goal is not to lock teams into heavy procedures, but to reduce the errors that could have been avoided.
Data security is not optional
An organisation that holds data on people carries a responsibility. In the development sector, some information is particularly sensitive: identity, contact details, social situation, health data, information concerning children or vulnerable people.
Security is therefore not just about protecting a file with a password. A few simple questions need, at minimum, to be asked: who can see this data (confidentiality), who can modify it (integrity), how can work continue in the event of a failure (availability), can significant changes be traced (traceability), does an independent copy exist (backup), has recovery actually been tested (restoration), what happens when someone joins or leaves the organisation (access management), and are we really only collecting the data we ask for (minimisation)? Data protection is designed into the system from the start, not bolted on afterwards.
In Madagascar, context matters as much as technology
An architecture that suits a large international organisation is not necessarily suited to a small Malagasy NGO. Real connectivity, geographic remoteness, teams' digital skills, equipment availability, recurring costs, staff turnover, languages and working habits, donor requirements, institutional systems already in place, and the organisation's own capacity to maintain the system once the project ends all need to be taken into account, an issue that is especially sensitive in remote and rural areas.
A highly sophisticated system that cannot be maintained locally can, in practice, perform worse than a simpler solution that is well understood and genuinely used day to day. Maturity does not mean aiming for the most sophisticated option, but choosing the level of complexity the organisation can actually absorb and sustain over time.
From data to decision: the real purpose
This is where the difference between a documentation system and a genuine steering system is decided.
Take a common example. A dashboard shows that coverage for an activity has dropped from 72% to 54%. That is a piece of information. But management still needs to ask several questions before acting: does this drop come from a supply problem, a staffing gap, a zone that has become hard to reach, a collection error, a change in the target population, or simply a change in how the indicator is defined? Then: what should be done? And, a little later: did the chosen action actually produce a change?
What emerges is a genuine loop: data, analysis, decision, action, observation, learning, then a new decision. It is this loop, and this loop alone, that gives an information system its strategic value. In the humanitarian sector, information management is designed precisely to support this kind of analysis and decision-making, and the principles championed by OCHA place particular emphasis on the accessibility, interoperability and accountability of information.
The most useful dashboard is not necessarily the prettiest
It is easy to build an impressive dashboard: lots of charts, maps, colours, filters, a few animations. But one question remains: who actually uses it, and what decision does it enable?
A dashboard meant for management does not need fifty indicators. Five to ten strategic indicators, well defined, reliable and regularly discussed in meetings, are generally far more useful than fifty poorly tracked ones. The true performance indicator of a dashboard is not how it looks. It is how it is used.
Start small, but think long term
A small NGO does not need to immediately build a data warehouse, a complex cloud architecture and several applications. It can move forward in stages.
Months 1 and 2: Understand. Map existing data, identify the systems already in place, spot duplicates, list users and the decisions that genuinely matter most.
Months 3 and 4: Structure. Define rules, clean up critical files, harmonise indicators, organise backups, clarify responsibilities.
Months 5 to 8: Integrate. Introduce a database where justified, progressively connect certain tools to one another, reduce double entry, put the first automated flows in place.
Months 9 to 12: Institutionalise. Document the system, formalise governance, strengthen security, train teams, assess how the system is actually being used and adjust the architecture accordingly.
This progression is not a universal recipe: a small structure can move faster, a multi-site organisation will often need considerably more time. What matters is starting with the most important problems, and letting the system evolve gradually rather than trying to redo everything at once.
Three questions to test your information system
If three key people left the organisation tomorrow, would the system keep working? If the answer is no, it is probably too dependent on a handful of individuals.
Can management quickly obtain reliable information, without asking several people to rebuild the figures by hand? If the answer is no, there is likely an architecture or governance problem.
Does the data produced genuinely lead to decisions and concrete improvements? If the answer is no, what may be missing is not a piece of software, but simply a steering loop.
Towards a sustainable information system
A sustainable IS is not necessarily the most modern one. It is one that users understand, that the organisation can maintain on its own, that adapts as needs change, that stays secure and documented, that gets passed on when someone leaves the organisation, that connects to other systems when needed, and that, above all, genuinely serves to improve decisions.
This is why digital transformation should never be reduced to buying a piece of software. It involves people, skills, processes, data, responsibilities and a working culture. Technology is only the means.
Our role, at Helpazone
This is precisely the intersection between data, systems, skills and decisions where our work at Helpazone sits. Our goal is not to install one more tool: it is to help organisations understand their own way of working, structure their information, strengthen their teams' skills, and build systems they can genuinely own and evolve themselves.
Depending on the need, this support can cover information systems, to understand the existing architecture, model data, design databases, organise flows, document and strengthen governance, MEAL, to structure indicators, monitoring, evaluation, learning and accountability, data analytics, to turn raw data into reliable, usable information, business intelligence, to build dashboards that genuinely inform decisions, or consultancy, to diagnose what exists and support the transformation step by step.
The goal always stays the same: not simply producing more data, but helping organisations better understand their reality, and act on it better.
A good information system does not always show
The best information system is not necessarily the one that impresses the most. It is sometimes almost invisible: teams know where to find information, data is reliable enough, responsibilities are clear, errors get caught quickly, information circulates, decisions get documented, and knowledge stays within the organisation even as people change. When the context shifts, the system can shift with it.
That is what maturity in an information system looks like: moving from the file to the structure, from the structure to the information, from the information to the decision, and from the decision to the action. An organisation does not need more technology simply because the technology exists. It needs a system that helps it understand better, decide better and act better. And that, perhaps, in the age of data, is where an organisation's transformation truly begins.