Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Procesy, strategie i reguły...

Bardzo ciekawy artykuł na temat wzajemnej relacji pomiędzy procesami biznesowymi, regułami biznesowymi i strategią.

Cytat z pierwszych akapitów tekstu: The best definition of business process I have come across to date is Janey Conkey Frazier's from one of the very first Business Rule Forum conferences in the late 1990s: the [business] tasks required for an enterprise to satisfy a planned response to an operational business event from beginning to end with a focus on the roles of actors, rather than the actors' day-to-day job. (Ronald G. Ross, "How Business Processes, Strategy, and Business Policies Relate," Business Rules Journal, Vol. 13, No. 6 (June 2012), URL: http://www.BRCommunity.com/a2012/b655.html )

To kolejny przykład podejścia, które uznaje, że proces jest skutkiem organizacji pracy a nie odwrotnie... jestem gorącym zwolennikiem tej tezy, zachęcam do lektury i wymiany poglądów :)Jarek Żeliński edytował(a) ten post dnia 25.08.12 o godzinie 11:45

konto usunięte

Temat: Procesy, strategie i reguły...

Jarek Żeliński:
Bardzo ciekawy artykuł na temat wzajemnej relacji pomiędzy procesami biznesowymi, regułami biznesowymi i strategią.

Dla mnie to, prawdę mówiąc, Majewski show tyle, że "po biznesowemu"; autor najwyraźniej nie ma nic konkretnego do przekazania dlatego pisze dużo, bez sensu i na każdy temat; bombardowanie bodźcami (emocjami) to dobry sposób na wyłączenie logicznego myślenia u odbiorcy.

Ale żeby nie być gołosłownym:

"the [business] tasks required for an enterprise to satisfy a planned response to an operational business event from beginning to end with a focus on the roles of actors, rather than the actors' day-to-day job"

? :) Jarosławie - to jest bełkot; Proponuję eksperyment - wyraź powyższe w języku "kosztów, zysku, organizacji (przy której zysk > koszty)"

"A restaurant sometimes allows members of a party to split the bill for a meal so each person can pay just part."

"The key word in understanding business processes is transformation."
... zaraz się okaże, że bussiness bazuje tylko na modelu rzeczywistości ;)
Może nie wszyscy to wiedzą, ale praca generalnie polega na transformacji jednej rzeczy w inną.

"Business rules are embedded in the flows."

"Unanswered questions surface about critical business practices and trade-offs. "

"A Father's Story"

"Allocation of responsibility to actors."

"A key question then is which scenarios should you model, and which ones not?"

No i pojawił się model ...

Ok. miałem swojego ulubionego ekonomistę(http://ryszardpetru.bblog.pl/); teraz mam ulubionego analityka biznesowego (?)

http://www.ronross.info/

;)
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Procesy, strategie i reguły...

bez przesady, daleki jestem od bałwochwalstwa, R.Ross - przyznaję - ma żyłkę kaznodziei, mam obie jego książki i faktem jest, że w moich oczach wody wlał w nie więcej niż Sokołów Podlaski do szynki świątecznej,, ;), traktuje to jako "chorobę amerykańskiego konsultanta" czyli traktowanie innych jak krowy, którym trzeba tłumaczyć na piechotę setkami metafor... (ogólnie nie raz mam wrażenie, że "amerykańskie książki są momentami pisane chyba dla debili ale może to taki naród... - sarkazm.;)))

Jedno jest tu jednak ważne: koncepcja mówiąca, że firma jest zarządzana poprzez reguły biznesowe (to co się dzieje jest efektem stwarzania ograniczeń i nakazów), doskonale pasuje i pomaga zrozumieć prace organizacji i ją modelować. Paradoksalnie w metodach obiektowych jednym z istotniejszych elementów analizy i modelowania w UML są ograniczenia (a mało kto stosuje?!). Dzięki ograniczeniom (ich stosowaniem) modele stają się lepsze i prostsze zarazem...

co nieco napisałem o tym rok temu:
http://it-consulting.pl/autoinstalator/wordpress/2011/...

Gdybyśmy chcieli opisać wymagania na samochód skupiając się jedynie na nim, uwzględniają promień skrętu i wymiary musielibyśmy zapisać wiele papieru. Łatwiej i w zasadzie bez ryzyka klapy, będzie jeśli podamy ograniczenie: wymiary garaży i plan skomplikowanego przejazdu od bramy do tego garażu.

Ale poza tym masz dużo racji jeśli chodzi o jego blog ;)

