Panie Tomaszu, 

Według ITILa odpowiedzialność za potencjalne interakcje między zmianą, w tym dużą lub poważną zmianą, a innymi zarządzanymi w tym samym procesie zmianami leży po stronie change managera. Jeżeli zmiana standardowa ma charakter powtarzalnej, lub nawet zautomatyzowanej akcji, zmiany normalne w tym samym środowisku muszą ją wziąć pod uwagę - przeprogramować by odpowiadała zmienionym parametrom środowiska lub wstrzymać tymczasowo, by nie dopuścić do interakcji między wydaniem zmiany normalnej a automatycznym działaniem standardowym. 

Fakt iż zmiana standardowa jest preautoryzowana, nie zwalnia change managera z odpowiedzialności rejestrowania jej potencjalnych interakcji z nowymi, być może dużymi lub poważnymi zmianami. 

Pozwolę sobie na pozorne non sequitur, na porównanie Pana pytania do innej sytuacji - w mojej pracowni stoi masa sprzętu komputerowego, między innymi drukarki. Ten pokój stanowi też gościnną sypialnię. Możemy przyjąć, że pewne automatyczne aktywności mojego sprzętu, które zaprogramowałem dla własnej wygody, odbywają się regularnie i mają charakter zmiany standardowej - oczekuję, że dwie drukarki będą raz na dobę czyściły głowice, a komputer będzie się uruchamiał co jakiś czas, aby przeprowadzić skany antywirusowe. Zmianą normalną jest sytuacja, gdy gość korzysta z mojego pokoju i planowane skany oraz samoczyszczenie drukarek mogą wejść w konflikt z jego snem (są zaplanowane na 1:00 w nocy), a zatem na mnie, zarządzającemu zmianami w moim środowisku, leży odpowiedzialność za wstrzymanie cyklu automatycznych działań, które wchodzą w niepożądane interakcje ze zmianą normalną - w tym przypadku śpiącym człowiekiem. 

Przykład jest nieco niestandardowy, przyznaję, ale zasada jest ta sama - ITIL oczekuje, że change manager będzie świadom nie tylko planowanych zmian normalnych i zmian pilnych, które mogą pojawić się w każdym momencie, ale również wszystkich standardowych, które mogą zachodzić w jego obszarze odpowiedzialności automatycznie. Zmiany standardowe mogą być pre-autoryzowane, ale pozostają odpowiedzialnością change managera. A w jaki sposób change manager egzekwuje tę odpowiedzialność to już technikalia, którymi ITIL się nie zajmuje - może on faktycznie wyposażyć skrypt zmiany standardowej w jakiś protokół diagnostyczny, odpowiednik patrzenia w lewo, prawo i lewo przed przejściem przez ulicę. Może też sterować grafikiem skryptów manualnie. Może też ustawić proceduralne granice czasowe dla wdrożeń zmian normalnych, by zagwarantować z automatu, że normalne zmiany nie będą wdrażane w czasie działania standardowych. Na przykład, zabraniając wprowadzania zmian normalnych w piątki i planując wszystkie automaty na ten właśnie dzień. 

Powyższe nie kłóci się z faktem, że autoryzacja zmiany standardowej jest "trwała". Co innego autoryzacja, a co innego faktyczna implementacja, faktyczne wdrożenie.