Regulatory Compliance and Risk Management

How process-led approach helps to tackle regulations and risks

Whatever regulation you have to operate within, producing documentation and building a compliant management system can become a major overhead. While every system is intended to add value and support the people who need to operate within it, many management systems can become the proverbial “tail wagging the dog”.

When the end customer experience, flexibility, innovation, and commercial performance suffer due to “regulatory constraints”, it is often not the regulations themselves to blame, but the sheer complexity of building a management system to document and comply to the necessarily changed and constrained ways of working.

Leverage and enhance your existing compliance and risk systems using Elements

Firstly, we take our own information security very seriously, so that you CAN use it for compliance and risk-related documentation, even though it is based in the cloud. Elements has a highly secure software and operational architecture complying with numerous rigorous cloud security standards

Secondly, we can add enormous value to information stored in the most secure environments by providing a layer of context and visibility of process, that allows users to navigate to the highly secure supporting documentation to understand or carry out specific activities.

Sometimes a rigorous, compliance-driven structure of documentation, focused on the clauses of a set of regulations, makes it really hard to see how things actually work across an organization. The Elements Process Knowledge approach and capability can put all this detailed documentation into an accessible, useful context which engages people. This can have a major impact on enabling people to continually improve their working practices, while remaining compliant through better understanding and awareness of the impacts of doing or not doing certain things. It can also have a big impact on audits, for both the auditors and the organization preparing for and being audited.

Once you have a clearer process context, it becomes self evident to focus on what is right for the customer and the organizational goals. The organization’s common sense can increasingly prevail, with the regulatory constraints much more likely to be surfaced in context and, where necessary, challenged.

Time and again over the last 20+ years, we have seen situations where ‘“standard practice” was flawed but accepted because “we have to do it that way — it’s a compliance issue”. If you then ask what regulatory requirement is stopping a specific process improvement idea, the answer was surprisingly often: “actually, there is no reason we can’t change”. The issue was that the people involved didn’t understand the process implications well enough to ask the right questions and interpret the regulatory requirements in the right context. When faced with an incomplete or confusing picture, the human mind almost always says no. When regulatory compliance is on the line, the lack of context or clear picture means that things don’t get changed and decisions don’t get made. People are rightly cautious about making a mistake and causing a compliance issue. But the cumulative impact of that caution on the clockspeed and agility of the affected organization can be immense, and sometimes threaten not just competitiveness, but survival.

Thirdly, the process mapping contains many specific features that allow you to create and manage the documentation directly in managed Process Knowledge content showing “who needs to do what when, why and how” — to deliver on your organization’s objectives (and yet still be compliant).

Think of it as turning the typical documentation in an Operational Management system on its head.

Regulatory Centric Management System

Frequently a Management System is:

1. structured around the requirements of a given set of regulations
2. with high level policy documents
3. in parallel (and often related to) a list of procedural documents
4. that relate to sets of lower level procedures and work instructions
5. that may or may not contain visualisations of process. The process is often contained within paragraphs and bullet point lists in text-based documents.

Outcome? A documentation industry inside most organizations is hard to get your head around, engage with, maintain, improve, work to, audit, and (most importantly) change. So, often people try to limit change because “we’re in a regulated industry”. Is this really “because of compliance”…or because it’s just so hard to understand what’s going on and how to change it without breaking the management system?

Process Centric Compliance and Risk Management System

Whereas, it can be:

1. structured around a graphical hierarchy of process knowledge
2. the high level maps can easily describe the key activities and scope of responsibilities
3. the standard process knowledge building block already captures “who needs to do what, when, and why”
4. the structured hierarchy defines scope and context, into which high level policies can be attached
5. procedures can be simplified and shortened, since the diagrams describe most of the procedural information and structure.
6. the lowest level procedures are simply attached to activities
7. Lowest level work instructions are either replaced by diagrams or split into the instructions representing a given step — and attached to an activity
8. Risk frameworks can be synced into Elements and related to individual activities across the process map. Business controls can be set up and managed — again, directly in the context of visible, understandable process knowledge.

The process content can then be managed and controlled as a compliant Management System itself, using the following principles and capabilities:

Elements Document Management principles

Elements Process Knowledge is architected as a secure Document Management solution. The Documents just happen to represent process knowledge with a particular format and set of attributes. There is also a hierarchy of documents (diagrams) with a specific syntax.

To draw a simple analogy, if all your Process Knowledge was in a book:

• You to decide who can edit the whole book and the individuals (inside and outside your team) who can view it.
• You to decide who owns the structure and who can edit which parts of the book, and manage who can view or edit content down to paragraphs within pages.
• You to manage versions of pages within the book, and the release of new editions with whole new chapters and minor edits. It manages the circulation of changes to all stakeholders who need to sign off. It manages the archives, the reviews, and the audit trail; and when everything is ready, the publishing, the distribution, and the recording of who has signed off as having read and understood it. It will even help them to give reviews and feedback so that the next edition of the book will be even better.