https://www.facebook.com/229341783585544/

Business Intelligence Center - BIC, Duy Tan University, Business Intelligence Center (BIC), Duy Tan University, 254 Nguyen Van Linh, Thac Gian, Thanh Khe, Da Nang (2026)

26/08/2026

🚀 LẦN ĐẦU LÀM DỰ ÁN THẬT, BẠN SẼ NHẬN RA: KIẾN THỨC CHỈ LÀ MỘT NỬA CÂU CHUYỆN
[English below]

Bạn có thể học rất kỹ về BA, BI hay SAP:

📚 Requirement

📝 User Story

✅ Acceptance Criteria

🔄 BPMN

📊 Excel, SQL, Power BI

⚙️ SAP & Business Process

Nhưng rồi bạn bước vào một dự án thật.

Và mọi thứ suddenly khác hẳn. 😵‍💫

📩 User không trả lời email.

🔄 Requirement thay đổi vào phút cuối.

🧹 Data không sạch như trong bài tập.

📊 Hai phòng ban đưa ra hai con số khác nhau.

⏰ Stakeholder nói “cần gấp” nhưng chưa biết chính xác cần gì.

🤝 Một task 1 ngày lại kéo dài cả tuần vì phụ thuộc team khác.

Đây là lúc bạn nhận ra:

🧠 Kiến thức giúp bạn biết phải làm gì.

💼 Kinh nghiệm giúp bạn biết làm điều đó trong một thế giới không hoàn hảo.

Vì vậy, nếu tháng đầu tiên đi làm bạn nghĩ:

“Ủa, sao mình học rồi mà vẫn không biết làm?” 😭

Đừng quá lo.

Bạn không kém đi.
Bạn chỉ vừa bước sang một loại bài toán hoàn toàn khác.

🏫 Ở trường, đề bài thường có đủ dữ kiện.
💼 Trong công việc, đôi khi chính bạn phải tìm ra dữ kiện còn thiếu.

📖 Ở trường, đáp án thường có sẵn.
🏢 Trong dự án, đôi khi cả team phải cùng nhau xác định đâu mới là đáp án đúng.

💡 Vì vậy, cách nhanh nhất để trưởng thành không phải lúc nào cũng là học thêm 10 khóa nữa.

Đôi khi, đó là:

🚀 Bước vào dự án thật.
👀 Quan sát người có kinh nghiệm.
🧩 Học cách họ xử lý những tình huống không có trong giáo trình.

Đó là lúc bạn bắt đầu chuyển từ “biết kiến thức” → “biết làm nghề.”🎯

-----------------------

🚀 YOUR FIRST REAL PROJECT WILL TEACH YOU THIS: KNOWLEDGE IS ONLY HALF THE STORY

You can study BA, BI, or SAP and learn:

📚 Requirements

📝 User Stories

✅ Acceptance Criteria

🔄 BPMN

📊 Excel, SQL, Power BI

⚙️ SAP & business processes

But then you enter a real project.

And suddenly, everything feels different. 😵‍💫

📩 Users don’t reply.

🔄 Requirements change at the last minute.

🧹 Data isn’t clean.

📊 Two departments report different numbers.

⏰ Stakeholders say “urgent” without knowing exactly what they need.

🤝 A one-day task takes a week because you depend on another team.

That’s when you realize:

🧠 Knowledge tells you what to do.

💼 Experience teaches you how to do it in an imperfect world.

So if, during your first month, you think:

“Wait… I learned all this, so why do I still not know how to do it?” 😭

Don’t worry.

You haven’t become less capable.
You’ve simply entered a completely different kind of problem.

🏫 At school, the problem usually gives you the necessary information.
💼 At work, you may have to find the missing information yourself.

📖 At school, the answer often exists.
🏢 In projects, the team may have to figure out what the right answer actually is.

💡 That’s why the fastest way to grow isn’t always taking 10 more courses.

Sometimes, it’s:

🚀 Working on a real project.
👀 Watching experienced people.
🧩 Learning how they handle situations no textbook prepared you for.

That’s how you move from “knowing” → “knowing how to do the job.”🎯

-----------------------
THÔNG TIN LIÊN HỆ
Email: [email protected]
Fanpage: Business Intelligence Center – BIC, Duy Tan University

25/08/2026

✅ UAT: Bài kiểm tra cuối cùng trước khi doanh nghiệp đặt niềm tin vào hệ thống
[English below]

“Hệ thống đã test xong rồi.”

Đây là câu mình nghe rất nhiều trong các dự án triển khai ERP.

