Green’s Winds Back ERP Modifications with LANSA’s BPI Solution

In order to make a packaged ERP solution suitable to a company’s way of doing business and to interface it with other systems, it is often unavoidable to make modifications. Moreover, it is often in the gaps created by these generic ERP systems where the real opportunities to innovate and gain competitive advantage exist. But over time, these modifications can also be a burden, especially when they are developed in hard-to-maintain or error-prone code. Many IT departments find that they are spending most of their time maintaining these modifications and interfaces.

Green’s General Foods (Green’s) found a way to wind back their RPG-developed ERP modifications without losing any custom functionality. Over 150 RPG programs have been replaced with LANSA’s Business Process Integration solution and custom processing is now managed by a business analyst, rather than a developer.

• More than just Middleware
• The Evaluation Process
• The Project
• The Benefits
• Conclusion
• Company and System Information

More than just Middleware

Green’s General Foods, based in Australia, produces and distributes food products, such as baking and pancake mixes, crackers, muesli, oats, popcorn, maple syrup, toppings and gravy. Brand names include Green’s, Lowan, Poppin, Waterthins and the gluten free range Basco.

Green’s IT environment consists of BPCS 8.0 as its main ERP system (called Infor-LX since version 8.3) supplemented by over 30 other systems that include Paperless (a Windows-based Warehouse Management System) and EDI Server (Windows-based EDI software from GXS/Inovis).

Anish Mathur, a Senior Business Analyst who joined Green’s in 2011, explains “Up until recently all the interfaces between BPCS and the other systems were custom developed RPG programs. We had many business rules embedded in those programs which were, unless you had very good documentation, only visible to a programmer. We wanted to move away from that way of doing things, as we had a lot of issues in supporting the various interfaces.”

“We needed more than just a technical middleware tool and were looking for a Business Process Management (BPM) solution. Something that would allow a business analyst to configure our business rules and orchestrate our business process, rather than having to write programs to do that. We wanted to make better use of our BPCS ERP system by moving the modifications outside the ERP and come back to a BPCS implementation with minimal custom developments.

We needed more than just a technical middleware tool and were looking for a BPM solution.

The Evaluation Process

Green’s looked at several middleware and BPM solutions. Anish was initially keen on TIBCO and MS BizTalk, because he already had experience with those products when working at other companies. “But the bigger more complex BPM tools weren’t really suitable, because of the amount of investment both in terms of licensing cost and in terms of what it would mean to learn, implement and support the tools. We only have a team of four, including help desk support. We want to keep our team small and were looking for a practical tool, something that could be managed by a small team, or even by a single business analyst,” says Anish.

LANSA Composer was one of the evaluated tools and was invited to complete a Proof of Concept (POC). Simplified for this case study, the POC consisted of:

• Pulling picking confirmations from the Windows-based Warehouse Management System.
• Applying validation rules on order-quantity and available inventory. Send an alert on fail and continue on pass.
• Triggering billing in BPCS and send the generated Invoice to the EDI server.

Those familiar with BPCS will know that it contains an ECM (Electronic Commerce Management) module to automate the import and processing of transactions that originate from outside the system, as well as to automate the export of transactions to other systems. But the ECM module doesn’t offer a way to automatically launch the Billing process. The only way to initiate BPCS billing is to type the order number into a BPCS screen.

This is where another LANSA product could fill the gap. aXes-Robot is an API (application programming interface) that allows applications to automatically operate 5250 screen-based programs, such as RPG or COBOL developed programs. aXes-Robot basically simulates the actions of a data entry person, making it possible to integrate 5250 applications with .NET, Java and other applications.

In Green’s POC, after LANSA Composer has pulled the picking confirmations from the Warehouse Management System, it extracts the order number from the confirmation, calls aXes-Robot and instructs it to navigate to a particular BPCS screen, type the provided order number and submit the screen to initiate the standard BPCS billing process.

“The LANSA Composer and aXes combination turned out to be a very good solution for us. Composer does the orchestration and contains the business rules and smartness, while aXes-Robot helped us with ‘the last mile’ of integration that would otherwise have meant that we needed to continue develop custom programs,” explains Anish.

The bigger BPM tools weren’t suitable, because of amount of investment in licensing cost and implementation effort.

The Project

Green’s went ahead with the LANSA Composer and aXes-Robot combination and decided to first tackle the six interfaces that were causing the most grief. In these six interfaces there were more than 150 custom RPG programs involved:

