Product Working Group - 10.27.2011

Owned by Ed Cable
Last updated: Oct 28, 2011Version comment
6 min read

Mifos Product Working Group Kickoff Meeting 

Goals of Working Group

  • Identify core functional requirements and gaps across each region
  • Build a unified product roadmap to meet these requirements
  • Unite contributors in one common direction to fulfill this roadmap.
  • Identify technical strategy to advance platform and fill feature gaps as efficiently as possible
  • Establish ongoing meeting schedule and break off into teams based on focus area.

On the Call

Keith W (Ireland), Binny (India), Krishnan (India, Craig (US), Ed (US)
Jakub (Poland), Krystian (Poland), Ryan (US), Udai (India), Ed (Manila), Van (US)

Action Items:

  • 0%

    Task List

Notes

pulled from: http://willyou.typewith.me/p/mifos-product-10-27-2011

Agenda

  • Introductions
  • Goals
  • Discussion of Core Focus Areas
  • Next Steps

Core Focus Areas to Cover

See also: Priority Gaps

Reporting

  • RW: integration of core reporting system in Mifos - SECDEP in Philippines didn't like a brand new system, not the same rights
  • Mailing List - many people are confused about which reports (BIRT v. Pentaho) to use. 
  • KW: what is usage of BIRT?
  • RW: Most larger MFIs moved to their own reporting systems apart from BIRT
  • KW: try to get existing MFIs to switch over to Pentaho. 
  • RW: make sure understand what get in BIRT, continue to get in Pentaho. 
  • Don't fall into bulding one-offs, make it universal
  • KM: Does moving to Pentaho solve the functional problem we're aiming to address? Is it the ease of reporting or the flexibility to do ad-hoc reporting?
  • RW - limitations of BIRT - not flexible, no dynamic reporting, no flexible data outputs, more of a BI platform.
  • VM: Jasper - would require licenses being purchased rather than community version, Pentaho ETL data integration is nicely integrated with reporting.
  • Goal was to build up a data warehouse/reporting database to make it easier to write reports rather than production schema.
  • VM: replace built in BIRT engine with Pentaho engine to have built-in reporting engine - allow people to have the all-in-one solution. If needed to run it separately - nothing to prevent them even if there was integrated reporting engine.
  • Even with Pentaho can still have an integrated BIRT viewer. 
  • RW: good to have both options because larger MFIs might want to integrated other systems with their reporting system. For operational reports for their staff, 
  • About ad-hoc, every MFI will have their own reporting needs (even more important moving forward with OS) - give flexibility/control over own reports without need for third party or external maintenance. 
  • How many MFIs using our collection sheet? - RW: I believe most are using their own design
  • VM: dynamically off of one of the cube definitions in Pentaho can speed up ease of generating reports. 
  • KW: JohnW will send an email out to users that is available to talk to and assist in any way that need help.
  • Simple as advice around reporting, how to get most out of data, how to get BI installed, which reports are relevant - CAN and ARE waiting to help. 
  • VM: what MFIs really seeking this all in one experience.
  • RW: KMBI not happy with different user rights.
  • RW: Must remember end staff using product are not technically proficient.  
  • Action:
  • Kick off a sub-group on reporting - John, Van, Binny, and anyone else. 
  • Binny: pain areas from my experience:
                       Single sign-on with authorization being inherited from Mifos
                       Not adequate enough - for example, getting list of members who have arrears, etc.
                       Design issues - Not professional enough (too many lines, not flexible enough, same report multiple times)
                       BIRT reports have errors and similar reports not available in Pentaho
                      Dashboard not flexible
                      Financial Reporting not possible - very very important (need accounting module to do this)
                      Installation is difficult

Accounting

  • RW: Stuff to explore: integration story - molly, working with Gigi on data formats, small branch-accounting trial balance type thing, any OS accounting application we can work more closely with to meet MF requirements.
  • Trifecta pattern - MIS for operations, accounting system, and then a reporting system that looked over the whole financial system for organization - saw this again and again at MFIs - much more attractive as a product - core needs everywhere.  
  • BG: All prospects ask about financial reports and when it's not there, they are quite unhappy.
  • BG: Cash Management at the branch level is important - May be an opportunity for small accounting functionality built into mifos
  • KW:Cash management can be done at MIS level and not necessarily have as much accounting interaction. 
  • Need to interact with cash deposited and cash withdrawn. 
  • BG: Support for either branch as a legal entity or head office as legal entity - accounting issue because need to consolidate data at whatever level needed (branch or HO)
  • Krishnan: happy to join a sub-group on accounting
  • Krishnan also willing to talk with others about accounting integration and cash mgmt and lay out plan to meet those needs soon enough. 
  •  

RW: ACTION - We should identify people to lead the sub-groups


Offline Collection Sheet: 
      - RW: still a need for offline data manipulation
      - Udai: looked at simple MFI for sync between mobile and MIS
      - Udai: offline collection sheet will function differently than on mifos?
      - Need to keep data structure at the client side - how much can you avoid having to redo data structure on the client side. 
      Offline collection sheet will be much different than online one with Mifos - capturing data and then some cases with validation. 
      Best bet is to use HTML5 - most browsers are allowing, mobiles are capable of HTML5 storage. 
      Problem is not about user interface.
      Problem is about specking out business rules and what client that data wants - Mifos data model is much more complex than what Simple MFI supports. hierarchical JSON model to capture but with validation it becomes more complicated. 
      - RW: Should spec out what are the needs for offline collection/account management
      - EC: we should also review again what Conflux built: https://groups.google.com/d/topic/mifosdeveloper/oNYjpGFp_LQ/discussion
      - RW: Need to think of appropriate technology - smartphones good for future, but many field staff using feature phones. should address branch offline solution first.
          - RW: I should add on a comment, I'm thinking of Africa and Asia - The situation with smartphones might be different in Eastern Europe and Latin America - this may be worth looking into
          - KM: Request for use of offline module is more from locations to operate when they don't have reliable power and connectivity, rather than for use on a mobile basis from the field.
          - KM: willing to offer the offline app that we at Mostfit have developed for use with Mifos if the API can be made compatible
          - KM (to Udai and others): will share experience on how much of the domain model needs to be replicated in the offline app for sane and effective usage
        -RW: Might be worth talking to FrontlineSMS for integration options. EC: Michael V is working on that and is connected with FrontlineSMS devs too.
      
      Credit Bureaus
      - RW: Good area to research. lots of talk but not much action happening yet. would be good for us to be ahead of curve for integration.
      - KM: Heard that GK's installation is now capable of talking with the HiMark credit bureau in India. Becoming mandatory for MFIN network to be credit bureau members.
          Consolidated reporting and also decision engine to send all loans pending approval to credit bureau. 
      - EC: Philippines also a good amount of movement towards credit bureaus but not sure how much action yet.
      - EC: Also interest in credit scoring modules to enable more innovation around individual products and mobile products

Credit Scoring:
    -EC: What is needed?
        - RW: What data they needs to collet is being covered by Question Groups
        -  Ease of collecting data can be enhanced, need a view into that data (BI).
        -  Have the components but need to understand very deeply what is needed to address gaps. 
        
Cloud

  • KM: should we make it much easier to spin up new cloud instances?
  • Jakub: planning to work on integration of Mifos with Cloud Foundry - easier to deploy Mifos on Cloud if do that integration.
  • EC: Conflux working on pre-configured AMIs as well. 
  • Still hard to launch a complete Mifos Cloud solution

Installation:

  • RW: if an MFI can't install Mifos, are they capable of maintaining it on their own?
  • Are there things we can do to the application to make it easier to maintain? Question for devs. 
  • Udai: Friction of trying Mifos is too high right now - installer address that evaluation gap. 
  • KM: have demo instances configured for certain regions and then have these given out on trial basis. 
  • Udai: think is a psychological issue - very frustrating to not be able to run it when wanting to go try it out. 
  • RW: What are other documentation areas we can address to make evaluation process smoother?

Moving Forward:

  • Need a roadmap to show progress is happening
  • To get new customers need to translate this into a release plan.
  • BG: need to figure out to how capture this. What is the action plan to move forward?
  •  
  •  
    Next Steps
  • Ongoing teams
  • Tools and Approach