Czym jest zarzą­dza­nie? Czym są sys­te­my wspo­ma­ga­ją­ce zarzą­dza­nie? Czym się róż­ni (i czy w ogó­le) sys­tem od opro­gra­mo­wa­nia? Czym są dane? Czym są doku­men­ty? Takie pyta­nia moż­na sta­wiać tyl­ko na pod­sta­wie lek­tu­ry arty­ku­łów na temat nowo­cze­snych metod zarzą­dza­nia jak i ofert dostaw­ców róż­ne­go rodza­ju roz­wią­zań. Niestety nie raz są to albo frag­men­ta­rycz­ne roz­wia­za­nia a nie raz po pro­stu pseu­do-narzę­dzia mają­ce samo­rzut­nie roz­wią­zać jakiś pro­blem ale w to ostat­nie chy­ba nikt roz­sąd­ny już nie wierzy.

Swego cza­su pisa­łem o tym, że tak na praw­dę w fir­mach, orga­ni­za­cjach zarzą­dza się pro­ce­sa­mi i prze­twa­rza­ne są infor­ma­cje. Moim zda­niem na ryn­ku biz­ne­so­wych sys­te­mów IT mamy dwa pod­sta­wo­we typy projektów:

  1. Wybór i wdro­że­nie goto­we­go oprogramowania.
  2. Zaprojektowanie i wyko­na­nie opro­gra­mo­wa­nia dedykowanego.

W obu przy­pad­kach mamy do czy­nie­nia ze skraj­nie róż­ny­mi pro­jek­ta­mi. W zasa­dzie ZAWSZE cze­ka­ja nas oba te warian­ty jednocześnie.

Oprogramowanie goto­we z regu­ły ma kil­ka (bywa kil­ka­na­ście) lat życia i sta­le jest roz­wi­ja­ne. Jeżeli zosta­ło opra­co­wa­ne jako uni­wer­sal­ny pro­dukt ryn­ko­wy (bo adre­sat jest ano­ni­mo­wy) zawie­ra do wybo­ru ogrom­ny nad­miar funk­cjo­nal­no­ści, któ­rych są set­ki a nie raz i tysiące.

Oprogramowanie dedy­ko­wa­ne nie ist­nie­je w momen­cie pod­ję­cia decy­zji o jego wybo­rze jed­nak chce­my by powsta­ło w roz­sąd­nie krót­kim cza­sie. Skoro tak to jeste­śmy w sta­nie w tym ?roz­sąd­nie krót­kim cza­sie? stwo­rzyć pro­dukt, mają­cy kil­ka­dzie­siąt funk­cjo­nal­no­ści (z per­spek­ty­wy użyt­kow­ni­ka) a nie kil­ka tysięcy.

Jaki z tego wnio­sek się mi nasu­wa? Zakup goto­we­go duże­go pakie­tu opro­gra­mo­wa­nia (np. sys­te­mu ERP) nie może pole­gać (nie ma to sen­su) na spi­sa­niu a potem spraw­dze­niu tych setek funk­cjo­nal­no­ści i szu­ka­nie ich pod­zbio­ru istot­ne­go dla nas w danym rodza­ju opro­gra­mo­wa­nia. Taki zakup to wia­ra w kom­pe­ten­cje dostaw­cy (nale­ży je ewen­tu­al­nie spraw­dzić), oce­na tech­no­lo­gii wyko­na­nia tego pro­duk­tu (bo to da oce­nę poten­cjal­nych kosz­tów roz­wo­ju i inte­gra­cji) oraz upew­nie­nie się, że pozwo­li on zarzą­dzać NASZYMI danymi.

Jest to dokład­nie taka sama decy­zja jak wybór pro­gra­mu gra­ficz­ne­go dla stu­dia czy edy­to­ra tek­stu dla asy­sten­ta: set­ki pozy­cji w menu, tysią­ce moż­li­wo­ści ale uży­wa­my wybra­nej ich czę­ści. Nie może być jed­nak tak, że pro­gram ten nie obsłu­ży nam naszych doku­men­tów! Musi oczy­wi­ście być przy­go­to­wa­ny na nie­zna­ne nam w przy­szło­ści zmia­ny ale tu spraw­dza­my stan­dar­dy bo nic inne­go nie możemy.

Jeżeli jed­nak oka­że się, że uni­wer­sal­ne roz­wia­za­nia, któ­re zresz­tą są seria kom­pro­mi­sów (w koń­cu to pro­dukt ?dla każ­de­go?) nie speł­nia­ją jakie­goś nasze­go wyma­ga­nia, w szcze­gól­no­ści nie pozwa­la­ją na pra­ce z NASZYMI DOKUMENTAMI to jeśli tyl­ko nie godzi­my się na rezy­gna­cję z NASZYCH DOKUEMNTÓW (i nie rób­my tego bo to praw­do­po­dob­nie jedy­ny ele­ment naszej prze­wa­gi na ryn­ku ? jeśli ją oczy­wi­ście posia­da­my), nale­ży ?bra­ku­ją­cą funk­cjo­nal­ność? odło­żyć na bok by ją sobie stwo­rzyć i zin­te­gro­wać z dużym uni­wer­sal­nym pro­duk­tem. To jest ten dru­gi dedy­ko­wa­ny pro­jekt. Tak więc dzie­li­my nasze wyma­ga­nia na ?dwie kup­ki? bo to rozsądniej.

Dlatego roz­sąd­nie jest kupić uni­wer­sal­ny edy­tor tek­stu i dodać do nie­go pro­gram, któ­ry np. w dedy­ko­wa­ny dla nas spo­sób będzie zarzą­dzał dedy­ko­wa­ny­mi for­mu­la­rza­mi ale ten uni­wer­sal­ny edy­tor tek­stu powi­nien ?współ­pra­co­wać? ze stan­dar­do­wy­mi, dostęp­ny­mi na ryn­ku narzę­dzia­mi programistycznymi.

Tak więc: naj­pierw ana­li­za tego co i jak robi­my. Potem podział tego na obsza­ry stan­dar­do­we, któ­re obsłu­ży­my narzę­dziem uni­wer­sal­nym, i pozo­sta­łe (któ­rych z regu­ły jest bar­dzo mało ale są bar­dzo waż­ne dla nas) i zrób­my je po swo­je­mu ale nie pakuj­my się w niszo­we lub prze­sta­rza­łe tech­no­lo­gie. Nie dawaj­my tak­że wia­ry w to, że kup­no tego co ma (powie­le­nie tego co robi) nasz kon­ku­rent uczy­ni nas bar­dziej kon­ku­ren­cyj­ny­mi bo prak­ty­ka poka­zu­je coś zupeł­nie odwrotnego.

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.