Skip to content
PERINGER Data Solutions, back to home

Back

Solution

The operations file

The question isn’t only whether IT works, but whether an authorised third party can perform priority tasks with the available access and dependencies. The record becomes evidence when another person actually uses it.

The knowledge written down nowhere

In practice

  • An architecture diagram readable by someone meeting the environment for the first time
  • An inventory of hardware, software, licences and access, with their dates
  • A dependency map: what falls over if a given machine stops
  • Operating procedures per task, written to be followed without you
  • Contacts and contracts: suppliers, support numbers, renewal dates
  • A versioned, dated document, with a review scheduled rather than hoped for

Systems involved

  • Inventory and asset management tools already in place
  • The directory and the password manager, for the access list
  • Backup systems, for what is genuinely protected
  • A Git repository or an internal knowledge base, to hold it
  • Contracts and supplier portals, for the renewal dates

Service lineServers and hosting →

How it runs

  1. Survey

    The survey takes as long as the systems, suppliers, access paths, exceptions and sources demand. The scope gets set before any console opens.

  2. Writing

    Diagram, inventory and dependencies, written for a reader who has never seen the environment.

  3. Test

    One procedure is followed by somebody else, to the letter. What is missing shows up immediately.

  4. Upkeep

    A dated review, and the simple rule that an architecture change gets written down as it happens.

Test the fit: The operations file

Describe the context, constraints and decision you need to make. The first conversation qualifies scope, boundaries and the next useful step.

Describe the situation