Nhưng câu hỏi tiếp theo mới thực sự quan trọng:

“Đã test bởi ai?” 🤔

Developer?
QA?
Hay chính những người sẽ sử dụng hệ thống mỗi ngày?

Đó là sự khác biệt giữa System Testing và User Acceptance Testing (UAT).

🧑‍💼 UAT không chỉ kiểm tra hệ thống có chạy đúng.
Nó kiểm tra xem hệ thống có thực sự hỗ trợ công việc của người dùng hay chưa.

Ví dụ:

📒 Kế toán thử quy trình xuất hóa đơn.
📦 Kho thử nhập – xuất hàng.
🛒 Sales tạo đơn hàng như trong công việc hằng ngày.

Điểm quan trọng là họ kiểm thử bằng quy trình thật + dữ liệu gần với thực tế, chứ không chỉ chạy những test case đẹp trên giấy.

⚠️ Trong nhiều dự án, UAT thường gặp 3 vấn đề:

⏰ Test quá sát Go-live → không còn thời gian sửa lỗi lớn.
🧹 Chỉ dùng dữ liệu “đẹp” → bỏ sót trường hợp ngoại lệ.
👥 Không có đúng người dùng tham gia → bỏ lỡ những khó khăn trong công việc thực tế.

💡 UAT không phải chỉ để ký biên bản nghiệm thu.

Đó là cơ hội cuối cùng để doanh nghiệp hỏi:

“Hệ thống này có thực sự phù hợp với cách chúng ta vận hành không?”

🚀 Một lỗi phát hiện trước Go-live luôn dễ xử lý hơn rất nhiều so với khi hàng nghìn giao dịch đã phát sinh trên hệ thống mới.
-----------------------------
✅ UAT: The Final Test Before a Business Trusts the System

“The system has already been tested.”

This is something you hear often in ERP implementation projects.

But the next question is the one that really matters:

“Tested by whom?” 🤔

The Developer?
QA?
Or the people who will actually use the system every day?

That is the difference between System Testing and User Acceptance Testing (UAT).

🧑‍💼 UAT is not only about whether the system works technically.
It checks whether the system actually supports the way users work.

For example:

📒 Accounting tests the invoicing process.
📦 Warehouse users test goods receiving and issuing.
🛒 Sales creates orders the way they do in real life.

The key is to test with real processes + realistic data, not just perfect test cases.

⚠️ UAT often loses its value because of three common mistakes:

⏰ Testing too close to Go-live → no time left to fix major issues.
🧹 Using only “clean” data → real-world exceptions are missed.
👥 Not involving the right users → practical problems remain invisible.

💡 UAT is not just a formality for signing acceptance documents.

It is the last opportunity to ask:

“Does this system actually fit the way our business operates?”

🚀 A problem discovered before Go-live is always much easier to fix than one discovered after thousands of transactions have already entered the new system.
-----------------------------
THÔNG TIN LIÊN HỆ
Email: [email protected]
Fanpage: Business Intelligence Center – BIC, Duy Tan University

24/08/2026

SAP TRANSACTION CODE LÀ GÌ? TẠI SAO NGƯỜI MỚI HỌC SAP THƯỜNG GẶP CHÚNG RẤT NHIỀU? 🤔
[English below]

Nếu bắt đầu tìm hiểu SAP, bạn có thể nhanh chóng gặp những cái tên như: VA01, ME21N hay FB60.

🔎 Và câu hỏi đầu tiên thường là:

“Đây là code lập trình à?”

😅 Câu trả lời là không hẳn.

Trong SAP, Transaction Code/T-code là mã được sử dụng để truy cập nhanh đến một transaction hoặc chức năng cụ thể trong hệ thống. ⚙️

Ví dụ, người dùng có thể sử dụng một transaction để tạo sales order, tạo purchase order hoặc thực hiện các nghiệp vụ tài chính.

📑 Điều này phản ánh một đặc điểm quan trọng của SAP:

SAP không chỉ là một phần mềm có nhiều màn hình.

Nó là một hệ thống gắn chặt với business process. 🏢

Một transaction thường không tồn tại độc lập mà nó nằm trong một chuỗi nghiệp vụ.

Ta có thể lấy ví dụ đơn giản:

📦 Doanh nghiệp nhận đơn hàng
➡️ Đơn hàng được xử lý
➡️ Hàng được giao
➡️ Khách hàng nhận hóa đơn
➡️ Khoản phải thu được ghi nhận
➡️ Tiền được thanh toán

Mỗi bước có thể liên quan đến các chức năng và module khác nhau trong hệ thống.