konto usunięte

Temat: Procesy, strategie i reguły...

Jedno jest tu jednak ważne: koncepcja mówiąca, że firma jest zarządzana poprzez reguły biznesowe (to co się dzieje jest efektem stwarzania ograniczeń i nakazów), doskonale pasuje i pomaga zrozumieć prace organizacji i ją modelować.

Trudno się nie zgodzić jednak widzę wyjątki. Nie wszystko da się opisać za pomocą reguł. Czasem po prostu nie można dopatrzeć się żadnych algorytmów. Czasem ich poszukiwanie trwa lata. A decyzja pracownika musi być zerojedynkowa.

Przykład? Zarządzanie ryzykiem kredytowym klientów firmy z rynku B2B pracującej z kluczowymi klientami. Pracownik finansów musi podjąć arbitralną decyzję czy realizować zlecenie i wziąć za to odpowiedzialność. Na wejściu praktycznie zawsze dysponuje jedynie fragmentarycznymi danymi. Ilość potencjalnie możliwych niespodzianek jest prawie nieskończona. Można tylko minimalizować ryzyko. Takie życie.

Oczywiście wielkie firmy i na to potrafią znaleźć algorytmy, ale to jest możliwe dopiero przy pewnej skali i wymaga dosyć zaawansowanych rozwiązań analitycznych.
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Procesy, strategie i reguły...

Marek, zwróciłeś uwagą na ważną rzecz, to co opisałeś - owe wyjątki istnieją - to "decyzja człowieka", a jednym z możliwych Zarządzeń Prezesa (reguła) może być: "W (konkretnych) uzasadnionych przypadkach decyzje o udzieleniu kredytu podejmuje Dyrektor Dep. Kredytów", musi być ona "skojarzona" z wymaganiami na osobę zajmująca to stanowisko (np. 10 lat doświadczenia w bankowości i 5 lat w udzielaniu kretów).

Algorytmizacja pracy to najbardziej mi obca rzecz pod słońcem :), reguły to nie tylko "procedury" ale przede wszystkim delegowanie uprawnień i właściwe "widełki" w zakresach podejmowanych decyzji...Jarek Żeliński edytował(a) ten post dnia 27.08.12 o godzinie 12:53

konto usunięte

Temat: Procesy, strategie i reguły...

Algorytmizacja pracy to najbardziej mi obca rzecz pod słońcem :), reguły to nie tylko "procedury" ale przede wszystkim delegowanie uprawnień i właściwe "widełki" w zakresach podejmowanych decyzji...

A, to jesteśmy w domu :-).

konto usunięte

Temat: Procesy, strategie i reguły...

bez przesady, daleki jestem od bałwochwalstwa, R.Ross - przyznaję - ma żyłkę kaznodziei, mam obie jego książki i faktem jest, że w moich oczach wody wlał w nie więcej niż Sokołów Podlaski do szynki świątecznej,, ;), traktuje to jako "chorobę amerykańskiego konsultanta" czyli traktowanie innych jak krowy, którym trzeba tłumaczyć na piechotę setkami metafor...

Ja taką narrację traktuję trochę inaczej - tzn. takie metafory / analogie / przenośnie nie służą przekazaniu jakiejś konkretnej wiedzy ale otumanieniu czytelnika / słuchacza. Każdy ma jakieś przekonania / wiedzę / doświadczenia i w związku z tym, nie można -wszystkim- przekazać -wszystkiego-.

Jeśli ktoś próbuje to zrobić (przekazać całą wiedzę wszystkim za pomocą metafor) to dla mnie automatycznie staje się oszustem / matołkiem.
(ogólnie nie raz mam wrażenie, że "amerykańskie książki są momentami pisane chyba dla debili ale może to taki naród... - sarkazm.;)))

IMHO narodowość to słaby wyznacznik czegokolwiek
Jedno jest tu jednak ważne: koncepcja mówiąca, że firma jest zarządzana poprzez reguły biznesowe (to co się dzieje jest efektem stwarzania ograniczeń i nakazów), doskonale pasuje i pomaga zrozumieć prace organizacji i ją modelować.

A czym jest firma ? IMHO - firma jest pewną organizacją (zasady) pracy która gwarantuje (na 99% ;) wytworzenie jakiegoś produktu.
Paradoksalnie w metodach obiektowych jednym z istotniejszych elementów analizy i modelowania w UML są ograniczenia (a mało kto stosuje?!). Dzięki ograniczeniom (ich stosowaniem) modele stają się lepsze i prostsze zarazem...

Nie prawda :)
Dobre ograniczenia to nic innego jak dobre polecenia. Różnica polega na formie.
Mogę przedstawić formalny dowód :)

