Decision to prepare
Which functions should be retained, which upgrades are needed and how should options be compared?
Chrysalid · Educational example / version 1.0 / 20 September 2026
Fictional industrial IT acquisition assessment pack
Use your browser’s Print function to save this pack as a PDF or print it.
ENTIRELY FICTIONAL DECISION PACK. The applications and findings below are invented to demonstrate the deliverables. They are not findings from a client engagement. No illustrative pricing is presented.
1. Decision scope
An investor is preparing the integration of an industrial laboratory. Demonstration assumptions: one site, 40 LIMS users and three interfaces to inventory. A LIMS is a laboratory information management system. STARLIMS is mentioned as an example of a customized LIMS, not as a vendor assessment or a vulnerability claim.
Evidence to collect
Versions, agreements, interfaces, business workflows, backups and acceptance requirements.
2. An actionable application map
Each record connects usage, dependencies and missing evidence. “To confirm” does not mean “non-compliant”.
| ID / application | Usage | Dependencies | Missing evidence |
|---|---|---|---|
| APP-01 Customized LIMS | Samples, results and approval | ERP, instruments, identities | Document version, support agreement and customizations |
| APP-02 ERP–LIMS interfaces | Reference data and work orders | Files and scheduled processing | Confirm ownership, retry controls and monitoring |
| APP-03 Local reporting | Operational indicators | LIMS exports and reporting sheets | Validate business rules and actual usage with business teams |
3. Risks to investigate before commitment
This example contains evidence gaps. The pack records the possible consequence, required verification and owner rather than assigning an unsupported score.
R-01 · Undocumented support
Do not infer obsolescence without the version and agreement.
Evidence required: Agreement, version inventory, support confirmation
Proposed owner: IT / vendor
R-02 · Interface recovery not demonstrated
An interface failure could delay processing.
Evidence required: Recovery test and exchanged-data checks
Proposed owner: Integration / business
R-03 · Restore not demonstrated
A backup does not establish usable recovery.
Evidence required: Isolated restore and validation of critical workflows
Proposed owner: Infrastructure / business
R-04 · Uncertain acceptance effort
Applicable requirements and customizations may affect cost.
Evidence required: Scope, requirements traceability and test plan
Proposed owner: Quality / business
4. A mockup to document the requirements
The mockup completes the available documentation. It describes the functionality in use, business rules and criteria to preserve before preparing adaptation, modernization or replacement.
Illustrative workflow
Order received → sample registered → result entered → authorized review → transfer to ERP.
No real data, instrument access or actual approval.
Comparable criteria
Role-based access, change traceability, retrying failed transfers, record export and recovery. Applicable requirements must be confirmed during scoping.
5. Decisions and gates to prepare
The target is selected from business needs, risks and collected evidence. Retention remains appropriate when supported by support arrangements, security, recovery and business fit.
Confirm scope
Agree applications, ownership and accessible evidence.
Resolve priority unknowns
Confirm support, test an isolated restore and assess interfaces.
Document and validate functionality
Complete mockups and business rules with application owners before choosing modernization or replacement.
Decide and plan
Jointly validate which applications to retain, secure, adapt or document, then establish the action schedule and operational deadlines.
This pack is not a commitment on price, timing, savings or regulatory compliance. It demonstrates how a decision is documented and what remains to be substantiated.