Lean Documentation Management: Yonder’s Modular Approach

Reliable and efficient documentation management has never been more relevant. The main reason being that organizations tend to accumulate more information than in the past and that this increase in volume is likely to be accompanied by a similar rise in complexity of that information.

Factors favoring the aforementioned complexity include but are not limited to compliance-related aspects, the need for reusability of content in different contexts (e.g. different documents or systems, provision of limited information to a third party for collaboration purposes, etc.), the dynamic nature of the information per se and its dependencies to external factors or triggers.

Based on these considerations and the observation that end-users are increasingly overwhelmed by the sheer amount of information they’re exposed to, it certainly makes sense for companies to explore solutions that are specifically designed to facilitate reliable and transparent documentation management for the relevant stakeholders (e.g. compliance teams, document owners, subject matter experts) while being capable of limiting the output for the end-user to what’s truly relevant for their role within (or even outside) the organization.

But what exactly should they be looking for?

Here at Yonder, we’ve been asking us this very question from day one and came to the conclusion, that these requirements are best reflected by taking a modular approach to documentation management. But what does that mean and how can your organization benefit from this approach? The following sections will answer this question in detail, starting with the definition of a term that will be central to our discussions: The Information Module.

By its most simple definition, Information Modules (or just modules) are discrete units of information that can be enriched with additional information. Individual modules, which can be as short as one sentence or a table row, are therefore capable of carrying information and to enable functionalities that go beyond simply displaying static content.

Organizations often seem to confuse the process of digitization with translating physical paper into PDF based documents or other formats that look like PDF. Here at Yonder, we believe that classic documents are a concept from the past and a roadblock to realizing the full potential of what digitization is truly capable of.

Actually, for the lack of a better term there are also documents in Yonder. In reality however, a document in Yonder is merely a container that holds a collection of information modules (figure 1) that is by no means bound to the typical limitations inherent to classic documents.

Consider the following benefits:

Instead of dealing with rigid page lengths, that still stem from the physical paper, Yonder allows you to display all of the information grouped together according to what makes sense.

“But what if I do need to print or export a document to PDF?”, you may ask. Well, that’s the beauty of it: Since there’s a strict separation of content and layout in Yonder documents, one can define an unlimited range of style sheets in the background that consequently allow for a given document to be exported to the desired PDF layout – including reformation of content to traditional pages, of course. Let it be known however that we at Yonder strongly believe that exporting content to static PDF should be seen as a measure of last resort rather than the norm.

As alluded to before, documents in Yonder are merely a collection of information modules. One of the resulting benefits is that a given piece of information really only needs to exist once in Yonder, since any module can be copy-pasted from one document to another in sync. Or in other words: Whenever the source module is being changed, it will be automatically updated wherever it’s been reused, thereby avoiding outdated duplicates and conflicting information that may otherwise be scattered across the documentation landscape.

Or to put it in more general terms: The ability to reference content between documents is yet another aspect that ensures scalability of your documentation at max efficiency and reliability. Figure 2 shows a schematic example.

By now we’ve established that information modules are discrete units of content that can be enriched with additional information, including metadata and tags. But what does that mean exactly and how can your organization benefit from refinable modules with dynamic capabilities? The following sections shed light on some of the major implications involved.

Display Temporary Information

Modules can have a limited validity attached to them. Hence, whenever a piece of information is of temporary nature, it can be reflected accordingly by dynamically displaying the related modules for the corresponding period only.

Limit Visible Content within a Document: Role & Topic-Based Filters

As alluded to earlier, end-users are increasingly overwhelmed by the sheer amount of information they’re exposed to on a daily basis. While that is frustrating enough as it is, it also bares the risk that users fail to locate the truly relevant information crucial to their role and mission. For that reason, Yonder allows for individual modules to be tagged with additional information that consequently allows to filter the content within a document based on these tags. This will limit the visible content of a given document to what’s relevant to someone’s particular role within the company, thereby allowing each function to focus on what’s truly relevant.

