Results for tag "technical"

2 Articles

Reliance Python Git

Have published Python classes for use with ETQ’s object model in the Reliance framework.

Custom classes made available include Discussion, Document, Forum, and Inheritance.

These have been supplemented with code for managing constants, evaluating regular expressions, and toolkit snippets for ease of use.

Available on github.

Enwaitr Implementation Strategy

In the governance and regulatory compliance world, document controllers are mental, control freaks. Equipping myself with @evernote – I am a massive fan – and a dab of OCD, I decided to see if an implementation of document management was feasible. The first step towards a full-blown quality management system.

My findings are documented in the following, in a format that I hope will promote discussion by like-minded architects and adoption by like-minded controllers.

It’s all free. For now.

Prerequisites

Besides an understanding of EN, the only prerequisites were an appreciation of the limitations. This experiment did not have to consider the lack of a strict security model nor the human elements of the system. Ultimately it will be a business decision – either by cost/benefit or risk assessment – but these results were satisfactory.

Adding Notebooks

Three notebooks were created in a stack:

  1. EnWaitr\EnDocument as the notebook for published notes.
  2. EnWaitr\EnFactory as the notebook for draft notes.
  3. EnWaitr\EnMuseum as the notebook for obsolete and superseded notes.

This stack was intended to separate the differing responsibilities and roles in a document management system – principally authors and readers.

By sharing notebooks with individuals it was possible to establish a reader community that could view notes, as well as granting ‘author’ access enabling modification and distribution (invite).

Evernote Share Dialog

The EnDocument notebook was shared with the user community giving access to view notes, and the EnMuseum notebook was shared with a smaller group of users who could have cause to search this archive (audits, investigations, et al).

Adding Tags

Daily usage of EN has seen an established schema of tags to denote a status and associated customers. From this starting point and giving consideration to emailing into EN (discussed later), a structure to categorise and organise notes was established.

Usage of a hyphen prefix to identify the type of note gave the following tags:

  • -policy
  • -procedure
  • -process

Usage of an exclamation point to manage the status of a note gave the following tags:

  • !draft
  • !feedback
  • !obsolete
  • !completed
  • !superseded

No prefix was used to determine the audience and distribution of a note. Be it an arrangement by team, division, company, or location, the following tags serve as readership roles:

  • allusers
  • developers
  • managers
  • testers

An alternative to character prefixes would be a textual hierarchy – it works with colon separators – such as ‘type : policy’, ‘status : draft’, and ‘europe : uk : england : london’, but for brevity this was not implemented.

Generating Content

Putting the meat onto the bones.

Creating a new note in the EnFactory notebook and tagging with ‘!draft -procedure allusers’ for example, there were a number data items required. The experience led to a number of best practice decisions:

Title

The format for a note title was decided upon to satisfy two requirements – a schema for identification and a structure that fitted with other notes. Sound the OCD alarm. The elements of the title schema were:

  • ‘Business Document’ + document type + ‘-‘ + document number + ‘.’ + revision number + title

Some example titles then read:

  • Business Document POL-00001.01 Health & Safety
  • Business Document PRO-00001.01 Personnel Grievances

This would extend to note titles prefixed as ‘Business Action ACT…’, ‘Business Audit AUD…’, et al.

Author

The ‘Note Info’ dialog was used to modify the author of a note. By default this was the username of the authoring person, but was found to be a good place to record the ‘owner’ of a note and could be changed to text identifying those responsible in the business either by name (Paul Williams) or by job title (Health & Safety Manager).

Body

EN has a good rich-text editor that supports document and image attachments, but in this case a single attachment PDF generated from a Microsoft Word template was used. This gave access to the full comment/review functionality of the Office application and could then be simply converted to PDF.

The approach means document controllers can emblazon their documents with headers, footers, and corporate logos until their heart’s content. But it also formalises some of the other meta data required by a management system. The template included the following meta information:

  • Document Number
  • Document Owner
  • Document Revision
  • Document Title
  • Document Type
  • Effective Date

