Zakazanie lub kontrolowanie „Hidden IT…” Kto powinien pisać i utrzymywać aplikacje ad-hoc?

61

Większe firmy zwykle mają problem z tym, że nie jest możliwe napisanie wszystkich programów, które chcą pracownicy (aby zaoszczędzić czas i zoptymalizować procesy) z powodu braku personelu i pieniędzy.

Następnie ukryte programy będą tworzone przez niektóre osoby mające (przynajmniej trochę) doświadczenie w kodowaniu (lub przez tanich studentów / stażystów ...). W niektórych okolicznościach aplikacje te nabierają znaczenia i rozprzestrzeniają się od jednego użytkownika do całego działu.

Jest jeszcze punkt krytyczny: kto będzie utrzymywał aplikację, dodawał nowe funkcje, ...? Ta aplikacja jest krytyczna. To jest potrzebne. Ale stażysta opuścił firmę. Nikt nie wie jak to działa. Masz tylko kilka źródeł i jakąś dokumentację.

Czy ma sens próba kontrolowania lub zakazywania tworzenia aplikacji wykonywanych ad hoc poza działem IT (z wyjątkiem drobnych rzeczy, takich jak makra Excel)?

matcauthon
źródło
3
Zależy od środowiska. Możesz skonfigurować system operacyjny w miejscu pracy, w którym tylko administratorzy mogą instalować nowe oprogramowanie, możesz zabronić dostępu do odpowiednich zasobów na serwerze (bazy danych, system plików), do których to oprogramowanie musiałoby uzyskać dostęp. Możesz to zrobić w sposób techniczny, aby było to niemożliwe, można uniknąć podawania haseł, adresów IP i podobnych informacji lub po prostu sprawić, że będzie to polityka firmy i zwolnić każdego, kto nie zastosuje się do nich. Widziałem mniej więcej wszystko.
thorsten müller,
40
Ale jeśli te „ukryte programy” są rzeczywiście krytyczne i nie mogą być wdrożone przez prawdziwy dział IT, co zyskujesz, zabraniając ich? W końcu są krytyczne , więc po prostu nie możesz sobie pozwolić na ich brak. Może zrestrukturyzujesz swój dział IT? Lub zmienić priorytety? Wydaje mi się zrozumiałe, że zręczni ludzie wykonują czynności poza normalnym obiegiem pracy, jeśli wspomniany obieg pracy nie odpowiada ...
Andres F.,
13
@ thorstenmüller W tym momencie ostatecznie kończy się implementacja ukrytych programów w formułach Excela, które są o rząd wielkości gorsze w utrzymaniu niż nawet Excel VBA. Ponieważ tworzenie arkuszy kalkulacyjnych Excel jest umiejętnością, której potrzebuje wielu pracowników biurowych, nie można całkowicie zablokować tego, tak jak można by stworzyć bardziej odpowiednią platformę programistyczną.
Dan Neely,
5
@ thorstenmüller Chodzi mi o to, że bez względu na to, co próbujesz i robisz, kiedy wybory są dokonywane kanałami, poczekaj kilka dni (jeśli nie miesiące z powodu burrocrazy), poświęć kilka godzin na zrobienie tego ręcznie, lub wykonaj końcowe obchodzenie polityki, którą ludzie idą zrobić to drugie. Zakładanie, że możesz to zatrzymać, jest złudzeniem. Najlepsze, co możesz mieć nadzieję, to mieć skuteczny proces znalezienia i przyjęcia tych narzędzi po fakcie.
Dan Neely,
16
Co jest złego w tym, że „zwykli ludzie” automatyzują swoje procesy biznesowe? Tak długo, jak faktycznie oszczędza im czas, co prawdopodobnie jest, uważam to za dobrą rzecz . Jeśli konkretne „niechlujne” „narzędzie ad-hoc” do automatyzacji stanie się silnie uzależnione, warto poprosić programistów o napisanie możliwej do utrzymania wersji. W najgorszym przypadku muszą zacząć robić rzeczy ręcznie, gdy zmieniają się wymagania, ale przynajmniej zaoszczędzili już dużo czasu!
Filip

Odpowiedzi:

79

Pracowałem dla firmy, w której każda aplikacja, którą im daliśmy, prowadziła do pytania: czy możemy wyeksportować te dane do Excela?

Po chwili zdecydowałem, że muszę wiedzieć, dlaczego mieli obsesję na punkcie eksportu Excela. Okazało się, że wiele działów miało jedną osobę, która była ekspertem w programie Excel i mogła w krótkim czasie napisać przydatną aplikację do analizy danych. Te aplikacje rozprzestrzeniłyby się po całym dziale jak pożar, a my, technicy, nie mieliśmy pojęcia, że ​​w ogóle istnieją.

Dlaczego nie przyszli do nas pierwszy? Ponieważ istniała opinia, że ​​zespół techniczny miał zbyt wiele do zrobienia, a gdyby o to poprosili, mogliby (jeśli mieliby szczęście) ustawić ją w kolejce sześć miesięcy później.

