Top 10 sai lầm khi xây dựng data platform năm 2025 (và cách tránh)

Trong ba năm vừa qua, đội ngũ Carptech đã đồng hành cùng hơn 20 doanh nghiệp Việt Nam trong hành trình xây dựng data platform. Chúng tôi đã chứng kiến những thành công vang dội: doanh nghiệp retail tăng 30% ROI marketing, công ty sản xuất tiết kiệm 2 triệu USD chi phí vận hành, startup fintech ra mắt sản phẩm nhanh hơn 50%.

Nhưng chúng tôi cũng đã thấy không ít dự án gặp khó khăn, thậm chí thất bại. Và điều đáng nói là: đa số các sai lầm đều có thể dự đoán và tránh được.

Trong bài viết này, chúng tôi tổng hợp 10 sai lầm phổ biến nhất khi xây dựng data platform mà các doanh nghiệp Việt Nam thường mắc phải trong năm 2025 - cùng với cách để tránh chúng. Đây không phải là lý thuyết sách vở, mà là những bài học đắt giá từ các dự án thực tế.

Sai lầm #1: Đầu tư vào công nghệ mà không có bài toán kinh doanh rõ ràng

Dấu hiệu nhận biết

"Chúng tôi muốn xây dựng data lake trên AWS S3 với Spark và Kafka real-time streaming."

Câu nói này nghe có vẻ ấn tượng trong buổi họp executive. Nhưng khi bạn hỏi: "Để giải quyết vấn đề kinh doanh gì?", câu trả lời thường là: "Ừm... để có thể phân tích dữ liệu tốt hơn."

Case study thực tế: Một công ty logistics với 500 nhân viên đầu tư 2 tỷ đồng xây dựng data lake với full suite công nghệ hiện đại. Sau 9 tháng triển khai, họ phát hiện ra: 80% nhu cầu báo cáo của họ có thể giải quyết bằng Google Sheets và vài dashboards Power BI đơn giản. Data lake trở thành một "cái hồ" chứa dữ liệu mà không ai sử dụng.

Tại sao lại sai?

Khi bạn bắt đầu bằng công nghệ thay vì bài toán:

1. Overengineering: Bạn xây hệ thống phức tạp hơn nhiều so với nhu cầu thực tế
2. Lãng phí ngân sách: Chi tiền cho infrastructure và license không cần thiết
3. Mất thời gian: Team dành 80% effort vào technical mà chỉ 20% vào business value
4. Khó đo lường thành công: Không có metrics rõ ràng để biết dự án có thành công hay không

Cách tránh

Bắt đầu từ bài toán kinh doanh cụ thể:

1. Xác định 3-5 use cases ưu tiên: "Giảm 20% churn rate khách hàng trong Q1" hoặc "Tối ưu 15% chi phí vận chuyển"
2. Tính toán ROI dự kiến: Nếu giảm được 20% churn, doanh nghiệp tiết kiệm được bao nhiêu?
3. Chọn công nghệ phù hợp với use case: Đừng dùng Kafka nếu bạn chỉ cần batch processing hàng ngày
4. Bắt đầu nhỏ, mở rộng sau: Proof of concept với 1-2 use cases trước, mở rộng khi đã có kết quả

Template câu hỏi để tự kiểm tra:

• "Nếu data platform này thành công, kết quả kinh doanh cụ thể là gì?"
• "Chúng ta đo lường thành công bằng metrics nào?"
• "Nếu không có data platform, chúng ta đang mất bao nhiêu tiền/cơ hội?"

Best practice: Tại Carptech, chúng tôi luôn yêu cầu khách hàng định nghĩa ít nhất 3 use cases cụ thể với ROI dự kiến trước khi bắt đầu thiết kế kiến trúc.

Sai lầm #2: Bỏ qua data governance, dẫn đến dữ liệu hỗn loạn

Dấu hiệu nhận biết

Sau 6 tháng triển khai data warehouse, data analyst của bạn hỏi:

• "Table user_transactions và transaction_users khác nhau thế nào?"
• "Trường revenue trong table A khác với trường revenue trong table B tại sao lại chênh nhau 15%?"
• "Ai là người sở hữu dataset này? Tôi có được phép dùng không?"

Case study thực tế

Một công ty fintech với 200,000 khách hàng không thiết lập data governance ngay từ đầu. Kết quả:

• Có đến 4 định nghĩa khác nhau về "khách hàng hoạt động" trong các hệ thống
• Báo cáo của team Marketing và team Finance về cùng một chỉ số nhưng chênh nhau 20%
• CEO mất niềm tin vào dữ liệu, quay lại ra quyết định bằng "kinh nghiệm"
• Tốn 8 tháng để "dọn dẹp" và standardize lại toàn bộ data

