7 Tips To Develop a Web Based ERP System

One of your sales staff is excited. He has just made a huge sale. Unfortunately, when he submitted the order for processing, he was informed the following day that there was not enough inventory to fill the order, and he would have to go back and explain to the customer that there would now be a two-week wait for the product.

When enough of these types of events occur, an enterprise realizes that customized ERP development is an essential addition. Yet, there is a myriad of choices to be made. And as these choices are made, there is a path to make these choices and to move forward in a logical way and end up with an ERP solution that works. Here is that path.

Begin with a Vision

Anyone who is going to engage in ERP system development, whether for their own enterprise or for another enterprise as a consultant, must begin with a vision of what the end product should deliver.

Everyone accepts the fact that the goal is to make information flow among all facets of an organization, as well as beyond, and flow with immediacy, with all routine processes automated. Beyond that, however, individual enterprises know what they need and the type of software applications will become a part of the overall system.

Typical Enterprise Resource Planning involves the following business activities:

• Sales
• Customer Service
• HR
• Accounts/Financing
• Inventory/Distribution
• Procurement
• Production or Service Deliver
• Other Functions

Each enterprise must determine, as a part of its vision, which ERP applications they need – which business functions need to be integrated. This leads to the next important consideration.

Developing the Blueprint

No Enterprise Resource Planning project should begin without all of the “players” involved in developing a blueprint for that development.

This includes each business function leader, the IT department, and the ERP developers, whether in-house or contracted. The Blueprint becomes the master plan, and is in writing.

As a developer, this blueprint determines your path. The modules to be included will be determined and for each module, there will be an ERP application development. Beyond that, the development will include the integration of all of those modules so that the boundaries between functions are softened, and access and communication flows seamlessly.

The Technologies – Hardware

This is where the ERP developers begin their work. During the blueprint stage, the decision is made whether the system will be hosted in-house or cloud-based.

Most enterprises choose a cloud based ERP platform, for the following reasons:

• Especially for small business, cost has to be a consideration. If an in-house solution is chosen, there will be the investment of hardware, servers, and possibly an additional facility.
• Additional IT staff will have to be employed for maintenance of servers.
• Employees have online access to the system from any device.
• Fluctuations in use can be more successfully handled, so that spikes in use are accommodated without slowing things down.
• SaaS systems scale easily when additional users are added as a company grows.
• Cloud providers also provide better security.

Often the first task of a developer is to conduct the research and negotiations with cloud providers and get an agreement that will meet enterprise needs.

The Technologies – ERP Software Development

Now the challenging work begins for the developer. S/he has to make the following happen:

1. Databases Must Be Consolidated: An ERP system has a “super-database”. Developers must consolidate all of an enterprise’s data that is specific to departments into a new database, and it must be tight.
2. Existing Legacy Apps Must Be Integrated: There may very well be canned ERP systems packages, some of which you will use. But there are systems which are very specific to a business that must remain. And that legacy software will have to be re-configured so that it will integrate with canned applications and new applications that will be developed.
3. Master Data Ownership by Department Must Be Made Available to All Users. Thus master data becomes transactional data.

And here are the features which must be built in:

1. Information in a pre-ERP system is passed from person to person. In an ERP model, this function is automatic. The role of the people involved is to ensure that the information being passed along is accurate and timely. The information is not passed in a linear fashion – it is passed in many directions as it is accessed.
2. There will be many interfaces. It is the developer’s job to develop applications that pass information to other systems, not between a database and a user. It means ensuring that all apps, legacy and new, interface with other systems.
3. The ERP system must integrate with other systems. Users will be all over the place with a wide variety of connections. This involves new protocols.

Achieving all of this is accomplished through a hierarchy of architecture – three tiers:

• The Data Tier: These are the databases which must be consolidated.
• The Business Tier: This is the application development – and they are not developed in the traditional sense but rather as components of the larger system that can be moved around endlessly as needed by users.
• The Presentation Level: This is the development phase that allows all of the interfaces which must occur – these will be modular components that can be combined and recombined over a wide spectrum of protocols.

Role of the Developer

Traditionally, developers created apps that stood alone, along with the database tables for each one.

ERP developers have a new role – developing components and becoming a specialist in the components of the tiered architecture, in relationships among database tables, and in the linking and triggering that makes all of these components and tables dynamic.