To nie był niesprawiedliwy zarzut i nigdy nie poprosili nas o wsparcie ich aplikacji Excel, więc nikt tak naprawdę nie pomyślał, że to problem. Kiedy ci programiści programu Excel odeszli, zawsze udało im się znaleźć kogoś, kto by go podniósł.

Można argumentować, że oznaczało to, że niepoprawnie ustalaliśmy priorytety, że nie wykonano ważnej pracy. Twierdziłbym jednak, że zwolniło to lepiej zarabiających programistów do trudniejszej pracy. Co może boleć?

Teraz byłoby zabronić oprogramowanie aktualizuje bazę danych zapisywane poza deweloperami. I odmówiłbym wspierania aplikacji napisanych poza zespołem programistów. Ale nie próbowałbym zabronić, aby całe oprogramowanie zostało napisane przez samą firmę, i chętnie napisałbym eksport danych, aby im to umożliwić (o ile nie ujawnia to danych, których nie powinni widzieć, oczywiście ).

pdr
źródło
36
Pracowałem w podobnym środowisku, a reakcja naszego działu na te „aplikacje” zawsze była frustrująca. Wiele moich uczelni w dziale IT było z jakiegoś powodu zagrożonych tymi aplikacjami, ale uważałem je za wspaniałe. Pozwoliło to użytkownikom departamentów zrealizować to, czego naprawdę POTRZEBUJĄ, a kiedy ta pojedyncza baza danych Access nie działała dla nich, mogliby nam to po prostu przekazać, a my zbudowalibyśmy „prawdziwe” rozwiązanie SQL obsługujące tę samą funkcjonalność. Znowu zabiłbym za taki projekt. Wszystkie wymagania były znane pierwszego dnia, kiedy zaczęliśmy.
Graham,
8
+1 Dobrze określone. Wzmocnienie pozycji użytkowników naszego oprogramowania powinno być jednym z naszych najwyższych priorytetów.
Steven Evers,
W większości musiałbym się zgodzić z odpowiedzią. Ale sedno jest takie, że źle napisane zapytania mogą doprowadzić do awarii serwera bazy danych; nawet jeśli jest napisany w Excelu lub Access. Raz musi zrównoważyć zobowiązania SLA IT z potrzebami firmy.
Steve,
@Stephen: Tak. I dlatego lepiej dać użytkownikom możliwość robienia własnych rzeczy, niż pozwolić im na dane produkcyjne. To, czy będzie to tylko do odczytu, codzienna kopia danych, eksport Excela, czy DSL, zależy w dużej mierze od twoich potrzeb bezpieczeństwa / SLA i ich danych.
pdr
1
@mattnz: Odradzam zdecydowanie. Daje to ludziom sposób, aby zespół techników nadał priorytet swoim problemom w stosunku do reszty firmy, po prostu łącząc coś razem i mówiąc „Czy widzisz, dlaczego to nie działa?” Czy znasz programistę, który mógłby się oprzeć takiemu wyzwaniu?
pdr
50

Myślę, że ludziom brakuje tutaj ogólnego punktu:

Jeśli nie podoba ci się cały rozwój niestandardowy, który jest w toku, zakazanie mu rozwiązania niewłaściwego problemu - powinieneś zamiast tego zapytać, dlaczego obchodzą IT, a nie tylko powiedzieć im, że nie jest to dozwolone. Pamiętaj, że istniejesz (IT), aby pomóc im lepiej wykonywać swoją pracę i że ludzie nie używają oprogramowania, ponieważ jest fajne, schludne lub nowe, używają go, ponieważ rozwiązuje problem, który mają.

Dlaczego te aplikacje są tworzone w pierwszej kolejności?

We wszystkich przypadkach, które widziałem, istnieje wspólny powód:

Grupy biznesowe traktują priorytetowo własne potrzeby bardziej niż te same potrzeby są traktowane priorytetowo w kontekście całej firmy

Marketing jest odpowiedzialny tylko za marketing, więc inicjatywy, które przynoszą korzyści ich celom, wydają się dla nich kluczowe, a jednocześnie są uważane za kłopotliwe dla innych grup i mają tendencję do priorytetowego traktowania niżej, jeśli chodzi o ograniczone zasoby, takie jak IT. Priorytetyzacja pojawia się tylko wtedy, gdy chcą skorzystać z udostępnionego zasobu - jeśli utrzymają projekt całkowicie w swoim własnym dziale, tylko kierownik działu musi dbać o budżet i harmonogram.

Nie ma powodu, dla którego zabraniałbym tego rodzaju rozwoju, w granicach rozsądku - łagodzi on ograniczenia dotyczące współdzielonych zasobów (głównie IT) i pozwala każdej grupie na samodzielne rozwiązywanie własnych problemów (ponieważ osoby zaznajomione z zaawansowanym programem Excel są dość powszechne, ponieważ jest to powszechny problem, większość działów ma co najmniej jeden).

