BDoc Monitoring 24x7

Question

We are looking to implement a solution in CRM V5 that involves the creation of bespoke BDoc Types, the contents of which then populate customer defined Z tables within CRM.   The business process that this supports is a critical process that can be initiated 7 days a week, 24 hours per day. 
Failed BDocs or unprocessed BDocs would severely impact (negatively) this solution, as well as subsequent dependent processes that occur both within CRM and then in the linked OLTP system. 
Standard transactions such as SMW01 allow us to monitor BDocs etc, but we require something more dynamic than this to prevent someone having to constantly monitor this transaction for failures 24 hours a day as this is just not realistic.  
There must be other companies who have a similar dilemma and need to be made aware of when failures / issues occur irrespective of time of day or day of week, e.g. if a failure occurs at say 03:00am on a Sunday. 
Is there a standard way that we can monitor the system and should a failure occur this is picked up and the appropriate support / call out person notified, e.g. workflow?  If not has anyone developed their own non standard solution that can be shared or at least guidance given as to the approach to take?  
Many Thanks
Ian

Answer 1

Shantala
Thanks for taking the time to reply, especially so promptly.  However, although I accept that we can create a program to interrogate SMW3_BDOC I am still faced with the fact that if this program finds an error how this info is then notified to the person on support / call-out so that they can then log onto the system (e.g. at 03:00am) and analyse the error.
In my view the steps would be a) find a simple way (standard if possible) of identifying errors and / or issues such as unprocessed messages and then b) when this occurs triggering a notification to the support person that a problem has arisen.  Your answer would help with point a) but I am still unclear as to how this would then help satisfy point b) especially if they are asleep in bed at the time. 
Currently if a program falls over then this is captured by our organisation, an incident raised and call-out invoked to the relevant support person. I suppose we could implement a similar scenario off the back of the bespoke SMW3_BDOC program where if an error occurs the program aborts with suitable error message which then invokes callout.  I am just wondering however whether there are more standard ways by which we could do this, because as I said in my initial post, there must be organisations who have similar business critical requirements. 
Ian