Khảo sát nhu cầu hệ thống

Vận hành doanh nghiệp
đang tắc ở đâu ?

18 câu, khoảng 12 phút. Mỗi câu quyết định một phần của đề xuất: phạm vi, kiến trúc, mốc triển khai, chi phí.

18câu hỏi
~12phút
6phần

Điền xong phần B và C, chúng tôi báo được khoảng chi phí. Điền thêm D và E, chúng tôi báo được con số chốt và mốc thời gian — vì lúc đó đã biết hệ thống nào phải tích hợp và ai bên bạn cùng làm.

Chỉ mô tả loại việc và con số tổng. Không cần dán dữ liệu khách hàng, hợp đồng hay báo cáo tài chính. Nếu có phần cần bảo mật, ghi ở câu D3, chúng tôi ký NDA trước khi trao đổi chi tiết.

0/18 câu
A

Bối cảnh doanh nghiệp

Để hiểu bạn đang ở đâu, ai quyết, và điều gì đang thúc bạn hành động

A1

Thông tin doanh nghiệp

Số điểm hoạt động và số người dùng ảnh hưởng trực tiếp tới kiến trúc: một chi nhánh khác hoàn toàn mười chi nhánh cần đồng bộ. Thông tin liên hệ chỉ dùng để gửi lại đề xuất.

A2

Vai trò của bạn, và quyết định đi qua những bước nào

Không phải để phân loại ai quan trọng hơn — mà để chúng tôi chuẩn bị đúng tài liệu, đúng người, đúng thời điểm. Người quyết cần một trang tóm tắt chi phí và rủi ro; người đề xuất nội bộ cần tài liệu đủ chi tiết để bảo vệ phương án trước ban lãnh đạo. Nếu phải qua đấu thầu hoặc so sánh nhiều nhà cung cấp, cứ nói thẳng — chúng tôi cần biết để làm hồ sơ theo đúng mẫu bạn cần.

A3

Vì sao lại là lúc này?

Câu này quyết định thứ tự ưu tiên của cả đề xuất. Có một mốc cứng đang ép thì phương án phải thiết kế ngược từ mốc đó về, và những gì làm sau go-live sẽ được tách ra thành giai đoạn hai. Không có mốc nào ép thì làm chắc chắn còn hơn làm nhanh.

B

Vấn đề cần giải

Phần này quyết định đề xuất giải cái gì — và giá trị của nó đo bằng gì

B1

Nếu chỉ được nói một câu, vấn đề lớn nhất là gì?

Viết bằng ngôn ngữ của bạn, không cần thuật ngữ kỹ thuật. Câu này là thước đo cuối cùng: khi đề xuất xong, chúng tôi đối chiếu lại xem nó có thật sự giải được câu bạn viết ở đây hay đã trôi sang việc khác.

B2

Những quy trình đang tắc

Đây là câu quan trọng nhất của khảo sát. Mỗi dòng được chấm điểm tác động nhân khả thi để quyết định làm gì ở giai đoạn một. Số giờ, số người, tần suất là cơ sở để tính ra chi phí bạn đang trả cho cách làm hiện tại — không có con số này thì phần hiệu quả trong đề xuất chỉ là ước lượng.

B3

Hậu quả đang chịu — và nếu 12 tháng nữa không làm gì

Chọn tất cả đang xảy ra. Câu này quyết định thứ tự ưu tiên khi phải cắt phạm vi: mất tiền trực tiếp và rủi ro pháp lý luôn được xử lý trước sự bất tiện. Ô cuối cùng để trả lời trung thực, kể cả khi câu trả lời là "vẫn sống được" — nếu vấn đề không tự xấu đi theo thời gian, chúng tôi sẽ khuyên làm gọn một phần trước thay vì đề xuất một dự án lớn không cần thiết.

B4

Đã thử cách nào, và học được gì?

Nói thẳng cả lần không thành công cũng được — chúng tôi cần biết để tránh lặp lại. Cái đã thất bại khoanh vùng chính xác chỗ khó thật, và giúp chúng tôi không đề xuất lại đúng thứ bạn đã bỏ. Phần lớn dự án phần mềm đổ vỡ không vì kỹ thuật mà vì cách phối hợp: phạm vi trôi, không ai chốt yêu cầu, bàn giao xong không ai vận hành được.

Từng làm dự án phần mềm với đối tác bên ngoài chưa?

C

Phạm vi giải pháp

Xây mới, thay thế, hay ghép những gì đang có lại với nhau

C1

Bạn hình dung cần làm gì, và ai sẽ dùng?

Chọn tất cả phù hợp, chưa cần chắc. Nếu bạn chưa rõ thì chọn ô cuối cùng — nhiều trường hợp việc đúng nhất không phải xây mới mà là ghép các hệ thống đang có lại, chi phí thấp hơn nhiều. Số người dùng quyết định hạ tầng và chi phí vận hành; người dùng bên ngoài — khách hàng, đại lý, nhà cung cấp — làm thay đổi hẳn yêu cầu bảo mật nên tách riêng.

Ai sẽ dùng hệ thống này?

C2

Luồng nghiệp vụ chính đi qua những bước nào?

Mô tả thô cũng được, dạng bước một rồi bước hai. Mức ngoại lệ ở dưới là yếu tố làm khối lượng công việc phình to nhất — một luồng thẳng khác một luồng mà mỗi khách một kiểu tính giá tới vài lần khối lượng.

