- Roles
- Business Analyst | AI & Digital Projects | PSM I & PSPO I | KPIs & BI Dashboards | Process Design & Modelling
- Bio
- Agile Business Analyst with practical experience building KPI frameworks, BI dashboards, and process structures from scratch. Replaced manual sales reporting with an interactive CRM dashboard, documented processes in BPMN, and contributed to AI projects across life sciences, healthcare, logistics, and telecom.
Comfortable operating at the boundary of business and IT by facilitating cross-functional reviews, managing backlogs, and keeping technical and non-technical stakeholders aligned. Currently expanding into Pandas and Power BI to bring more depth to the data side of the role. - Skills
- BPMN | Methodologies
Agile | Methodologies
Scrum | Methodologies
Kanban | Methodologies
Jira & Confluence | Platforms & Tools
Camunda | Platforms & Tools
HubSpot | Platforms & Tools
Microsoft Office | Platforms & Tools
German (native) | Languages
English (business proficient) | Languages
Italian (basic conversational skills) | Languages
Portuguese (basic conversational skills) | Languages
Python | Programming (Working Knowledge)
SQL | Programming (Working Knowledge)
Git | Programming (Working Knowledge)
Pandas | Ongoing Self Study
Power BI | Ongoing Self Study
AI Concepts | Ongoing Self Study - Timeline
- ## Experience
Business Analyst | QuantumBasel Corp. | 05/2025 — 05/2026
Business Intern | QuantumBasel Corp. | 08/2024 — 04/2025
## Education
BSc Business Information Technology | University of Applied Sciences Nordwestschweiz | 2020 — 2024
GPA 5.7 /6
Draughtsman EFZ in Architecture with Technical Baccalaureate | Ferrara Architekten AG | 2015 – 2019
## Certifications
Professional Scrum Product Owner (PSPO l) | Scrum.org | 2026
Professional Scrum Master (PSM l) | Scrum.org | 2025 - Philosophy
- <p>
I started out as an architectural draughtsman before moving into business and tech. One thing from that apprenticeship still shapes how I work. The people who design something are usually not the people who have to live with it afterward, and once a project is technically finished, that gap gets easy to lose sight of.
<p>
<p>
I try to stay close to it. When I replaced manual sales reporting with a CRM dashboard, getting the sales team to trust it enough to check every morning instead of falling back on spreadsheets took more work than the design itself. That meant sitting through complaints about a version I thought was already good, then rebuilding parts that worked fine technically but didn't match how the team actually made decisions. Documenting processes in BPMN taught a similar lesson. A diagram nobody reads doesn't fix anything, however accurate it is.
<p>
<p>
So before I optimize a process or hand someone a new tool, I ask who has to use it every day, and I expect my first version of the answer to be wrong. The business case and the technical architecture matter. They just don't hold up on their own if people don't actually use the thing.
<p>