Canonical product model
Normalize product, share-class, performance, benchmark, holdings, commentary, and disclosure fields with a named source and owner for each value.
Representative implementation
Automating a multi-product factsheet operation without weakening review
A representative operating design for producing fund and strategy factsheets from controlled data, commentary, disclosure, validation, and approval workflows.
Firm profile
A boutique asset manager with mutual funds, ETFs, and separately managed strategies. Product, marketing, operations, and compliance share responsibility for quarterly materials, but no single system owns the complete publication workflow.
Operating trigger
The product set and number of required output variants have outgrown a spreadsheet-and-desktop-publishing process. Production begins only after quarter-end files arrive, leaving little time to investigate exceptions or complete review.
Systems in scope
The workflow crosses system boundaries.
Current state
What makes the workflow break down.
Operations combines administrator files, product attributes, benchmark data, holdings, and prior-period workbooks by hand.
Product and portfolio teams provide commentary through email, creating uncertainty about the current approved version.
Disclosures are copied from prior materials and reviewed late in the cycle, when layout changes are most disruptive.
PDFs and website values can be updated through separate processes, allowing the two publication channels to diverge.
Review status is tracked through filenames, inbox history, and individual knowledge rather than a shared queue.
Solution architecture
A controlled operating design.
Validation layer
Run completeness, date, tolerance, benchmark, formatting, and period-over-period checks before content enters layout.
Controlled composition
Generate tables, charts, narrative blocks, and disclosure sections from reusable templates rather than manually editing every page.
Review and publication
Route exceptions and proofs to named owners, capture approvals, and publish web and PDF outputs from the same approved release.
Implementation sequence
Prove the workflow before expanding it.
Map one representative product
Document every source field, calculation, review decision, disclosure rule, and output variant for a product with meaningful complexity.
Build the data contract
Define expected files, identifiers, dates, formats, validation rules, late-arrival behavior, and ownership for every input.
Create and compare outputs
Generate the new output alongside the existing process for multiple periods and reconcile every material difference.
Expand by product family
Add products only after templates, exceptions, and approval responsibilities are stable for the prior group.
Controls
What keeps the workflow dependable.
- Immutable source files and release-level version history
- Explicit calculation and rounding rules
- Named product, compliance, and publication approvals
- Exception blocking for missing or out-of-tolerance values
- Environment separation between draft, approved, and published outputs
Target state
What changes after implementation.
- Teams work from one release record showing source readiness, exceptions, commentary, disclosures, proofs, and approvals.
- Reviewers focus on material changes and exceptions instead of manually locating every value.
- PDF and web factsheets use the same approved data and content release.
- A new product or share class is configured through mappings and rules rather than a separate manual workflow.
Measurement
Metrics to baseline and track.
Hours per product per reporting cycle
Time from final source arrival to approved publication
Number and age of open exceptions
Corrections found after first proof and after publication
Percentage of output fields populated from controlled sources
Evidence note
The appropriate calculations, disclosures, reviewers, and record-retention requirements remain the responsibility of the asset manager and its approved legal and compliance process.
Have a version of this workflow inside your firm?
We can map the current state, identify a credible first release, and define the controls and measures required to operate it.
Discuss this use case