Đây là lý do khi học SAP, việc chỉ học thuộc T-code chưa chắc giúp bạn hiểu SAP.

🧠 Bạn có thể nhớ hàng chục transaction nhưng vẫn không hiểu transaction đó nằm ở đâu trong business process.

Với sinh viên và fresher, cách học hiệu quả hơn là:

T-code → nghiệp vụ → quy trình → dữ liệu được tạo/thay đổi → module liên quan. 🔄

💡Khi hiểu được chuỗi này, SAP bắt đầu trở nên dễ hình dung hơn.

Bạn không còn nhìn ME21N hay VA01 như những ký hiệu khó nhớ mà sẽ bắt đầu hiểu:

“À, đây là thao tác đang xảy ra ở một bước cụ thể trong quy trình kinh doanh.” ✅

Đó cũng chính là lý do người học SAP nên kết hợp kiến thức hệ thống với kiến thức business. 🎯

SAP không yêu cầu bạn chỉ nhớ thật nhiều màn hình. Bạn cần hiểu doanh nghiệp đang làm gì và hệ thống đang ghi nhận điều gì. 🏢
-----------------------
WHAT IS AN SAP TRANSACTION CODE? WHY DO SAP BEGINNERS ENCOUNTER THEM SO OFTEN? 🤔

If you are starting to learn SAP, you may quickly come across names such as VA01, ME21N, or FB60.

🔎 And the first question that often comes to mind is: “Is this a programming code?”

😅 The answer is not exactly.

In SAP, a Transaction Code/T-code is a code used to quickly access a specific transaction or function within the system. ⚙️

For example, users can use a transaction to create a sales order, create a purchase order, or perform financial transactions.

📑This reflects an important characteristic of SAP:

SAP is not simply a software system with many screens.

It is a system that is closely connected to business processes. 🔗

A transaction usually does not exist independently. Instead, it is part of a business process.

We can take a simple example:

📦 A company receives an order
➡️ The order is processed
➡️ The goods are delivered
➡️ The customer receives an invoice
➡️ Accounts receivable is recorded
➡️ Payment is made

Each step may involve different functions and modules within the system.

This is why, when learning SAP, simply memorizing T-codes does not necessarily mean you understand SAP.

🧠 You may remember dozens of transactions but still not understand where each transaction fits within the business process.

For students and freshers, a more effective way to learn is:

T-code → business transaction → process → data created/changed → related module. 🔄

Once you understand this chain, SAP starts to become much easier to visualize. 💡

You no longer see ME21N or VA01 as difficult codes to memorize. Instead, you begin to understand:

“Ah, this is the action taking place at a specific step in the business process.” ✅

That is also why SAP learners should combine system knowledge with business knowledge. 🎯

SAP does not require you to simply memorize as many screens as possible. You need to understand what the business is doing and what the system is recording. 🏢
-----------------------
THÔNG TIN LIÊN HỆ
Email: [email protected]
Fanpage: Business Intelligence Center – BIC, Duy Tan University

21/08/2026

“DASHBOARD” TỪNG KHÔNG HỀ LIÊN QUAN ĐẾN DỮ LIỆU 🔍
[English below]

Nếu quay ngược thời gian vài trăm năm, “dashboard” chẳng liên quan gì đến Power BI hay Tableau cả. 😮

Ban đầu, dashboard là một tấm chắn đặt phía trước xe ngựa.

Mục đích rất đơn giản: ngăn bùn đất và sỏi đá bị vó ngựa hất ngược vào người điều khiển. 🐴💨

Từ “dash” trong tiếng Anh vốn mang nghĩa hất tung hoặc bắn văng.

Sau này, khi ô tô xuất hiện, dashboard trở thành nơi đặt đồng hồ tốc độ, báo nhiên liệu và những thông tin giúp tài xế đưa ra quyết định khi đang lái xe. 🚗📊

Rồi từ ô tô đến máy bay, từ các hệ thống quản trị đến những dashboard dữ liệu mà chúng ta mở ra mỗi sáng. ✈️💻

Dù hình thức đã thay đổi rất nhiều, mục đích của dashboard gần như vẫn không đổi:

Giúp người đang điều khiển biết điều gì đang xảy ra để có thể hành động. 🎯

Và đó cũng là lý do một dashboard tốt không phải là dashboard có nhiều biểu đồ nhất.

Nó là dashboard giúp ai đó đưa ra một quyết định tốt hơn. 💡

