Nhà May Quân — Công ty TNHH Phước Thanh Phúc

Hệ thống Quản lý
Sản xuất theo Tuần

Kế hoạch rõ ràng · Đo lường công bằng · Giao hàng đúng hẹn

"Chúng ta đang ở đâu, sẽ đi đâu, và đi cùng nhau như thế nào"

Đối tượng Giám đốc · Quản đốc · Trưởng ban · Admin · Thợ

Mục đích Cùng hiểu — Cùng đồng thuận — Cùng triển khai

Thời lượng 37 slide · 7 chương · Khoảng 60-90 phút

Chương 1 · Khởi động

Chúng ta đang gặp vấn đề gì?

Trước khi nói về giải pháp, hãy nhìn thẳng vào thực tế. Đây là những vấn đề ảnh hưởng đến uy tín công ty và thu nhập của tất cả mọi người.

⏰

Trễ hẹn giao hàng

Nhiều đơn không giao đúng ngày đã hứa với khách. Khách hàng ngại đặt thêm.

❓

Không ước tính được

Khi khách hỏi "Bao giờ xong?" — câu trả lời thường là phỏng đoán, không có cơ sở.

📋

Không có kế hoạch rõ

Không ai biết chính xác trong tuần này mình cần làm gì, ưu tiên gì.

⚖️

Khó đo công bằng

Người làm nhiều việc khó, người làm ít việc dễ — hiện chưa có cách phân biệt rõ.

🌀

Đơn chìm dưới bùn

Có những đơn tồn lâu, không ai nhớ, không ai theo dõi đến nơi đến chốn.

🔥

Luôn bận, luôn cháy

Cả xưởng luôn căng thẳng, nhưng đơn vẫn trễ. Không phải do thiếu nỗ lực.

Sự thật cần nói thẳng: Đây không phải lỗi của ai cụ thể. Đây là vấn đề của hệ thống. Và hệ thống thì có thể cải thiện được.

Chương 1 · Khởi động

Nếu không thay đổi — chuyện gì sẽ xảy ra?

1

Khách mất niềm tin

Trễ hẹn vài lần — khách lớn (Six Senses, Hyatt, Marriott...) sẽ chuyển sang nhà may khác.

↓

2

Đơn hàng giảm

Mất khách lớn → doanh thu giảm → công ty phải nhận đơn nhỏ, lợi nhuận thấp hơn.

↓

3

Thu nhập của tất cả giảm

Khi công ty kém đi, không ai trong xưởng được hưởng lợi. Thợ giỏi sẽ rời đi tìm chỗ ổn định hơn.

↓

4

Vòng xoáy đi xuống

Ít người hơn → áp lực nhiều hơn cho người ở lại → chất lượng giảm → khách mất thêm.

Ngược lại — nếu chúng ta giao hàng đúng hẹn ổn định: Khách trust → nhận thêm đơn lớn → giá tốt hơn → thu nhập mọi người tăng → giữ được thợ giỏi → chất lượng tốt hơn → khách trust hơn nữa. Đây gọi là vòng xoáy đi lên.

Chương 1 · Khởi động

Chúng ta đang hướng tới điều gì?

Hiện tại

Không biết tuần này mình làm gì cụ thể
Ưu tiên thay đổi liên tục
Việc gấp chen ngang việc đang làm
Người làm nhiều việc khó = người làm ít việc dễ về thu nhập
Trễ hẹn không có hậu quả rõ ràng
Làm tốt không được ghi nhận cụ thể

Hướng tới

Thứ Hai nhận danh sách công việc rõ ràng
Kế hoạch tuần được "khóa" — không đổi tùy tiện
Việc gấp có cơ chế xử lý riêng, không phá kế hoạch
Việc khó được tính điểm cao hơn, thu nhập cao hơn
Đúng hẹn → thưởng. Trễ → giảm điểm rõ ràng
Mỗi tuần đều có đo lường và xếp hạng quý

Mục tiêu cuối cùng: cam kết được mọi đơn hàng giao đúng hẹn — và mọi người được trả công đúng với giá trị thực mình tạo ra.

Chương 2 · Khái niệm cốt lõi

