Baselining. Baselining is the process of defining what is normal in a particular environment, so that alerting is done on only aberrant patterns and events. For instance, every network environment has multiple failed logons during the day. How many failed logons are normal? How many failed logons in a particular time period should be reported as suspicious? Some log management products will listen to incoming message traffic and help set alerts when levels have exceeded certain thresholds. If the product doesn't do it, you must.
Alerting. When a critical security or operation event happens, it's important that a response team get notified. Most products support email and SNMP alerting, and others support paging, SMS, network broadcast messages, and syslog forwards. A few products interface with popular help desk products so that a service ticket can automatically be generated and routed.
It's also crucial for alerting thresholds to suppress multiple, continuous alerts from happening from a single causative event; most products support this feature. For example, you don't want to be alerted 1,000 times of a single, continuing port scan across multiple ports. One alert should be enough to get the response team moving.
Reporting. Reporting on all collected events allows long-term baselining and metrics to be accomplished. Critical events should be included on reports and alerted. Reporting allows technical teams to pinpoint problems and management to gauge compliance efforts.
You can find a more detailed discussion of the log management lifecycle and security auditing in my downloadable report, "Log Analysis Deep Dive: Finding Gold in Log Files."