Jak mogę informować o ryzyku zmiany oprogramowania dostawcy?

Mamy poważny problem, w którym pracuję, a jego nazwa to „personalizacja”. Mamy stary (10+ lat) system oprogramowania dla dostawców, który nasze działy IT i księgowości wcześniej lubiły dostosowywać. Gdzieś wzdłuż tego oprogramowania zaczęło się pojawiać wiele błędów. Następnie zostałem zatrudniony po dużej części dostosowania.

Niemal każdy problem, który znalazłem w systemie, jest bezpośrednim wynikiem dostosowania; wszystko, co zmieniamy, grozi zerwaniem krytycznego oprogramowania finansowego dla firmy. Jednak dział księgowości wciąż sugeruje zmiany (ponieważ zawsze mówiliśmy tak!) I wydaje się, że nie ma szacunku dla tego, jak znaczące mogą być zmiany.

Niektóre zmiany nie powodują problemów; formularze mogą być (i powinny być) dostosowane w oprogramowaniu dostawcy, możemy poruszać się po polach formularzy, usuwać je itp. Ale dla każdego takiego nieszkodliwego dostosowania sugerują również zmiany, takie jak procedury składowane i wyzwalacze do manipulowania danymi w bazie danych dla aplikacji dostawcy.

Niedawno (ledwo) sprawiłem, że przestali próbować importować klientów z jednego programu dostawcy do drugiego, ponieważ informacje były całkowicie niezgodne. Mój problem z tym, jak to zostało rozwiązane, polega na tym, że stwierdziłem, że system nie działa po stronie użytkownika; zadanie było bardziej skomplikowane, niż im się wydawało, więc się poddali. Niezależnie od tego, jak łatwe jest zadanie po stronie użytkownika, operacja, której chcieli, nie powinna była zostać wykonana.

Jak mogę komunikować, że zmiana sposobu działania tego systemu wiąże się z ryzykiem, szczególnie gdy zagrożona jest ważność danych? Jestem nowym (6-miesięcznym) zatrudnieniem i stało się to stanem rzeczy, ale ryzykuje to ważność naszych danych finansowych i naszych umów wsparcia - gdy wsparcie dostawcy usłyszy „X został dostosowany”, co daje im tyle powodów, że nie wesprzeć nas lub powiedzieć, że to nasza wina.

Ryzykiem / korzyścią związaną z dostosowywaniem systemów jest zapewnienie przewagi konkurencyjnej, która pozwoli Twojej firmie zaoferować coś innego niż inne firmy w Twojej przestrzeni.

Większe organizacje, z którymi współpracowałem, czerpią przewagę konkurencyjną z dostosowywania i dzięki temu ustawieniu robią rzeczy bardziej wydajnie, zapewniają więcej funkcji lub więcej pieniędzy.

Fakt, że komunikuję się w takich sytuacjach, polega na tym, że jest to kompromis. Wprowadzając te zmiany w systemie, organizacja rozwija własną wewnętrzną bazę wiedzy / wiedzę specjalistyczną na temat swoich systemów, z którą nie byliby w stanie łatwo sobie poradzić. Ta wewnętrzna baza wiedzy musi być lepiej utrzymywana i zorganizowana, aby zmiany te mogły być śledzone i zarządzane. Oznacza to również, że może to unieważnić umowy o wsparcie dla dostawców i inne aspekty, które zasoby IT wykorzystują w tym procesie.

Największe ryzyko, o którym mówię, to aktualizacje wersji oprogramowania dostawcy, gdy firma przyjmuje tę filozofię zarządzania danymi. Jest to jedno z najbardziej prawdopodobnych ryzyk, w których coś się zepsuje. Firma musi zrozumieć kompromisy, które są dokonywane, a wszyscy muszą być na bieżąco z procesem koniecznym do ich wsparcia.

W swojej kulturze możesz wprowadzić analogię lub filozofię, ale potrzebujesz osoby odpowiedzialnej za biznes, aby zdać sobie sprawę, że tworzą środowisko, które jest jeszcze bardziej zależne od wewnętrznych specjalistów biznesowych, którzy wprowadzają zmiany w tych systemach.

Dla analogii samochodu to nie mechanik musi wiedzieć, jakie zmiany wprowadza się w samochodzie, jego właściciel musi zrozumieć, że może to wymagać specjalnych mechaników, więcej pieniędzy lub utraty tej usługi przez pewien czas. Edukacja właściciela jest kluczem do tej rozmowy.

Komunikowanie się z mieszkańcami biur? Wybrałbym analogie.

Powiedz im, że wszystkie te zmiany zmieniają typowego 4-drzwiowego sedana w egzotyczny zagraniczny samochód. Za każdym razem, gdy wprowadzasz go do warsztatu mechanicznego, od dostrajania, przez zgniecione światło, po przegląd skrzyni biegów, będzie drożej. „Nie mamy części, tylko dealer ze specjalną wiedzą może tego dotknąć, próbowaliśmy, ale instrukcja obsługi jest w języku niemieckim”.

Jesteś mechanikiem odpowiedzialnym za jego utrzymanie. Baza danych jest silnikiem. Cały system to samochód. Księgowi jeżdżą samochodem. Słodki króliczek, za którym tęsknili księgowi, jest umlautką w imieniu nowego klienta. Słup świetlny, wokół którego owinęli swój samochód, jest krytycznym błędem, który został wprowadzony, gdy chcieli dodać kulę dyskotekową do samochodu.