Tại sao cần đơn vị đo chung?

🤔

Vấn đề: Làm sao so sánh công bằng giữa các công việc rất khác nhau?

1 áo sơ mi cơ bản (~2 giờ) vs 1 sửa lai quần (~15 phút) vs 1 vest bespoke (~3 ngày)

Đếm "cái" thì không công bằng. Đếm "giờ" thì không phản ánh độ khó. Đếm "tiền" thì không phản ánh effort.

💡

Giải pháp: Quy đổi tất cả về Token — một đơn vị chung phản ánh:

⚙️ Độ khó kỹ thuật

🔥 Độ gấp deadline

👑 Loại khách hàng

📦 Kết quả giao hàng

Hình dung: Token giống như "tiền tệ nội bộ" của xưởng. Mỗi công việc có giá trị token nhất định. Cuối tuần, tổng token = thưởng tuần. Cuối quý, tổng token quyết định xếp hạng.

Chương 2 · Khái niệm cốt lõi

Bảng Token cơ bản (Base Token)

Mỗi loại sản phẩm có một Token cơ bản — đo lường effort/độ khó trung bình khi điều kiện bình thường.

Loại công việc	Token cơ bản	Thời gian TB	Quy đổi VNĐ tham khảo
Sửa lai quần đơn giản	2	~15 phút	~30.000 đ
Vắt sổ, đính nút sản phẩm	5	~30 phút	~75.000 đ
May sơ mi cơ bản	10	~2 giờ	~150.000 đ
May quần tây hoàn chỉnh	15	~3 giờ	~225.000 đ
May áo dài / đầm uniform	25	~5 giờ	~375.000 đ
May áo vest đồng phục	40	~8 giờ	~600.000 đ
May vest bespoke / fitting cao cấp	80	~16 giờ	~1.200.000 đ
Cắt rập cho đơn mới (per mẫu)	20	~3 giờ	~300.000 đ

Lưu ý quan trọng: Đây là bảng khởi tạo. Trong tháng đầu triển khai, ban quản lý sẽ hiệu chỉnh con số dựa trên thực tế. Mục tiêu: đảm bảo công bằng cho thợ làm thật.

Chương 2 · Khái niệm cốt lõi

4 yếu tố quyết định giá trị thực của công việc

Token cơ bản chỉ là điểm xuất phát. Giá trị thực phụ thuộc vào bối cảnh công việc đó diễn ra.

⚙️

1. Độ khó

Công việc khó kỹ thuật, mẫu mới, vải khó, rủi ro hỏng cao → được tính điểm cao hơn.

Vì sao? Người dám nhận việc khó đáng được trả công xứng đáng. Tránh tâm lý "né khó chọn dễ".

🔥

2. Độ gấp

Đơn cần gấp tạo áp lực lớn hơn — buộc dừng việc khác, làm nhanh nhưng vẫn phải chuẩn.

Vì sao? Chịu áp lực giỏi là một kỹ năng. Xưởng giải được đơn cháy → giữ uy tín → giữ khách.

👑

3. Khách hàng

Khách lớn (Six Senses, Hyatt...) đòi hỏi tiêu chuẩn cao hơn, fitting tỉ mỉ hơn, ít sai sót hơn.

Vì sao? Làm khách lớn là làm danh tiếng công ty. Đơn từ những khách này quyết định tương lai xưởng.

📦

4. Kết quả giao

Đúng hẹn được giữ nguyên điểm. Sớm hẹn được cộng. Trễ hẹn / lỗi → bị giảm.

Vì sao? Khách trả tiền cho kết quả, không phải effort. Hệ thống cần phản ánh điều này.

Chương 2 · Khái niệm cốt lõi

Hệ số nhân (Multiplier) chi tiết

🔥 Độ gấp

Bình thường: ×1.0
Cần trước ngày X: ×1.2
Gấp trong tuần: ×1.5
Cháy — cần ngay: ×2.0

⚙️ Độ khó

Mẫu quen thuộc: ×1.0
Mẫu mới: ×1.2
Vải khó / kỹ thuật lạ: ×1.3
Rủi ro hỏng cao: ×1.5