Theo IBM 2025, bad data gây mất trung bình $15 triệu/năm cho các doanh nghiệp. Nghiên cứu 2025 State of Data Quality Survey cho thấy data quality kém tiêu tốn trung bình 31% doanh thu của doanh nghiệp.

Tại sao lại sai?

Data governance không phải là "nice-to-have", mà là nền tảng của mọi data platform. Không có governance:

1. Mất lòng tin vào dữ liệu: Khi số liệu không nhất quán, stakeholders ngừng tin tưởng
2. Duplicate effort: Nhiều người làm cùng một việc vì không biết ai đã làm gì
3. Rủi ro compliance: Vi phạm GDPR, PDPA về bảo mật dữ liệu cá nhân
4. Chi phí bảo trì tăng vọt: Càng về sau càng khó sửa

Cách tránh

Thiết lập data governance ngay từ Sprint 1:

1. Data ownership rõ ràng

• Mỗi dataset phải có một "data owner" chịu trách nhiệm về quality và definition
• Ví dụ: Team Product làm chủ dữ liệu user behavior, team Finance làm chủ dữ liệu revenue

2. Business glossary

• Tạo một "từ điển" chung cho các thuật ngữ kinh doanh
• Ví dụ: "Monthly Active User" = user có ít nhất 1 transaction trong 30 ngày gần nhất

3. Data catalog

• Triển khai công cụ data catalog (ví dụ: DataHub, Amundsen, Atlan)
• Mỗi table/dataset phải có: description, owner, update frequency, sample queries

4. Access control

• Định nghĩa rõ ai được phép truy cập dữ liệu gì (RBAC - Role-Based Access Control)
• Dữ liệu nhạy cảm (PII) phải được mask hoặc encrypt

5. Data quality monitoring

• Thiết lập data quality checks tự động (ví dụ: Great Expectations)
• Alert khi phát hiện anomaly hoặc schema change

Tool recommendations:

• Data catalog: DataHub (open-source), Atlan (commercial)
• Data quality: Great Expectations, dbt tests, Soda
• Lineage tracking: dbt docs, OpenLineage

Bài học: Một doanh nghiệp e-commerce từng nói với chúng tôi: "Chúng tôi đã tiết kiệm 2 tuần ở đầu dự án khi bỏ qua governance. Nhưng đã mất 6 tháng để sửa lại sau này."

Sai lầm #3: Coi nhẹ việc làm sạch và mô hình hóa dữ liệu

Dấu hiệu nhận biết

"Chúng tôi đã ingest được 200 data sources vào data lake rồi. Bây giờ chỉ cần analysts tự kéo dữ liệu ra dùng thôi."

Nghe có vẻ đơn giản, nhưng thực tế:

• Analysts dành 70-80% thời gian để làm sạch và transform dữ liệu
• Mỗi analyst viết một query khác nhau cho cùng một chỉ số
• Báo cáo chạy chậm vì query trực tiếp raw data

Case study thực tế

Một công ty retail có data lake với 50TB dữ liệu raw từ website, mobile app, CRM, ERP. Nhưng:

• Không có data modeling: Analysts phải join 15-20 tables để tạo một báo cáo đơn giản
• Không có cleaning rules: 30% records có missing values hoặc invalid data
• Query performance tệ: Dashboard mất 2-3 phút để load

Sau khi áp dụng data modeling (dimensional modeling với fact và dimension tables):

• Query time giảm từ 2-3 phút xuống còn 3-5 giây
• Analysts tiết kiệm được 60% thời gian làm báo cáo
• Số liệu nhất quán giữa các teams

Tại sao lại sai?

"Raw data" không phải là "analysis-ready data". Nếu bạn dump raw data vào lake và kỳ vọng analysts tự xử lý:

1. Duplicate effort: Mỗi analyst tự viết logic cleaning riêng
2. Inconsistency: Kết quả phân tích không nhất quán giữa các teams
3. Performance issues: Query trực tiếp raw data rất chậm
4. Steep learning curve: Analysts mới mất tuần để hiểu schema phức tạp

Cách tránh

Xây dựng data modeling layer:

1. Áp dụng dimensional modeling

• Fact tables: Chứa metrics và foreign keys (ví dụ: fact_orders, fact_transactions)
• Dimension tables: Chứa descriptive attributes (ví dụ: dim_customers, dim_products)
• Kết quả: Query đơn giản hơn, performance tốt hơn

2. Implement transformation pipeline với dbt

-- models/staging/stg_orders.sql
-- Làm sạch và chuẩn hóa raw data
with source as (
    select * from {{ source('raw', 'orders') }}
),
cleaned as (
    select
        order_id,
        customer_id,
        lower(trim(email)) as email,  -- Chuẩn hóa email
        cast(order_date as date) as order_date,
        case
            when total_amount < 0 then null  -- Remove invalid amounts
            else total_amount
        end as total_amount
    from source
    where order_id is not null  -- Remove invalid records
)
select * from cleaned

