Process mapping establishes how a business record moves from the first request to a completed, paid piece of work. Seichō follows that record through each decision, identifying who has authority and where information is entered again. Exceptions have named owners, and the existing cost is measured before a replacement is designed. That gives automation a defined job and the business a basis for judging its return.
Process mapping follows the record through the business.
A department chart describes reporting relationships. A process map describes what happens to a piece of work. The useful starting point is the record that carries the commercial commitment: a job, an order or an instruction. Its journey crosses departments because the commitment continues after one person's task is complete. The map holds that journey together from receipt through delivery to the point at which the obligation is settled.
The record needs a clear beginning and end. For a service job, the beginning is the accepted request and the end includes the invoice. Defining those boundaries keeps preparation and administration within the same view as the work being sold. It also establishes what counts as a completed unit when the business measures cost. A map ending at delivery leaves the remaining billing work outside its account of the process.
Business process mapping at Seichō follows an actual record through the people and systems that handle it. The description distinguishes the evidence held in the record from the knowledge someone supplies from memory. Where a decision depends on an email, that email belongs in the account of the current state. The map records the work as it runs, including the steps that sit between the formal stages.
Each decision carries its authority.
A box marked approval says little about the decision itself. The map establishes what is being approved, the information available at that point and the person authorised to commit the business. Approval of a price carries a different responsibility from confirmation that a file is ready for delivery. Combining them under one status conceals the conditions that the eventual system must enforce.
The decision also needs an outcome that the next step can use. An approved price becomes part of the job record, with the approval retained beside it. A rejection leaves a reason and a named owner for the next decision. Where responsibility passes between roles, the map makes that transfer explicit. This is how a working map becomes a specification for access and approval rules.
Authority remains with a role even when software carries out the resulting action. A system can create a folder after a job is accepted because the acceptance has already been established. A commercial exception requires its own decision. Seichō separates those conditions before choosing which steps will run automatically. The distinction determines where the system proceeds and where it waits for a person.
Repeated entry reveals the joins in the work.
Each place where information is entered again deserves a place on the map. The same job reference appearing in a calendar, a folder name and an invoice connects several activities to one commitment. The map identifies the source of each value and the systems that receive it. It then establishes whether the later entry adds a decision or repeats information already agreed.
Repeated entry has consequences beyond the time spent typing. A changed date needs to reach every place that relies on it. A revised price needs to remain attached to the right job. The current state records how those changes travel and who confirms that they have arrived. That account exposes the coordination work required to keep separate copies in agreement.
The future state assigns a source to each piece of information. Other systems receive the values they need from that source, under defined rules. This allows specialist tools to remain in use while the operating record holds the agreed position. The design also states which changes require approval before they reach scheduling or billing. Connecting the systems follows the decision about which record has authority.
One project record carries a property shoot to invoice.
The property operating study gives this method a concrete setting. Its commercial objective was to support higher shoot volume within existing coordination capacity. Requests arrive from estate-agency teams, CSV imports and photographer calendars. Each request has to reach a billable record. Following that obligation gives the process a boundary wider than booking a photographer or delivering a set of files.
In the delivered system, one project record connects the shoot to scheduling, files, delivery and billing. Each new record triggers calendar synchronisation and creates the project folders. Client-specific pricing carries the shoot through to invoicing and delivery. The same record supplies the information that these steps require, replacing separate hand-offs with defined actions. Branch access limits each branch to its own records.
The mapping method makes the reason for that design visible. The project is the continuing commercial unit, so its identity survives each change of stage. Scheduling and folder creation follow from information already held against it. Pricing remains connected to the work being invoiced. A map organised only around departmental tasks would leave those connections harder to specify and harder to test.
The study records a 45% reduction in operating costs while scaling. Its measurement note states the basis: Coordination and administration cost per completed shoot, the 12 months before launch against the 12 months after, while shoot volume grew. This is the measured result of the operating system in use. It provides evidence for the connected record in this operation; it does not set a promised saving for another business.
Exceptions belong within the process and have owners.
The standard route describes work that meets the agreed conditions. The map also needs to account for work that falls outside them. A changed request or an incomplete record requires a decision about what happens next. The exception remains attached to the commercial record, with an owner who can resolve it. Its status explains why the usual route has paused.
An exception route needs the same precision as the ordinary one. The record states what triggered the referral and what information the owner needs. It also states the authority required to release the work. A resolved exception returns to a defined point in the process, carrying the decision forward. This prevents an informal approval from disappearing when the job resumes.
The exception routes establish the boundary between routine execution and judgement. Software follows the agreed rule when its conditions hold; the responsible person decides when they do not. A map that includes both routes gives the business a process it can run and inspect.
The baseline precedes the proposed change.
A process map becomes commercially useful when the existing work has a measured cost. Seichō establishes that baseline before designing the replacement. The unit of measurement follows the record: cost per completed shoot in the property example. The observation period and completion rule remain part of the measure, so a later comparison refers to the same work.
Handling time and elapsed time answer different questions. Handling time accounts for the labour a record consumes. Elapsed time includes the periods when the record waits for information or a decision. A shorter queue creates value differently from a reduction in administration. Recording both gives the proposed change a specific objective and prevents one measure from standing in for another.
Volume belongs beside the cost measure because the business is commissioning a system to operate under changing demand. The property result compares coordination and administration cost per completed shoot across two twelve-month periods while volume grew. That basis explains the figure more precisely than a percentage alone. It keeps the measure attached to the operating work whose cost changed.
The future state is a decision the business can test.
The proposed map describes the same commercial journey under the new arrangement. It shows where the record originates and which information it supplies to each step. Decision authority remains visible, as do the exceptions that require a person. Every proposed connection has a purpose within that journey. Automation earns its place through the work it removes or the control it establishes.
The comparison between current state and future state then becomes specific. A repeated entry disappears because a source record supplies the value. An approval becomes traceable because its outcome is retained against the job. The baseline gives each proposed change a commercial reference. These are the grounds on which the business can agree scope before implementation begins.
This is the discipline behind Seichō's Operating Model Diagnostic. The record and its decisions establish what the system must do, while the baseline establishes why the work is justified. The completed map carries enough detail to test the proposed arrangement against real work. It gives the business a defined operating change to commission and a result to measure afterwards.