A clear “ERP for life” example

by Asier Zabaleta

Senior Consultant at Global Partner Services

Just one year ago the first Quickstart implementation reached the "go live" milestone. Idea Innovación Asistencial is a management company, developer of  social and health services under the clinical and care sector, with an interesting Openbravo ERP customer case.

After a successful QuickStart implementation in 60 hours (including system configuration and user training), Idea started managing one of its organizations, including around 100 customers, and over 150 transactions every month. Their daily work changed completely, as they abandoned their accounting software, and started using Openbravo ERP for issuing invoices to customers, effectively managing collections, and knowing on time the cash situation for vendor payments.

Today, the picture is quite different, as the use of the ERP has grown exponentially. Now the ERP supports the management of seven organizations, and two more to come in the following months. The number of users in the ERP has been doubled in just a year, and the number of transactions multiplied by four. Now there are over 300 customers to be managed, and lots of payment situations to be taken care of.

This is a clear example of the Openbravo QuickStart value proposition both for the customer and the system integrator.

System integrators should see this kind of implementations not just as “quick-wins”, but as a way to start a long term relationship with their customers. With Openbravo QuickStart, system integrators can reach many small companies looking for a quick, standard implementation; a low risk proposition for a successful ERP implementation.

On the other hand, end customers should see a low risk first implementation, establishing this starting point that can incrementally grow in the future, based in a solid ground that Openbravo ERP provides. Openbravo's modular architecture, combined with Openbravo Exchange and the associated Central Repository, make it very easy to embrace new modules directly from the browser via the click-thru installation process. In Idea's case, the "Mass Invoicing" module was added during the initial QuickStart implementation to streamline the invoicing process.

Idea Innovación Asistencial began with the Openbravo QuickStart option based on the promise of a rapid, low-risk ERP implementation with a minimal upfront investment.  The deployment was  hosted on the Amazon EC2 Cloud to avoid upfront hardware acquisition costs, with the assumption that the application would likely be brought in house at some point. To date, Idea has actually stayed on the Amazon cloud, finding it cost-effective and reliable, with off-site backup for full peace of mind. While Openbravo ERP started as a "quick win" for Idea, its web-based scalability and modular extensibility have made Openbravo a strategic part of this customer's business -truly an "ERP for life" -, that they will continue to grow with in the future.

Have you got similar experiences?

Launch of the Functional Graduate Certification for Openbravo ERP 2.50!!

by Renate Nieuwkoop
Senior Education Specialist at Global Partner Services

After a successful launch of Foundation Certification programme last year, we are now happy to announce the first Graduate Exam. The Functional Graduate Certification has been made widely available starting February 26, 2010.

Since the launch of the Foundation exams, many partners have become certified and can now progress to the next level to become certified at a Graduate level.

Certification is essential to end customers, partners and us at Openbravo for several reasons:

• Assures customers of your knowledge, skill and credentials
• Shows tangible evidence of your ability
• Adds to your credibility in the Openbravo ecosystem
• Allows Openbravo to set a brand standard and monitor the quality of our partners

Whereas the Functional Foundation knowledge can be mastered through participation in the Basic Functional Training, the Graduate exam is going beyond that and is based on knowledge that can only be gained through practical use and implementation of the Openbravo ERP application. The objective of the Graduate exam is to demonstrate the ability to configure and use the application in a real life scenario.

For more information about the Functional Graduate Certification, please click here. For any questions, do not hesitate to contact us directly at training@openbravo.com

What does upgrading to 2.50 mean?

by Jorge Monfort
Senior Consultant at Global Partner Services

When you are facing an Openbravo ERP 2.40 to 2.50 upgrade project the first thing you need to consider is what the real purpose of this upgrade is and what your client's expectations are.

The upgrade process, in fact, entails converting core customization into modular extensions and the effort required to perform this task greatly depends on the degree of re-use that you want to achieve.

For most companies, who have customized 2.40 for their own usage and do not have an interest in sharing their extensions, the scope is limited to a straight technical upgrade. On the other hand, if the client wishes to obtain reusable modules that can be distributed through the Central Repository or sold through the Openbravo Exchange, more work is required.

At the extreme end of complexity, you will find the case where the client wants to achieve a complete and fully packaged and reusable vertical solution.

I recently worked on such an upgrade and I would like to share here some lessons learned in this project. Let's try to analyze these different scenarios and the impact of each one of them.

Case 1: Single company that just wants to upgrade to 2.50:
There are many reasons for upgrading to 2.50

• To take advantage of the new functionality included in the 2.50 version
• To leverage the easy maintainability experience of the modularity platform
• Due to the sunset of their current Openbravo ERP version

In this case, just an upgrade could mainly fulfill the expectations. The Openbravo ERP upgrader would create a single extra module including all customizations, and after some adaptations and manipulations we could enjoy a real 2.50 implementation, always taking into account that this module wouldn't accomplish the necessary naming rules required to be able to publish it in the Openbravo Central Repository or in the Exchange.

Apart from this first simple scenario we could think of enhancing it by re-factoring our big module into smaller ones to simplify its maintainability in production environments and reduce the effort of resolving future potential bugs or naming conflicts (reviewing and updating a small module will always be easier than having to create a new version of the whole big industry template module). It would involve creating new modules and moving some customizations from the original big module (mycustomization module) to these new modules.

Although we should always take into account the significant increase in effort required, it would also constitute a pre-step to future module reusability which will lead us to case 2.

Case 2: Client that expects to commercialize his customizations
In case our client considers that customizations implemented for them could have commercial relevance, or just thinks that it could be a chance to recoup their investment, we should take some specific actions in order to be able to publish them in the Openbravo Exchange.

• In this case, re-factoring into independent modules is a must. That means a higher investment but it is justified by a commercial return.
• Adjusting to Naming Rules would also be a must in order to guarantee that our modules are fully compatible with others published in Openbravo Exchange. This task also implies a big effort for renaming all our customizations.

So, notice that all this judgments need to be done and scope should be clearly defined before starting the project because it has a clear impact in the effort load calculation and in reaching the client's expectations.