186 Znaleziono wyniki wyszukiwania

Szukałeś: "modele procesów biznesowych"
IEEE830-1998 ? czy produkuje dobre wymagania?

IEEE830-1998 ? czy produkuje dobre wymagania?

Paradoksalnie wyko­na­nie takie­go mode­lu jest tu naj­więk­szą trud­no­ścią. Dlaczego? Tworząc go nale­ży bez­względ­nie pano­wać na jego zło­żo­no­ścią, pano­wać nad subiek­ty­wi­zmem osób z któ­ry­mi pro­wa­dzi­my wywia­dy, rozu­mieć stra­te­gię mode­lo­wa­nej fir­my i jej model biz­ne­so­wy, wie­le innych. Identyfikacja pro­ce­sów sama w sobie jest trud­na, wyma­ga posia­da­nia metod ich iden­ty­fi­ka­cji i wery­fi­ka­cji popraw­no­ści samej ana­li­zy i mode­lu, to jed­nak temat na książ­kę a nie na taki artykuł.

Czytaj dalej IEEE830-1998 ? czy produkuje dobre wymagania?

SaaS czy to jest BPO? Czyli swoje w końcu czy cudze…

A jed­nak jak to mówią ​„nigdy nie mów nigdy”. Postanowiłem napi­sać o SaaS (Software as a Service, ang. Oprogramowanie jako Usługa) mimo wcze­śniej­szych dekla­ra­cji, że nie będę tego tema­tu poru­szał, ale tu w nie­co innym kon­tek­ście. Dlaczego? Bo jed­nak nie potra­fię słu­chać tłu­ma­cze­nia: ​„SaaS jest dobre dla firm bo jest dobre”. Ja oczy­wi­ście zawsze jestem uciąż­li­wy i pytam ​„Dlaczego dla mnie jest dobre”? Tłumaczenie, że ​„Dzierżawione jest lep­sze i tań­sze” od razu nasu­wa mi pyta­nie ​„To dla­cze­go dostaw­cy SaaS nie są jesz­cze milio­ne­ra­mi?” A jak chcę sko­pać leżą­ce­go to pytam jesz­cze o ren­tow­ność (dla mnie, nie dla niego).

Czytaj dalej SaaS czy to jest BPO? Czyli swoje w końcu czy cudze…
Software Development Journal 11/2007

Software Development Journal 11/2007

Artykuł opi­su­je dru­gi, po przy­pad­kach uży­cia i mode­lu dzie­dzi­ny sys­te­mu, aspekt opi­su wyma­gań: zacho­wa­nia sys­te­mu. Nie jest to pro­ste bio­rąc pod uwa­gę róż­no­rod­ność pro­ble­mów: obiek­ty sta­no­we (np. doku­men­ty, ludzie), współ­bież­ność i trans­ak­cyj­ność i wie­le innych. Opisanie tek­stem w spo­sób jed­no­znacz­ny tych ele­men­tów wyma­gań jest prak­tycz­nie nie moż­li­we. Za pomo­cą dia­gra­mów: sekwen­cji, komu­ni­ka­cji, aktyw­no­ści, maszy­ny sta­nów, czy prze­bie­gów cza­so­wych moż­li­we jest prze­ka­za­nie opi­su budo­wy sys­te­mu np. pro­gra­mi­stom będąc nie­mal­że pew­nym, że napi­szą kod taki jaki chciał pro­jek­tant mimo, tego, że nie będzie go w tym pro­ce­sie kodowania.

Czytaj dalej Software Development Journal 11/2007
Obieg danych, dokumentów, informacji a proces biznesowy

Obieg danych, dokumentów, informacji a proces biznesowy

Kolejna śle­pa ulicz­ka jaką dostrze­gam w rekla­mach sys­te­mów kla­sy work­flow to wska­zy­wa­nie jako głów­nej korzy­ści ich wdro­że­nia narzu­ce­nie ści­słej kon­tro­li poczy­na­niom pra­cow­ni­ków. Nie znam przy­pad­ku wdro­że­nia sys­te­mu zakoń­czo­ne­go suk­ce­sem, któ­re­go głów­nym celem było kon­tro­lo­wa­nie pra­cow­ni­ków wbrew ich woli. Typowym przy­kła­dem są róż­ne­go typu restryk­cyj­ne sys­te­my kon­tro­li cza­su pra­cy czy kon­tro­li pra­cy przy kom­pu­te­rze, nad­zór urzęd­ni­ka tą meto­dą tak­że się nie spraw­dza. Lepszy jest moim zda­niem sys­tem infor­ma­tycz­ny zapro­jek­to­wa­ny tak by poma­gał pra­cow­ni­kom osią­gać ich cele. On nie­ja­ko wdra­ża się sam. Systemy kon­tro­li i restryk­cji, nawet jeże­li uda­je się je wdro­żyć, są bar­dzo kosz­tow­ne i czę­sto boj­ko­to­wa­ne przez ludzi.

Czytaj dalej Obieg danych, dokumentów, informacji a proces biznesowy

Stopień wykorzystania technik wspierających przetwarzanie informacji w przemyśle

