Another thing that might happen is that change management gets selectively enforced. One set of machines would be scrutinized where every change, even an addition of a drive to an array, would require a meeting and people signing off on the change, while the machines running a different OS would be able to be taken down, reinstalled, or otherwise modified at will without any paperwork needing to be done. (And vice versa.) Even SANs need to be documented because if someone puts both paths of a production box's MPIO links on the same drive controller, then reboots the controller, there will be Hell to pay.
Change management needs to be even across the board, be it SAN configurations, Windows, UNIX, router configurations, ASA rules, phone switch configs, VMWare configurations, and so on. If one group starts getting a free pass, then the whole system ends up being pointless come an outage that ends up being traced to undocumented changes in a part of the company that has gotten carte blanche.
Change management in even a SMB requires someone dedicated to the task of dealing with documenting changes. It requires a dedicated server, change management software, and someone who will maintain/backup/archive that. That server will be a PITA... until an outage happens and the fingers start pointing. Then, it can save a person their job.
Ideally, the change management software should allow people to put in their own changes. Say an admin is changing passwords or moving files from one filesystem to another. Might as well have a tool where items like that can be documented. Same with calls to a vendor for support, so later on, if something breaks, a simple search might come up with historical data.
All and all, a change management system is a good thing. However, it needs to be universally enforced with various grades of policies (emergency fixes can go on without approval, for example) for it to be of any good.