👑 Khách hàng

Khách lẻ: ×0.9
Hợp đồng thường: ×1.0
Khách lớn (Hyatt, Marriott...): ×1.3
VIP cao cấp (Six Senses): ×1.5

📦 Kết quả giao

Sớm hơn hẹn: ×1.2
Đúng hẹn: ×1.0
Trễ nhẹ (<1 ngày): ×0.8
Trễ nặng / hỏng: ×0.5 hoặc ×0

Quan trọng: Các hệ số trên là khởi tạo. Sau 1-2 tháng vận hành thực tế, ban quản lý sẽ hiệu chỉnh dựa trên data thật và phản hồi của thợ. Mọi điều chỉnh đều công khai.

Chương 3 · Công thức & Ví dụ

Công thức tính Token tổng quát

Công thức 1 — Production Token (PT)

PT = Token
cơ bản × Độ gấp × Độ khó × Khách hàng

PT (Production Token) = giá trị công việc tại thời điểm giao task. Đây là điểm "tiềm năng" mà thợ có thể đạt được nếu hoàn thành đúng và tốt.

↓ Sau khi hoàn thành ↓

Công thức 2 — Reward Token (RT)

RT = PT × Kết quả
giao × Chất lượng

RT (Reward Token) = điểm thực tế được tính vào thưởng. Đúng hẹn + chất lượng tốt → RT = PT. Trễ hoặc lỗi → RT giảm.

Tóm lại: PT là điểm hứa, RT là điểm thực. Chỉ RT mới được tính vào lương thưởng cuối tuần.

Chương 3 · Công thức & Ví dụ

Ví dụ tính Token — Từ dễ đến khó

Cấp 0 — DỄ Sửa lai quần cho khách lẻ

Token cơ bản: 2

× Độ gấp (bình thường): ×1.0

× Độ khó (quen thuộc): ×1.0

× Khách hàng (khách lẻ): ×0.9

PT = 1.8 token

Giao đúng hẹn × Chất lượng tốt: ×1.0 × 1.0

RT (điểm thực) = 1.8 token ≈ 27.000 đ

Cấp 1 — TRUNG BÌNH May sơ mi đồng phục — hợp đồng thường

Token cơ bản: 10

× Độ gấp (cần trước ngày X): ×1.2

× Độ khó (mẫu quen): ×1.0

× Khách hàng (HĐ thường): ×1.0

PT = 12 token

Đúng hẹn × Chất lượng tốt: ×1.0 × 1.0

RT (điểm thực) = 12 token ≈ 180.000 đ

Cấp 2 — KHÓ Vest đồng phục Six Senses — gấp, hoàn thành sớm

Token cơ bản: 40

× Độ gấp (gấp trong tuần): ×1.5

× Độ khó (mẫu quen): ×1.0

× Khách hàng (VIP Six Senses): ×1.5

PT = 90 token

Sớm hơn hẹn × Chất lượng tốt: ×1.2 × 1.0

RT (điểm thực) = 108 token ≈ 1.620.000 đ

Chương 3 · Công thức & Ví dụ

Ví dụ "Hero" — Cứu đơn cháy

🦸 HERO LEVEL

Tình huống thực tế

Khách sạn Hyatt báo: cần 30 áo sơ mi đồng phục cho event khai trương phòng mới. Deadline còn 2 ngày. Không ai trong xưởng dám nhận — vì không kịp.

Anh A (cùng nhóm 2 thợ khác) đứng ra: "Tôi nhận. Sẽ làm xong."
Cả nhóm OT, làm cả đêm, hoàn thành lúc 8h sáng ngày deadline. Khách hài lòng.

Cách tính Token cho Hero

Token cơ bản (30 áo × 10): 300

× Độ gấp (CHÁY — cần ngay): ×2.0

× Khách hàng (Hyatt VIP): ×1.3

PT = 780 token

Đúng hẹn × Chất lượng tốt: ×1.0 × 1.0

+ Hero Bonus (cứu đơn cháy): +200 token

RT (chia 3 người trong nhóm) = 980 token ≈ 14.700.000 đ

