PODEJŚCIE KONTEKSTOWE W ROZWOJU ZINTEGROWANYCH SYSTEMÓW INFORMATYCZNYCH

(1)

Studia Ekonomiczne. Zeszyty Naukowe Uniwersytetu Ekonomicznego w Katowicach ISSN 2083-8611 Nr 216 · 2015 Informatyka i Ekonometria 1

Edyta Abramek

Uniwersytet Ekonomiczny w Katowicach Wydział Informatyki i Komunikacji Katedra Informatyki

edyta.abramek@ue.katowice.pl

PODEJŚCIE KONTEKSTOWE W ROZWOJU ZINTEGROWANYCH SYSTEMÓW

INFORMATYCZNYCH

Streszczenie: Celem artykułu jest analiza możliwości wykorzystania podejścia kontek- stowego w rozwoju zintegrowanych systemów informatycznych, które są zazwyczaj postrzegane z perspektywy obsługiwanych przez nie modułów, ale praca z nimi wymaga zastosowania podejścia procesowego. Uzupełnienie procesu o kontekst przeznaczony dla pracownika na danym stanowisku sprzyja zwiększeniu efektywności jego pracy. Użyt- kownik rozumie jak przebiega proces i jaki ma wpływ praca, którą wykonuje, na inne obszary w firmie. Podejście kontekstowe pozwala dostrzec korzyści, jakich dostarczają sprawnie przebiegające procesy. Kontekstowe spojrzenie na zintegrowany system informatyczny i eksploracja procesów ze względu na różne konteksty sprzyja wzrostowi efektywności wykorzystania zasobów firmy. Odkrywa wzorce dla integracji zasobów wiedzy w organizacji.

Słowa kluczowe: kontekst, podejście kontekstowe, kontekst w zintegrowanych systemach informatycznych, kontekstowa eksploracja procesów.

Wprowadzenie

Zintegrowane systemy informatyczne zarządzania wspierają najważniejsze obszary działalności firmy, m.in. zaopatrzenie, sprzedaż, gospodarkę magazy- nową, produkcję, zarządzanie kadrami, księgowość czy kontroling. Wszystkie istotne dla firmy transakcje są rejestrowane w tych systemach z wykorzystaniem menu programu, które jest zorganizowane w sposób modułowy. Jeżeli użytkow- nik przyswoi sobie sposób poruszania się w obrębie jednego modułu, to z łatwo- ścią będzie mógł pracować w pozostałych modułach systemu. Użytkownikiem

(2)

Edyta Abramek 12

danego modułu systemu jest osoba, która z jednej strony posiada wiedzę meryto- ryczną dotyczącą danego obszaru firmy, a z drugiej informatyczną w zakresie obsługi systemu.

Zintegrowane systemy informatyczne są zazwyczaj postrzegane z perspektywy obsługiwanych przez nie modułów, ale praca z nimi wymaga zastosowania podejścia procesowego. Konieczne jest zatem wprowadzenie rozwiązań, które pozwolą na pracę z systemem w ramach procesu biznesowego. Aby zrealizować w firmie wybrany proces i zarejestrować związane z nim dane w systemie informatycznym, wymagane jest wprowadzenie tych danych przez pierwszych użytkowników systemu, a następnie przesłanie ich do kolejnych użytkowników lub dalszego ich przetworzenia z pomocą systemu. Procesy przebiegają bowiem w poprzek struktury funkcjonalnej organizacji i integrują pracę osób z różnych obszarów firmy. Do zbudowania modelu funkcjonalnego czy procesowego zintegrowanego systemu informatycznego na etapie jego projektowania czy wdra- żania jest wymagane zastosowanie podejścia kontekstowego.

Celem artykułu jest analiza możliwości wykorzystania podejścia kontekstowego w rozwoju zintegrowanych systemów informatycznych, przedstawiona na przykładzie graficznego interfejsu użytkownika zaprojektowanego na podstawie modelu procesu biznesowego. Interfejs ten z założenia nie jest przeznaczony dla menadżerów czy decydentów, ale dla pracowników poziomu opera- cyjnego, którzy korzystają z systemów klasy MRPII/ERP. W świetle badań literaturowych, analizy przykładów rozwiązań proponowanych przez producen- tów systemów tej klasy oraz zgodnie z przyjętym celem, można sformułować następujące tezy badawcze:

1) graficzny interfejs użytkownika projektowany na podstawie modelu procesu biznesowego może być wykorzystywany jako rodzaj interfejsu dla użytkow- nika systemu klasy MRPII/ERP na szczeblu operacyjnym;

2) graficzny interfejs użytkownika projektowany na podstawie modelu procesu biznesowego, podobnie jak narzędzia do dynamicznego modelowania struktury przedsiębiorstwa (DEM, Dynamic Enterprise Modeller), korzysta z modelu funkcjonalnego, modelu procesu oraz modelu odniesienia, którym jest kontekst procesu;

3) graficzny interfejs użytkownika projektowany na podstawie modelu procesu biznesowego jest powiązany ze związanymi z nim, w formie odnośnika, funkcjami w systemie, oknami dokumentów, danymi oraz innymi elementa- mi, w tym odnośnikami do danych z systemów zewnętrznych, czyli z tym, co będzie stanowiło jego kontekst, inaczej tło lub okoliczności, które będą wyja- śniały znaczenie zdarzeń i czynności lub ich następstwo.