C3

Quy trình hiện tại đã được viết ra chưa?

Đây là câu quyết định thời gian và chi phí nhiều hơn bất kỳ câu kỹ thuật nào. Quy trình nằm trong đầu người làm thì phần lớn công sức giai đoạn đầu là đi phỏng vấn và viết lại nó — việc này phải tính vào phạm vi, không thể bỏ qua rồi tính sau. Trả lời thật giúp con số báo giá không bị vỡ giữa dự án.

C4

Dữ liệu hiện tại đang ở đâu và có cần chuyển sang không?

Chuyển dữ liệu cũ thường bị bỏ quên khi báo giá rồi trở thành phần mệt nhất của dự án. Dữ liệu trùng lặp hoặc không có mã chuẩn làm việc này nặng hơn nhiều lần, nên cần biết trước.

D

Hệ thống và ràng buộc kỹ thuật

Phần này quyết định việc gì làm được, làm bằng cách nào, và mất bao lâu

D1

Những hệ thống doanh nghiệp đang dùng

Cột "có cho kết nối dữ liệu không" là thông tin đắt nhất trong cả khảo sát này. Hệ thống có sẵn kết nối chuẩn thì tích hợp mất vài ngày; hệ thống đóng, nhà cung cấp không hợp tác thì phải làm đường vòng, đắt hơn nhiều lần và rủi ro cao hơn. Không biết thì chọn "không rõ", chúng tôi sẽ kiểm tra giúp.

D2

Hạ tầng, vận hành sau bàn giao, và năng lực IT phía bạn

Câu ai vận hành sau bàn giao thường bị bỏ qua và là lý do nhiều hệ thống chết dần sau một năm. Nếu bên bạn không có người, chúng tôi phải đưa gói bảo trì vào đề xuất ngay từ đầu chứ không để phát sinh sau. Năng lực IT nội bộ quyết định cách bàn giao và mức tài liệu cần làm; cam kết hoạt động 24/7 khác giờ hành chính rất nhiều về thiết kế và về giá.

Năng lực IT nội bộ

D3

Ràng buộc bảo mật và tuân thủ

Chọn tất cả áp dụng. Những ràng buộc này phải biết trước khi thiết kế, không phải sau — đưa dữ liệu cá nhân lên dịch vụ nước ngoài rồi mới phát hiện vi phạm thì phải làm lại kiến trúc từ đầu.

E

Điều kiện triển khai và ngân sách

Phần lớn dự án phần mềm trễ hạn vì những câu ở phần này, không phải vì kỹ thuật

E1

Ai là đầu mối nghiệp vụ phía doanh nghiệp?

Người này chốt yêu cầu, trả lời câu hỏi nghiệp vụ và nghiệm thu từng phần. Không có người này, hoặc có nhưng không được dành thời gian, là nguyên nhân trễ hạn số một — và là điều chúng tôi sẽ nói thẳng ngay từ đầu chứ không để phát hiện giữa dự án.

E2

Mô hình hợp tác bạn thấy phù hợp

Không có mô hình nào tốt hơn tuyệt đối, chỉ có mô hình khớp với việc bạn cần. Yêu cầu chưa rõ mà khoán gọn theo phạm vi thì hai bên sẽ tranh nhau định nghĩa phạm vi suốt dự án — trường hợp đó nên chia giai đoạn, làm rõ yêu cầu trước rồi mới khoán phần triển khai.

E3

Khi nào cần chạy được, và ngân sách dự kiến

Nếu mốc quá gấp so với phạm vi, chúng tôi sẽ nói ngay và đề xuất cắt phạm vi giai đoạn một để kịp mốc, phần còn lại làm tiếp — thay vì nhận rồi trễ. Về ngân sách, nói khoảng cũng được, và tình trạng quan trọng hơn con số: đã có trong kế hoạch thì chúng tôi làm đề xuất triển khai; chưa có thì việc trước tiên là làm bộ tài liệu để bạn trình xin.

Ngân sách dự kiến

F

Nghiệm thu

Chốt trước điều gì là thành công, để cả hai bên không tranh nhau định nghĩa lúc cuối

F1

Điều gì xảy ra thì bạn coi dự án này là thành công?

Nêu con số nếu có, dạng từ X xuống Y. Nếu kỳ vọng nằm ngoài tầm một hệ thống tác động trực tiếp — ví dụ doanh thu gấp đôi trong một quý — chúng tôi sẽ đặt lại thành chỉ số đo được và nói rõ vì sao, thay vì nhận lời rồi để bạn thất vọng lúc nghiệm thu.

Tự động

Mức sẵn sàng của bạn

Cập nhật trực tiếp khi bạn trả lời. Đây không phải điểm đánh giá — chỉ là bốn thứ chúng tôi cần đủ rõ để đưa ra một đề xuất chắc chắn thay vì một con số phỏng đoán. Ô để trống là chưa đủ dữ liệu.

Độ rõ vấn đề
—
Rõ về phạm vi
—
Rõ về hệ thống, dữ liệu
—
Rõ về nguồn lực, mốc
—

Gửi khảo sát

Bạn đã trả lời 0/18 câu. Không bắt buộc đủ — nhưng những câu bỏ trống sẽ thành câu hỏi trong buổi trao đổi đầu tiên. Sau khi gửi, chúng tôi phản hồi trong 3 đến 5 ngày làm việc kèm nhận định sơ bộ về phương án.