From: Keith W. <kei...@gm...> - 2011-07-02 10:16:30
|
Hi Amit, > .I would > love to share my views for developing the same.We just require for keeping > the thought of several Modules just like a different parts assemble at one > place to made a powerful car. Yes splitting things into components/modules is where we want to head to and are moving in that direction with respect to the code base. > I am ready to give my eligible support in any form. Amit, could you answer the following on behalf on Digamber? 1) what is the biggest challenge facing your MFI and what can we add/improve on mifos to help with this? regards, Keith. On Fri, Jul 1, 2011 at 6:26 PM, AMIT JAIN <ami...@gm...> wrote: > Hello to all, > > MAYA G is very close to us and we would not like to a part of a history. > > Now, yes Binny you understood all the major requirements of an MFI.I would > love to share my views for developing the same.We just require for keeping > the thought of several Modules just like a different parts assemble at one > place to made a powerful car. > > The theme of Mifos is good no one software having such wonderful UI. > > I appeal to the community please save the "Titanic" because we have a tools > for it. > > I am ready to give my eligible support in any form. > > THINK AGAIN > > Hope for a positive reply. > > Regards > > AMIT > DIGAMBER | FINANCE > On Fri, Jul 1, 2011 at 9:44 PM, Binny Gopinath <bin...@gm...> > wrote: >> >> Keith, >> >> Here are the high-lelvel points I have gathered during my interactions >> with Mifos users: >> >> Priority 1: >> >> Reporting and Dashboards - we have made good progress on this. But there >> is still some work here to get a few more key reports created or fixed. And >> also sort out some of the ETL related issues, make the ETL job quicker, >> reduce installation complexity, integrate reporting UI with Mifos etc. .. >> Flexibile loan scheduling - with facility for individual lending - Maya >> G's allowing a member to have loans with differing frequencies takes care of >> this partially. However, navigating to such individual loans (members may >> not belong to groups) still will have some challenges in Maya G >> Accounting - there are 2 approaches that MFI's have been requesting in >> India: >> a) Integrated accounting module - specifically for branch level >> accounting >> Also we need to re-look into accrual accounting and a cash book >> maintenance/cash management module >> b) Better integration with an existing accounting software like >> Tally >> Disbursement date flexibility - ability to specify a loan disbursement >> date in the future and not just the meeting period immediately following the >> current date >> Data migration toolkit - facility for easily and cleanly getting past >> member/group/loan data into Mifos - SunGard guys have developed a tool for >> this. They did give me a demo of this. We should just test and adopt this. >> >> Priority 2: >> >> Mobile devices and handheld device integration >> Offline data entry - important if Mifos has to be adopted by larger >> MFIs/SHGs who have better reach in rural areas (where internet connectivity >> is poor and electricity is available only for 1 or 2 hours on some days) >> Adequate Support for Self Help Groups - where more details of each groups >> linkage with their banks accounts can be managed, managing linkage between >> savings and loans etc. >> Support for large MFIs (> 1 million customers) - batch jobs and upgrades >> and reporting becomes a challenge with some tables have millions of rows >> >> Priority 3: >> >> HR integration - attendance, user security etc. >> Customer acquisition process - to schedule and manage the client >> pre-enrollment process (Group trainings and group tests) >> Customization of look and feel (logo, colors etc.) per installation - move >> internationalization resource bundles to the configuration folder so that it >> can be customized and deployed without being overwritten by each upgrade >> Integration with Credit Bureau / Identity verification systems >> >> Thanks >> Binny >> >> >> >> On Fri, Jul 1, 2011 at 5:41 PM, Keith Woodlock <kei...@gm...> >> wrote: >>> >>> Binny, >>> >>> > Are we concentrating too much on technical improvements while not >>> > paying >>> > adequate attention to new/improved features? >>> >>> Yes, this is the whole point of this email chain. I was asking for >>> input/feedback from the users about what to put into mifos after Maya >>> G. So far only george has offered some insight into what might be >>> useful going forward. From a technical point of view we know what we >>> need to do but theres no point in taking on that investment unless >>> customers out there want further features/improvements etc >>> >>> regards, >>> Keith. >>> >>> On Fri, Jul 1, 2011 at 5:50 AM, Binny Gopinath <bin...@gm...> >>> wrote: >>> > >>> > Are we concentrating too much on technical improvements while not >>> > paying >>> > adequate attention to new/improved features? >>> > >>> > Technical improvements without any visible improvement to end-users - >>> > may >>> > cause users to consider moving away from Mifos. I would like releases >>> > to be >>> > a mix of new/improved functional features + a bunch of technical >>> > improvements. I have had the chance to get a glimpse into some of our >>> > competition and very soon our feature set is going to be insufficient, >>> > which >>> > is heartbreaking .. >>> > >>> > On technical improvements: >>> > - would be good to include testing/handling of larger volumes - I have >>> > had a >>> > couple of enquiries from large MFI's - one of them has 4+ million >>> > members >>> > - on i18n, would be good to allow overriding of specific >>> > internationalized >>> > labels look up from config folders - so that they do not get >>> > overwritten by >>> > any upgrades. And also handle date formats consistently, especially in >>> > reports. >>> > >>> > Thanks >>> > Binny >>> > >>> > >>> > On Thu, Jun 30, 2011 at 10:33 AM, Van Mittal-Henkle >>> > <va...@gr...> wrote: >>> >> >>> >> George, >>> >> >>> >> I'm catching up on some of these threads after being out for a few >>> >> days >>> >> >>> >> > - there's a mobile revolution underway in sub-Saharan Africa; >>> >> > building >>> >> > both the APIs/hooks for connecting into a variety of mobile systems >>> >> > (from mobile money to mobile interfaces for clients and MFI staff to >>> >> > exchange of info with other systems that are running mobile apps) >>> >> > and >>> >> > also potentially getting a few sample/reference mobile apps running >>> >> > on >>> >> > Mifos (need to vet specific pain points so we don't build something >>> >> > just for the sake of building it) >>> >> >>> >> If Mifos provided Restful or WSDL based APIs it would open up lots of >>> >> possibilities for building on Mifos for things like this. Having >>> >> stable >>> >> APIs for people to build on is one of the things we have been working >>> >> towards for some time. A lot of KeithW's efforts in particular have >>> >> been around getting internals to a state where we could start layering >>> >> an API on them. As mentioned, getting specific customers with >>> >> specific >>> >> use cases to drive this is key. >>> >> >>> >> > also for you and the other engineers who have worked on MIfos: in a >>> >> > community model if there's less oversight, is there under-the-covers >>> >> > work that should be prioritized which will help keep Mifos stable >>> >> > and >>> >> > scalable as it goes forward in the community? >>> >> >>> >> Here's where some big questions come up. >>> >> >>> >> One hypothesis is that there are two classes of Mifos users-- Class 1: >>> >> larger MFIs who have a need for various extensions and customizations >>> >> of >>> >> Mifos and who can take on some expense to do that and even host their >>> >> own infrastructure and Class 2: smaller MFIs who could likely manage >>> >> with fewer features and less extensibility and who would benefit most >>> >> from low cost hosted access to Mifos. >>> >> >>> >> How to most effectively meet the needs of both users is tricky. >>> >> >>> >> We've been challenged by the current code base being difficult and >>> >> expensive to extend and maintain. We have made progress in improving >>> >> the code and certain areas of it are much easier to deal with now. >>> >> However, there is still a large amount of code left that needs >>> >> improvement. >>> >> >>> >> The most cost effective way to deliver a solution that can be >>> >> effectively hosted at very low cost (supporting multi-tenancy for >>> >> example) at this point looks like a rewrite that would pull in >>> >> reusable >>> >> parts of Mifos but redo the basics from the ground up to get things >>> >> like >>> >> multi-tenancy, transaction management, auditing, clean i18n, layered >>> >> architecture, separation of concerns and manageable tests in place. >>> >> To >>> >> keep the cost of doing a rewrite low, it would help for the target >>> >> release to have fewer features and options than Mifos currently does. >>> >> >>> >> On the other hand, supporting larger existing and new MFIs and those >>> >> requiring the larger feature set currently supported by Mifos would >>> >> benefit from the current code base being extended and refined. The >>> >> difficulty here is that the cost to continue maintaining the current >>> >> code is high as is the cost to refactor and improve it. >>> >> >>> >> Keith and I are in agreement on the things that he already laid out >>> >> here: >>> >> >>> >> http://mifosforge.jira.com/wiki/display/MIFOS/Technical+Roadmap+%28Post+ >>> >> Maya+G+and+onwards%29 >>> >> >>> >> This is a good list of how the current code base could be moved >>> >> forward. >>> >> >>> >> >>> >> Replacing the current Struts/JSP based UI code with Spring/Freemarker >>> >> is >>> >> the biggest single enabler for lowering the cost of maintaining and >>> >> extending Mifos. It leads to: >>> >> * API creation across the application (by achieving complete >>> >> separation >>> >> of business logic from presentation code) >>> >> * simplified transaction management >>> >> * simplified i18n >>> >> * improvement of layered architecture >>> >> * reduction and simplification of test code >>> >> >>> >> --Van >>> >> >>> >> >>> > >>> > >>> > ------------------------------------------------------------------------------ >>> > All of the data generated in your IT infrastructure is seriously >>> > valuable. >>> > Why? It contains a definitive record of application performance, >>> > security >>> > threats, fraudulent activity, and more. Splunk takes this data and >>> > makes >>> > sense of it. IT sense. And common sense. >>> > http://p.sf.net/sfu/splunk-d2d-c2 >>> > _______________________________________________ >>> > Mifos-users mailing list >>> > Mif...@li... >>> > https://lists.sourceforge.net/lists/listinfo/mifos-users >>> > >>> > >>> >> >> >> ------------------------------------------------------------------------------ >> All of the data generated in your IT infrastructure is seriously valuable. >> Why? It contains a definitive record of application performance, security >> threats, fraudulent activity, and more. Splunk takes this data and makes >> sense of it. IT sense. And common sense. >> http://p.sf.net/sfu/splunk-d2d-c2 >> _______________________________________________ >> Mifos-users mailing list >> Mif...@li... >> https://lists.sourceforge.net/lists/listinfo/mifos-users >> > > > > -- > AMIT JAIN | E.D | Digamber Finance (Chota Loan Bade Sapne) | +919414041821 | > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > _______________________________________________ > Mifos-users mailing list > Mif...@li... > https://lists.sourceforge.net/lists/listinfo/mifos-users > > |