Wprowadzenie

W ramach jed­ne­go z moich nie­daw­nych pro­jek­tów badaw­czych celem ana­li­zy nie było opra­co­wa­nie wyma­gań na opro­gra­mo­wa­nie (tego typu pro­jek­ty to naj­wy­żej ok. 70% mojej aktyw­no­ści) a roz­wią­za­nie pew­nych pro­ble­mów infor­ma­cyj­nych. Z uwa­gi na ochro­nę know-how klien­ta, opis ten został moc­no okro­jo­ny do isto­ty pro­ble­mu oraz meto­dy jego roz­wią­za­nia, nie ma tu z oczy­wi­stych powo­dów opi­su roz­wią­za­nia (ale waż­ne jest to, że roz­wią­za­nie zna­le­zio­no). Wartość jed­nak ma to, że czy­tel­nik może się tu odna­leźć i sam prze­ko­nać, co jest źró­dłem pew­nych pro­ble­mów, czy i jak moż­na je rozwiązać. 

W poniż­szym tek­ście poję­cie sys­tem odno­si sie do sys­te­mu doku­men­tów i for­mu­la­rzy czy­li do infor­ma­cji i zarzą­dza­nia nią. 

Problem 1

Obsługa zapy­tań ofer­to­wych dla zare­je­stro­wa­nych użyt­kow­ni­ków, do pro­stych przy­pad­ków ist­nie­je narzę­dzie on-line do gene­ro­wa­nia ofert: klient skła­da zapy­ta­nie ofer­to­we samo­dziel­nie (przez www) lub przez email. 

Problemem o któ­rym wspo­mnia­łem jest takie uło­że­nie systemu/formularzy, żeby był względ­nie uni­wer­sal­ny. Chciałbym móc wybrać sprze­daż każ­de­go typu ele­men­tu, nato­miast w pamię­ci mam przy­pad­ki, z któ­ry­mi do tej pory nie potra­fię sobie pora­dzić. Sprzedajemy zespo­ły urzą­dzeń (wariant bar­dziej skom­pli­ko­wa­ny do opi­sa­nia). Zespół jako taki ma rów­nież swo­je akce­so­ria. Musimy przy­pi­sać każ­de­mu zleceniu/podzleceniu numer urzą­dze­nia, a w przy­pad­ku ich ser­wi­su, np. wymia­ny klu­czo­wych pod­ze­spo­łów lub ele­men­tów dodat­ko­wych, zapi­sać to w histo­rii tego urządzenia. 

Bardzo czę­sto pro­jek­tan­ci for­mu­la­rzy opi­su­ja­cych pro­dukt intu­icyj­nie odtwa­rza­ją w tych for­mu­la­rzach opis pro­duk­tu ana­lo­gicz­nie do struk­tu­ry jego kon­struk­cji. W efek­cie for­mu­la­rze te mają skom­pli­ko­wa­ną struk­tu­rę i zło­żo­ne regu­ły kon­tro­lu­ją­ce zawar­tość poszcze­gól­nych pól (jeże­li do tego są zacho­wy­wa­ne i przy­wo­ły­wa­ne z bazy rela­cyj­nej zapy­ta­nia­mi SQL, to są bar­dzo kosz­tow­ne w wytwo­rze­niu i utrzy­ma­niu). W efek­cie powie­la­na jest znacz­na część logi­ki opi­su­ją­cej kon­struk­cję, któ­ra i tak jest opi­sa­na w deta­lach w opro­gra­mo­wa­niu CAD. Analiza poka­za­ła, że w celu wybo­ru pro­duk­tu, na for­mu­la­rzu zapy­ta­nia wystar­czy umie­ścić pła­ską listę klu­czo­wych, cha­rak­te­ry­stycz­nych cech pro­duk­tu by go ziden­ty­fi­ko­wać, i na tej pod­sta­wie – dla pew­no­ści – poka­zać np. doku­ment opis (np. PDF) lub zdję­cie pro­duk­tu, by dać klien­to­wi pew­ność, że zna­lazł i zama­wia to co chce. To czy jest to pro­dukt czy też pod­ze­spół, prze­sta­je mieć zna­cze­nie. Dlatego bar­dzo waż­ne jest opra­co­wa­nie mode­lu poję­cio­we­go opi­su­ją­ce­go pro­duk­ty i ich (pro­duk­tów) tak zwa­ne defi­ni­cje atry­bu­to­we (każ­dy pro­dukt ma uni­kal­ny zestaw atry­bu­tów i ich war­to­ści, jakie go opi­su­ją). ,

