In the 1990s I programmed a small suite of component tracking/plant configuration tracking/support incident tracking applications for our company - as I am an engineer and had no background in business databases I started from first principles, which in a professional context includes personal responsibility and traceability of decisions IMO.
So the views of the data included log entries like e.g.
04.01.1997 9:38 - Firstname Lastname - component approval status changed from untested to tested; firmware version changed from (empty) to 2.99.12
21.05.2002 15:20 - Firstname Lastname - system circuit diagram approved for production
01.07.2004 10:10 - Firstname Lastname - support incident marked closed - billing status changed to no invoice - note: Under warranty - address switch was incorrectly set by us in final test.
These last years the functionality of these old handcrafted applications have been integrated into a relatively standard, relatively lightweight ERP system.
What looks curious to me as an user is that in this system I can see mostly what actions/commercial or quality-related decisions have been made, but not by whom, with what reason, and sometimes not even when.
For example, I can see a certain invoice has been issued on a certain date, but not who (out of the users with the requisite permission level) has processed it. Likewise, a list of components has been certified, but I don’t see by whom (again, out of the users with the needed permissions) and when, etc. For forensic purposes this could probably be reconstructed out of the SQL server’s log files, but not for practical purposes.
I am curious which of these two mindsets (“User A has taken action X at time Y, logging comment C” versus “Action X has been taken by someone authorized to do so”) is the prevailing one in the larger ERP world.
I’ve done systems where only the initiator of a few broad processes were logged by accountname, some where changes were logged ony at the record (i.e., row) level regardless of which field (i.e., column) was modified, some where every single change to any value and every execution of any user-deployable script (i.e., button-driven or menu-driven automated process) was recorded, and for all such variants done them both WITH and WITHOUT recording the prior values.
I consider it to be part of the whole “what does the customer want” process: what kind of tracking & logging to you need?
My experience with Purchasing-warehouse-accounting-payroll was that everything is logged for audit purposes, even if it is not visible on the screen to most end users.
Part of the issue of visibility is “who needs to know and why”? If it’s not important, there’s no need to show it. If it can’t reach that stage without authorization, you know an authorized person did the previous transaction. Unles there’s a need to know that person (i.e. phone Jack because there’s a question about this order) why bother? Fred put in the order, someone with the right to sign off on the account says it’s ok to spend the money.
Whether there’s a need to track it, and possibly give detailed audit reports for forensic or diagnostic reasons, is a different issue. Most of the high end systems are anal about tracking absolutely everything (disk space is so cheap today).
Most of the middle tier ERP systems I have worked on have traditionally only had date/time/user stamping of row changes with typically select tables having more detailed logging (e.g. sales order header/detail tables).
Tier 1 systems like SAP have complete detailed logging, and I imagine tier 2 systems will (or do already) have it more and more as time goes on.