Our Zurich data analytics projects follow a methodology adapted for Swiss business requirements: (1) Data assessment and strategy (weeks 1-3): understanding data before building dashboards. Data inventory: documenting all data sources — transactional systems (ERP, CRM, trading systems), operational databases, Excel files (yes — even in Zurich's sophisticated business environment, critical data often lives in Excel), external data sources (market data, regulatory reference data, demographic data), and unstructured data (documents, emails, log files). Data quality assessment: measuring accuracy, completeness, consistency, and timeliness of existing data. Swiss businesses: often having better data quality than global averages (the precision culture helps), but with specific issues — legacy Swiss-German system data with character encoding problems (umlauts), historical data from pre-merger entities with different coding schemes, and date/time data complicated by the fact that Switzerland shares a timezone with most of continental Europe but has different summer time conventions for older historical data. Analytics strategy: defining what questions the analytics must answer — not "build a dashboard" but "enable the CFO to understand margin by product line, customer segment, and region in under 5 minutes." Strategic analytics needs: aligned with business KPIs, documented with data sources and calculation methods, and prioritised by business impact. Swiss businesses typically prefer depth over breadth — fewer analytics use cases implemented thoroughly rather than many implemented superficially. (2) Data platform architecture (weeks 2-5): building the analytics foundation. Data warehouse design: dimensional modelling (Kimball methodology — fact tables and dimension tables) for business analytics. Swiss-specific design considerations: multi-currency (CHF as reporting currency with original transaction currencies maintained — exchange rate handling for historical analysis), multilingual dimensions (product names, customer names, and location names in multiple languages — stored as language-specific attributes), Swiss calendar (incorporating Swiss public holidays — which vary by canton: Zurich observes Sechseläuten, Geneva observes Escalade), and regulatory periods (fiscal years that may not align with calendar years, FINMA reporting periods, and Swissmedic reporting cycles). Technology selection: for Zurich businesses, the platform must balance analytical capability with data sovereignty. Cloud options: Snowflake (available on Azure Switzerland), Azure Synapse (native on Azure Switzerland), Google BigQuery (available but with data location configuration required), and Databricks (available on Azure Switzerland). Self-hosted: PostgreSQL with analytics extensions, Apache Spark for big data, and traditional data warehouse appliances for organisations with existing on-premises infrastructure. For financial services: the platform must support FINMA's expectations for data lineage, change management, and access control — often influencing the choice toward platforms with mature governance capabilities. ETL/ELT pipeline: building the data pipelines that extract data from source systems, transform it for analysis, and load it into the data warehouse. Tools: dbt (data build tool) for transformation logic (version-controlled SQL transformations — enabling audit trail and reproducibility), Airbyte or Fivetran for data extraction (pre-built connectors for common systems), and Airflow or Dagster for orchestration. Swiss-specific pipelines: SAP data extraction (for enterprises running SAP — extracting from SAP BW or direct table access), Abacus integration (for Swiss SMEs — Abacus doesn't have standard analytics connectors, requiring custom extraction), and SIX financial data (market data feeds — pricing, corporate actions, and reference data used across Swiss financial services). (3) Analytics and visualisation (weeks 4-7): building the insights layer. BI platform: Tableau (dominant in Swiss financial services), Power BI (for Microsoft-ecosystem organisations), Looker (for technically sophisticated teams comfortable with LookML), or Metabase (open-source — for cost-conscious organisations or those with data sovereignty requirements who want to self-host the BI layer). Dashboard design: Swiss business dashboards are functional, not decorative. The aesthetic: clean, precise, with every number accountable. Key design principles: data-to-ink ratio (maximising information, minimising visual noise — Swiss executives appreciate Edward Tufte more than they appreciate gradient-filled pie charts), drill-down capability (summary metrics with the ability to drill into detail — the CFO seeing total revenue, then drilling to revenue by product line, then to revenue by customer within a product line), comparative context (numbers alone are insufficient — numbers compared to budget, prior year, and forecast. Swiss business planning culture is rigorous, and analytics must support comparison against plan), and multilingual labels (dashboard labels and KPI names in the user's preferred language — not a translated afterthought but a designed multilingual experience). Advanced analytics: beyond dashboards, implementing predictive and prescriptive analytics where they add value. Forecasting (time series forecasting for financial, demand, and operational planning — using statistical methods like ARIMA/Prophet for established patterns, ML models for complex multi-factor prediction), segmentation (customer segmentation, product clustering — using unsupervised learning to discover natural groupings in data), and anomaly detection (identifying unusual patterns in financial transactions, operational metrics, or quality data — flagging for investigation rather than acting automatically). (4) Governance and quality (integrated throughout): ensuring analytics are trusted. Data governance: defining data ownership (who is responsible for each dataset), data quality rules (automated checks for accuracy, completeness, and timeliness), and access controls (who can see what data — particularly important in Swiss financial services where information barriers may exist between departments). Data lineage: documenting the path from source data to analytics output — every transformation, calculation, and aggregation traceable. For regulated industries: this lineage documentation is a regulatory requirement, not a nice-to-have. Metric definitions: a central metric catalogue defining how each KPI is calculated — agreed across the organisation, version-controlled, and consistently applied across all dashboards and reports. Swiss businesses: taking metric consistency seriously. If the CFO's dashboard shows revenue of CHF 45.2M and the sales director's shows CHF 46.1M, trust in the analytics platform collapses immediately. (5) Training and adoption (weeks 6-8): ensuring the analytics are used. Executive training: focused sessions for C-level — how to use dashboards for decision-making, not how to build dashboards. In Zurich: executives expect to receive clear, action-oriented analytics, not to become data analysts themselves. Analyst training: deeper training for business analysts and data team — how to create new analyses, how to maintain data quality, and how to extend the platform as needs evolve. Self-service: enabling business users to answer their own questions — within governed guardrails. Self-service analytics: pre-defined data models and metrics that users can explore without breaking governance rules.