Temat: Korporacyjne odejście

najpierw cytat z bardzo nie nieinformtycznego bloga:

Często widząc ewidentnie skopany produkt narzekamy na niedoróbki programistów, inżynierów, dizajnerów. Rzadko mamy rację. W realnych przypadkach to z reguły wina menedżmentu, wszystkich tych dumnych absolwentów szkół biznesu, zarządzania, lansu i baunsu.

cały artykuł:
http://wo.blox.pl/2012/11/Not-to-worry-about-those-peo...

i pytanie: Na ile Wasze doświadczenia potwierdzają powyższe?

Temat: Korporacyjne odejście

Ciężko się nie zgodzić :) Jeżeli rzecz jest kiepsko zaprojektowana, to nawet najbardziej staranne wykonanie nie sprawi że będzie ona świetna i funkcjonalna.

Pozatym - nie oszukujmy się - ktoś wpada na pomysły typu: "obcinamy koszty na testerów, w końcu programista oddaje funkcję przetestowaną, a testy na procesie klient wykona sobie sam - co oczywiście potwierdzi nasz sukces, gdyż programista oddał funkcje po testach jednostkowych"
- i tymi pomysłodawcami (wychodzącymi z pomysłami/forsującymi je) nie są inżynierowie oprogramowania.Krzysztof T. edytował(a) ten post dnia 12.11.12 o godzinie 12:43

Temat: Korporacyjne odejście

Nie wydaje mi się aby problem był taki czarno-biały : albo tylko wina "menadżmentu" albo tylko inżynierów. Sytuacja gdy na stanowisku decyzyjnym znajdzie się osoba, która zwyczajnie nie rozumie jakie następstwa w sferze technicznej powodują jej poczynania, jest w moim odczuciu bardzo prawdopodobna. Ale czy to oznacza, że "informatyk" ma mieć to wszystko gdzieś bo XIX wieczny model korporacji stawia go na końcu łańcucha pokarmowego? To jest panowie nasza odpowiedzialność aby wytłumaczyć tym ludziom co się stanie jeśli poświęcimy jakość techniczną dla innych celów.

pzdr

Temat: Korporacyjne odejście

idealista :)

Temat: Korporacyjne odejście

Jarek Żeliński:
najpierw cytat z bardzo nie nieinformtycznego bloga:

Często widząc ewidentnie skopany produkt narzekamy na niedoróbki programistów, inżynierów, dizajnerów. Rzadko mamy rację. W realnych przypadkach to z reguły wina menedżmentu, wszystkich tych dumnych absolwentów szkół biznesu, zarządzania, lansu i baunsu.

cały artykuł:
http://wo.blox.pl/2012/11/Not-to-worry-about-those-peo...

i pytanie: Na ile Wasze doświadczenia potwierdzają powyższe?

Pan Jobs nie żyje, a Pan W.O. (niestety nie ujawnia imienia i nazwiska) skupia się na polityce (błaznowaniu).

Temat: Korporacyjne odejście

A Wy nie widzicie , ze w większości przypadków rożne funkcjonalności i ich powiązane obszary struktur danych w zasadzie saszufladkowaniem i mieszaniem w kółko tych samych pojęć?

Narzędzia do analizy rynkowej nie powinny znacząco odbiegać od narzędzi dla biologow zajmujących sie laboratoryjna hodowla kultur bakterii. Transformacje w logistyce kontenerow lub przy obiegu dokumentów są dokładnie takie same. W kółko pisze sie te same funkcje robiące to samo, ktore ewentualnie cementuja aktualna w firmie strukturę danych u ksiegowej.

To co jest potrzebne to dobre i uniwersalne interfejsy do nawigacji i przekazywania komunikatów do tej wielowymiarowej infrastruktury danych.

Moze patrzę przez pryzmat firm do 50 pracownikow. Ale warto zadac sobie pytanie dlaczego badanie potrzeb w dwóch takich samych budkach z kebabami wyjdzie zupełnie inaczej. Ok. Wspieramy różnorodność właściwego dotarcia do celu i wygra mądrzejsze podejście. Ale moze warto doedukowac ta cześć użytkowników (decydentów zakupywanego systemu i polityki), do odpowowiedniego poziomu abstrakcji. Wybieranie systemu DMS , bo rozdziela szybko i łatwo załączniki i wersjonuje, to cementowanie głupiej praktyki u jednego z pierwszych klientów danego systemu, ktory nie potrafił wymyślić w swojej firmie prostego schematu organizacyjnego do obiegu dokumentów , ktory znali już Rzymianie przed Jezusem.

Temat: Korporacyjne odejście

Jarek Żeliński:
najpierw cytat z bardzo nie nieinformtycznego bloga:

Często widząc ewidentnie skopany produkt narzekamy na niedoróbki programistów, inżynierów, dizajnerów. Rzadko mamy rację. W realnych przypadkach to z reguły wina menedżmentu, wszystkich tych dumnych absolwentów szkół biznesu, zarządzania, lansu i baunsu.