Mỗi người trong nhóm: ≈ 4.900.000 đ cho 1 lần cứu đơn

Triết lý Hero: Hệ thống phải đặc biệt khuyến khích người dám chịu áp lực, dám giải bài toán khó. Đây là người giữ uy tín cho cả công ty. Không thưởng xứng đáng → không ai dám nhận đơn cháy → khách mất → tất cả cùng thua.

Chương 3 · Công thức & Ví dụ

Anti-Gaming — Vì sao không thể "lách luật"

Mọi hệ thống tính điểm đều có nguy cơ bị lách. Sau đây là 4 cơ chế ngăn chặn — đảm bảo công bằng cho người làm thật.

🎯

1. Bắt buộc mix công việc

Mỗi thợ phải có tỷ lệ:

40-60% việc trung bình
20-30% việc khó
20-30% việc dễ

Chống cherry-picking (chỉ chọn việc dễ token cao).

⏳

2. Lookback chất lượng 14 ngày

Token chỉ "chốt" sau 14 ngày kể từ ngày giao.

Nếu khách complain, phát hiện lỗi trong 14 ngày → token bị giảm hồi tố.

Chống làm ẩu cho nhanh, kệ hậu quả.

👥

3. Peer review ngẫu nhiên

Mỗi tuần KCS chọn ngẫu nhiên 10-20% sản phẩm để kiểm tra kỹ.

Phát hiện lỗi giấu (hidden rework) → trừ điểm kép.

Chống tự sửa không khai báo.

🤝

4. Hệ số teamwork

Có thêm điểm khi giúp đồng nghiệp giải vướng mắc.

Người cô lập, từ chối hỗ trợ → giảm hệ số (×0.95).

Chống "siêu sao đơn độc", khuyến khích văn hóa hỗ trợ.

Triết lý: Hệ thống tốt không phải là hệ thống "bắt người gian". Hệ thống tốt là hệ thống làm việc làm thật trở thành chiến lược tốt nhất. Khi đó, mọi người tự nhiên đi đúng hướng.

Chương 4 · Kiến trúc hệ thống

Triết lý Master-Slave — Tập trung quyết định

Trong giai đoạn đầu, chúng ta chọn mô hình Master-Slave: quyết định tập trung ở Admin, thợ chỉ tập trung vào việc may.

🧠 MASTER

Admin · Quản đốc · Giám đốc

Listen — nhận đơn từ mọi nguồn

Decide — phân loại, ưu tiên

Distribute — giao task

Lock — khóa kế hoạch tuần

Monitor — theo dõi tiến độ

Score — chấm điểm cuối tuần

↓ Task list (giấy / Zalo)

↑ Kết quả (giấy ký)

🔨 SLAVE (Người thực thi)

Thợ · Nhóm thợ · KCS

Receive — nhận task list

Execute — tập trung làm việc kỹ thuật

Confirm — ký xác nhận hoàn thành

Report — báo cáo nếu vướng mắc

Vì sao chọn Master-Slave trong giai đoạn đầu?

✅ Đơn giản

Thợ không cần học hệ thống phức tạp. Chỉ cần nhận giấy, làm, ký nộp lại.

✅ Kiểm soát

Tránh chaos "ai cũng tự chọn việc dễ". Admin có cái nhìn tổng thể để cân đối.

✅ Đo lường

Có 1 điểm tập trung dữ liệu → dễ phân tích, dễ cải tiến hệ thống.

✅ Mở rộng

Sau khi ổn định, có thể tiến hóa sang model tự chọn task (kanban) cho thợ nghiệm.

Chương 4 · Kiến trúc hệ thống

Kiến trúc kỹ thuật — Đơn giản, tự chủ, hiệu quả

📥 Nguồn đầu vào (Input Sources)

📞
Zalo

📧
Email

☎️
Điện thoại

🚶
Khách trực tiếp

↓

💻 Local Web App (chạy trên PC ở xưởng)

Form nhập đơn

Phân loại Past/Current/Future

Gán task cho thợ

In task list / Xuất Zalo

Nhập kết quả tuần

Tính token tự động

↕

🗄️ PostgreSQL Database (local)

