Mozambique has used OpenLMIS for many years and is interested in upgrading to v3 of it. Mozambique’s existing edition of OpenLMIS allows not just for CCE management, but for basic accounting of other equipment types as well. To keep their adoption of OpenLMIS v3 from involving a regression in this area, we’ll need to add functionality either to the Core product or Mozambique’s version of it. The necessary functionally is generic enough for potential use in other countries and has been surfaced in at least one other gap analysis I’ve seen.
This pdf represents our current plan for broadening OpenLMIS’ ability to track equipment:
Note that pink areas (mostly buttons) within the pdf are clickable. Please review it and let me know if there’s anything you think the described changes need in order to be worthwhile for contribution to the Core project. Developers on the Core team think they can cleanly add the functionality to the Core product if desired.
Thanks very much for putting this together and sharing it here. This request has come up a couple times now (the other place being Tanzania, though I am not sure of their specific requirements) and it is helpful to be able to have something concrete to discuss. While I understand the desire to include this functionality in OpenLMIS, I have some concerns about whether OpenLMIS is the right place to be the system of record for this information.
Basically, it seems like any simple equipment management solution that we could build into OLMIS would end up being a poor equipment management system that would lack most of the features that those types of systems support. We would end up spending time to build something which is not generally useful, requires yet more maintenance to support, and will likely require additional features down the road. Instead, I think that we should purpose integrating with dedicate equipment management system that already does all the kind of equipment management stuff that our clients are likely to need now and in the future.
@joshzamor - I’d love to hear your thoughts on this.
If people want to add this feature, what about helping them do so as a separate optional module? It might not be part of the RefDistro, and the community might not agree to maintain it over time, but we could help get it started and see
if it gains traction. Is there a down-side to that approach?
The potential ramification of the lack of visibility and support is main downside I can think of. What you’re describing sounds a lot like a country-specific addition. Without being included in the RefDistro, I imagine such features are more likely to remain unknown. Without guaranteed support, they’ll surely seem less appealing. A module may be less likely to see use and gain traction under these circumstances than otherwise.
@Ben_Leibert1 could you explain what this means? From what I know Mozambique isn’t using any equipment management from OpenLMIS. As far as I know Mozambique has SELV (OpenLMIS v1) which had some basic cold chain equipment management for use by a handful of Field Coordinators that visited health facilities. Mozambique also has SIGLUS (OpenLMIS v2) which could have had a lab equipment module and a cold chain equipment module, however they built v2 for themselves in such a way that it didn’t include it in the mobile app nor the web-interface. Since it was built out of SIGLUS, I can’t see how it’s a regression in features.
Equipment management isn’t an LMIS domain. The most overlap between the workflows I’ve seen documented or heard talked about fall into two categories:
It’s data that could be collected as part of the reporting & re-supply process.
Support data that for lack of a better word would inform an LMIS on the “worthiness” of that Location to receive and store supplies.
There is no end to the data people would like to collect during #1, and #2 suggests the data could be informative to a re-supply workflow, but not critical to it. Neither of which makes for a strong argument for building a solution from scratch.
At worst the feature scope continues from there and starts including service contracts, service requests, service logging, parts inventory, vendor analysis, and continues straight into capital asset accounting. The cave becomes a labyrinth, and is I think a prime reason why the governance of the Gap analysis opted to assign it a low priority in v3.
The equipment management module concept, especially with maintenance requests and logs, is well outside one of what an LMIS does well, especially as we address sustainability of what we already have, and we’d do better to explore solutions we could integrate with or at least recommend.
Possible solutions (illustrative):
ODK or Google Sheets for disbursed data collection of what equipment is installed.
ODK-X or RapidPro if maintaining a distributed inventory of installed assets and general functioning is needed through mobile devices.
I just recently had an illuminating side-conversation with those that have explored the asset management space (which has some overlap to CMMS) in detail, so I’ll reach out and see if there’s anything they’d like to expand upon.
Offhand, I think the form has been used within Mozambique for several years by now, but that it was added to SELV after you shifted focus away from the project. It would have thus been easy to miss.
In Mozambique’s case, the history of equipment management paired with the modest nature of the requests they’re making as part of the v3 upgrade lead me to think that the likelihood of significant scope creep is minimal. Your point that it’s possible and could perhaps be likely and extensive within a more global context, though, certainly makes sense.
What strikes me most about it is that the functionality the screenshot shows is actually what an ODK or ODK-like application would be good at: it knows no existing context and simply gathers data. Looking back at your mock-ups though, it’s pretty clear the scope has crept: by adding equipment master-data, inventory, maintenance logs and requests. These are definitive features of a CMMS.
Let me flip this around to you: Why would OpenLMIS want to build a CMMS?
I’d also like to note that in the CCE module the persona’s and user-stories appear to be very different than these equipment mockups. For example CCE loads all equipment master-data through an Administrator whereas this asks many different people to tell OpenLMIS what that equipment master data is. That’s significant.
If a country implementation wants to do this form collection inside OpenLMIS (rather than ODK or an asset management tool), then my question is what’s the harm in allowing that. We should allow hooks or extension points so that a country
implementation can do this, even if Josh, as the Architect, recommends that don’t necessarily want this functionality in the core community version for the reasons mentioned. So can’t we help the country implementation use ExtraData mechanism, or use the Extension
approaches to add these relatively few fields to their implementation?
@brandon: We do do that. If Mozambique wants to build a new micro-service, or request/contribute a new extension point, or include extra data somewhere, then we’d fast track the parts of that that we can - as we’ve always promised.
That is I believe why we’re having this discussion - for the purpose of inclusion into OpenLMIS - and the extra maintenance that would come with it.
@Ben_Leibert1, one concept I’ve floated in the past is that of an incubating service - similar to that from Apache, an incubating service wouldn’t be supported by the community (no maintenance, no guarantees), though it would be on a trial path to adoption. If Mozambique created an incubating Equipment service, that’d be great but we’d need to clearly communicate expectations, which I’d imagine would roughly be:
the team that contributed it would be required to maintain it (through upgrades, etc),
if the contributing team abandoned it, it’d be delisted,
it doesn’t come with the standard Reference Distribution,
and again - no guarantees to implementations.
Incubating would be a stepping-stone designation to see if the community wants it (features, quality, etc) and if the community can maintain it. Is this something that you’d be interested in?
I’m open to everything – including the Incubating designation and use of dedicated software like OpenMaint. For the Incubating approach to be impactful, though, I think the PC would need to take care to publicize the modules within it.
You had asked why would OpenLMIS want to build a CMMS, and I certainly don’t suggest that we should. There’s overlap, though, between the domains of OpenLMIS / SELV and something like OpenMaint. That’s presumably why the latter has a “Logistics Management” module why we, meanwhile, offer support for CCE and motorbikes. It’s subjective, but I think updating OpenLMIS v3 to meet Mozambique’s needs could well be worthwhile because:
From a usability perspective, it’s a natural refinement of functionality we already offer. The proposed “Service Notes and History” modal nicely complements our existing CCE functionality. Meanwhile, every other change simply genericizes what we already have – thereby
making it more useful.
It seems cheaper than the likely alternatives. OpenLMIS v3 is already pretty resource heavy. Suggesting that a country with Mozambique’s modest needs run something like OpenMaint alongside OpenLMIS, as well as incur the cost and complexity of integrating the two, seems a bit much.
It’s more elegant that the likely alternatives. Using OpenLMIS to manage equipment like cold chain and some other software to track other equipment would yield a disjointed user experience. We could pursue integration, of course, but that gets us back to the cost/complexity drawback.
Rather than a proposal to build a CMMS, I’d see this as a low-cost request for improving what we already offer. If need be, I’d rather pursue it within the context of an Incubating module than one slated from the beginning exclusively for Mozambique.