KII business OS / Operations first
Make the first 90 days executable, Operations first.
This document turns the proposed engagement into the decisions, access, source material, named owners, and acceptance evidence KII and the delivery team need before implementation starts. Fill it in before kickoff and confirm it in the first Friday review.
WHAT KII PROVIDES
People, access, and real work
One named owner per decision, read-only access to the current systems, a small set of representative Operations examples, a data center environment for the install, and a 30-minute interview slot per team member.
WHAT AGENCY MIOSA PROVIDES
Delivery, governance, and handover
The foundation installed on KII infrastructure, the Operations vertical slice, Microsoft Teams integration via Microsoft Graph, documentation and runbooks, admin training, and full source handover in KII's own repository by Day 90.
How this document is used: KII completes the owner table, the access table, and the policy inputs before kickoff. Agency MIOSA converts the confirmed answers into the environment plan, the access plan, and the acceptance checks for each milestone.
ON-SITE
One week in Zurich
Included in the price, with travel and lodging covered by Agency MIOSA.
RHYTHM
Friday review
A 30 to 60 minute review, a written weekly status, and recorded decisions.
OWNERSHIP
KII owns the platform
Source, modules, configuration, and documentation live in KII's own repository.
02 Named owners before kickoff
06 Department sequence
03 Systems and access
07 Security and policy inputs
04 Representative Operations examples
08 Kickoff gate and confirmation
05 Roadmap, Day 0 to Day 90
Named owners before kickoff
Every decision has one accountable person, not a committee.
Name the person who owns each decision. Where a decision needs a second signature, the second signature is confirmation, not a second owner. Owners are needed by Day 0 unless the table states otherwise.
| Role | Decides | Name (fill in) | Needed by |
|---|
| Executive sponsor | Confirms scope, milestone acceptance, and any change to dates. | | Day 0 |
| Engineering evaluator | Reviews the architecture, integration approach, and technical acceptance. | | Day 0 |
| Business and budget owner | Approves the commercial schedule, invoices, and any scope change. | | Day 0 |
| Operations owner | Owns the Operations pilot, the workflows, and daily user acceptance. | | Day 0 |
| Security and data owner | Approves access methods, data handling, and the Data Management Plan. | | Day 0 |
| Teams and Microsoft 365 admin | Grants Microsoft Graph access and confirms tenant policy for the integration. | | Day 10 |
| Data center and infrastructure owner | Approves the install environment, the network path, and the internal model endpoint. | | Day 10 |
Escalation: any blocked access or policy decision goes to the named owner with a written 24-hour response path. Agency MIOSA records the ruling in the decision log.
Schedule rule: a delay in these client decisions moves the affected milestone. The delivery team will not invent authority, data meaning, or acceptance criteria to preserve a date.
Read-only mirror, the current tools keep running
Connect the current systems without disrupting live operations.
Agency MIOSA reads from the current systems through a mirror layer. Nothing writes to a production system without the approval of an authorized KII role. Access type is stated for each system.
| System | What we need | Access type | Owner | Ready |
|---|
| Autotask | Accounts, contracts, tickets, and time entries for the Operations mirror. | Read-only mirror | | □ |
| KII ERP (in progress) | Current schema, APIs, and a staging environment as it replaces Autotask. | Read-only mirror, API | | □ |
| Ticketing | Ticket sources, status fields, priority rules, and escalation paths. | Read-only mirror | | □ |
| Time billing | Time entries and billing rules tied to tickets and cases. | Read-only mirror | | □ |
| Microsoft Teams via Microsoft Graph | Graph application access to meetings and channels, with tenant consent. | Microsoft Graph API | | □ |
| Repositories | Read access to current code, then a KII-owned target repository for the fork. | Read, then admin on KII repo | | □ |
| Documentation | Existing documentation as it stands, so it is reused and completed, not rewritten. | Read-only | | □ |
| Internal RAG | Current retrieval setup, sources, and embedding approach for reuse. | Read-only, API | | □ |
| vLLM endpoint and model | Endpoint details and the model name that serves operations. | API | | □ |
| Data center environment | Target hosts, network path, storage, and a service account for the install. | Admin, install | | □ |
| Accounting systems (later) | Read-only integration in a later phase. Migration is out of scope for these 90 days. | Read-only, later phase | | □ |
Do not send by email: production secrets, shared administrator credentials, or unredacted client data. Credentials are exchanged through KII's approved method and stored under the Data Management Plan.
Measure the system against real work
Prepare a small set of real examples, then confirm the expected result.
SIGNALS
- A set of real signals from client environments
- Expected classification and routing for each
- Known duplicates and ambiguous cases
- Thresholds for an urgent signal
TICKETS
- Open and closed tickets across priorities
- Examples of priority changes
- Escalation and handover examples
- Expected status at each step
CASES
- Representative cases with owner and history
- Resolution notes and linked tickets
- At least one case that went wrong
- Expected summary for each case
TIME ENTRIES
- Time entries tied to tickets and cases
- Billing rules and rounding
- Examples that are unclear or disputed
- Expected billing output
A HANDOVER EXAMPLE
- One task that moves from one person to another
- The context each person needs
- Where the context currently lives
- What full context would include
A CLIENT REPORT
- One periodic report KII sends to a client
- Source data and manual steps
- Review and approval before sending
- Expected content and layout
How these are handled: examples are read through the mirror layer, stay on KII infrastructure, and are governed by the Data Management Plan. If KII stops after the Operations pilot, KII keeps everything delivered to that point and Agency MIOSA disposes of KII data as the plan states.
| Acceptance attribute | What KII confirms | Owner |
|---|
| Correct | What outcome counts as correct, including allowed variance. | |
| Complete | Which fields, evidence, and actions must be present. | |
| Timely | The maximum acceptable response time. | |
| Safe | Which actions require human approval, or are prohibited. | |
KII confirms these four attributes once, and every milestone is measured against them.
Ninety days, four milestones
From signature to a governed, owned platform, one department at a time.
DAYS 0 TO 10Mobilize (remote)
ON-SITE WEEKOperations audit and install
DAY 30M1 Operations pilot
DAY 45M2 Operations live
DAY 70M3 Second department wave
DAY 90M4 Company rollout and handover
| Milestone | Days | What is delivered | Acceptance | Invoice |
|---|
| M1 Mobilization and Operations Pilot | Days 0 to 30 | NDA and Data Management Plan countersigned, access, environment plan, 30-minute interviews, one on-site week, foundation installed on KII infrastructure, Operations pilot running on mirrored data with human approval gates. | Operations pilot runs on mirrored data with approval gates, confirmed in the Friday review. | USD 30,000 at signature |
| M2 Operations Live | Day 45 | Real users live, Microsoft Teams integration via Microsoft Graph, shared project workspace with session handoff, role and data governance. | Accepted with real users working in the system. | USD 30,000 on acceptance |
| M3 Second Department Wave | Day 70 | The second department chosen at kickoff, plus SOP and documentation completion. | Department live and SOP accepted. | USD 30,000 on acceptance |
| M4 Company Rollout and Handover | Day 90 | Remaining in-scope departments, runbooks, admin training, and full source handover in KII's own repository. | Handover accepted and admin training complete. | USD 30,000 on acceptance |
AFTER DAY 90
Accounting migration
A later phase, quoted separately. Accounting is integrated read-only first.
AFTER DAY 90
Deeper agent automation
More agent authority inside the governance model already accepted.
AFTER DAY 90
Other group companies
Optional expansion, under separate agreements and separate scopes.
After Day 90 is not included in the price. It is listed so KII can plan. Weekly rhythm throughout: a Friday review of 30 to 60 minutes, a written weekly status, and recorded decisions.
Operations first, then the next wave
One department proves the model, then it spreads on evidence.
WAVE ONE / OPERATIONS
Signals, tickets, cases, time billing
Operations runs through the busiest, most measurable work in the company and every step leaves a record. It is the smallest slice that proves governed shared context in real conditions.
DOCUMENTATION COMPLETION PLAN
30 to 40 percent toward complete, in parallel
- Reuse existing repositories and documentation as they stand.
- Document the Operations workflow as it is mapped on-site.
- Move documentation from about 30 to 40 percent toward complete.
- Company glossary so people and agents use KII's terms.
WAVE TWO / CANDIDATES
Chosen at kickoff
- Service delivery
- Sales and client management
- Administration and finance, excluding accounting migration
The second wave is confirmed in the first Friday review, based on the criteria on the right.
SELECTION CRITERIA
- Enough real signal volume to test the model.
- Systems ready enough to mirror read-only.
- An owner available for the Friday review.
- A measurable acceptance result.
- Low disruption risk to live operations.
- Direct value to the Operations team already live.
Principle: one foundation, then one department at a time. Each wave is accepted before the next begins, so KII always sees a working result before committing more of the organization to it.
WHAT WAVE TWO NEEDS
- A named owner from the department.
- Its systems mirrored read-only.
- Its own representative examples.
- A first Friday review date.
WHAT STAYS THE SAME
- One foundation, one governance model, one glossary.
- The same read-only mirror and human approval gates.
- The same Friday review rhythm.
- The same source handover into KII's repository.
Policy before production data
State the control, then let the platform follow it.
The platform is governed at three levels: user, role, and data. These inputs define the boundary. Agency MIOSA needs each item in writing before production data enters the system.
| Input | What KII provides | Owner | Needed by |
|---|
| Data classification | Levels, labels, and which levels may enter the platform and the mirror. | | Day 0 |
| Access methods | Approved remote access, network path, and credential handling. | | Day 0 |
| Model usage policy | What the internal model on vLLM may handle, and where frontier models are allowed for research only. | | Day 10 |
| Retention | How long data is kept, and what is deleted at the end of the engagement. | | Day 10 |
| Incident contacts | Named contacts and the escalation path for a security incident. | | Day 0 |
| Client notification requirements | When and how KII's clients are told who handles their data. | | Day 10 |
| Swiss FADP and EU GDPR | Data residency, subject access, and deletion obligations that apply to KII and its clients. | | Day 10 |
Fixed by design: everything runs on-prem in KII's own data center. Operations use the internal model served through vLLM. Data stays on KII infrastructure, and remote access follows KII-approved methods only.
Required before production: the security and data owner approves the access methods, the retention rules, and the model usage policy. Until then, only mirrored data in a controlled environment is used.
GOVERNED AT THE USER LEVEL
Each person signs in with their own identity, and sessions are visible to the team according to role.
GOVERNED AT THE ROLE LEVEL
A role decides what a person may see and do, and which actions need an approval gate.
GOVERNED AT THE DATA LEVEL
Classification decides which records and data levels may enter the mirror and the workspace.
Readiness and confirmation
Start when the inputs are owned, accessible, and testable.
BEFORE DAY 0
- SOW signed by both parties
- NDA and Data Management Plan signed
- All owners named in the owner table
- Kickoff date set
BEFORE THE ON-SITE WEEK
- Access granted for the listed systems
- Representative Operations examples prepared
- On-site dates and location confirmed in Zurich
- Friday review slot set in the calendar
Readiness item
Ready
Owner
Date
SOW signed by both parties
□
NDA and Data Management Plan signed
□
Executive sponsor and acceptance authority named
□
Access granted for the listed systems
□
Representative Operations examples prepared
□
On-site week dates and location confirmed
□
Friday review slot and escalation path set
□
| Confirmation | Name | Role | Signature | Date |
|---|
| KII | | | | |
| Agency MIOSA | Roberto H. Luna | Principal Architect and Engagement Lead | | |
Definition of ready: every critical input has a named owner, an approved access path, and a testable acceptance consequence.
Agency MIOSA