Nếu một biểu đồ chưa từng khiến người xem thay đổi hành động, đặt ra câu hỏi hoặc đưa ra quyết định khác đi, có lẽ nó chưa thực sự tạo ra giá trị.

Nó chỉ đang chiếm chỗ trên màn hình. 👀

Vì vậy, hãy nhớ:

Dashboard sinh ra để hỗ trợ quyết định, không phải để trang trí. 📈

-----------------------
THE ORIGIN OF “DASHBOARD” 🔍

If you travel back a few centuries, “dashboard” had nothing to do with Power BI or Tableau. 😮

Originally, a dashboard was a barrier placed in front of a horse-drawn carriage.

Its purpose was simple: to block mud and stones kicked up by the horses’ hooves from hitting the driver. 🐴💨

The word “dash” itself refers to something being thrown or sent flying.

Later, with the arrival of automobiles, the dashboard became the place for speedometers, fuel gauges, and other information that helped drivers make decisions while driving. 🚗📊

Then came airplanes, management systems, and the data dashboards we open every morning. ✈️💻

Although the form has changed dramatically, the core purpose of a dashboard has remained almost the same:

Help the operator understand what is happening so they can take action. 🎯

That is why a great dashboard is not the one with the most charts.

It is the one that helps someone make a better decision. 💡

If a chart has never made the viewer change an action, ask a question, or make a different decision, perhaps it is not really creating value.

It may simply be taking up space on the screen. 👀

So remember:

Dashboards are built to support decisions, not decoration. 📈
-----------------------
THÔNG TIN LIÊN HỆ
Email: [email protected]
Fanpage: Business Intelligence Center – BIC, Duy Tan University

20/08/2026

DATA ANALYST VÀ DATA SCIENTIST KHÁC NHAU Ở ĐÂU? 📊
[English below]

Data Analyst và Data Scientist thường xuyên xuất hiện cạnh nhau trong các bài viết về nghề nghiệp dữ liệu.

Điều này khiến nhiều sinh viên mới bắt đầu dễ nghĩ rằng hai vị trí chỉ khác nhau ở mức độ “code nhiều hay ít”. 🤔

Thực tế thì phức tạp hơn rất nhiều.

Một cách đơn giản để hình dung:

Data Analyst thường tập trung nhiều vào việc hiểu dữ liệu hiện tại và quá khứ để hỗ trợ ra quyết định. 📊

Trong khi đó, Data Scientist thường đi sâu hơn vào thống kê, machine learning và các bài toán dự đoán hoặc tối ưu. 🤖

Ví dụ, một nền tảng thương mại điện tử phát hiện doanh thu tháng này giảm.

Data Analyst có thể tìm hiểu:

🔍 Doanh thu giảm ở nhóm sản phẩm nào?

📍 Khu vực nào bị ảnh hưởng?

👥 Khách hàng mới hay khách hàng cũ đang mua ít hơn?

Kết quả có thể là một phân tích giúp management hiểu chuyện gì đang xảy ra.

Data Scientist có thể tiếp cận một bài toán khác:

🎯 “Có thể dự đoán khách hàng nào có khả năng rời bỏ trong tháng tới không?”

Lúc này, bài toán có thể cần xây dựng mô hình dự đoán dựa trên lịch sử giao dịch, hành vi khách hàng và nhiều biến khác.

Tuy nhiên, ranh giới giữa hai vị trí không phải lúc nào cũng tuyệt đối.

Trong doanh nghiệp thực tế, trách nhiệm có thể giao thoa tùy vào quy mô công ty và cách tổ chức team.

Một Data Analyst cũng có thể sử dụng thống kê nâng cao.

Một Data Scientist cũng có thể làm exploratory data analysis.

Vì vậy, thay vì học thuộc:

“DA = Excel + Power BI.”

“DS = Python + Machine Learning.”

Hãy hiểu bản chất của vấn đề. 💡

Hãy nhìn vào loại câu hỏi bạn muốn dùng dữ liệu để giải quyết.

Nếu bạn thích khám phá business, tìm pattern, phân tích nguyên nhân và biến dữ liệu thành insight, Data Analytics có thể là một hướng rất phù hợp. 🔎

Nếu bạn hứng thú sâu hơn với thống kê, mô hình hóa, machine learning và các bài toán dự đoán, Data Science có thể là hướng đáng tìm hiểu. 🧠

Công cụ có thể thay đổi.

Nhưng loại vấn đề bạn thích giải quyết mới là thứ quyết định hướng nghề nghiệp lâu dài. 🚀
-----------------------
WHERE DO DATA ANALYSTS AND DATA SCIENTISTS DIFFER? 📊🧠

