Làm thế nào tôi có thể truyền đạt những rủi ro của việc thay đổi phần mềm của nhà cung cấp?

Chúng tôi có một vấn đề lớn khi tôi làm việc và tên của nó là "tùy biến". Chúng tôi có một hệ thống phần mềm nhà cung cấp cũ (hơn 10 năm) mà bộ phận kế toán và CNTT của chúng tôi trước đây yêu thích để tùy chỉnh. Đâu đó, phần mềm này bắt đầu rất lỗi. Sau đó, tôi đã được thuê sau phần lớn các tùy chỉnh.

Gần như mọi vấn đề tôi tìm thấy với hệ thống là kết quả trực tiếp của việc tùy chỉnh; tất cả mọi thứ chúng tôi thay đổi rủi ro phá vỡ phần mềm tài chính quan trọng kinh doanh. Tuy nhiên, bộ phận kế toán tiếp tục đề xuất các thay đổi (vì chúng tôi luôn nói có!) Và dường như có rất ít sự tôn trọng đối với các thay đổi có thể ảnh hưởng như thế nào .

Một số thay đổi gây ra không có vấn đề; các biểu mẫu có thể được (và có nghĩa là) được tùy chỉnh trong phần mềm của nhà cung cấp, chúng ta có thể di chuyển xung quanh các trường của biểu mẫu, loại bỏ chúng, ect. Nhưng đối với mọi tùy chỉnh vô hại như thế, họ cũng đề xuất các thay đổi như thủ tục được lưu trữ và kích hoạt để thao tác dữ liệu trong cơ sở dữ liệu cho ứng dụng của nhà cung cấp.

Gần đây tôi (hầu như) đã khiến họ ngừng cố gắng nhập khách hàng từ một chương trình của nhà cung cấp vào một chương trình khác vì thông tin hoàn toàn không tương thích. Vấn đề của tôi với cách giải quyết đó là vì tôi thấy hệ thống không hoạt động ở phía người dùng; nhiệm vụ phức tạp hơn họ nghĩ nên họ đã từ bỏ. Bất kể nhiệm vụ phía người dùng dễ dàng như thế nào, thao tác họ muốn không nên được thực hiện.

Làm cách nào tôi có thể thông báo rằng việc thay đổi cách hệ thống này hoạt động có rủi ro, đặc biệt là khi tính hợp lệ của dữ liệu bị đe dọa? Tôi là một người thuê mới (6 tháng) và nó trở thành hiện trạng, nhưng nó có nguy cơ về tính hợp lệ của dữ liệu tài chính và hợp đồng hỗ trợ của chúng tôi - một khi hỗ trợ của nhà cung cấp nghe thấy "X đã được tùy chỉnh", điều đó mang lại cho họ nhiều lý do không để hỗ trợ chúng tôi hoặc cho chúng tôi biết đó là lỗi của chúng tôi.

Rủi ro / phần thưởng của việc tùy chỉnh các hệ thống là cung cấp lợi thế cạnh tranh cho phép công ty của bạn cung cấp một cái gì đó khác biệt so với các doanh nghiệp khác trong không gian của bạn.

Các tổ chức lớn hơn mà tôi đã làm việc có được lợi thế cạnh tranh từ việc tùy chỉnh và trong suy nghĩ đó, họ khiến họ làm mọi việc hiệu quả hơn, cung cấp nhiều tính năng hơn hoặc kiếm được nhiều tiền hơn.

Thực tế là tôi giao tiếp trong những tình huống này là một sự đánh đổi. Khi thực hiện những thay đổi này cho một hệ thống, tổ chức đang phát triển nền tảng kiến ​​thức / chuyên môn nội bộ của riêng mình về các hệ thống của họ mà họ sẽ không thể dễ dàng thực hiện được. Cơ sở kiến ​​thức nội bộ này cần được duy trì và tổ chức tốt hơn để những thay đổi này có thể được theo dõi và quản lý. Điều đó cũng có nghĩa là nó có thể làm mất hiệu lực hợp đồng hỗ trợ của nhà cung cấp và các khía cạnh khác mà tài sản CNTT mà công ty sử dụng cho quy trình này.

Rủi ro lớn nhất mà tôi nói đến là nâng cấp phiên bản lên phần mềm của nhà cung cấp khi một công ty áp dụng triết lý quản lý dữ liệu này .. Đây là một trong những rủi ro rất có thể xảy ra khi có thứ gì đó sắp hỏng. Công ty cần phải hiểu sự đánh đổi đang được thực hiện và mọi người cần phải tham gia vào quá trình cần thiết để hỗ trợ họ.