• Pull EDI orders from the GXS EDI server to the IBM i and transform them to a format that the ERP system can process.
• Trigger ERP processes to generate order acknowledgements and send those acknowledgements to the EDI server.
• Trigger ERP processes to generate pickslips and send those pickslips to the Warehouse Management System.
• Pull picking confirmations from the Warehouse Management System and send them to the ERP system to trigger the ERP inventory adjustment process.
• Based on the same picking confirmations prepare orders for billing, initiate the ERP Billing process to generate invoices and then send those e- invoices to the EDI server.
• Pull the ASNs (Advanced Shipping Notifications) from the Warehouse Management System to the IBM i. Then for each ASN find and update the matching Order in the ERP system and check that the billing has completed. The ASNs are then updated with ERP invoice information and sent to the EDI server.

As already explained in the previous section of this case study, aXes-Robot played an important role in automating Green’s billing process. Previously Green’s was using custom-developed RPG programs to automate the billing process, duplicating complex business rules and creating a maintenance headache. Being able to use the standard BPCS billing programs in an automated way, removed the need for tens of custom programs.

The standard ECM functionality was also not sophisticated enough to cater for conditional order adjustments. If there isn’t enough stock to fulfil an order either the quantity of the order line needs to be reduced or the order-line needs to be cancelled. And if the cancelled line was the only line in the order, the whole order needs to be cancelled. These validations are now done in Composer, which then calls aXes-Robot to navigate to a standard BPCS screen to make the appropriate order adjustments.

“By putting the rules and validations in Composer and filling the data-entry gaps with aXes-Robot, we were able to remove the need for many custom programs,” says Anish.

aXes was also used to execute ‘batch allocations’, mimicking what a data entry person would do to allocate inventory to an order. This reduced the need for BPCS custom programs to facilitate this functionality.

By putting the rules in LANSA Composer and filling the data-entry gaps with aXes-Robot, we were able to remove the need for many custom programs.

The Benefits

“Our ERP system is quite robust, if you use it in the standard way. The problems start when you make too many modifications, because you end up having complex business rules duplicated and embedded in hard to maintain programs. We replaced over 150 custom RPG programs by putting the smartness in LANSA Composer and having it trigger the standard ERP processes, with the help of aXes-Robot where needed,” says Anish.

Anish found the learning curve short and both products easy to use. “We had given ourselves six months for this project, but after I spent two days together with a LANSA Consultant on automating the first few processes, I was able to rather quickly design and create the rest of the processes. Most of the work was done in about two to three months and we then had the luxury to deploy parallel testing for the remaining three to four months.”

“Some of the old custom programs were of poor quality, resulting in all kinds of issues and time-consuming fixes. Records would get locked, inventory updates would go wrong, trucks would queue up in the morning, because we were having delays getting the invoices and ASNs out. We would sometimes spend hours fixing things. These programs needed a lot of maintenance and corrective action,” continues Anish.

“By running in parallel for several months we were able to test the system in scenarios that we otherwise would never have anticipated. We established beyond any doubt that those problems and issues had disappeared in the new environment. So we were extremely confident going live with the new solution. We knew the project was a success.”

Most of the work was done in two months and we then had the luxury to deploy parallel testing for the remaining four months.

Conclusion

It’s not always easy to calculate the ROI on a software investment, but in this case the benefits are very clear. “If we had to re-write the RPG interfaces from scratch, I estimate we would be looking at something like $60,000 to $100,000 and at least seven man-months. And although the new programs would be of better quality than the old RPG programs, fundamentally we would end up in a similarly heavily customized and difficult to upgrade ERP environment,” explains Anish.

“We evaluated other more complex middleware/BPM products and the cost of implementation would have been at least double as compared to the solution we implemented with LANSA Composer”, says Anish.

“To us LANSA Composer is far more than just middleware that transports files from A to B. We can actually build rules into it. It’s a true BPM solution. With Composer, the business rules are more visible and if the business changes, I can very quickly change the rules. There is no programming or compiling involved. And aXes-Robot fills the last-mile data-entry gaps between the various tools and solution,” concludes Anish.

With Composer, the business rules are more visible and I can very quickly change them. There is no programming or compiling involved.

Company and System Information

• Green’s General Foods produce and distribute food products under brand names of Green’s (Baking, Maple Syrup, Pancakes & Topping and Gravy), Lowan (muesli and oats), Poppin (popcorn), Basco (gluten free),Waterthins ( crackers, twists, lavosh etc),Lolly Gobble Bliss Bombs (an old time favourite) and Paradise biscuits and cookies)
• Green’s uses BPCS version 8.0 and an IBM model P7/E4C
• For more information visit: www.greens.com.au