 network functions, and roll back procedures should issues occur. As the changes are progressively rolled out across the network, sophisticated analytics such as those described in [LT_MERCURY_1, LT_MERCURY_2] can be used to verify that the changes are not resulting in unexpected negative performance impacts, and are realizing desired positive performance impacts. Should the desired goals not be realized, it may be necessary to halt the rollout until a solution is identified and can be deployed. Automating the change management process at scale reduces OPEX, and also reduces the risk of human operational errors ("Plant Operating Error," or POE). 15.2.3.5 Configuring ONAP to Enable Operations Automation One of the primary goals of ONAP is to put the definition of new automation in the service design- ers' and operators' hands, and to minimize any software development required to introduce new functionality. As an example, ONAP enables users (service designers and operators) to define con- trol loops without requiring software development-specifying events to be detected, correlation rules that localize the underlying location and root cause of an issue, and defining actions to be taken to automatically mitigate an issue, or to alert a network operator for further investigation. As another example, ONAP enables workflows to be specified from predefined building blocks to define how change management activities should be executed. This dynamic configurability of the ONAP environment ensures that the operations teams are in control of the policies and workflow that manage networks and services, and do not require that development teams be engaged to make changes unless new platform or analytics capabilities or network function interfaces are required. This improves operations' ability to introduce new capa- bilities, enabling faster deployment of new automation for new conditions observed in the network, and correspondingly improving customer experience. 15.2.4 ONAP-RELATED CHALLENGES Although ONAP promises exciting 