Z resztą:
Na czym polega różnica między "zróbcie tak, żeby nie było źle" a "zróbcie tak, żeby było dobrze" ?
co nieco napisałem o tym rok temu:
http://it-consulting.pl/autoinstalator/wordpress/2011/...

Gdybyśmy chcieli opisać wymagania na samochód skupiając się jedynie na nim, uwzględniają promień skrętu i wymiary musielibyśmy zapisać wiele papieru. Łatwiej i w zasadzie bez ryzyka klapy, będzie jeśli podamy ograniczenie: wymiary garaży i plan skomplikowanego przejazdu od bramy do tego garażu.

"Brak ryzyka klapy" ... gdzie podpisać ? :)
Ale poza tym masz dużo racji jeśli chodzi o jego blog ;)

No ba. Od niedawna namiętnie śledzę ;)
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Procesy, strategie i reguły...

Ja taką narrację traktuję trochę inaczej - tzn. takie metafory / analogie / przenośnie nie służą przekazaniu jakiejś konkretnej wiedzy ale otumanieniu czytelnika / słuchacza. Każdy ma jakieś przekonania / wiedzę / doświadczenia i w związku z tym, nie można -wszystkim- przekazać -wszystkiego-.

bez przesady, metafora to zwykłe odwołanie do doświadczeń rozmówcy... byle z umiarem ;)
Paradoksalnie w metodach obiektowych jednym z istotniejszych elementów analizy i modelowania w UML są ograniczenia (a mało kto stosuje?!). Dzięki ograniczeniom (ich stosowaniem) modele stają się lepsze i prostsze zarazem...

Nie prawda :)
Dobre ograniczenia to nic innego jak dobre polecenia. Różnica polega na formie.
Mogę przedstawić formalny dowód :)

chodzi o sposób i skuteczność przekazu: wyobraź sobie, że masz komuś "przekazać" jaki kształt przyjmie balon nadmuchiwany w kartonowym pudełku, możesz podjąć próbę opisania praw fizyki itp. a może napisać po protu: balon po nadmuchaniu przyjmie kształt pudełka, w którym jest nadmuchiwany, informacje w efekcie przekażę tę samą, ale drugi sposób daje znacznie większa szansę na przekazanie tego co się chce przekazać (kształt balonu po nadmuchaniu to prostopadłościan)
Z resztą:
Na czym polega różnica między "zróbcie tak, żeby nie było źle" a "zróbcie tak, żeby było dobrze" ?

jak wyżej :), na ilości przekazanego tekstu i ryzyka nieporozumienia...
Gdybyśmy chcieli opisać wymagania na samochód skupiając się jedynie na nim, uwzględniają promień skrętu i wymiary musielibyśmy zapisać wiele papieru. Łatwiej i w zasadzie bez ryzyka klapy, będzie jeśli podamy ograniczenie: wymiary garaży i plan skomplikowanego przejazdu od bramy do tego garażu.

"Brak ryzyka klapy" ... gdzie podpisać ? :)

;)
Ale poza tym masz dużo racji jeśli chodzi o jego blog ;)

No ba. Od niedawna namiętnie śledzę ;)

konto usunięte

Temat: Procesy, strategie i reguły...

Ja taką narrację traktuję trochę inaczej - tzn. takie metafory / analogie / przenośnie nie służą przekazaniu jakiejś konkretnej wiedzy ale otumanieniu czytelnika
Jeśli ktoś próbuje to zrobić (przekazać całą wiedzę wszystkim za pomocą metafor) to dla mnie automatycznie staje się oszustem / matołkiem.

Jakub, nie obraź się, ale w sposób kategoryczny krytykujesz używanie metafor, jednocześnie sam używasz metafory / analogii, skądinąd sympatycznego zwierzęcia z komiksu Kornela Makuszyńskiego. To jak jest?