Jednak nie można oczekiwać, że rozwiąże on jakiekolwiek problemy wynikające z tych aplikacji lub wesprze je po odejściu pierwotnego programisty z firmy. Jak wspomniano w innym poście, nie powstrzymuje to dużego szefa przed żądaniem, abyś go wspierał, ale jeśli wyczuwasz rodzaje niestandardowych aplikacji lub procesów, możesz poczuć, kiedy coś staje się krytyczne, a ty być może trzeba będzie zaangażować się, aby wprowadzić go „wewnętrznie”. Ponadto, jeśli coś łączy się i modyfikuje systemy podlegające kontroli IT, należy zaangażować IT, choćby po to, aby zapewnić bezpieczeństwo i integralność ich systemów centralnych - jeśli jednak jest to coś ograniczonego do pulpitu użytkownika, po co czuć potrzebę zabronić?

Należy jednak pamiętać: każda aplikacja niestandardowa opracowana poza IT odpowiada potrzebie, która nie jest zaspokajana przez IT . Może być dobry powód, dla którego nie zostały spełnione - brak priorytetu w firmie, bardzo wyspecjalizowany problem, nie tak dobry jak inne opcje, niestandardowy język, którego nie znają informatycy itp. - i brak zaangażowania IT może być uzasadnione, ale te rozwiązania zostały stworzone, ponieważ niektóre działy miały potrzeby, których dział IT nie mógł (lub nie chciałby) zaspokoić.

Spróbuj pomóc im rozwiązać ich problemy, a jeśli nie masz czasu ani zasobów, pozwól im rozwiązać je samodzielnie. Ustanowienie jakiegoś języka o silnej krzywej uczenia się, którego jedynym celem jest powstrzymanie ludzi od prowadzenia działalności, służy jedynie wzmocnieniu elitarnego nastawienia większości użytkowników biznesowych postrzegających IT, a ostatecznie takie elitarne podejście prowadzi tylko do więcej tego samego problemu, ponieważ użytkownicy boją się podejść do IT i są przekonani, że IT nie rozumie ich potrzeb lub pragnień. Otwórz relację - zrozumienie, czego potrzebują, to jedyny sposób, aby powstrzymać ich przed obejściem ciebie.

SqlRyan
źródło
2
+1 miejsce na. Nie widzę tutaj nikogo, kto wspominałby o tym, co stanowi ogromny problem z praktykami, które widziałem w wielu firmach. To, co działa w krótkim lub krótkim czasie dla jednej lub dwóch osób, szybko zamienia się w olbrzymi bałagan oprogramowania 30 małych aplikacji, które rozwinęły się przez lata, a połowa z nich działa, a utrzymanie ich jest dziesięciokrotnie wyższe niż koszt, gdyby dział IT zatrudnił ludzi do zrób je wszystkie, aby były spójne i miały centralną bazę własności IT.
Jimmy Hoffa
4
Jako osoba pracująca jako programista „black ops” mogę powiedzieć, że często dział IT nie ma umiejętności rozumienia potrzeb konkretnego działu technicznego. Niektóre z naszych najbardziej krytycznych i innowacyjnych programów powstały jako programy „black ops”. IT nie jest miejscem, w którym innowacja jest nagradzana, innowacje i eksperymenty często oznaczają wiele nieudanych projektów dla każdego udanego projektu. Po dobrze przyjętym programie „black ops” zazwyczaj jest on przekazywany do działu IT w celu utrzymania.
Bill
+1 Moje myśli dokładnie, ale sformułowane znacznie lepiej.
Phil
16

Należy również wziąć pod uwagę przypadek firm, w których dział IT składa się z niekompetentnych osób, podczas gdy ukryta aplikacja zostałaby stworzona przez zręcznego programistę, który nie pracuje w firmie. Z mojego doświadczenia wynika, że ​​przypadki te są niezwykle częste.

Wyobraź sobie, że masz podwójny profil programisty i księgowego. Jesteś zatrudniony jako księgowy, ponieważ była to okazja na znalezienie dobrze płatnej pracy. Szybko widzisz, że twoi koledzy (a teraz ty) spędzają godziny na powtarzaniu rzeczy, które program może zrobić w kilka sekund.

Poświęcasz kilka wieczorów na napisanie aplikacji, która wykona całą pracę. Pokazujesz to na swoim laptopie swoim kolegom, a oni uważają to za bardzo przydatne. Chcesz zainstalować go na komputerach firmowych, ale powinieneś mieć zgodę działu IT. Prosisz o to, ale odrzucają, ponieważ nie będą obsługiwać Twojej aplikacji.

Czy to nie brzmi głupio?

Poza tym szczególnym przypadkiem problem ze wsparciem nie różni się zbytnio od tego, że wiele firm napotyka całe  oprogramowanie, nawet jedno napisane w dziale IT: jeśli dział IT nie egzekwuje najlepszych praktyk, kod będzie źle / nieudokumentowany, napisane przez niedoświadczonych ludzi, którzy nie dbają o utrzymanie i którzy opuścili lata temu.

