Tuesday, August 03, 2010
Ouch! Retrofitting a Partial OO program
The program uses classes but all methods were public and variables were global. It uses objects for the UI components (CL_GUI_ALV_GRID) and uses one massive class for data build full of public methods.
There was sufficient value in the UI components and data build. I really did not want to reinvent the wheel so I left it. It's the record processing components that we wanted to update. There was an issue because it was tightly integrated with the data build.
Good thing the data build logic is fairly simple.
Once I've taken out the old record processing components, I put breakpoints where update method calls need to happen. I tested that the program calls are is still consistent.
The data build contained business rule validations that needed to remain.The mechanical process of building a persistent class for update purposes was pretty easy. But the use of a new update object also need to ensure validations still work. The data which are now encapsulated in persistent objects were also used in the validations so they have to be re-thought.
I really should have known but what was experienced painfully first hand is that retrofitting partial oo programs is hard work. What I believed to be easy turned out to be massive because pre-existing logic have to be revisited every step of the way. An effective regression test of the whole program had to happen.
Thursday, May 27, 2010
Taking Stock - an RF Solution implemented 4 years ago
It’s actually interesting to look back at the amount of uncertainty in the beginning of the project and what has happened at the end of it.
Among a whole host of SAP environment questions : there were issues around what sort of RF gun availability, physical networks on sites, label printer availability, warehouse management solution, specifications, ownership, testing criteria. This is typical for projects really. But for me then, it was really daunting as the uncertainty about who has to use them and what expectations they had was quite a big issue for me. The technical requirements are quite simple, but understanding the conditions that users really face was quite abstract. That brings about a whole host of issues.
The whole thing turned out well in the end thanks to solution management by the implementation team. They did quite well to manage teething issues and address site expectations.
- I learned a couple of things back then.
Simple is better. The smaller screen prohibits some interactivity that’s normally available in the large screen. Plant and Warehouse people just wants simple interfaces ‘something that will scan, job done’. - Some companies prefer third-party products to talk to SAP because the SAP-user licensing costs can become significant. Be prepared for maintenance on third-party products though. When third party products are installed, the solution may be simpler to develop, but there is a maintenance penalty as the components and servers need to be maintained separately.
- Separation of back-end and front-end was implied in the architecture. This means that the ‘separation of concerns’ in a model-view-controller development methodology is inherent in the process. This had some positive effect on the development, testing and support processes.
Looking back at it now there was only one thing I would have preferred - that we installed thermal printing on SAP via Smartforms+Zebra rather than on the third party product.
Oh well, you can’t win it all the time. :)
Process Improvement Quick Wins - Label Scanning and Test Recording
It is quite rewarding whenever I encounter cases where a ‘relatively’ small effort gives high return. One of my measures of ‘high return’ considers how high up a customer’s smile goes to. After all, the whole point in being a consultant is to provide technical knowledge for customers so that they can improve their own processes.
PILOT PROJECT
I am involved in pilot project to deliver a replacement quality management system with SAP. One half of the technical requirement is involved in interfacing with milk testing machines. The other half, which I'm involved in, relates to label printing and user test results recording.
The old process involves manually invoking printout to a label printer that prints out a sample number. The sample number then becomes a reference but has to be keyed in individual systems manually. This has issues relating to manual management of labels and keying errors related to managing samples.
PROCESS IMPROVEMENT
In order to improve the process, a few things needed to be done. I sourced a new printer to talk to SAP so that a new label is printed from SAP as soon as an inspection process is triggered.
I also built a new label with a barcode intended for scanning applications. The label set print includes information on who and when the printouts were created.
Now, the standard transaction requires navigation through a number of screens just to record test information. (For technical reasons, it is possible to configure multiple tests in SAP against a sample, but this is not in use for this case). The screen navigation adds unnecessary complexity to the work-flow, so I created a new transaction to directly navigate to the test result recording from a sample number.
The main benefits of all these to the Quality Management Process are improvements in print management and test entry automation. Users don’t have to read and type in samples. They just have to scan it to record test results.
THE REWARD
When the process was shown to a business representative, she beamed. She was shown the inspection process trigger, label printing, scan and new transaction.“It’s official. This is better than what we used to have”, she said.
I should note that this is yet to be rolled out. Much still has to be done to ensure technology adoption. I'll let you know. :)