3. Layered architecture

• Staging layer: Cleaned raw data, 1:1 mapping với source
• Intermediate layer: Business logic, joins, calculations
• Marts layer: Final tables tối ưu cho use cases cụ thể

4. Data quality tests

# dbt models/schema.yml
models:
  - name: stg_orders
    columns:
      - name: order_id
        tests:
          - unique
          - not_null
      - name: total_amount
        tests:
          - not_null
          - accepted_range:
              min_value: 0
              max_value: 1000000000

Carptech principle: Chúng tôi luôn tuân theo quy tắc "90% chuẩn bị, 10% phân tích". Đầu tư đúng vào data modeling sẽ tiết kiệm gấp 10 lần thời gian về sau.

Để tìm hiểu thêm về data modeling, bạn có thể đọc bài Data modeling: star schema, snowflake schema hay data vault?

Sai lầm #4: Xây dựng một "cái hồ" dữ liệu mà không ai biết cách dùng

Dấu hiệu nhận biết

Data platform của bạn có:

• ✅ Petabytes dữ liệu trong S3
• ✅ Kafka streams processing real-time
• ✅ Spark clusters với auto-scaling
• ❌ Nhưng... chỉ có 3 người trong công ty biết cách query dữ liệu

Case study thực tế

Một công ty logistics đầu tư 5 tỷ đồng xây data lake với đầy đủ công nghệ hiện đại. 12 tháng sau:

• Usage rate: Chỉ có data team (4 người) sử dụng thường xuyên
• Business users: Vẫn gửi email cho data team để xin báo cáo
• ROI: Âm, vì không tạo ra business value

Root cause: Không đầu tư vào data democratization và self-service analytics.

Theo IDC 2025, các hệ thống patchwork integration (không được tích hợp đồng nhất) gây mất 40% năng suất của data teams và business users do phải liên tục chuyển đổi giữa các công cụ và hệ thống khác nhau.

Tại sao lại sai?

Data platform không chỉ là infrastructure và data. Nếu business users không thể tự phục vụ:

1. Data team becomes bottleneck: Mọi yêu cầu báo cáo đều phải qua data team
2. Slow decision-making: Phải đợi 3-5 ngày để có báo cáo
3. Limited innovation: Chỉ có data team nghĩ ra insights, business users không được khám phá
4. Poor adoption: Stakeholders không thấy value của data platform

Cách tránh

Xây dựng self-service analytics capability:

1. Business Intelligence layer

• Triển khai BI tools thân thiện với non-technical users (Tableau, Power BI, Metabase, Looker)
• Tạo semantic layer: Các metrics và dimensions được define sẵn với business terms
• Pre-built dashboards cho common use cases

2. Data catalog cho discovery

• Business users có thể search và khám phá datasets available
• Mỗi dataset có documentation rõ ràng: "Table này chứa gì", "Dùng khi nào", "Sample queries"

3. Training program

• Level 1: Training cơ bản về cách sử dụng BI tools (2-4 giờ workshop)
• Level 2: SQL fundamentals cho những người muốn tự viết queries
• Level 3: Advanced analytics cho power users

4. Enable data culture

• Celebrate data wins: Chia sẻ success stories khi business users tự phát hiện insights
• Office hours: Data team có slot cố định mỗi tuần để answer questions
• Champions network: Identify 1-2 "data champions" trong mỗi department

Ví dụ implementation:

-- Tạo semantic layer với dbt metrics
-- models/metrics.yml
metrics:
  - name: monthly_active_users
    label: Monthly Active Users
    description: >
      Number of unique users who completed at least one transaction
      in the last 30 days
    type: count_distinct
    sql: user_id
    timestamp: transaction_date
    time_grains: [day, week, month]
    filters:
      - field: transaction_date
        operator: '>'
        value: "current_date - interval '30 days'"

Khi business users mở Looker/Tableau, họ sẽ thấy metric "Monthly Active Users" với định nghĩa rõ ràng, không cần biết SQL phức tạp phía sau.

Success metric: Mục tiêu của Carptech là 80% các câu hỏi phân tích thường gặp có thể được business users tự trả lời mà không cần qua data team.

Bạn có thể tìm hiểu thêm về cách xây dựng văn hóa self-service trong bài Self-service analytics: giải phóng data team, trao quyền cho business

Sai lầm #5: Không có người "chủ" (owner) cho dữ liệu

Dấu hiệu nhận biết

Khi phát hiện dữ liệu sai, bạn hỏi: "Ai là người chịu trách nhiệm về dataset này?"