tasks backlog & assignments

workers skill matrix, capacity

weeks lock status, schedule

results token earned, rankings

🔧 DBeaver

Tool quản lý DB miễn phí — khi cần edit/query thô.

↓

📤 Đầu ra (Output)

📄
Giấy in
cho thợ lớn tuổi

💬
Zalo message
cho thợ trẻ

📊
Báo cáo tuần
cho QĐ/GĐ

Vì sao chọn stack này?

Local (không cloud): Không phụ thuộc internet. Nha Trang hay cúp điện/mạng, hệ thống vẫn chạy.

PostgreSQL: Miễn phí, ổn định, đủ mạnh cho 30-40 thợ + hàng nghìn task/tháng.

DBeaver: Khi cần thao tác trực tiếp data (sửa lỗi nhập, query đặc biệt) — admin dùng DBeaver.

Giấy + Zalo: Phù hợp với mọi lứa tuổi thợ. Không bắt thợ phải dùng app phức tạp.

📋 Bảng dữ liệu chính

Bảng	Cột quan trọng	Mô tả
`tasks`	id, product_type, base_token, status, assigned_to, week_id	Mỗi công việc trong backlog
`workers`	id, name, group, skill_level, capacity_per_week	Thợ và năng lực
`weeks`	id, week_number, year, status (draft / locked / closed)	Tuần kế hoạch
`results`	task_id, worker_id, tokens_earned, on_time, quality_score	Kết quả giao hàng theo tuần

Chương 4 · Kiến trúc hệ thống

Quy trình "Listen & Distribute" của Admin

5 bước Admin xử lý backlog mỗi tuần. Đây là "công việc thật" của master trong mô hình Master-Slave.

1

🎧 LISTEN — Thu thập backlog

Sáng mỗi ngày, admin tổng hợp đơn từ mọi nguồn về một chỗ.

Check Zalo các nhóm khách hàng
Check email công ty
Ghi nhận điện thoại từ khách trong sổ
Khách đến trực tiếp → nhập vào hệ thống ngay

Tool: Form nhập đơn trên local web app — mỗi đơn có ID duy nhất.

2

🏷️ CATEGORIZE — Phân loại

Mỗi đơn được gắn 3 nhóm tag.

Thời gian: Past (chìm) / Current (đang) / Future (sắp tới)
Độ gấp: 🔥 Cháy / 📅 Có deadline / 📋 Trong tuần / 💡 Dự phòng
Khách hàng: VIP / HĐ / Lẻ

Tool: Dropdown trên web app, lưu vào bảng tasks trong PostgreSQL.

3

🎯 MATCH — Ghép skill

Hệ thống gợi ý ai nên làm việc này, admin quyết định cuối cùng.

Web app query bảng workers → lọc thợ phù hợp skill
Check capacity còn lại của họ trong tuần
Admin override nếu cần (A bận → chuyển B)
Gán task → tạo record trong bảng weeks

Tool: Trang "Phân công" — bảng kéo-thả task vào người, có warning nếu overload.

4

🔒 LOCK — Khóa kế hoạch

Thứ Hai 8h sáng, kế hoạch tuần được "đóng băng".

Click nút "Khóa tuần" trên web app
Trường week_locked = TRUE
In task list cho từng thợ / xuất Zalo message
Mọi thay đổi sau khi lock đều phải log lại

Tool: Nút "Print" → trang in được CSS sẵn cho A4. Nút "Export Zalo" → copy text format.

5

👁️ MONITOR — Theo dõi giữa tuần

Thứ Tư check giữa tuần. Phát hiện vướng mắc sớm.

Dashboard hiển thị: ai đã xong bao nhiêu, ai đang vướng
Tag BLOCKED nếu thợ báo: chờ vải, chờ duyệt, máy hỏng...
Re-assign nếu cần thiết (escalation từ QĐ)

Tool: Trang Dashboard trên web app + query SQL trực tiếp qua DBeaver khi cần phân tích sâu.

Chương 4 · Kiến trúc hệ thống

Cơ chế "Lock tuần" — Vì sao bắt buộc

❌ Nếu không lock tuần...

