Đang nạp...

Góc tư vấn: Các câu hỏi thường gặp (FAQ)


Học thuộc tất cả các quy tắc để biết cách phá vỡ chúng hợp lý (Learn the rules, break the rules, make up new rules, break the new rules)
Nếu dự án không đặc thù, không phức tạp, chúng tôi sẽ làm pilot project với một số tính năng cơ bản. Nếu dự án có độ khó cao, chúng tôi cần có cam kết đặt cọc một chi phí nhỏ để duy trì động lực cho dự án. Ngoài ra một số dự án về demo hoặc mockup cũng được xem là pilot project mà chúng tôi làm cho khách hàng.
Hãy tham gia sâu vào quy trình phát triển phần mềm của nhà thầu. Yêu cầu nhà thầu bàn giao công việc từng phần, thí dụ 2 tuần một lần. Chức năng nào làm xong có thể gửi cho khách hàng "test nhanh" để kiểm tra xem các yêu cầu ban đầu có khớp với thực tế khi vận hành không. Các yêu cầu kém khả thi sẽ được loại bỏ trong quá trình phát triển. Ngoài ra khách hàng có cơ hội xem trước "hình hài" của phần mềm mà họ sẽ sử dụng sau này, từ đó gián tiếp giảm thời gian tập huấn khi bắt đầu thực hành sử dụng phần mềm.
Nếu Web bán hàng chỉ bao gồm các tính năng đơn giản, khoảng thời gian 2 tuần là vừa đủ. Nhưng nếu nghiệp vụ đặc thù, hoặc ý tưởng sản phẩm không thuộc dòng sản phẩm "đại trà" có thể dễ dàng tìm thấy trên thị trường, thì thời gian phát triển có thể tính bằng tháng, năm. Có thể dễ dàng nhận thấy thời gian dành cho khảo sát, phân tích yêu cầu, phác thảo prototype, thiết kế chi tiết, kiểm thử, nghiệm thu, bàn giao và cả đi lại, thảo luận cũng đã chiếm khoảng một tháng.
Câu trả lời ngắn gọn nhất của chúng tôi là: Phụ thuộc vào kế hoạch ngắn hạn hay dài hạn của doanh nghiệp bạn. Chúng tôi xuất bản một số bài viết tư vấn chi tiết về mảng này, bạn có thể tìm đọc ở đây: <a href='/Pages/TigoOutsourcing' style="color:#2196F3" target="_blank">Giới thiệu dịch vụ Outsourcing của TIGO</a> và <a href='/blogstory/41' style="color:#2196F3" target="_blank">Outsource là gì? Khác nhau giữa Outsource và Product?</a>
Bạn có thể tải về mẫu lập dự toán phần mềm có tên dự án là "Car Booking" của chúng tôi tại đây: <a href="http://tigosolutions.com/Uploads/Template lập dự toán dự án phần mềm.xlsx" style="color:#2196F3">Template lập dự toán dự án phần mềm</a>
Thứ nhất, TIGO không phát triển dàn trải. Chúng tôi không phát triển các ý tưởng đột phá (disrupt). Chúng tôi chỉ chú trọng vào phân khúc mà chúng tôi có thế mạnh, đặc biệt là các giải pháp "dân dụng" đem lại giá trị bền vững. Sản phẩm của chúng tôi hướng tới mục tiêu "state-of-the-art" (đỉnh của ngách), tức là tốt nhất trong phân khúc đó. Các ý tưởng sản phẩm không có gì mới, nhưng được xây dựng bằng công nghệ mới và tư duy mới, cùng với rất NHIỀU TIỆN ÍCH MỚI mà khách hàng sẽ không thể tìm thấy ở các sản phẩm khác. Thứ hai, chúng tôi không cạnh tranh về "tuổi đời sản phẩm". Chúng tôi cạnh tranh bằng sức sáng tạo không ngừng nghỉ. Chúng tôi có lợi thế của người đi sau khi mà công nghệ mới đem đến nhiều sự đột phá cho sản phẩm và trải nghiệm người dùng.
Đúng. Không nên lạm dụng các tính năng tự động khi mà con người vẫn có thể xử lý bằng tay mà không ảnh hưởng đến công việc chính. Phần mềm có thể cung cấp chức năng backup toàn bộ Database chỉ bằng một click, nhưng nếu hỗ trợ cả "tự động" khi bạn không có mặt ở đó, thì sẽ phát sinh nhiều rủi ro. Bạn có thể đưa vào yêu cầu xây dựng tính năng "nhắc việc" (qua email, notification trên trang) vì tính năng này đơn giản hơn và hỗ trợ rộng hơn là xây dựng tính năng đặc thù "backup tự động" nhưng tốn kém và rủi ro cao.
Nếu bạn am hiểu chút về kỹ thuật, hoặc nhờ người tư vấn để đặt ra các câu hỏi cho nhà cung cấp giải pháp. Tuy nhiên có một chi tiết mà TIGO ít thấy khách hàng đặt câu hỏi nhất là đối với các phần mềm "lớn và đặt tiền". Đó là "phần mềm có cung cấp các cổng kết nối API để truy xuất dữ liệu không? Tương tự như khi bạn ra siêu thị điện máy hỏi mua TV thì bạn cần hỏi có hỗ trợ cổng kết nối HDMI hay không". Nếu câu trả lời là không có API, thì sản phẩm có phương án thay thế là import/export file không?" Nếu cả 2 câu trả lời đều là không, thì bạn sẽ gặp rủi ro để liên thông dữ liệu giữa các hệ thống sau này. Nếu phần mềm có tính "mở" kém như vậy thì đến "customize" cũng khó, huống hồ là trao đổi dữ liệu với các hệ thống khác.
Muốn xem một doanh nghiệp phần mềm có làm ra sản phẩm chất lượng hay không, hãy hỏi họ dùng quy trình quản lý lỗi như thế nào. Đặc biệt đừng quên hỏi họ có sử dụng phần mềm để theo dõi bug không hay vẫn chỉ làm thủ công (thí dụ dùng Excel để "log bug", tệ hơn là chỉ lưu giữ thông tin trong đầu thay vì ghi chú). Doanh nghiệp phần mềm mà không dùng phần mềm để quản lý, thử hỏi làm sao họ thuyết phục được khách hàng dùng phần mềm để quản lý. Những phần mềm theo dõi lỗi chuyên nghiệp còn cho phép khách hàng vào bình luận và tham gia "log bug" như một Tester.
Sau khi sản phẩm chính thức "lên sóng" (GO-LIVE), cứ cách một tuần, chúng sẽ kiểm thử hồi quy (kiểm tra lặp lại các Test Cases chính) và kiểm tra khả năng chịu tải khi chạy trên môi trường dữ liệu thật. Chúng tôi vẫn tiếp tục tiến hành kiểm thử UAT (tương tự như kiểm tra trước lúc nghiệm thu) cho đến hết giai đoạn bảo hành từ 1-2 tháng tùy hợp đồng. Trong trường hợp sản phẩm không quá đặc thù, ít độ phức tạp, ít thay đổi yêu cầu,chúng tôi cam kết duy trì bảo trì 1 năm trị giá 10-15% giá trị hợp đồng.
Trên thị trường có rất nhiều giải pháp CRM, nhóm giá rẻ có, nhóm giá đắt cắt cổ cũng có. Đặc biệt các giải pháp CRM của nước ngoài có giá rất cao, độ phủ chức năng của chúng rất lớn. Doanh nghiệp có xài hết các tính năng của CRM hay không, đó là một câu hỏi đầu tiên. Nếu bạn đã mua giải pháp CRM đó rồi, thì nếu muốn mở rộng sẽ ra sao? Thí dụ bạn muốn nó liên thông với các phần mềm tương lai như: Sales Management, Dashboard, HRM, Timesheet (Chấm công), Booking... thì có dễ dàng nâng cấp một hệ thống "phức tạp và cồng kềnh"? Đó là câu hỏi thứ hai. Các hệ thống CRM, ERP... đắt tiền (từ vài chục ngàn đến trăm ngàn USD) thường là các phần mềm có tính "đóng", rất khó để có thể mở các cổng giao tiếp dữ liệu API từ chúng để liên thông dữ liệu với các phần mềm khác. Một doanh nghiệp vừa và nhỏ sẽ không thể có ngân sách lớn để mua toàn bộ hệ sinh thái phần mềm ERP. Chúng tôi khuyến nghị bạn nên tư duy về một giải pháp "vừa đủ", được "ghép nối" từ nhiều service hoặc mô đun nhỏ (CRM, Back-office Sales, Front-end Store...) để có thể giải quyết tốt nhất các nhu cầu "theo chiều ngang" của doanh nghiệp. Nắm bắt được nhu cầu này, TIGO phát triển các giải pháp "tinh gọn" theo mô hình tính năng tối thiểu MVP (Minimum Viable Product), nhưng vẫn đảm bảo tính khả dụng cao và khả năng "customize" tốt hơn các sản phẩm cùng phân khúc trên thị trường. Chúng tôi tin rằng đến với chúng tôi, bạn chỉ cần chọn gói customize 20-30% sản phẩm mẫu là có thể giải quyết trên 80% nhu cầu của bạn.
Thông thường BA giỏi sẽ giúp bạn khoanh vùng được yêu cầu quan trọng cho bất cứ giai đoạn nào trong suốt vòng đời tồn tại của sản phẩm (ít nhất cho đến lúc nó thoái trào). BA khác với PM (quản lý dự án). Trong khi PM hỗ trợ dự án để vận hành hiệu quả, đúng kế hoạch thì BA sẽ làm việc với sản phẩm nhiều hơn là các quy trình phát triển dự án. Nếu dự án của bạn có ngân sách ít, bạn cần chú trọng vào khâu phân tích thiết kế vì với chi phí nhỏ, bạn không "có cơ hội sửa sai" nếu sản phẩm đi sai hướng. Thậm chí bạn phải bỏ nhiều thời gian vào tham gia khảo sát liên tục cùng nhà thầu cho đến khi dự án kết thúc hẳn thì mới mong có kết quả tốt. Ngược lại, nếu ngân sách lớn, bạn có nhiều cơ hội thử nghiệm nhiều ý tưởng mà không cần mất quá nhiều thời gian vào giai đoạn khảo sát. Điều này không có nghĩa là không cần BA. Bạn vẫn cần BA để hỗ trợ ra quyết định, tuy vậy bạn vẫn ưu tiên chọn con đường đi nhanh thay vì thận trọng để đạt mục tiêu xa hơn. Nếu đi sai hướng, bạn vẫn có cơ hội sửa sai.
Nếu bạn đang dùng giải pháp phần mềm trong nhiều năm và nó vẫn chạy tốt, thì không có gì lo lắng về công nghệ cũ. Nếu bạn mới bắt đầu tìm mua một giải pháp, hãy cân nhắc yếu tố công nghệ. Hiện nay các nền tảng công nghệ mới giúp giảm chi phí làm sản phẩm, đem lại nhiều trải nghiệm tốt hơn, chất lượng và bảo mật cũng tốt hơn. Lấy thí dụ, các phần mềm Web vẫn dùng mô hình "Web Forms không tuân theo kiến trúc MVC" có thể được xem là khá lạc hậu. Việc nâng cấp sẽ gặp rào cản rất lớn về chi phí. Ngày nay tư duy làm sản phẩm "nguyên khối" không còn nữa, thay vào đó là tư duy "Internet Of Things". Một trong số đó là kiến trúc đa nền tảng rời rạc (MicroServices) kết nối với nhau qua các cổng API và cơ chế đăng nhập một cửa SSO (Single SignOn). Với cách làm này, doanh nghiệp của bạn hoàn toàn có thể sở hữu hai phần mềm Web viết bằng những ngôn ngữ lập trình khác nhau (thí dụ .NET, Java, PHP...) nhưng chúng vẫn làm việc được với nhau qua API, đầu ra của dịch vụ này là nguồn cấp dữ liệu đầu vào của dịch vụ khác, do vậy toàn bộ hệ thống được trong suốt. Chúng tôi khuyên bạn nên khảo sát cùng với các chuyên gia tư vấn để có lựa chọn tốt nhất.
Nhu cầu có một Web đẹp, hiện đại, thân thiện với các thiết bị là mong muốn của bất cứ chủ sở hưu nào. Cũng giống như nhu cầu thẩm mỹ của bạn: bọc răng, thẩm mỹ khuôn mặt... Tất nhiên chi phí của những công việc làm đẹp là không hề rẻ. Trong bất cứ dự án nào cũng cần cân bằng giữa hình thức và nội dung. Trong tất cả các loại phần mềm thì phần mềm Web có độ khó về giao diện cũng như trải nghiệm người dùng (UI/UX) ở mức cao nhất. Điều này xuất phát từ bản chất công nghệ đứng đằng sau. Cùng một tập các yêu cầu giống nhau, thiết kế trang Web bao giờ cũng tốn nhiều thời gian và công sức hơn các phần mềm khác (ứng dụng Desktop app, mobile app...). Lưu ý rằng tất cả sản phẩm Web đều vận hành dưới một mái nhà chung là "trình duyệt" (Chrome, FireFox...) do vậy chúng phải tuân theo những quy định và chuẩn cực kỳ khắt khe. Chỉ cần một lỗi sai nhỏ trong thiết kế cũng có thể gây vỡ layout, biến đổi font, xê dịch các điều khiển trên trang... Những lỗi như vậy không dễ phát hiện trong quá trình kiểm thử. Một khi phát hiện ra lỗi, có thể mất nhiều giờ chỉ để sửa một chi tiết nhỏ - những "yếu tố mất thẩm mỹ" này thực tế không ảnh hưởng đến sự vận hành của toàn hệ thống. Do vậy với những dự án phiên bản 1.0, không nên đặt ra yêu cầu khá cao về trải nghiệm UI/UX ngay, mà cần tập trung vào tính năng cốt lõi và quan trọng hơn cả, giao diện phải đạt chuẩn tối thiểu "thân thiện với mobile, tablet" (chuẩn thiết kế Responsive Web Design).
Các hệ thống phần mềm với công nghệ cũ kỹ là vấn đề chung của phần lớn các doanh nghiệp hiện nay. Chi phí lớn, rủi ro cao, nhà thầu thiếu nguồn lực cho công nghệ mới ... là những yếu tố cản trở sự mở rộng này. Nếu không nâng cấp thì vấp phải sự cạnh tranh khốc liệt với các doanh nghiệp non trẻ - nhóm biết cách tận dụng công nghệ mới để đem lại giá trị cho doanh nghiệp và cải thiện năng suất lao động. Thí dụ như doanh nghiệp A muốn nâng cấp các hệ thống Web để thân thiện với mobile hơn (layout hiển thị co dãn trên màn hình mobile), nhưng nếu phát triển trên nền tảng công nghệ cũ thì hiệu quả thấp, tồn tại nhiều vấn đề chồng chéo mà chỉ công nghệ mới có thể giải quyết được. Chúng tôi sẽ tư vấn cho doanh nghiệp bạn xây dựng một cổng thông tin (Web portal) mới theo mô hình Dashboard. Web portal này sẽ kết nối lấy dữ liệu từ các dịch vụ cổng API đang được bật trên các hệ thống cũ. Việc phát triển các cổng cắm API không gặp nhiều khó khăn vì đều được hỗ trợ trên cả công nghệ cũ và công nghệ mới. Về chi tiết xây dựng Web Portal, hãy liên lạc với chúng tôi để được tư vấn cụ thể.
Dự toán đơn giản như sau: ● Do không phải là tác vụ đơn giản như thiết kế Website, landing page, mà là một dự án có "scope" rất rộng, do vậy sẽ rủi ro cao nếu chỉ có một lập trình viên (LTV). Tối thiếu là 2 LTV cho dự án này. ● Hai LTV sẽ làm full-time liên tục và về mặt kỹ thuật, không thể nào hoàn thành dự án sớm hơn 1 tháng. Tổng số giờ trong một tháng sẽ là 172 x 2 = 344 giờ. Mỗi giờ có tiền công trung bình 3$, tức khoảng 67,000VNĐ. Tiền công cho 2 LTV là 344 x 67N = 23 triệu. ● Chi phí Test và quản lý dự án, phân tích thiết kế chiếm tối thiểu 25% tổng chi phí coding, vào khoảng 5.8 tr. Như vậy tổng chi phí thực hiện dự án xấp xỉ 30 triệu. Nếu nhó hơn con số dự toán này, dự án có nguy cơ "fail" rất lớn !!!
Đúng. MVP là viết tắt của Minimum Viable Product, nghĩa là sản phẩm vận hành vừa đủ với các tính năng tối thiểu. Những tính năng "hay ho" nhưng chưa cần thiết sẽ không xuất hiện ở phiên bản 1.0. Những tính năng "có cũng được, không có cũng không sao" cần phải loại bỏ khỏi phiên bản đầu tiên. Nếu không chốt được yêu cầu chính, làm sản phẩm dễ lan man sang các tính năng "bạn hoặc lãnh đạo thấy hay, nhưng người dùng cuối lại thấy không cần thiết", từ đó kéo dài thời gian làm dự án, gây lãng phí tiền bạc và nguồn lực.
MVP (Minimum Viable Product) là mô hình sản phẩm tinh gọn, bao bọc bởi một một đường giới hạn bám sát mục tiêu (objectives) của dự án. Thí dụ: Tính năng đăng ký, đăng nhập và quản lý Users là bắt buộc phải có trong đường giới hạn đó. Nhưng tính năng tạo nhóm không cần thiết có trong MVP. Đối với tính năng phân quyền thì "có thể có, có thể không". Trong phiên bản 1.0 thì phân quyền có thể dừng lại ở tính năng đơn giản là "Public" hoặc "Private", tức đã ngăn truy cập thì sẽ không có ai được nhìn thấy nữa (trạng thái riêng tư - private). Hãy chờ đến các phiên bản sau này, khi có chi phí mở rộng thì có thể nâng cấp phân quyền sao cho có thể "share" cho từng nhóm người cụ thể, và phạm vi truy cập không chỉ là từng thực thể dữ liệu (data entity) mà được trải dài trên một vùng miền dữ liệu. Cách làm tương tự như chia sẻ trên Google Documents.
Câu trả lời là tùy thuộc vào bản chất nghiệp vụ của bài toán. Nếu chỉ là một Web tin tức, Web cá nhân, portfolio doanh nghiệp thì sử dụng WordPress là phương án tối ưu. Nếu bạn muốn vận hành cả Web bán hàng trên nền tảng này, bạn cần tích hợp một framework bên thứ 3 như WooCommerce. Yêu cầu càng phức tạp thì càng cần đến phương án tích hợp nhiều plugin nhỏ để giảm chi phí, tuy nhiên sẽ phát sinh chi phí chuyên gia. Vì xây dựng những hệ thống mở rộng của WordPress sẽ đòi hỏi các chuyên gia trình độ cao. Nhược điểm của giải pháp lựa chọn WordPress/WooCommerce là công việc "customize" rất khó khăn và phức tạp. Lúc này làm chủ WordPress sẽ còn khó khăn hơn lập trình một ngôn ngữ. Nhìn chung WordPress phù hợp với các Web site quản lý nội dung. Nhưng để kiểm soát tốt nhất về "performance" và khả năng "customize" sau này, Doanh nghiệp nên tìm một đơn vị tư vấn lựa chọn nhà thầu có chuyên môn sâu về một nền tảng nào đó (thí dụ Microsoft .NET).
Man-hours là khối lượng thực hiện công việc bởi một nhân viên có năng lực trung bình trong một giờ, còn man-days sẽ là số man-hours chia cho 8. Được sử dụng để ước tính tổng số lượng lao động không bị gián đoạn cần thiết để thực hiện một nhiệm vụ, dự án.... Thí dụ nếu dự án có tổng dự toán là 1000 man-hours, có nghĩa là một nhân viên sẽ làm liên tục 1000 giờ để hoàn thành. Nếu hai nhân viên làm song song thì sẽ cần 500 giờ để hoàn thành. Mười nhân viên làm song song và liên tục thì cần 100 giờ, tức 2.5 tuần để hoàn thành. Thông thường một dự án phần mềm có quy mô 1000 man-hours chỉ cần 3-4 lập trình viên thực hiện trong 1.5 - 2 tháng. Nếu số lượng nhân sự lớn hơn mức này sẽ làm gia tăng các chi phí: quản lý, giám sát chất lượng, kiểm soát thay đổi (requirement changes), kiềm chế rủi ro ... Ngoài ra Timeline cần phải có mức giãn hợp lý ở từng giai đoạn nhỏ hơn, tạo ra các vùng đệm (buffer) cần thiết để ổn định các tính năng đã "code" trước khi bắt tay vào xây dựng các tính năng mới, giống như cơ thể chúng ta cần có những khoảng thời gian nghỉ ngơi hợp lý. Đó là lý do vì sao Timeline thực tế bao giờ cũng phải đảm bảo lớn hơn con số lý tưởng xét về mặt lý thuyết, thường sẽ vênh nhau 1-2 tuần. Chúng tôi khuyến nghị những dự án 1000 man-hours nên có Timeline từ 2 - 2.5 tháng để đảm bảo chất lượng tốt nhất, đề phòng mọi rủi ro về thay đổi yêu cầu giữa chừng có thể ảnh hưởng đến tiến độ và chi phí dự án. Muốn biết thêm chi tiết, hãy liên hệ với TIGO để được tư vấn đầy đủ.
Nếu bạn bỏ tiền mua một "phần mềm mẫu", tức là thiết kế mọi thứ đã có sẵn, chỉ việc đăng ký tài khoản là dùng được ngay, thì bạn có thể tiết kiệm được rất nhiều chi phí so với tự "may đo" một giải pháp với rất nhiều yêu cầu phức tạp, đặc thù. Còn nếu cần phải customize thêm phần mềm mẫu để đạt được một số hiệu quả nào đó cho doanh nghiệp của bạn, thí dụ bạn muốn bổ sung thêm nhiều tính năng tự động hóa (automation rules) thì chi phí sẽ tăng, ngoài ra sẽ xuất hiện rủi ro tiềm ẩn nếu bạn không hoạch định tốt các yêu cầu bạn muốn. Có những yêu cầu "hay ho" nhưng không phải là thời điểm tốt để triển khai. Do vậy mấu chốt quan trọng là bạn nên tham gia phân tích chuyên sâu cùng với đoàn khảo sát của nhà thầu để biết chính xác điều gì bạn muốn cho phiên bản sắp tới, khoanh vùng những hạng mục ưu tiên cao. Nếu thực hiện tốt và liên tục các nhiệm vụ này chắc chắn sẽ làm giảm chi phí dự án xuống rất nhiều, đồng thời sẽ góp phần nâng cao chất lượng của sản phẩm.
Các mô hình chúng tôi áp dụng bao gồm: Agile/Scrum, Kanban, Lean Software Development, Team-based... Tùy từng tính chất dự án mà chúng tôi áp dụng một mô hình khác nhau. Thí dụ các sản phẩm từ các đối tác là các startup thường có khối lượng yêu cầu khá lớn từ giai đoạn sơ khai, cho nên chúng tôi sẽ áp dụng mô hình phát triển tinh gọn (Lean Development) để đẩy nhanh sản phẩm ra thị trường, đồng thời giảm chi phí cho họ khi thời gian đầu họ chưa có doanh thu. Đối với các sản phẩm mới "go-live" một thời gian thì chúng tôi sẽ áp dụng Scrum để kiểm soát tốt hơn số lượng các thay đổi dồn dập rất lớn trong một thời gian ngắn. Đối với các sản phẩm đã được "thử lửa" trong một thời gian dài thì chúng tôi áp dụng mô hình Team-based để giữ sự ổn định, dành nhiều thời gian cho đảm bảo chất lượng, các kỹ sư lúc này làm việc vì mục tiêu lâu dài bền vững hơn là mục tiêu về tiến độ.
"On-premise softwate" là một dạng phần mềm tại chỗ được cài đặt và chạy trên các máy tính cá nhân hoặc máy chủ của tổ chức, thay vì truy cập vào trung tâm máy chủ từ xa như trang trại máy chủ (server farm) hoặc đám mây (cloud). Phần mềm "on-premise" đôi khi được gọi là sản phẩm “gói gọn” (shrinkwrap) và phần mềm từ xa thường được gọi là “phần mềm dưới dạng dịch vụ” hoặc “phần mềm đám mây”. Phần mềm "on-premise" có thể là một desktop-app (phần mềm cài đặt trên máy cá nhân), Client-Server apps (đòi hỏi cài đặt cả trên máy cá nhân và máy chủ tổ chức), hoặc Web app (phần mềm Web triển khai trong nội bộ doanh nghiệp hoạt động ngay cả khi không có Internet). Về mặt lý thuyết thì phần mềm "on-premise" sẽ không có nhiều lợi thế như phần mềm đám mây nếu xét về tốc độ nâng cấp và hoàn thiện. Nhưng trên thực tế hiện nay, các phần mềm "on-premise" vẫn đang được ưa chuộng vì khách hàng có toàn quyền với hệ thống của mình, đặc biệt nếu có bộ phận IT chuyên nghiệp để vận hành hệ thống phần mềm, bao gồm backup dữ liệu và tối ưu máy chủ để đạt được sự tối ưu về hiệu năng phần mềm, thì giải pháp "on-premise software" luôn là sự lựa chọn an toàn cho cả doanh nghiệp và nhà thầu.

Chat với chúng tôi + 

CRM, e-Marketing, Portal, ERP, Accounting, HelpDesk, Service Desk, Dashboard, B2B, B2C,giải pháp quản trị doanh nghiệp, cổng thông tin, chăm sóc khách hàng,dịch vụ phần mềm chuyên nghiệp, dịch vụ thiết kế Web chuyên nghiệp, phần mềm thông minh,phần mềm tiện ích,freelancer,phần mềm POS, phần mềm quản lý bán hàng, phần mềm quản lý văn phòng, phần mềm booking, thiết kế website, thiết kế landing page, phần mềm thu chi, email marketing, quảng cáo trực tuyến, google adwords, online marketing