konto usunięte

Temat: Procesy, strategie i reguły...

Ja taką narrację traktuję trochę inaczej - tzn. takie metafory / analogie / przenośnie nie służą przekazaniu jakiejś konkretnej wiedzy ale otumanieniu czytelnika
Jeśli ktoś próbuje to zrobić (przekazać całą wiedzę wszystkim za pomocą metafor) to dla mnie automatycznie staje się oszustem / matołkiem.

Jakub, nie obraź się, ale w sposób kategoryczny krytykujesz używanie metafor,

Nie krytykuję metafor, a jedynie to, że Pan Ross pisze dużo i o niczym.

Powody są czysto samozachowawcze; po prostu boję się, że jakiś manager -z mojej firmy- to przeczyta i weźmie ten bełkot na serio.
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Procesy, strategie i reguły...

Nie krytykuję metafor, a jedynie to, że Pan Ross pisze dużo i o niczym.

Powody są czysto samozachowawcze; po prostu boję się, że jakiś manager -z mojej firmy- to przeczyta i weźmie ten bełkot na serio.

blog jest - jak sądzę - dla tych co przeczytali jego książkę (fakt, że wodolejstwo... ), gdyby jakiś menedżer się tym przejął miał bys opis firmy wykonany z pomocą logicznych zapisów...

tu masz konkrety:

http://www.omg.org/spec/SBVR/1.0/

konto usunięte

Temat: Procesy, strategie i reguły...

Nie krytykuję metafor, a jedynie to, że Pan Ross pisze dużo i o niczym.

Powody są czysto samozachowawcze; po prostu boję się, że jakiś manager -z mojej firmy- to przeczyta i weźmie ten bełkot na serio.

blog jest - jak sądzę - dla tych co przeczytali jego książkę (fakt, że wodolejstwo... ), gdyby jakiś menedżer się tym przejął miał bys opis firmy wykonany z pomocą logicznych zapisów...

na pewno ? To na czym polega relacja między "Business Processes, Strategy, and Business Policies" ? (http://www.brcommunity.com/b655.php)

Bardzo proszę o odpowiedź na to pytanie; najlepiej by było gdyby miała ona jakieś odniesienie do tekstu pana Rossa.

Kiedyś wpadła mi w rękę książka "serferzy wymiarów" w której co drugim słowem było "energia, wymiary, światło, atomy, czas etc ... " to oczywiście był bełkot, ale nie przeszkadzało to pewnym osobom w określaniu tego jako "fizyki".

Wg. mnie Pan Ross "serfuje po biznesie".
Jest to zadanie o tyle prostsze, że nie ma na to wzorów.

tu masz konkrety:

http://www.omg.org/spec/SBVR/1.0/

Opis języka na 400 stron ? :)
Nie, dziękuję. Dziecko nie musi czytać takich rzeczy żeby nauczyć się mówić.

Z całym szacunkiem, ale ani Bill Gates, ani Lary Page, ani nawet Steve Jobs nie mieli o tym pojęcia.
I może właśnie dlatego coś im się udało stworzyć.

Ale wracając do sedna - język (sposób przekazu) ma znaczenie drugorzędne; najważniejsze jest to, co chce się przekazać.
A panów z OMG coraz częściej mam ochotę określić "współczesnymi szamanami"
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Procesy, strategie i reguły...

Jakub Wojt:
tu masz konkrety:

http://www.omg.org/spec/SBVR/1.0/

Opis języka na 400 stron ? :)
Nie, dziękuję. Dziecko nie musi czytać takich rzeczy żeby nauczyć się mówić.

Z całym szacunkiem, ale ani Bill Gates, ani Lary Page, ani nawet Steve Jobs nie mieli o tym pojęcia.
I może właśnie dlatego coś im się udało stworzyć.

tu się mylisz, słownik biznesowy te firmy mają, o ile wiem, wszystkie opisy produktów w tych firmach są mocno sformalizowane ...

Ale wracając do sedna - język (sposób przekazu) ma znaczenie drugorzędne; najważniejsze jest to, co chce się przekazać.

no teraz to pojechałeś...
A panów z OMG coraz częściej mam ochotę określić "współczesnymi szamanami"

skoro tak uważasz...

konto usunięte

Temat: Procesy, strategie i reguły...

