Working with existing automations

Use this workflow to weave existing RPA bots into one coordinated, end-to-end process instead of rebuilding them.

Use this workflow when you already have working automations that each do a valuable job in isolation, and you want Cartographer to weave them into a single, coordinated end-to-end process with visibility, controls, and SLAs — the "automation islands" situation: trusted bots, no process connecting them. The goal is to reuse what works, replace only the manual glue between the bots, and add new capability only where the assets can't reach.

開始する前に

Gathering your assets

Cartographer designs best when it can read your automations, not just hear about them. For each bot you want to reuse, have a description ready that covers:

• What it does and what triggers it (schedule, queue, manual, or API)
• Its inputs and outputs — file formats, queue-item structures, the exact fields it reads and writes
• Which systems it touches and how (screen/UI vs. API), since that determines how reusable it is
• How it handles exceptions, and who owns it
• Whether it is business-critical or compliance-scoped (for example, SoX)

Give each asset a stable reference (for example, a CoE code) and ask Cartographer to refer to it by that code throughout. That single habit keeps the current-state map, the future design, and the final document all pointing at the same real thing.

Setting up the business process

In your project instructions, state the reuse intent explicitly — for example: "I have several existing RPA bots I want to reuse. Document the current process, keep track of the existing assets, and design a future end-to-end orchestration that reuses them, replacing only the manual glue." Being explicit here is what puts Cartographer into constrained, reuse-first mode.

ワークフロー

Capturing the current state from the assets

Open with something like "Begin to document the current process; keep track of the existing assets and reuse them." Cartographer reads your asset descriptions and builds a current-state picture: a process map, the systems and data each bot uses, the hand-offs between them, and a list of pain points. Let it finish before you discuss the future design — the current-state map is the anchor everything traces back to.

Correcting how each asset really fits

Cartographer makes its best guess at how the assets connect, and it may guess wrong. Correct it plainly — for example, "that approval bot is a separate downstream process; it does not touch commissions." Cartographer re-draws the map and keeps the corrected asset available for reuse rather than discarding it.

Deciding which assets belong in the future pipeline

Tell Cartographer which assets to reuse and where. You can reuse an asset even if it's separate today — just say so: "I want that approval bot to be part of the future automated pipeline; recommend where to place it." State your overall aim (for example, "automated end-to-end with minimal human evaluation, except where a control is essential"). Cartographer reasons from the assets' real inputs and outputs to find a placement that connects them without a rebuild.

Checking the data contracts between chained assets

Where one bot feeds another, confirm the outputs of the upstream asset actually satisfy the inputs of the downstream one — field names, formats, and structures. Mismatches here are the most common source of silent failure in a stitched-together pipeline.

Assigning an automation mode to every unit

Cartographer proposes automation units (one bot, or a natural cluster) and asks you to pick a mode for each — see Assigning automation modes. Choose by the nature of the work, not a blanket default. A good sign the design is sound: your existing bots keep running as Fully Automated tasks, human touchpoints exist only where a real control requires them, and new Agent units appear only where the bots genuinely can't reach.

Confirming the future shape before the detail

Cartographer presents the future-process shape (for example, "five automated, one human review, two agent — what needs to change?") and waits. This checkpoint matters: a change to the shape after the detail is written throws away work. Review the map, adjust, and only then confirm — a casual "looks good" is treated as approval, so be deliberate.

ヒント:

Force the data-passing question. Expressly request a disposition table and ask Cartographer to account for how data moves between nodes. Example: "Generate a PDD and include a disposition table on what has happened with each existing asset. Also call out how data is passed from node to node, taking into account potential differences in how each RPA communicates. Call out any gaps."

Reviewing controls, exceptions, and open decisions

After you confirm the shape, Cartographer writes the detail: business rules, exception handling, benefits, and a list of open decisions it deliberately did not guess (things like an approval tolerance threshold, the approver's channel, or the trigger mechanism). Treat that open-decisions list as your action list — each item is a real choice the build team will need answered.

Generating the process document

When the design is confirmed, ask Cartographer to generate the PDD. For a reuse scenario the document should carry more than a PDD written from scratch: an inventory of the reused assets, the reuse decision for each, the data contracts between them, a map from current-state to future-state, and a phased plan for getting there.

Tips and common pitfalls

• Feed the assets, don't just describe them. The design is only as good as the asset detail Cartographer can read.
• Reuse first, add second. Resist rebuilding a working bot; let orchestration wrap it and replace only the glue around it.
• Change intent freely — it will adapt. If you reclassify or re-place an asset mid-session, Cartographer re-works the design around the new intent.
• Watch for silent re-platforming. If reuse moves data from one system of record to another, treat that as a decision needing sign-off, not a detail.
• Confirm shared assets are yours to reuse. For a centrally-managed or third-party bot, check the owning team agrees and has capacity before building on it.
• Consider a staged path. Orchestrating the existing bots and replacing the glue is a valuable first phase on its own, with human touchpoints and modernization following later.

次のステップ

• AS-IS documentation — The Discovery and Define as-is interview mechanics, shared with the clean-start workflow
• TO-BE design and PDD generation — Automation modes and PDD generation, shared with the clean-start workflow
• Generating an SDD — Build-ready specification from the confirmed PDD