Ưu tiên thay đổi liên tục → kế hoạch vô nghĩa
Thợ phải đổi việc giữa chừng → context switching tốn 15-20 phút/lần
Việc đang dở dang chất đống → WIP overload
Không ai dám commit deadline → khách mất tin tưởng
Cuối tuần không thể đo: ai làm thật, ai chạy theo

✅ Khi lock tuần...

Mỗi thợ có danh sách rõ ràng, không bị làm phiền
Tập trung kỹ thuật → chất lượng tăng, tốc độ tăng
WIP giới hạn → flow ổn định
Admin/Sales dám hứa deadline với khách
Đo lường công bằng cuối tuần

Quy tắc Lock

🕗

Thời điểm lock: Thứ Hai 8h sáng. Trước thời điểm này, admin còn thời gian chỉnh sửa. Sau thời điểm này, task list "đóng băng".

📜

3 trường hợp được phép unlock:

Đơn cháy bất ngờ từ khách lớn (cần escalation từ giám đốc)
Khách lớn yêu cầu sửa mẫu / đổi spec
Vấn đề kỹ thuật khẩn cấp: vải hết, máy hỏng, thợ bệnh đột xuất

📝

Mọi thay đổi đều LOG: Mỗi lần unlock được ghi lại — ai unlock, vì sao, ảnh hưởng đến ai. Cuối quý đánh giá: tuần nào ổn định, tuần nào bị phá nhiều.

⚖️

Bù điểm khi bị phá: Nếu thợ bị thay task giữa tuần (do unlock), việc cũ vẫn được tính một phần token theo % đã làm.

Chương 4 · Kiến trúc hệ thống

Vòng đời 1 Task — Từ nhận đến chấm điểm

1

BACKLOG

Đơn vừa được nhận, chưa lên lịch

→

2

SCHEDULED

Đã được xếp vào tuần cụ thể

→

3

ASSIGNED

Đã gán cho thợ/nhóm cụ thể

→

4

IN PROGRESS

Thợ đang thực thi

→

5

SUBMITTED

Thợ báo xong, đưa cho KCS

→

6

CHECKED

KCS đã kiểm, đạt chất lượng

→

7

DONE ✓

Hoàn tất, tính token

🛑 BLOCKED

Có thể xảy ra ở bước 4: chờ vải, chờ duyệt, máy hỏng. Tách riêng để đo thời gian chờ.

🔄 REWORK

Nếu KCS không đạt (bước 6) → quay lại bước 4. Mỗi lần rework: hệ số chất lượng giảm.

Trách nhiệm theo từng trạng thái

Trạng thái	Ai chịu trách nhiệm	Hành động chính
BACKLOG	Admin	Nhập đơn, phân loại
SCHEDULED	Admin + Quản đốc	Xếp vào tuần, ước lượng token
ASSIGNED	Quản đốc	Gán cho thợ/nhóm
IN PROGRESS	Thợ	Thực thi kỹ thuật
SUBMITTED	Thợ	Ký xác nhận, đưa cho KCS
CHECKED	KCS	Kiểm tra chất lượng
DONE	Admin	Tính token vào kết quả tuần
BLOCKED	Quản đốc	Xử lý nguyên nhân chặn

Chương 5 · Vận hành hằng ngày

Vai trò trong hệ thống — Ai làm gì?

👤

Admin

MASTER

Nhập đơn từ mọi nguồn (Zalo, email, điện thoại, khách trực tiếp)
Phân loại Past/Current/Future
Gắn tag urgency, khách hàng
Nhập kết quả cuối tuần
In task list / xuất Zalo

🛠️

Quản đốc

MASTER

Gán task cho thợ/nhóm dựa trên skill
Theo dõi tiến độ giữa tuần
Xử lý vướng mắc, BLOCKED
Quyết định unlock tuần (trong giới hạn)
Báo cáo lên giám đốc

🏢

Giám đốc

MASTER

Phê duyệt unlock tuần cho đơn cháy lớn
Quyết định nhận / từ chối đơn dựa trên capacity
Phê duyệt thưởng Hero, thưởng quý
Đánh giá tổng thể hệ thống theo quý
Quyết định hiệu chỉnh bảng token