Podsumowując, głównym pytaniem jest rentowność . Jeśli ty, dział IT, zostaniesz poproszony o utrzymanie aplikacji opracowanej przez urzędnika, który nie rozumie najbardziej podstawowych zasad tworzenia oprogramowania, nie ma znaczenia, jak przyjemne jest to zadanie, nadal musisz to zrobić, jeśli przynosi dużo pieniędzy dla firmy . Lub przepisujesz go od zera, jeśli jest to najtańszy sposób na załatwienie sprawy.

Arseni Mourzenko
źródło
2
„Z mojego doświadczenia wynika, że ​​te przypadki są niezwykle częste”. - Więc twoja firma wykonuje niesamowitą robotę, zatrudniając świetnych programistów na stanowiskach nieprogramistycznych, a następnie słabych programistów na stanowiskach programistycznych? Myślę, że bardziej prawdopodobne jest, że ktoś, kto nie rozumie praktyk i systemów leżących u podstaw, MYŚLĄ, że piszą lepsze oprogramowanie. Tylko moje 2 centy.
Ominus
2
@Ominus: jeśli jest wolne miejsce na prawnika, firma będzie szukać prawnika; jeśli kandydat jest również wykwalifikowanym programistą, ankieter może nawet tego nie wiedzieć. Więc nie, firma nie „zatrudnia świetnych programistów na stanowiskach nieprogramowych”: zatrudniają wykwalifikowaną osobę do pracy, nie mając szczególnej świadomości, że ta osoba jest również świetnym programistą.
Arseni Mourzenko
@Ominus: pamiętaj, że kiedy jesteś zatrudniony na przykład jako urzędnik, nie mówisz podczas wywiadu, że jesteś świetnym programistą. Dla wielu osób bez doświadczenia technicznego programista = haker = koleś, który spędza czas na krakowaniu komputerów firmowych = wiele problemów.
Arseni Mourzenko
1
@Ominus - Firma nie musi być zła w zatrudnianiu pracowników IT, którzy mają niekompetentny dział IT. Mogą pojawić się złe działy IT, ponieważ IT jest przez kogoś uważane za „ogólne” i zmniejszone, o ile to możliwe. To rozciąga ich poza ich rzeczywiste możliwości i stają się niekompetentni jako organizacja - ciągłe przełączanie się między zadaniami, ciągły tryb paniki, brak komunikacji z kimkolwiek, nie dotrzymywanie obietnic.
Michael Kohne,
2
@Ominus: Bardziej prawdopodobne jest to, że firma wykonuje równie dobrą pracę, zatrudniając oba rodzaje ról, ale wtedy grupa IT jest obciążona beurokracją, sprzecznymi priorytetami i systemem PM, który nie wykonuje dobrze pracy, dusząc innowacja zamiast ją pielęgnować. Technicy w zawodach niezwiązanych z IT, gdy tylko zauważą swoje umiejętności, mogą faktycznie skupić się na zadaniu, ponieważ tylko ich kierownik kontroluje ich czas. Osoby wykonujące rzeczywistą pracę mają automatyczny wkład w innowacje, podczas gdy grupa IT nie ma takiego samego spojrzenia na potrzeby.
SqlRyan
6

Nie możesz tego w pełni kontrolować ...

Powiedziałbym, że nigdy nie możesz W PEŁNI kontrolować tego, ponieważ pracownicy zawsze będą mieli środki do tworzenia fałszywego kodu i rozpowszechniania go w alternatywny sposób. Nie ma więc zbyt wiele pożytku z obsesji na punkcie tego, gdy opracujesz i egzekwujesz kilka podstawowych zasad i procesów oraz skonfigurujesz kilka narzędzi.

Chodzi o to, aby uczynić to tak atrakcyjnym, jak to możliwe, aby ludzie przestrzegali tych zasad i korzystali z tych narzędzi, a nie uniemożliwiali robienie nowych rzeczy, że nic nie produkują.

Ale możesz stworzyć środowisko przyjazne dla kodu

Robi to wiele firm, często bardzo dużych. Dobrym przykładem jest Google, dla którego przedstawiciele stwierdzili, że używają jednego SCM dla całej firmy, aby każdy mógł monitorować i patrzeć na kod innych użytkowników.

Polecam wykonać następujące czynności:

  • dać publiczny dostęp do niektórych obszarów twojego SCM,
  • ułatwić dostęp do serwerów ciągłej integracji i ciągłej kontroli,
  • zachęcać ludzi do tworzenia miejsc pracy dla swoich narzędzi.

Problemem jest zatem rozprzestrzenianie się technologii. Oczywiście niektórzy wolą używać X zamiast Y i wtedy trudniej jest dopasować je do architektury. Jednak nie jest to niemożliwe, a jeśli chcą, aby ich kod został utrzymany, prawdopodobnie dostaną dodatkową milę, jeśli, cóż, to tylko jedna mila.

Możesz również zająć bardziej arbitralne stanowisko i zdecydować, że dozwolony jest tylko język L i Stack S, ale wtedy dostaniesz jakieś nieuczciwe rzeczy tu i tam, więc polecam je trochę rozszerzyć. Niektóre systemy CI dokonują cudów za pomocą kilku wtyczek, jeśli Twoi pracownicy są gotowi napisać trochę kodu kleju lub skryptów konfiguracyjnych, aby dopasować je.

