What procedure can be used to change system statistics in a production environment System statistics aren't required but highly recommended by Oracle. From my own experience, it produced a huge improvement on the total user IO waits of our production environment when first implemented.

There isn't a need to change it regularly, however it is recommended to regather the system statistics when a big change occur, such as change of hardware.

When such a need occur, what procedure do you use to refresh it and ensure the results are beneficial?
For major database statistics regathers, it is best to forget the old stats and essentially regather statistics freshly on the whole system. I do not advise doing this frequently because it is a significant workload undertaking on your system and there are better methods of controlling statistics over time.

This would likely require a script to go out and gather all the tables that exist in your database and put them into a queue for the DB to analyze. After the DB has completed reanalysis you need to publish the changes for them to take effect. 

Once you've forced the system to stage the new statistics, this is how to flush the old statistics out and push the staged statistics into production.

exec dbms_stats.flush_database_monitoring_info;

exec dbms_stats.import_database_stats('&lt; table_name &gt;','&lt; table_value &gt;','&lt; user &gt;',force=&gt;true);

exec dbms_stats.export_schema_stats ('&lt; user &gt;','&lt; table &gt;','ACTUAL','&lt; user &gt;');

exec sys.dbms_stats.delete_system_stats();

exec sys.dbms_stats.gather_system_stats(gathering_mode=&gt;'NOWORKLOAD'); #This is subjective based upon the workload the system was on during analysis

exec dbms_stats.gather_dictionary_stats();

exec dbms_stats.gather_fixed_objects_stats();


EDIT:
I cannot yet respond to the comment asking if there are ever any adverse effects from gathering statistics. 

Statistics regathers cannot promise that they won't make one or many individual pieces of the system perform poorly. Sometimes SQL scripts will determine that there is a better path based on your new statistics that is actually a worse path in reality. Sometimes it'll make a quiet script that runs millions of times a day with no issue turn into a problematic script that halts the DB (until you go tell it to take the old path). It also cannot promise general performance increases on your database. It can only promise that the statistics on your tables will become fresh.

The other risk is that statistics gathering and analysis is an intensive process which can bog down the system if done under production stress. It is best to do a full statistics regather when you're guaranteed that the majority of users won't be on the system (overnight, during client downtimes, etc)

Finally, if you are gathering statistics while a user is making massive changes then that can cause some unruly performance changes. It's another reason to gather stats while minimal users are on the system or when no atypical changes are being made.