Moim zda­niem sto­pień wyko­rzy­sta­nia tech­no­lo­gii wspie­ra­ją­cych prze­twa­rza­nie infor­ma­cji jest w sek­to­rze prze­my­sło­wym naj­więk­szy z uwa­gi na sto­pień kom­pli­ka­cji więk­szo­ści pro­ce­sów pro­duk­cyj­nych. Trudno jest oce­nić o ile wię­cej bo chy­ba nikt takich badań nie pro­wa­dził. Moim zda­niem każ­dą fir­mę moż­na podzie­lić na podob­ne obsza­ry jed­nak ile by ich nie było tyl­ko fir­my pro­duk­cyj­ne będą mia­ły obszar pro­duk­cji. Firmy han­dlo­we, usłu­go­we, logi­stycz­ne nie­wąt­pli­wie mają skom­pli­ko­wa­ne pro­ce­sy biz­ne­so­we jed­nak nie odbie­ga­ją one w swej isto­cie zbyt­nio od tych w fir­mach pro­duk­cyj­nych. Systemy infor­ma­cyj­ne spe­cy­ficz­ne dla pro­duk­cji są nato­miast niszą na ryn­ku wła­śnie z uwa­gi na ogra­ni­czo­ny rynek na nie (tyl­ko fir­my pro­duk­cyj­ne) dla­te­go dodat­ko­wo są kosztowniejsze.

Czytaj dalej Stopień wykorzystania technik wspierających przetwarzanie informacji w przemyśle

Za system IT odpowiada Prezes a nie informatyk

Osobą odpo­wie­dzial­ną za sys­tem IT zawsze będzie zama­wia­ją­cy. Dlatego zama­wia­ją­cy powi­nien jed­no­znacz­nie opi­sać swo­je ocze­ki­wa­nia i zro­zu­mieć potem odpo­wiedź czy­li pro­po­zy­cję ich wyko­naw­cy. Menedżer nie musi uczyć się dia­gra­mów UML ale powi­nien rozu­mieć mode­le pro­ce­sów tak by mieć moż­li­wość ich oce­ny i zatwier­dza­nia. Dlatego mode­le pro­ce­sów powin­ny być two­rzo­ne meto­da­mi zro­zu­mia­ły­mi dla mene­dże­rów, moim zda­niem nie jest to nota­cja UML. Notacja ta jed­nak jest nie­wąt­pli­wie dosko­na­łym narzę­dziem do udo­ku­men­to­wa­nia i prze­ka­za­nia swo­ich ocze­ki­wań przy­szłe­mu wyko­naw­cy sys­te­mu: inte­gra­to­ro­wi IT. Tak więc wyko­naj model pro­ce­sów biz­ne­so­wych, określ któ­re pro­ce­sy chcesz infor­ma­ty­zo­wać. Potem przy­go­tuj na bazie tej ana­li­zy listę przy­pad­ków uży­cia przy­szłe­go sys­te­mu, uzu­peł­nij ją o model poję­cio­wy two­je­go biz­ne­su i fir­my i prze­każ to do reali­za­cji wyko­naw­cy sys­te­mu. Na koniec pozo­sta­je wdro­że­nie a to już osob­ny pro­jekt :), socjologiczny.

Czytaj dalej Za system IT odpowiada Prezes a nie informatyk
Modelowanie a rysowanie

Modelowanie a rysowanie

Model to przede wszyst­kim narzę­dzie ana­li­tycz­ne i komu­ni­ka­cyj­ne. Analityczne bo model powi­nien bez potrze­by kon­tak­tu z pier­wo­wzo­rem zacho­wy­wać sie tak jak on (w wybra­nym kon­tek­ście oczy­wi­ście). Komunikacyjny bo powi­nien być zro­zu­mia­ły dla oso­by nie bio­rą­cej udzia­łu w jego two­rze­niu. Po trze­cie model powi­nien odwzo­ro­wy­wać isto­tę bada­ne­go zja­wi­ska a nie kopio­wać jego pobocz­ne cechy lub opi­sy­wać nie wno­szą­ce nic do bada­nia infor­ma­cje oczy­wi­ste lub wręcz zaciem­nia­ją­ce isto­tę pro­ble­mu. Model wie­ży Eiffla do celów zba­da­nia opo­rów powie­trza nie musi zawie­rać infor­ma­cji o kolo­rze i o tym ile scho­dów nale­ży poko­nać by na nią wejść. Na tej samej zasa­dzie ryso­wa­nie na dia­gra­mie fak­tu, że np. doku­ment jest komu­kol­wiek prze­ka­zy­wa­ny z ręki do ręki jest rysow­nic­twem a nie modelowaniem.

Czytaj dalej Modelowanie a rysowanie
O błędach w modelowaniu

O błędach w modelowaniu

Poprawny model orga­ni­za­cji, w szcze­gól­no­ści mapa pro­ce­sów biz­ne­so­wych, powi­nien opi­sy­wać tyl­ko przed­miot ana­li­zy np. spe­cy­fi­kę orga­ni­za­cji będą­ca np. źró­dłem jej prze­wa­gi kon­ku­ren­cyj­nej i to jak orga­ni­za­cja tę spe­cy­fi­kę two­rzy. Model powi­nien się odwo­ły­wać do innych ist­nie­ją­cych już doku­men­tów, np. zakre­su kom­pe­ten­cji pra­cow­ni­ka czy instruk­cji sta­no­wi­sko­wej. Model zawsze powi­nien mieć jakiś cel swo­je­go powsta­nia i kontekst.

Czytaj dalej O błędach w modelowaniu