The Epistemology of Living Organizations ― Theoretical Foundations and Practical Applications

Editor's Notes

• #32: Begin here to emphasize that organizations are organic entities whose continued existence depends on satisfying their imperatives for continued existence. Taking a holistic view of organizations and their problems that would benefit from architectural reengineering reduces the likelihood that important issues and the benefits from resolving them will be missed in the initial analyses. An important aspect of this analysis is to understand the organizational imperatives – both from the viewpoint of an independent observer, and from what the organization itself thinks are its imperatives. The latter are ordinarily expressed in high-level formal documents within the organization. However, such documents are often platitudinous and do not reflect true situations.
• #33: Direct Business Drivers for Performance Based Logistics? Warranty Latent Defects Operational Availability Assessment Period Our Build Program for ANZAC is winding down, so we are shifting to In Service focus for ANZACS. This presentation will focus in the data management needs in this in-service environment. Warranty & Latent Defect Clearly important from a Tenix perspective Data to support warranty claim resolution with customers, suppliers and sub constractors Includes time of install, serial number, planned design usage profiles Operational Availability Assessment Took 10 ship years of operation data (4 x 1, 3 x 2, 2 x 3, 1 x 4) Everything done in that time recorded Sparing activities Failures Maintenance This was designed to uncover issues Proud to say the ILS package survived the test well, only requiring minor tweaks. This was a very large logistics expertise – one of the largest we’ve ever conducted because of the amount of data involved. Used OARRS (operational assessment recording & reporting), superceded by CSARS (???) Constant refinement of ship support package based on operational performance metrics. E.g. recommending reduced sparing holdings to save $, Or recommending part super-session by reviewing failure analysis Lead into product lifecycle management and the product data management to support this.
• #34: What are the overriding goals for the delivery of operational knowledge to fleet managers and operators? Correct and consistent - use same words to describe the same actions wherever they occur. Applicable and Effective Availability of the documentation - this is an important issue. (It didn't exist for Longford.) Explicitly documented knowledge is useless if it sits on a shelf and isn't readily accessed when and where decisions need to be made. (Westralia?? Sensible procedural documentation existed . Why wasn't it followed?) Usable - discoverable, understandable and relevant to the end user (e.g., an operator or maintainer) and manageable in whatever kind of knowledge management environment the fleet operator uses. (Library shelves full of paper manuals is one form of knowledge management - a bad one) Capturing, managing and delivering knowledge is a cost and risk burden Minimise cycle times - new information and changes must be deployed to the end-users when and where they need it Maximise quality - knowledge capture, production processes must deliver a high quality product or the product won't be used or will cause more problems than it solves. Minimise costs - data/documentation is a cost against the needed capability to be minimised wherever possible - but not at the expense of increasing risk. "Faster, better, cheaper" - but not at the risk of catastrophe. Up front saving is worthless if the project fails - e.g., the Mars Lander.
• #36: Explicit knowledge for a long lived project is expressed in its documentation. Project documentation is developed through a number of phases, and at least for defence engineering projects the same information and knowledge is often contained in many different documents, in both similar contexts and in different contexts. A major issue is to manage this redundant content consistently over the life-cycle in relation to changing product configurations and to reflect project experience. The remainder of the presentation discusses architectures and tools we have implemented in Tenix to do these things.
• #37: This slide shows the complete knowledge cycle for ANZAC Ship maintenance procedures. The green area encompasses the parts of the system implemented by Tenix (now being managed by the ANZAC Alliance). The knowledge to manage maintenance is originally assimilated from a number of sources including system and component definitions maintained in the ILS Database into text and maintenance management metadata by technical authors and ILS analysts according to the maintenance philosophies developed in the technical maintenance plans. Authoring now takes place under control of the TeraText DB. Released documents and associated maintenance management metadata are transferred electronically into the AMPS system. When a maintenance procedure is triggered and the job raised, AMPS prints instructions to the maintainer(s), who do the job and enter completion details back into AMPS. Job histories (including spares use and maintainer comments) are periodically downloaded into the CSARS system for analysis. Analysis will highlight systems with low availability or high maintenance costs for attention, and will help to define causes of the problems. On further investigation, engineering or documentation changes will be suggested, defined and implemented. Part of the engineering change process is to incorporate configuration and documentation changes into the maintenance procedures and associated metadata, which are then fed back into the AMPS system as the engineering changes become applicable and effective.
• #38: Although we were delivering a high quality of wordprocessed documentation, the client threatened not to accept the 5th ship unless we solved the data quality issues impaired AMPS's ability to link all of the metadata contained in the routines. We were also required to enter new H&S warnings and cautions into virtually every routine. The document conversion to SGML had to satisfy these requirements for the deliverable to be acceptable to the client. 4,000 (one each RAN and RNZN) ship specific WordPerfect routines were converted to SGML. These were reviewed and the latest routine of each type was edited to produce a dual language instance applicable to the whole class of 10 ships. Edits included adding new warnings and cautions to almost all routines, standardising the routines’ logical structures, checking for consistency between line item lists and text references, and rewriting many routines to improve consistency for the relevant systems and routines of that type. This conversion process stress tested the system far beyond what any normal authoring process would have: with more than 6000 live documents in the repository (RAN, RNZN and Class), and more than 2,000 active workflow items. W e could not have managed to enter all the warnings and cautions in the WordPerfect environment and maintain any semblance of document quality - which would very likely would have triggered the payment of liquidated damages against a failed Ship acceptance. By doing everything required to move the documents into SGML in the TeraText environment, we saved the bacon. Volume reduction was achieved primarily by single sourcing (one routine applies to both RAN and RNZN fleets and can apply to more than one configuration item on each ship). Data delivery is the difference producing between full ship-sets each year to delivering net changes against the class set in near real time. We eliminated a significant “documentation quality” issue which could not have been realistically solved in our WordPerfect environment, and which could have indefinitely delayed acceptance of our fifth ship.