Đối với văn hóa của bạn, bạn có thể giới thiệu một sự tương tự hoặc triết lý nhưng bạn cần một người chịu trách nhiệm cho doanh nghiệp nhận ra rằng họ đang tạo ra một môi trường thậm chí còn phụ thuộc nhiều hơn vào chuyên gia kinh doanh nội bộ, những người thay đổi các hệ thống này.

Đối với sự tương tự xe hơi, nó không phải là thợ máy cần biết những thay đổi đang được thực hiện đối với một chiếc xe, chủ sở hữu của nó cần phải hiểu rằng nó có thể mất cơ học đặc biệt, nhiều tiền hơn hoặc mất dịch vụ đó trong một khoảng thời gian. Giáo dục chủ sở hữu là chìa khóa cho cuộc trò chuyện này.

Giao tiếp với cư dân văn phòng? Tôi muốn đi với sự tương tự.

Nói với họ rằng tất cả những thay đổi này đang biến chiếc xe nội địa 4 cửa điển hình của bạn thành một chiếc xe nước ngoài kỳ lạ. Mỗi khi bạn mang nó vào cửa hàng cơ khí, từ tinh chỉnh, đến ánh sáng bị nghiền nát, đến đại tu truyền tải, nó sẽ đắt hơn. "Chúng tôi không có các bộ phận, chỉ có đại lý có kiến ​​thức đặc biệt mới có thể chạm vào đó, chúng tôi đã thử nhưng hướng dẫn sử dụng bằng tiếng Đức".

Bạn là thợ cơ khí phụ trách giữ cho nó chạy. Cơ sở dữ liệu là động cơ. Toàn bộ hệ thống là xe. Các kế toán lái xe xung quanh. Chú thỏ nhỏ dễ thương mà các kế toán đã bỏ lỡ là một nhân vật có tiếng trong tên cuối cùng của một khách hàng mới. Cột đèn họ quấn chiếc xe của họ xung quanh là lỗi nghiêm trọng được đưa ra khi họ muốn thêm một quả bóng sàn nhảy trong xe.

Những người khác đã cung cấp một số ví dụ hay về việc sử dụng các chất tương tự và ngôn ngữ khác để trả lời câu hỏi chính của bạn, đó là "Làm thế nào tôi có thể truyền đạt việc thay đổi cách hệ thống này hoạt động có rủi ro, đặc biệt là khi tính hợp lệ của dữ liệu bị đe dọa?"

Nhưng dựa trên nhận xét rõ ràng của bạn về cách phân công nhiệm vụ đến với bạn, tôi không chắc rằng bất kỳ sự tương tự nào sẽ giúp bạn trong tình huống - có vẻ như mọi người không hiểu nhầm những gì họ đang yêu cầu, nhưng đúng hơn là họ không quan tâm. Tôi đã từng ở đó - có lẽ tất cả chúng tôi đã ở đó - và trong những tình huống này, tôi có xu hướng đưa ra một nỗ lực lớn hơn để hoàn toàn rõ ràng về các vấn đề, thay vì vùi dập chúng theo nghĩa là để dạy thay vì cảnh báo .

Tập trung vào những gì bạn có thể làm, điều này không đơn lẻ làm thay đổi suy nghĩ của mọi người khi yêu cầu các tùy chỉnh khiến rủi ro toàn vẹn dữ liệu và hợp đồng hỗ trợ nhà cung cấp gặp rủi ro, mà thay vào đó là nói trực tiếp với CTO của bạn (và đến lượt CFO) rất rõ ràng về các vấn đề trong tầm tay.

Đặc biệt:

• Yêu cầu CTO hoặc CFO của bạn (hoặc bất kỳ ai nắm giữ nó) để xem hợp đồng dịch vụ với nhà cung cấp, bởi vì (và tôi nói những lời này) bạn đang được yêu cầu thực hiện các nhiệm vụ có khả năng vi phạm thỏa thuận và bạn muốn có thể chỉ ra rằng trong báo cáo khả thi nhiệm vụ của bạn. Họ có thể không đưa nó cho bạn, nhưng nói những lời đó thường khiến mọi người ở những vị trí đó hiểu rõ hơn rằng bạn nghiêm túc và tình hình có thể nghiêm trọng.

