From Green Screens To Web Services: An ROI Story
February 8, 2016 Dan Burger
There are times when we find ourselves in the wrong place, but it turns out to be the right time. Les Peebles can tell you about that. During a presentation on webfacing 5250 screens, a technology that Peebles was not in favor of implementing, he was introduced to a web services option that came to be a solution to the IBM i and Windows integration issues he was grappling with. The wrong place was now the right place.
Peebles began his IT career as an RPG developer. In the years that followed, he learned Java and web development. He also got into PCs, networking, and a variety of technologies and languages. He learned to create web services using Java and WebSphere. The Java web services ran on a Windows server and accessed data on IBM i.
When he discovered looksoftware‘s Newlook suite of products included a web services tool that’s used within an application to bypass 5250 navigation and construct a link between any two screens, Peebles saw the opportunity to simplify workflows and increase user productivity.
“The ROI (return on investment) for webfacing was not there. But there was absolutely an ROI on web services because we can greatly reduce the labor of people using the web services,” Peebles explained during a phone interview with IT Jungle last week. “The looksoftware tools provide the capability to interface with that program. We needed to auto-invoice hundreds of existing orders per day in our RPG-based transportation system using invoice data obtained from our SQL Server. The original process had our invoicing department opening a daily spreadsheet of orders/invoice data, retrieving the order on the 5250 screen, and type in the invoicing data.”
The heads-down data entry required four hours of time each day. It took two web services to eliminate that manual labor and replace it with automated features. The person who used to open a 5250 screen and do data processing for four hours a day now opens a .NET application and starts an automatic process. That person can then take on other tasks that contribute to workflow efficiency and revenue-generating tasks.
Peebles and the manager of the department that benefited from the labor savings worked together to determine the ROI.
“We didn’t put a stop watch on anyone, but we had fairly accurate estimates on how long certain actions take. We can see how much data we are pushing through,” Peebles says.
According to their computations, the ROI would take less than a year. That information was delivered to executive management before the project got the green light.
A second reason for creating web services from 5250 applications was industry specific. Peebles’ employer, Challenger Motor Freight, is a transportation company with its core systems dependent on green-screen user interfaces.
The logistics division purchased a cloud-based transportation system for managing the lifecycle of customer orders. The system is considered excellent from the operational perspective, but somewhat weak in regard to accounts receivable and general ledger interfaces and access to the backend database.
The original process that was targeted for improved efficiency involved paper invoices that required hand processing to enter the data into the core transportation system. In the core system, a manual order would be created and then invoiced. The data would follow the existing integration paths into AR and the GL.
On average, the manual process required 140 seconds. It was also prone to errors during the data entry process. After the web service was created, the time to process was an average of 2 seconds and data quality issues are eliminated.
As part of the purchase, which included Newlook, Newlook Server, and the web services tool, Challenger bought a proof of concept, which was fulfilled by looksoftware, a division of Fresche Legacy.
“That proof of concept code gave us a really good start,” Peebles says. “It didn’t get us to production, but it provided a great framework for understanding how to get an app to production. We also purchased training that focused on how to develop using the looksoftware tools.”
The training consisted of two hours once a week for six weeks. At the end of the training the proof of concept code was complete. Afterward, Peebles devoted a couple of weeks to learning, understanding and modifying the code before putting it into production.
Because the business logic is locked into the RPG programs, it’s a simpler web services project than the web services he writes using Java. When he uses Java, he has to know the nuts and bolts of updating files, fields, and relationships between tables. That’s all taken care of in the existing 5250 apps, but you still have to grasp how to interact with the 5250 screens.
“I have always been drawn into integration projects,” Peebles says. “I find it an interesting challenge trying to get various software systems to work together.”