Other key skills in knowing how to develop ERP software relate to transport and data communication, common protocols, and a good amount of web application technology.

As soon as the decision is made to transition to a web-based ERP system, the developer must identify map out the framework for completing the task. This will involve several projects.

The Platform Revision: There are two possible scenarios that a developer will face:

• The company has made the decision to implement a software system from a major vendor – there will then be canned database table structures and applications.
• The company has decided to craft an environment that will use existing applications and, as well, develop new ones.

In both cases, the job of the developer is one of the configurations. This is going to require careful thought and lots of planning in order to redesign existing enterprise processes. If you have a canned system, you’ll be embedding procedures in those database tables, and configuring application links. On the other hand, if you are developing the environment, you will be writing numerous app components and containers for data transport among tiers.

Database Reconfiguration: this has been addressed somewhat above. One of the best custom ERP tips is to use the myriad of tools now available to you, especially stored procedures and triggers. Otherwise this already complex task will be even more frustrating than it has to be. The other tip is to pay absolute attention to every link’s impact on your table update. You have to be sure in data validity and integrity.

Implementing the Application Environment Driven by Components: You’ll be writing small chunks of code that result in a single operation which must also be useful to several applications. Canned ERP apps typically have a large library. But if you are writing components, another tip is to look at the legacy apps you are re-configuring and see if there are any common elements.

Developing New Interfaces: Protocol is the key. But there are shortcuts as you work through this, especially finding a web service that will convert data for you. And use XML dialects so that documents can be passed in neutral formats.

Use The Tools at Your Disposal

There are probably more tools out there now than a developer will ever need. Here are a few:

Software Packages: Even if a company has decided to purchase a mega cloud-based ERP system, a developer will have a great deal of work to do – all of those things mentioned above, actually. The system will have to be fine-tuned; applications will have to be customized and possibly extended; legacy apps will have to be re-configured; and new interfaces will have to be developed. Mega canned systems always include a package of tools for development tasks.

Check Our ERP Development Environments: If a company has decided against a big ERP package and wants, instead, to re-design its existing systems, on Java (most likely J2EE), then make use of the fact that the technology is open-source and therefore has a huge number of options in those environments, as well as toolkits.

Database Embedded Technology: Today, there is great technology embedded in databases – vendors have a lot of pretty sophisticated options for initiation of processes within that database. So, for example, you may update a database table, and it will automatically trigger updates in other databases. Think of the time saved.

Technology on the Web: Particularly for extending ERP systems, there is a host of tools, including CSS, DOM, and web services.

Cost, Time, Personnel, and Early Errors Must Be Considered

Any business in need of an ERP solution has several things to consider.

1. 1. Cost: There are the upfront costs that everyone factors in. However, there are hidden costs as well. And the cost of training all users must be considered too. In general, smaller businesses can expect it to be in the $50 K price range when all is said and done; larger companies can expect to pay upwards to $150,000+.
   2. Time: Implementation, which is usually layered, can take up to a year. During that year, staff will have to be trained as each module is developed and put into the place. Add to that the continuing training for new employees.
   3. Personnel: Whether a business has the in-house development expertise or must hire developers from without, these costs are quite high. And new hires tend to be permanent because things have to be maintained and updated, and new hires have to be trained.
   4. Blueprint Errors: If errors are made during the blueprint stage, these will come up at some point. They can be costly and delay development and deployment.

If all of this seems overwhelming, understand that it certainly can be. For this reason, many companies make the decision to use an ERP development company. Romexsoft is such a company and, in fact, is a leader in both in-house and cloud based ERP. Through years of experience and acquiring the most expert team in the industry, we are able to provide ERP solutions to companies of any size and any business niche. Our methodology is both logical and customized for any solution, and always involves the following:

• In-depth discussions with our clients to determine needs and operational functions. We work with you to develop the vision and the blueprint.
• During the development process, we deliver each module to you with full training and support. We continue to refine and de-bug each module until it is perfectly operational.
• We provide thorough and effective training and develop training manuals for your IT department.
• We give on-going support as applications must be extended or new apps developed as the life cycle of your business evolves.
• You will find that our costs will ultimately be lower than those you would face by attempting to do this on your own.

Written by Romexsoft on October 26, 2016