Daj drużynom trochę swobody

Ważne jest, aby dać zespołom trochę swobody w zachowaniu kaprysu i rozpocząć nowe małe projekty z eksperymentalnymi rzeczami. Trzyma je na palcach, a ty, podobnie jak zmuszasz do rozważenia tych technologii, a raczej do pozostania w stosie na zawsze, dopóki nie spowoduje to problemów.

Upewnij się więc, że mają możliwość zainstalowania własnych systemów do testowania swoich domowych projektów. Ale upewnij się, że mają w zwyczaju rozmawiać o tym z IT.

Porozmawiaj z IT, zaangażuj ich

O wiele lepiej, jeśli twoi pracownicy rozwiną odruch strzelania do wiadomości e-mail do IT i zapytają ich, czy mogą coś dla nich skonfigurować i pomieścić. Przez większość czasu będą odrzucani, ale przynajmniej istnieje pojęcie kontroli i kto powinien być odpowiedzialny, i daje IT pewien wgląd w wymagania różnych zespołów.

Gdy projekty osiągną masę krytyczną, możesz poprosić ponownie, a one ponownie rozważą. Komunikacja jest kluczowa i musisz mieć zespoły programistów, konsultantów, personelu wsparcia IT lub kogokolwiek, kto zajmuje się kodem do współpracy. Żaden z nich nie chce bezpańskich programów, więc leży to w interesie wszystkich. O wiele łatwiej jest egzekwować reguły, jeśli same je wykonują.

Haylem
źródło
3

Nie można zatrzymać tych „ukrytych” aplikacji, ponieważ ludzie zmuszają je do rozwiązywania rzeczywistych problemów biznesowych. Wszystko, co możesz zrobić, to pomóc im to zrobić „we właściwy” sposób. Mówiąc „w prawo” mam na myśli tworzenie aplikacji, aby aplikacje mogły być utrzymywane po odejściu osoby, która je uruchomiła. Zalecam używanie języka sugerowanego w Up lub Out : Potrzebuję, abyś szczegółowo opisał ten proces, aby każdy Yahoo mógł go zrozumieć po roku od odejścia. Pomoc w konfigurowaniu kontroli wersji (i pokazaniu, jak z niej korzystać), wiki (do przechowywania nieformalnych notatek o tym, jak praca faktycznie się wykonuje) i prosty system śledzenia błędów. Jeśli chcesz sprawić, by wszystko było naprawdę gładkie, ustaw ciągłą integrację na zapasowym serwerze (jeśli taki masz).

Zobaczysz ogromne pragnienie integracji Excela (a przynajmniej importu / eksportu), ponieważ wszystkie szkoły biznesu uczą teraz Excela i jest to główne narzędzie używane na wielu kursach biznesowych.

Tangurena
źródło
3

Sarbanes-Oxley i podobne ustawodawstwo poza USA, w połączeniu z przepisami dotyczącymi prywatności oraz wewnętrznie narzuconym przez siebie procesem i polityką prywatności i bezpieczeństwa to „młotek”, który może i często jest wykorzystywany do ograniczania zjawiska IT-shadow.

Gdy tylko informacje umożliwiające identyfikację klienta lub pracownika (lub dowolne dane, których nie chcesz wydostać) zaczną krążyć w tych arkuszach kalkulacyjnych, czeka Cię wypadek.

Podobnie, gdy tylko jeden z tych projektów informatycznych skunkworks weźmie arkusz kalkulacyjny Excel i użyje go jako danych za zewnętrzną aplikacją internetową, która została zhakowana, Twój CIO i CEO szturmują biuro każdego, kto stworzył tę aplikację nadchodzi weekend, aby wyjaśnić konsekwencje.

Następnie pojawia się problem polegający na tym, że kiedy spojrzymy na te wysiłki pomnożone przez setki (lub tysiące) działów w przedsiębiorstwie z listy Fortune 500, wkrótce okaże się, że nasze przedsiębiorstwo ma ponad 100 „głównych” baz danych klientów. Twoi klienci zaczynają narzekać, że zaktualizowali swoje dane kontaktowe w jednym miejscu, ale nadal są nieaktualne w 10 innych lub że nawet nie wiesz, jak wiele robisz z dużymi partnerami, ponieważ informacje są rozłożone na 10 cieni Bazy danych IT.

Wszystko to powoduje uciążliwe procesy zgodności i audytu, które nie są zabawne dla nikogo, ale są twardymi faktami z życia IT w środowisku przedsiębiorstwa.

Dobrą strategią jest przeanalizowanie wszystkich działów, które to robią, i uzasadnienie przeniesienia inwestycji w cień IT do IT, co uzasadnia argument, że IT może osiągnąć ekonomię skali i wykonać tę pracę bardziej efektywnie niż obecnie rozproszony model skunkworks ad hoc. Może to być trudne do sprzedania w środowisku, w którym ograniczenia budżetu IT i szybkość dostarczania spowodowały przede wszystkim skunkworks, ale w połączeniu z ryzykiem audytu / powiernictwa może dać dobry wynik dwa do dwóch.

