For a software vendor that has multiple software products up for sale one of the key challenges it faces is the development of new products and enhancement of existing products keeping in view the fitment of the new development or enhancement in the existing portfolio of products.
Say for example a software vendor has each software products for merchandising system, price management system (PMS) ,forecasting, replenishment and merchandise financial planning(MFP). It aims now to develop new products for promotions optimization(PO) , markdown optimization(MDO) and buying and assortment planning(BAM). Each of the three new products can be developed parallelly and separately. However one of the key points to consider before doing a development of the new products would be to consider the integration development that might be required to ensure that the new products intergate perfectly with the exisitng products. For example in the case mentioned above the MFP tool should integrate perfectly with the BAM tool and simillarly the PMS should integrate well with the new MDO and PO tool.
The basic fact is that most software products dont work independently, software products need to interact with and most of the time highly dependent on other software products for complete functioning of the end to end solution comprising many software products.
For the case above replenishment tool is dependent of the forecasting tool to get the forecast based on which it can generate demand driven replenishment stock quantities. Similarly the BAM tool will depend on the MFP tool for a class level sale speed factor to calculate the assortment quantities.
Now lets understand the development or enhancement of an exisiting product to add additional/new functionalities in it. Say for example the PMS tool mentioned above is not suited for an Indian retailer as the product doesnt support the functionality of maximum retail price (MRP) of Indian retailing. This calls for enhancing the PMS tool around the MRP requirement. However the point to consider here is that the alone enhancing the PMS tool will not be sufficient; as other tools such as the PO and MDO tool might require the MRP fucntionality and might require the MRP related data from the PMS tool. In this case the impact of introducing the MRP fucntionality in PMS tool on MDO and PO and maybe other tools need to be analyzed.
In either case; that of new product development or that of enhancement of exisitng products; the impact of integration touch points across the products needs to be anaylzed very clearly.
In the traditional approach of developing software products; the products are developed standalone while keeping in view only the basic intergation touch point with other software products. Not much investment is done in trying to analyze the impact of the integration development being done for the new or exisitng products to the other product. Say for example the integration method chosen by the PO tool development team to integrate the PO tool to PMS for a particular data flow from PO to PMS is a method that might not be supported by PMS and might require lot many modifications in PMS to accomodate it to this integration method. The effort to now modify PMS to integrate it with PO might be lot and this effort estimation might come as a sudden suprise for the PMS team. Also it might just happen that the integration of PO and PMS could have been done using a simpler and a cheaper and more stable method. The reason that this scenario might happen is that proper and indepth analysis of exisitng integration architecture of PMS and the analysis of effort and quality estimation between the integration modifications that might be required in PO to integrate it with PMS vs integration modifications that might be required in PMS to integrate it with PO was not done. Each of the development teams of PMS and PO missed out the wholistic picture and were focussed in developing/enhancing their individual products. This calls for an integrated product development approach.
Integrated product development methodology calls for individual develpoment teams to work in close cohesion and interaction with each other to have a bigger view of an intergrated product suite and then understand the impact of a development/ enhancement of one product on the other products. In doing so the best approach of development/enhancement method and clearer effort estimation is available. This leads to a far more robust integration in a shorter time period than if each of the development teams works seperately and then the finer details of intergation are thrased out. Say for example for the case given above the PMS development team will work closely with the PO and MDO development teams to understand the complete integrated solution of PMS-MDO-PO. The entire team comprising the MDO , PO and PMS developemnt teams would analyze the best approach for developing/enahancing the three products based on the integration touch points between the products to have a stable and effcient intergated solution rather than efficient stand alone products but inefficent when integrated.
Summary:
Software products dont run independently. They need to interact with each other for complete functioning of the solution comprising the software products. Hence integration of the products become a very cruical aspect of the proper and efficient working of the products.
In Traditional Product Development the development teams work separately. There is a limited interaction among the development teams. The individual teams miss the bigger integrated picture. Hence the chances of additional developments that might be required for a complete integrated solution and hence the chances of additional developements and chances of an inefficient integration run high. This in turns leads to longer lead time to deliver an integrated solution.
In integrated product development methodologhy the individual development teams in close interaction with each other to have a bigger view of an intergrated product suite. Hence they understand the impact of a development/ enhancement of one product on the other products better and thus the best approach of development/enhancement method and clearer effort estimation is available. This leads to a far more robust integration in a shorter time period.
Say for example a software vendor has each software products for merchandising system, price management system (PMS) ,forecasting, replenishment and merchandise financial planning(MFP). It aims now to develop new products for promotions optimization(PO) , markdown optimization(MDO) and buying and assortment planning(BAM). Each of the three new products can be developed parallelly and separately. However one of the key points to consider before doing a development of the new products would be to consider the integration development that might be required to ensure that the new products intergate perfectly with the exisitng products. For example in the case mentioned above the MFP tool should integrate perfectly with the BAM tool and simillarly the PMS should integrate well with the new MDO and PO tool.
The basic fact is that most software products dont work independently, software products need to interact with and most of the time highly dependent on other software products for complete functioning of the end to end solution comprising many software products.
For the case above replenishment tool is dependent of the forecasting tool to get the forecast based on which it can generate demand driven replenishment stock quantities. Similarly the BAM tool will depend on the MFP tool for a class level sale speed factor to calculate the assortment quantities.
Now lets understand the development or enhancement of an exisiting product to add additional/new functionalities in it. Say for example the PMS tool mentioned above is not suited for an Indian retailer as the product doesnt support the functionality of maximum retail price (MRP) of Indian retailing. This calls for enhancing the PMS tool around the MRP requirement. However the point to consider here is that the alone enhancing the PMS tool will not be sufficient; as other tools such as the PO and MDO tool might require the MRP fucntionality and might require the MRP related data from the PMS tool. In this case the impact of introducing the MRP fucntionality in PMS tool on MDO and PO and maybe other tools need to be analyzed.
In either case; that of new product development or that of enhancement of exisitng products; the impact of integration touch points across the products needs to be anaylzed very clearly.
In the traditional approach of developing software products; the products are developed standalone while keeping in view only the basic intergation touch point with other software products. Not much investment is done in trying to analyze the impact of the integration development being done for the new or exisitng products to the other product. Say for example the integration method chosen by the PO tool development team to integrate the PO tool to PMS for a particular data flow from PO to PMS is a method that might not be supported by PMS and might require lot many modifications in PMS to accomodate it to this integration method. The effort to now modify PMS to integrate it with PO might be lot and this effort estimation might come as a sudden suprise for the PMS team. Also it might just happen that the integration of PO and PMS could have been done using a simpler and a cheaper and more stable method. The reason that this scenario might happen is that proper and indepth analysis of exisitng integration architecture of PMS and the analysis of effort and quality estimation between the integration modifications that might be required in PO to integrate it with PMS vs integration modifications that might be required in PMS to integrate it with PO was not done. Each of the development teams of PMS and PO missed out the wholistic picture and were focussed in developing/enhancing their individual products. This calls for an integrated product development approach.
Integrated product development methodology calls for individual develpoment teams to work in close cohesion and interaction with each other to have a bigger view of an intergrated product suite and then understand the impact of a development/ enhancement of one product on the other products. In doing so the best approach of development/enhancement method and clearer effort estimation is available. This leads to a far more robust integration in a shorter time period than if each of the development teams works seperately and then the finer details of intergation are thrased out. Say for example for the case given above the PMS development team will work closely with the PO and MDO development teams to understand the complete integrated solution of PMS-MDO-PO. The entire team comprising the MDO , PO and PMS developemnt teams would analyze the best approach for developing/enahancing the three products based on the integration touch points between the products to have a stable and effcient intergated solution rather than efficient stand alone products but inefficent when integrated.
Summary:
Software products dont run independently. They need to interact with each other for complete functioning of the solution comprising the software products. Hence integration of the products become a very cruical aspect of the proper and efficient working of the products.
In Traditional Product Development the development teams work separately. There is a limited interaction among the development teams. The individual teams miss the bigger integrated picture. Hence the chances of additional developments that might be required for a complete integrated solution and hence the chances of additional developements and chances of an inefficient integration run high. This in turns leads to longer lead time to deliver an integrated solution.
In integrated product development methodologhy the individual development teams in close interaction with each other to have a bigger view of an intergrated product suite. Hence they understand the impact of a development/ enhancement of one product on the other products better and thus the best approach of development/enhancement method and clearer effort estimation is available. This leads to a far more robust integration in a shorter time period.
No comments:
Post a Comment