Developing cloud-based WMS system for ERP | Blog about ERP | FiduciaSoft

Developing cloud-based WMS system for ERP

Introduction

To initiate a project that can implement a full-fledged WMS and configure it in already existing ERP system sometimes can be very challenging task for many companies. In order to make the right decision, it is not enough just to have an idea about each of these systems. It is necessary to carry out their comparative analysis and apply them to the individual parameters of each particular business and strategic plans for its development. WMS (Warehouse Management System) is a software application designed to control technological operations inside in real time. The WMS usually receives orders from the host ERP system, manages these in a database and delivers them to the connected control systems. In this regard, we would like to share one of our projects that was completed a few years ago. 

While a WMS concentrates mostly on the warehouse, an ERP can automate every process in your company. It’s possible to merge such processes as inventory management, accounting, purchasing, and customer management into one complete system. An ERP has some of the same functions as a WMS, but they aren’t completely the same. It’s possible to monitor the inventory items, and it will provide the information about the details of picking, packages, and shipping. The aim of an ERP is to manage the flow of information between different departments of business. But the ERP system doesn’t  always work well with other programs. That’s why it’s more effective to use more than one software controlling your operations with different vendors. Both a WMS and ERP have strong points needed for the long-term projects. However, a WMS is more adaptable, valuable, and has a better performance.

Task: Creating a stand-alone cloud-based Warehouse Management System (WMS)

The goal of the project was to create a stand-alone cloud-based Warehouse Management System (WMS)  — system that would easily integrate into popular cloud based ERP systems. The initial stage of the product was to integrate with the first WMS system to exchange Sales Orders, Purchase Orders, Inventory, etc. and extend ERP Functionality to mobile devices. This could allow users to use mobile scanners to do basic inventory management transactions that would flow right back into an ERP. This was followed up later on by a second stage: integrating into a second cloud-based ERP system. This was supposed to become a complex system that could be provided as a service to other customers.

First ERP System on the list was NetSuite ERP. In one respect the WMS system could not have a complete feature set. Specifically, it could not have an interface to create Sales / Purchase orders or Inventory Items via the WMS system itself, rather relying on the link with the ERP system, where that data is created. This was a specific client requirement from the very start.

The Team and Technologies that we used

After deciding on .NET for the development platform for both — mobile and web portion of the project and selecting MySQL as a cloud database, client selected team members that would move the project forward. Team consisted of:

  •  project manager
  •  business analytic
  •  web & database engineer
  •  mobile & server side engineer
  •  Team lead
  •  QA Engineer. 

Later, the project team was expanded to two Mobile and Server engineers and two QA Engineers.

First prototype was to be done in 6 months and the first working version of the system was set to be delivered in 12 months. Outside contractor was engaged specifically to extend the NetSuite API for sync purposes, specifically to allow bulk processing of large data sets across two cloud systems. On the hardware side, the system should be supported by the AWS Services for the server side (database and middle tier) and mobile clients would run interchangeably on iOS and Android mobile devices. Middle tier would be a Rest API Service written in .NET that would be scalable via AWS Load balancing.

During the project we used following technologies:

  1. First stage of the project, up to a prototype release, was executed in the waterfall style.
  2. At the insistence of the client, the second stage was to be managed in a mix of agile and waterfall (yes, one of those), allowing customer to have some budgeting visibility and yet allowing them to see the product as it is developed.
  3. In the middle of the project, once the prototype was out, the client found a specific end user site where the first version of the project was to be implemented. End user’s organization had its own requirements for the project which in turn required a large set of change orders.
  4. In the initial stages of the project team was working on the system-level elements.

Security of the service in a multi-tenant environment was paramount, so in addition to the SSL Level encryption, the system of daily-based tokens was devised to ensure that each end user data was stored securely and no cross-pollination of data could possibly occur. 

Development of the project

After 9 months of the project, NetSuite released a brand-new major version of its API’s which client and end-user were insisting on migrating to right away. To accommodate new requirements and keep the project as close to the deadline as possible, the development team had to be expanded with an addition of a middle-tier coder and second QA engineer and the timeline extended by additional 3 months.

The main steps that can be highlighted during the implementation of the project are:

  • Administrative portal was created to allow the customer to easily configure and deploy new tenants as needed.
  • Customer portal was created to allow each tenant (end user) to manage their own configurations as well as monitor transactions in progress.
  • NetSuite plugin with API extension was created by the contractor to establish a link between two systems. 6 months into the project prototype of both portals and link to NetSuite was complete.
  • A prototype of the Android mobile client was created and released into Google Play Store as a beta app.

In this version, the link would ensure that companies, warehouses, Bins, Items, and Item details (i.e. Lot numbers / Serials / UOMs / etc) would stay up-to-date in both systems. Mobile app would allow the first WMS transaction — Inventory transfers — to be performed on the mobile device. Information from WMS would be immediately transferred back to ERP as transactional data.

Project changes and further development progress

After the prototype was released, the client brought onboard a first end user for the service, a company that would become a first tenant on the service. The idea was that this organization would become a beta tester for the system when it became available. End user insisted that they needed to immediately implement a physical count transaction, which was not originally in the project plan. Additionally, this tenant’s organization needed a label printing solution that was outside of the scope of this stage of the project.

Finally, sales order functionality had to be expanded right away to support both, sales kits and Inventory kits: again, something outside of the project scope. Because the client gave end user broad promises, the budget and timeline for the project was revised and additional resources were brought onboard. The only part of the project that did not need to change and stayed exactly according to the initial plan was administrative and client portals.

It was conducted the post initial prototype, project plan called for developing transaction at a time. Dev team developed functionality and passed it to QA Team to test, while in turn developing the next item on the list. Any items that were found in testing had been discussed in a short daily meeting and were rotated back into development if needed. 

Conclusion

Overall, a new “beta” release was produced every 5 weeks, which allowed end users to work on testing the system in their beta environment. This was a deviation from a traditional waterfall model, bringing elements of the agile development into the project delivery model. Even though the project was planned in exactly that manner, this was the most difficult part to manage — running agile-like project while avoiding scope creep. In general, the project was delivered in the revised 15 months timeline and within the revised budget, to the satisfaction of the client. Due to unrelated marketplace conditions, this system never became the de facto WMS system for NetSuite ERP, but instead was quickly re-integrated into another cloud ERP system. That project, though, will become its own post in the near future.


We hope you enjoyed this case. Subscribe to our pages on LinkedinTwitterFacebook. There we publish information about our cases and relevant news.

If you have additional questions about this case or you have similar requests, feel free to contact us!