> ## Knowledge Base Index
> Fetch the complete knowledge base index at: https://help.vicronix.net/sitemap.xml
> Use this file to discover available pages before exploring further.
> Pure-Markdown content can be obtained by appending a '.md' suffix to the content URLs listed in the sitemap (without the trailing slash).

# Shematix – Procedure & Contents

# Shematix – How the process works

| (Discovery → Blueprinting → Roadmap)

If you want a project to survive reality, you don’t start by building. You start by making the chaos measurable.
Shematix is our concept & planning phase. We sit down with you, analyze your project, check what’s technically and organizationally feasible, and turn it into a realistic, clearly structured concept.

---
### 

### What you can expect from Shematix

Shematix covers: **current-state analysis, feasibility, goal definition, resource & time planning, requirements engineering**—and results in a structured concept/planning document that can be used for our next modules or external implementation.

In practice, we run Shematix in three phases:
1. **Discovery** → understand the real problem + define measurable goals
2. **Blueprinting** → convert findings into a precise plan (digital or physical)
3. **Roadmap** → tools/components/skills + realistic schedule, priorities, responsibilities, resources

| That structure is exactly how our service flow is designed.

---

### Phase 1: Discovery (understand it before we touch it)

**Goal:** build a shared, concrete understanding of what you’re trying to achieve—and what you’re not.

We start with:
* **Target outcome:** what “success” means (measurable, testable). 
* **Scope boundaries:** what’s included, what’s out-of-scope (so we don’t drift).
* **System & process landscape:** which systems, processes, devices, people are involved.
* **Constraints:** timeline, budget reality, compliance, infrastructure limitations.
* **Risks & unknowns:** things that could break the plan later (and how we de-risk early).
* **Assumptions log:** what we believe to be true *for now*—so we can validate or kill it fast.

What we actively do in Discovery (typical outputs inside the concept):
* Break the project into **functional units** and define what each unit must do. 
* Define **requirements** (must/should/could) and translate them into acceptance criteria. 
* Capture **feasibility checkpoints** (technical + organizational). 

| Why it matters: Discovery prevents the classic “we built the wrong thing perfectly” scenario.

---

### Phase 2: Blueprinting (turn analysis into a plan you can implement)

**Goal:** convert Discovery into a plan with structure, interfaces, steps—and zero hand-waving.

We blueprint:
* **Processes & flows:** what happens when, in which order, and why.
* **Interfaces & touchpoints:** system-to-system, human-to-system, device-to-system. 
* **Architecture & implementation steps:** how we get from current state → target state (digital or physical). 

Typical Blueprinting artifacts (depending on your project type):
* **System sketch / architecture map** (components + connections)
* **Process maps** (e.g., onboarding flow, support flow, automation flow)
* **Integration outline** (what data moves where, and under which rules)
* **Implementation sequence** (the order that avoids dependency traps)

| From our side, Blueprinting is the “bridge between idea and implementation.” 

---

### Phase 3: Roadmap (make it real: tools, people, time, budget)

**Goal:** define what is needed to build this—*and when it happens*.

We determine:
* Which **tools, components, and skills** are required. 
* A realistic view on **hardware, software, time, budget**. 
* A schedule that defines **priorities, responsibilities, and technical resources**. 

What the Roadmap usually contains:
* **Phases & milestones** (what gets delivered when)
* **Dependencies** (what must happen before the next step can start)
* **Resource plan** (who does what: you / your team / VICRONIX / third parties)
* **Decision points** (what you need to approve, and when)
* **Risk mitigation plan** (what we do if a key assumption fails)

| Result: you know exactly what the next step is. 

---

### Output (what you receive)

At the end, you get a **precise concept document / project plan** as the foundation for implementation—often as a digital document (typically PDF). 

Depending on your use case, it can include:
* Technical specification
* Digital wireframe
* System sketch / architecture overview
* Implementation-ready plan that lets development/installation start immediately 

| “Clear, structured, with no unanswered questions” is the benchmark. 

---