Twiggy in your organisation

How teams in banks and other regulated organisations put Twiggy to work: one place where everyone can see how the work is really done, who owns it, what can go wrong and what keeps it in check, signed off and kept current.

The idea

Most organisations already have process documents. They are hard to find, out of date the day they are approved, and disconnected from the risk register, the control library and the systems list. Twiggy keeps the process, its risks, controls, systems and obligations in one model. Owners sign it off, it comes back for review on a schedule, and anyone who needs it can read it.

Playbooks

Operational risk and controls

Show, process by process, where each risk arises and which control deals with it. That is the heart of a risk and control self-assessment.

Import your risks and controls into the Risks and Controls registers from your GRC tool's export (CSV or Excel). Category columns become the hierarchy, and the import shows exactly what will change first.
Link risks and controls to the steps where they apply: type in a step's Details, drag items from the explorer onto the diagram, or link many steps at once in the Linker.
Record which control mitigates which risk in the register, and see the gaps in Insights. Ask the AI to find the gaps and suggest controls.
Colour the map by risk rating with a lens to see where the exposure sits.
Signed-off processes come back for review sooner when they carry higher risks: every 6 months for critical, every 12 for high.

Regulatory change

When a rule changes, know which processes and controls it touches, and prove the change was made.

Keep your obligations in the Requirements register, with regulator, jurisdiction and due date, grouped by regulation.
Link each obligation to the steps and controls that meet it. Each requirement's Where it is used panel lists every process and step that meets it.
When an obligation is replaced, retire it with its successor and move the processes that use it across in one go.
The changed processes go out for review and sign-off. The audit log and version history show who changed what, and when.

Critical operations and resilience

Standards such as APRA CPS 230 ask you to identify critical operations and the people, technology and service providers they depend on. Twiggy helps you document that.

On the process map, model the operations end to end, and mark the critical ones with a property (Administration › Properties, for example Critical operation: yes).
Put the systems each step relies on in the Applications register, with criticality and owner, and add a register of your own for service providers if you need one.
Use where-used and lenses to answer “if this system or provider fails, which critical operations stop?”
Owners sign off each critical operation's flows, with an e-signature setting for the most critical ones.

Process improvement

Find where time and effort go, design the better way, and keep the before and after.

Interview the people who do the work with the AI: it models live and asks about exceptions.
Add your own properties (volume, pain point, automation potential) and colour the map with a lens to see hot spots.
Ask the AI to find waste and sketch a simpler future state. Keep it as a variant of today's process, so both stay side by side.
Run workshops in Present mode, and export to BPMN for teams that build in other tools.

Training and onboarding

New starters learn the real process, not last year's slide deck.

Give new starters the process map as their orientation: where their team fits, and who they hand over to.
Walk them through a flow in Present mode, step by step, with the details of each step on screen.
Ask the AI to explain a process for a new starter, or to draft work instructions for one role.
Readers always see the signed-off version, even while a new revision is being worked on. Viewers and reviewers don't need a modeller seat.

Audit and assurance

Evidence that the process is documented, owned, approved and reviewed on time, without chasing people.

Folders give each area an owning team (who is Responsible, Accountable, Consulted and Informed), and models there need sign-off by the Accountable people.
Every sign-off is recorded with who, when and what they approved. Each model keeps its version history, and the audit log keeps the rest, for as long as you set.
The governance view lists what is due for review, overdue or awaiting sign-off, and Insights shows the gaps: risks with no control, requirements nothing meets, retired items still in use.
Export registers to CSV, and models as text or BPMN, for auditors.

Rolling it out

Weeks 1–2: the map. One modeller and one senior sponsor model the process map: the handful of enterprise processes and their areas. Set up folders and owning teams to match.
Weeks 2–4: registers. Import roles, applications, risks, controls and obligations from what you have. Name an owner for each register.
Weeks 3–8: the first flows. Pick the 10 to 20 processes that matter most (critical, high-risk or changing). Interview the people who do the work with the AI, link risks and controls, then send each for review and sign-off.
From month 3: business as usual. Review cycles bring each process back on time. New processes and changes go through the same review, and the risk team checks the gaps.

Who does what

Process owners are Accountable for their folders: they sign off and keep processes current.
Modellers (a modeller seat each) build and change models, usually with the AI and the people who do the work.
Subject-matter experts are interviewed, and review and sign off from an emailed link. No seat needed.
The risk and compliance teams own the registers, check the gaps, and approve proposed controls and obligations.
Admins manage people, sign-in rules, the domains allowed in, and audit settings.

Security and data handling: see Security. For a pilot, single sign-on, or a security review, talk to us.