Câu trả lời: "Ừm... không rõ. Có lẽ là team IT? Hay team Analytics?"

Case study thực tế

Một công ty SaaS phát hiện customer churn report sai số sau 3 tháng sử dụng. Khi điều tra:

• Data source do team Engineering maintain
• ETL pipeline do team Data Platform viết
• Business logic do team Analytics define
• Dashboard do team BI tạo

Không ai chịu trách nhiệm end-to-end. Kết quả: Mất 2 tuần để tìm ra root cause và fix.

Tại sao lại sai?

Khi không có owner rõ ràng:

1. Accountability gap: Không ai chịu trách nhiệm về data quality
2. Slow response: Khi có issue, không biết escalate cho ai
3. Knowledge silos: Chỉ người viết code mới hiểu data
4. Poor documentation: Không ai có responsibility để maintain docs

Cách tránh

Implement data ownership model:

1. Assign data owners

• Mỗi business domain có một Data Owner (thường là senior manager)
• Ví dụ:
  • Customer data → Head of Customer Success
  • Product data → Head of Product
  • Financial data → CFO/Finance Manager

2. Data stewards

• Data Owner ủy quyền cho Data Stewards (technical people) để thực thi
• Data Stewards responsible for:
  • Data quality monitoring
  • Documentation maintenance
  • Access control
  • Supporting users

3. RACI matrix Đối với mỗi data asset:

4. Document ownership trong data catalog

# DataHub dataset metadata
dataset:
  name: dim_customers
  domain: Customer
  owner:
    primary: john.doe@company.com
    steward: jane.smith@company.com
  sla:
    freshness: "updated daily by 6am UTC"
    quality: "99.9% completeness on critical fields"
  support:
    slack: "#data-customer-domain"
    documentation: "https://wiki.company.com/data/customers"

5. Service-level agreements (SLAs) Data owners commit to:

• Freshness: Dữ liệu được update thường xuyên thế nào?
• Quality: Standard về completeness, accuracy
• Availability: Uptime expectation
• Support: Response time khi có issues

Carptech recommendation: Trong các dự án của chúng tôi, chúng tôi luôn yêu cầu khách hàng assign data owners trước khi bắt đầu implementation. Đây là prerequisite không thể bỏ qua.

Sai lầm #6: Bỏ qua việc đào tạo cho người dùng cuối

Dấu hiệu nhận biết

Câu chuyện quen thuộc:

• Data platform hoàn thành, go-live thành công
• Training session: 2 giờ workshop với 50 người, everyone says "looks great!"
• 2 tuần sau: Inbox của data team nhận 50 emails/ngày hỏi "How do I...?"
• 2 tháng sau: Usage metrics cho thấy chỉ 20% users actively sử dụng

Case study thực tế

Một công ty F&B triển khai Looker với 100+ dashboards phục vụ 200 users. Sau 6 tháng:

• Active users: 30 người (15%)
• Common complaint: "Quá phức tạp, tôi không biết bắt đầu từ đâu"
• Fall back: Vẫn dùng Excel và gửi email hỏi data team

Sau khi redesign training program và ongoing support:

• Active users: 140 người (70%)
• Ad-hoc requests giảm 60%
• NPS score tăng từ 20 lên 65

Tại sao lại sai?

Một tool tốt nhưng users không biết dùng = tool vô dụng. Thất bại trong training dẫn đến:

1. Poor adoption: ROI không đạt được vì không có usage
2. Frustration: Users frustrated → negative perception
3. Data team overload: Trở lại mô hình cũ, data team làm tất cả
4. Wasted investment: Công cụ đắt tiền nhưng không được dùng

Cách tránh

Xây dựng comprehensive training & enablement program:

1. Segmented training theo user personas

Đừng training "one size fits all". Segment users:

Persona A: Viewers (40%)

• Chỉ cần xem dashboards sẵn có
• Training needs: 30 phút về cách navigate, filter, export

Persona B: Explorers (40%)

• Cần modify dashboards, tạo ad-hoc charts
• Training needs: 2-4 giờ về tool fundamentals, best practices

Persona C: Builders (20%)

• Tạo dashboards mới, viết SQL
• Training needs: 1-2 ngày intensive workshop + advanced topics

2. Multi-format learning

• Live workshops: Hands-on exercises với real scenarios
• Video tutorials: 5-10 phút per topic, có thể xem lại
• Documentation: Wiki với screenshots, FAQs
• Quick reference cards: 1-page cheat sheets in bên cạnh màn hình

3. Ongoing support structure

Training một lần là không đủ. Cần có:

Office hours

• Data team có slot cố định mỗi tuần (ví dụ: mỗi thứ 3 lúc 2-3pm)
• Users có thể drop in để ask questions

Slack/Teams channel