Data Analysts and Data Scientists often appear side by side in articles about data careers.

This can make students who are just starting out think that the two roles only differ in how much they code. 🤔

In reality, the distinction is much more complex.

One simple way to think about it is:

Data Analysts tend to focus more on understanding current and historical data to support decision-making. 📊

Meanwhile, Data Scientists tend to go deeper into statistics, machine learning, and prediction or optimization problems. 🤖

For example, an e-commerce platform notices that its revenue has decreased this month.

A Data Analyst might investigate:

🔍 Which product categories experienced a decline?

📍 Which regions were affected?

👥 Are new or existing customers buying less?

The result could be an analysis that helps management understand what is happening.

A Data Scientist might approach a different problem:

🎯 “Can we predict which customers are likely to churn next month?”

This problem may require building a predictive model based on transaction history, customer behavior, and many other variables.

However, the boundary between the two roles is not always absolute.

In real businesses, responsibilities may overlap depending on the company’s size and how the team is structured.

A Data Analyst may also use advanced statistics.

A Data Scientist may also perform exploratory data analysis.

Therefore, instead of memorizing:

“DA = Excel + Power BI.”

“DS = Python + Machine Learning.”

Try to understand the underlying nature of the problem. 💡

Look at the type of questions you want to use data to answer.

If you enjoy exploring business, finding patterns, analyzing causes, and turning data into insights, Data Analytics may be a very suitable career path for you. 🔎

If you are more interested in statistics, modeling, machine learning, and predictive problems, Data Science may be a direction worth exploring. 🧠

Tools can change.

But the type of problems you enjoy solving is what ultimately determines your long-term career direction. 🚀
-----------------------
THÔNG TIN LIÊN HỆ
Email: [email protected]
Fanpage: Business Intelligence Center – BIC, Duy Tan University

19/08/2026

🚀 SAU VÀI NĂM ĐI LÀM, NGƯỜI TA KHÔNG CÒN HỎI BẠN “BIẾT CÔNG CỤ GÌ?” NỮA
[English below]

Khi mới bắt đầu, CV của bạn thường được đánh giá bằng những thứ rất dễ nhìn thấy:

💻 Excel
🗄️ SQL
📊 Power BI
🐍 Python
⚙️ SAP
📋 Jira
🎓 Và một vài certificate.

Không thể phủ nhận những thứ đó rất quan trọng. Chúng giúp bạn chứng minh rằng mình có nền tảng và có thể bắt đầu công việc.

Nhưng càng đi lâu trong nghề, câu hỏi sẽ dần thay đổi.

Không còn chỉ là:

❓ “Bạn biết Power BI không?”

Mà sẽ là:

👉 “Bạn đã giải quyết bài toán gì bằng Power BI?”

Không chỉ:

❓ “Bạn biết SAP không?”

Mà là:

👉 “Bạn đã tham gia quy trình nào và tạo ra giá trị gì cho doanh nghiệp?”

Không chỉ:

❓ “Bạn biết làm BA không?”

Mà là:

👉 “Bạn đã từng xử lý một requirement khó như thế nào?”

💡 Đó là lúc kinh nghiệm bắt đầu trở nên có giá trị.

Một công cụ có thể học.
Một phần mềm có thể thay đổi.
Một phiên bản SAP có thể được nâng cấp.
Một framework có thể trở nên lỗi thời.

Nhưng khả năng:

🧠 Hiểu vấn đề
🔍 Đặt đúng câu hỏi
🤝 Làm việc với stakeholder
🧩 Xử lý ambiguity
🎯 Đưa ra quyết định tốt hơn
..lại được tích lũy qua từng dự án.

Vì vậy, nếu bạn đang là sinh viên hoặc fresher, đừng chỉ xây một CV có thật nhiều tool.

Hãy bắt đầu xây những câu chuyện về vấn đề bạn từng giải quyết:

📌 Một project bạn từng làm
📌 Một data issue bạn từng phát hiện
📌 Một requirement bạn từng phân tích
📌 Một quy trình bạn từng hiểu sâu hơn
📌 Một lần bạn làm sai và biết cách sửa

Đến một lúc nào đó, điều khiến người khác nhớ đến bạn sẽ không phải là:

“Bạn này biết rất nhiều công cụ.”

Mà là:

“Bạn này gặp vấn đề thì biết cách xử lý.” 💡

🚀 Và đó mới là dấu hiệu bạn đang bước từ học nghề sang làm nghề.
-----------------------
🚀 AFTER A FEW YEARS IN THE WORKFORCE, PEOPLE STOP ASKING “WHAT TOOLS DO YOU KNOW?”

