In this post I comment two blog entries related to the use of open source software for auditing purposes in the banking area.
In the first one, Open Source Banking for Financial Stability, Jean Paul Smets affirms that some serious problems presented by financial products not compliant to the regulations are caused by software systems which "are not subject to any kind of regulatory control and, therefore, may be used to circumvent regulations either through functional inconsistencies or through temporal inconsistencies." Therefore, he defends the idea of using a reference open source software, without getting rid of the software in which banks invested for decades. This reference, besides offering an auditable software representation of the regulations rules, would be used "to provide to regulation authorities a very accurate picture of [banks] activity, much more precise than what accounting can provide." - by importing the data handled by existing bank's software.
In the second post, Python Could Become the Language of Finance, Jonathan Allen informs that SEC is proposing that Asset Backed Securities should include a “program that gives effect to the flow of funds, or “waterfall,” provisions of the transaction.” Waterfall in this case "refers to how some bonds are broken into levels, where those who bought into the higher level must be paid off before the lower level sees any money." The interesting part is that SEC is planning to mandate Python as the language for building this reporting tool, because it is open source, uses a standalone interpreter, and is supported by many platforms, including proprietary software such as .NET.
Although the first post is an opinion, the second isn't, and both present good arguments to motivate regulatory organs to use more open source for auditing tasks in the financial area, and, why not say, in other areas. The use of open source reference softwares would (i) help people compare their implementations of regulatory rules with a standard implementation, (ii) provide cheaper software that could be customized for specific adopters, while following the regulation, (iii) provide automated tools for regulatory agencies to audit data. In that way, maybe the number of financial scandals could be reduced, as well as regulatory work in other areas, such as environment, could be simplified and streamlined.
Showing posts with label Free/Open Source ERP (FOS-ERP). Show all posts
Showing posts with label Free/Open Source ERP (FOS-ERP). Show all posts
Friday, February 25, 2011
Thursday, October 28, 2010
Free/Open Source ERP (FOS-ERP) - Part VI
In 2007 I wrote a book chapter on the differences between FOS-ERP and proprietary ERP (P-ERP), published as part of the Handbook on Research in Enterprise Systems in 2008. This post is part of a series that revisits this paper. Please refer to the first post of this series to better understand the structure used in this comparison.
Opportunities and Challenges
FOS-ERP offer a series of opportunities for actors that are currently out of (or ill inserted) the ERP market. Since there is nothing such as free lunch, these opportunities come together with a series of challenges, as listed below.
For smaller consulting firms:
a) Opportunities:
P-ERP vendors generally impose rigid procedures, associated to high costs, for firms that want to enter their partner network, raising the difficulties for smaller enterprises to become players in this market. In contrast, smaller consulting firms can enter the FOS-ERP market in an incremental way, increasing their commitment to a project as new business opportunities appear and bring more financial income. In other words, firms can start contributing with small improvements to the project as a way of gaining knowledge on the system platform and framework, and, as customers appear, more money can be invested on a growing commitment to the project.
b) Challenges:
If on one hand it is easier to enter the market, on the other it is harder to retain clients: a broader consultancy basis empowers the demand side, making customers more demanding and reducing profit margins.
Keeping the quality level among a heterogeneous network of consulting services providers is also a major challenge. FOS-ERP in general lack certification and quality assurance programs that guarantee service levels to clients. However, exactly those programs keep smaller consulting firms way from P-ERP, pushing them towards FOS-ERP. For a small consulting firm, a possible solution to this deadlock is to start with smaller, less demanding projects, and then go towards bigger ones, as its deployment processes and related activities gain maturity. This maturity will become the competitive advantage of the firm on a high competitive FOS-ERP market.
For smaller adopters:
a) Opportunities:
lower costs open new opportunities for Small and Medium Enterprises (SME) to become ERP adopters. With globalization, small firms suffer more and more with competition, and when they try to modernize their processes, they hit the wall of global players’ high costs, or have to adopt smaller off-the-shelf (and also proprietary) solutions that ties them to a single supplier that usually doesn’t have a partner network. In contrast, FOS-ERP are less expensive and support can be found in different ways, including individuals and small consulting firms.
This is also truth for local governments and countries in development in general, by reducing costs and technological dependency from global players. In fact, FOSS in general is an opportunity for countries in development to shift from buyers to players in the software industry.
b) Challenges:
lower costs can also mean that adopters have to deal with lower service levels, then stressing the necessity of carefully evaluating FOS-ERP options and the maturity of their supportive services. Actually, as said before, consulting certification is yet on the early stages for FOS-ERP, thus quality of service must be carefully addressed during contract negotiation.
For researchers:
a) Opportunities:
I've been contributing to ERP5 since its conception. During this time it was possible to observe, and sometimes take part, of all the process that compose an ERP solution, from conception and development, to business models, deployment, operation and maintenance, and evolution. This is a really good opportunity, since most research papers on ERP are related to deployment and operation, given that P-ERP companies don’t usually open their solution's internals for researchers. Smaller research groups can find their way in this area by getting associated to a FOS-ERP project, and contributing to specific parts of it.
b) Challenges:
If on one hand the openness of FOS-ERP may give researchers more information on their internal features and development processes, on the other hand it is harder to get information from a distributed set of partners that sometimes carry informal relationships. Social and economical aspects, like reward structures, must be taken into account to understand the dynamics of FOS-ERP, like in every FOSS, bringing more components to be analyzed.
For individuals
a) Opportunities:
FOS-ERP represent an unique opportunity for an individual to install an ERP framework and understand its internals. It is the chance of participating in a big software development project without being an employee of a big company. Also, the developer can incrementally gain knowledge of the system, and get free support from the community, without the necessary investment on the P-ERP expensive training and certification programs. In the future, these advantages can make more free-lance developers enter FOS-ERP communities, currently formed mostly by consulting companies employees.
b) Challenges:
learning the internals of a FOSS in general means to spend considerable time in understanding system architecture, design decisions, and specific features. Moreover, FOS-ERP still lack courseware in general*** to help accelerating the learning process, and many times the individual must count on Web sites, mailing lists, discussion forums, and the good will of community members to acquire deeper knowledge on the framework.
***When I originally wrote this in 2007, ERP5's OSOE Project didn't exist yet. My opinion on ERP5 can be biased, but the truth is that Nexedi agreed on this point and decided to start a web based training program to fill this gap.
Opportunities and Challenges
FOS-ERP offer a series of opportunities for actors that are currently out of (or ill inserted) the ERP market. Since there is nothing such as free lunch, these opportunities come together with a series of challenges, as listed below.
For smaller consulting firms:
a) Opportunities:
P-ERP vendors generally impose rigid procedures, associated to high costs, for firms that want to enter their partner network, raising the difficulties for smaller enterprises to become players in this market. In contrast, smaller consulting firms can enter the FOS-ERP market in an incremental way, increasing their commitment to a project as new business opportunities appear and bring more financial income. In other words, firms can start contributing with small improvements to the project as a way of gaining knowledge on the system platform and framework, and, as customers appear, more money can be invested on a growing commitment to the project.
b) Challenges:
If on one hand it is easier to enter the market, on the other it is harder to retain clients: a broader consultancy basis empowers the demand side, making customers more demanding and reducing profit margins.
Keeping the quality level among a heterogeneous network of consulting services providers is also a major challenge. FOS-ERP in general lack certification and quality assurance programs that guarantee service levels to clients. However, exactly those programs keep smaller consulting firms way from P-ERP, pushing them towards FOS-ERP. For a small consulting firm, a possible solution to this deadlock is to start with smaller, less demanding projects, and then go towards bigger ones, as its deployment processes and related activities gain maturity. This maturity will become the competitive advantage of the firm on a high competitive FOS-ERP market.
For smaller adopters:
a) Opportunities:
lower costs open new opportunities for Small and Medium Enterprises (SME) to become ERP adopters. With globalization, small firms suffer more and more with competition, and when they try to modernize their processes, they hit the wall of global players’ high costs, or have to adopt smaller off-the-shelf (and also proprietary) solutions that ties them to a single supplier that usually doesn’t have a partner network. In contrast, FOS-ERP are less expensive and support can be found in different ways, including individuals and small consulting firms.
This is also truth for local governments and countries in development in general, by reducing costs and technological dependency from global players. In fact, FOSS in general is an opportunity for countries in development to shift from buyers to players in the software industry.
b) Challenges:
lower costs can also mean that adopters have to deal with lower service levels, then stressing the necessity of carefully evaluating FOS-ERP options and the maturity of their supportive services. Actually, as said before, consulting certification is yet on the early stages for FOS-ERP, thus quality of service must be carefully addressed during contract negotiation.
For researchers:
a) Opportunities:
I've been contributing to ERP5 since its conception. During this time it was possible to observe, and sometimes take part, of all the process that compose an ERP solution, from conception and development, to business models, deployment, operation and maintenance, and evolution. This is a really good opportunity, since most research papers on ERP are related to deployment and operation, given that P-ERP companies don’t usually open their solution's internals for researchers. Smaller research groups can find their way in this area by getting associated to a FOS-ERP project, and contributing to specific parts of it.
b) Challenges:
If on one hand the openness of FOS-ERP may give researchers more information on their internal features and development processes, on the other hand it is harder to get information from a distributed set of partners that sometimes carry informal relationships. Social and economical aspects, like reward structures, must be taken into account to understand the dynamics of FOS-ERP, like in every FOSS, bringing more components to be analyzed.
For individuals
a) Opportunities:
FOS-ERP represent an unique opportunity for an individual to install an ERP framework and understand its internals. It is the chance of participating in a big software development project without being an employee of a big company. Also, the developer can incrementally gain knowledge of the system, and get free support from the community, without the necessary investment on the P-ERP expensive training and certification programs. In the future, these advantages can make more free-lance developers enter FOS-ERP communities, currently formed mostly by consulting companies employees.
b) Challenges:
learning the internals of a FOSS in general means to spend considerable time in understanding system architecture, design decisions, and specific features. Moreover, FOS-ERP still lack courseware in general*** to help accelerating the learning process, and many times the individual must count on Web sites, mailing lists, discussion forums, and the good will of community members to acquire deeper knowledge on the framework.
***When I originally wrote this in 2007, ERP5's OSOE Project didn't exist yet. My opinion on ERP5 can be biased, but the truth is that Nexedi agreed on this point and decided to start a web based training program to fill this gap.
Free/Open Source ERP (FOS-ERP) - Part V
In 2007 I wrote a book chapter on the differences between FOS-ERP and proprietary ERP (P-ERP), published as part of the Handbook on Research in Enterprise Systems in 2008. This post is part of a series that revisits this paper. Please refer to the first post of this series to better understand the structure used in this comparison.
Operation
During operation, environmental changes will lead to corresponding changes in the system. These changes can be conducted by the original vendor, other service providers, or even the adopter with help of the community. Operation costs are reduced by other technologies of which FOS-ERP usually rely on, such as Operating Systems, Office Suites, Middleware etc.
A conclusive remark is that, although experience has shown that most of the times the adopter will not be active on tasks that involve coding, FOS-ERP is still a good choice, since it reduces vendor dependency. Moreover, the openness of code delivers much more opportunities for creating competitive differential by implementing innovative processes or algorithms and integrating to other solutions.
Until this point I talked about the differences between FOS-ERP and P-ERP on the adopter side. For understanding the differences on the vendor side, please refer to the original article. In the next post I will talk about the opportunities and challenges brought by FOS-ERP.
Operation
During operation, environmental changes will lead to corresponding changes in the system. These changes can be conducted by the original vendor, other service providers, or even the adopter with help of the community. Operation costs are reduced by other technologies of which FOS-ERP usually rely on, such as Operating Systems, Office Suites, Middleware etc.
A conclusive remark is that, although experience has shown that most of the times the adopter will not be active on tasks that involve coding, FOS-ERP is still a good choice, since it reduces vendor dependency. Moreover, the openness of code delivers much more opportunities for creating competitive differential by implementing innovative processes or algorithms and integrating to other solutions.
Until this point I talked about the differences between FOS-ERP and P-ERP on the adopter side. For understanding the differences on the vendor side, please refer to the original article. In the next post I will talk about the opportunities and challenges brought by FOS-ERP.
Wednesday, October 20, 2010
Free/Open Source ERP (FOS-ERP) - Part IV
In 2007 I wrote a book chapter on the differences between FOS-ERP and proprietary ERP (P-ERP), published as part of the Handbook on Research in Enterprise Systems in 2008. This post is part of a series that revisits this paper. Please refer to the first post of this series to better understand the structure used in this comparison.
Detailed Design and Implementation
The detailed design phase focuses on refining models and parametrization. The implementation phase concentrates on programming/configuring, validating, integrating and releasing modules for initial use. Remember that if you are using an interactive and incremental process, you will do this module by module, or even by implementing intermediary versions of modules: modules can have partial implementations that will be refined by operation, in other words, we can go back to refine a module in a future iteration. The Figure 1 revisits Gera's life cycle by changing it from a Waterfall to an Iterative & Incremental perspective.
In Figure 1, the outer loop refers to the iterations, while the internal loop refers to the possibility of releasing incremental versions of the modules.
If the adopter opts to participate actively in the selected project, deeper design and implementation decisions are involved, as well as the necessity of investing more human and financial resources for understanding the FOS-ERP framework, developing and maintaining parts of it, and managing the relationship with the project's community.
If a FOS-ERP vendor is involved, customization and maintenance contracts must define the responsibilities of each part on the deployment process. For instance, what the vendor should do if it finds a bug injected by the customer? What is the priority, for the vendor, for correcting this bug? Actually, is the vendor responsible for correcting this bug, since for this part of the system the adopter decided to take advantage of the solution’s free license, therefore exempting the vendor of responsibility for the bug?
Furthermore, the adopter has the option of assuming different grades of involvement for each module. For ordinary modules, like payroll, the adopter can let the vendor do the work. However, for strategic modules, for which the adopter believes that holds competitive advantage by following its own business processes, the adopter can take an active role from detailed design to implementation and maintenance, to assure that the business knowledge, or at least the more precious details that keep the competitive advantage, will be kept in the adopter company. In that situation the vendor is limited to act as a kind of advisor to the adopter.
A very interesting point is the openness of parts customized for and sponsored by a specific adopter. Maybe the adopter doesn’t want to become a developer at all – which is very likely to happen, but it still wants to keep some tailored parts of the system in secrecy. In these cases, the ERP's licensing terms must be adapted, so that general openness of the code is guaranteed, while some client-sponsored customized parts can be kept closed.
Although this last point can seem to be nonsense in FOSS terms, it is a common real-life situation in FOS-ERP. In fact, I know a case that an adopter company sponsored the whole development of an FOS-ERP during a three-year period, without becoming a prosumer and keeping only a specific algorithm in secret. The original license had to be changed to fit this customer demand.
Detailed Design and Implementation
The detailed design phase focuses on refining models and parametrization. The implementation phase concentrates on programming/configuring, validating, integrating and releasing modules for initial use. Remember that if you are using an interactive and incremental process, you will do this module by module, or even by implementing intermediary versions of modules: modules can have partial implementations that will be refined by operation, in other words, we can go back to refine a module in a future iteration. The Figure 1 revisits Gera's life cycle by changing it from a Waterfall to an Iterative & Incremental perspective.
Figure 1: Iterative & Incremental Gera's Lifecycle
In Figure 1, the outer loop refers to the iterations, while the internal loop refers to the possibility of releasing incremental versions of the modules.
If the adopter opts to participate actively in the selected project, deeper design and implementation decisions are involved, as well as the necessity of investing more human and financial resources for understanding the FOS-ERP framework, developing and maintaining parts of it, and managing the relationship with the project's community.
If a FOS-ERP vendor is involved, customization and maintenance contracts must define the responsibilities of each part on the deployment process. For instance, what the vendor should do if it finds a bug injected by the customer? What is the priority, for the vendor, for correcting this bug? Actually, is the vendor responsible for correcting this bug, since for this part of the system the adopter decided to take advantage of the solution’s free license, therefore exempting the vendor of responsibility for the bug?
Furthermore, the adopter has the option of assuming different grades of involvement for each module. For ordinary modules, like payroll, the adopter can let the vendor do the work. However, for strategic modules, for which the adopter believes that holds competitive advantage by following its own business processes, the adopter can take an active role from detailed design to implementation and maintenance, to assure that the business knowledge, or at least the more precious details that keep the competitive advantage, will be kept in the adopter company. In that situation the vendor is limited to act as a kind of advisor to the adopter.
A very interesting point is the openness of parts customized for and sponsored by a specific adopter. Maybe the adopter doesn’t want to become a developer at all – which is very likely to happen, but it still wants to keep some tailored parts of the system in secrecy. In these cases, the ERP's licensing terms must be adapted, so that general openness of the code is guaranteed, while some client-sponsored customized parts can be kept closed.
Although this last point can seem to be nonsense in FOSS terms, it is a common real-life situation in FOS-ERP. In fact, I know a case that an adopter company sponsored the whole development of an FOS-ERP during a three-year period, without becoming a prosumer and keeping only a specific algorithm in secret. The original license had to be changed to fit this customer demand.
Thursday, October 14, 2010
Free/Open Source ERP (FOS-ERP) - Part III
Free/Open Source ERP (FOS-ERP), Process, ProductIn 2007 I wrote a book chapter on the differences between FOS-ERP and proprietary ERP (P-ERP), published as part of the Handbook on Research in Enterprise Systems in 2008. This post is part of a series that revisits this paper. Please refer to the first post of this series to better understand the structure used in this comparison.
Requirements and Preliminary Design
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.
Sunday, October 10, 2010
Free/Open Source ERP (FOS-ERP) - Part II
In 2007 I wrote a book chapter on the differences between FOS-ERP and proprietary ERP (P-ERP), published as part of the Handbook on Research in Enterprise Systems in 2008. This post is part of a series that revisits this paper. Please refer to the first post of this series to better understand the structure used in this comparison.
Concept
During this phase, high-level objectives are established, such as the acquisition strategy, preliminary time and cost baselines, as well as the expected impact of the ERP adoption in the organization. If besides customization, development is necessary, in the case of FOS-ERP, the level of involvement of the adopter in this development can be established. In other words, even from this initial point, the adopter can start considering the possibility of contributing to a FOS-ERP project, becoming a prosumer - a mixture of consumer and producer of the solution. The final decision on becoming or not a prosumer will be possible only during the following phases, when the adopter better understands the solution requirements and the solution alternatives.
Small and Micro enterprises hardly will become prosumers because of the lack of IT personal necessary to develop - I will talk about this latter.
Concept
During this phase, high-level objectives are established, such as the acquisition strategy, preliminary time and cost baselines, as well as the expected impact of the ERP adoption in the organization. If besides customization, development is necessary, in the case of FOS-ERP, the level of involvement of the adopter in this development can be established. In other words, even from this initial point, the adopter can start considering the possibility of contributing to a FOS-ERP project, becoming a prosumer - a mixture of consumer and producer of the solution. The final decision on becoming or not a prosumer will be possible only during the following phases, when the adopter better understands the solution requirements and the solution alternatives.
Small and Micro enterprises hardly will become prosumers because of the lack of IT personal necessary to develop - I will talk about this latter.
Free/Open Source ERP (FOS-ERP) - Part I
In 2007 I wrote a book chapter on the differences between FOS-ERP and proprietary ERP (P-ERP), published as part of the Handbook on Research in Enterprise Systems in 2008. I will start now a series of posts that will revisit this paper.
This first part will quickly introduce the Generalized Enterprise Reference Architecture and Methodology (GERAM) as a framework for comparing FOS and P-ERP.
GERAM defines seven life-cycle phases for any enterprise entity and can be used as a template life cycle to analyze FOS-ERP selection, deployment, and evolution. These phases, represented on Figure 1, can be summarized as follows:
a)Identification: identifies the particular enterprise entity in terms of its domain and environment.
b)Concept: conceptualizes an entity’s mission, vision, values, strategies, and objectives.
c)Requirements: comprise a set of human, process, and technology oriented aspects and activities needed to describe the operational requirements of the enterprise.
d)Design: models the enterprise entity and helps to understand the system functionalities.
e)Implementation: the design is transformed into real components. After tested and approved the system is released into operation.
f)Operation: is the actual use of the system, and includes user feedback that can drive to a new entity life cycle.
g)Decommission: represents the disposal of parts of the whole entity, after its successful use.
Except for decommission and identification, which are not (directly) influenced by licensing models, these phases can be used to better understand how FOS-ERP differs from P-ERP, as next posts will explain.
This first part will quickly introduce the Generalized Enterprise Reference Architecture and Methodology (GERAM) as a framework for comparing FOS and P-ERP.
GERAM defines seven life-cycle phases for any enterprise entity and can be used as a template life cycle to analyze FOS-ERP selection, deployment, and evolution. These phases, represented on Figure 1, can be summarized as follows:
a)Identification: identifies the particular enterprise entity in terms of its domain and environment.
b)Concept: conceptualizes an entity’s mission, vision, values, strategies, and objectives.
c)Requirements: comprise a set of human, process, and technology oriented aspects and activities needed to describe the operational requirements of the enterprise.
d)Design: models the enterprise entity and helps to understand the system functionalities.
e)Implementation: the design is transformed into real components. After tested and approved the system is released into operation.
f)Operation: is the actual use of the system, and includes user feedback that can drive to a new entity life cycle.
g)Decommission: represents the disposal of parts of the whole entity, after its successful use.
Figure 1. GERAM Life Cycle Phases
Except for decommission and identification, which are not (directly) influenced by licensing models, these phases can be used to better understand how FOS-ERP differs from P-ERP, as next posts will explain.
Monday, September 13, 2010
ERP Licensing perspectives - Confenis 2010
Paper presented at Confenis 2010, compares, in general, licensing perspectives for Free/Open Source ERP (FOS-ERP) and Proprietary ERP (P-ERP). The main findings are that Small companies are different of Medium companies in terms of adoption and that Community Sponsored is different of Commercially Sponsored FOS-ERP.
Subscribe to:
Comments (Atom)