• #data-help channel để users hỏi questions
• Data team + power users trả lời
• Tạo knowledge base từ repeated questions

Champions program

• Identify 5-10% users có technical skills tốt
• Train kỹ hơn, họ trở thành "first line support" trong team mình
• Champions được recognition (certificate, mention trong company meeting)

4. Progressive rollout

Đừng launch cho 200 users cùng lúc:

Phase 1: Pilot (2-4 tuần)

• 10-20 users, các personas khác nhau
• Intensive support, gather feedback
• Iterate dựa trên feedback

Phase 2: Early adopters (4-6 tuần)

• Mở rộng đến 30-40% users
• Champions từ pilot group giúp support
• Refine training materials

Phase 3: General availability

• Rollout còn lại
• Mature support structure đã sẵn sàng

5. Gamification & incentives

Tạo động lực để users engage:

• Certification program: Hoàn thành training → get certified
• Data insight of the month: Reward users phát hiện insights hay
• Dashboard showcase: Highlight well-designed dashboards

Carptech approach: Trong mỗi dự án, chúng tôi budget 15-20% effort cho training và change management. Nhiều khách hàng ban đầu nghĩ đây là "overhead", nhưng đây chính là yếu tố quyết định adoption.

Sai lầm #7: Để chi phí cloud vượt khỏi tầm kiểm soát

Dấu hiệu nhận biết

Tháng 1: AWS bill = $5,000. "Ổn, đúng dự kiến."

Tháng 3: AWS bill = $12,000. "Ồ, usage tăng nhanh quá. Nhưng OK, chúng ta đang growth."

Tháng 6: AWS bill = $35,000. "WTF?! Tại sao lại tăng gấp 7 lần?"

Bạn login vào AWS Cost Explorer, thấy 50+ services, hàng trăm resources, không biết bắt đầu optimize từ đâu.

Case study thực tế

Một startup e-commerce với $500K funding:

• Month 1: Triển khai data platform on AWS. Bill = $3,000
• Month 4: Bill = $18,000 (60% của revenue)
• Root causes:
  • Snowflake warehouse set to auto-resume, không auto-suspend
  • S3 bucket chứa 15TB dữ liệu, 80% không được dùng
  • Airflow running trên EC2 instances chạy 24/7 dù chỉ cần 8 giờ/ngày
  • Fivetran connectors sync every 5 minutes dù chỉ cần hourly

Sau khi optimize:

• Bill giảm từ $18,000 → $6,000 (giảm 67%)
• Performance không bị ảnh hưởng

Tại sao lại sai?

Cloud computing có nguyên tắc: "You pay for what you use". Nhưng nếu không monitor và optimize:

1. Zombie resources: Services đang chạy mà không ai dùng
2. Overprovisioning: Instances quá lớn so với nhu cầu
3. Inefficient queries: Queries scan toàn bộ table thay vì partition
4. Data hoarding: Giữ dữ liệu cũ không cần thiết

Cách tránh

Implement FinOps practices for data platform:

1. Set up cost monitoring and alerts

# AWS Budget alert config
Budget:
  Name: DataPlatform-Monthly
  Amount: 10000
  Unit: USD
  Alerts:
    - Threshold: 80%  # Alert tại $8,000
      Type: ACTUAL
      Subscribers:
        - cto@company.com
        - data-team@company.com
    - Threshold: 100%  # Alert tại $10,000
      Type: FORECASTED  # Dự đoán sẽ vượt

2. Tagging strategy

Tag mọi resources với:

• Environment: production, staging, dev
• Team: data-platform, analytics, ml
• Project: customer-churn, inventory-optimization
• Owner: john.doe@company.com

→ Dễ dàng track chi phí theo team, project, environment

3. Right-sizing và auto-scaling

Snowflake optimization:

-- Set warehouse auto-suspend after 1 minute of inactivity
ALTER WAREHOUSE analytics_wh SET AUTO_SUSPEND = 60;

-- Scale down size if usage low
ALTER WAREHOUSE analytics_wh SET WAREHOUSE_SIZE = 'SMALL';

-- Query optimization: sử dụng clustering keys
ALTER TABLE fact_orders CLUSTER BY (order_date);

4. Data lifecycle policies

# S3 lifecycle policy
{
    "Rules": [
        {
            "Id": "ArchiveOldData",
            "Status": "Enabled",
            "Filter": {"Prefix": "raw-data/"},
            "Transitions": [
                {
                    "Days": 90,
                    "StorageClass": "STANDARD_IA"  # Infrequent Access
                },
                {
                    "Days": 365,
                    "StorageClass": "GLACIER"  # Archive
                }
            ],
            "Expiration": {"Days": 2555}  # Delete after 7 years
        }
    ]
}

5. Query và pipeline optimization