tu się mylisz, słownik biznesowy te firmy mają, o ile wiem, wszystkie opisy produktów w tych firmach są mocno sformalizowane ...

Najprawdopodobniej tak jest.
Pytanie tylko - w jaki sposób ?

Czy np. Larry Page przeczytał ten 400 stronicowy dokument zanim zaczął coś formalnie (w końcu doktor matematyki) opisywać ?
Ale wracając do sedna - język (sposób przekazu) ma znaczenie drugorzędne; najważniejsze jest to, co chce się przekazać.

no teraz to pojechałeś...

No to teraz nie rozumiem.
Czy użyty język jest ważniejszy od jasno sprecyzowanej idei (w głowie) ?

Moim zdaniem nie - jeśli ktoś ma konkretny pomysł i chce go opisać to dobiera sobie formę przekazu (język).

Jeśli ktoś uważa, że to język decyduje o "konkretności idei" to dochodzi do absurdalnych sytuacji jak np. na forum UML kiedy ktoś dokładnie opisuje jakąś ideę a następnie prosi o pomoc w "przepisaniu" jej na UML.

Po co dokładne opisy w języku naturalnym (akurat w tym przypadku) przepisywać na UML ? Dokładniejsze i tak nie będą....
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Procesy, strategie i reguły...

Jakub Wojt:
tu się mylisz, słownik biznesowy te firmy mają, o ile wiem, wszystkie opisy produktów w tych firmach są mocno sformalizowane ...

Najprawdopodobniej tak jest.
Pytanie tylko - w jaki sposób ?

Czy np. Larry Page przeczytał ten 400 stronicowy dokument zanim zaczął coś formalnie (w końcu doktor matematyki) opisywać ?

po co, dobra dokumentacja ma ściśle adresowane rozdziały, dla managementu jest jednostronicowe "streszczenie menedżerskie" ;)

Ale wracając do sedna - język (sposób przekazu) ma znaczenie drugorzędne; najważniejsze jest to, co chce się przekazać.

no teraz to pojechałeś...

No to teraz nie rozumiem.
Czy użyty język jest ważniejszy od jasno sprecyzowanej idei (w głowie) ?

tak, bo do jej sprecyzowania i przekazania potrzebny jest (jakikolwiek) język


Moim zdaniem nie - jeśli ktoś ma konkretny pomysł i chce go opisać to dobiera sobie formę przekazu (język).

czyli język jest potrzebny :), gdyby miłą znaczenie drugorzędne nie istniało by pojęcie "poziom znajomości i posługiwania się językiem"...
Jeśli ktoś uważa, że to język decyduje o "konkretności idei" to dochodzi do absurdalnych sytuacji jak np. na forum UML kiedy ktoś dokładnie opisuje jakąś ideę a następnie prosi o pomoc w "przepisaniu" jej na UML.

jak myślisz po co wymyślono diagramy lub pseudokod przy dokumentowaniu algorytmów?

jak sobie wyobrażasz napisanie konkretnej idei niekonkretnym językiem?
Po co dokładne opisy w języku naturalnym (akurat w tym przypadku) przepisywać na UML ? Dokładniejsze i tak nie będą....

przejście z prozy języka pisanego, nafaszerowanego wieloznacznością, na jakikolwiek język (dokumentację) opatrzony słownikiem pojęć spełniającym wymagania typowej przestrzeni nazw to pierwszy krok do jasnego i jednoznacznego opisu "ide", przejście na sformalizowany np. UML czyni ten opis jeszcze bardziej jednoznaczny.

konto usunięte

Temat: Procesy, strategie i reguły...

tu się mylisz, słownik biznesowy te firmy mają, o ile wiem, wszystkie opisy produktów w tych firmach są mocno sformalizowane ...

Najprawdopodobniej tak jest.
Pytanie tylko - w jaki sposób ?

Czy np. Larry Page przeczytał ten 400 stronicowy dokument zanim zaczął coś formalnie (w końcu doktor matematyki) opisywać ?

po co, dobra dokumentacja ma ściśle adresowane rozdziały,

Znowu się nie rozumiemy :)
Nie mówię, że "dokumentacja może przybrać formę brudnopisu ucznia z kiepskim piórem wiecznym" a to, że nie trzeba tworzyć diagramów
np. UML żeby pewne rzeczy precyzyjnie opisywać.