When you’re just starting out, your CV is often evaluated based on things that are easy to see:

💻 Excel
🗄️ SQL
📊 Power BI
🐍 Python
⚙️ SAP
📋 Jira
🎓 And a few certificates.

These skills are important. They help prove that you have a solid foundation and are ready to start working.

But the longer you stay in the field, the questions start to change.

Not just:

❓ “Do you know Power BI?”

But:

👉 “What problem have you solved using Power BI?”

Not just:

❓ “Do you know SAP?”

But:

👉 “Which business process have you worked on, and what value did you create?”

And not just:

❓ “Do you know Business Analysis?”

But:

👉 “How have you handled a challenging requirement?”

💡 That’s when experience starts to matter more.

A tool can be learned.
A software platform can change.
An SAP version can be upgraded.
A framework can become outdated.

But the ability to:

🧠 Understand problems
🔍 Ask the right questions
🤝 Work with stakeholders
🧩 Navigate ambiguity
🎯 Make better decisions
..compounds over time.

So, if you're a student or fresher, don't focus only on building a CV packed with tools.

Start building stories about the problems you've solved:

📌 A project you worked on
📌 A data issue you discovered
📌 A requirement you analyzed
📌 A business process you understood deeply
📌 A mistake you made — and how you fixed it

Eventually, what makes people remember you won't be:

“This person knows a lot of tools.”

It will be:

“When this person faces a problem, they know how to handle it.” 💡

🚀 And that’s when you’re no longer just learning a profession.

You’re starting to practice one.
-----------------------
THÔNG TIN LIÊN HỆ
Email: [email protected]
Fanpage: Business Intelligence Center – BIC, Duy Tan University

18/08/2026

💾 Data Migration: Công việc ít được nhắc đến nhưng quyết định thành bại của Go-live
[English below]

Đến ngày Go-live, hệ thống mới đã sẵn sàng nhưng dữ liệu vẫn đang nằm trong hệ thống cũ.

Vậy làm thế nào để chuyển dữ liệu sang hệ thống mới mà không làm gián đoạn hoạt động kinh doanh? 🤔

Đó chính là bài toán của Data Migration.

Nhiều người nghĩ Data Migration chỉ đơn giản là sao chép dữ liệu từ hệ thống cũ sang hệ thống mới.

Nhưng thực tế, phía sau đó là cả một quy trình: 🔄

📥 Extract – Trích xuất dữ liệu từ hệ thống cũ
🧹 Clean – Làm sạch và loại bỏ dữ liệu không phù hợp
🔗 Map – Mapping cấu trúc dữ liệu cũ với hệ thống mới
🔄 Transform – Chuyển đổi mã, đơn vị tính và định dạng
🧪 Test – Nạp thử và đối chiếu kết quả
✅ Validate – Kiểm tra dữ liệu trước khi Go-live

Và quá trình này thường phải lặp lại nhiều lần trước ngày chính thức vận hành.

Một câu hỏi rất quan trọng là:

🤔 Có thực sự cần chuyển toàn bộ dữ liệu lịch sử sang hệ thống mới không?

Chuyển tất cả dữ liệu có thể làm tăng khối lượng xử lý, kéo dài dự án và thậm chí mang theo những dữ liệu không còn giá trị.

Đến ngày Go-live, mọi người thường nhìn thấy giao diện mới. ✨

Nhưng ít ai nhìn thấy những tuần hoặc tháng mà đội dự án đã dành để:

🧹 Làm sạch dữ liệu
🔍 Đối chiếu từng dòng
🔄 Mapping và chuyển đổi
🧪 Kiểm thử nhiều lần

Và chính những công việc thầm lặng phía sau đó giúp hệ thống có thể vận hành ổn định ngay từ ngày đầu tiên. 🚀
-----------------------------
💾 Data Migration: The Often-Overlooked Work That Can Make or Break Go-live

By the time Go-live arrives, the new system may be ready — but the data is still sitting in the legacy system.

So how do you move that data into the new system without disrupting business operations? 🤔

That is the challenge of Data Migration.

Many people think Data Migration simply means copying data from the old system to the new one.

In reality, it involves a much broader process: 🔄

📥 Extract – Extract data from the legacy system
🧹 Clean – Clean and remove unsuitable data
🔗 Map – Map old data structures to the new system
🔄 Transform – Convert codes, units, and formats
🧪 Test – Load and reconcile the data
✅ Validate – Verify the data before Go-live

And this process is often repeated several times before the actual Go-live.

