Developing cloud-based WMS system for ERP

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.

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.

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.

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.

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.