huzz-dotcom Analyze Complex Business Links
Purpose
Use this skill to turn messy complex business requirements into a clear product model. Focus on business abstraction: objects, documents, states, rules, exceptions, and system boundaries.
The core idea:
A complex business chain is not just a long flow. It is a set of business objects/documents changing state under rule constraints across roles and systems.
Default Workflow
1. Frame the Business Boundary
Start by defining scope before drawing flows or pages.
Answer:
- What business goal does this chain serve?
- What is the start event?
- What is the end condition?
- Who are the actors?
- Which systems participate?
- What is in scope now?
- What is explicitly out of scope?
Output a short boundary statement when the request is ambiguous.
2. Run the Main Flow, Then Branches
Describe the happy path first, then add branch and exception paths.
Use this order:
- Main flow
- Conditional branches
- Reverse/exception flow
- Cross-system failure or compensation
Do not jump directly into UI, fields, or APIs before the chain is clear.
3. Abstract Business Objects and Documents
Identify the stable business objects behind the flow. Treat documents/orders as carriers of business facts.
For each object/document, capture:
- Name
- Business meaning
- Source or trigger
- Key fields or dimensions
- Lifecycle/state
- Related upstream and downstream objects
- Responsible system or owner
Common document types:
- Order / order item
- Payment record
- Inventory reservation
- Fulfillment task
- Delivery or verification record
- Receipt/completion record
- After-sales request
- Refund record
- Settlement bill
- Invoice or financial voucher
4. Separate State Dimensions
Avoid forcing everything into one coarse status like "processing".
Separate state dimensions when needed:
- Business/order state
- Payment state
- Fulfillment state
- After-sales state
- Settlement state
- Approval state
- Financial/accounting state
For each important state, clarify:
- Meaning
- Entry condition
- Allowed actions
- Exit condition
- Whether it is user-triggered, system-triggered, or external-system-triggered
5. Extract Rules From Narrative
Do not leave rules buried in paragraphs. Convert them into a rules table.
Rule categories:
- Eligibility/admission rules
- Validation rules
- Pricing/calculation rules
- Approval rules
- State transition rules
- Fulfillment rules
- Refund/after-sales rules
- Settlement rules
- Exception/compensation rules
Rule table columns:
| Rule | Trigger | Condition | Action | Exception | Owner/System |
|---|
6. Define System Boundaries
For cross-system chains, clarify responsibility explicitly.
Use this table:
| Business object | Created by | Source of truth | Can modify | Consumers | Notes |
|---|
Key questions:
- Which system owns the data?
- Which system only consumes results?
- Who can change status?
- How are failures retried or compensated?
- What happens if systems disagree?
Recommended Output Structure
When the user asks for analysis or PRD support, produce the answer in this order:
- Business boundary
- Simplified main flow
- Core objects/documents
- State dimensions
- Key rules
- Exception scenarios
- System responsibility boundaries
- Open questions or risks
Keep the first pass lightweight unless the user asks for full detail. Prefer a clear, usable model over an exhaustive enterprise architecture document.
Transaction Fulfillment Pattern
For familiar transaction fulfillment chains, start from this mental model:
Main flow:
- User submits order
- System validates product, price, inventory, promotion, and eligibility
- Order is created and awaits payment
- Payment succeeds or fails
- Inventory is reserved or deducted
- Fulfillment task is generated
- Merchant/warehouse/service provider fulfills
- Delivery, verification, or service completion is recorded
- After-sales may happen
- Settlement is generated based on order, payment, fulfillment, and after-sales result
Core objects:
| Object | Meaning |
|---|---|
| Order | User transaction agreement |
| Order item | Product-level quantity, price, and allocation |
| Payment record | Payment action and result |
| Inventory reservation | Stock lock or deduction |
| Fulfillment task | Delivery/service execution task |
| Delivery/verification record | Fulfillment process evidence |
| After-sales request | Refund, return, replacement, or compensation |
| Refund record | Reverse fund movement |
| Settlement bill | Merchant/supplier settlement basis |
Useful framing sentence:
Transaction fulfillment is not one flow. It is a group of documents generated, checked, reversed, and closed under business rules.
Quality Checklist
Before finalizing an analysis, verify:
- The start and end of the chain are clear.
- Core objects/documents are named.
- Object relationships are visible.
- States are separated by dimension where needed.
- Rules are tabled, not hidden in prose.
- Exception and reverse flows are included.
- System ownership is explicit.
- Remaining ambiguities are listed as questions.
Anti-Patterns
Avoid:
- Only drawing a process without identifying objects.
- Treating "order status" as the only state dimension.
- Mixing payment, fulfillment, after-sales, and settlement into one status.
- Writing rules as vague prose.
- Designing pages before clarifying the business model.
- Ignoring exceptions such as partial fulfillment, partial refund, retries, reversals, and compensation.
- Leaving system boundaries implicit.