Your question's pretty broad. There's a lot of different commands you can use to troubleshoot and monitor QoS, so I'll focus on the primary question you have, which is how to reasonably verify your QoS configuration is working and how to read the policy-map interface output.
The only true way to verify that QoS is working is to hook up a traffic generator and monitor your drop rate in various queues. Since that isn't typically feasible, particularly in a production environment, all you can really do is verify that the traffic is being marked and classified properly.
What you're really looking for, when it comes to verifying if your QoS configuration is working, is for the counters in the policy-map interface command to increment.
So, for example, in the output your provided:
Class-map: VOICE (match-any)
3860628 packets, 1070196895 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: protocol sip
97348 packets, 49867304 bytes
5 minute rate 0 bps
Match: protocol rtp
3763280 packets, 1020329591 bytes
5 minute rate 0 bps
Match: access-group name NEC-PBX
0 packets, 0 bytes
5 minute rate 0 bps
Priority: 40% (340 kbps), burst bytes 8500, b/w exceed drops: 5
You can see that you're seeing packets under SIP and RTP, but not NEC-PBX. If you know you're getting SIP and RTP traffic across a link, you should see the packet counts increment and that's a reasonable way to know that your configuration is basically working.
No, there is absolutely no reason why you would if you are on an isolated network. Quality of Service is simply a queueing mechanism that prioritize traffic based on predetermined requirements. If you enabled QoS on this network, you would effectively be saying "guarantee 100% of my already 100% available bandwidth is guaranteed for VoIP".
Best Answer
internet speed seams to be very good (80k/user X 50 user = 4000K = 4M) sure QOS is great thing to think about but first you need to make sure of the next.
you must think about
1- Uplinks between switches and each other (specially when it seams you run spread network). lets say you attached the users to 3 24 port switchs for example and connect switches to each other by 1G uplink so you fail into bottle neck, so how you connect your switches to each other very affect the performance of any traffic switching.
2- uplink between switches and your router , port speed of each also can be bottle neck.
3- you must think about storm control and broad cast control , if you run over cisco switches may you adapt storm control and broad cast level.
4- Firewall traffic inspection may delay the voice traffic specially you run soft phones which may use the same range of IPs as normal Data . (you may configure your firewall with roles and polices which allow SIP traffic with no inspection based on port number or protocol type)
5- may you can make sure of your internet speed per each user to make sure it is equal or greater 80 KBPS.