Running PulseAudio in system mode is usually a bad idea. There are use cases however, where PulseAudio’s system mode is a great tool, e.g. for building a PulseAudio streaming target to stream audio from multiple clients to speakers.

First, install PulseAudio, avahi (a free implementation of zeroconf) to publish the service throughout the network and the corresponding PulseAudio module:

# yum install pulseaudio pulseaudio-module-zeroconf avahi

Since the use cases of PulseAudio in system mode are limited, distributions usually do not ship a systemd unit for it.

[Unit]
Description=PulseAudio Daemon

[Install]
WantedBy=multi-user.target

[Service]
Type=simple
PrivateTmp=true
ExecStart=/usr/bin/pulseaudio --system --realtime --disallow-exit --no-cpu-limit 

For a list of available options, have a loot at the pulse-daemon manpage.

In Fedora, sound devices (/dev/snd/*) are usually owned by root:audio and since the pulse user who will run PulseAudio daemon later is not part of the audio group per default, it cannot access sound devices. Adding the pulse user to the audio group is simple though

# ls -lah /dev/snd/
total 0
drwxr-xr-x  3 root root      180 Nov 18 09:45 .
drwxr-xr-x 19 root root     3.2K Nov 18 09:45 ..
drwxr-xr-x  2 root root       60 Nov 18 09:45 by-path
crw-rw----  1 root audio 116,  2 Nov 18 09:45 controlC0
crw-rw----  1 root audio 116,  4 Nov 18 11:33 pcmC0D0c
crw-rw----  1 root audio 116,  3 Nov 18 11:29 pcmC0D0p
crw-rw----  1 root audio 116,  5 Nov 18 09:45 pcmC0D1c
crw-rw----  1 root audio 116,  1 Nov 18 09:45 seq
crw-rw----  1 root audio 116, 33 Nov 18 09:45 timer
# usermod -a -G audio pulse

To make PulseAudio available over the network, you have to add a bit of configuration to /etc/pulse/system.pa

[...]
### Enable positioned event sounds
load-module module-position-event-sounds

load-module module-native-protocol-tcp auth-anonymous=1
load-module module-zeroconf-publish

For a list of available module options, consult the PulseAudio module dokumentation, especially module-native-protocol-tcp.
auth-anonymous in particular might be a questionable idea in larger environments. An IP based access control list (auth-ip-acl) or a cookie containing some random data that serves as a shared secret between server and clients (auth-cookie) could be a more feasible approach.

Next, enable and start the PulseAudio server as well as the avahi daemon

# systemctl enable pulseaudio.service 
ln -s '/etc/systemd/system/pulseaudio.service' '/etc/systemd/system/multi-user.target.wants/pulseaudio.service'
# systemctl start pulseaudio.service
# systemctl start avahi-daemon.service

You should be able to see a new service being published through avahi on the client:

[user@PulseClient ~]$ avahi-browse -a
+ enp0s25 IPv4 PulseAudio [46:46:46:46:46:46]                 Workstation          local
+ enp0s25 IPv4 pulse@PulseAudio                               PulseAudio Sound Server local
+ enp0s25 IPv4 pulse@PulseAudio: Built-in Audio Analog Stereo PulseAudio Sound Sink local
+ enp0s25 IPv4 pulse@PulseAudio: Built-in Audio Analog Stereo PulseAudio Sound Source local

You could then go ahead and use paprefs on your client to make remote PulseAudio sound devices available locally:

Use paprefs to make remote sound devices available locally.

Finally, you might want to enable additional audio channels or change the channel mapping on the server:

[...]
; default-sample-format = s16le
; default-sample-rate = 44100
; alternate-sample-rate = 48000
; default-sample-channels = 2
default-sample-channels = 4
; default-channel-map = front-left,front-right

Don’t forget to restart the PulseAudio server afterwards!

Resources:
https://elehack.net/writings/computing/audio-server