Over the years we have seen a huge variety of applications for our action tracker - Although it originated in the world of HAZOPS which are typically very high governance with multiple review stages our clients quickly realised that just about anything they wanted to track could be accommodated. We've described a few scenarios here:
Historically lessons-learned systems have been repositories where best practice from projects could be recorded, however unfortunately it is quite rare to achieve the expected value from the knowledge stored in such systems, mainly because they quickly become static 'silos' with no real incentive for people to either consult or update the data once it has been created. Typically the systems which succeed are those where knowledge is proactively shared - this means that stakeholders are personally informed about learnings which could benefit them - this makes it more likely that they will pause their busy schedule to engage with the information.
No matter what type of incident is being managed the priorities for an incident management system are the same - provide a way of recording all relevant data, and allocating important actions . because incidents can be very fast moving in the early stages it is vital that systems don't get in the way while also allowing complete flexibility to capture all relevant data - for example photos, witness statements etc. It's also very useful to be able to record root cause/contributing factors as the incident progresses. Crucially any actions generated as a result of an incident - e.g. a corrective action need to be managed in a controlled way to ensure that all stakeholders are kept informed and nothing slips through the net. When we achieved our ISO27001 accreditation we found that ATMS provided a great way to manage any Info sec incidents - logs and other data could be easily attached and the configurable workflow and transparent communication around action closure helped us to sail through the last 6 years' audits
Although practically every business has a slightly different way of recording and categorising risk there is generally a risk description, pre and post mitigation matrices and a set of actions to mitigate the risk. Our customers should be able to to configure their data capture, matrices and workflows to exactly match their internal risk management process and the associated actions should be easy to manage with a high degree of governance and accountability
The actual data captured will be different but the principles are the same - it's important that the data captured exactly matches the specific requirements of the audit, and that any resulting actions are easy to manage with an appropriate level of governance - some audits may not require anyone but the actionee/responsible person to close them while others may require one or more' review stages' or 'Gates' which must be approved before close-out.
Controlling access and tracking changes
Many of the systems described here can be ( to a point) replicated in tools like Excel, however there are two areas where Excel is not very effective: Managing access and tracking changes. Controlling the people who can edit/view a spreadsheet is possible with considerable effort and if you have a management system like Sharepoint it is possible to see previous versions of a spreadsheet, but it's not going to be a granular, field by field record of what was changed. Ideally a management system should allow access to be controlled at company/department/team and individual level so that project teams can be formed across companies. Auditability on a field by field basis should be built in so that an audit trail of all changes to every field can be viewed at any time.