A black hole is an object whose gravitational pull is so strong that nothing - not even light - can escape from it. Although predicted by Einstein's General Theory of Relativity, the existence of black holes in our galaxy and elsewhere has only recently been confirmed. A black hole forms when a massive star dies and collapses under its own mass.
For all but a few astronomers, black holes are unknown in the realm of ordinary experience. Analogs do exist, however, in the more terrestrial domain of business process reengineering and take the form of supply chain management implementations.
Similar to their gravitational counterparts, supply chain management implementations can grow to vast, unanticipated proportions, enveloping unbudgeted amounts of time, resources, and money. A crucial difference between the two is that supply chain projects can be kept to a manageable size by making careful preparations and setting realistic expectations at the outset. The following real-life examples offer insights that may help prevent your supply chain project from collapsing into oblivion, taking your enterprise with it.
Case 1:
Problem
Five months into the implementation of a factory scheduling system at a mid-sized PC assembly facility and one month before going live, planners were asked to help perform the system test of the application, during which daily workflow would be checked against requirements.
Planning involved making a survey of the next few days of PC orders, the required components indicated by the Bill of Materials, and the current inventory so that new components could be procured in time to meet the demand. Planners relied on a metric known as "days of inventory," calculated for each component SKU (stock keeping unit) by subtracting all components needed for each day of production successively from inventory until the inventory was exhausted. The number of days that would bring inventory to zero was that component's days of inventory.
Unfortunately, the new system had no capability for computing this value and planners found that to generate it, they had to page through hundreds of scheduled orders, sorted by finished SKU, use the software's capability for reverse BOM explosion to get the components, total the needed components by SKU in a spreadsheet and then manually subtract the totals one day at a time from the inventory, also provided by the system. The software selected for the new system had no capability to produce the required metric. Needless to state, the manual steps completely derailed the workflow and the planners revolted.
Resolution
Under pressure to finish the implementation, the project team resolved the system shortcomings by writing a custom report in Microsoft VBA (Visual Basic for Applications) and Excel. This required four additional weeks at roughly $60,000 per week:
* Three additional weeks of interviews with planners to understand the metrics and development work by a VBA programmer
* Followed by one additional week of testing by the frustrated and increasingly skeptical planners.
In spite of the efforts, the completed solution was an unsatisfactory compromise between mitigating budget overrun and delivering the required reporting capabilities.
Underlying problems
* Failure to appreciate the importance of existing reports and metrics to planner workflow
* Inadequate communication between planners and the project team in the early stages of the project
* Failure to adequately screen candidate software packages for advanced reporting capabilities
Best practices that might have prevented the problems
* First off, the project team needs to prepare a list of detailed requirements by involving end users and then conduct a careful evaluation of several packages to find the one that best fulfills them.
* End users, those who will be working with the new system on a daily basis, should be included in the project implementation phase early on. Managers need to give these key users time off from their normal duties to contribute their expertise to the project. This commitment requires the support of top management.
* Rapid prototyping provides a basic system to users who then have a tactile understanding of what the new system will look like and how it will behave.
Case 2:
Requirements
* Implementation of a demand/supply matching system for two separate PC assembly plants, one owned by the company and the other, a contract facility.
* The system was needed to support new channel programs designed to facilitate replenishment of reseller inventory by allowing resellers to share requirements via EDI (electronic data interchange). This was an ambitious departure from existing procedures that relied on telephone communication between resellers and demand planners.
Problem
The project schedule was based solely on the start of the new channel programs without regard to resource constraints. In addition, the supply chain software vendor gave optimistic release dates for the software to be used, which were taken as firm by client management.
Even working 65-70 hours per week, the undersized project team of 15 people had no hope of conducting a thorough design and test implementation. To make matters worse, less than three weeks were allotted for receiving the new server, installing the software on it, and configuring it to run the software in a live setting. The vendor consistently failed to meet its expected release dates due to other projects and clients. Resellers could not keep up with required milestones for the implementation of EDI capabilities.
Nearly three months into the project, almost at the proposed conversion date, the project team and management conceded defeat.
Resolution
The project timeline was redrawn by factoring in the number of skilled resources available, realistic software release dates, and firm delivery dates for the hardware server. Also, the new plan included the development of interfaces to allow resellers to input inventory and demand data independent of EDI. The system went live six months after the original conversion date. Estimated budget overrun: $2.5 million.
Underlying problems
* Implementation was squeezed into an overly aggressive three-month project schedule to support the inauguration of three new reseller channel programs.
* Failure to realize the barriers to be overcome in implementing new business processes, i.e., obtaining commitments from resellers to share inventory data with demand planners
Best practices that might have prevented the problems
* Timelines should always be constructed using a bottom-up approach, where project milestones are determined by the availability of people, software, and hardware.
* No supply chain management solution will work unless the business processes it is designed to support are agreed upon by the parties involved. Obtaining this agreement should be an ongoing process that starts before the technical aspects of the project begin and continues through the implementation phase by allowing all organizational entities, both internal and external, to understand the new changes.
Case 3:
Background and Requirements
* Large, multinational semiconductor manufacturer
* Supply chain planning software implementation at the headquarter planning division responsible for creating production requirements for seven wafer fabs and assembly/test facilities and allocating supply to customer orders
* The new system was to support four main activities:
1. facilitate development of consensus forecasts
2. allocate different categories of supply to forecasts and orders based on business rules
3. generate finite capacity plans and schedules to be passed to manufacturing sites
4. promise orders to customers based on supply allocated from inventory as well as planned and actual production
* Systems to support all four activities were implemented in parallel using a "Big Bang" approach
Problem
During the user test, in which headquarter planners were allowed to play around with the system tested version of the software and make suggestions, the project team was inundated with requests for additional functionality. The project team dictated each of these to the software vendor who was responsible for making customizations to the core software. Not only was the vendor unable to make all the requested modifications in time, it viewed the changes as well beyond the originally agreed upon scope. Deadlines slipped and the development environment became chaotic with all the requested changes, which caused more delays.
Resolution
Client top management finally intervened and put a freeze on modifications to the software. It also split the project into four phases based on each headquarter planning activity to allow the project team to focus on fewer requirements at one time. The last phase of the project was completed nearly one year after the originally scheduled "Big Bang" conversion date. Estimated budget overrun: $4 million.
Underlying problems
* The client failed to appreciate the size of the undertaking and tried implementing the four areas in parallel to save money.
* The client was unwilling to table new functionality requests for a later release, causing severe scope creep. Best practices that might have prevented the problems
* Where project scope spans multiple business functions, a phased implementation approach can be used to reduce the complexity of the project. Lessons learned in the early phases can often be applied to succeeding phases.
* Project scope should be decided at the outset and adhered to throughout the implementation. New requirements that arise during the implementation should be prioritized and only the "must-have" changes should be made. The rest should be saved for future releases.
Summary
From a broad perspective, many problems result because the complexity of supply chain management projects is underestimated by corporate management.
Often supply chain packages are installed on top of ERP or legacy systems requiring an array of interfaces to be developed. Linking different applications requires a profound level of understanding about the data that is passed back and forth between them.
Apart from technical complexities, managers fail to appreciate the bottom line impact that supply chain management tools can have on their businesses. Even with the expanding compass brought to supply chain by B2B collaboration, this perception will be slow to change.
Finally, it is important to remember that, even with good preparation, experienced resources, and an enthusiastic project team, all supply chain management projects are guaranteed to bring unanticipated problems and dead ends. Successful projects are not those that finish without a hitch, but those in which project managers adapt well to adversity and persevere in spite of the problems.
SOURCE:
http://www.technologyevaluation.com/research/articles/how-supply-chain-projects-morph-into-black-holes-16781/
Wednesday, August 18, 2010
How Supply Chain Projects Morph Into Black Holes
12:53 AM Posted by amma
A black hole is an object whose gravitational pull is so strong that nothing - not even light - can escape from it. Although predicted by Einstein's General Theory of Relativity, the existence of black holes in our galaxy and elsewhere has only recently been confirmed. A black hole forms when a massive star dies and collapses under its own mass.
For all but a few astronomers, black holes are unknown in the realm of ordinary experience. Analogs do exist, however, in the more terrestrial domain of business process reengineering and take the form of supply chain management implementations.
Similar to their gravitational counterparts, supply chain management implementations can grow to vast, unanticipated proportions, enveloping unbudgeted amounts of time, resources, and money. A crucial difference between the two is that supply chain projects can be kept to a manageable size by making careful preparations and setting realistic expectations at the outset. The following real-life examples offer insights that may help prevent your supply chain project from collapsing into oblivion, taking your enterprise with it.
Case 1:
Problem
Five months into the implementation of a factory scheduling system at a mid-sized PC assembly facility and one month before going live, planners were asked to help perform the system test of the application, during which daily workflow would be checked against requirements.
Planning involved making a survey of the next few days of PC orders, the required components indicated by the Bill of Materials, and the current inventory so that new components could be procured in time to meet the demand. Planners relied on a metric known as "days of inventory," calculated for each component SKU (stock keeping unit) by subtracting all components needed for each day of production successively from inventory until the inventory was exhausted. The number of days that would bring inventory to zero was that component's days of inventory.
Unfortunately, the new system had no capability for computing this value and planners found that to generate it, they had to page through hundreds of scheduled orders, sorted by finished SKU, use the software's capability for reverse BOM explosion to get the components, total the needed components by SKU in a spreadsheet and then manually subtract the totals one day at a time from the inventory, also provided by the system. The software selected for the new system had no capability to produce the required metric. Needless to state, the manual steps completely derailed the workflow and the planners revolted.
Resolution
Under pressure to finish the implementation, the project team resolved the system shortcomings by writing a custom report in Microsoft VBA (Visual Basic for Applications) and Excel. This required four additional weeks at roughly $60,000 per week:
* Three additional weeks of interviews with planners to understand the metrics and development work by a VBA programmer
* Followed by one additional week of testing by the frustrated and increasingly skeptical planners.
In spite of the efforts, the completed solution was an unsatisfactory compromise between mitigating budget overrun and delivering the required reporting capabilities.
Underlying problems
* Failure to appreciate the importance of existing reports and metrics to planner workflow
* Inadequate communication between planners and the project team in the early stages of the project
* Failure to adequately screen candidate software packages for advanced reporting capabilities
Best practices that might have prevented the problems
* First off, the project team needs to prepare a list of detailed requirements by involving end users and then conduct a careful evaluation of several packages to find the one that best fulfills them.
* End users, those who will be working with the new system on a daily basis, should be included in the project implementation phase early on. Managers need to give these key users time off from their normal duties to contribute their expertise to the project. This commitment requires the support of top management.
* Rapid prototyping provides a basic system to users who then have a tactile understanding of what the new system will look like and how it will behave.
Case 2:
Requirements
* Implementation of a demand/supply matching system for two separate PC assembly plants, one owned by the company and the other, a contract facility.
* The system was needed to support new channel programs designed to facilitate replenishment of reseller inventory by allowing resellers to share requirements via EDI (electronic data interchange). This was an ambitious departure from existing procedures that relied on telephone communication between resellers and demand planners.
Problem
The project schedule was based solely on the start of the new channel programs without regard to resource constraints. In addition, the supply chain software vendor gave optimistic release dates for the software to be used, which were taken as firm by client management.
Even working 65-70 hours per week, the undersized project team of 15 people had no hope of conducting a thorough design and test implementation. To make matters worse, less than three weeks were allotted for receiving the new server, installing the software on it, and configuring it to run the software in a live setting. The vendor consistently failed to meet its expected release dates due to other projects and clients. Resellers could not keep up with required milestones for the implementation of EDI capabilities.
Nearly three months into the project, almost at the proposed conversion date, the project team and management conceded defeat.
Resolution
The project timeline was redrawn by factoring in the number of skilled resources available, realistic software release dates, and firm delivery dates for the hardware server. Also, the new plan included the development of interfaces to allow resellers to input inventory and demand data independent of EDI. The system went live six months after the original conversion date. Estimated budget overrun: $2.5 million.
Underlying problems
* Implementation was squeezed into an overly aggressive three-month project schedule to support the inauguration of three new reseller channel programs.
* Failure to realize the barriers to be overcome in implementing new business processes, i.e., obtaining commitments from resellers to share inventory data with demand planners
Best practices that might have prevented the problems
* Timelines should always be constructed using a bottom-up approach, where project milestones are determined by the availability of people, software, and hardware.
* No supply chain management solution will work unless the business processes it is designed to support are agreed upon by the parties involved. Obtaining this agreement should be an ongoing process that starts before the technical aspects of the project begin and continues through the implementation phase by allowing all organizational entities, both internal and external, to understand the new changes.
Case 3:
Background and Requirements
* Large, multinational semiconductor manufacturer
* Supply chain planning software implementation at the headquarter planning division responsible for creating production requirements for seven wafer fabs and assembly/test facilities and allocating supply to customer orders
* The new system was to support four main activities:
1. facilitate development of consensus forecasts
2. allocate different categories of supply to forecasts and orders based on business rules
3. generate finite capacity plans and schedules to be passed to manufacturing sites
4. promise orders to customers based on supply allocated from inventory as well as planned and actual production
* Systems to support all four activities were implemented in parallel using a "Big Bang" approach
Problem
During the user test, in which headquarter planners were allowed to play around with the system tested version of the software and make suggestions, the project team was inundated with requests for additional functionality. The project team dictated each of these to the software vendor who was responsible for making customizations to the core software. Not only was the vendor unable to make all the requested modifications in time, it viewed the changes as well beyond the originally agreed upon scope. Deadlines slipped and the development environment became chaotic with all the requested changes, which caused more delays.
Resolution
Client top management finally intervened and put a freeze on modifications to the software. It also split the project into four phases based on each headquarter planning activity to allow the project team to focus on fewer requirements at one time. The last phase of the project was completed nearly one year after the originally scheduled "Big Bang" conversion date. Estimated budget overrun: $4 million.
Underlying problems
* The client failed to appreciate the size of the undertaking and tried implementing the four areas in parallel to save money.
* The client was unwilling to table new functionality requests for a later release, causing severe scope creep. Best practices that might have prevented the problems
* Where project scope spans multiple business functions, a phased implementation approach can be used to reduce the complexity of the project. Lessons learned in the early phases can often be applied to succeeding phases.
* Project scope should be decided at the outset and adhered to throughout the implementation. New requirements that arise during the implementation should be prioritized and only the "must-have" changes should be made. The rest should be saved for future releases.
Summary
From a broad perspective, many problems result because the complexity of supply chain management projects is underestimated by corporate management.
Often supply chain packages are installed on top of ERP or legacy systems requiring an array of interfaces to be developed. Linking different applications requires a profound level of understanding about the data that is passed back and forth between them.
Apart from technical complexities, managers fail to appreciate the bottom line impact that supply chain management tools can have on their businesses. Even with the expanding compass brought to supply chain by B2B collaboration, this perception will be slow to change.
Finally, it is important to remember that, even with good preparation, experienced resources, and an enthusiastic project team, all supply chain management projects are guaranteed to bring unanticipated problems and dead ends. Successful projects are not those that finish without a hitch, but those in which project managers adapt well to adversity and persevere in spite of the problems.
SOURCE:
http://www.technologyevaluation.com/research/articles/how-supply-chain-projects-morph-into-black-holes-16781/
For all but a few astronomers, black holes are unknown in the realm of ordinary experience. Analogs do exist, however, in the more terrestrial domain of business process reengineering and take the form of supply chain management implementations.
Similar to their gravitational counterparts, supply chain management implementations can grow to vast, unanticipated proportions, enveloping unbudgeted amounts of time, resources, and money. A crucial difference between the two is that supply chain projects can be kept to a manageable size by making careful preparations and setting realistic expectations at the outset. The following real-life examples offer insights that may help prevent your supply chain project from collapsing into oblivion, taking your enterprise with it.
Case 1:
Problem
Five months into the implementation of a factory scheduling system at a mid-sized PC assembly facility and one month before going live, planners were asked to help perform the system test of the application, during which daily workflow would be checked against requirements.
Planning involved making a survey of the next few days of PC orders, the required components indicated by the Bill of Materials, and the current inventory so that new components could be procured in time to meet the demand. Planners relied on a metric known as "days of inventory," calculated for each component SKU (stock keeping unit) by subtracting all components needed for each day of production successively from inventory until the inventory was exhausted. The number of days that would bring inventory to zero was that component's days of inventory.
Unfortunately, the new system had no capability for computing this value and planners found that to generate it, they had to page through hundreds of scheduled orders, sorted by finished SKU, use the software's capability for reverse BOM explosion to get the components, total the needed components by SKU in a spreadsheet and then manually subtract the totals one day at a time from the inventory, also provided by the system. The software selected for the new system had no capability to produce the required metric. Needless to state, the manual steps completely derailed the workflow and the planners revolted.
Resolution
Under pressure to finish the implementation, the project team resolved the system shortcomings by writing a custom report in Microsoft VBA (Visual Basic for Applications) and Excel. This required four additional weeks at roughly $60,000 per week:
* Three additional weeks of interviews with planners to understand the metrics and development work by a VBA programmer
* Followed by one additional week of testing by the frustrated and increasingly skeptical planners.
In spite of the efforts, the completed solution was an unsatisfactory compromise between mitigating budget overrun and delivering the required reporting capabilities.
Underlying problems
* Failure to appreciate the importance of existing reports and metrics to planner workflow
* Inadequate communication between planners and the project team in the early stages of the project
* Failure to adequately screen candidate software packages for advanced reporting capabilities
Best practices that might have prevented the problems
* First off, the project team needs to prepare a list of detailed requirements by involving end users and then conduct a careful evaluation of several packages to find the one that best fulfills them.
* End users, those who will be working with the new system on a daily basis, should be included in the project implementation phase early on. Managers need to give these key users time off from their normal duties to contribute their expertise to the project. This commitment requires the support of top management.
* Rapid prototyping provides a basic system to users who then have a tactile understanding of what the new system will look like and how it will behave.
Case 2:
Requirements
* Implementation of a demand/supply matching system for two separate PC assembly plants, one owned by the company and the other, a contract facility.
* The system was needed to support new channel programs designed to facilitate replenishment of reseller inventory by allowing resellers to share requirements via EDI (electronic data interchange). This was an ambitious departure from existing procedures that relied on telephone communication between resellers and demand planners.
Problem
The project schedule was based solely on the start of the new channel programs without regard to resource constraints. In addition, the supply chain software vendor gave optimistic release dates for the software to be used, which were taken as firm by client management.
Even working 65-70 hours per week, the undersized project team of 15 people had no hope of conducting a thorough design and test implementation. To make matters worse, less than three weeks were allotted for receiving the new server, installing the software on it, and configuring it to run the software in a live setting. The vendor consistently failed to meet its expected release dates due to other projects and clients. Resellers could not keep up with required milestones for the implementation of EDI capabilities.
Nearly three months into the project, almost at the proposed conversion date, the project team and management conceded defeat.
Resolution
The project timeline was redrawn by factoring in the number of skilled resources available, realistic software release dates, and firm delivery dates for the hardware server. Also, the new plan included the development of interfaces to allow resellers to input inventory and demand data independent of EDI. The system went live six months after the original conversion date. Estimated budget overrun: $2.5 million.
Underlying problems
* Implementation was squeezed into an overly aggressive three-month project schedule to support the inauguration of three new reseller channel programs.
* Failure to realize the barriers to be overcome in implementing new business processes, i.e., obtaining commitments from resellers to share inventory data with demand planners
Best practices that might have prevented the problems
* Timelines should always be constructed using a bottom-up approach, where project milestones are determined by the availability of people, software, and hardware.
* No supply chain management solution will work unless the business processes it is designed to support are agreed upon by the parties involved. Obtaining this agreement should be an ongoing process that starts before the technical aspects of the project begin and continues through the implementation phase by allowing all organizational entities, both internal and external, to understand the new changes.
Case 3:
Background and Requirements
* Large, multinational semiconductor manufacturer
* Supply chain planning software implementation at the headquarter planning division responsible for creating production requirements for seven wafer fabs and assembly/test facilities and allocating supply to customer orders
* The new system was to support four main activities:
1. facilitate development of consensus forecasts
2. allocate different categories of supply to forecasts and orders based on business rules
3. generate finite capacity plans and schedules to be passed to manufacturing sites
4. promise orders to customers based on supply allocated from inventory as well as planned and actual production
* Systems to support all four activities were implemented in parallel using a "Big Bang" approach
Problem
During the user test, in which headquarter planners were allowed to play around with the system tested version of the software and make suggestions, the project team was inundated with requests for additional functionality. The project team dictated each of these to the software vendor who was responsible for making customizations to the core software. Not only was the vendor unable to make all the requested modifications in time, it viewed the changes as well beyond the originally agreed upon scope. Deadlines slipped and the development environment became chaotic with all the requested changes, which caused more delays.
Resolution
Client top management finally intervened and put a freeze on modifications to the software. It also split the project into four phases based on each headquarter planning activity to allow the project team to focus on fewer requirements at one time. The last phase of the project was completed nearly one year after the originally scheduled "Big Bang" conversion date. Estimated budget overrun: $4 million.
Underlying problems
* The client failed to appreciate the size of the undertaking and tried implementing the four areas in parallel to save money.
* The client was unwilling to table new functionality requests for a later release, causing severe scope creep. Best practices that might have prevented the problems
* Where project scope spans multiple business functions, a phased implementation approach can be used to reduce the complexity of the project. Lessons learned in the early phases can often be applied to succeeding phases.
* Project scope should be decided at the outset and adhered to throughout the implementation. New requirements that arise during the implementation should be prioritized and only the "must-have" changes should be made. The rest should be saved for future releases.
Summary
From a broad perspective, many problems result because the complexity of supply chain management projects is underestimated by corporate management.
Often supply chain packages are installed on top of ERP or legacy systems requiring an array of interfaces to be developed. Linking different applications requires a profound level of understanding about the data that is passed back and forth between them.
Apart from technical complexities, managers fail to appreciate the bottom line impact that supply chain management tools can have on their businesses. Even with the expanding compass brought to supply chain by B2B collaboration, this perception will be slow to change.
Finally, it is important to remember that, even with good preparation, experienced resources, and an enthusiastic project team, all supply chain management projects are guaranteed to bring unanticipated problems and dead ends. Successful projects are not those that finish without a hitch, but those in which project managers adapt well to adversity and persevere in spite of the problems.
SOURCE:
http://www.technologyevaluation.com/research/articles/how-supply-chain-projects-morph-into-black-holes-16781/
Subscribe to:
Post Comments (Atom)
0 comments:
Post a Comment