Równo 10 lat temu (wte­dy to na full time sta­łem się nie­za­leż­ną jed­no­oso­bo­wą fir­ma ana­li­tycz­ną) napisałem:

Decyzja o wdro­że­niu jakie­go­kol­wiek sys­te­mu infor­ma­tycz­ne­go wspie­ra­ją­ce­go dzia­łal­ność fir­my wyma­ga oce­ny zasad­no­ści takie­go pro­jek­tu oraz wska­za­niu obsza­rów dzia­łal­no­ści fir­my, któ­re zyska­ją na takim wdro­że­niu. Bardzo czę­sto popeł­nia­nym błę­dem jest roz­po­czę­cie roz­wa­żań doty­czą­cych potrze­by i moż­li­wo­ści wdro­że­nia kon­kret­nej apli­ka­cji. Jest to dość typo­we dzia­ła­nia ini­cjo­wa­ne naj­czę­ściej zło­że­niem ofer­ty przez dostaw­cę apli­ka­cji a nie raz tak­że zna­le­zie­niem rekla­my dane­go pro­duk­tu obie­cu­ją­cej popra­wę funk­cjo­no­wa­nia fir­my w wyni­ku li tyl­ko wdro­że­nia ofe­ro­wa­ne­go roz­wią­za­nia. Dlaczego to jest błąd? Odpowiedź brzmi: zakup sys­te­mu infor­ma­tycz­ne­go mają­ce­go wspie­rać zarzą­dza­nie fir­mą bez posia­da­nia mode­lu tego zarzą­dza­nia oraz zin­for­ma­ty­zo­wa­nie sta­nu zasta­ne­go fir­my jest niczym innym jak tyl­ko utrwa­le­niem tego sta­nu. Nawet jeże­li uda się wdro­żyć sys­tem w tej posta­ci to fir­ma nie posu­nę­ła się w efek­cie ani krok do przodu. […]

Wymagania na sys­tem infor­ma­tycz­ny to w naj­prost­szej posta­ci lista ocze­ki­wa­nych funk­cjo­nal­no­ści nowe­go sys­te­mu powsta­łych i opi­sa­nych jako efekt pra­cy nad pla­nem uspraw­nie­nia pra­cy fir­my. Jak to zro­bić? Potrzebne są do tego trzy głów­ne kroki:

1. Zdefiniowanie roli fir­my na ryn­ku, zro­zu­mie­nie i opi­sa­nie war­to­ści użyt­ko­wej jaką wno­szą ofe­ro­wa­ne pro­duk­ty lub usłu­gi dla klien­ta (ich odbiorcy).
2. Opisanie całe­go pro­ce­su powsta­wa­nia tych pro­duk­tów i usług w kon­tek­ście tych war­to­ści, zbu­do­wa­nie mode­lu fir­my w posta­ci mapy procesów.
3. Na bazie posia­da­ne­go mode­lu fir­my oce­nić struk­tu­rę orga­ni­za­cyj­ną, to czy i jak wspie­ra ona pro­ce­sy zacho­dzą­ce w firmie.

(Jak wyko­nać wyma­ga­nia na sys­tem infor­ma­tycz­ny | Jarosław Żeliński IT-Consulting).

Po tej deka­dzie mogę spo­koj­nie zacy­to­wać kla­sy­ka: ​„histo­ria uczy ludzi, że histo­ria nicze­go ludzi nie nauczy­ła” (Georg Wilhelm Friedrich Hegel, 1770?1831).

Ciekawe jest to, że od tam­tej pory w zasa­dzie nic się nie zmie­ni­ło poza tym, że roz­wi­ja­ją się narzę­dzia i meto­dy pra­cy, na OMG​.org poja­wi­ły nowe wer­sje spe­cy­fi­ka­cji sys­te­mów nota­cyj­nych. mamy znacz­nie wię­cej doświadczeń.

Napisałem ​„w zasa­dzie” nic, bo nadal sta­ty­sty­ki nie­uda­nych pro­jek­tów nie­mal­że nie drgnę­ły, jed­nak świa­teł­ko w tune­lu jest, bo coraz czę­ściej spo­ty­kam się u klien­tów ze zda­niem, że jed­nak ana­li­za jest potrzeb­na przed wybo­rem dostaw­cy, czy­li histo­ria jed­nak cze­goś tam uczy… Teraz jed­nak pozo­sta­je pyta­nie: czym ma być ta ANALIZA… 🙂 Dawny brak przy­go­to­wa­nia do wdro­że­nia zastą­pi­ło zwin­ne przy­go­to­wa­nie, malut­ki postęp … Metody cięż­kie też nie odcho­dzą i to one chy­ba psu­ją to co dziś nazy­wa­my zwin­ną archi­tek­tu­rą, ite­ra­cyj­nym podej­ściem do reali­za­cji pro­jek­tów, tak więc postęp jest…

Przy oka­zji gorą­co zachę­cam do prze­czy­ta­nia całe­go cyto­wa­ne­go arty­ku­łu, nie zdez­ak­tu­ali­zo­wał się ani na milimetr ;).