Bad query (scan toàn bộ table):

SELECT * FROM orders WHERE order_date > '2025-01-01';

Cost: $50 per run, scanning 500GB

Good query (partition pruning):

SELECT * FROM orders
WHERE year = 2025 AND month = 1;  -- Partition keys

Cost: $2 per run, scanning 20GB

6. Reserved instances & savings plans

Đối với stable workloads:

• AWS Reserved Instances: Giảm 30-50% chi phí EC2, RDS
• Snowflake upfront capacity: Giảm 15-30% chi phí compute
• GCP Committed use contracts: Giảm 25-50%

7. Monthly cost review

Schedule monthly meeting để:

• Review top 10 most expensive resources
• Identify optimization opportunities
• Compare với previous month
• Forecast next month

Carptech FinOps checklist: Chúng tôi có một checklist 25 điểm để optimize data platform costs. Khách hàng trung bình giảm được 40-60% chi phí sau khi apply.

Tìm hiểu thêm về cách tính toán chi phí data platform trong bài So sánh chi phí data warehouse: Snowflake vs BigQuery vs Redshift

Sai lầm #8: Tuyển dụng sai người, sai vai trò

Dấu hiệu nhận biết

Bạn post job description: "Cần tuyển Data Engineer, phải biết Python, SQL, Spark, Kafka, Airflow, Kubernetes, AWS, Terraform... Kinh nghiệm 2-3 năm."

Hoặc: "Data Analyst phải biết làm tất cả: SQL, Python, Tableau, Excel, PowerPoint, product management..."

Red flag: Bạn đang tìm unicorn, không phải human.

Case study thực tế

Một công ty logistics tuyển "Data Engineer" với JD rất rộng. Người được tuyển:

• Background: 3 năm làm backend engineer, biết Python và SQL
• Không có kinh nghiệm về data modeling, ETL orchestration, hoặc data warehouse
• Công ty kỳ vọng người này xây dựng entire data platform trong 6 tháng

Kết quả:

• 6 tháng sau: Platform built, nhưng full of technical debt
• Data quality issues liên tục
• Performance terrible
• Phải hire consultant external để "fix"

Root cause: Hire sai profile, expectations mismatch.

Tại sao lại sai?

Data roles rất specialized. Khi tuyển sai:

1. Underperformance: Người không có skills phù hợp → output kém
2. Technical debt: Quick hacks thay vì proper solutions
3. Burnout: Kỳ vọng quá cao → stress → người đó nghỉ việc
4. Wasted time & money: Phải hire lại, training lại

Cách tránh

1. Hiểu rõ các vai trò trong data team

Đừng nhầm lẫn các roles sau:

2. Hire for team maturity stage

Stage 1: 0→1 (startup, no data team yet)

• Hire: Analytics Engineer hoặc Senior Data Analyst with some engineering skills
• Why: Cần người hiểu business + có thể tự build simple pipelines
• Don't hire: Junior Data Scientist (chưa có data sạch để làm ML)

Stage 2: Scaling (đã có basic platform)

• Hire: Data Engineer to professionalize pipelines
• Then: More specialized analysts cho từng business domain

Stage 3: Advanced (mature platform)

• Hire: Data Scientists, ML Engineers cho advanced use cases
• Hire: Data Platform Engineer cho infrastructure optimization

3. Write clear, realistic JDs

Bad JD example:

Data Engineer (2 years exp)
Must know: Python, Java, Scala, SQL, Spark, Kafka,
Airflow, Kubernetes, Docker, AWS (S3, EC2, EMR, Glue, Lambda),
Snowflake, dbt, Tableau, machine learning...

→ Đây là 3 roles khác nhau!

Good JD example:

Analytics Engineer (2-4 years exp)
Core requirements:
- SQL expert (window functions, CTEs, optimization)
- Experience with dbt or similar transformation tools
- Understanding of dimensional modeling
- Familiar with BI tools (Tableau/Looker/Power BI)

Nice to have:
- Python for scripting
- Experience with Snowflake or BigQuery
- Data quality testing frameworks

4. Assess for right skills

For Data Engineer:

• Technical test: "Design ETL pipeline to process 1M records/hour"
• System design: "How would you build a real-time streaming pipeline?"

For Analyst:

• SQL test với real business scenarios
• Case study: "Given this data, what recommendations would you make?"

For Analytics Engineer:

• dbt modeling test
• Data modeling exercise: "Design star schema for e-commerce"

Carptech insight: Chúng tôi thấy nhiều doanh nghiệp Việt Nam hire Data Scientist trước khi có Data Engineer. Đây là sai lầm lớn. Data Scientist cần "clean, modeled data" để làm việc. Không có foundation → Data Scientist sẽ dành 80% time làm data engineering, không phải ML.