(3)

Podejście kontekstowe w rozwoju… 13

1. Zintegrowany system informatyczny z perspektywy funkcji, procesów oraz w ujęciu kontekstowym

Zintegrowany system informatyczny jest różnie definiowany w literaturze przedmiotu, m.in. jako taki system, w którym „(…) dane wprowadza się do bazy systemu tylko raz, w ramach funkcji wejścia jednego z jego podsystemów i od tej chwili stają się one dostępne dla użytkowników wszystkich pozostałych pod- systemów” [Januszewski, 2004, s. 425]. Ponadto, przez system zintegrowany jest rozumiany system, w którym [Lech, 2003, s. 12]:

− użytkownik, korzystając z własnej stacji roboczej, jest w stanie uruchomić dowolną funkcję systemu,

− użytkownicy korzystają z jednakowego interfejsu,

− dane są wprowadzane do systemu tylko raz i automatycznie uaktualniają stan systemu oraz są widoczne dla wszystkich jego użytkowników.

Przykładem takich systemów są: SAP Business One, SAP ERP, Comarch ERP Optima, Impuls Evo, IFS Applications, Enova czy Sage ERP X3. Należy zwrócić uwagę na to, że tego rodzaju systemy realizują obecnie procesy zarów- no wewnątrz firmy, jak i w jej otoczeniu.

Pierwotne systemy informatyczne wspomagały określone obszary funkcjo- nalne firmy. Brak było pomiędzy nimi integracji, przez co nieraz wielokrotnie wprowadzano te same dane w różnych systemach czy też modułach tego samego systemu. Z czasem dostrzeżono możliwość i potrzebę integracji pomiędzy mo- dułami, a na wyższym poziomie abstrakcji – integracji pomiędzy komputerowo zintegrowanym zarządzeniem i komputerowo zintegrowanym wytwarzaniem.

Dobrym punktem wyjścia do wdrażania zintegrowanych systemów informatycznych jest uprzednie zamodelowanie procesów biznesowych. Zintegrowa- ne systemy informatyczne wymagają zastosowania podejścia procesowego, aby użytkownik nie zastanawiał się nad następnym krokiem w systemie oraz aby procesy były realizowane sprawniej i efektywniej. Procesy z jednej strony są de- komponowane na czynności (działania), a te są opisywane poprzez konkretne procedury ich realizacji. Z drugiej strony, procesy są grupowane w większe jed- nostki zwane grupami procesów, a te w kategorie procesów np.:

• Poziom pierwszy – Kategorie procesów operacyjnych według klasyfikacji PCF – np. 3.0. Marketing i sprzedaż produktów i usług,

• Poziom drugi – Grupy procesów – np. 3.5. Opracowanie planów sprzedaży i zarządzania,

• Poziom trzeci – Procesy – np. 3.5.4. Zarządzanie zamówieniami sprzedaży,

• Poziom czwarty – Działania/czynności – np. 3.5.4.1. Przyjęcie i weryfikacja zamó- wień sprzedaży, 3.5.4.2. Gromadzenie i utrzymywanie informacji opisujących klienta.

(4)

1

w i F m t

R Ź

14

wan i sp FI-A mat tyw

Rys.

Źród

Z neg prze

AR teria D wy ic

. 1. W dło: E

ka o s edaż R Ro ałow oty ch m

Wid Ekran

ateg syst ż p ozra wa, ychc mod

dok m n z s

gori tem prod

achu , PP czas dułó

mod ystem

ami mu in

duk unk P Pr s zin ów

dułów mu S

i pr nfo któw

ki z rodu

nteg (rys

w w SAP

roc orm w i z od

ukc grow s. 1

w sys Bus

esó aty

us dbio cja.

wan ) al

stem sines

ów czn ług orca

ne s lbo

mie S s On

E

mo nego g w

ami

syst wsp

SAP ne.

Edyt

ożna o z

sy , SD

tem pier

Bu ta A

a p arz yste D S

my in rany

sine Abra

ow ądz emie

Sprz

nfor ych

ess O ame

iąza zani

e S zed

rma h prz

One ek

ać ia, SAP daż

atyc zez

mo np.

P E i dy

czne nie

oduł z RP ystr

e by e fun

ły f kat m rybu

yły nkc

funk tego ożn ucja

pos cjon

kcjo orią na z

a, M

strz naln

ona ą 3.

zwi MM

zega nośc

alne .0.

iąza M G

ane ci (r

e zi Ma ać m Gosp

z p rys.

inte arke mo pod

pers 2).

egro etin

duł dark spek

o- ng

ły ka

k-

(5)

R Ź

