W polskich instytucjach finansowych (a wcześniej zapewne i gdzie indziej) zmiany pod tym względem przyniosły wdrożenia centralnych systemów obsługi operacyjnej oddziałów. Okazało się wówczas, że innowacje, które własne służby informatyczne wprowadzały niemal na życzenie, nagle można stosować nie częściej niż raz, najwyżej dwa razy w roku. Stwierdzono też, że gotowe systemy centralne to garnitury w znacznym stopniu gotowe, w które trzeba raczej wpasować się samemu, aniżeli próbować czynić z nich ubrania na miarę.

Innym źródłem konfliktów między służbami biznesowymi a obsługą informatyczną bywa decydowanie tych pierwszych o obszarze nie tylko strategii, ale także taktyki (przyjmując, że strategia wyznacza cele i wskazuje oczekiwane po ich realizacji efekty, podczas gdy do taktyki należy opracowywanie szczegółowych sposobów osiągania tych celów). W ten sposób wybory biznesowe przesądzają często o sprawach oprogramowania, sprzętu, protokołów telekomunikacyjnych, metod eksploatacji itp. Zmusza to służby informatyczne do karkołomnych sztuczek, mających wpisać nowe rozwiązanie w istniejące środowiska, a często do budowy jeszcze jednego środowiska od nowa. Oczywiste w takiej sytuacji dodatkowe koszty są dla pomysłodawców całkowitym zaskoczeniem.

Błędy utrudniające współpracę zdarzają się jednak nie tylko po stronie służb biznesowych.

Podstawowy, można rzec - historyczny, powtarzany z pokolenia na pokolenie, szczególnie w młodych, niedoświadczonych zespołach, błąd służb informatycznych z zakresu współpracy z biznesem polega na założeniu, że prędzej czy później biznes da się ukształtować tak, by działał po myśli i według wskazań informatyki.

Podobna sytuacja występuje również wtedy, gdy służby informatyczne w danej organizacji dysponują pewną nadreprezentacją w najwyższym kierownictwie, wynikającą z charyzmy osoby czy ze względów historycznych (np. spektakularny sukces w przeszłości). W takim przypadku dominującą staje się postawa "na nie", zmierzająca, w pierwszej kolejności, do odrzucania, nawet uzasadnionych, żądań biznesowych. Przyjęte żądania są realizowane opieszale, z celebracją reguł i samych działań, co jednak nie zawsze przekłada się na oczekiwaną jakość.

Truizmem jest stwierdzenie, że oba przedstawione modele współpracy - jeden z informatyką zbyt słabą w stosunku do biznesu oraz drugi z informatyką nadmiernie, w odniesieniu do biznesu, mocną - są z punktu widzenia strategii całej organizacji złe i szkodliwe.

Podobnym truizmem jest stwierdzenie, że podstawą poprawności relacji biznes - informatyka jest symbioza, a nie agresja, gdzie strategia informatyczna jest przedłużeniem strategii biznesowej, a nie jej zaprzeczeniem.

Realizacja tych - wydawałoby się oczywistych - reguł nie jest jednak tak prosta, jak samo ich sformułowanie. Wymaga to ścisłej i zorganizowanej współpracy (ciągłej, a nie tylko wynikającej z realizacji okresowej wspólnoty przedsięwzięć) między obydwoma stronami, obejmującej wymianę informacji o planach i zamierzeniach stron, na długo zanim osiągną one oficjalny status oraz stałe, również nieformalne, kontakty wyznaczonych przedstawicieli oraz szefów.

Po różne sposoby rozwiązania problemu, o którym mowa, sięgano już w odległej, jak na informatykę, przeszłości. Stosowano metodyki tworzenia i bieżącego utrzymania systemów, w których duże znaczenie przykładano do fazy analizy potrzeb użytkowników. Działania w niej prowadzono wspólnie z użytkownikami, którzy podpisywali się pod całością powstałych przy tym dokumentów na dowód, że odzwierciedlają one właściwie zgłoszone przez nich potrzeby. Mimo takich zabiegów, gotowe systemy i tak nie spełniały oczekiwań, gdyż w trakcie ich powstawania oczekiwania te się zmieniały.

Przełomem w stosunkach użytkownicy - informatyka miało stać się zastosowanie rozmaitych systemów umożliwiających tworzenie modeli odzwierciedlających potrzeby i zależności występujące w konkretnej dziedzinie. Zakładały one udział użytkowników od początku tworzenia rozwiązań informatycznych i budowę - z ich udziałem - działających prototypów przyszłych systemów. Rozwiązania takie zyskały jednak stosunkowo niewielką popularność i ich stosowanie ogranicza się do niektórych firm informatycznych i nielicznych dużych organizacji.

Podobną metodykę (Oracle Custom Development Method) stosuje firma Oracle, w której po fazie definiowania potrzeb i analizy problemu, następują tradycyjne etapy projektowania, programowania i wdrażania. W odmianie tej metodyki o nazwie Fast Track zakłada się, że przedstawiciele przyszłego użytkownika wchodzą w skład zespołów projektowych tworzących kolejne przybliżenia rozwiązań, które w jakiś sposób są odpowiednikiem prototypów.