Or in other words: Filters for specific tags can be preset according to the user’s role, consequently allowing to limit document-specific content to what’s relevant to a user’s specific role and mission within the company. Whiles users may apply filters manually, it is even possible to connect Yonder to your organization’s Active Directory (AD) to pull the user’s preset role when logging in. And yes: Even rows within a table can be selectively displayed in that way, if so desired. Figure 3 shows a random example of filters applied for an A320 pilot in one of our customer’s manuals.

The increase in information volume in today’s day and age is directly linked to a similar rise in information-complexity, due to the manifold dependencies that may exist between a company’s documentation and external stakeholders. Keeping track of these dependencies across the documentation landscape and managing the necessary changes to the related content both reliably and efficiently, should therefore be a basic requirement in lean documentation management. So, how can Yonder’s modular approach help you reach these objectives?

Let’s take a compliance-related example for illustrational purposes:

You may remember that individual information modules can not only carry additional information (e.g. tags), but also provide additional functionality. One of these allows to directly link a module to its corresponding regulation via dedicated providers: Any change to a referenced regulation triggers an automatic change request for the information module at hand, thereby proactively informing the relevant stakeholders and enabling them to take action based on dedicated compliance workflows (figure 5).

Or in other words: Compliance is ensured all the way down to the module level at all times by triggering automatic change requests whenever content-related regulations change. Thus, dependencies are always well monitored and manual tracking of such items across the documentation landscape can be avoided at last.

We are convinced that lean documentation management must not only be capable of mapping internal revision procedures faithfully, but also allow for users to be notified explicitly on changes in content that actually have an impact on their role and mission.

Yonder allows you to reflect your internal revision and approval procedures without compromise, even allowing for external parties to be included if so required. To that end, it’s worth mentioning that subject matter experts (SMEs) can issue their change requests once again on the information module level, consequently allowing the relevant stakeholders to further discuss and potentially approve the input right in Yonder, on the module level as well. Aside from the fact that doing so will result in a seamless audit and revision trail at all times, there are additional benefits to consider:

Yonder Workflows: Classify Change Requests & Enable Module Specific Approvals

Yonder’s flexible workflow capabilities easily qualify for a dedicated article on its own, which is why I will refrain from elaborating on its extensive functionalities in great detail at this point. As previously mentioned however, SMEs may issue their change requests right on the information module level within a given document, thereby triggering the related workflow procedure.

Typically (although not mandatory by any means), the first step of a given workflow will then allow to further classify the change request for the module at hand, for example as a major, minor, or editorial change. Or in other words: A given change request can initially be classified by a central function (e.g. compliance team) based on its potential impact, consequently allowing the remainder of the approval process to branch out dynamically, thus ensuring that only stakeholders explicitly required for a given workflow step are invited to the virtual table, so to speak.

Speaking of virtual tables: Change requests are not only issued on the module level, but enable for all of the collaboration to take place on that level in Yonder as well. Meaning that all of the discussions related to a potential module-change can take place right in the respective content, even allowing users to attach additional files whenever it makes sense (e.g. to support someone’s view on a particular change request). Yet another added benefit is that such changes can finally be discussed asynchronously and independent of someone’s location, thus drastically reducing the need for physical approval meetings to take place.

In short: Module-based workflow procedures trigger the right set of stakeholders at the right time, allowing for seamless virtual collaboration that is geared towards transparency and accountability by default.

Role-based Revision Updates

Once the approval procedure for a given information module has been finalized and therefore is “Ready for Publish”, it can also be specified which user groups (or roles) have to be proactively informed about the change at hand, once the revised document as a whole is being published.

So, instead of having to go through lengthy highlights of revision in order to assess whether a given change may actually have an impact on my role, I get an explicit notification on all of the module-changes that actually do affect my scope of duties (including instructions on whether I merely have to read the item or also have to actively acknowledge having done so, by means of clicking on an ‘Acknowledge’ button).

Figure 6 shows an example of two notifications that were triggered for a particular user group after the latest revision of an operation manual.