An earlier post on ‘Enhancing Values’ talked about some simple ways of enhancing the value of custom-made software. This post is also on the question of enhancing the value delivered by a software solution, with a slightly different perspective.
Projects involving development of custom-software are especially great opportunities to deliver significant and special punch for the business; something an off-the-shelf software solution often falls short trying to address the needs of the widest cross-section of customers with the commonest capabilities.
These opportunities are not readily served at the table – they need to be excavated. The efforts get handsomely rewarded when the business gains in real from exercising the punch.
Very recently there is an interesting experience of this kind illustrating the point being made.
The organization is into manufacturing or sourcing basic equipment and executing infrastructure projects using the same. It is rolling out ERP for the whole enterprise. In the pre-sales phase, the marketing function receives the requirements from the customer. It responds with a design that includes the specs of major equipments. When the customer order is received, these go as inputs to the R & D. R & D prepares the engineering drawing using a PLM solution, prepares the BOM and triggers other processes in procurement, manufacturing and contracting functions.
The PLM and the ERP are not tightly integrated. The PLM generates a BOM for a drawing. The Codes for the Items in the BOM would have to be appended manually before the completed BOM could be uploaded into the ERP.
A simple application was needed to close this process gap.
The requirements were outlines as: the BOM would be imported into the application and would be processed for all Items contained in the BOM. For each Item in the BOM, the application would search its database (the Item Master would be periodically downloaded from the ERP; a real-time interface was not envisaged) and would produce a standard Code for the Item by matching the attributes specified for the Item in the BOM against the Item Master. For example, an electric motor may have its type, horse-power, number of poles, etc. specified as attributes. These would be used to obtain a match in the Item Master and retrieve the Code for the standard Item. For sheet-metal Items, the set of attributes was different. Once all Item Codes are appended, the BOM would be exported in a suitable format. This would be uploaded into the ERP by the ERP Support Cell. The process is complete with the filled-up BOM available for all down-stream processes.
Continuing with the requirements: The exception handling was a little more involved – when there was no match and the Item was new. New Item Codes are created in the ERP by a designated member in the ERP Support Cell. He sits a few tables away from the R & D section. How he creates new Item Codes is known to R & D. So the R & D takes it upon itself to design a Code for the new Item using his logic and send it to him as its recommendation along with a duly filled-in indent for creating this new Item in the ERP. In the meanwhile, assuming the new Item Code would be created in the ERP, R & D completed its BOM with standard and recommended new Item Codes and exported the BOM ready for import into the ERP.
Taking the simpler issue first: The last part of the requirements needed to be cleaned up. The process of R & D designing a new Item Code and proactively exporting the BOM with these new Codes plugged in is error-prone and hence cut out. In the revised wrinkle-free process, the R & D merely forwards its indent for a new Item Code to the member in the ERP Support Cell and waits for him to create the new Item and download it for this application. In the second run, the application will find now the Item Code. In this way the logic for creating a new Item Code could change independently without any impact. Of course, now it means that the BOM cannot be completed until the process of creating the Code and downloading the Item Master is completed. Multiple iterations could be avoided if in the first run itself, a consolidated indent for all new Items is generated to be processed by the ERP Support Cell in one shot. In this revised process all Codes are assigned by the application without any manual step.
Now to the nub: The requirements even at this stage miss an important business opportunity – is it not possible to negotiate on the BOM? After all, the BOM made up for over 70% of the total cost. Any savings on the BOM cost would reflect significantly on the last line. For every Item in the BOM, match or no match, there could be opportunities for a) substituting one Item by a cheaper equivalent b) use a similar Item (may not be an exact match) readily available in stock c) use a similar Item (may not be an exact match) from a more reliable supplier etc. etc.
When this important possibility was pointed out, user expressed legitimate fears of abuse of the negotiation capability to cut corners compromising quality for the customer. Negotiation on the BOM need not always mean dilution of specifications or quality. There could be genuine opportunities to affect some savings. The kinds of permissible negotiation and approval levels may be specified to guard against abuses. The second objection was: the equipment specs are laid down and costed by the customer-facing marketing function as part of its solution to meet the customer’s needs and hence are not negotiable. While this may be true, it is quite possible that certain attributes of an Item are non-negotiable while the other attributes are, leading to a few possibilities.
The user is still not very convinced about negotiating the BOM, but has promised to give it a deeper thought. If the user finally finds legitimate room for negotiation, the implication for the application is that it would be required to present a palette of exact (if there is one) and approximate matches when the Item Master is searched using a set of attributes. It could also indicate the impact of making a specific choice from available alternatives. It may also mean that the application may have to be aware of many other things like Work-In-Progress, etc. when it performs the search.
An analyst must tirelessly strive for providing in the software solution aggressive support to business objectives when he is engaged in the process of collecting requirements. A feel for the business domain certainly helps. Anything short is a missed opportunity!
Tags: Business Objectives, CIO, IT, Project, Value, Value Enhancers