🔨

Thợ / Nhóm thợ

SLAVE

Nhận task list Thứ Hai
Tập trung kỹ thuật — không lo scheduling
Báo BLOCKED nếu vướng (vải, máy, mẫu...)
Ký xác nhận hoàn thành, nộp KCS
Tham gia họp Thứ Sáu

🔍

KCS

CHECKPOINT

Kiểm tra chất lượng sản phẩm khi SUBMITTED
Quyết định hệ số Quality (×1.0 / ×0.9 / ×0.7)
Yêu cầu rework nếu không đạt
Peer review ngẫu nhiên 10-20% sản phẩm
Báo cáo xu hướng chất lượng theo tuần

👔

Trưởng ban

MASTER

Quản lý nhóm thợ thuộc ban (sơ mi / vest / quần...)
Đánh giá năng lực cá nhân cho cập nhật skill matrix
Đề xuất xếp hạng quý
Đào tạo, phát triển thợ trong ban
Phối hợp với QĐ về capacity

Chương 5 · Vận hành hằng ngày

Một tuần làm việc sẽ diễn ra thế nào?

Thứ Hai

📋 Nhận danh sách công việc

8h sáng: Lock kế hoạch tuần.
Mỗi cá nhân / nhóm nhận task list in trên giấy hoặc gửi Zalo. Ghi rõ: việc gì, deadline, token dự kiến, độ ưu tiên.

Thứ Ba

🔨 Thực thi theo kế hoạch

Làm theo thứ tự ưu tiên đã thống nhất. Không xáo trộn tùy tiện.

Thứ Tư

🔍 Check giữa tuần

Quản đốc rà soát: ai vướng? Việc gấp phát sinh? Có cần re-assign?

Thứ Năm

🔨 Hoàn thiện việc trong tuần

Tập trung đóng các việc đến deadline trong tuần. Submit cho KCS.

Thứ Sáu

📊 Họp tổng kết — Chấm điểm

15-17h: Họp tuần.
Mỗi người nộp lại giấy đã ký. Admin nhập kết quả vào hệ thống, tính token, công bố kết quả tuần và kế hoạch tuần kế tiếp.

Thứ Bảy

🔄 Đệm — xử lý phát sinh

Ngày dự phòng cho việc cháy hoặc rework. Không nên dùng đến nếu kế hoạch tuần được tôn trọng.

Phân loại tác vụ trong task list

🔥 GẤP Cần hoàn thành ngay — ưu tiên tuyệt đối. Hệ số ×1.5 đến ×2.0.

📅 CÓ DEADLINE Phải xong trước ngày cụ thể trong tuần. Hệ số ×1.2.

📋 TRONG TUẦN Xong bất cứ lúc nào trong tuần. Hệ số ×1.0.

💡 DỰ PHÒNG Việc làm thêm nếu xong sớm. Tính bonus.

Chương 5 · Vận hành hằng ngày

Mẫu Task List — Giấy in & Zalo

Hai định dạng song song để phù hợp mọi đối tượng thợ. Cùng một nội dung, khác cách trình bày.

📄 GIẤY IN (A4)

NHÀ MAY QUÂN — PHƯỚC THANH PHÚC

DANH SÁCH CÔNG VIỆC TUẦN

Tuần: 15/2026 (10-15/04/2026) Thợ: Anh Nguyễn Văn A Nhóm: Sơ mi

#	Công việc	Loại	Deadline	Token	Xác nhận
1	Sơ mi Hyatt — 5 áo (size M, L)	🔥 GẤP	T3 17h	65	☐ ____
2	Sơ mi đồng phục Marriott — 8 áo	📅 T5	T5 12h	96	☐ ____
3	Sơ mi khách lẻ — 3 áo (custom)	📋 Tuần	T6 17h	27	☐ ____
4	Sơ mi Six Senses fitting — 1 áo	📅 T4	T4 17h	18	☐ ____
5	Dự phòng: sửa lai 5 quần	💡 Buffer	—	10	☐ ____
TỔNG TOKEN MỤC TIÊU (chính):				206	—

Quản đốc giao việc:

