Requirements and Preliminary Design
Given that most software development (and customization) today is done (or should be done) through interactive and incremental life cycles, the requirements, preliminary design, detailed design, and implementation phases are performed in a loop.
Following its list of priority requirements, the adopter can model its main business processes – as part of the Preliminary Design – in order to check how the different ERP systems fit to them. At this point, FOS-ERP need to be evaluated using the criteria traditionally used to evaluate ERPs in general, as well as criteria related specifically to Free/Open Source Software (FOSS) in general, such as maturity of the community and the levels of support.
An interesting point regarding FOS-ERP is that, although it can produce a smaller financial impact, it may bring a bigger knowledge and innovation impact. The access to the source code in FOS-ERP can drive to a much better exploration of the ERP’s capabilities, thus allowing a better implementation of differentiated solutions. Of course, software development resources must be available to reach this, what means that for smaller organizations this is usually not possible.
From this standpoint, the strategic positioning of an adopter in relation to a FOS-ERP seems to be of greatest importance, given the possibility of deriving competitive advantage from the source code. Therefore, the adopter must decide to behave as a simple consumer, only obtaining the solution from a vendor or the community, or become a prosumer, by mixing passively acquiring commodity parts of the system with actively developing strategic ones by itself. Thus it is clear that when an adopter considers FOS-ERP as an alternative, it should also consider developing parts of the system to fit its requirements – taking into account that this kind of positioning represents allocating managerial and technical resources for development tasks in a FOSS environment.