cały artykuł:
http://wo.blox.pl/2012/11/Not-to-worry-about-those-peo...

i pytanie: Na ile Wasze doświadczenia potwierdzają powyższe?

Nie - większość moich doświadczeń wiąże sie z tzw. Customizacja już gotowego produktu i obiecanek firm informatycznych, ze da sie wszystko zrobić, ze bedzie skalowalne i podlaczone do setki innych aplikacji, i ze bedą to tzw. Real data zbierane z całego swiata, etc.
Wszystko jest kwestia definicji i zrozumienia potrzeb i bolączek obydwu stron.
Wiele przedsiebiorcow nie rozumie, ze implemetacja systemów to dopiero początek współpracy, ze duży globalny system moze zacząć działać w pełni bez większych błędów po 2-5 latach, bo biznes sie zmienia non stop i wymagania tez. To co było przygotowane przed budowa systemu jest juz zdezaktualizowane w momencie implemetacji i moze wymagać upgradu, updatu.
Zaufanie i budowanie relacji partnerskich pomaga obydwu stronom. Wycena kosztow Obslugi jest tez ważna.
To jest kwestia doświadczenia i wiedzy.
Pamietam sytuacje z implemetacja Siebla crm i baz danych Oracla, które musiały obrabiac tryliony danych dziennie. Kilkanaście tysięcy jobow dziennie i updaty innych aplikacji na serwerach, w chmurze, etc.
Ktoś obiecał, ze będzie to działać w Real time, a technologia była z początku lat 90 tych.
Biznes zaufał... A firma informatyczna miała ogromne problemy... W końcu prace podzielilosmy na kilka firm, kilka dostawców, etc. Od nowa pisaliśmy procesy, trigery, zależności.
Strata czasu.

Temat: Korporacyjne odejście

Jarek Żeliński:
najpierw cytat z bardzo nie nieinformtycznego bloga:

Często widząc ewidentnie skopany produkt narzekamy na niedoróbki programistów, inżynierów, dizajnerów. Rzadko mamy rację. W realnych przypadkach to z reguły wina menedżmentu, wszystkich tych dumnych absolwentów szkół biznesu, zarządzania, lansu i baunsu.

cały artykuł:
http://wo.blox.pl/2012/11/Not-to-worry-about-those-peo...

i pytanie: Na ile Wasze doświadczenia potwierdzają powyższe?

Odpowiedzialni są ludzie którzy płacą za projekt (i tylko oni ponoszą konsekwencję), a nie ludzie którzy "wykonują polecenia przełożonego" (z mgmt. włącznie).

Jeśli projekt nie wypala, to znaczy to tylko tyle, że osoby które go organizują, nie mają pojęcia o jego "materii". Dość standardowa sytuacja ..Jakub Wojt edytował(a) ten post dnia 15.12.12 o godzinie 21:52

Temat: Korporacyjne odejście