Problem 2

Usługa mon­ta­żu urzą­dze­nia w powie­rzo­nej więk­szej kon­struk­cji. Ten pro­ces jest u nas nie­unor­mo­wa­ny, zatar­ty jest podział obo­wiąz­ków produkcji/serwis.

To pro­blem wie­lu firm. Tu tak­że roz­wią­za­niem jest posia­da­nie wie­dzy o tak zwa­nym oto­cze­niu nasze­go pro­duk­tu, czy­li: do cze­go słu­ży, komu i cze­go jest czę­ścią. Każda nie­try­wial­na kon­struk­cja czy usłu­ga, to część jakie­goś sys­te­mu. Jedyną sku­tecz­ną meto­dą zarza­dza­nia swo­imi pro­duk­ta­mi jest peł­na wie­dza o śro­do­wi­sku w jakim są uży­wa­ne. Jeżeli Wasz pro­dukt lub usłu­ga są czę­ścią więk­szej cało­ści, to bez jej zro­zu­mie­nia, zarzą­dza­nie Waszą ofer­tą w zasa­dzie nie jest moż­li­we: pro­du­cent butów ma peł­ną wie­dzę o kon­struk­cji ludz­kiej sto­py i typo­wej pogo­dzie w regio­nie, kon­struk­tor auto­bu­sów o urba­ni­sty­ce, pro­du­cent cukier­ków o kub­kach sma­ko­wych a pro­du­cent sil­ni­ków o samo­cho­dach. To dla­te­go posia­da­nie mode­lu wła­sne­go pro­duk­tu, wraz z tym gdzie i jak jest wyko­rzy­sty­wa­ny, jest bazą do opra­co­wa­nia mode­lu poję­cio­we­go i struk­tur infor­ma­cyj­nych opi­su­ja­cych pro­duk­ty i to co sie z nimi dzieje. 

Problem 3

Obecnie nie mam wpro­wa­dzo­nych pro­ce­dur odno­śnie zarządzania/wersjonowania naszych produktów.

To typo­wy pro­blem a roz­wią­za­niem nie jest ERP, a sys­tem CAD i repo­zy­to­rium pro­jek­to­we uzu­peł­nio­ne sys­te­mem PLM (Product Lifecycle Management, ang. Zarządzani Cyklem Życia Produktu). .

Problem 4

Zarządzanie ser­wi­sem. Obecnie dział ser­wi­su jest jed­nym z dzia­łów fir­my. Planujemy out­so­ur­cing ser­wi­su. Jak wydzie­lić ser­wis z firmy?

Wbrew pozo­rom, out­so­ur­cing wybra­nych usług lub całych dzia­łów, czy­li ich wydzie­le­nie z fir­my bez prze­ry­wa­nia bie­żą­cej pra­cy, wyma­ga bar­dzo pre­cy­zyj­ne­go pla­nu. Opracowanie tego pla­nu tak, by wdro­że­nie zmia­ny nie zaszko­dzi­łem fir­mie w okre­sie przej­ścio­wym, wyma­ga bar­dzo dobre­go przy­go­to­wa­nia, bo stra­ty finan­so­we, w tym utra­ta czę­ści klien­tów, spo­wo­do­wa­ne nawet okre­so­wym spad­kiem jako­ści obsłu­gi, mogą być nie­od­wra­cal­ne. Takie pro­jek­ty wyma­ga­ją: audy­tu i opra­co­wa­nia mapy aktu­al­nych pro­ce­sów biz­ne­so­wych, ana­li­zy i opra­co­wa­nia stan­da­ry­za­cji doku­men­tów i pro­ce­dur, wdro­że­nia stan­dar­dów, prze­ka­za­nie wła­sno­ści tak upo­rząd­ko­wa­nych pro­ce­sów biz­ne­so­wych innej fir­mie. Mając opra­co­wa­ne struk­tu­ry doku­men­tów i to do cze­go słu­żą, mapu­je­my je na role w naszej fir­mie i w fir­mie podwykoanwcy/partnera. A to zna­czy, że nale­ży opra­co­wac co naj­mniej szkie­let pro­ce­sów biz­ne­so­wych part­ne­ra 9to-be) i wymu­sić go w umo­wie z pod­wy­ko­naw­cą. .