Pat James
źródło
2

Decyzja o napisaniu nowego wniosku często opiera się na analizie kosztów i korzyści wniosku; a także ogólną wartość dla firmy. Wszystko to przy uwzględnieniu wielu innych czynników, takich jak dostępne zasoby IT, zakres zapytania, cele biznesowe i kierunek, żeby wymienić tylko kilka. Często odrzucane jest żądanie konkretnego działu, ponieważ kierownik / dyrektor działu nie wykazał rozsądnego zwrotu z inwestycji lub po prostu nie przestrzega ustalonego procesu.

Niezależnie od powodu „dział IT” często jest kozłem ofiarnym, nawet jeśli decyzja była poza ich kontrolą. Dlatego nawet jeśli odrzucenie wniosku może nie odzwierciedlać źle działu IT, postrzeganie jest często zupełnie inne.

Mimo to znajdziesz fałszywe aplikacje w prawie każdej organizacji biznesowej na świecie. Niektóre dobrze napisane, a inne dobrze, zawierają kod, który nigdy nie powinien ujrzeć światła dziennego.

Chociaż powinniśmy robić wszystko, co w naszej mocy, aby zaspokoić potrzeby naszych wewnętrznych klientów, są chwile, których po prostu nie możemy. Kiedy tak się stanie, będą szukać gdzie indziej, aby rozwiązać swój problem.

Jeśli grupa IT jest aktywnie zaangażowana w projekt, możemy wymagać przestrzegania naszych standardów, pomóc konsultantowi w przestrzeganiu wewnętrznych wytycznych dotyczących kodowania oraz zrozumieć interakcje aplikacji z naszymi systemami (wymagania dotyczące bazy danych, sieci, zapory ogniowej itp.). Bez tego zaangażowania zostaniemy przyłapani i spędzimy dużo czasu próbując dowiedzieć się, dlaczego nasze systemy produkcyjne nie spełniają warunków SLA.

Niezależnie od tego, czy dział IT akceptuje je i wspiera, czy nie, mogą i będą miały bezpośredni wpływ pod względem wsparcia, zobowiązań OLA i SLA, na podstawie których ocenia się każdy dział IT.

Steve
źródło
1

Są one zabronione w naszej firmie z następujących powodów:

  • Makra Excel chronione hasłem, w których jedyna osoba znająca hasło opuściła firmę,
  • Odpowiedzialność za nieprawidłowe raporty napisane przez niedoświadczone osoby, ponieważ to IT ”
  • Prośba o zmodyfikowanie raportu, o którym nigdy wcześniej nie słyszeliśmy ani nie słyszeliśmy.

Rozumiem, że może to być frustrujące dla użytkowników, gdy dział IT jest zajęty i mogą mieć skłonność do „po prostu robienia tego sami”. Ale IT nie może być pociągnięte do odpowiedzialności za rzeczy, o których nie wie, że w ogóle istnieją, a jeśli nikt nie jest odpowiedzialny za całość IT, to przed nami wielkie problemy.

Paul T. Davies
źródło
5
Z tego co rozumiem, IT ma wspierać biznes; czy nie ma celu, aby dział IT pomagał ludziom w wykonywaniu pracy? Jak mogą dobrze wykonywać swoją pracę, jeśli zabraniasz im tworzenia narzędzi, których potrzebują? Nie ma nic złego w powiedzeniu: „Nie pociągaj nas do odpowiedzialności za ten nieprawidłowy raport - stworzył go ktoś z działu sprzedaży”.
Phil,
@Phil - Zgoda. Dział informatyczny ma na celu pomóc firmie w prowadzeniu działalności, a nie pełnić samodzielnie żadnej funkcji - nie istniałby, gdyby nie umożliwił firmie lepszego wykonywania pracy, a wszystko, co osiąga, powinno być postrzegane przez pryzmat tego, w jaki sposób biznes działa lepiej dzięki ich wysiłkom. Każdy proces utworzony poza IT odpowiada potrzebie, której IT nie spełnia, a zakazanie im cofa się bardziej niepewnością. Nie można oczekiwać, że będziesz wspierać procesy, których nie opracowałeś, a ja stanowczo, ale odmowa uznania, że ​​te „nieuczciwe” rozwiązania odpowiadają rzeczywistym potrzebom, jest po prostu uparta.
SqlRyan
1
Muszę dodać, że podjęto działania w celu rozszerzenia działu IT w celu spełnienia tych potrzeb.
Paul T Davies,
Podczas gdy IT wspiera biznes, często biznes nie wspiera IT. Firmy często nie biorą pod uwagę czasu, jaki zajęłoby IT przejęcie lub doradztwo w zakresie złożonych arkuszy kalkulacyjnych lub aplikacji opracowanych przez użytkowników końcowych. Efektem netto jest niedostateczny dział IT. I wszyscy wiemy, jak to działa.
Mike Sherrill „Cat Recall”
1