Fascynują mnie kwestie takich rozproszonych aplikacji i ich projektowania, chodź nigdy tego nie robiłem. Napisałem na własne potrzeby system billingowy z fragmentem ksiegowosci, system techniczny, a teraz juz z prpgramistami doszliśmy do wlasnego BPEL. W zasadzie to nie potrafię odnaleźć sie w tym co stworzyliśmy (porównuje sobie do Sap'a) , bo w teorii ma to umieć wszystko i wszyztko ma sie dać opisać procesowo i obiektowo. Dopisujemy sterowniki do rożnych baz danych, plików xls, obiektów xml, a nawet do tego aby wprost można było parsowac zewnętrzne strony www. Wychodzi na to, ze metodologia wdrażania / naszego rozwoju to przedewszystkim Człowiek - wykonawca procesu, jako jednostka, która zna, rozumie strukturę, potrafi w narzędziu typu xero: rozpisać go na elementarne zasoby, podlegające procesom . Jezeli to kuma, to dopisuje te elementy do bazy, dodajemy je do tabel inwentaryzacyjnych i laczymy z procesami. Po malu zaczynaja nam sie schody, ale efekty już mamy. Wydaje mi sie, ze funkcjonujeny w stylu "agile", ale to tez muszę wyjaśnić. Zaczynam jeździć po tych konferencjo/prezentacjach, ale jak pokazuje zainteresowanym flaki naszych założeń i tego co chodzi, to rozkładają ręce i nie wiedza, czy tak sie działa w jakimś systemie czy metodologii. Ale nie w tym rzecz, bo obserwując na naszym rynku konkurencje (firmy z branzy naszej izby) to w firmach są wszyscy bardzo źle nastawieni na procesy - myślą, ze to jest ISO i niepotrzebne dokumenty. Nie rozumieją podejścia procesowego, z reszta sie nie dziwie, bo dopiero samemu niedawno zrozumiałem czym były tak na prawdę główne struktury danych w tabelach. Np. dane w bazie rozrachunków stanowią byt procesu rozliczeniowego itp. Zaczynaja od szukania systemu do obiegu dokumentów, zamiast weryfikacji co jest tak naprawdę potrzebne. Co z tym można zrobić? W zasadzie próbując skonsolidowac rynek inaczej niż kapitalowo, od żadnej z 250 firm nie mogłem jako prezes doprosić sie żadnej mapy procesow. Sami informatycy w ichniejszych firmach o mapie nie maja pojęcia , a jakimś trafem zrobili system do ticketow. Jeszcze nie tracę nadziei, bo w kilku miejscach zaczęli już robic mapy procesow (zrobiliśmy konkurs dla załogi - za najlepsza mapę swojego obszaru procesow dostaniesz iphona). Podsumowując , jak widzicie, zagadnienie jest trudne, a i czasy coraz trudniejsze. Niektóre branże nie wytrzymają tepa narzucanego przez wyprocesowana konkurencje i popadają na plecy. My przyjęliśmy u siebie założenie : czas wdrożenia nowej osoby 2 dni. Tak pisze do systemu szkolenia i testy i tak już mamy zamodelowany proces (nazwę go po naszemu) proces rewitalizacji zasobów dotyczący zasobów typu stanowisko pracy ;-) . Z tego co widzę, jakie sa potrzeby, to powinno zabraknąć specjalistów albo od szkolen albo od modelowania na najbliższe pare lat. To jeszcze zależy jak sie bedą konsolidowac rynki. Boje sie trochę tego, co sie bedzie działo w najbliższych latach .

Temat: Korporacyjne odejście

Informatyka wspiera biznes, nie na odwrót.
Zgadzam sie w 100 %, ze bez znajomosci procesów w firmie nie da sie zajść daleko. Operacje stanowią ok. 80% całej działalności firmy i tutaj jest ogromne pole do automatyzacji i cięcia kosztów..
Wiele osób nie potrafi myśleć procesowo. Ale tak sie nie da działać na dłuższa metę.
Żeby dobrze wydać jakaś rzecz z magazynu w systemie, wszystkie poszczególne etapy muszą być dobrze wprowadzone i zaksiegowane, a najlepiej niewrazliwe na bledy ludzkie. Bez wiedzy biznesowej nie da rady zrobić dobry system i aplikacje.
Pamietam jak wdrazalam budowany od podstaw ERP oparty na dot.necie w jednej firmie z 11 oddziałami w Europie.
Dzięki rozpisaniu na składowe procesów, produktów i ich charakterystyk, wymagan, ryzyk, change requestow, moi developerzy mieli jasne dane i kierunek co maja robić.
Wymyslalismy rewelacyjne rozwiązania: oni techniczne rozwiazania, ja upraszczanie procesow. Ale musieli dogłębnie zrozumieć wszystkie procesy w firmie: produkcje, sprzedaż, magazyny, księgowość ( w każdym kraju inna), jakość, obsługę klienta, raportowanie dla klienta i wewnętrzne, obsługa salonów, security, audyty etc. I jeszcze dobry project management, który jest kluczem.
A potem regularna dokumentacja zmian w systemie, żeby nie było niespodzianek.

Temat: Korporacyjne odejście

Dlatego dostrzegłem, że np. tematy księgowe (to co też podnosi Pan Jarek Żeliński w swoim opracowaniu) , jak można sobie skomplikować procesy dotyczące wprowadzania faktury za tysiące różnych rzeczy, zamiast od razu dojść do wniosku, że księgowość powinna odwzorowywać ważne obiekty kosztowe lub/i procesowe, tak samo też powinny wchodzić do firmy/być księgowane. Przyjęliśmy zasadę, że nie ma dokumentu bez numeru sprawy/zagadnienia. Jedyna różnica to taka, że dzielimy koszty do jednego obiektu na "kosztowe" oraz "inwestycyjne", które stanowią potem "kosztowe" po amortyzacji.
Mamy tyle samo kont kosztowych syntetycznych 080 ile spraw.



Ramowo zawsze nam starczają dwie syntetyki dla "głównego numeru sprawy=numer działu" oraz "numer sprawy". Zawsze to można wszystko łatwo zagregować w arkuszach. Przygoda dokumentu to zawsze numer sprawy.
Co robią koledzy z branży ? Nie mają ani wykazu umów, ani wykazu obiektów kosztowych, ani wykazu spraw. Zamiast narzucać zagadnienia Księgowości, to Księgowość im narzuca obiekty i sposoby pracy. W efekcie czego jak coś chcą policzyć, to siedzą z arkuszami kalkulacyjnymi i rzeźbią sobie drugą księgowość.Arkadiusz Binder edytował(a) ten post dnia 17.12.12 o godzinie 12:14