It is nearly impossible to see new players in ERP market especially international ones. Big vendors are very powerful and ERP is not such an application that anybody could write when wishing so. Software vendors who want to enter this field generally buy some small players in the town. ERP is an aged product, it requires time to mature. It requires at least 10 years getting the applications ready for mid-market. For that reason ERPs are usually based on some old-technologies and always on the track to catch the new technologies. We began to write our ERP in 2001 and for that reason we could have contemporary technologies inside the ERP which is Java EE.
Our ERP project began as an in-house project to meet the requirements of a big group of companies. We finished almost 30 ERP implementations. The total time we spent during that time is approximately 8 years. It took 3 years to get first release of the ERP which is a very daunting project. Making first release doesn’t guarantee to sustain ERP package growth. We designed the applications by analyzing many ERP packages to make the right choices. We struggled to make it architecture “Made to Grow” since every ERP applications get bigger by the time with new projects.
We are currently trying to package this in-house ERP to serve outside companies. We are expecting to release that packaged version on the early months of 2010. We believe we have some unique aspects.
Current ERPs Disadvantages
1- Cost: ERPs are really very costly projects compared with other IT projects. It is not a sole software project but it is a hardware and business improvement project as well. Its selection and its consequences are another article topic.
2- Complexity: ERPs get bigger and bigger. Every piece of business logics is programmed and to manage such a big application source base is a very big challenge. Big scaled ERP applications are an extra cost for mid-size companies with no real benefit. This is something that you buy a fully-fledged gadget and you use only one function of this gadget paying for all functions. You not only pay for unused functions, you also pay for the complexity of managing and adapting this huge code base to your company.
3- Old Core Technology: Many ERPs are rooted to back 20 years. Although many ERP vendors tried to renovate their core technology, they still lack many new technologies. Web technologies are the primary problem of ERP vendors since migrating to these technologies are still a risky operation since there is still some function gaps compared with client-server architecture. To innovate in this function gaps are still very hard for most of them. For that reason, you won’t see an existence for old players in the field of SAAS market.
Our ERP Features
1- Contains Standard ERP Modules: It contains 4 suites; Common, Finance, Production and Human Resources which are totally 80 modules. We have some beta suites; Import/Export, Insurance, Free Trade Management, Catering.
2- Based on Java EE Platform: Yes, finally an ERP is written in Java EE from bottom up. As I outlined some of the features in the previous blog post, it is not as much proprietary as the others. We depend on Java EE on infrastructure side, and Java EE advantages are our applications advantages.
3- 100% Web-Based: Many ERPs claiming to be web-based are just some thin-client applications instead of core web technologies. In my perspective, web is going to be the most powerful and prevalent application model in today and would be in coming years. Web architecture advantages are our applications advantages. To convert a standard client-server application to web-based architecture is not an ordinary application migration. As I said before, it is much more difficult than to change a programming language of ERP.
4- It is Built with Best Features of Current ERPs: Oracle Fusion Application target is to mix bets of features in ERP packages, we already did it. During application design, we analyzed a lot of ERPs and tried to build best of breed modules.
5- ALM Platform for Easy Extensibility and Customization: We have a complete ALM platform so application management is very easy. Our development platform is not only a development platform, it is like an application operating system.
We are Seeking Investor Partners
We are seeking partners to invest in our Java EE platform and ERP. If you are an IT company and want to enter this market, it is a best practice to go with an existing package. Developing an ERP is a challenging job which is beyond from the technical expertise. Many ERP development projects failed because of not realizing that reality.
I remember a colleague who asked me for advice about their ERP project. I said not to see ERP development as a software project. His answer was I’m technically profound to develop any software package. What happened? They failed. Why? They had exhausted their time with infrastructure and development process issues and application modules were late to use (I guess it stemmed from the lack of knowledge to transfer business logic to applications) and their project cancelled. That kind of stories generally finish with a new ERP project bought from big vendors (To reduce a new risk and failure, project sponsors are now more generous to buy from a big vendor).
Subscribe to:
Post Comments (Atom)
3 comments:
IMHO from what ever I have seen, Thinking about ERP as a Functional application is a mistake, one have to look at ERP as a platform, kind of developing an eclipse, Development team should "avoid" to get bogged down in initial iteration on building functionality but stick to building platform.
The point I am trying to put is, packaged ERP module is just a part of solution, but providing extension point for writing and integrating a new specific application is the other part of solution, and providing ability to extend a solution with individual problem, is IMO completes the picture. Again Think Eclipse think writing a new Plugin, think plugin which extends a plugin.
"Thinking about ERP as a Functional application is a mistake".
Sorry but I can't agree with that. ERP is "first of all" a functional application. A customer would not look at your platform if he can't find an important function in your ERP. Platform comes next but it is also a very important part of ERP project lifecycle. Platform concerns both ERP technical team and system administrators. If you can't debug your code in Eclipse you won't prefer it, why? you don't find a crucial function(debugging) in the target application. You won't look at how powerful its plugin architecture is.
Ok let me try to put my point around your analogy.
Development team finds it easy to source a debugging plugin for the required application.
2) Application developer team finds it easy to extend eclipse and build their debugger.
IMO Pre-eclipse era lot of java IDE suffered from wana-be visual studio complex.
1) not having enough experience of building IDE
2) not having enough developer like visual studio team
Eclipse changed that with eclipse eco system,
Ok I know it’s a bit of stretch that you will make the ERP ecosystem platform and automagically all the Brick and mortar company will start using / building / contributing to the eco system, but what can really happen is your platform becomes your team’s core strength and then you start building/mashing component with your Functional expert who if my dream comes true uses ERP DSL to modify/customize their specific module.
So again In my View spring framework is successful because it never tried to be a framework only, the core of its success was the service locator platform on which I can integrate, hibernate, struts, quartz and all the other library, (please don’t take this as I am trivializing spring, I am just using spring in a very shallow and specific context of my ERP example)
OT: ERP software company don’t only buy other ERP solution company for their ERP package, but mostly and only to get access to their client some Brick and mortar company
Post a Comment