Jeśli występuje tutaj problem, dotyczy to działu IT.

Nie ma nic złego w pozwalaniu osobom o specjalistycznej wiedzy biznesowej / domenowej na manipulowanie i przetwarzanie własnych danych.

Dział IT musi to potwierdzić i wesprzeć. Zapewniając interfejsy wielokrotnego użytku, dostarczając dane w wygodnych formatach, takich jak EXCEL lub Access DB, oraz zapewniając elastyczne narzędzia (COGNOS, Raporty Jaspera itp.).

Dział IT musi również przemyśleć swoje priorytety - ma służyć biznesowi, nie wdrażać najnowszej metodologii lub instalować najseksowniejszy sprzęt.

James Anderson
źródło
1

Frustracja wielu firm lub działów w firmach polega na tym, że ich działy IT przeszkadzają im w wykonywaniu pracy lub wykonywaniu nowych zadań. To powoduje, że działy, które wydają się być powstrzymywane przez zasady IT, próbują rozwiązać własne problemy. Komunikacja jest kluczem. Jeśli działy pracują nad IT, to tak naprawdę masz problem z IT. IT nie może być postrzegane jako wróg. Firmy, a zwłaszcza działy IT, muszą zdać sobie sprawę, że muszą ze sobą współpracować zamiast ze sobą. Jeśli departamenty komunikują się ze swoimi pracownikami IT (zwłaszcza tymi, którzy powinni mieć nadzór) i mówią im o swoich potrzebach oraz o tym, jak pracują nad rozwiązaniem własnych problemów, Dział IT będzie miał przynajmniej możliwość pomocy w rozwiązywaniu problemów, zamiast dowiedzieć się, kiedy nastąpi kryzys. Informuj na bieżąco.

Nathan Pilling
źródło
1

Prawie nie ma potrzeby używania tych specjalnych narzędzi, czy to aplikacji, czy arkuszy kalkulacyjnych. Dział IT ma dwie możliwości. Mogą to być czynniki włączające lub wyłączające. Z mojego doświadczenia wynika, że ​​osoby niepełnosprawne przegrywają, ponieważ stają na przeszkodzie uzasadnionym potrzebom biznesowym i stają się wspólnym wrogiem. Z drugiej strony czynniki wspomagające rzeczywiście pomagają przedsiębiorstwom.

Nie oznacza to, że rozwój finansowany przez departament powinien mieć swobodę. Należy egzekwować niektóre wymagania, takie jak:

  • Cały kod musi być regularnie przypisywany do systemu kontroli wersji obsługiwanego przez dział IT. Aby to umożliwić, dział IT powinien swobodnie tworzyć konta i katalogi. IT może nawet chcieć przekazać jakieś instrukcje.
  • Wszystko, co wiąże się z PII (dane osobowe), uwierzytelnianiem, autoryzacją, kryptografią, danymi chronionymi przez prawo lub danymi, które firma uważa za kluczowe, musi obejmować i musi zostać zatwierdzone przez konsultanta z działu IT. IT / konsultant powinien zapewnić pomoc, biblioteki itp., Aby odpowiednio chronić firmę, jednocześnie umożliwiając tworzenie aplikacji.
  • Podstawowe bazy danych powinny być chronione. W zależności od bazy danych dostęp do odczytu powinien być stosunkowo łatwy do uzyskania, a dostęp do zapisu trudniejszy. IT może potrzebować zapewnić konta, logowanie lub audyt.

Włączanie ma wiele zalet.

  • IT uczy się więcej o zaspokajaniu potrzeb swoich klientów. Prowadzi to do lepszego ustalania priorytetów i udostępniania.
  • IT jest postrzegane raczej jako przyjaciel i korzyść niż problem.
  • Rzeczywiste potrzeby biznesowe są spełnione.
  • Dane biznesowe są odpowiednio chronione, ponieważ zaangażowano IT, co zapobiega potrzebie tylnych drzwi.
  • Narzędzia oddziału nie są tracone z powodu obrotu i w razie potrzeby można je łatwiej przenieść do działu IT.
walrii
źródło
0

Nie mogłem się powstrzymać od utożsamienia się z tobą. Problem, który opisujesz, wydaje się być uniwersalny, obejmujący kultury, języki i kontynenty.