By viewing this PDF attachment inline, duplication of data in the note was avoided.

References

By copying note links into the note, relationships can be built between the system elements. Perhaps better thought of as references, these were added to a dedicated section of the note layout.

These same links can be used to list the contents of the the ‘quality manual’, generated in a dedicated note by selecting all published notes in EnDocument and opting to ‘Create Table of Contents Note’. Don’t forget to tag. This could then be added to shortcuts?

Staging Workflow

The essence of workflow in document control and quality management systems in general is simple. Someone creates content, someone else agrees/approves, and everyone else can then read/use it. This approach was adopted in the soft workflow, as represented in Bizagi.

En.Waitr.Workflow.Document 0.01

Feedback

Sharing an individual note by email proved to be the quickest method for getting feedback and approval. An ‘issue’ arose whereby attachments are not embedded inline in the email. Ultimately this would be improved by the use of note sharing and in-place annotation, but that will keep for another day.

By replacing the !draft tag with !feedback and leaving the note in the EnFactory notebook, management proved simple. Combined with reminders, the lapsed period of opportunity could be controlled.

Completed

Having considered any feedback – perhaps warranting a status tag change to !draft and further feedback – the status of a note was tagged as !completed and then moved to the EnDocument notebook. With this notebook already shared, the user community at large could now view the appropriate documentation.

Superseded

Revising an existing note proved the most reliant on user intervention. IFTTT recipes or some API work might add finesse, but a manual process is still feasible and practical.

Having identified the !completed note in EnDocument, the note would the be duplicated into EnFactory, incrementing the revision number, and tagging the status as !draft. When this note was approved and reached the !completed status it was moved from EnFactory to EnDocument, and the old revision tagged as !superseded and moved to EnMuseum.

Obsolete

When a note reached the end of its lifespan it was simple to tag its status as !obsolete and move to the EnMuseum notebook.

With no restrictions possible, the system would be reliant on adherence to best practices – to moving documents to EnMuseum – rather than deletion.

Finding Notes

Views

The EN views offer a degree of flexibility in their columns, and is useful to have the title, tags, and author represented. Each to their own. With the tagging schema in place for readership and reading lists the tag based filtering proved useful.

Searching

Speaks for itself. Has a few annoying quirks, but good at locating content in rich-text and attachments.

Starting Templates

Having predetermined ‘template’ notes offered a good way of standardising content and making a DOTX attachment readily available. These seemed like a sensible investment. Stored in the EnFactory notebook, a copy of the template could be created and developed. It’s an approach already adopted for documenting agendas, minutes, and actions.

Extending The Notebooks

With an eye on the next release of this methodology, the vision would see additional notebooks in the stack:

  • EnWaitr\EnAction as the notebook for corrective and preventive actions.
  • EnWaitr\EnAudit as the notebook for audit schedules and checklists.

Not an exhaustive list, but a flavour of what could come next.

Extending The System

Both Penultimate and Skitch could add gloss to the system, but are not yet formalised. The vision would be for them to be used when reviewing or approving content by annotation, et al.

Past versions of notes are available in Note History. Being available as a value-add to premium users it is as yet unseen, but the expectation is that it would be great for satisfying the requirements of an audit or investigation.

Integration with the IFTTT service is limited but advancements could be forthcoming.

Perhaps the most realistic usage of EN in a management system would be as a method of delivery rather than production. Publishing via email can be triggered by process-driven software like Bizagi, or from a full-implementation management system like Reliance. Having generated content and been through tightly-controlled rounds of review and approval, a converted PDF version could be mailed into a shared EnDocument notebook. Nice.

References

Emailing Into Evernote Just Got Better, Andrew Sinkov
http://blog.evernote.com/blog/2010/03/16/emailing-into-evernote-just-got-better/

Connect Evernote with Other Services You Use with IFTTT, Kasey Fleisher Hickey
http://blog.evernote.com/blog/2011/12/30/trunk-spotlight-ifttt-to-connect-evernote-with-other-services-you-use/