Merce

A bespoke ERP system
  • Summary

    Industry Trading / distribution

    Client One of India's top five distributors of electrical components. Operations in six states. Twelve warehouses and branch offices. Fifty years old, family owned, owner managed. HQ in Lohar Chawl, Mumbai.

    Requirement The growth of the business required tight management of inventory, fast responses to customer requirements, operating out of multiple locations and tightly monitored from one HQ. This required a bespoke business automation system which would mirror the flexibilities needed in their real-life business processes, but would be browser based and would be accessed from all branches and godowns.

  • Our solution

    Existing systems The company had built a set of bespoke applications using Foxpro and Clipper over a period of two decades, by employing a team of 2-3 experienced programmers. The specifications were created and modified by the head of the firm as per his personal understanding of his business processes, and each MIS report was tuned over many years to indicate a lot of information against each row by using special tags and icons. These applications operated at the HO over the office LAN and were used by about 20-25 users. The godowns and branches did not have any custom-built software; they used Tally for financial accounting.

    Business benefits The primary aims of building a new business application were:

    • Multi-site access: The new system needed to be accessible from all branches and warehouses in addition to the HO, so that the most current accounting and stocks positions could be seen from all locations in real time
    • Stock movement: With the old system there was no way to monitor stocks of all locations from all other locations. With the new system, this was one objective, so that stocks could be moved between branches and godowns on demand.
    • Rapid response: By maintaining all stock positions current in real time, customer inquiries about stocks and delivery times should be responded to accurately and instantly.
    • Tracking dispatches: Since all godowns must update goods movement online in the new system, all tracking of actual goods shipped could be done at HO without inquiring about any dispatch status by contacting personnel at those sites.

    These are fairly typical of the business benefits of a comprehensive business information system for a multi-location organisation. It is very rare is for an Indian family-owned, owner-managed business to invest in such systems.

    Project process For this project, the customer recruited a team of developers and we provided a team of equal strength from our company. This joint team of developers were trained in the development process and tools. In parallel, the specifications of the system were captured by our business analysts from inputs directly given by the owner of the firm and his existing senior software engineer. The owner gave a lot of his time for sharing business specs with our team. Development project management was entrusted to us, and the joint team undertook the development at the customer's HO in Lohar Chawl, South Mumbai, where space was created for the dev team. Arrangements were made to keep the office open beyond the normal business hours of the firm to allow the dev team to work late hours.

    The specs capture process took about three months and the coding and testing took about 12 months. Some group collaboration and peer review was enforced to attempt to minimise the impact of developers quitting and being replaced by new members. Agile development processes would have been the ideal approach for this project, but were not followed because we were not aware of them at the time. The composite team was almost 20 developers at some points in the project. After the initial 12-13 month development period, our team moved out of the project and the remaining development and maintenance was continued by the in-house team, as had been originally intended.

    The project was structured in a composite model, with the initial specs capture and design phase as a fixed-priced assignment and the development phase being taken up as a T&M project.

    Technologies The system was implemented in Java servlets, with a Java/Perl library for template patching. The database was Oracle Standard Edition. The system operated on 32-bit Linux OS, with Apache and Tomcat. A pair of servers in tower cabinets were set up as the core hardware for the system.

    Minimal Javascript was used in the UI. This is a reflection on our team's concerns about the relative instability of Javascript implementations of the time and their browser-dependent idiosyncracies. Care was taken to design the UI to permit users to open multiple browser windows and perform multiple operations asynchronously, since we discovered that most executives worked in a non-linear and multi-tasking manner at their desks and needed this behaviour fronm the system.

    There were 74 master tables in the system. We built a generic master maintenance (GMM) module in Java which allowed us to generate automatic modules for the usual add/edit/delete/authorise functions of master table records without writing any code. Once the GMM module was built and tested, 71 out of the 74 master tables were maintained using its generated modules without any code being written. The remaining three master tables could not be managed this way because they had cross-table references and master-detail relationships in their information structure, while our GMM handled only standalone master tables. For these three tables, maintenance modules were written in the conventional way.

    Deployment This was done bit by bit at HO, by running extended parallel runs of modules as they got ready, while development of other modules continued. In order to operate a composite system with part of the modules in the legacy system and part in the new system, tools were developed for batch data movement back and forth at each BOD/EOD.

    The system was initially used at HO for many months before being extended to the other locations, to minimise end-user support overheads if unstable systems were deployed to remote locations. All locations had to connect to the HO over the Internet, therefore the quality of Internet connections at all locations became a key pre-requisite. In 2001, the quality of Internet connections at most Tier 2 and Tier 3 cities and towns in India was problematic.

    Since the customer did not have any Linux/Unix/Oracle background, we set up the deployment stack for them, configured the database, and provided a first level of training in system and database maintenance, starting with OS troubleshooting and including hand-correcting of database records from the SQL prompt. This helped the legacy Foxpro team migrate their knowledge to the new system effectively.

RELATED READING