Jeśli rozmowa ma toczyć się dalej to proszę o określenie tematu, bo mam takie dziwne wrażenie, że takiego nie ma :)
dla managementu jest jednostronicowe "streszczenie menedżerskie" ;)

Management z pewnością doceni jednosłowną formę streszczenia - "źle" albo "dobrze".
Wtedy będzie mógł podejmować tylko dobre decyzje. :)Jakub Wojt edytował(a) ten post dnia 02.09.12 o godzinie 19:43
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Procesy, strategie i reguły...

Jakub Wojt:
nie trzeba tworzyć diagramów
np. UML żeby pewne rzeczy precyzyjnie opisywać.

oczywiście, że nie trzeba, podobno projekt drapacza chmur tez można opisać słowami... dlaczego taksie nie robi?

dyskusja moim zdaniem nie toczy się o tym czy używać formalizmów opisując "Procesy, strategie i reguły...", problem w tym jakim ryzykiem komunikacyjnym (dokumentacja służy do utrwalania i przekazywania treści) są obłożone różne metody opisu.

Ja "polecam" te sformalizowane i graficzne bo lata spędzone w technikum a potem na studiach politechnicznych pokazały mi, że obrazy, "schematy" są bez porównania skuteczniejsze niż np. opis tekstem.

Teza "kod programu jest także jego dokumentacją" natychmiast rodzi w mojej wyobraźni: zbudowany dom jest udokumentowaniem jego istnienia.

Tu nikt nikogo do niczego nie przekonuje, po protu w zawalonych projektach (nie tylko IT), podczas ich ratowania (lub ponownego rozpoczynania) projektowanie i dokumentowanie projektu pojawia się bardzo często jako wymagany etap.

Nawet mój obecny projekt: dlaczego zostałem zaangażowany? Bo nikt nie miał pojęcia co powstaje, nie licząc fasady jaką jest ekran programu.
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Procesy, strategie i reguły...

Tak więc pomijając rozwlekły styl pisania Rossa, stworzenie sformalizowanego słownika pojęć i systemu zapisu reguł biznesowych zbliża nas do superformalizmu jakim jest kod programu... i o to chyba chodzi: o jednoznaczność.

konto usunięte

Temat: Procesy, strategie i reguły...

nie trzeba tworzyć diagramów
np. UML żeby pewne rzeczy precyzyjnie opisywać.

oczywiście, że nie trzeba, podobno projekt drapacza chmur tez można opisać słowami... dlaczego taksie nie robi?

Bo można robić rysunki techniczne które z kolei mogą zostać użyte do czegoś konkretnego.
Zapis formalny nie od razu oznacza zapisu użytecznego.

Dla przykładu: do czego konkretnego można użyć np. diagramu UC ?
Teza "kod programu jest także jego dokumentacją" natychmiast rodzi w mojej wyobraźni: zbudowany dom jest udokumentowaniem jego istnienia.

A nie jest ? ;)
Z domami jest o tyle prostsza sprawa, że je widać i "stan domu" nie ulega zmianie w czasie.
Można więc je "narysować".
Tu nikt nikogo do niczego nie przekonuje, po protu w zawalonych projektach (nie tylko IT), podczas ich ratowania (lub ponownego rozpoczynania) projektowanie i dokumentowanie projektu pojawia się bardzo często jako wymagany etap.

No w końcu ogólnie pojęty management zaczyna rozumieć, że żeby coś zrobić, trzeba wiedzieć co ;)

Jak z początkującymi programistami ...
Nawet mój obecny projekt: dlaczego zostałem zaangażowany? Bo nikt nie miał pojęcia co powstaje, nie licząc fasady jaką jest ekran programu.

Ich problem rozwiązałby Agile albo Scrum; po co od razu zastanawiać się nad tym, co chce się robić ;)

konto usunięte

Temat: Procesy, strategie i reguły...

Tak więc pomijając rozwlekły styl pisania Rossa,

... szarlatański :)
stworzenie sformalizowanego słownika pojęć i systemu zapisu reguł biznesowych zbliża nas do superformalizmu jakim jest kod programu... i o to chyba chodzi: o jednoznaczność.

Oczywiście, że o nią chodzi.
To, że uważam Pana Rossa za "szarlatana biznesu" nie znaczy, że podważam sens jednoznaczności :)



Wyślij zaproszenie do