• Nếu bạn làm được một bản sao của thỏa thuận, sau đó khi bạn viết báo cáo nhiệm vụ khả thi của bạn, trích dẫn trực tiếp từ nó khi có sự vi phạm rõ ràng.

• Nếu bạn không nhận được một bản sao của thỏa thuận, thì hãy đặt chỗ trước rất rõ ràng về cách thay đổi có thể khiến công ty rơi vào tình trạng tồi tệ liên quan đến mối quan hệ với nhà cung cấp.

• Nếu mối quan tâm của bạn không có vấn đề vì thỏa thuận của nhà cung cấp nhưng "đơn giản" là có vấn đề vì ảnh hưởng xếp tầng của thay đổi, hãy phác thảo điều đó có nghĩa là gì: nếu nó lộn xộn như bạn nói, thì có lẽ bạn chỉ có một hoặc hai gạch đầu dòng trước khi bạn có thể sử dụng dòng "và nó sẽ lật đổ như một ngôi nhà thẻ".

Nói tóm lại, hãy làm những gì bạn có thể để chỉ ra rất rõ ràng và chính xác vấn đề và tác động của nó ngay cả một hoặc hai bước xuống dòng. Rằng bạn có cơ hội đã đặt một báo cáo khả thi trước những người ra quyết định là một điều tốt; bạn không có cấu trúc hoặc hỗ trợ quản lý (hoặc ethos) để nói "Tôi cần bạn ký tên này nói rằng bạn hiểu rằng đây là một điều xấu và tôi không khuyến nghị điều đó và sẽ không chịu trách nhiệm về những ảnh hưởng của việc này quyết định tồi tệ "(giống như bạn có thể là một nhà cung cấp và họ là khách hàng), nhưng bạn vẫn có thể đưa ra nhiều điều trên giấy cho thấy bạn đang xem xét điều gì là lợi ích tốt nhất của công ty và tài sản của công ty.

Nếu họ đang bảo bạn thực hiện các quy trình và kích hoạt được lưu trữ - bạn có vấn đề lớn về quy trình kinh doanh.

Thách thức lớn nhất của bạn là khiến người dùng ở đây thay đổi cách họ nghĩ. Họ cần được cung cấp cho bạn vấn đề hoặc yêu cầu. Ví dụ, chúng ta cần dữ liệu di chuyển từ đây đến đây .

Bạn nên thực hiện giải pháp với ít rủi ro / lợi nhuận cao nhất và chính bạn là người có thể làm điều này theo cách giúp ngăn chặn các vấn đề phát triển trong tương lai.

Một số điều khiển dưới dạng đăng xuất hoặc yêu cầu của người dùng, sau đó đăng xuất khỏi sự phát triển được phân phối cũng sẽ giúp ích. Nếu người dùng phải chịu một số trách nhiệm / trách nhiệm cho những gì họ đang yêu cầu, họ có thể nghĩ về nó nhiều hơn một chút.

Bạn dường như ngụ ý sự lựa chọn của bạn là giữa việc thực hiện rủi ro của một yêu cầu kinh doanh hoặc không có gì cả. Nó hiếm khi có màu đen và trắng. Tôi có một thời gian khó tin rằng kế toán đang trực tiếp yêu cầu các thủ tục được lưu trữ, nhưng nếu có, bạn cần cung cấp cho họ ý nghĩa của chúng thay vì những gì họ yêu cầu. Tìm hiểu yêu cầu kinh doanh là gì, sau đó tìm ra cách ít rủi ro nhất để thực hiện nó.

Nếu nhà cung cấp của bạn không cung cấp các hook bạn cần thực hiện một cách an toàn các yêu cầu mà người dùng của bạn muốn, thì vấn đề đó thuộc về nhà cung cấp chứ không phải người dùng của bạn.

Về cơ bản, bạn đang phát triển phần mềm và như vậy bạn cần một phương pháp phát triển. Làm thế nào là thay đổi tài liệu? Thử nghiệm? Đã triển khai đến QA? Triển khai sản xuất? vv Tôi nghĩ rằng nếu bạn bắt đầu nghĩ ra một phương pháp và chi phí liên quan đến nó, họ sẽ bắt đầu hiểu. Có lẽ các chi phí là hợp lý và bạn chỉ cần thực hiện một thủ tục để chiếc xe không bao giờ tự bọc quanh một cột đèn.