One important question is:

🤔 Do we really need to migrate all historical data into the new system?

Migrating everything can increase processing effort, extend the project timeline, and potentially bring outdated or irrelevant data into the new system.

On Go-live day, people usually see the new interface. ✨

What they rarely see are the weeks or months the project team spent:

🧹 Cleaning data
🔍 Reconciling records
🔄 Mapping and transforming data
🧪 Running migration tests

Yet this behind-the-scenes work is what helps the new system operate reliably from day one. 🚀
-----------------------------
THÔNG TIN LIÊN HỆ
Email: [email protected]
Fanpage: Business Intelligence Center – BIC, Duy Tan University

17/08/2026

BUSINESS PROCESS VÀ BUSINESS RULE KHÁC NHAU NHƯ THẾ NÀO? 🔄📋
[English below]

Đây là một cặp khái niệm rất dễ bị sinh viên mới học BA hoặc ERP nhầm lẫn. 🤔

Khi Business Process mô tả doanh nghiệp thực hiện công việc như thế nào, thì Business Rule mô tả những điều kiện hoặc nguyên tắc mà doanh nghiệp phải tuân theo trong quá trình đó. 🎯

Ví dụ, quy trình mua hàng có thể là:

Nhân viên tạo yêu cầu mua hàng → quản lý phê duyệt → bộ phận mua hàng tạo đơn mua → nhà cung cấp giao hàng → doanh nghiệp nhận hàng → hóa đơn được xử lý.

Đó là Process. 🔄

Nhưng trong quy trình này có thể tồn tại các Business Rule như:

💰 “Nếu giá trị đơn mua vượt quá 100 triệu đồng thì phải có cấp quản lý cao hơn phê duyệt.”

🚫 “Nhân viên không được tự phê duyệt yêu cầu mua hàng của chính mình.”

Đó là Business Rules.

Hai khái niệm này liên quan chặt chẽ nhưng không giống nhau.

Process trả lời:

👉 “Công việc diễn ra như thế nào?”

Trong khi Business Rule trả lời:

👉 “Trong quá trình đó, điều gì được phép hoặc không được phép xảy ra?”

Đây là kiến thức rất quan trọng đối với BA. 📌

Nếu BA chỉ mô tả process mà bỏ qua business rules, hệ thống có thể được xây dựng đúng flow nhưng vẫn sai logic nghiệp vụ.

Ví dụ:

✅ Flow cho phép nhân viên gửi yêu cầu mua hàng.

✅ Flow cho phép quản lý phê duyệt.

Mọi thứ có vẻ đúng.

Nhưng nếu hệ thống không kiểm tra rule “người tạo không được tự phê duyệt”, doanh nghiệp vẫn có một lỗ hổng trong nghiệp vụ. ⚠️

Khi nhìn một quy trình bất kỳ, hãy thử tách nó thành hai lớp:

Process: Ai làm gì? Làm trước hay sau? Chuyển giao cho ai?

Rule: Khi nào được làm? Khi nào không được làm? Điều kiện nào phải được đáp ứng?

🔍 Khi bắt đầu nhìn được hai lớp này, bạn sẽ hiểu business requirement sâu hơn rất nhiều.

Và quan trọng hơn, bạn sẽ nhận ra:

Một hệ thống doanh nghiệp tốt không chỉ mô phỏng cách con người làm việc.

Nó còn phải phản ánh những nguyên tắc mà doanh nghiệp muốn con người tuân theo. 💡
-----------------------
HOW ARE BUSINESS PROCESSES AND BUSINESS RULES DIFFERENT? 🔄📋

This is a pair of concepts that students who are new to BA or ERP can easily confuse. 🤔

While a Business Process describes how a business carries out its work, a Business Rule describes the conditions or principles that the business must follow throughout that process. 🎯

For example, a purchasing process might be:

Employee creates a purchase requisition → manager approves it → purchasing department creates a purchase order → supplier delivers the goods → company receives the goods → invoice is processed.

That is the Process. 🔄

But within this process, there may be Business Rules such as:

💰 “If the purchase order value exceeds VND 100 million, approval from a higher-level manager is required.”

🚫 “An employee cannot approve their own purchase requisition.”

Those are Business Rules.

The two are closely related but not the same.

Process answers:

👉 “How does the work happen?”

While Business Rule answers:

👉 “What is allowed or not allowed to happen during the process?”

This is very important for a BA. 📌

If a BA only describes the process and overlooks the business rules, the system may be built with the correct flow but still have incorrect business logic.

For example:

