Potential Post-v3.6 Features

Hello All,

As we are rapidly approaching the 3.6 release and, with it, the end of the Gap Project, we are looking to the community to help us prioritize the focus areas and features for future versions of OpenLMIS. We started this discussion during the last Product Committee where a few different feature lists and potential features were provided:

Please note that the above list is just a starting point and if you have a feature or other focus areas we would love to hear from you.

To get our discussion regarding the priority features, here is a potential prioritized list of post-3.6 features:

  1. OLMIS-5476 (?) - DHIS2 Transportation
  2. OLMIS-5765 - Add Stock Management to the OpenLMIS Reporting solution
  3. OLMIS-1621 - Offline functionality for stock management stories
  4. OLMIS-5641 - Indicate tracer product for reporting
  5. OLMIS-2013 - Allow user to reverse incorrect historical stock line item
  6. AO-6 - Create a system alert that notifies when a product is about to expire
  7. AO-73 - Commodities Cost
  8. OLMIS-5726 - Cost Summary on Orders and in Stock Management transactions
  9. OLMIS-5124 - Configuration Assistant Page
  10. OLMIS-5305 - Add additional filters on approve R&R screen
  11. Barcode support (Still not well defined)
  12. AO-69 - Aggregated Requisitions
  13. OLMIS-3858 - Filter REST api pattern
  14. AO-31 - 3rd Party Supplier Management
  15. OLMIS-5120 - Administration Screens Wizards for FTAP and Requisition Groups

We are requesting input into the features in this list as well as the prioritization of the features in the coming weeks and will eventually turn this post, and the subsequent feedback, into a wiki page that details our short-medium term plans. This is your opportunity to let us know the features that you want so please do give us some feedback; we want to build the features that the community wants!

Hi @ibewes - i would like to see items 2, 3 and 4 incorporated into the next version!

I think we’d like to focus (yet) again on demo data. Our efforts to obtain an implementation’s anonymized data (mostly daily stock data at this point) have been failing short of visible movement for months despite our best efforts.

So far we have demo data spread across two countries, with a bunch of generated data that is badly in need of cleaning up and hopefully improving. I’d think the priorities would be:

  1. Re-evaluate if the two demo countries (Malawi and Mozambique) are the right ones. I’d think we’d want some of these places to match other public demos (e.g. DHIS2 for Sierra Leone), and two already can be confusing when trying to remember which login is needed to demo/explore a specific feature. We do want a sufficiently large set of facilities - 4k is the current proposal.
  2. Get rid of the auto-generated facility names and auto-generated product lists - this is a cleanup item that came from our old Performance Data - it looks horrible. We could use some help on sourcing facility and product data, though really this should be easy enough.
  3. Find / Create an algorithm that can generate realistic-ish workflow data: Stock Management first, Requisition second, fulfillment third. I think we’d like to be able to tune that algorithm to generate results of the kind we’d like to see in visualization (superset). e.g. I could image tuning it to so the facility frequently runs out of stock Or tuning it so that the facility is often way overstocked. Or where it keeps close to the ideal amount. We’d then take these characteristic runs (stocked out, overstocked, etc) and fill that run in, at random, for each facility in our demo-data. This would still be a hack of course - I’d expect we’d get visualizations with some more interesting charts, but I wouldn’t expect anyone to try to demo conclusions drawn based on one facilities/districts stock status compared to any other.

Looking forward to everyone’s thoughts on priorities, approach and how we should invest our time here.

Thanks very much for the feedback, @joshzamor and @nidris!

@joshzamor - I agree that improving our demo data is a very important piece of technical debt that we need to pay back. This is such a large task that we will likely be working on this for a number of sprints but it is definitely something that we need to include in our plans.

@nidris - That is really helpful! Are there any other functional areas or specific features that Malawi would be interested in?

In our last Product Committee meeting we did have a good initial discussion about these features and so I wanted to include the notes from that here:

  • @Ashraf_Islam - based on recent RFPs, a lot around stock management and robust offline capabilities. Vote to have these in future version of OpenLMIS.
  • @sam.im - Ability to export reference data - do we want to prioritize this higher? OLMIS-5440
  • @joshzamor - Are there needs for deployment support (i.e. monitoring tools for their instance; multi server etc)?
  • New instances of reporting stack?
  • @craigappl Feature around asynchronous uploading. Future state where power may be limited and there will be a need to fire off a request for a report, run it into a queue and when this is processed, having report available and archived for users. Josh - this has come up before.
  • @Gaurav (or @Gaurav_Bhattacharya) How does this list overlap with the Living Product Roadmap? Agrees with Ashraf to look at country requirements and have a broad list of where we want product to go. IE one RFP requested some functionality at warehouse level/interoperability with ERPs.
  • @Ashraf_Islam Good idea to understand needs for inventory mgt, warehouse mgt etc.
  • @Gaurav Explore mobile application part of OpenLMIS/connect with other open source apps
  • @joshzamor Recently published mobile strategy publication. See here - https://docs.google.com/document/d/1aaZ3TkX3QPiLYCbhiuWDFgZ_lMmr_Cj-ZiqDFXmIlCI/edit?usp=sharing
  • @Gaurav Would like to have a broader discussion on this to evolve the mobile strategy
  • @craigappl Potential pivot following Resonance work. Need to be sure to align with product roadmap.