Hãy hình dung một doanh nghiệp dịch vụ có 20 người. Yêu cầu của khách hàng đến qua email, thông tin liên hệ được chép vào CRM, báo giá được làm trong bảng tính, công việc đã duyệt được đưa lên lịch chung và khi hoàn thành lại được nhập vào phần mềm kế toán. Mọi người đều bận, nhưng không ai thấy được toàn bộ công việc nếu không hỏi nhiều nơi.
Doanh nghiệp đó có thể cần một sản phẩm quản lý dịch vụ. Có thể họ chỉ cần kết nối các công cụ đang dùng. Hoặc các quy tắc về giá, phê duyệt hay xếp lịch đủ đặc thù để cần một hệ thống nội bộ tập trung. Quyết định hữu ích phải bắt đầu từ quy trình đang gặp vấn đề, không phải từ công nghệ yêu thích hay một danh sách tính năng dài.
Mô tả quy trình trước khi so sánh phần mềm
Bản trình diễn sản phẩm có thể khiến hầu hết công cụ trông hoàn chỉnh vì nó đi theo luồng mà nhà cung cấp đã thiết kế. Quyết định của bạn lại phụ thuộc vào cách doanh nghiệp thực sự làm việc, bao gồm nơi thông tin phải chờ, đổi người phụ trách hoặc rời khỏi luồng thông thường.
Hãy chọn một quy trình và lần theo một trường hợp thật từ lúc bắt đầu đến kết quả. Mô tả phải đủ cụ thể để bộ phận vận hành, tài chính và người trực tiếp làm việc nhận ra cùng một quy trình.
- Sự kiện nào bắt đầu công việc?
- Ai phụ trách quyết định tiếp theo ở mỗi giai đoạn?
- Hồ sơ nào phải luôn đáng tin cậy?
- Những người và công cụ nào đang tham gia?
- Điều gì xác nhận công việc đã hoàn thành?
- Ngoại lệ nào ảnh hưởng đến tiền, quyền truy cập, tuân thủ hoặc cam kết với khách hàng?
- Quy trình diễn ra thường xuyên đến mức nào?
- Việc chờ đợi, làm lại hoặc thất bại hiện gây thiệt hại gì?
Có bốn câu trả lời, bao gồm không thêm phần mềm mới
Xây hay mua là một câu hỏi chưa đầy đủ. Doanh nghiệp nhỏ thường có bốn lựa chọn thực tế, và lựa chọn đầu tiên rất dễ bị bỏ qua.
Sửa quy trình trước
Chọn khi người phụ trách, thông tin bắt buộc, cách đổi trạng thái hoặc điều kiện hoàn thành vẫn chưa rõ. Phần mềm chỉ khiến sự mơ hồ được lặp lại nhanh hơn, chứ không loại bỏ nó.
Mua và cấu hình
Dùng sản phẩm có sẵn khi nhu cầu phổ biến và doanh nghiệp có thể điều chỉnh quy trình theo một sản phẩm đã được kiểm chứng mà không tạo ra rủi ro.
Kết nối các công cụ
Tích hợp hoặc tự động hóa khi mỗi công cụ làm tốt nhiệm vụ riêng nhưng công việc bị gián đoạn lúc chuyển giữa chúng.
Xây hệ thống cho quy trình trọng tâm
Xây dựng khi quy tắc, hồ sơ, vai trò hoặc ngoại lệ riêng của doanh nghiệp tạo ra giá trị mà sản phẩm có sẵn không thể hỗ trợ nếu không dựa vào cách xử lý vòng vo tốn kém.
Mua khi nhu cầu đã được giải quyết tốt
Kế toán, tiền lương, email, xếp lịch cơ bản và CRM là những nhu cầu đã có nhiều sản phẩm được kiểm chứng. Mua giúp doanh nghiệp nhỏ bắt đầu nhanh hơn, được nhà cung cấp bảo trì và hưởng kiến thức tích lũy từ nhiều khách hàng.
Đừng chỉ đếm tính năng. Một công cụ có thể đáp ứng phần lớn danh sách nhưng vẫn thiếu đúng ngoại lệ bảo vệ khoản thanh toán, quyền truy cập hoặc cam kết với khách hàng. Hãy thử một trường hợp thông thường và các ngoại lệ quan trọng trước khi kết luận mức độ phù hợp là đủ.
- Chức năng phổ biến và đã có nhiều sản phẩm đáng tin cậy.
- Đội ngũ có thể điều chỉnh quy trình mà không mất lợi thế quan trọng.
- Sản phẩm hỗ trợ hồ sơ, quyền hạn và ngoại lệ mang rủi ro thực tế.
- Triển khai nhanh quan trọng hơn kiểm soát mọi chi tiết.
- Khả năng tuân thủ hoặc kiến thức chuyên môn do nhà cung cấp duy trì có giá trị.
- Chi phí thuê bao, quản trị và chuyển đổi vẫn hợp lý khi doanh nghiệp phát triển.
Kết nối khi từng công cụ hoạt động tốt nhưng việc bàn giao thì không
CRM có thể quản lý thông tin khách hàng tốt trong khi phần mềm kế toán quản lý hóa đơn tốt. Thay cả hai sẽ lãng phí nếu vấn đề thật sự là nhân viên phải chép thông tin khách hàng và công việc đã duyệt từ hệ thống này sang hệ thống kia.
Kết nối có thể là tích hợp có sẵn, một tự động hóa đơn giản, nền tảng tích hợp hoặc dịch vụ riêng nhỏ. Hãy chọn dựa trên tầm quan trọng của dữ liệu, độ phức tạp của quy tắc và cách xử lý khi đồng bộ thất bại, không chỉ dựa trên tốc độ tạo ra bản trình diễn đầu tiên.
- Cùng một thông tin được nhập vào nhiều hệ thống.
- Trạng thái thay đổi trong một công cụ phải kích hoạt hành động dự đoán được ở công cụ khác.
- Các đội ngũ phải đối chiếu báo cáo vì hệ thống không thống nhất về cùng một công việc.
- Mỗi sản phẩm hiện tại vẫn phù hợp với trách nhiệm riêng của nó.
- Doanh nghiệp cần một góc nhìn chung mà không phải thay mọi công cụ hiện tại.
- Có người phụ trách giám sát, bản ghi đồng bộ thất bại, thông tin xác thực và thay đổi API sau khi triển khai.
Xây dựng khi quy trình riêng đáng để doanh nghiệp sở hữu
Việc xây phần mềm riêng phải được chứng minh bằng kết quả vận hành, không phải mong muốn đạt độ phù hợp hoàn hảo. Trường hợp thuyết phục nhất là quy trình diễn ra thường xuyên, có giá trị và có quy tắc, ngoại lệ hoặc trải nghiệm khách hàng khác đáng kể so với giả định của sản phẩm có sẵn.
Quyền sở hữu không chỉ là mã nguồn. Doanh nghiệp còn phải chịu trách nhiệm cho định hướng sản phẩm, bảo mật, lưu trữ, hỗ trợ, tài liệu và việc thay thế sau này. Nếu không ai có thể tiếp tục chịu trách nhiệm cho những phần đó, doanh nghiệp chưa sẵn sàng xây dựng dù ý tưởng hấp dẫn.
- Sản phẩm có sẵn buộc doanh nghiệp lặp lại những thao tác vòng vo trong quy trình quan trọng.
- Quy tắc riêng ảnh hưởng đến biên lợi nhuận, chất lượng dịch vụ, quyền truy cập hoặc tuân thủ.
- Một hồ sơ đáng tin cậy phải điều phối nhiều vai trò và hệ thống.
- Quy trình diễn ra đủ thường xuyên để việc giảm chờ đợi hoặc lỗi có thể hoàn vốn.
- Doanh nghiệp có thể chỉ định người phụ trách và dành ngân sách bảo trì sau bản đầu tiên.
- Phạm vi đầu tiên có thể đi trọn một quy trình thay vì thay thế mọi công cụ.
Dùng chuỗi câu hỏi để quyết định, không dùng điểm số thần kỳ
Bảng điểm có trọng số có thể giúp cuộc thảo luận chặt chẽ hơn, nhưng điểm trung bình có thể che khuất một yếu tố mang tính quyết định. Sản phẩm rẻ không thể chấp nhận nếu không bảo vệ được phê duyệt quan trọng. Xây hệ thống riêng là thiếu trách nhiệm nếu không ai có thể bảo trì. Hãy hỏi theo thứ tự và dừng đánh giá ngay khi một câu trả lời cho thấy rủi ro không thể chấp nhận.
Quy trình đã được hiểu rõ chưa?
Nếu người tham gia không thống nhất về trách nhiệm, thông tin bắt buộc hoặc điều kiện hoàn thành, hãy làm rõ quy trình trước khi chọn phần mềm.
Sản phẩm đã được kiểm chứng có xử lý được trường hợp quan trọng không?
Nếu hỗ trợ cả luồng thông thường và ngoại lệ mang rủi ro thực tế, hãy mua và cấu hình nó.
Vấn đề chủ yếu nằm giữa các công cụ phù hợp?
Nếu các công cụ hoạt động tốt riêng lẻ nhưng dữ liệu hoặc trạng thái bị mất khi bàn giao, hãy kết nối chúng.
Quy tắc riêng có quyết định kết quả không?
Nếu giới hạn của sản phẩm liên tục gây thiệt hại cho quy trình có giá trị, hãy cân nhắc xây một hệ thống tập trung.
Ai sở hữu hệ thống sau khi triển khai?
Không xây dựng hoặc tích hợp nếu chưa có người chịu trách nhiệm cho thay đổi, lỗi, quyền truy cập và chi phí.
Thử nghiệm nhỏ nhất có thể đổi hướng là gì?
Hãy dùng trường hợp thật để thử sản phẩm, một bàn giao tự động hoặc một luồng nhỏ hoàn chỉnh trước khi cam kết lớn hơn.
So sánh chi phí của cùng một kết quả vận hành
Báo giá thuê bao và ước tính phát triển không thể so sánh trực tiếp. Mỗi lựa chọn phải tạo ra cùng kết quả đã thống nhất và phép so sánh phải tính cả phần việc còn lại với doanh nghiệp. Với doanh nghiệp nhỏ, góc nhìn ba năm thường đủ cụ thể để thấy chi phí lặp lại mà không giả định hoạt động sẽ giữ nguyên suốt một thập kỷ.
Hãy dùng báo giá thật, thời gian của nhân viên và khối lượng quy trình khi có thể. Phép tính gần đúng dựa trên hoạt động của chính bạn hữu ích hơn số trung bình từ doanh nghiệp có hàng trăm ứng dụng và một phòng IT riêng.
- Mua: giấy phép, triển khai, cấu hình, tích hợp, quản trị, công sức duy trì thao tác vòng vo, thay đổi giá và chuyển đổi.
- Kết nối: nền tảng hoặc lưu trữ, triển khai, giám sát, bảo trì, xử lý và khôi phục khi lỗi, cùng các thay đổi API của nhà cung cấp.
- Xây dựng: khảo sát, thiết kế, phát triển, chuyển dữ liệu, hạ tầng, bảo trì, bảo mật, nhân sự phụ trách sản phẩm và thay thế sau này.
- Mọi lựa chọn: thời gian nhân viên, phản hồi khách hàng chậm, sửa lỗi, làm báo cáo, đào tạo và chi phí cơ hội của việc triển khai.
Một quy trình dịch vụ có thể dẫn đến ba quyết định khác nhau
Quay lại doanh nghiệp dịch vụ đang xử lý yêu cầu, báo giá, lịch làm việc và hóa đơn trên nhiều công cụ. Câu trả lời đúng thay đổi theo những dữ kiện mà bảng so sánh tính năng không thể cho thấy.
Mua sản phẩm quản lý dịch vụ
Chọn nếu mô hình tiêu chuẩn xử lý được báo giá, xếp lịch, quyền hạn và ngoại lệ quan trọng. Đội ngũ có một hệ thống được hỗ trợ và chấp nhận mô hình vận hành của nhà cung cấp.
Kết nối CRM, lịch và kế toán
Chọn nếu các công cụ hoạt động tốt riêng lẻ và nhập lại là vấn đề chính. Báo giá đã duyệt có thể tạo công việc trên lịch, còn công việc hoàn thành có thể tạo hóa đơn nháp mà không thay thế các sản phẩm hiện tại.
Xây hệ thống điều phối tập trung
Chỉ chọn nếu giá, điều phối, phê duyệt hoặc cam kết khách hàng đi theo quy tắc có giá trị mà các sản phẩm đã được kiểm chứng vẫn liên tục cản trở. Giữ kế toán và chức năng phổ thông khác trong sản phẩm có sẵn.
Bắt đầu bằng bước nhỏ nhất có thể chứng minh quyết định
Bước đầu có thể đổi hướng giúp giữ các lựa chọn mở trong khi tạo ra bằng chứng. Nó cũng làm lộ vấn đề về sử dụng, dữ liệu và ngoại lệ trước khi chúng bị chôn trong hợp đồng hoặc mã nguồn lớn hơn.
- Thử sản phẩm bằng trường hợp thật và ngoại lệ khó, không chỉ dữ liệu mẫu.
- Kiểm tra một điểm bàn giao trước khi tích hợp toàn bộ hệ thống công cụ.
- Xây một luồng nhỏ hoàn chỉnh từ điểm bắt đầu đến kết quả trước khi lên kế hoạch cho nền tảng.
- Xác nhận quyền truy cập API, xuất dữ liệu, điều khoản hợp đồng và phương án chuyển đổi trước khi mua.
- Xác định cách giám sát, khôi phục và người phụ trách trước khi đưa tích hợp vào vận hành.
- Đo xem thay đổi có giảm chờ đợi, nhập lại, lỗi hoặc công sức báo cáo hay không.
Dấu hiệu cho thấy còn quá sớm để quyết định
Hãy hoãn cam kết khi doanh nghiệp chưa thể mô tả rõ kết quả thành công và điều kiện vận hành an toàn. Tính cấp bách có thể đòi hỏi một biện pháp tạm thời nhỏ, nhưng không làm một hệ thống dài hạn trở nên an toàn khi yêu cầu vẫn còn mơ hồ.
- Yêu cầu chỉ là danh sách tính năng chưa được ưu tiên.
- Không ai sở hữu quy trình hoặc kết quả cuối cùng.
- Mỗi bên liên quan mô tả một quy trình khác biệt đáng kể.
- Lợi ích kỳ vọng chỉ là giúp doanh nghiệp trông hiện đại hơn.
- Hệ thống riêng không có người bảo trì hoặc ngân sách vận hành.
- Chưa đánh giá sản phẩm định mua về API, xuất dữ liệu, gia hạn hoặc chi phí chuyển đổi.
- Tích hợp không có kế hoạch cho giám sát, bản ghi đồng bộ thất bại hoặc thay đổi thông tin xác thực.
Lựa chọn tốt giúp doanh nghiệp giảm phần phải tự sở hữu
Mua cho nhu cầu phổ biến. Kết nối các điểm chuyển giao đang gây gián đoạn. Chỉ xây quy trình riêng đáng để doanh nghiệp sở hữu. Nếu quy trình chưa rõ, hãy sửa nó trước.
Mục tiêu không phải chọn phương án phức tạp nhất. Mục tiêu là làm một quy trình quan trọng trở nên đáng tin cậy với ít gánh nặng lâu dài nhất. Nếu cần thêm góc nhìn, hãy gửi các công cụ hiện tại, các điểm chuyển giao và ngoại lệ quan trọng. AMSOFT có thể giúp xác định bước hữu ích nhỏ nhất, kể cả khi câu trả lời là sản phẩm có sẵn thay vì phần mềm riêng.