Adoption paths: roles, tasks and shared integrations

Status, 29 October 2026: strategy and selection criteria. This is not a claim that every integration listed here is available. See the separate Odoo pilot readiness record.

One product, several jobs

The proposed shared Tvijo layer handles tasks, access, limits, logs and verifiable results. System adapters and scenario packages sit above it. The public wiki explains value and limitations; private repositories hold commercial implementation; customer configuration and data stay separate from both.

A “MCP for BAS” page can describe a discovery proposal. Its name does not require a separate server, repository or subscription. For BAS, BAF and 1C, first record the exact platform and configuration, version, access method, data owner and task. Similar names do not establish compatibility.

A different API or permission model warrants an adapter. Different deployment, dependencies, licensing or support cycles may warrant a package. Customer data isolation warrants a separate customer boundary. Choose repository boundaries after establishing these needs.

Start with a role and a task

For analytics, MCP supplies access. ARIMA, Prophet, boosting, ETL and SQL require their own demonstrated work. An employer's requirements do not establish our skills or demand for an MCP product.

Sequence

1. Choose one audience. Developers and small integrators are the initial hypothesis because they fit the existing Tvijo clients. A committed ERP customer may change this priority.
2. Record the task and baseline. Review one Odoo diff or reconcile one inventory report. Give each its own acceptance criteria.
3. Run a bounded demonstration. Begin with synthetic or authorized data. Record limitations and stop conditions.
4. Offer a scoped paid pilot. Agree scope, price, access, outcome and acceptance before connecting systems. Pricing remains a commercial hypothesis until economics are measured.
5. Measure repeat use. First result, paid pilot, repeated task, support and renewal are distinct events.
6. Package a repeatable scenario. Add an ERP adapter after validating demand and technical access. BAS, BAF and 1C remain discovery proposals.

Three paths to a pilot

Task discovery: a customer's question → worked example → demonstration → qualification → pilot → repeated use.

Existing tools: a user already works in VS Code or another supported client → connection guide → a verified first task → team package. Test the exact client version. Naming another product does not establish a partnership.

Learning: role → short guide → practical exercise → result review → optional pilot. Use adoption psychology to explain limitations, encourage independent checks and discuss workload. Fear of falling behind, pressure on employees and guaranteed productivity claims are not part of the offer.

Partnership with mutual benefit

The integrator keeps the customer relationship and leads ERP implementation. Tvijo supplies the agreed AI scenario, technical boundaries and support for its component. An education project may teach; an external evaluator may assess. Before joint sales, agree responsibility for data, support, payment, materials and public claims. Discuss commissions against actual margin. No invented percentages or “official partner” labels.

Comparisons should help buyers choose, including when an existing tool or direct ERP report is a better fit. Email volume and bot comments do not prove value. No promotional messages were sent as part of this work.

Next: choose an ERP scenario, agree evaluation criteria and plan practical evidence.