Power BI consultancy in Zug: what it costs, what breaks and what to build first

Power BI is rarely the thing that is broken in a Zug reporting estate. What is broken is that the business logic lives in twelve separate files, each maintained by whoever needed it first.

Zug is large enough that most organisations here already have several analytics teams and the problem is reconciling them. With around 32,000 people in the city itself and roughly 130,000 across the wider urban area and an economy built on commodity trading, asset and wealth management, and software and technology, the reporting questions here are specific rather than generic, and so are the ways they go wrong. This page sets out what a Power BI engagement in Zug actually involves: the metrics we check first, what it costs, how licensing should be chosen, whether you would be better off hiring, and what the compliance position looks like under the revised Federal Act on Data Protection (revFADP / revDSG), in force since September 2023.

Why reporting breaks in Zug specifically

Generic advice about Power BI is not very useful, because the failure modes follow the industry rather than the tool. Zug's economy is weighted towards commodity trading, asset and wealth management, and software and technology, with one of Europe's densest concentrations of commodity trading and holding companies and a well-known blockchain and digital assets cluster shaping much of the local employment base. That mix produces a predictable set of reporting problems, and we have seen each of them here more than once.

Asset and wealth management

Position, transaction and valuation data arriving from custodians and portfolio systems on different cycles, with market data licensed under terms that restrict redistribution.

The characteristic failure is this: reporting built on the custodian feed and reporting built on the portfolio system disagree, and nobody owns the reconciliation between them. Where that has already happened, the first deliverable is not a dashboard. It is a written reconciliation that establishes which number is correct and why. In practice we start by building a position and valuation model with an explicit as-at dimension, so every figure states the valuation date it was computed on.

Typical source systems: portfolio management system, custodian files, order management system, market data feeds and CRM. Client identity is subject to professional secrecy duties in several of our markets, and market data licences frequently prohibit onward distribution through a BI tool.

Fintech and payments

Event-level transaction and authorisation data at very high volume, with settlement arriving later and often reconciling imperfectly against the event stream.

Here the recurring problem is different: product analytics tooling is treated as the system of record for revenue, so finance and product publish different numbers to different audiences. The fix is a reconciled transaction model joining authorisation events to settlement records, with breaks as a first-class entity rather than an exception report. PCI DSS scope should be deliberately limited in the analytics estate, which means tokenising or excluding card data rather than landing it and securing it.

Professional and legal services

Time, billing and pipeline data where almost every meaningful figure is an allocation, and where confidentiality obligations constrain who may see matter-level detail. Four definitions of utilisation circulate simultaneously, so partner behaviour responds to whichever figure appears in the meeting they attend.

We would usually begin with a time, billing and WIP model with one agreed utilisation and realisation definition, reported from practice group down to individual under agreed visibility rules. Source systems to expect: practice management system, time recording, professional services automation, CRM and finance system.

The metrics we check first in a Zug engagement

Sector knowledge in analytics is mostly knowing which definitions destroy a number when they drift. Before we design anything we go through the measures that matter to you and establish, in writing, exactly how each one is calculated and who owns that definition. The table below is the starting list for Zug, derived from the industries that dominate here.

None of this is exotic. If a number can be calculated two reasonable ways, it eventually is, and the difference turns into a standing explanation rather than a decision. The output of this stage is a measure dictionary: every KPI, its business definition, its owner, and the DAX that implements it.

What a first Power BI engagement looks like

We work the same way whether the client is a large group with nine existing workspaces: decisions first, sources second, model third, reports last. Reports built before the model are the single most common cause of rework.

1. Decision inventory, week 1We start from the recurring decisions that need numbers, not from the data that happens to be available. Who decides, on what cadence, and what currently blocks them. For a Zug business in asset and wealth management, that usually surfaces three or four decisions worth building for and a dozen reports nobody needs.
2. Source profiling, weeks 1 to 2Each source system profiled for grain, volume, change tracking, quality and refresh window. portfolio management system, custodian files and order management system are the usual candidates here. This is where unpleasant surprises belong, not in week ten.
3. Model build, weeks 3 to 7A star schema with conformed dimensions, measures written against the agreed definitions, and row-level security applied from the start. For asset and wealth management the argument that has to be settled first is normally assets under management, where multi-share-class and mandate-level double counting, plus FX translated at the wrong rate date. Settle it before any report exists, not after two of them disagree.
4. Report build and validation, weeks 6 to 10Reports built with the people who will use them and validated line by line against the source of record until the numbers tie out. Disagreements get resolved and written down, never averaged.
5. Handover, weeks 10 to 14Workshops with your team, documentation in your own systems, and a thirty-day period where we fix what breaks while your people drive. Zug draws on the Zurich and Lucerne labour markets; local supply is small relative to the number of corporate headquarters.

What that costs

Build cost follows project size rather than report count, the number of source systems and their state drive almost all of it. These are the bands we quote in Switzerland, and we publish them because a buyer cannot start an approval chain without a budget figure.

Running it afterwards is a separate line: CHF 3,000 to CHF 8,000 a month for a small estate, CHF 8,000 to CHF 20,000 for a mid-sized one, CHF 20,000 to CHF 50,000+ for a large multi-domain platform. Microsoft licensing is separate again, and is covered next.

Licensing: what Zug organisations should actually pay