Podsumowanie

Systemy infor­ma­cyj­ne to nie tech­no­lo­gia, ta jest ich nośni­kiem. Bez zro­zu­mie­nia słow­nic­twa, struk­tur infor­ma­cyj­nych doku­men­tów (for­mu­la­rze ekra­no­we to też doku­men­ty), wdro­że­nie sys­te­mu infor­ma­tycz­ne­go jest nie­moż­li­we lub odby­wa sie ogrom­nych kosz­tem kolej­nych zmian i pro­to­ty­pów. Prowadzenie audy­tów, ana­liz i pro­jek­to­wa­nia ma jeden cel: mini­ma­li­za­cja nie­pew­no­ści w pro­jek­cie. Niepewności jaką jest jego zakres. Nie jest to żaden water­fall, czy­li wie­lo­mie­sięcz­ne ana­li­zy i wdro­że­nia. To pra­ce przy­go­to­waw­cze zaj­mu­ją­ce poje­dyn­cze tygo­dnie. Opracowanie stan­da­ry­za­cji i stra­te­gii wdra­ża­nia zmian w fir­mie, to meto­da na szyb­kie wdro­że­nie każ­dej zmia­ny, zarów­no orga­ni­za­cyj­nej jak i w obsza­rze tech­no­lo­gii IT. 

Zaprzęganie ​„zaawan­so­wa­nej nauki” do takiej pra­cy budu­je pew­ną małą barie­rę mię­dzy mną a klien­tem, dla­te­go wyma­ga­ne jest tu jed­nak pew­ne part­ner­skie pro­jek­to­we zaufanie:

o ile jesz­cze może nie do koń­ca zro­zu­mia­łem wszyst­ko co dla nas Pan wypro­du­ko­wał, to na pew­no naj­waż­niej­szą lek­cją jest to (może nie tyle sobie uzmy­sło­wi­łem, bo z tyłu gło­wy to zawsze sie­dzia­ło, ale spra­wa zyska­ła nowe zna­cze­nie) od cze­go nale­ży zacząć ukła­dać sobie firmę/model biz­ne­so­wy. Nowym dla mnie podej­ściem jest roz­dzie­le­nie mode­lu biz­ne­so­we­go na war­stwy – użyt­ko­wą, infor­ma­cyj­ną, wyko­naw­czą i to że moż­na a nawet chy­ba nale­ży je po kolei i z osob­na ukła­dać. Do tej pory każ­dy doku­ment, któ­ry chcia­łem wpro­wa­dzić był swo­im wła­snym bytem łączą­cym parę zadań. Tu zoba­czy­łem dro­gę: jak opra­co­wać sza­blo­ny doku­men­tów i jak zacząć z nich korzy­stać, tak żeby jako opra­co­wa­ny doku­ment mógł być sku­tecz­nie uży­ty do wie­lu róż­nych zasto­so­wań. Np. to o czym roz­ma­wia­li­śmy: czy rekla­ma­cja róż­ni się od inne­go typu usłu­gi ? Np. od zamó­wie­nia na pro­dukt ? W zasa­dzie nie, i jest prak­tycz­nie tym samym doku­men­tem ale o innym sta­tu­sie. O ile jesz­cze nie wytwo­rzy­łem nic mery­to­rycz­ne­go z Pana pra­cy, tak dała mi pew­ne zaple­cze, inny punkt widze­nia w dal­szych pra­cach. Staram się o dofi­nan­so­wa­nie w ramach prze­my­słu 4.0, jeśli uda mi się ten pro­jekt ruszyć, to jest szan­sa, że jesz­cze popro­szę o wsparcie 🙂

Elementem tego zaufa­nia jest sto­so­wa­nie stan­dar­dów bo, bar­dzo waż­ne jest też to, by autor ana­li­zy i pro­jek­tu roz­wią­za­nia nie uza­leż­niał od sie­bie swo­ich klien­tów. Jak? Autor ana­liz i pro­jek­tów wyra­żo­nych w for­mie doku­men­tów, powi­nien sto­so­wać otwar­te stan­dar­dy i prze­ka­zać klien­to­wi pra­wa do opra­co­wa­nej doku­men­ta­cji, w czę­ści opi­su­ją­cej jego firmę. 

Źródła