Trong phần đầu của loạt bài này , chúng ta đã thảo luận về việc làm thế nào chúng ta có thể trở nên phụ thuộc một cách không lành mạnh vào nhà cung cấp và trên hết, những vấn đề mà điều này có thể gây ra cho công ty của chúng ta.
Hôm nay, chúng ta sẽ xem xét những việc mình có thể làm để tránh sự phụ thuộc đó.
1. Giữ quyền sở hữu đối với bí quyết quy trình và hệ thống cũng như các kế hoạch phát triển chúng.
Nếu bạn quyết định không muốn lo lắng về CNTT và chỉ đưa ra những chỉ dẫn chung chung cho nhà cung cấp CNTT của mình, bạn đang đi đúng hướng để trở nên phụ thuộc. Điều có thể khiến bạn ngạc nhiên là cách tiếp cận này thường gây ra vấn đề cho chính nhà cung cấp; bởi vì sau một thời gian, các yêu cầu của khách hàng bắt đầu chồng chéo và trở nên rối rắm; và việc đáp ứng các yêu cầu mới trở thành một vấn đề lớn đối với nhà cung cấp.
Đối với một công ty muốn duy trì khả năng cạnh tranh, điều quan trọng là phải xem CNTT như một công cụ hỗ trợ, cải thiện và đo lường các quy trình của mình. Việc tìm ra cách thực hiện điều này không khó, bởi vì hiện nay chúng ta đã có đủ các phương pháp và tiêu chuẩn cho phép chúng ta nắm được tổng quan về các quy trình và lập kế hoạch hiệu quả.
- Kiến trúc doanh nghiệp – một cách thức mô tả các mục tiêu của tổ chức; các phương thức đạt được những mục tiêu này thông qua các quy trình kinh doanh; và cách thức các quy trình này có thể được hỗ trợ bởi công nghệ. Để biết thêm thông tin, hãy xem bài viết "Đừng để bị sa lầy" bởi kiến trúc doanh nghiệp kém hiệu quả. Hai cách tiếp cận nổi tiếng nhất về kiến trúc doanh nghiệp có thể được tìm thấy trên các trang web của The Open Group và Zachmann .
- Mô tả quy trình – các tiêu chuẩn nổi tiếng và được sử dụng rộng rãi nhất được tạo ra bởi Open Management Group (www.omg.org). Mô tả quy trình theo đặc tả BPMN (Business Process Model and Notation) cho phép ban quản lý công ty dễ dàng đọc và ghi lại các quy trình diễn ra trong công ty của họ.
- Tài liệu hướng dẫn sử dụng – đây không nhất thiết phải là tài liệu do nhà cung cấp viết rồi cất vào ngăn kéo cho bụi bám. Một cách tiếp cận tốt là quay video hướng dẫn người dùng cách sử dụng ứng dụng trong công việc hàng ngày; từ đó đơn giản hóa việc hỗ trợ sản phẩm và đào tạo cho người dùng mới. Các video thường chỉ dài vài phút và mô tả mọi thứ bạn cần biết để sử dụng hệ thống một cách hiệu quả. Ví dụ: hãy xem hướng dẫn sử dụng Yammer trong một dự án nghiên cứu ; hoặc hướng dẫn cách đặt hàng từ một cửa hàng trực tuyến .
Tất cả các tiêu chuẩn và phương pháp luận đều đi kèm với tài liệu và tài liệu nghiên cứu toàn diện mô tả chi tiết từng lĩnh vực. Theo kinh nghiệm của tôi, việc thuê một chuyên gia để lựa chọn những phần của phương pháp luận phù hợp với từng công ty cụ thể là rất đáng giá.
Nếu bạn xử lý kiến thức chuyên môn của mình theo một hình thức chuẩn hóa, bạn sẽ không chỉ có một công cụ để thảo luận các chủ đề dẫn đến sự cải tiến của công ty, mà còn có được sự chắc chắn rằng bạn sẽ tìm thấy điểm chung với phần lớn các nhà cung cấp hiện tại và tiềm năng của mình.
Nếu bạn muốn thay đổi điều gì đó trong quy trình và luồng thông tin của mình, hãy bắt đầu bằng cách thay đổi cách tổ chức công việc; hoặc ở cấp độ mô hình hoặc thông qua một thử nghiệm thí điểm – kiểm tra xem sự thay đổi có mang lại lợi ích như bạn mong đợi hay không. Sau đó, tính toán lợi ích của sự thay đổi và chi phí thực hiện. Nếu mọi thứ đều ổn, hãy bắt đầu sửa đổi hệ thống; và nếu không, bạn có thể dừng lại mà không gặp vấn đề gì. Khi bạn giao phó hoàn toàn việc này cho một nhà cung cấp bên ngoài, rất ít người có đủ can đảm để dừng một dự án mà chúng ta đã đầu tư nguồn lực vào.
2. Dữ liệu phải thuộc về bạn trong mọi trường hợp.
Dữ liệu được lưu trữ bởi nhà cung cấp của chúng tôi; hiện tại chúng tôi đã xảy ra mâu thuẫn với họ và họ nói rằng dữ liệu thuộc về họ... Thật không may, tình huống này không phải là hiếm gặp như bạn nghĩ. Nó không thường xảy ra với các nhà cung cấp dịch vụ đám mây và lưu trữ, như mọi người thường cho rằng; mà thường xảy ra nhất với các hệ thống được phát triển tùy chỉnh, nơi dữ liệu được lưu trữ bên trong một "hộp đen" hoàn toàn do nhà cung cấp kiểm soát.
Đây là cách truyền thống để giữ khách hàng dưới sự kiểm soát của nhà cung cấp. Vấn đề này thường có thể được giải quyết theo hai cách – bằng cách kiểm soát trực tiếp dữ liệu hoặc bằng cách đảm bảo phương thức thu thập dữ liệu đáng tin cậy ở định dạng có thể sử dụng được.
Ví dụ: một dịch vụ quản lý danh bạ email mà chúng ta có được khi đăng ký trên trang web của nhà cung cấp. Cách tiếp cận đầu tiên là đảm bảo dữ liệu được sao chép vào hệ thống của chúng ta; và cách thứ hai là thường xuyên tải xuống thông tin được lưu trữ trong hệ thống của nhà cung cấp và lưu trữ nó với chúng ta để "phòng khi cần".
Ngay cả trong hệ thống của chúng ta, nơi việc lưu trữ dữ liệu được ghi chép đầy đủ, phương pháp xuất dữ liệu sang bảng chuẩn, cơ sở dữ liệu hoặc XML cũng có thể tạo điều kiện thuận lợi rất nhiều cho việc tích hợp một hệ thống mới. Điều quan trọng là phải thiết lập các quy trình trích xuất dữ liệu; xác minh rằng việc xuất dữ liệu hoạt động tốt; và định dạng được ghi chép đầy đủ; bởi vì thời điểm quan trọng nhất khi chúng ta cần truy xuất dữ liệu lại chính là thời điểm tồi tệ nhất để phát hiện ra rằng việc xuất dữ liệu không hoạt động hoặc dữ liệu được xuất hoàn hảo lại được mã hóa ở định dạng mà chúng ta không thể làm việc được.
Các yêu cầu nêu trên cần được kiểm chứng khi chấp nhận bất kỳ chức năng mới hoặc thay đổi nào đối với hệ thống từ nhà cung cấp.
3. Giữ lại quyền sở hữu trí tuệ đối với các ứng dụng
Quyền sở hữu ứng dụng bao gồm quyền sở hữu mã nguồn hoặc thiết kế của ứng dụng. Nếu chúng ta không kiểm soát được mã nguồn, chúng ta sẽ gặp rủi ro là khi muốn thay đổi nhà cung cấp, chúng ta sẽ phát hiện ra rằng nhà cung cấp hiện tại sở hữu một phần quan trọng của mã nguồn và sẽ không sẵn lòng cung cấp miễn phí. Chúng ta có thể tránh điều này bằng cách xác định rõ ràng quyền sở hữu trong hợp đồng; nêu rõ rằng mã nguồn được phát triển do những thay đổi được yêu cầu là tài sản độc quyền của chúng ta; hoặc những thay đổi này được tạo ra theo giấy phép cho phép chúng ta sử dụng và phân phối chúng miễn phí.
Ngay cả khi chúng ta đã giành được quyền sở hữu theo hợp đồng, điều đó không có nghĩa là nhà cung cấp mà chúng ta sắp chấm dứt hợp đồng sẽ cho phép chúng ta truy cập vào mã nguồn. Vì lý do này, việc lưu trữ hệ thống kiểm soát nguồn, wiki và các tài liệu khác với bên thứ ba là rất cần thiết, và đối tác đó phải có nghĩa vụ lưu trữ dữ liệu ở một địa điểm và thời điểm cụ thể để chúng ta có thể truy cập vào các phiên bản hiện hành.
4. Tích hợp hệ thống thay vì mở rộng chức năng
Giao diện lập trình ứng dụng (API) dịch vụ web hiện nay là một tính năng phổ biến trong nhiều ứng dụng thương mại và mã nguồn mở. Điều này có nghĩa là tất cả các tính năng hoặc chức năng có sẵn cho người dùng ứng dụng cũng có thể được sử dụng giữa các hệ thống và ứng dụng khác nhau.
Bằng cách sử dụng các giao thức và tiêu chuẩn để định nghĩa giao diện này, các dịch vụ này tạo thành một phương tiện giao tiếp và nền tảng thống nhất; một ứng dụng được viết bằng một ngôn ngữ hoặc trên một hệ điều hành có thể truy cập được bởi các hệ thống được viết theo cách hoàn toàn khác. Dữ liệu được truyền tải ở định dạng chung, chẳng hạn như XML hoặc JSON; và mã nguồn của cả hai hệ thống vẫn hoàn toàn độc lập.
Ngày nay, người dùng nào cũng có thể hình dung được việc tích hợp hệ thống trông như thế nào. Sau cùng, tất cả chúng ta đều sử dụng các dịch vụ ứng dụng web được tích hợp với nhau – ví dụ: Lịch Google với Danh bạ Google và Gmail. Nếu chúng ta quyết định bắt đầu sử dụng một lịch khác thay vì lịch hiện có, chúng ta chỉ cần kết nối nó với dữ liệu hiện có. Phương pháp thay đổi hệ thống này không khả thi nếu chúng ta có hệ thống riêng, mà ban đầu chúng ta chỉ mua để kế toán và dần dần yêu cầu nhà cung cấp phát triển thêm mô-đun CRM, mô-đun dịch vụ, v.v.
Nguyên tắc tương tự cũng áp dụng cho việc tích hợp với các hệ thống được cung cấp dưới dạng dịch vụ bởi các nhà cung cấp dịch vụ đám mây (SaaS – Software as a Service). Việc sử dụng các dịch vụ web giúp tách biệt các ứng dụng riêng lẻ, làm cho toàn bộ hệ thống trở nên linh hoạt và minh bạch hơn. Ngược lại, các liên kết cố định giữa các mô-đun khác nhau tạo điều kiện thuận lợi cho nhà cung cấp tăng sự phụ thuộc của chúng ta vào họ, làm tăng độ phức tạp của mã nguồn, và tính linh hoạt của hệ thống sẽ bằng với phần kém linh hoạt nhất.
5. Cố gắng giảm thiểu tối đa các thay đổi đối với hệ thống tiêu chuẩn.
Hãy cố gắng triển khai hệ thống cần thiết với mức độ sửa đổi tối thiểu so với hệ thống tiêu chuẩn. Thông thường bạn không phải là khách hàng đầu tiên của nhà cung cấp. Hãy tận dụng tối đa kinh nghiệm của nhà cung cấp với các khách hàng khác trong quá trình triển khai. Bạn có thể sẽ ngạc nhiên về hiệu quả được cải thiện của một số quy trình hoặc việc một số dữ liệu mà chúng ta từng bỏ qua sẽ trở thành lợi thế cạnh tranh của chúng ta.
Nếu chúng ta cần thực hiện những thay đổi lớn về chức năng của ứng dụng, điều này có thể làm phức tạp đáng kể quá trình chuyển đổi sang các phiên bản mới trong tương lai; và bất kỳ quá trình chuyển đổi nào cũng sẽ gặp nhiều thách thức về mặt phát triển và triển khai.
6. Sử dụng nhiều nhà cung cấp
Hãy cố gắng tự quản lý toàn bộ quá trình thiết kế, phát triển, triển khai và vận hành hệ thống, đừng giao phó cho nhà cung cấp. Việc tách biệt các nhà phân tích nghiệp vụ khỏi các nhà phát triển là một ý tưởng hay; ví dụ, nên thuê các chuyên viên kiểm thử độc lập, không thuộc nhóm phát triển. Họ sẽ làm việc hiệu quả hơn, và khả năng bạn nhận được sản phẩm hoàn hảo sẽ cao hơn. Nếu có bên thứ ba chịu trách nhiệm vận hành (ví dụ: nhà cung cấp dịch vụ đám mây), hãy đảm bảo rằng họ sẽ thúc đẩy các nhà phát triển tạo ra sản phẩm giảm thiểu tối đa các sự cố vận hành hệ thống.
7. Quy định rõ quy trình chấm dứt hợp đồng trong hợp đồng; bao gồm cả các điều khoản phạt đối với nhà cung cấp.
Việc chấm dứt hợp tác được quy định như thế nào trong hợp đồng? Thông báo trước ba tháng; sau đó bạn ngừng thanh toán và nhà cung cấp ngừng hỗ trợ? Điều đó là hoàn toàn không thỏa đáng.
Cần phải xác định rõ nhà cung cấp hiện tại phải cung cấp những tài liệu gì và với chất lượng như thế nào cho bạn; hoặc trực tiếp cho nhà cung cấp mới; trong thời gian thông báo. Nếu bạn đã bảo đảm quyền sở hữu trí tuệ đối với thiết kế, mã nguồn và các phần khác của tài liệu được đề cập ở điểm 3, thì càng tốt. Khi ký kết hợp đồng với nhà cung cấp, nên kiểm tra với các công ty xếp thứ 2 và thứ 3 xem họ cần những gì nếu họ tiếp quản việc phát triển và bảo trì từ công ty thắng thầu.
8. Thông báo cho nhà cung cấp về kế hoạch phát triển trong tương lai.
Hãy xây dựng mối quan hệ đối tác lâu dài với các nhà cung cấp của bạn. Nếu bạn thường xuyên thảo luận về kế hoạch phát triển và các vấn đề chiến lược với họ, chứ không chỉ là những thay đổi chức năng hiện tại, thì nhà cung cấp có thể đưa ra các đề xuất tạo ra một kiến trúc hệ thống ổn định, hiệu quả và tiết kiệm chi phí, không chỉ đáp ứng các yêu cầu hiện tại mà còn cả các yêu cầu trong tương lai. Để làm rõ các yêu cầu của mình, bạn có thể sử dụng, ví dụ, phương pháp MuSCoW, phương pháp này chia các yêu cầu thành các danh mục sau:
- Phải có – nhất định phải có
- Đáng lẽ ra – nên có
- Giá mà có – Thật tuyệt nếu có
- Sẽ không có vào thời điểm này – không cần thiết phải có vào lúc này.
9. Thu thập ý kiến và quan điểm từ các bên khác
Đừng mãi dậm chân tại chỗ; hãy theo dõi xu hướng; tìm kiếm những phương pháp và thực tiễn tốt nhất; và luôn để mắt đến mọi thứ. Hãy thuê một công ty để có ý kiến thứ ba – họ sẽ đánh giá các quyết định của bạn từ cả góc độ kỹ thuật và chiến lược. Việc này không nhất thiết phải tốn kém. Và việc tư vấn như vậy rất đáng giá vì nó sẽ giúp bạn tránh được những sai lầm. Theo kinh nghiệm của tôi, tôi biết một trường hợp nhà cung cấp đã ép khách hàng đầu tư vài triệu krona để giải quyết vấn đề do chính họ gây ra; và một nhà tư vấn đã phát hiện ra rằng khoản đầu tư đó sẽ không giải quyết được vấn đề vì vấn đề nằm ở chỗ khác.
Một chuyên gia tư vấn có thể giúp bạn xác định chiến lược; tạo ra nhu cầu; đánh giá các lựa chọn; và nhìn nhận vấn đề từ một góc độ bất ngờ. Họ cũng có thể giúp bạn kiểm toán nhà cung cấp và đảm bảo kết quả tốt nhất có thể cho bạn. Chuyên gia tư vấn luôn cần ghi nhớ rằng bạn muốn độc lập với bất kỳ nhà cung cấp cụ thể nào và bạn nhận thức được giá trị của bí quyết chuyên môn của mình như một lợi thế cạnh tranh.
Lựa chọn nhà cung cấp phù hợp liên quan đến quản lý rủi ro.
Tôi tin rằng sau khi đọc bài viết này, bạn đã có cái nhìn rõ ràng hơn về cách biến nhà cung cấp thành đối tác cùng thành công chứ không phải trở thành chư hầu của họ. Ngăn ngừa những tình huống khó chịu nằm ở việc quản lý rủi ro một cách nhất quán và lựa chọn các giải pháp cân bằng giữa yêu cầu hiện tại và tính linh hoạt trong tương lai. Bằng cách tuân thủ các nguyên tắc trên, bạn sẽ đảm bảo lựa chọn đúng nhà cung cấp và hệ thống mới.