______________________

Thợ nhận việc (T2):

______________________

Xác nhận hoàn thành (T6):

______________________

Lưu ý: Nộp giấy này lại trong buổi họp Thứ Sáu để được chấm điểm.

💬 ZALO MESSAGE

QĐ

Quản đốc Phương

Thứ Hai, 08:05

📋 TASK LIST TUẦN 15/2026

👤 Anh Nguyễn Văn A — Nhóm Sơ mi

━━━━━━━━━━━━━━

🔥 GẤP — Deadline T3 17h:

1. Sơ mi Hyatt (5 áo size M, L) → 65 token

━━━━━━━━━━━━━━

📅 CÓ DEADLINE:

2. Sơ mi Marriott (8 áo) — T5 12h → 96 token

3. Sơ mi Six Senses fitting (1 áo) — T4 17h → 18 token

━━━━━━━━━━━━━━

📋 TRONG TUẦN:

4. Sơ mi khách lẻ (3 áo custom) — T6 17h → 27 token

━━━━━━━━━━━━━━

💡 DỰ PHÒNG (nếu xong sớm):

5. Sửa lai 5 quần → 10 token

━━━━━━━━━━━━━━

🎯 MỤC TIÊU TUẦN: 206 token

⚠️ Vướng mắc gì báo QĐ ngay. Họp tổng kết T6 lúc 15h.

📄 Giấy task list đã in để trên bàn anh, ký xác nhận giùm em.

Tại sao có cả 2? Thợ lớn tuổi thích giấy (ký xác nhận có giá trị, không phụ thuộc điện thoại). Thợ trẻ thích Zalo (tiện theo dõi, hỏi nhanh). Hệ thống tạo ra cả 2 từ cùng 1 dữ liệu.

Chương 5 · Vận hành hằng ngày

Phân loại tác vụ — Chi tiết 4 cấp độ

Mỗi task trong task list đều có một trong 4 cấp độ. Cấp độ quyết định cách thợ xử lý ưu tiên.

🔥

GẤP

Ưu tiên tuyệt đối

Khi nào dùng? Khách báo cháy, event sắp diễn ra, đơn cần ngay trong 1-2 ngày.

Cách xử lý: Dừng việc khác (nếu thợ đồng ý), tập trung 100%.

Hệ số: ×1.5 (gấp trong tuần) hoặc ×2.0 (cần ngay).

Bonus: Hoàn thành sớm → +Hero bonus (xem slide 11).

📅

CÓ DEADLINE

Trước ngày X

Khi nào dùng? Đa số đơn hợp đồng có lịch giao cụ thể trong tuần.

Cách xử lý: Phân bổ thời gian sao cho xong trước deadline. Có thể làm xen kẽ.

Hệ số: ×1.2.

Lưu ý: Trễ deadline → hệ số Delivery giảm xuống ×0.8 hoặc thấp hơn.

📋

TRONG TUẦN

Xong cuối tuần là được

Khi nào dùng? Đơn không gấp, chỉ cần xong trong tuần đó.

Cách xử lý: Làm khi có thời gian rảnh giữa các task khác. Linh hoạt.

Hệ số: ×1.0 (chuẩn).

Lưu ý: Không xong trong tuần → bị đẩy sang tuần sau, deadline mới cứng.

💡

DỰ PHÒNG

Bonus nếu xong sớm

Khi nào dùng? Việc dự trữ phòng khi thợ xong sớm các task chính.

Cách xử lý: Chỉ làm nếu task chính đã xong. Không bắt buộc.

Hệ số: ×1.0 + bonus tinh thần.

Lợi ích: Tăng tổng token tuần, vào ranking quý cao hơn.

Quy tắc vàng: Luôn ưu tiên theo thứ tự GẤP → CÓ DEADLINE (gần nhất trước) → TRONG TUẦN → DỰ PHÒNG. Không tự ý đảo thứ tự.

Chương 5 · Vận hành hằng ngày

Thứ Sáu — Họp tổng kết & Chấm điểm

Đây là buổi quan trọng nhất trong tuần. Mọi kết quả được đo lường, công bố, ghi nhận.