Sai lầm #9: Kỳ vọng có kết quả trong vài tuần

Dấu hiệu nhận biết

Tuần 1: Kickoff meeting. "Chúng ta sẽ có dashboard đầu tiên khi nào?" - "Có lẽ 2-3 tuần nữa ạ."

Tuần 4: "Dashboard đã xong chưa?" - "Dạ chúng em đang integrate data từ 5 systems, schema rất messy, cần thêm thời gian..."

Tuần 8: "Sao lâu vậy? Competitor họ làm trong 1 tháng mà!" - CFO không hài lòng.

Case study thực tế

Một công ty retail kỳ vọng "data-driven culture" sau 2 tháng triển khai data platform. Timeline họ tưởng tượng:

• Month 1: Setup infrastructure, ingest data
• Month 2: Có dashboards, bắt đầu data-driven decisions
• Month 3: ROI rõ ràng

Reality:

• Month 1-2: Setup infrastructure, nhưng phát hiện data quality issues nghiêm trọng
• Month 3-4: Fix data quality, standardize schemas
• Month 5: First reliable dashboards ready
• Month 6-8: Training users, adoption gradual
• Month 9-12: Bắt đầu thấy business impact rõ ràng

Actual timeline: Gấp 4-5 lần kỳ vọng ban đầu.

Tại sao lại sai?

Data platform không phải là "install software và xong". Các yếu tố làm chậm:

1. Data quality issues: Data source messy hơn expected (luôn luôn!)
2. Technical complexity: Integration giữa nhiều systems phức tạp
3. Organizational change: Người dùng cần time để adopt new tools
4. Iterative process: Cần nhiều vòng feedback để refine dashboards

Cách tránh

Set realistic expectations từ đầu:

1. Phân chia thành phases với milestones rõ ràng

Phase 1: Foundation (Month 1-3)

• ✅ Infrastructure setup
• ✅ Connect 2-3 critical data sources
• ✅ Basic data quality checks
• 🎯 Deliverable: First prototype dashboard

Phase 2: Expansion (Month 4-6)

• ✅ Connect remaining data sources
• ✅ Data modeling & transformation
• ✅ User training & onboarding
• 🎯 Deliverable: 5-10 production dashboards

Phase 3: Optimization (Month 7-9)

• ✅ Performance tuning
• ✅ Self-service enablement
• ✅ Advanced use cases
• 🎯 Deliverable: Measurable business impact

Phase 4: Scale (Month 10-12)

• ✅ Expand to more teams
• ✅ Advanced analytics & ML
• 🎯 Deliverable: ROI positive

2. Quick wins strategy

Đừng chờ "perfect solution". Tìm quick wins để build momentum:

Week 2-3: Simple dashboard từ 1-2 data sources sạch nhất → Show early progress, build confidence

Month 2: Solve 1 painful manual process → Tangible value, users bắt đầu tin

Month 3: Enable self-service cho 1 team pilot → Prove concept works

3. Communicate progress regularly

Weekly updates to stakeholders:

• What we completed this week
• What we learned (especially challenges)
• What's next
• Any blockers

→ Transparency giúp manage expectations

4. Use phased rollout

Đừng launch "big bang" cho toàn công ty. Rollout theo phases:

• Pilot team (1-2 teams) → learn & iterate
• Early adopters (20-30% users) → build momentum
• General availability (everyone) → proven and stable

Carptech rule of thumb:

• Prototype: 4-6 tuần
• Production-ready: 3-4 tháng
• Business impact visible: 6-9 tháng
• ROI positive: 12-18 tháng

Nếu ai hứa nhanh hơn, hãy skeptical.

Sai lầm #10: Không có sự bảo trợ từ cấp lãnh đạo

Dấu hiệu nhận biết

"Sếp tôi nói 'cứ làm data platform đi', nhưng khi tôi xin budget hoặc cần decisions, họ không available."

Hoặc: "CEO không bao giờ tham gia meetings về data. Họ nghĩ đây là 'IT project'."

Case study thực tế

Một công ty sản xuất triển khai data platform với budget 3 tỷ đồng. CTO sponsor, nhưng CEO và CFO "không quan tâm lắm".

Challenges encountered:

• Month 3: Cần access vào SAP ERP data, nhưng Finance team từ chối (security concerns). CTO không đủ authority để override.
• Month 5: Cần thêm budget 500 triệu cho unexpected costs. CFO decline vì "không thấy value".
• Month 7: Cần Marketing team allocate 2 người for training. CMO nói team quá bận, không thể spare.

Result: Dự án kéo dài 18 tháng thay vì 12 tháng, cost overrun 40%, adoption rate thấp.

Root cause: Không có executive sponsor với real authority và commitment.

Tại sao lại sai?