✅ The flow allows an employee to submit a purchase requisition.

✅ The flow allows a manager to approve it.

Everything seems correct.

But if the system does not enforce the rule that “the requester cannot approve their own request,” the business still has a gap in its logic. ⚠️

When looking at any process, try to break it down into two layers:

Process: Who does what? What happens before or after? Who is it handed over to?

Rule: When is an action allowed? When is it not allowed? What conditions must be met?

🔍 Once you start seeing these two layers, you will understand business requirements much more deeply.

And more importantly, you will realize one thing:

A good enterprise system does not simply model how people work.

It must also reflect the principles that the business expects people to follow. 💡
-----------------------
THÔNG TIN LIÊN HỆ
Email: [email protected]
Fanpage: Business Intelligence Center – BIC, Duy Tan University

16/08/2026

🎮 ERPsim có những cấp độ nào?

Từ Maple Introduction với những quyết định cơ bản về đặt hàng, giá bán, marketing đến Manufacturing với sản xuất, nguyên vật liệu và cuối cùng là Sustainability với bài toán carbon & phát triển bền vững.

📈 Càng lên level, bài toán kinh doanh càng “khó nhằn”!

🎬 EP03 — Cùng khám phá các cấp độ của ERPsim nhé!

14/08/2026

CON "BUG" ĐẦU TIÊN TRONG LỊCH SỬ MÁY TÍNH LÀ MỘT CON BỌ THẬT 🔍🐛
[English below]

Bạn đã từng nghe từ “debug” hàng trăm lần. 💻

Nhưng có thể bạn chưa biết, thuật ngữ này bắt nguồn từ một câu chuyện có thật.

Năm 1947, khi nhóm kỹ sư đang vận hành máy tính Harvard Mark II, hệ thống bất ngờ hoạt động không chính xác.

Sau khi kiểm tra, họ phát hiện “thủ phạm” là một con bướm đêm mắc kẹt trong rơ-le của máy. 🐛

Con bướm được gỡ ra, dán vào sổ nhật ký kỹ thuật cùng dòng ghi chú nổi tiếng:

“First actual case of bug being found.”

Trang nhật ký ấy vẫn còn được lưu giữ đến ngày nay. 📖

Nhưng điều thú vị hơn là trong các dự án ERP hiện đại, “bug” rất hiếm khi bắt đầu từ một dòng code.

Nó có thể xuất hiện sớm hơn nhiều:

❓ Khi yêu cầu chưa được làm rõ.
⚠️ Khi một trường hợp đặc biệt bị bỏ sót.
📊 Khi dữ liệu thực tế khác hoàn toàn dữ liệu dùng để kiểm thử.

Nói cách khác, rất nhiều bug có thể được tạo ra ngay trong phòng họp. 🏢

Chỉ là đến khi hệ thống được triển khai, chúng mới bắt đầu “lộ diện”.

💡 Một bug được phát hiện sớm có thể chỉ mất vài phút để sửa.

Nhưng một bug chỉ được phát hiện sau khi hệ thống đi vào vận hành có thể khiến cả dự án phải trả giá.
-----------------------
THE FIRST “BUG” IN COMPUTER HISTORY WAS A REAL BUG 🔍🐛

You may have heard the word “debug” hundreds of times. 💻

But you may not know that the term is connected to a real story.

In 1947, while engineers were operating the Harvard Mark II computer, the system suddenly began malfunctioning.

After investigating, they found the “culprit”: a moth trapped inside one of the machine’s relays. 🐛

The moth was removed and taped into the engineering logbook with the famous note:

“First actual case of bug being found.”

That logbook page is still preserved today. 📖

But what’s even more interesting is that in modern ERP projects, a “bug” rarely starts with a line of code.

It can appear much earlier:

❓ When requirements are unclear.
⚠️ When edge cases are overlooked.
📊 When real-world data is very different from test data.

In other words, many bugs may be created in the meeting room long before they appear in the system. 🏢

They simply remain hidden until go-live.

💡 A bug found early may take only minutes to fix.

A bug discovered after the system is already in operation, however, can cost the entire project much more.
-----------------------
THÔNG TIN LIÊN HỆ
Email: [email protected]
Fanpage: Business Intelligence Center – BIC, Duy Tan University

Business Intelligence Center - BIC, Duy Tan University

26/08/2026

25/08/2026

24/08/2026

21/08/2026

20/08/2026

19/08/2026

18/08/2026

17/08/2026

16/08/2026

14/08/2026

Address

Website

Alerts

Contact The School

Shortcuts

Share

Category

Listing takedown request