Rzeczy, które możesz zrobić:

  • Ogranicz tworzenie kont bazy danych , prosząc o zgodę przełożonego. Zmuszenie ich do używania lokalnego komputera jako serwera bazy danych lub pisanie aplikacji jako samodzielnych znacznie zmniejsza jego użyteczność.

  • Spraw, aby wszyscy stażyści w karierach związanych z IT byli zatrudniani wyłącznie przez IT .

  • Ograniczanie za pomocą zasad systemu operacyjnego instalacji oprogramowania . Każda instalacja oprogramowania musi być prowadzona za pośrednictwem działu pomocy IT, wymagając zgody przełożonego. W ten sposób instalacja czegoś takiego jak MS Access, PHP, Visual Basic itp. Będzie trudniejsza do przejścia niezauważona.

  • Należy wydać zasadę, zgodnie z którą każdy nowy program, aby uzyskać wsparcie, musi być napisany w języku Java, C #, C ++ lub innym języku wymagającym intensywnej nauki . W ten sposób redukujesz wszechświat ludzi z „pewną wiedzą na temat programowania”, aby się bawić.

  • Te wymagania ludzie muszą spojrzeć na „rozwiązań Excel” wokół firmy, ponieważ jest to odzwierciedlenia potrzeb informatycznych korporacji.

  • Wdrożenie hurtowni danych oraz przyjaznego dla użytkownika narzędzia do eksploracji i raportowania danych . W ten sposób zmniejszasz potrzebę tworzenia niestandardowych, napisanych przez małe aplikacje aplikacji wewnętrznych.

Ale: nic, co zrobisz, nie przebije połączenia telefonicznego od Wielkiego Szefa , dzwoniąc do IT Managera i prosząc go o wsparcie aplikacji stworzonej przez stażystę.

Tulains Córdova
źródło
o punkcie 1, samodzielne aplikacje mogą być bardzo pomocne w przetwarzaniu danych nawet bez DB, o punkcie 4 stroma krzywa uczenia się nigdy nie powstrzymuje kogoś przed pisaniem rzeczy, gdy są u ich podstawy, czego wynikiem będzie jeszcze gorzej wsparcie, a nawet wieczór mówi „meh Nie potrzebuję obsługiwanej aplikacji”
maniak ratchet
Punkt 3 dotyczący ograniczeń systemu operacyjnego nie działa. Wiele firm już przeszło na model „zabierz ze sobą własnego laptopa”.
Sułtan
5
Zgadzam się z punktem 4 (należy pamiętać, że narzędzia niestandardowe mogą odzwierciedlać brak reakcji ze strony IT), ale nie z resztą. Środki ograniczające cuchną biurokracją. Z mojego doświadczenia wynika, że ​​efektem końcowym są rzeczy, których nie można zrobić , a rzadko efektywne angażowanie się w IT. Np. „Nie, nie możesz zrobić X. Zapytaj menedżera i uzyskaj zgodę”. (wynik: X nigdy się nie kończy; poziom frustracji wzrasta)
Andres F.,
0

Jednym ze sposobów, w jaki moja firma pomaga w takich sytuacjach, jest brak agnostyki językowej. Jeśli chcesz, aby aplikacja / program był nawet brany pod uwagę, musi być w wybranym przez nas języku (java). Możemy nieco rozszerzyć reguły dla niektórych JQuery lub js, ale musiałaby to być dobrze skomponowana aplikacja, która zaspokoiłaby krytyczną potrzebę. Nie przychodź i nie mów: „Mam tę aplikację PHP, którą musisz dla mnie hostować”, ponieważ prawdopodobnie dostaniesz po prostu arkusz polis.

Ważne jest, aby skubać rzeczy, zanim staną się zbyt duże, ponieważ kiedy już się pojawią, lepiej mieć kogoś, kogo możesz poświęcić na naukę lub przepisywanie. Ponieważ kiedy ta duża peruka na górze zdecyduje, że mu się podoba, prawdopodobnie nigdy nie pozbędziesz się jej z mojego doświadczenia.

Sedaition
źródło
0

Arogancja maniaków!

W wielu przypadkach użytkownicy biznesowi mogą używać narzędzi do robienia rzeczy, których ludzie IT nie rozumieją. Nie dlatego, że są z natury źli, ale dlatego, że znają biznes, jak to działa i jak chcieliby, aby działał.

Na przykład firma programistyczna opracowała aplikację do optymalizacji (pod względem kosztów) dostępu do danych rynkowych. W zamian udostępnili wtyczkę Excel, aby użytkownicy mogli uzyskać dostęp do najnowszej ceny akcji za pomocą arkusza kalkulacyjnego. Jeden rok do przodu i prawie każdy handlowiec w firmie, w której pracowałem, miał jeden lub więcej niezwykle złożonych arkuszy kalkulacyjnych wspierających ich strategię handlową. Od czasu do czasu mieli problem z makrami i prosili jednego z informatyków o pomoc, większość odmówiła (i zastanawiają się, dlaczego firma nas nienawidzi!). Miałem jednak okazję i chociaż mogłem naprawić problemy techniczne z różnymi parametrami funkcji i referencjami cyklicznymi, mogę szczerze powiedzieć, że nie miałem najmniejszego pojęcia, co właściwie zrobił cały arkusz kalkulacyjny. Nie dlatego, że były źle połączone lub źle zaprogramowane, ale dlatego, że nie miałem wiedzy ani doświadczenia, aby docenić subtelność tego, co inwestorzy starali się osiągnąć. Ponadto oszacowałbym, że projekt informatyczny dla 5 osób na rok plus powiela funkcjonalność jednego z tych arkuszy kalkulacyjnych w „właściwym” języku programowania jako standardowy projekt informatyczny.

James Anderson
źródło