Data platform là enterprise initiative, không phải "IT project". Cần executive sponsorship vì:

1. Cross-functional collaboration: Cần cooperation từ nhiều departments (IT, Finance, Marketing, Ops...)
2. Budget decisions: Thường cần budget adjustments
3. Priority conflicts: Khi có conflict, cần executive để arbitrate
4. Change management: Cultural change cần push từ top-down

Cách tránh

1. Identify the right executive sponsor

Good sponsors:

• CEO hoặc COO (best)
• CFO (nếu data platform focus vào financial/operational insights)
• CDO (Chief Data Officer) nếu company có

Not ideal:

• CTO alone (often seen as "just IT", không đủ business context)
• VP level (không đủ authority)

2. Executive sponsor responsibilities

Clarify expectations:

Commitment:

• Attend monthly steering committee meetings
• Make decisions khi có blockers
• Communicate importance của initiative to the org

Advocacy:

• Present data platform vision trong all-hands meetings
• Lead by example: Use dashboards, ask data-driven questions
• Celebrate wins publicly

Resource allocation:

• Approve budget when needed
• Help resolve cross-functional conflicts
• Ensure teams allocate time for collaboration

3. Create steering committee

Members:

• Executive sponsor (chair)
• Representatives từ key departments (Finance, Marketing, Ops, Product)
• Data team lead
• IT/Infrastructure lead

Cadence: Monthly 1-hour meeting

Agenda:

• Progress update
• Key decisions needed
• Budget status
• Risks & blockers

4. Regular executive updates

Format: Executive dashboard (not slide deck)

Key metrics:

• Progress: % milestones completed
• Adoption: # active users, # dashboards created
• Business impact: Use cases delivered, ROI delivered
• Health: Budget status, timeline status, team sentiment

Frequency: Monthly to sponsor, Quarterly to broader exec team

5. Tie to business OKRs

Connect data platform to company OKRs:

Company OKR: "Increase revenue by 25% in 2026"

Data platform contribution:

• KR1: Enable sales team với customer insights → improve conversion by 15%
• KR2: Marketing campaign optimization dashboards → improve ROI by 20%

→ Executives see direct link to their goals

Carptech observation: Trong các dự án thành công, executive sponsor dành trung bình 2-3 giờ mỗi tháng cho data initiative. Trong các dự án thất bại, sponsor "too busy", chỉ xuất hiện trong kickoff meeting.

Tổng kết: Checklist để tránh các sai lầm

Trước khi bắt đầu data platform project, hãy đảm bảo bạn có:

Strategy & planning

• 3-5 use cases ưu tiên với ROI dự kiến
• Executive sponsor committed
• Realistic timeline (9-12 tháng minimum)
• Budget cho cả technology và training

Foundation

• Data governance framework defined
• Data owners assigned
• Business glossary started
• Data quality monitoring plan

Technical

• Architecture phù hợp với use cases (không overengineer)
• Data modeling strategy (không dump raw data)
• Cost monitoring setup
• Right team with right skills hired

Adoption & people

• Training program planned cho các user personas
• Change management strategy
• Champions identified
• Self-service capability roadmap

Governance

• Steering committee established
• Monthly review cadence
• Metrics to measure success defined
• Communication plan to broader org

Kết luận

Xây dựng data platform là một hành trình dài, phức tạp, và đầy thách thức. Những sai lầm chúng tôi chia sẻ trong bài viết này không phải là lý thuyết - chúng là những bài học đắt giá từ kinh nghiệm thực tế của hàng chục dự án.

Good news: Tất cả các sai lầm này đều có thể tránh được nếu bạn:

1. Học từ người đi trước: Đừng tự mình học bằng cách mắc sai lầm
2. Bắt đầu từ business problem: Technology là phương tiện, không phải mục đích
3. Đầu tư vào people và process: Không chỉ infrastructure
4. Có patience: Kết quả sẽ đến, nhưng cần thời gian

Nếu bạn đang plan xây dựng data platform cho năm 2026, hãy đọc bài Lập kế hoạch data platform 2026: các ưu tiên cho năm tới để có một roadmap cụ thể hơn.

Bạn muốn được tư vấn chi tiết?

• Tính ROI Data Platform miễn phí → — Ước tính chi phí và lợi ích trước khi đầu tư, tránh sai lầm "đầu tư không có business case"
• Làm Data Maturity Assessment → — Biết doanh nghiệp đang ở đâu trên 6 dimensions

Tại Carptech, chúng tôi đã giúp 20+ doanh nghiệp Việt Nam tránh được những sai lầm này và xây dựng data platform thành công. Đặt lịch tư vấn miễn phí 60 phút để chúng tôi giúp bạn đánh giá hiện trạng và lập kế hoạch cho năm 2026.