This is where money is most often wasted, in both directions. Power BI Pro is listed at around US$14 per user per month and Power BI Premium Per User at around US$24 following the 2025 price revision. Local list prices in sterling, euro and Swiss francs track those figures with regional adjustment, and enterprise agreements usually land below list.

The arithmetic that matters: F64 only becomes cheaper than per-user licensing somewhere in the region of 350 to 600 readers, depending on the discount you actually pay and whether you reserve capacity. Below that, Pro or PPU per user is normally the right answer, and buying capacity for prestige is a straightforward waste of money.

For larger Zug organisations with hundreds of report consumers, a capacity SKU is usually the right answer, and which one depends on measured consumption rather than headcount. We profile workloads on a short-lived trial capacity before anyone signs.

Always price from the current Microsoft rate card for your region and agreement. Any figure in an article older than a quarter should be treated as an order of magnitude, not a quote.

Hiring in Zug versus engaging a consultancy

This is a fair question and the honest answer is sometimes "hire". Zug draws on the Zurich and Lucerne labour markets; local supply is small relative to the number of corporate headquarters. Locally, a mid-level analytics engineer costs roughly CHF 110,000 to CHF 160,000, with Zurich and Zug at the top. An experienced external consultant runs at roughly CHF 1,300 to CHF 2,200 per day.

Where a Zug client has told us they intend to build an internal team, we design for it from the start. We build on the assumption that we leave. That means a model your own engineers can change without us, naming that needs no explanation, documentation inside your systems rather than ours, and a measure dictionary that still makes sense in two years. Several clients have gone on to need us only for quarterly review, which is a perfectly good outcome.

Data residency and compliance for Zug organisations

Switzerland North and Switzerland West give in-country residency, which matters more here than almost anywhere else in Europe: banking secrecy, professional secrecy obligations and client expectation all push Swiss data to stay Swiss. Verify per service, because not every Azure or Fabric feature is available in both Swiss regions. In practice, Zug deployments normally use Switzerland North (Zurich), with Switzerland West (Geneva) as the paired region.

Regulatory oversight relevant to analytics comes from the Federal Data Protection and Information Commissioner (FDPIC / EDÖB) under the revised Federal Act on Data Protection (revFADP / revDSG), in force since September 2023, plus the sector bodies that matter here: FINMA for banking, insurance and asset management supervision, including outsourcing circulars, FDPIC for federal data protection oversight and ElCom for electricity market and grid reporting.

• The revFADP brought Swiss law closer to the GDPR but not identical to it: records of processing, impact assessments and breach notification follow Swiss rules, and an EU-shaped compliance pack needs adapting rather than copying.
• FINMA outsourcing expectations require documented control over cloud providers, including the right to audit and a tested exit plan.
• Article 321 of the Criminal Code and sectoral secrecy duties restrict who may see client-identifying data, which has direct consequences for row-level security design.

We cover this properly on the data governance and compliance page, and in more depth in our article on data governance for Zug organisations.

How we deliver into Zug

• Swiss engagements are precise about scope and documentation, and tolerate fewer surprises than UK projects.
• Multilingual stakeholder groups are normal: German-speaking head office, French-speaking region, English-language group reporting.
• Expect strict supplier onboarding, including security questionnaires and in some cases background checks before any data access.

Delivery is remote-first with on-site workshops at the points where being in the room genuinely helps: definition sessions, validation and go-live. We work in German, French, Italian and English, and stakeholder sessions run in whichever of those the room prefers.

How a Zug organisation actually buys this

Most consultancy pages stop at what the work is and leave the buying process to email. Relationship-led but heavily documented, with supplier due diligence that goes further than anywhere else in our markets, particularly in banking and pharmaceuticals.

In the private sector: A relationship and a reference open the door; a formal supplier onboarding then decides whether the work can proceed. Expect a security questionnaire, financial checks and, in financial services, an outsourcing assessment against the FINMA circular with documented audit rights and a tested exit plan. Background checks on individual engineers are routine in banking, and some clients require that named staff never move data outside Switzerland.

In the public sector: Federal and cantonal bodies publish on SIMAP under BöB at federal level and IVöB at cantonal level, with WTO/GPA thresholds determining the procedure. Cantonal rules differ, and language requirements follow the canton.

Documents you should expect to request, and that any supplier worth shortlisting will have ready, are handelsregisterauszug, current commercial register extract, betreibungsregisterauszug, a debt enforcement register extract, requested more often than people expect, insurance certificates including professional indemnity, in chf cover levels and data processing agreement drafted against the revfadp, not a translated eu template.

Our own entity details, insurance, processing agreements and contracting shapes are published on the procurement page, so your buying team can start without waiting for a reply.

Signals it is time to call someone

The usual triggers are two reports disagreeing on a headline number, an overnight refresh someone re-runs by hand each morning, a largest model that is one file owned by one person, finance still rebuilding the board pack in a spreadsheet, a legacy BI renewal whose price no longer makes sense, or a question about who can see a sensitive dataset that took a week to answer honestly. If two or more are true, a two to three week paid discovery will tell you what to do about it, and you keep the output whether or not you engage us further. Book a technical review, or read what we actually build:

We work across Switzerland and deliver into neighbouring markets regularly. Nearby pages worth reading if your group has sites elsewhere: Zurich, Geneva, Lausanne, Baden, Lugano and Schaffhausen.

Frequently asked questions