Vendors continue to create industry templates as an attempt to simplify SCP implementations. Embedded in the templates are predefined strategies for common planning issues that might need to be addressed in a given industry. But the nature of SCP applications defies such "cookie-cutter" implementations. SCP solutions are specific to each supply chain, and this is the reason they are able to deliver such significant results. Developing an effective supply chain solution requires a deep understanding of each company's supply chain processes and objectives. Supply chain applications model the real-life constraints of the supply chain. If constraints are overlooked or not represented accurately, then the plans will not deliver realistic results. If the optimization objectives guiding the solution are not in line with the goals of the business, then the plans will not deliver the expected benefits. The business users of the application must work hand in hand with the developers of the solution to ensure these benefits and results. The SCP solution development process tends to be iterative in nature. It relies heavily on the use of prototype sessions with the business users to validate the accuracy of the design and the technical feasibility of the solution.
Given that SCP solutions are representations of a specific supply chain, and that supply chains change constantly, maintenance of the solution is critical. An up-to-date model is required to keep plans valid and to build on the benefits of the initial implementation. As planners work with an SCP solution over time, they will learn more about its capabilities. This will generate more ideas about how to increase the value delivered by the systems. The supply chain solution needs to be as dynamic as the supply chain itself. The resources who developed the solution are the ones who are best equipped to identify the point at which changes are warranted, and to implement those changes in the software.
While it is acceptable, and even preferable, to outsource the development and testing of a company's SCP software code (see The Many Flavors of Application Software Outsourcing), the same may not be true for the SCP business rules. The ability to support a SCP solution over the long term depends on keeping the personnel that developed the business rules for the solution available to the organization. If a company relies solely on outside resources to develop and support their business rules, they have much less control. Turnover in consulting and outsourcing organizations tends to be much higher than in other industries. Relying on an outside vendor to select and train a backup support person is also not sufficient. The secondhand training they receive is unlikely to convey the detail and business context required for understanding the solution well enough to make independent changes or to confirm that the results of changes are accurate.
Keeping the solution running on a daily basis also requires an understanding of the data coming from the transaction systems. Changes to the format of this data, or to the meaning of this data, will impact the ability of the SCP solution to run, or to stay meaningful. The person maintaining the business rules in the system needs to understand the business context of the transactional data, and to know how to modify the structure of the model to represent changes in the supply chain. This breadth of knowledge is difficult to maintain outside the organization. A typical worst-case scenario occurs when the overnight planning run fails, and the original resource from the outside provider—the resource that developed the solution model and initially supported it—is no longer available. The current support person doesn't know the model well enough to single-handedly diagnose the problem. The planner or scheduler who shows up in the morning has to manually issue schedules while assisting the outside provider in diagnosing the problem over the phone.
Given that SCP solutions are representations of a specific supply chain, and that supply chains change constantly, maintenance of the solution is critical. An up-to-date model is required to keep plans valid and to build on the benefits of the initial implementation. As planners work with an SCP solution over time, they will learn more about its capabilities. This will generate more ideas about how to increase the value delivered by the systems. The supply chain solution needs to be as dynamic as the supply chain itself. The resources who developed the solution are the ones who are best equipped to identify the point at which changes are warranted, and to implement those changes in the software.
While it is acceptable, and even preferable, to outsource the development and testing of a company's SCP software code (see The Many Flavors of Application Software Outsourcing), the same may not be true for the SCP business rules. The ability to support a SCP solution over the long term depends on keeping the personnel that developed the business rules for the solution available to the organization. If a company relies solely on outside resources to develop and support their business rules, they have much less control. Turnover in consulting and outsourcing organizations tends to be much higher than in other industries. Relying on an outside vendor to select and train a backup support person is also not sufficient. The secondhand training they receive is unlikely to convey the detail and business context required for understanding the solution well enough to make independent changes or to confirm that the results of changes are accurate.
Keeping the solution running on a daily basis also requires an understanding of the data coming from the transaction systems. Changes to the format of this data, or to the meaning of this data, will impact the ability of the SCP solution to run, or to stay meaningful. The person maintaining the business rules in the system needs to understand the business context of the transactional data, and to know how to modify the structure of the model to represent changes in the supply chain. This breadth of knowledge is difficult to maintain outside the organization. A typical worst-case scenario occurs when the overnight planning run fails, and the original resource from the outside provider—the resource that developed the solution model and initially supported it—is no longer available. The current support person doesn't know the model well enough to single-handedly diagnose the problem. The planner or scheduler who shows up in the morning has to manually issue schedules while assisting the outside provider in diagnosing the problem over the phone.
No comments:
Post a Comment