c o [ m g p w r u n p n t j z f d s s

Rys.

Źród

cen oraz [Ma maj gran pow wyn rozw uwz nie prac nyc tuac jest zbu funk dla szcz sprz

. 2. F dło: O

Po truj z po acie jąc nice wied niku wój zglę pro cow h. W cję

roz udow

kcji wyb zegó zeda

Funk Opra

ode je s owi ejcz na e dz dzia u, c j z ędn oces wnik W s

i po zwią wan

i, ra bran ólny aży

kcjo cowa

ejśc się iąza zak,

uw ział alno co m zint niać

sów kow ytu odją

ąza nia

apor neg ych y) je

onaln anie

ie p na ania , 20 wadz łów ość ma egr op w, ta wi le uacji ąć o anie gra rtów go p h fu est w

nośc wła

proc sek ach 014 ze w fir

os pr row próc akże epsz i kie odp

zas aficz w, s proc unkc wido

ci m sne n

ces kwe h po 4]. O

rea rmy sób.

ow wany

cz o e ko ze z edy

ow stos znej staty cesu

cji.

ocz P

modu na po

ow encj omi

Ori aliza

y. N . K adz ych obsł onte zroz y po

iedn sow

j pr ysty u. U

Na zny

Pod

ułu P odsta

e o jach ędz ent ację Nies Kons

zić h sy

ługi ekst zum ojaw

nie wane reze yk Użyt

ek gra

dejśc

Prod awie

ozna h d zy n tacja ę ok tety sekw

do yste iwa t pro mien wi si kro e w enta czy tkow kran aficz

cie k

dukcj e [ww

acza dzia

nim a p kreś y je

wen sku em anyc

oce nie ię p oki.

sys acji y sy wni nie u

zny kon

ja w ww 1

a sp ałań mi w

proc ślon edno ncją utec ów ch p esu

teg prob Prz stem pro ystem

ik d użyt

obr teks

w sys 1].

pos ń po w ce ceso neg ocz ą ta czn w in prze [zob go p blem

zyk mie oce mów dział

tkow raz

stow

stem

ób odej elu owa go p eśn akie niejs nfor ez n b. W proc m, p kład Sa esu w z ła d wni pro

we w

mie e

pod jmo osi a zm proc nie z ej o szeg rma nie Whi cesu prac dem age E

biz zew dzię ika oces

w ro

enov

dejś owa iągn mus cesu zwi orie go atyc

fun itak u i cow m ilu ERP znes wnęt ęki t sys su o

ozwo

va

ścia any nięc sza u, w ięks enta zar czn nkcj ker,1

dzi wnik ustru RP X sow

trzn temu

stem oraz

oju…

a do ych

cia do w ty sza acji rząd nych ji o 199 iałań k bę

ując X3.

wego nych u w mu z ze

…

o za w zam o ca

ym się jes dzan h z oraz 98].

ń p ędzie

cym Sys o w h, k w ram

