Martin Hilmersson
As a result, we see a balanced record and an updated manufacturing order, and updates to the transaction history and financial events.
Most of the time, implementation projects are extremely focused on these kinds of transactional outputs, with little thought given to the process’s usability. We typically use issue lists and focus only on the most challenging processes, which makes sense when the goal is to put a new working system in place using limited resources. But recent M3 development has introduced tools that enable excellent, tailored process support. And truth to be told, these tools are often overlooked.
But why not develop these 2 fancy things after the initial project is finished?
That might be a viable strategy, but I’d like to point out a couple of key challenges:
1. There’s more to this than just the fancy stuff like coloring, links, etc. We’re talking about major differences in operation requiring dedicated testing, education, and more.
2. Retention of competencies from the initial project also needs to be considered. Are we confident that the people involved, both consultants and staff, will still be available once the initial project is closed?
These challenges can, of course, be mitigated to some extent, but I still think we need to be better at incorporating these new tools directly into the original design. This might come at the cost of an increased budget, but in my opinion, it’s more than worth it.
Example: Reporting of Goods receiving
Let’s use an example of a process which most M3 customers use, reporting of goods receiving.
I know many M3 customers today use various mobility tools and shipment advice in the goods receiving process. Naturally, this changes the process considerably, and the following might not be applicable out-of-the-box. But it should serve well enough as an example of the difference between using new tools and not.
Traditional goods receiving in Infor M3:
The reporting of goods receiving is basically done by three different M3-programs (or their corresponding API transactions). Which of these programs is used, and in what order, is decided by parameters in M3. Each program is started independently, and the input value is typed in manually.
- PPS300 – Goods Receiving
Initial reporting of goods that have arrived. Typically, the input used is a purchase order number or item number. This info is supplied by the supplier and taken from the documentation that came with the goods. Once receipt of goods is reported, a receiving number is created to enable further reporting if necessary. - PPS310 Quality Inspection
The receiving number (identified typically in printed documents) is used to report the result of a quality inspection. - PPS320 Put Away
Again, we can use this program to place the approved goods in the warehouse’s selected location alongside the receiving number.
The standard setup of goods receiving has, in my opinion, two key shortcomings:
1. The dependency on printed information, both concerning the purchase number from the supplier and the internal receiving number.
2. The difficulty for staff involved in using M3 to identify work in progress. Staff will need competency across many programs and must interpret various statuses to maintain full control of the process.
Goods receiving using new Infor M3 tools:
Instead of relying on printed documents, we should be able to make M3 work for us!
The idea is to create a single list program where all expected and ongoing transactions are displayed, with a clear signal of the next step in the process and a link to guide the user there.
A new list program can be built with standard tools only. Here’s a short description:
- The version of M3 is 13.4, and the user interface is H5 (relevant also for older tech).
- The list shows purchase order lines and sorts by warehouse and expected delivery date.
- In case quality inspection or putaway is called for, the receiving number is retrieved.
- To guide the user, the ACTION-column will tell them what the next activity should be. It also provides a dynamic link to start the appropriate program (PPS300, -310, -320), with the corresponding purchase order line or receiving number initiated.
NOTE: the system prompts us to the next step rather than giving information only about the current stage!
- Information such as responsible buyer is included and a phone number in case any issues need to be sorted out.
- A filter is applied to ‘status’ to show only relevant records.
Again, what’s important here isn’t this specific functionality. It’s how new, generic M3 functionality can fundamentally change business processes for the better.
The functionality used is as follows:
- Information Category (CMS010) is constructed with related tables.
- Serially connected virtual fields (numerical & formulas) are used to calculate columns ‘QTY’ and ‘ACTION.’
- Link Manager contains mforms-scripts which dynamically start programs with the correct input.
- Conditional Styles, based on the value in column ‘ACTION’, enable hyperlinks relating to Link Manager.
- Bookmark is used to enable initiation of the list as a regular M3-program.
Summary
Using ACTION-columns like those I described above is a powerful way to make the system work for you by guiding the user through each step of the process. This isn’t easy to accomplish in an out-of-the-box ERP because of the variation of processes.
In my personal opinion, most M3 customers can benefit from taking advantage of the kind of generic functionality I’ve talked about above. However, many aren’t currently aware of the potential of such features. It’s up to business consultants with broad competencies to span the gap between business practices and M3 technology to highlight the possibilities.
It isn’t enough, to my mind at least, to call in expertise AFTER a new system is up and running. At that point, it’s already too late – no system developer can work magic, no matter how well they know their stuff. The best work is done upfront, during the initial project, and not after go-live.
We now have the tools to put M3 to work for YOU – so let’s use them