Inni podali kilka dobrych przykładów użycia analogii i innego języka, aby odpowiedzieć na twoje główne pytanie, które brzmiało: „Jak mogę komunikować, że zmiana sposobu działania tego systemu wiąże się z ryzykiem, szczególnie gdy zagrożona jest ważność danych?”

Ale w oparciu o twój wyjaśniający komentarz na temat tego, w jaki sposób otrzymujesz zadanie, nie jestem pewien, czy jakakolwiek analogia pomoże ci w tej sytuacji - nie wydaje się, aby ludzie źle rozumieli, o co proszą, ale raczej że ich to nie obchodzi. Byłem tam - prawdopodobnie wszyscy już tam byliśmy - i w tych sytuacjach staram się dokładać wszelkich starań, aby mieć absolutną jasność co do problemów, zamiast zajmować się nimi w kategoriach przeznaczonych raczej do nauczania niż ostrzegania .

Skupić na tym, co można zrobić, co nie jest jednoosobowo zmienia umysły wszystkich, prosząc o dostosowań, które wprowadzone kontrakty integralności danych i wsparcia sprzedawca zagrożone, lecz przemawia bezpośrednio do CTO (i kolei CFO) i samopoczucia bardzo jasne co do bieżących problemów.

Konkretnie:

• Poproś swojego CTO lub CFO (lub kogokolwiek, kto go posiada), aby zobaczył umowę o świadczenie usług ze sprzedawcą, ponieważ (i powiedziałbym te słowa) jesteś proszony o wykonanie zadań, które potencjalnie naruszają umowę i chcesz wskazać to w raporcie wykonalności zadania. Mogą ci tego nie dać, ale powiedzenie tych słów często sprawia, że ​​ludzie na tych stanowiskach lepiej rozumieją, że jesteś poważny, a sytuacja jest potencjalnie poważna.

• Jeśli zrobić otrzymać kopię umowy, wtedy kiedy piszesz raport wykonalności zadania, zacytować bezpośrednio od niego, gdy istnieje wyraźne naruszenie.

• Jeśli nie dostaniesz kopii umowy, wyraźnie zaznacz swoje zastrzeżenia, w jaki sposób zmiana może postawić firmę w złej sytuacji w zakresie relacji z dostawcą.

• Jeśli Twoje obawy nie są problematyczne z powodu umowy z dostawcą, ale są „po prostu” problematyczne ze względu na kaskadowe skutki zmiany, opisz, co to oznacza: jeśli jest tak niechlujny, jak mówisz, prawdopodobnie masz tylko jeden lub dwa wypunktuj zanim będziesz mógł użyć linii „i przewróci się jak domek z kart”.

Krótko mówiąc, zrób co możesz, aby bardzo wyraźnie i zwięźle wskazać problem i jego skutki nawet o krok lub dwa w dół. To, że masz już okazję przedstawić raport wykonalności przed decydentami, jest dobrą rzeczą; nie masz wsparcia w zakresie struktury lub zarządzania (lub etosu), aby powiedzieć „Potrzebuję podpisu, mówiąc, że rozumiesz, że jest to zła rzecz i nie polecam tego i nie będę odpowiedzialny za skutki tego zła decyzja ”(jak gdybyś był sprzedawcą, a był klientem), ale wciąż możesz napisać na papierze wiele rzeczy, które pokazują, że zastanawiasz się nad tym, co leży w najlepszym interesie firmy i jej aktywów.

Jeśli nakazują ci wdrożenie procedur przechowywanych i wyzwalaczy - masz poważny problem z procesem biznesowym.

Twoim największym wyzwaniem jest zachęcenie użytkowników do zmiany sposobu myślenia. Muszą dostarczyć ci problem lub wymaganie. Na przykład potrzebujemy danych przenoszonych z miejsca na miejsce .

To Ty wdrażasz rozwiązanie o najmniejszym ryzyku / największym zysku, i to Ty możesz to zrobić w sposób, który pomoże zapobiec problemom rozwojowym w przyszłości.

Pomoże również kontrola w formie wylogowania użytkownika lub wymagań, a następnie wyrejestrowania dostarczonego oprogramowania. Jeśli użytkownik musi wziąć odpowiedzialność za to, o co prosi, może się nad tym zastanowić.

Wydaje się, że sugerujesz, że twój wybór jest pomiędzy ryzykownym wdrożeniem wymagań biznesowych lub wcale. Rzadko tak czarno-biały. Trudno mi uwierzyć, że księgowi bezpośrednio proszą o procedury składowane, ale jeśli tak, musisz dać im to, co mają na myśli, zamiast tego, o co proszą. Dowiedz się, jaki jest wymóg biznesowy, a następnie wymyśl najmniej ryzykowny sposób jego realizacji.

Jeśli twój dostawca nie zapewnia haków, których potrzebujesz, aby bezpiecznie wdrożyć wymagania, których oczekują Twoi użytkownicy, oznacza to, że problem leży po stronie dostawcy, a nie Twoich użytkowników.

Zasadniczo tworzysz oprogramowanie i jako taki potrzebujesz metodologii programowania. Jak dokumentuje się zmiany? Przetestowany? Wdrożyłeś do kontroli jakości? Wdrożony do produkcji? itp. Myślę, że jeśli zaczniesz wymyślać metodologię i związane z nią koszty, zaczną ją rozumieć. Być może koszty są dobrze uzasadnione i wystarczy wdrożyć procedurę, aby samochód nigdy nie owijał się wokół słupa światła.