(np estaw

arzą org mie ałoś wy ę zak

st s nia zarz z ws Jeg prze

e m m po

stem wraz

któr mac p. ob w o

ądz gani erzo ścio ykr kre skup

pro ząd

spo go z

z n mógł owy m o z z re st ch p bsłu odno

zani izac onyc owe

acz es za

pien oce zan oma znaj nieg

ł lep yższ feru od tano proc uguj ośni

ia, k cji

ch r ego zają ada nie esam nia agan

jom go w piej ze r uje dnoś owi cesu ując

ików któr i po rezu my ąceg ań o uw mi.

po nyc mość

wyk oc rozw

mo śnik ią k u, a ego w (

ry k oza ulta yśle go p oraz wag Da owin

h p ć uł kony

enić waż ożliw kam

kont a nie o pr

link 1

kon a ni atów enia poz z od gi n alsz nie prze łatw ywa ć sy żani woś mi d teks e po roce ków 5

n- ią w a, za d- na zy n ez wi a- y- ia ść do st o- es w)

(6)

Edyta Abramek 16

prowadzących do danych (np. Baza klientów), dokumentów (np. Zrealizowane ofer- ty, Zwroty), funkcji (np. Przygotowanie informacji na potrzeby deklaracji systemu Intrastat) czy innych systemów niezbędnych do codziennej pracy użytkownika systemu. W związku z tym użytkownik nie skupia się na konkretnej funkcji w systemie, lecz na krokach, jakie musi wykonać, aby zrealizować tę część procesu, za którą jest odpowiedzialny [www 4]. Możliwość definiowania profili użytkowników zastoso- wano także w zintegrowanym systemie Comarch ERP Altum, dedykowanym dla średnich i dużych firm handlowo-usługowych i sieci handlowych. Użytkownik mo- że korzystać ze swoich ustawień z dowolnego komputera, na którym zaloguje się w firmie. Analizowanie potrzeb oraz przyzwyczajeń użytkowników systemów jest podstawą tworzenia rozwiązań firmy [Budzinowski, 2012, s. 15-17]. Zmieniając procesy, można lepiej dostosowywać się do wymagań rynku.

2. Modele procesów i ich kontekst

Zgodnie z definicją organizacji OMG, procesem jest sekwencja lub prze- pływ czynności w organizacji, których celem jest wytworzenie jakiegoś dobra [Drejowicz, 2012, s. 10]. Inne definicje podają, że procesem jest ciąg (sekwencja) logicznie uporządkowanych czynności, w wyniku których powstaje okre- ślony efekt działania (produkt, usługa). Proces jest także definiowany jako upo- rządkowany w czasie ciąg zmian i stanów zachodzących po sobie, połączonych związkami przyczynowo-skutkowymi.

Model procesu biznesowego ułatwia zrozumienie, w jaki sposób on przebiega.

Elementy, takie jak odnośniki do funkcji w systemie, dostęp do potrzebnych doku- mentów (raportów, statystyk) oraz systemów zewnętrznych na zajmowanym przez pracownika stanowisku stanowią natomiast elementy jego kontekstu (model odniesienia). Na jednym ekranie jest dostępny zestaw wszystkich narzędzi niezbędnych do codziennej pracy z systemem. Dzięki graficznej prezentacji procesu, uzupełnio- nej o dodatkowe elementy, użytkownik posiada wiedzę m.in. o tym:

1. Jak przebiega proces?

2. Co powinno zostać wykonane?

3. Co lub kto wywołuje proces albo w jakiej sytuacji jest wywoływany proces?

4. Kto jest wykonawcą procesu lub jego etapu?

5. Jakie zasoby są wymagane do realizacji procesu?

6. Kto jest dostawcą danych wejściowych?

7. Co jest wynikiem realizacji procesu?

8. Kto jest odbiorcą wyniku procesu?

9. Kto sprawuje kontrolę nad procesem?

(7)

t z ( a w l k k E ś s o k

R Ź

tam zroz (gdz aliz wów lopo kum któr Ekr śnik sów obs kow

Rys.

Źród

G mi st

zum zie zacj wcz ozio men

rego ran ków w m erw wan

. 3. K B dło: O

Grafi tano mie

jes i da zas

omo ntów o u z ry w np mag wow ny, z

Kole Bus Opra

ficzn owi ć j stem

ane nie owe w. N użyt ys.

p. d gazy wać zam

ejno ines cowa

ny i iący ego m, c ego e mu

ego Naz tko 3 m do l ynow

sta mkn

ość p ss O

ano n

inte ymi o m czym

pro usi o m zwy own moż isty wy atus

ięty

przy ne na p

erfe i je miej m d oces on menu y do nik żna

y do ch, s ka y cz

ygoto odst

P

ejs u ego

jsce dysp su.

otw u (r

oku prz uzu osta od ażde zy a

owy awie

Pod

uży ko e i pon Prz wie rys.

ume zech upeł awc dno ego anul

ywan e [ww

dejśc

ytko onte rol nuję zyjm erać

1) entó

hod łnić ców śnik o z

low

nia d ww 6

cie k

own ekst lę w ę, co

mijm ć po

, ty ów dzi ć o w, do

ków dok wany

doku 6].

kon

nika t (m w z o m my, oszc ylko sta do mo o ra w d kum y) i

ume teks

a w mod

zint mam , że czeg o w anow

sz odel apo do men itp.

ntów stow

po del

tegr m zr e pr góln wybi

wią zcze l od rtu inn ntów

w w we w

ostac odn row robi raco nyc iera ą in egó dnie wi nych

w (

w pro w ro

ci m nies wan ić lu own ch o a ko nter

łów esie

eko h s czy

ocesi ozwo

mod sien nym ub nik okie olej akty w d

nia owa syst y do

ie za oju…

delu nia) m sy co wid en p jno

ywn dane a dla ania tem oku

akup

…

u pr po yste mo dzi prog

po ny ego a pr a zo mów ume

pu n

roc ozw

emi ogę int gram

szc odn o do roce obow w lu

ent j

na pr

esu wala ie i zro terfe

mu czeg

noś oku esu wią ub z

jest

rzyk

u wr a uż info obić fejs u z p

góln śnik ume w p ązań

z je t ot

kładz

raz żytk orm ć) p jak poz ne n k, z entu pos ń, s ego twa

zie s

z e kow maty podc k na ziom

naz za p u (r stac tan o p arty,

syste

elem wnik

yczn cza a ry mu w zwy

pom rys.

ci od nu z

ozi , za

emu

1

men kow nym s re ys. 3 wie y do moc . 4) dno zapa om ablo

u SA

7

n- wi

m e- 3, e- o- cą

).

o- a- mu

o-

AP

(8)

1

R Ź

G

−

− 18

Rys.

Źród

Gro

− s u n

− s

− w

− u p

− z

− o

− d z

− d

− d n

. 4. D k dło: O

D oup

skró uży now skró wsp ułat pro zmn obn

Sł def zów def def.

def nau

Dok kont Opra

o z zal óce ytko wisk

óce parc

twie ces niej niże łow f. 1.

w lu f. 2.

f. 3.

f 4.

ukow

kume teks cowa

zalet licz enie own ku ( enie cie enie sów

jsze enie wnik . fra ub w zes zes zes weg

ent F stem

anie

t pr za m

e cz niko (int e cz pro e w w,

enie e ko k jęz

agm wyr

spó spół

pół go i

Fakt m

wła

racy m.in zasu owi terfe

asu oces w za

e lic oszt

zyk men raże ół cz

ł jed ł od

itp.

tury sne n

y z n.:

u po po fejs u szk

su w arzą

czby tów ka p nt te eń,

zyn dno dnie

y zak na po

tak

otrz odcz dos kol wdr ądz

y b w zw

pols eks

nnik oste esień

kupu odsta

k pr

zeb zas stos eni roże zani

łęd wiąz

skie tu p

ków ek ję

ń ni

u w s awie

rzyg

bneg pra sow a n enia iu z

dów, zany ego

pot

w ws ęzyk iezb

E

syst e ekra

goto

go n acy wany

ow a, zmia

w, ych

PW trze

spó kow będn

Edyt

temi anu z

owa

na z s y do ego aną

h z o WN

bny

łist wyc

nyc ta A

e SA z sys

any

dot syst o je o uż ą i z

obs def y do

tniej ch, k ch d

Abra

AP B stem

ym i

tarc tem ego żytk ze w

ług fini o d

jący któr do z

ame

Busi mu SA

inte

cie mem

rol kow wzg

gą p iuje dokł

ych re s zroz

ek

ines AP B

erfej

do m na

li w wnik

ględ

roc e ko ładn

h, po stan zum

s On Busin

jsem

inf a za w sy

ka, du

cesó onte neg

owi now mien

ne w ness

m k

form ajm ystem

na

ów.

ekst go r

iąza wią o nia u

wraz One

kon

mac mow mie

kon

t jak rozu

any otoc utw

z z m .

ntek

cji, wany

e),

niec

ko [ umi

ych czen woru

możl

kstow

któ ym

czn

[ww ieni

z c nie u lit

iwy

wym

óre prz

ność

ww ia d

zym dan tera

ym d

m f

są zez

ć m

5]:

dan

mś, nej j acki

do od

firm

nie nie

mody

nych

jedn ego

dczy

ma S

ezbę ego

yfik

h w

nos o, dz

ytani

Sag

ędn sta

kacj

wyra

stki, zieł

ia

ge

ne a-

ji

a-

, ła

(9)

O kontekście wiadomo, że [Cortada, 2009]:

− istnieje, jest prawdziwy i ludzie używają go do podejmowania decyzji, za- równo świadomie, jak i podświadomie,

− może zostać sprecyzowany, określony,

− zarząd firmy powinien wykorzystać kontekst w celu poprawy jakości pracy na wszystkich szczeblach przedsiębiorstwa,

− wiedza i narzędzia socjologów i humanistów mogą pomóc wykorzystać moc kontekstu [zob. także: www 1].

Dla osób bezpośrednio związanych z realizacją danego procesu znaczenie będzie miał kontekst, który D. Snowden i M. Bonee [2008, s. 48] nazywają kontekstem sytuacyjnym. W zależności od rodzaju związków przyczynowo- -skutkowych wyróżnili oni różne jego odmiany: prosty, skomplikowany, złożony, chaotyczny i tzw. bezład. Tam, gdzie sytuacje są przewidywalne i rozwiązanie można ustalić na podstawie faktów, mamy do czynienia z kontekstem prostym lub skomplikowanym. Tam, gdzie brak jest wyraźnej zależności między przy- czyną a skutkiem i rozwiązanie problemu odbywa się w zależności od zaistniałej sytuacji i rozwoju wydarzeń, mówimy o kontekstach złożonym lub chaotycz- nym. Czynnikami współistniejącymi, powiązanymi z danym procesem i istot- nymi z punktu widzenia kontekstu sytuacyjnego dla danego użytkownika procesu są [www 4; www 7]:

− miejsce, inaczej lokalizacja w czasie i przestrzeni,

− uczestnicy sytuacji i ich role,

− typ aktywności, inaczej rodzaj zastanej sytuacji (spotkanie, debata, wykład),

− cele, plany, intencje, wiedza na temat sytuacji,

czyli wszystko to, co pozwoli użytkownikowi odpowiedzieć na pytania gdzie jest, czym dysponuje, co mam zrobić lub co może zrobić.

Dla zintegrowanych systemów informatycznych charakterystyczny jest kontekst sytuacyjny określany jako prosty. Cechuje go bowiem stabilność i jasne zależ- ności przyczynowo-skutkowe, jak np. w sytuacji przyjmowania zamówienia lub realizacji sprzedaży. Konteksty tego rodzaju wymagają bezpośredniego zarządzania i monitorowania. Tego rodzaju sytuacjami rządzą określone procedury.

J.W. Cortada wymienia trzy najistotniejsze elementy, które składają się na konteksty proste. Są to (od tego o najszerszym zakresie do tego o najwęższym za- kresie): otoczenie, inaczej środowisko, w którym zaistniała dana sytuacja (envi- ronmental knowledge), najlepsze praktyki (best practice) oraz specyficzna sytuacja (situational specific), którą wszyscy jednakowo rozumieją i w związku z tym wła- ściwe rozwiązanie jest na ogół na tym poziomie oczywiste. Według niego kontekst zapewnia zrozumienie istniejącej sytuacji oraz pobudza myślenie w kierunku po- szukiwania nowego, alternatywnego podejścia do rozwiązania problemu.

(10)

Edyta Abramek 20

3. Kontekstowe spojrzenie na procesy biznesowe realizowane z pomocą zintegrowanych systemów informatycznych

Oprócz wspomnianego wcześniej kontekstu sytuacyjnego i jego rodzajów, można także mówić o kontekście wewnętrznym i zewnętrznym dla organizacji czy też procesu biznesowego. Kontekst wewnętrzny organizacji to kontekst określonej sytuacji, który mówi o tym, jak dane przedsięwzięcie jest zagnież- dżone w strukturze organizacji. Kontekst zewnętrzny organizacji to charaktery- styka środowiska, w jakim działa organizacja (branża, rynek, usługi). Kontekst wewnętrzny procesu biznesowego pozwala zgromadzić informacje na temat [Grajewski, 2012, s. 35]: przebiegu procesu (jakie operacje muszą zostać wykonane, jaka jest ich kolejność i warunki następowania po sobie), danych wejścio- wych i wyjściowych, zdarzeń, jakie trzeba uwzględnić w przebiegu procesu, reguł biznesowych, elementów kontrolnych, wykonawców (osób, grup osób, ale także wsparcie ze strony systemów informatycznych), efektu, jaki proces ma wygenerować. Kontekst zewnętrzny w odniesieniu do danego procesu mówi m.in. o tym, jaki jest cel procesu (w tym także jakie są wobec niego wymagania lub oczekiwania), jakie wyróżniamy role użytkowników (jakie są powiązania pomiędzy nimi i zakresy odpowiedzialności), jakie są potrzeby biznesowe osób związanych z procesem, jakie są mierniki sterujące procesem, ograniczenia, roz- piętość procesu (powiązania procesu z innymi procesami, umiejscowienie procesu w strukturze organizacyjnej), kto jest właścicielem procesu, kto dostarcza danych do procesu, kto odbiera jego rezultaty, jak kompletne są informacje na temat procesu, w jakim zakresie wymagane jest wsparcie techniczne procesu, produkty i dokumenty będące wynikiem procesu i ich ścieżka w procesie. Są to elementy, które mogą mieć wpływ na kształt procesu.

Dla przygotowania kontekstowego interfejsu pracownika zajmującego w firmie stanowisko na szczeblu operacyjnym istotne będą następujące antecedencje:

1. Zgromadzenie potrzeb (później także przyzwyczajeń) użytkownika systemu.

2. Przygotowanie i przedstawienie struktury procesu (np. z odwołaniem do aktu- alnie obowiązującego modelu klasyfikacji procesów).

3. Przygotowanie opisu procesu (słownego lub w postaci karty opisu procesu).

4. Wykonanie graficznej prezentacji procesu (rysunek poglądowy lub model procesu zgodny z obowiązującą notacją modelowania procesów).

5. Wykonanie graficznej prezentacji procesu uzupełnionej dodatkowo o takie elementy, jak odnośniki do funkcji w systemie, dostęp do potrzebnych doku- mentów oraz systemów zewnętrznych na zajmowanym przez pracownika stanowisku itp.

(11)

6. Wskazanie modułów funkcjonalnych zintegrowanego systemu informatycznego związanych z realizacją danego procesu.

7. Opisanie czynności wykonywanych w systemie uzupełnionych o przedstawienie zależności kontekstowych w postaci okien programu lub w postaci dokumentów towarzyszących procesowi.

Posłużmy się przykładowo procesem 4.2.3. Zamawianie materiałów i usług (kategoria procesów – 4.0. Zaopatrzenie, realizacja i dostawa produktów/usług, grupa procesów – 4.2. Zakupy materiałów i usług). Struktura takiego procesu zgodnie z modelem PCF klasyfikacji procesów wygląda następująco [Auksztol, Chomuszko 2012]:

− 4.2.3.1. Przygotowanie/przegląd zamówień,

− 4.2.3.2. Zatwierdzenie zamówień,

− 4.2.3.3. Zwracanie się o śledzenie ofert od dostawców,

− 4.2.3.4. Tworzenie/dystrybucja zamówienia zakupu,

− 4.2.3.5. Wysyłka zamówienia i udzielenie odpowiedzi na zapytania,

− 4.2.3.6. Rejestrowanie otrzymanych towarów,

− 4.2.3.7. Ocena i wyjaśnienie zastrzeżeń.

W celu graficznej prezentacji procesu można wykonać rysunek poglądowy lub zastosować notację modelowania procesów biznesowych, np. BPMN (Busi- ness Process Model and Notation). Dużą zaletą tej notacji jest jej przydatność do opisywania procesów na potrzeby systemów klasy MRPII/ERP oraz Workflow.

Model poglądowy służy jedynie do przedstawienia ogólnego przebiegu procesu biznesowego. Dopiero model wykonywalny służy do precyzyjnego opisania procesu. Zdefiniowane są już dla niego wszystkie jego czynności składowe, typy zadań i zdarzeń, parametry bramek, obiekty oraz ich definicje. Uzupełnieniem graficznej prezentacji procesu powinny być odnośniki (linki) do:

− funkcji w systemie,

− do potrzebnych dokumentów, z którymi użytkownik pracuje,

− do zadań, jakie ma na dany dzień zaplanowane,

− ewentualnie do innych modułów lub systemów zewnętrznych, z których korzysta pracownik na danym stanowisku [zob. www 4], a które będą stanowiły zespół odniesień niezbędnych do zrozumienia procesu.

Na rys. 3 pokazano dokumenty związane z realizacją procesu zamawiania charakterystyczne dla systemu SAP Business One. Na podstawie tak przygoto- wanego rysunku można odczytać, jaka jest kolejność uzupełniania dokumentów w danym procesie, np. najpierw przygotowujemy dokument Zamówienie zakupu, potem dokument PZ (przyjęcie z zewnątrz), następnie fakturę.

(12)

Edyta Abramek 22

Na rys. 4 przedstawiono z kolei dokument przykładowej faktury zakupu z systemu SAP Business One, z której można odczytać te wszystkie elementy, które stanowią jego kontekst, tj. zespół czynników współistniejących, powiąza- nych z danym dokumentem.

Interfejs użytkownika powinien zostać tak zaprojektowany, aby na modelu procesu było pokazane przejście do jego następnego etapu. Użytkownik powinien mieć możliwość wyświetlania podpowiedzi, co ma zrobić w dalszej kolejności.

Graficzny interfejs użytkownika oparty na modelu procesu wprowadza no- wy sposób nawigacji po systemie klasy MRPII/ERP. Rozwiązanie to z założenia powinno przyspieszyć wykonywanie podstawowych operacji i procesów w czasie rzeczywistym.

4. Konteksty eksploracji procesów

Eksploracja procesów polega na analizie struktury modelu procesu i prze- pływu sterowania w ramach konkretnej instancji danego procesu. Wyróżnia się trzy etapy eksploracji procesów: pierwszym jest budowa modelu procesu, dru- gim – weryfikacja modelu procesu, a trzecim – rozbudowa modelu procesu.

W tym ostatnim przypadku chodzi o rozszerzenie i udoskonalenie istniejącego modelu procesu na podstawie informacji z sytuacji, które mogą wystąpić podczas realizacji danego procesu, ale analizując je w określonym kontekście.

Wyróżnia się następujące konteksty eksploracji procesów [www 2]:

• Kontekst przepływu sterowania – celem eksploracji procesów w tym kontek- ście jest analiza kolejności, w jakiej czynności są wykonywane oraz znale- zienie sposobu zapisu ścieżek przebiegu procesu, np. w notacji BPMN.

• Kontekst organizacyjny – celem eksploracji procesów w tym kontekście jest analiza informacji o zasobach zgromadzonych w danych o zdarzeniach, tj. informacji o tym, kto jest zaangażowany w proces (osoby, systemy, role, działy), jaka jest ich rola i wzajemne powiązania. Wynikiem analizy jest: odkrycie struktury organizacyjnej przez grupowanie osób według kryterium roli i jed- nostki organizacyjnej, przedstawienie sieci społecznościowej w organizacji.

• Kontekst przypadku procesu – celem eksploracji procesów w tym kontekście jest analiza właściwości konkretnego przypadku, który może być scharakte- ryzowany poprzez: ścieżkę procesu, aktorów procesu, wartości danych o zdarzeniach (zobacz rys. 4, kto dostarcza dany towar, po jakiej cenie, jaka jest wysokość opłaty za transport).

(13)

• Kontekst czasu – celem eksploracji procesów w tym kontekście jest analiza wykonywania czynności w czasie, ich koordynacji oraz częstotliwości wy- stępowania zdarzeń. Gdy zdarzenia mają znaczniki czasu, wówczas możliwe jest np. odkrywanie wąskich gardeł, przewidywanie czasu zakończenia wy- konywanego procesu.

Oprócz elementu czasu w przypadku procesów, można także oceniać wykorzystanie zasobów lub poniesione koszty. Wykorzystanie narzędzi do pomiaru procesów umożliwia przezwyciężenie problemów zanim powstaną warunki do ich pojawienia się. Eksploracja procesów sprzyja podejmowaniu lepszych decyzji. Pozwala na wyjaśnienie wielu zjawisk, na odkrycie przyczyn występujących problemów oraz na szczegółowe badanie funkcjonowania organizacji.

Podsumowanie

Wiedza o kontekście przydaje się w przypadku, gdy jest wymagana bezpo- średnia interakcja użytkownika ze zintegrowanym systemem informatycznym.

Producenci zintegrowanych systemów informatycznych wychodzą naprzeciw potrzebom użytkowników systemów i udostępniają narzędzia do modelowania procesu i zarazem jego kontekstu – model procesu biznesowego zostaje uzupeł- niony o odnośniki do elementów systemu, z których powinien korzystać pracownik. Odnośniki mogą być dodawane na podstawie preferencji pracownika na danym stanowisku albo też mogą być tworzone na podstawie obserwacji pracy użyt- kownika z systemem. Celem wdrożenia przedstawionego rozwiązania jest dostarcze- nie użytkownikowi narzędzia umożliwiającego kontrolę nad procesem biznesowym lub jego etapami. „Użytkownik rozumie kontekst procesu biznesowego i potrafi określić miejsce, w jakim się znajduje. Rozumie, że praca, którą wykonuje ma wpływ na inne obszary w firmie i nie ogranicza się do pojedynczego zadania czy określonej funkcjonalności w systemie” [www 4]. Po wdrożeniu takiego rozwiązania wykonywanie zadań, pobieranie, uzupełnianie i wysyłanie dokumentów odbywa się zgodnie z definicją procesu. Pracownik ma dostęp do listy zadań oczekujących na wykonanie. Jeżeli tylko posiada uprawnienia, może sprawdzić status procesu. Kontek- stowe spojrzenie na zintegrowany system informatyczny powinno zatem sprzy- jać wzrostowi efektywności wykorzystania zasobów firmy, ponieważ dzięki procesom są odkrywane wzorce integracji zasobów w organizacji.

Rozważania przedstawione w artykule dotyczą etapu projektowania gra- ficznych interfejsów użytkownika na podstawie modeli procesów biznesowych.

Kolejny etap rozważań będzie odnosił się do badania efektywności tego rodzaju rozwiązania. Należy bowiem spodziewać się wzrostu efektywności pracy użyt- kownika w systemie MRPII/ERP wspomaganego poprzez graficzny interfejs

(14)

Edyta Abramek 24

użytkownika w postaci modelu procesu. Użytkownik nie będzie musiał otwierać kolejnych ekranów korzystając z wielopoziomowego menu, dzięki temu zadania powinny być wykonywane w optymalnym czasie. Użytkownik będzie także lepiej zorientowany w tym, jak jego praca będzie wpływała na pracę innych osób w firmie. Zminimalizowane zostanie ryzyko popełnienia błędu na etapie wpro- wadzania danych, skróci się czas wykonywania operacji. Praca z systemami MRPII/ERP będzie sprawiała użytkownikom większą satysfakcję. Z doświad- czeń autorki podczas prowadzenia zajęć ze studentami w zakresie obsługi sys- temów SAP Bussiess One, SAP ERP czy Impuls Evo wynika, że efektywność pracy studentów rośnie, jeżeli wcześniej zapoznali się oni z graficznym modelem procesu, jeżeli wiedzą z których funkcjonalności muszą kolejno skorzystać w czasie realizacji danego procesu. Większość ćwiczeń zostaje wtedy wykonana w zakładanym czasie.

Literatura

Auksztol J., Chomuszko M. (2012), Modelowanie organizacji procesowej, Wydawnictwo Naukowe PWN, Warszawa.

Budzinowski P. (2012), Co mają ze sobą wspólnego system ERP i Facebook?

„Nowoczesne Zarządzanie”, nr 1.

Cortada J.W. (2009), Power and use of context in business management, „Journal of Knowledge Management”, Vol. 13, No. 3.

Drejowicz Sz. (2012), Zrozumieć BPMN, Helion, Gliwice.

Grajewski P. (2012), Procesowe zarządzanie organizacją, PWE, Warszawa.

Januszewski A. (2004), Informatyka w przedsiębiorstwie. Systemy i procesy informatyzacji [w:] A. Rokicka-Broniatowska (red.), Wstęp do informatyki gospodarczej, Oficyna Wydawnicza SGH, Warszawa.

Lech P. (2003), Zintegrowane systemy zarządzania ERP/ERPII, Difin, Warszawa.

Maciejczak M. (2014), Orientacja funkcjonalna i procesowa w zarządzaniu, maciejczak.pl/download/zproc-c1.pdf (dostęp: styczeń 2014).

Snowden D.J., Boone M.E. (2008), Złożoność a proces podejmowania decyzji:

praktyczne rady dla liderów, „Harvard Business Review Polska”, nr 61.

Whitaker, R. (1998), Managing context in enterprise knowledge processes, [w:] Klein D.A. (ed.), The Strategic Management of Intellectual Capital, Butterworth- Heinemann, Boston.

[www 1] www.enova.pl/produkt/moduly/enova-produkcja/ (dostęp: styczeń 2014).

[www 2] Manifest eksploracji procesów, www.win.tue.nl/ieeetfpm/lib/exe/fetch.php?media=

shared:pmm-polish-v1.pdf (dostęp: styczeń 2014).

(15)

[www 3] Pomerol J.-Ch., Brézillon P. (2001), About some relationship between knowledge and context, http://pdf.aminer.org/000/115/348/about_some_relationships _between_knowledge_and_context.pdf (dostęp: 2014).

[www 4] www.sage.com.pl/srednie-i-duze-firmy/Sage_ERP_X3_Procesy_Graficzne.pdf (dostęp: styczeń 2014).

[www 5] Słownik języka polskiego PWN, definicja kontekstu, sjp.pwn.pl/slownik/

2473490/kontekst (dostęp: styczeń 2014).

[www 6] SAP, help.sap.com (dostęp: styczeń 2014).

[www 7] Wikipedia, definicja kontekstu, pl.wikipedia.org/wiki/Kontekst (dostęp: styczeń 2014).

CONTEXT APPROACH IN THE DEVELOPMENT OF INTEGRATED MANAGEMENT INFORMATION SYSTEMS

Summary: The aim of this article is to analyse the possibilities of using the contextual approach in the development of Integrated Management Information Systems (IMIS).

IMIS are usually seen from the perspective of their modules, but working with them requires to use the process approach. Supplementing the process connected with a context of the employee contributes in increasing of the effectiveness of work. A user of IMIS understands how the process continues and how his work which he performs, has an influence on other areas of the company. Contextual approach allows to notice the benefits provided by smoothly running processes. Contextual approach allows look at the integrated system and exploration of process due to the different contexts conducive to the growth of efficiency in the use of company resources. It explores patterns for the integration of knowledge in the organization.

Keywords: context, contextual approach, context in the Integrated Management Infor- mation Systems, process mining based on a context.