Dizajn i implementacija informacionih sistema. Prelazak informacionog sistema u komercijalni rad

Detalji Objavljeno: 14.07.2018 21:24: Razmotrene su osnovne faze implementacije korporativnih informacionih sistema. Pored toga, vrši se pregled projektne dokumentacije svake faze, te se pokazuje zavisnost podataka iz date faze od dokumenata narednih faza.
Preuzimanje: PDF.
Ključne riječi: Dokumenti ERP sistema, dokumentacija implementacije korporativnih informacionih sistema, dokumentacija informacionih sistema, dokumenti u informacionom sistemu, projektnu dokumentaciju ERP sistemi, radna dokumentacija IS, tehnička dokumentacija KIS, pravila informacioni sistem, regulatorni dokumenti za projektovanje informacionih sistema, dokumenti za implementaciju softvera, dokumenti za implementaciju informacionih sistema, faze i dokumenti implementacije softverskih proizvoda, probni rad informacionih sistema, GOST R 54869-2011, ANSI PMBoK.

Definitivno najdepresivnija moguća situacija je neizvjesnost. Neznanje šta će se dalje desiti po pitanju koje vas brine ima izuzetno negativan uticaj. Proces implementacije korporativnog informacionog sistema (u daljem tekstu – CIS) nije izuzetak. Recimo da ste se upravo pridružili projektnom timu bez ikakvog radnog iskustva ili teoretskog znanja. Obavljanjem određenih zadataka ličimo na „slijepe mačiće“ koji čekaju sutrašnja uzbuđenja. Drugi ništa manje ilustrativan primjer je kada konsultant već nekoliko godina rješava strogo ograničen spektar problema, ne želeći razumjeti za koje procese višeg nivoa su relevantni. U takvim slučajevima ne biste se trebali iznenaditi kada se zadatak iznenada ispostavi da je završen „jučer“. Da bismo isključili gore navedeno, potrebno je jasno razumjeti redoslijed faza implementacije CIS-a i dokumente pripremljene u svakoj fazi.

Cilj i zadaci

Svrha ovog rada je sagledavanje osnovnih faza implementacije korporativnih informacionih sistema kako bi se osigurao bolji proces implementacije. Za postizanje ovog cilja potrebno je riješiti sljedeće zadatke:

• pregled literature o implementaciji CIS-a;
• razmatranje osnovnih faza implementacije CIS-a;
• analiza projektne dokumentacije i njihove zavisnosti od faza.

1. Pregled pristupa implementaciji korporativnih informacionih sistema

Korporativni informacioni sistem predstavlja skup informacionih sistema (u daljem tekstu IS) koji definišu datu predmetnu oblast. Postoji nekoliko pristupa uvođenju IS-a, koji su primenljivi i na implementaciju CIS-a (Sl. 1). Počnimo pregled sa pristupom koji je proglasila država. Mi pričamo o tome industrijski standardi, posebno, GOST R 54869-2011, kao i međunarodni ISO standard 21500. Dokumenti sadrže opis faza upravljanja projektom od procesa inicijalizacije do završetka, bez obzira na vrstu sistema koji se implementira. Stoga je moguće koristiti ove standarde za implementaciju tehničkih, informacionih i korporativnih sistema. Trezor stručno znanje upravljanje projektom, predstavljeno od strane ANSI PMI PMBoK, reguliše procese planiranja, izvršenja, pregleda i uticaja od faze iniciranja do završetka projekta. Slično GOST R 54869-2011 i ISO 21500, njegova upotreba je dozvoljena za upravljanje implementacijom razne vrste sistemima

Rice. 1.

Metodologije Accelerated SAP (u daljem tekstu ASAP), Accenture Delivery Methods (u daljem tekstu ADM) i Microsoft Dynamics Sure Step (u daljem tekstu MDSS) koriste kompanije SAP, Accenture i Microsoft pri implementaciji paketa CIS rješenja. Pristupi su fokusirani isključivo na implementaciju projekata implementacije CIS-a. Pristupi o kojima se govorilo prije prvenstveno koriste kaskadnu šemu za implementaciju CIS-a. Ovu šemu karakteriše stroga vremenska zavisnost implementacije faza projekta. Radi za u ovoj fazi može se izvesti samo ako su implementirane sve aktivnosti prethodne faze projekta. Nazivi faza variraju od pristupa do pristupa, međutim sadržaj rada ostaje nepromijenjen. Stoga je sasvim moguće formirati pojedinačna lista i operacije i pripremljena dokumenta. Sumirajmo rezultat analize pristupa implementaciji CIS-a sa listom tipičnih faza implementacije projekta (slika 2).

Rice. 2.

2. Projektna dokumentacija za tipične faze implementacije projekta

U prethodnom dijelu su istaknute tipične faze implementacije projekata za implementaciju CIS-a, uključujući

• priprema projekta;
• dizajn;
• implementacija;
• priprema za pilot industrijski rad (u daljem tekstu LZO);
• OPE;
• prelazak na produktivan rad (u daljem tekstu PE)

i koji su zajednički za ASAP, ADM, MDSS metodologije i standarde. Odsustvo faze PE je dozvoljeno, tada će 4. i 5. faza projekta obezbediti pripremu za PE i PE, respektivno. Pogledajmo dokumente svake faze detaljnije (slika 3).

Rice. 3.

2.1. Faza pripreme projekta

Početna faza projekta implementacije CIS-a je priprema. U kontekstu ove faze, formulišu se ciljevi i zadaci, pripremaju se šabloni dokumenata i prošireni raspored projekta. Glavni dokument faze je povelja koja definiše ciljeve projekta, a sadrži i funkcionalni, organizacioni, tehnički i metodološki obim projekta. Osim toga, dokument opisuje učesnike projekta i utvrđuje proceduru za odobravanje projektne dokumentacije. U pripremi je koncept obuke za projektni tim, uključujući predloženi pristup obuci klijentovog tima za implementaciju CIS-a. Ovdje se generiraju predlošci dokumenata koji se koriste za pripremu dokumentacije u narednim fazama projekta. Opseg projekta sadržan u povelji je neophodan da bi se odredilo vrijeme projekta. Potonji se ogledaju u proširenom rasporedu, koji se kasnije dorađuje za svaku fazu. Dakle, povelja je dominantni dokument u fazi pripreme.

2.2. Faza projektovanja

Nakon završetka pripreme projekta, prelazimo na fazu projektovanja sistema. Kvalitet, povezanost i detaljnost osmišljenih rješenja odlučujući su faktor za uspjeh implementacije CIS-a. Greške napravljene u fazi projektovanja su prilično radno intenzivne za otklanjanje. Početak faze dizajna prati priprema materijala za obuku i plan obuke za tim kupca. Prethodno formirani koncept obuke projektnog tima sadrži samo površinski sadržaj ovih dokumenata. Zatim, projektni tim kupca, zajedno sa stručnjacima izvođača, sudjeluje u istraživanju poslovnih procesa klijenta. Rezultat analize procesa su funkcionalni i tehnički zahtjevi za projektovani sistem.

Zahtjevi kupaca se upoređuju sa standardnim CIS rješenjem (Fit analiza) za identifikaciju funkcionalnih nedostataka (GAP analiza). Funkcionalni nedostatak zahtijeva modifikaciju sistema, za šta se pripremaju razvojne specifikacije koje sadrže iskaz problema i predloženi vektor rješenja. U toku je razvoj koncepta uloga i ovlašćenja koji definiše listu korisničkih uloga i pravila za njihovo kreiranje i dodeljivanje zaposlenima. Standardna CIS funkcionalnost, razvojne specifikacije i koncept uloga i ovlaštenja su neophodni za formuliranje dizajnerskih rješenja. Dizajnerska rješenja sadrže kupčeve poslovne procese u modelima "kao što je" i "kao što će biti", što ukazuje na poboljšanja sistema i uloge korisnika.

Dizajnerska rješenja kreiraju se na osnovu Fit/GAP analize funkcionalnih i tehničkih zahtjeva klijenta. Projektno iskustvo pokazuje da se rješenja najčešće formiraju za poslovni proces svakog kupca. Osim toga, posebno su istaknuta rješenja za održavanje matičnih podataka, organizacijsku strukturu i migraciju. Pitanje migracije istorijskih podataka sistema razmatra se posebno u odgovarajućem konceptu. Koncept uključuje opis pristupa migraciji podataka, mehanizme migracije koji se koriste prema odlukama o dizajnu i predloženi plan migracije. U ovoj fazi kreiraju se i koncepti za obuku krajnjih korisnika i prelazak na korištenje sistema. Koncept obuke korisnika određuje redoslijed i planirano vrijeme treninga, potrebne materijale za obuku, kao i listu vježbi koje će se izvoditi.

Koncept prelaska na korišćenje sistema opisuje proceduru korišćenja novog CIS rešenja i rad prethodnog sistema, postavlja listu koraka kojima se korisnicima pruža mogućnost rada sa novim rešenjem i definiše skup operacija koje se izvršavaju. ručno od strane tehničkih stručnjaka u CIS-u. Svi dokumenti kreirani u ovoj fazi su međusobno povezani. Najviše se mogu smatrati dizajnerska rješenja značajnih dokumenata, budući da su osnova za implementaciju sistema, obuku korisnika, migraciju podataka i prelazak na primjenu predloženog CIS rješenja.

2.3. Faza implementacije

Sistem je implementiran u skladu sa dokumentacijom pripremljenom u fazi projektovanja. Greške u projektovanju neminovno dovode do pogrešne konfiguracije i modifikacije sistema, zbog čega je faza projektovanja toliko bitna. Slijedom projektnih odluka, razvojnih specifikacija i koncepta uloga i ovlaštenja, implementira se sistem, pripremaju se opisi izvedenih postavki, tehnička implementacija specifikacija i postavke uloga i ovlaštenja. Operacije koje nisu uključene u opis izvedenih postavki zahtijevaju ručni unos od strane CIS stručnjaka. Stoga je opis takvih operacija sadržan u uputama za prelazak na korištenje sistema, veza do kojih je sadržana u odgovarajućem konceptu.

Prema konceptu migracije podataka, u ovoj fazi su pripremljena i implementirana projektna rješenja u CIS-u. Ovdje su također pripremljena uputstva, uključujući opis procedura za učitavanje i praćenje podataka, kao i primjere šablona za učitavanje. Konfigurisani i modifikovani sistem se koristi za interno testiranje. Testiranje provode stručnjaci CIS-a na osnovu scenarija funkcionalnog testiranja. Scenariji sadrže vježbe koje odražavaju poslovne procese dizajnerskih rješenja. Svrha funkcionalnog testiranja je provjera ispravnosti rada individualni programi. Integracijsko testiranje, za razliku od funkcionalnog testiranja, omogućava nam da ispitamo ispravnu interakciju programa uključenih u jedan poslovni proces.

U integracijsko testiranje uključeni su i stručnjaci CIS-a i ključni korisnici klijenta. Greške u funkcionalnom i integracijskom testiranju se bilježe u dnevnik problema za naknadnu eliminaciju. Broj grešaka u dnevniku problema ukazuje na dubinu razumijevanja poslovnih zahtjeva korisnika. Ako dnevnik sadrži previše veliki broj kritičnih komentara, postoji velika vjerovatnoća obustave projekta (pošto komentari moraju biti eliminisani prije faze PPE).

2.4. Faza pripreme za pilot-industrijski rad

Implementacija sistema je završena i dnevnik problema sadrži mali broj komentara. Pripreme za OPE počinju. Primarni cilj ove faze je edukacija krajnjih korisnika. Pripremaju se uputstva za krajnje korisnike (u kontekstu poslovnih procesa ili poslovanja). Zatim se na osnovu njih kreiraju scenariji obuke korisnika i uključuju u konačni plan obuke. Predloženi plan obuke kreiran je ranije u kontekstu koncepta obuke. Obuka korisnika se odvija u uslovima bliskim realnim. Stoga je potrebno pripremiti listu učesnika i dodijeliti im stvarne uloge za izvođenje testnih vježbi. Obuke su svojevrsno testiranje sistema, čime se ažurira dnevnik problema.

Zatim se analiziraju komentari dobijeni tokom obuke. Nastavak projekta je moguć ako dnevnik problema sadrži komentare koji ne ometaju realizaciju projekta. U tom slučaju se priprema lista korisnika koji učestvuju u OPE-u i dodjeljuju se potrebne uloge. U toku je izrada plana za prelazak na korištenje sistema u PPE modu, uključujući popis potrebnih koraka kako bi se osigurao rad CIS-a i vrijeme njihove implementacije. Konkretni koraci plana sadrže veze do operacija iz uputstava za prelazak na korištenje sistema. Plan migracije podataka sličan je planu tranzicije sistema, međutim, sadrži veze do uputstava za migraciju. Klijent obezbeđuje popunjavanje i proveru podataka u predlošcima za preuzimanje. Faza pripreme završava se uspostavljanjem korisnika u EPE sistemu, kao i migracijom osnovnih i varijabilnih podataka.

2.5. Faza pilot operacije

Pilot testiranje vam omogućava da testirate performanse sistema tokom poslovnih operacija u stvarnom svetu koristeći istorijske podatke iz prethodnog sistema. Učitavanje varijabilnih podataka u fazi pripreme za EPE ograničeno je na jedan period. Stoga, prva stvar koju korisnici rade u sistemu je da provjere da li su preostala stanja ispravno učitana. Zatim, zaposleni unose kretanja materijala i transakcije na računu na osnovu primarnih dokumenata za dati period. Komentari korisnika prilikom rada sa sistemom se bilježe u dnevnik problema. EPE faza završava se zatvaranjem perioda u modulima logistike, računovodstva i kontrole.

2.6. Faza prelaska na produktivan rad

Uspješan završetak EPE faze omogućava nam da govorimo o prelasku na PE. Glavni uslov za tranziciju je izostanak komentara u dnevniku problema i ažuriranje cjelokupne projektne dokumentacije na osnovu rezultata ispravljanja komentara. Slično fazi pripreme za PE, pripremaju se liste korisnika sistema, planovi za prelazak na PE i migracija podataka. Predlošci za preuzimanje podataka su popunjeni. Nakon kreiranja korisnika u CIS-u, završetka svih operacija iz plana tranzicije i migracije podataka, počinje rad u PE modu. Od ovog trenutka, sve komentare ili probleme koji se pojave rješava tim za korisničku podršku. U fazama implementacije, pripreme za operativno i industrijsko ispitivanje, sistemske greške su evidentirane u dnevniku problema i ispravljene od strane stručnjaka izvođača.

3. Zavisnost dokumenata koji se pripremaju o fazama projekta

Projektnu dokumentaciju odobrava klijent u fazi projektovanja. Nakon toga, tokom faza implementacije, pripreme za PPE i PPE, komentari klijenta na implementirani prototip sistema se odražavaju u dnevnik problema. Ispravljanje komentara dnevnika problema sastoji se od ažuriranja i ponovnog odobravanja dokumenata, kao i dodatne konfiguracije i demonstracije sistema korisniku. Slika ispod prikazuje tok dokumenata za procese dizajna, obuke, tranzicije sistema i migracije podataka (Slika 4). Recimo, na osnovu rezultata obuke otkriveno je da je jedan od scenarija obuke u suprotnosti sa zahtjevima. Koje su posljedice?

Rice. 4.

Prvo, gotovo svi dokumenti su podložni promjenama, od dizajnerskih rješenja do scenarija obuke krajnjih korisnika. Drugo, potrebno je prilagoditi i dokumente o prelasku na korištenje CIS-a i migraciju podataka. Konačno, treće, ponovo obučite krajnje korisnike. Ovako značajni troškovi rada nastaju zbog činjenice da su, s jedne strane, procesi projektovanja, obuke, prelaska na korišćenje sistema i migracije usko povezani, s druge strane, što su komentari kasnije formulisani, to je teže i skupo je njihovo uklanjanje. Zato kvalitet projektnih rješenja određuje uspjeh implementacije CIS-a.

Rezultati i zaključci

Razmatranje metodologija implementacije CIS-a, identifikacija tipičnih faza implementacije sistema, kao i pregled projektne dokumentacije i zavisnost dokumenata od faza projekta predstavljaju glavne rezultate rada. Analiza metodologija implementacije IS omogućila je da se identifikuju faze pripreme projekta, dizajna, implementacije, pripreme za PPE, LZO i prelaska na PPE, koje su tipične bez obzira na izabrani standard ili metodologiju upravljanja projektom. Opis projektne dokumentacije je napravljen za svaku tipičnu fazu implementacije CIS-a i jasno je predstavljen u obliku kaskadnog dijagrama (slika 3). Dato Kratki opis dokumenata i proceduru za njihovu pripremu. Glavni naglasak je na svrsi dokumenata, a ne na njihovom sadržaju.

Prikazana je zavisnost dokumenata od faza projekta. Kao što je ilustrovano, manja izmena u jednom dokumentu zahteva ažuriranje dokumenata koji su korišćeni za pripremu originalnog (slika 4). Ovo značajno povećava radni intenzitet rada. Detaljan opis tipičnih radova u svakoj fazi projekta, analiza projektne dokumentacije i identifikacija osnovnih zahtjeva za sadržaj dokumenata na sličan način određuju obećavajući smjer za dalja istraživanja.

Književnost

1. GOST R 54869-2011. Upravljanje projektima. Zahtjevi za upravljanje projektima. – M.: Standardinform, 2011. – 10 str.
2. Zandhuis A., Stellingwerf R. ISO 21500. Vodič za upravljanje projektima. Džepni vodič. – NL.: Van Haren Publishing, 2013. – 148 str.
3. ANSI/PMI 99-001-2014. Vodič kroz Zbor znanja za upravljanje projektima (PMBOK Vodič). – Pennsylvan.: Project Management Institute, 2013 – 589 str.
4. Brend H. Implementacija SAP R/3 uz ASAP: Službeni SAP vodič. – NJ.: Sybex Inc, 1999. – 591 str.
5. Kress R. Running IT Like a Business: Korak-po-korak vodič za interne IT kompanije Accenture – Ely: IT Governance Publishing, 2012. – 140 str.
6. Shankar C., Bellefroid V. Microsoft Dynamics Sure Step 2010. – Birmingham: Packt Publishing, 2011. – 360 str.
7. Projektovanje informacionih sistema: tutorial/ Gvozdeva T.V., Ballod B.A. – Rostov n/d.: Phoenix, 2009. – 508 str.
8. Kovalev S., Kovalev V. Tajne uspješna preduzeća: poslovni procesi i organizaciona struktura. – M.: BITEK, 2012. – 498 str.
9. Stepanov D.Yu. Pregled logističkih poslovnih procesa na primjeru nabavnih aktivnosti poduzeća // Logistika danas. – 2014. – tom 65, br. – str.208-228.
10. Stepanov D.Yu. Formiranje univerzalnih zahtjeva za korisničke programe pri izradi specifikacija za razvoj ABAP-a // Aktuelni problemi moderne znanosti. – 2014. – tom 78, br. – str.258-268.

Implementacija

Teško je dati savjet o implementaciji koda modula, jer svaki programer ima neke navike i svoj stil razvoja koda. Prilikom implementacije projekta važno je koordinirati razvojni tim(ove). Svi programeri podliježu strogim pravilima kontrole izvornog testa. Razvojni tim, nakon što je dobio tehnički dizajn, počinje kodirati module, a u ovom slučaju glavni zadatak je razumjeti specifikaciju. Dizajner određuje šta treba da se uradi, a programer određuje kako to učiniti.

U fazi razvoja postoji bliska interakcija između dizajnera, programera i testnih timova. U slučaju intenzivnog razvoja, tester je bukvalno „vezan“ za programera, u stvari je član razvojnog tima.

Dizajner u ovoj fazi funkcionira kao „hodaća referentna knjiga“, budući da stalno odgovara na pitanja programera u vezi sa tehničkim specifikacijama.

Najčešće se korisnički interfejsi menjaju tokom faze razvoja. To je, između ostalog, zbog činjenice da se moduli periodično demonstriraju kupcu. Zahtjevi za podacima također se mogu značajno promijeniti.

Treba napomenuti da mora postojati namjenski radni prostor za sklapanje cijelog projekta. Upravo se ovi moduli šalju na testiranje. Interakcija između testera i programera bez centralizovanog prenosa delova projekta je prihvatljiva, ali samo ako je potrebno hitno proveriti neku izmenu. Vrlo često su faza razvoja i faza testiranja međusobno povezane i odvijaju se paralelno. Sistem za praćenje grešaka sinhronizuje radnje testera i programera.

Tokom razvoja treba organizovati stalno ažurirana spremišta gotovih projektnih modula i biblioteka koje se koriste pri sklapanju modula. Preporučljivo je da proces ažuriranja memorije kontroliše jedna osoba. Jedno od spremišta treba da bude za module koji su prošli funkcionalno testiranje, a drugo za module koji su prošli testiranje povezivanja. Prvi od njih su nacrti. Drugi je nešto od čega je već moguće sastaviti sistemski distributivni komplet i demonstrirati ga kupcu za provođenje kontrolnih testova ili prolazak bilo koje faze rada.

Dokumentacija se kreira tokom procesa razvoja. Nakon što je modul prošao testiranje veze, može se opisati u dokumentaciji. Ako se moduli često mijenjaju, opis počinje tek kada modul postane više ili manje stabilan.

Obrada rezultata projektovanja

U fazi razvoja, po pravilu se ponovo provjerava atomičnost funkcija, kao i odsustvo dupliciranja.

Poželjno je da je u fazi projektovanja već izgrađena matrica „funkcija-entitet“. To je u suštini formalizovana reprezentacija onoga što firma pokušava da uradi (funkcioniše) i koje informacije treba obraditi da bi se postigao rezultat (entitet). Takva matrica vam omogućava da provjerite sljedeće točke:

• da li svaki entitet ima konstruktor - funkciju koja kreira instance entiteta (create);
• postoje li reference na ovaj entitet, odnosno da li se ovaj entitet koristi bilo gdje (reference);
• da li ima promjena u ovom entitetu (ažuriranje);
• da li svaki entitet ima destruktor - funkciju koja briše instance entiteta (delete).

Često ulogu destruktora obavlja skup programa za arhiviranje podataka. Često se u informacionim sistemima informacije jednostavno akumuliraju. Ovo je dozvoljeno samo ako tokom čitavog perioda akumulacije informacija (i, zapravo, tokom celog životnog veka informacionog sistema), njegove karakteristike performansi zadovoljavaju zahteve korisnika. U praksi, ovo je izuzetno retka slučajnost. To je uglavnom zbog rasta obrađenih količina informacija. Treba napomenuti da se u ovom slučaju ne možete osloniti samo na snagu DBMS-a ili hardvera, jer ovako opsežne metode povećanja produktivnosti daju nisko procijenjeno povećanje brzine. Zapravo, zadatak da se sistem ili njegovi pojedinačni delovi reaguju na povećanje obima obrađenih podataka je najverovatniji zadatak testiranja. U ovom slučaju, grupa za testiranje kreira modul za generiranje (čak i apstraktnih) podataka, odabire skup upita za koje su karakteristike brzine kritične, zatim vrši mjerenja i crta ovisnost brzine izvršavanja od količine podataka za svaki od upita. . Ovakva jednostavna radnja će vam omogućiti da izbjegnete ozbiljne greške kako u dizajnu tako iu implementaciji informacionog sistema.

Specifikacija modula mora biti završena u fazi projektovanja, kojoj se često jednostavno ne pridaje važnost u stvarnim projektima. I uzalud - jer se zbog nepromišljene implementacije modula mogu izgubiti sve prednosti sheme baze podataka. Dakle, zanemarivanjem specifikacija modula, rizikujete da u informacioni sistem unesete:

• nekontrolisani rast obima podataka;
• nizovi zahtjeva sa inherentno velikom vjerovatnoćom sukoba, ili niti zahtjeva koji će se izvoditi "zauvijek" (pokušati izvršavanje niti, otkrivanje sukoba i vraćanje svih akcija, pokušaj ponovo, itd.) zbog niti koje su s njima u sukobu;
• sistem za miješanje i moduli interfejsa;
• umnožavanje modula;
• greške u postavljanju poslovne logike;
• nedostatak implementacije ili nepotpuna implementacija sistemskih funkcija koje zahtijeva kupac.

Ovo nije potpuna lista problema koji će se otkriti ni u fazi sveobuhvatnog testiranja, bilo prilikom puštanja sistema u rad, a možda čak i tokom rada sistema (kada moduli zaista počnu da se koriste).

Osim toga, nedostatak specifikacija modula neće vam omogućiti da precizno procijenite složenost svakog modula i, kao rezultat, odredite redoslijed kreiranja modula i pravilno rasporedite opterećenje osoblja. Uobičajena situacija u takvom slučaju je „neko nekoga čeka“, dok proces stvaranja informacionog sistema miruje.

Sistemski moduli

Često moramo uzeti u obzir veliki broj procesi usluga ili podrške koji nisu direktno povezani sa navedenom poslovnom funkcijom. U pravilu, to su sistemske funkcije koje se nalaze u bilo kojem informacionom sistemu, kao što su:

• upravitelj redova ili planer zadataka;
• print manager;
• alati za pristup podacima i kreiranje ad hoc upita (često su to generatori izvještaja);
• upravljanje direktorijumima i drugim resursima sistema datoteka;
• automatska rezervna kopija;
• automatski oporavak nakon kvara sistema;
• sredstva za regulisanje pristupa korisnika sistemu (sastoje se od sredstva za kreiranje korisnika i sredstva za dodelu privilegija njima);
• alat za postavljanje okruženja za korisnika informacionog sistema;
• način na koji korisnik može promijeniti svoje postavke (uključujući lozinku);
• alat za upravljanje aplikacijama;
• okruženje administratora informacionog sistema.

Neke od ovih funkcija mora da obavlja operativni sistem, ali ako radi u heterogenom okruženju, onda nema garancije da će se korisnicima dopasti prisustvo različitih interfejsa u različitim operativnim sistemima. U idealnom slučaju, sve klijentske aplikacije treba da rade na istom operativnom sistemu, ali u praksi programeri često moraju da imaju posla sa čitavim „zoološkim vrtom“ različitih radnih stanica kod korisnika – što je rezultat nekoliko pokušaja automatizacije poslovanja. Cilj programera je da sistem dovede do što homogenijeg stanja ili da barem radne stanice krajnjeg korisnika učini sličnima.

Zadatak kreiranja informacionog sistema u heterogenom okruženju značajno povećava zahtjeve za programere koda i za odabrani razvojni alat. Ovo posebno važi za razvoj sistemskih modula. Treba obratiti pažnju na module od kojih zavisi implementacija koda operativni sistem. Takvi moduli moraju biti odvojeni za svaki operativni sistem u grupe, na primjer Win98, WinNT, itd. Moduli svake grupe moraju imati stroga sučelja za razmjenu – podaci koje prenose i primaju su striktno definirani, a svako odstupanje od specifikacije je kažnjivo. Nijedan od modula izvan ove grupe ne može koristiti nikakve pozive osim sučelja razmjene. Na ovaj način su moduli koji zavise od operativnog sistema izolovani od ostalih modula.

Uopšteno govoreći, praksa izolacije sistemskih modula kroz striktno regulisanje njihovih komunikacionih interfejsa značajno minimizira troškove ispravljanja grešaka i podrške sistemu. Osim toga, ovo olakšava testiranje, odnosno otkrivanje grešaka i otklanjanje grešaka. Druga strana problema je da se zahtjevi za kodom interfejsa za razmjenu sistemskih modula naglo povećavaju. Ovo je ono što se prvo otklanja greške i trebalo bi da radi veoma jasno.

Alati za praćenje informacionog sistema

Ako je informacioni sistem veliki, onda biste trebali razmotriti zadatak administriranja sa jedne radne stanice. Neophodno je voditi računa ne samo o krajnjem korisniku informacionog sistema, već i o osoblju koje će ga servisirati. Posebnu pažnju treba posvetiti praćenju kritičnih oblasti informacionog sistema, jer je kvar često lakše sprečiti nego ispraviti njegove posledice. Praćenje se odnosi na one zadatke za koje kupac po pravilu ne razmišlja o potrebi da ih riješi i koji najčešće izostaju u analitičkoj studiji, pa čak i u dizajnu. Potreba za alatima za praćenje postaje očigledna tek u fazi puštanja sistema u rad, a ta potreba je veća što je sistem kompleksniji i što sadrži kritičnije dijelove.

Programeri i dizajneri bi trebali procijeniti složenost sistema. Ako se donese odluka da se napiše sveobuhvatan alat za administraciju i nadzor koji nije predviđen tehničkim specifikacijama, onda u ovom slučaju tehničke specifikacije treba promijeniti, a ne slijediti vodstvo korisnika. U složenom sistemu i dalje ćete morati da nadgledate kritične procese. Vrlo je teško implementirati takve alate u gotov sistem, jer monitori često primaju početne podatke iz sistemskih modula prilično niskog nivoa. Ovo je također malo vjerovatno moguće bez promjena u shemi baze podataka, a nema garancije da takva promjena neće smanjiti performanse sistema.

Razvoj monitora je prilično specifična klasa zadataka: s jedne strane, oni moraju obraditi dovoljnu količinu informacija, s druge strane, ne smiju bitno utjecati na rad ostalih komponenti informacionog sistema. Ovo prisiljava programere da budu posebno oprezni kada dizajniraju monitore i vrlo pažljivo pišu kod svojih modula.

Interfejsi

Sučelja krajnjeg korisnika su ono što korisnik najviše kritikuje, jer upravo te dijelove informacionog sistema može manje-više kompetentno procijeniti – obično su oni jedini koje vidi. To znači da su interfejsi najčešće mijenjani element informacionog sistema u fazi implementacije.

Često mijenjane komponente informacionog sistema treba izolovati od komponenti koje se rijetko mijenjaju tako da neke promjene ne povlače druge. Jedna tehnika za takvu izolaciju je izolacija zahtjeva za podacima iz sučelja na sljedeći način:

• svaki zahtjev je kodiran identifikatorom ili je “zatvoren” određenom sistemskom funkcijom;
• programer interfejsa ne zna ništa o zahtevu za podacima osim parametara atributa selekcije - njihov tip i, eventualno, broj redova u selekciji;
• rukovanje greškama u zahtjevima za podacima je poseban modul;
• rukovanje greškama u tumačenju rezultata upita je takođe poseban modul.

Prilikom obrade rezultata upita podataka, također biste trebali Posebna pažnja obratite pažnju na pitanja korespondencije između tipova jezika domaćina i DBMS-a, uključujući pitanja tačnosti numeričkih tipova, budući da se njihova zastupljenost u različitim DBMS-ovima značajno razlikuje. Također, imajte na umu upite podataka koji koriste funkcije specifične za operativni sistem, kao što su funkcije bajtova i riječi vrijednosti atributa (na primjer, ove funkcije će raditi drugačije na Intel i SUN SPARC). Tipovi podataka se mogu eksplicitno baciti u zahtjevu korištenjem cast funkcija i funkcija ugrađenih u DBMS ili u funkcijama aplikacijskog programa. Ne za sve DBMS, implicitna konverzija tipa daje isti rezultat, tako da ako informacioni sistem koristi podatke iz nekoliko baza podataka kojima upravljaju različiti DBMS, onda je bolje izbjeći implicitne konverzije tipova.

Također biste trebali uspostaviti prilično stroga pravila za izgled korisničkih interfejsa. Treba stvoriti utisak jedinstvenog stila za sve komponente informacionog sistema.

Verzije baze podataka

U većini slučajeva, prva verzija baze podataka projekta kreira se prilično brzo - ovo je implementacija potpuno normalizirane strukture, koja se dobiva u fazi analize. Glavna svrha ove baze podataka je pružanje prototipova, demonstracija i nekih eksperimenata od strane programera i dizajnera.

Skripte za kreiranje baze podataka i njeno popunjavanje početnim podacima također su izvorni kod informacionog sistema i na njega se primjenjuju pravila kontrole verzija. Treba napomenuti da je održavanje verzija baze podataka na razini skripte još uvijek lakše nego na razini alata za izbacivanje i učitavanje podataka koje pruža sam DBMS, budući da u velikoj većini slučajeva takvi alati ne mogu pružiti nekoliko jednostavnih, ali neophodnih funkcija:

• kontrolirati koji se objekti podataka i podaci odvijaju u objektima učitavanja A i B i učitavati samo “razliku” A i B u bazu podataka (izvršiti ažuriranje verzije);
• provjerite da li promjene koje se dešavaju u objektima za učitavanje C i D nisu u sukobu u poređenju sa objektom za učitavanje A (spojite verzije).

CASE alati imaju kontrolu verzije šeme baze podataka, a neki imaju postavke koje vam omogućavaju i kontrolu podataka o pokretanju. Ovo omogućava korištenje ovih alata za pružanje kontrole verzije baze podataka.

Pouzdanije je kontrolirati verzije izvornog koda okidača i pohranjenih procedura korištenjem istog sistema kontrole verzija koji je usvojen za pohranjivanje izvornog koda samog projekta.

Postavljanje logike obrade

Jedno od važnih pitanja dizajna je način postavljanja poslovne logike za obradu podataka: postaviti je (i koji dio) ili na server u obliku pohranjenih procedura, paketa, okidača, drugih ograničenja integriteta direktno na serveru baze podataka, ili u obliku funkcija na klijentu (u klijentskom softveru). Lokacija pravila interfejsa i pravila podataka je precizno određena: prva se uvek nalaze na klijentu, a druga na serveru. Pravila poslovne logike u modernim DBMS-ovima mogu se postaviti i na klijenta i na server. Pogledajmo jedan primjer jednostavnog poslovnog pravila:

• Vrijednost u polje za prikaz unosi korisnik, a ne bira sa liste, ali je skup važećih vrijednosti strogo ograničen (na primjer, dvije ili tri različite vrijednosti).

S jedne strane, korisnik zahtijeva trenutni odgovor sistema na grešku u unosu podataka, s druge strane, vrijednosti u polju baze podataka koje se razlikuju od navedenih (dvije ili tri) su neprihvatljive. U stvari, postoje dva pravila koja se moraju primijeniti u ovoj situaciji. Pravilo podataka u ovom slučaju će biti organizirano u obliku ograničenja provjere, a pravilo interfejsa koje zabranjuje unos vrijednosti osim navedenih će tačno ponoviti pravilo podataka, ali će se implementirati na razini korisničkog sučelja. Čini se da je implementacija forme sa listom u ovom slučaju idealno rješenje, ali većina operatora preferira tip u obrascu, posebno ako je dužina ulazne vrijednosti mala. Obrasce sa velikim brojem lista krajnjim korisnicima je prilično teško obraditi. U slučaju skupa vrijednosti u obrascu, također treba voditi računa o pretvaranju velikih ili malih znakova nizova znakova (gdje velika i mala slova nisu značajna) na nivou interfejsa aplikacijskog programa.

Predlošci

Korišćenje šablona i biblioteka za pravljenje „sličnih“ modula je prilično uobičajena praksa. Šta koristiti u ovom slučaju - objekte i klase ili biblioteke - odlučuje određena grupa programera. U većini slučajeva, diktiranje razvojne metode je besmisleno, jer programer piše kod onako kako zna ili je navikao. Ove trenutke obično kontroliše projektni menadžer.

U bilo kojem projektu kopiranje koda je zabranjeno, jer to dovodi do pojave različitih verzija istog koda u različitim fragmentima aplikacijskog programa i, kao rezultat, do grešaka koje je teško otkriti i ispraviti. Treba uspostaviti strogo pravilo: koristi se poziv funkcije, a ne njegova kopija u kodu; svako odstupanje od ovog pravila je kažnjivo.

Testiranje

Kao što je već spomenuto, grupe za testiranje mogu biti uključene već u ranim fazama razvoja projekta. Samo sveobuhvatno testiranje zaista treba odvojiti u posebnu razvojnu fazu. Ovisno o složenosti projekta, testiranje i ispravke grešaka mogu zauzeti trećinu, polovinu ili više vremena razvoja cijelog projekta.

Kako složeniji projekat, veća je potreba za automatizacijom sistema za skladištenje grešaka - praćenje grešaka. Takav sistem pruža sljedeće funkcije:

• pohranjivanje poruke o grešci (sa obaveznim informacijama o tome na koju komponentu sistema se greška odnosi, ko ju je pronašao, kako da je reproducira, ko je odgovoran za njeno ispravljanje i kada treba da bude ispravljena);
• sistem obavještavanja o pojavi novih grešaka, o promjenama u statusu poznatih grešaka u sistemu (po pravilu su to obavještenja putem e-maila);
• izvještaji o trenutnim greškama po komponentama sistema, vremenskim intervalima, razvojnim grupama i programerima;
• informacije o istoriji greške (uključujući praćenje sličnih grešaka, praćenje ponavljanja greške);
• pravila za pristup greškama određenih kategorija;
• interfejs ograničenog pristupa sistemu za praćenje grešaka za krajnjeg korisnika informacionog sistema, koji se koristi kao interfejs za razmenu informacija između korisnika i servisa tehnička podrška sistemima.

Ovakvi sistemi eliminišu mnoge organizacione probleme, posebno pitanje automatskog obaveštavanja o grešci.

Sami sistemski testovi mogu se podijeliti u nekoliko kategorija:

• testovi autonomnih modula - koriste se već u fazi razvoja komponenti sistema i omogućavaju vam da pratite greške pojedinačnih komponenti;
• testovi povezivanja komponenti sistema - koriste se iu fazi razvoja iu fazi testiranja i omogućavaju vam da pratite ispravnu interakciju i razmjenu informacija između komponenti sistema;
• test sistema je glavni kriterijum za prihvatanje sistema. U pravilu se radi o grupi testova koja uključuje autonomne testove, te testove povezivanja i modele. Ovaj test mora reproducirati rad svih komponenti i funkcija sistema, njegova glavna svrha je interno prihvatanje sistema i ocjena njegovog kvaliteta;
• prijemni test - koristi se prilikom predaje sistema kupcu. Ovdje programeri često snižavaju sistemske zahtjeve u odnosu na sistemski test i općenito je jasno zašto je to opravdano;
• Testovi performansi i opterećenja uključeni su u test sistema, ali su vredni posebnog pomena, jer je ova grupa testova glavna za procenu pouzdanosti sistema.

Testovi svake grupe nužno uključuju testove modeliranja neuspjeha. Ovdje se provjerava reakcija komponente, grupe komponenti ili sistema u cjelini na kvarove sljedećeg tipa:

• kvar posebne komponente informacionog sistema;
• kvar grupe komponenti informacionog sistema;
• kvar glavnih modula informacionog sistema;
• kvar operativnog sistema;
• “tvrdi” kvar (nestanak struje, kvar tvrdog diska).

Ovi testovi omogućavaju procjenu kvaliteta podsistema za vraćanje ispravnog stanja informacionog sistema i služe kao glavni izvor informacija za razvoj strategija za sprečavanje negativnih posljedica kvarova tokom industrijskog rada. Tipično, ovo je klasa testova koje programeri zanemaruju i onda se bore s posljedicama kvarova na proizvodnom sistemu.

Još jedna važna tačka programa testiranja informacionih sistema je dostupnost generatora testnih podataka. Koriste se za izvođenje testova funkcionalnosti sistema, testova pouzdanosti sistema i testova performansi sistema. Zadatak procene karakteristika zavisnosti performansi informacionog sistema od rasta obima obrađenih informacija ne može se rešiti bez generatora podataka.

Rad i održavanje

eksploatacija mučenja nadjačava proces testiranja. Po pravilu, sistem se ne pušta u potpunosti u rad, postepeno.

Puštanje u rad prolazi kroz najmanje tri faze:

akumulacija informacija;

dostizanje projektovanog kapaciteta.

Inicijalno učitavanje informacija pokreće prilično uzak raspon grešaka – uglavnom su to problemi neusklađenosti podataka tokom učitavanja i vlastite greške učitavača, odnosno ono što nije praćeno u podacima testa. Takve greške se moraju ispraviti što je prije moguće. Nemojte biti lijeni da instalirate verziju sistema za otklanjanje grešaka (ako vam je, naravno, dozvoljeno da primenite čitav kompleks softvera koji prati otklanjanje grešaka u informacionom sistemu na licu mesta). Ako je nemoguće otkloniti greške „na živim“ podacima, morat ćete simulirati situaciju i to brzo. Za to su potrebni vrlo kvalifikovani testeri.

U periodu akumulacije informacija pojaviće se najveći broj grešaka napravljenih prilikom kreiranja informacionog sistema. U pravilu se radi o greškama koje se odnose na višekorisnički pristup. Često se u fazi testiranja takvim greškama ne pridaje odgovarajuća pažnja - očito zbog složenosti modeliranja i visoke cijene alata za automatizaciju procesa testiranje informacioni sistem u uslovima višekorisničkog pristupa. Neke greške će biti prilično teško ispraviti jer su greške u dizajnu. Ni jedan dobar projekat nije imun na njih. To znači da za svaki slučaj trebate rezervirati vrijeme za lokalizaciju i ispravljanje takvih grešaka.

Tokom perioda gomilanja informacija, možete naići na čuveno „baza je pala“. U najgorem slučaju ispada da DBMS ne može izdržati protok informacija. Ako je dobro, konfiguracijski parametri su jednostavno netačni. Prvi slučaj je opasan, jer je prilično teško utjecati na proizvođača DBMS-a, a korisniku se zaista ne sviđaju linkovi ka službi tehničke podrške DBMS-a. Nije proizvođač taj koji će morati da rešava problem kvara DBMS-a, već vi - promenite šemu, smanjite protok zahteva, promenite same zahteve; općenito - postoji mnogo opcija. Dobro je ako se osnovno vrijeme oporavka uklapa u planirano.

Dostizanje projektnog kapaciteta sistema pod uspješnom kombinacijom okolnosti znači ispravljanje niza manjih grešaka, a povremeno i ozbiljnih grešaka.

Drugi pristupi razvoju aplikacija

Tipično, krajnji korisnici i menadžment vjeruju da proces dizajna nije dao rezultate jer ne postoje gotove komponente koje bi se „dodirale“. Često kupac insistira na tome da se faza implementacije projekta izvrši prije roka kako bi se dobio neki rezultat i pokazao što je prije moguće. U ovom slučaju, vrlo je primamljivo odabrati ubrzani razvoj aplikacija (AAD) ili kolaborativni razvoj aplikacija (CAD). Takve metode uključuju razvoj radnog prototipa, a zatim ga demonstrirati korisnicima. Korisnici komentarišu šta im se sviđa, a šta ne. Dizajner usavršava prototip uzimajući u obzir date komentare, a zatim ponovo demonstrira šta se dogodilo. I tako dalje. Proces se ponavlja sve dok se korisnicima ne dopadne ono što vide i prototip ne postane funkcionalna aplikacija. Obično postoji vremensko ograničenje i broj iteracija, inače će korisnici zauvijek poboljšavati prototip. U teoriji, ovo vam omogućava da dobijete sistem koji je potreban korisnicima. U praksi, ovakav pristup razvoju aplikacija predstavlja ozbiljne probleme.

• Sva pažnja je usmerena na ekranske forme, a ono što se tiče pravila obrade podataka i funkcija sistema ostaje iza kulisa. Postoji iskušenje da se počne raditi sa izvještajima, dok izvještaj nije početni proizvod, već derivat informacionog sistema.
• Korisnici pretpostavljaju da ako je prototip verzija dogovorena, onda je modul spreman. Zapravo, ovo može biti samo slika sa skupom „stubova“ za pozivanje sistemskih funkcija i interakciju s drugim modulima.
• Moduli su dizajnirani izolovano jedan od drugog (većina od vas se vjerovatno susrela sa računovodstvenim programima u kojima je svaka radna stanica autonomna i funkcije se često dupliciraju). Posljedica ovoga su kontradikcije između modula, dupliciranje funkcija i podataka, što se može identificirati samo testiranjem skupa modula.
• Funkcionalnost se širi paralelno u nekoliko pravaca, što znači da struktura baze podataka mora biti strogo kontrolisana. Sa DRM-om, shema baze podataka pretvara se u deponiju gdje se tabele na brzinu skupljaju, što rezultira skupom kontradiktornih i duplih podataka.
• Dokumentacija pri korištenju URP metode u pravilu izostaje, odnosno zaboravlja se potreba za dokumentovanjem sistema, jer se stvara iluzija da korisnik već razumije šta se dešava. Kada aplikacija počne da radi drugačije nego što korisnik očekuje, nastaje mnogo problema.
• Izuzetne situacije se rješavaju različito za svaki modul.
• Kompletan sistem, po pravilu, ne funkcioniše, najverovatnije će to biti određeni skup automatizovanih radnih stanica, na brzinu međusobno povezanih.

URP i SRP metode se ne mogu uvijek koristiti, već samo ako:

• Obim projekta i poslovni zahtevi su jasno definisani, ne menjaju se, a sam projekat je mali;
• projekat ne zavisi od drugih alata za automatizaciju poslovanja, broj eksternih interfejsa koji će morati da se obrađuju je ograničen;
• sistem je fokusiran na ekranske forme, obrada podataka i sistemske funkcije čine beznačajan deo, pogodnost ekranskih formi je jedan od pet najvažnijih faktora za uspeh projekta;
• korisnici su visoko kvalificirani i a priori pozitivno ocjenjuju ideju ​​kreiranja novog softvera.

Ipak, bolje je razviti male i, po mogućnosti, autonomne dijelove projekta korištenjem URP metode.

Trenutno je učinjen pokušaj da se uvede još jedan način za brzo pisanje projekta - metod ekstremnog programiranja. Principi ovog pristupa će biti razmotreni u nastavku.

Igra planiranja. Na osnovu procjena programera, korisnik određuje funkcionalnost i period implementacije verzija sistema. Programeri implementiraju samo one karakteristike koje su neophodne za funkcije odabrane u datoj iteraciji.

Kao rezultat ove odluke, razvoj sistema ostaje „iza kulisa“, zbog čega tokom razvoja postoji potreba za izgradnjom „stubova“ i prepisivanjem koda. Nije jasno zašto rok za realizaciju određuje naručilac, jer je to u stvari direktna odgovornost projektantskog tima. Naručilac, generalno govoreći, može samo izraziti svoje želje u pogledu rokova („Želim do tog i tog datuma“), ali samo projektant može odrediti rok („to se može uraditi ni manje ni više od tog i tog datuma“). vrijeme”).

Česte promjene verzija (mala izdanja). Sistem se pušta u rad u roku od nekoliko mjeseci nakon početka implementacije, bez čekanja na konačno rješavanje svih nastalih problema. Nove verzije se mogu objavljivati ​​u intervalima od dnevnih do mjesečnih.

Sve je dobro, osim jedne stvari: nemoguće je testirati manje ili više složenu komponentu u takvom periodu. Kupac se zapravo ponaša kao beta tester. U ovom slučaju može vidjeti da programeri naporno rade, pa čak i da popravljaju greške. Međutim, postavljaju se razumna pitanja: isplati li se kupca uvoditi u proces rada i da li je potrebno provoditi eksperimente na radni sistem? Pored navedenog, treba napomenuti da je malo vjerovatno da će takav princip biti implementiran za dijelove projekta koji zahtijevaju rad 24x7.

Metafora. Ukupni izgled sistema određuje se korištenjem metafore ili skupa metafora na kojima klijent i programeri rade zajedno.

S jedne strane, ovaj postulat izgleda prilično dobar, ali s druge strane, ima li smisla inicirati kupca u unutrašnje poslove razvojne grupe? Ono što se tiče opšteg izgleda (sučelja, izveštaji, itd.) može zaista biti u nadležnosti kupca, ali kada mi pričamo o tome o specifičnostima implementacije pojedinih komponenti, kupac teško može biti od koristi zbog nedostatka potrebnih znanja.

Jednostavan dizajn. U svakom trenutku, razvijeni sistem obavlja sve testove i podržava sve relacije definisane od strane programera, nema duplikate koda i sadrži minimalni mogući broj klasa i metoda. Ovo pravilo se može ukratko izraziti na sljedeći način: “Svaku misao formulirajte jednom i samo jednom.”

Ova ideja je također dobra, ali se ne uklapa baš u princip brzog pisanja koda. Možda bi trebalo prvo razmisliti kako napraviti ovaj ili onaj modul, grupu modula, pa tek onda početi pisati kod?

Testovi. Programeri stalno pišu jedinične testove. Uzeti zajedno, ovi testovi bi trebali raditi ispravno. Za faze u iteraciji, kupci pišu funkcionalne testove, koji takođe moraju ispravno raditi. Međutim, u praksi to nije uvijek moguće postići. Da biste doneli ispravnu odluku, potrebno je da shvatite koliko će koštati isporuka sistema sa poznatim defektom i uporediti to sa cenom odlaganja ispravke kvara.

Kada testove pišu sami programeri (posebno kada rade prekovremeno), ovi testovi nisu u potpunosti funkcionalni, a svakako ne uzimaju u obzir posebnosti višekorisničkog rada. Programeri obično nemaju dovoljno vremena za naprednije testove. Možete, naravno, izgraditi razvojni sistem tako da će isti ljudi sve rješavati, ali ipak ne biste trebali pretvarati projekat u analognu TV emisiju „Vaš vlastiti direktor“. Na navedeno je potrebno dodati da testiranje sistema nije ograničeno na testiranje komponenti (jedinica); Testovi interakcije između njih nisu ništa manje važni, a isto važi i za testove pouzdanosti. Ipak, metod ekstremnog programiranja ne omogućava kreiranje testova ove klase. Ovo se objašnjava činjenicom da takvi testovi sami po sebi mogu predstavljati prilično složen kod (ovo posebno važi za testove koji simuliraju stvarni rad sistema). Ova tehnologija takođe ne uzima u obzir još jednu važnu klasu testova - testove ponašanja sistema kada se povećava obim obrađenih informacija. Pri visokoj stopi promjena verzija, tehnološki je nemoguće izvesti takav test, jer njegova implementacija zahtijeva stabilan i nepromijenjen kod projekta, na primjer, u roku od tjedan dana. Ovakvi rokovi, generalno govoreći, nisu zagarantovani zbog česte promjene verzije. U tom slučaju ćete morati ili obustaviti razvoj komponenti, ili kreirati paralelnu verziju projekta tokom testa, koja će ostati nepromijenjena, dok će se druga promijeniti. Zatim ćete morati izvršiti proces spajanja koda. Ali u ovom slučaju, test će se morati ponovo kreirati, jer ekstremne metode programiranja jednostavno ne predviđaju razvoj alata koji omogućavaju predviđanje ponašanja sistema pod određenim promjenama.

Refaktoring sistema. Arhitektura sistema se stalno razvija. Trenutni projekat se transformiše, uz osiguranje da se svi testovi izvode ispravno.

Ovdje zabava počinje. Ekstremno programiranje se zasniva na premisi da je uvijek moguće ponoviti, i to bez velikih troškova. Međutim, praksa pokazuje suprotno.

Programiranje u paru. Čitav kod projekta pišu dvije osobe koje koriste isti desktop sistem.

Postavlja se pitanje: da li je neko video dva potpuno identična programera, od kojih bi svaki na kraju radnog dana imao vremena da napiše dokumentaciju za svog partnera? Da li je moguće naći programere blizance koji se u svemu slažu?

I što je najvažnije, zašto nam treba takav par programera? Razlog je, generalno, jednostavan: ne može svako da izdrži visok tempo rada koji nameće ekstremno programiranje, a odliv osoblja je neizbežan. Takav par može pružiti neku vrstu osiguranja - ako jedan odustane, možda će drugi doživjeti posao do kraja. Istina, preostali će pasti u još kraćem vremenskom okviru - na kraju krajeva, količina posla će ostati ista, a sigurnosne kopije neće biti, barem neko vrijeme. Ono što slijedi je prirodan proces prenošenja informacija novom studentu, za koji opet treba vremena. I tako u nedogled.

Kontinuirana integracija. Novi kod se integriše u postojeći sistem u roku od nekoliko sati. Nakon toga, sistem se ponovo sastavlja u jedinstvenu cjelinu i izvode se svi testovi. Ako se barem jedan od njih ne izvrši ispravno, izvršene promjene se poništavaju.

Ovaj postulat je u najmanju ruku kontroverzan, jer nije jasno ko će ispraviti greške, ne samo lokalne, već i inducirano pogrešan kod. Uostalom, ne očekuje se da se u ovoj fazi provode složeni testovi; osim toga, promjene ostaju čak i ako se otkrije greška. U isto vrijeme, metoda ekstremnog programiranja ne obezbjeđuje sistem praćenja grešaka.

Kolektivno vlasništvo. Svaki programer ima priliku da poboljša bilo koji dio koda u sistemu u bilo koje vrijeme ako smatra da je to potrebno.

Zar vas ovo ne podsjeća na anarhiju? Kako pronaći autora izmjena u ovom slučaju? Da li se iko ikada susreo sa takvim „majstorom“ tokom razvoja velikog projekta i koliko bi takav „majstor“ mogao da izdrži na svom poslu? Tako je, ne predugo.

Kupac na licu mesta. Kupac koji je u razvojnom timu tokom perioda rada na sistemu.

Ovo je, naravno, dobro, ali cilj je nejasan: ili da se kupac rasvijetli u suštinu stvari, ili da on postane koautor? Malo je vjerovatno da će samo kupac imati tako visoko kvalificiranog stručnjaka.

40-satne sedmice. Obim prekovremenog rada ne može biti duži od jedne radne sedmice. Čak i izolovani slučajevi prekovremenog rada, koji se prečesto ponavljaju, znak su ozbiljnih problema koji zahtevaju hitnu pažnju.

Kao što pokazuje praksa korišćenja ekstremnog programiranja (uprkos brojnim pozitivnim primerima koje navode pristalice ove metode), prekovremeni rad kod ovakvog pristupa je pravilo, a ne izuzetak, a borba protiv problema u ovom slučaju je stalna pojava. Pojačava se u periodu zamjene trenutne sirove verzije proizvoda drugom, opet sirovom, verzijom. Kupac, iniciran u proces, doživljava sve užitke ispoljavanja sistemskih grešaka na sebi. Šta mislite, koliko dugo će kupac imati dovoljno strpljenja u ovakvom stanju stvari? Potreban mu je sistem da radi...

Otvoreni radni prostor. Razvojni tim je smješten u velikoj prostoriji okruženoj manjim prostorijama. U centru radnog prostora instalirani su računari na kojima rade parovi programera.

Štaviše, sve ovo, sudeći po prethodnim principima, trebalo bi da se nalazi na teritoriji kupca, budući da je on veoma aktivno uključen u proces razvoja. Postavlja se pitanje: da li je takva srećna slučajnost stvarna?

Ništa više od pravila. Članovi tima koji rade na tehnologiji ekstremnog programiranja obavezuju se da će se pridržavati navedenih pravila. Međutim, ovo nisu ništa drugo do pravila i tim ih može promijeniti u bilo kojem trenutku ako su njegovi članovi postigli načelni dogovor u vezi sa učinjenim promjenama.

Možda će se na kraju razviti jedno korisno pravilo: „prvo razmisli, pa uradi“. U ovom slučaju, imat ćemo uzorak vrlo sličan "vodopadu". Iz nekog razloga, pristalice ekstremnog programiranja su uvjerene da kada se koristi "vodopad" i njegovi klonovi, razvojni ciklus mora biti dug. Nije jasno šta uzrokuje takvo povjerenje. Uostalom, nije zabranjeno podijeliti projekat na faze. Iz nekog razloga, vjeruje se da će planiranje nužno biti jednokratno i nepromjenjivo, iako to zapravo nije istina, uključujući i u slučaju „vodopada“.

Kao rezultat, dobijamo metodu koja je potencijalno vrlo prilagodljiva zahtjevima projekta koja se jako mijenja, ali u isto vrijeme nije oslobođena niza ozbiljnih nedostataka. Posljednja okolnost nam ne dozvoljava da preporučimo ovu metodu za upotrebu u projektima koji zahtijevaju visoku ili barem dovoljnu pouzdanost rada.

ComputerPress 2"2002

Nema ništa teže, opasnije i neizvjesnije od vođenja uvođenja novog poretka stvari, jer svaka inovacija ima vatrene neprijatelje koji su dobro živjeli pod starim, i trome pristaše koji nisu sigurni da li mogu živjeti pod novim.
N. Machiavelli

I sada se zanimljiv i pun kreativnosti, projekcije, kreativnosti i kreacije dio projekta bliži kraju. Počinju strogosti odbrane vaše odluke u pravoj atmosferi konkretno preduzeće, a što je takođe važno, sve je takođe u okvirima važećeg zakonodavstva.

Početi prodati proizvod mora biti raspoređeno na opremi pripremljenoj za organizovanje probnog rada.

1. Postavljanje sistema na mjestu pilot operacije

U skladu sa projektovanom tehnološkom arhitekturom koja se ogleda u dokumentaciji, vrši se nabavka serverske, komunikacione i druge opreme, kao i sistemskog softvera. Komponente informacionog sistema se sklapaju u jedinstven hardversko-softverski kompleks na lokacijama na kojima se planira njegova industrijska upotreba.

Zbog činjenice da u velikih projekata, uključena je velika količina opreme na kojoj je softver razbacan po čvorovima, čvorovima, pa čak i oblacima, tada ovaj proces mora biti popraćen kompletnom dokumentacijom. Na primjer, tehnička dokumentacija uključuje tabele sa adresama servera, radnih stanica, metodama pristupa itd. Za vizualno predstavljanje koriste se dijagrami komponenti koji daju razumijevanje lokacije mrežnih čvorova, distribucije komponenti njihove interakcije itd. Ali još uvijek se moraju odrediti mjere za regulisanje svih vrsta promjena u infrastrukturi, omogućavajući eliminaciju posljedica kvarova različitih elemenata sistema.

Slika 19. – Primjer tehničkog opisa faze implementacije

Ovo je sve izuzetno važno, jer će sljedeća faza na ovim operativnim lokacijama početi potiskivati ​​mnoge stručnjake iz tima za implementaciju i podršku, koji ne bi trebali svaki put izvlačiti informacije potrebne za rad iz različitih, čak i informiranih izvora. Stoga se dokumentacija mora ažurirati i mijenjati istovremeno sa promjenama postavki sistema, promjenama arhitektonsko rješenje i tako dalje.

Korisno je postaviti ispitne stolove na "borbenim" mjestima za industrijski rad sistema, simulirajući rad blizak stvarnom životu. Pa, odjednom će biti komentara koji zahtijevaju objavljivanje novih izdanja. Naravno, svi su profesionalci, odgovorni ljudi i sve to, ali ipak je bolje prvo pokrenuti ažuriranja na probnom stolu. Samo u slučaju.

U međuvremenu, 90% vremena je već prošlo...

2. Obuka osoblja korisnika za rad sa informacionim sistemom

Kao što je već nekoliko puta pomenuto, u velikim projektima posebna pažnja se poklanja kvalitetu dokumentacije, uključujući i uputstva za korisnike sistema. Najčešće se korisnička uputstva dijele na segmente prema vrsti aktivnosti, specijalizaciji itd. Ovo vam omogućava da pažnju u dokumentu usmerite na važne tačke i ne opterećujete korisnike nepotrebnim informacijama.

Budući da u obuku može biti uključen značajan broj različitih zaposlenika kupaca, koji se, pak, da bi se osigurao kontinuitet poslovnih procesa ne mogu istovremeno obučavati, koji moraju biti obučeni u različitim funkcionalne odgovornosti i druge stvari dobri razlozi, potrebno je pažljivo planirati proces obuke kadrova. Također je korisno podijeliti učenike u grupe prema kategorijama koje zahtijevaju upotrebu različiti pristupi i dubinu obuke, na osnovu nivoa njihove početne pripremljenosti. Kao rezultat toga, sastavljeni raspored obuke mora biti dogovoren sa svima zainteresovane strane, i odobreno od strane menadžmenta korisnika kao obavezno.

I upozorili smo u fazi projektovanja da obuka osoblja kupaca nije samo veoma važan zadatak, već i veoma radno intenzivan...

3. Identifikacija nedostataka i nedostataka informacionog sistema

Vrlo često u velikim projektima testiranje konačnog izdanja ne dozvoljava nam da identifikujemo sva problematična područja rješenja. Razlog tome može biti: ogromne količine podataka u stvarnim borbenim uslovima, ispoljavanje jedinstvenih kombinacija poslovnih pravila u stvarnim poslovnim procesima, karakteristike rada specifične opreme, specifične kombinacije komponenti sistema, balansiranje opterećenja između distribuiranih čvorova itd.

Često se situacija dodatno komplikuje činjenicom da uvođenje novih sistema u početnim fazama ni na koji način ne eliminiše potrebu za izvođenjem radova na starim sistemima. To jest, korisnici dupliraju podatke u oba sistema. Ponekad je postojeće, ažurne podatke potrebno migrirati iz naslijeđenih skladišta u nove, a struktura i format informacija obično su vrlo, vrlo različiti. Na primjer, ako nova struktura podataka nema dovoljno informacija za popunjavanje potrebnih detalja, oni se popunjavaju nekim podacima koji su dodijeljeni „podrazumevano“, a zatim ih korisnici ručno prilagođavaju. A ovo je samo mali dio onoga što susrećemo u stvarnim projektima.

Posebna tema su integracijska rješenja, u kojima se kvarovi mogu pojaviti u lancu korištenjem različitih komponenti koje razvijaju dva, tri ili više tima. Pronaći krivce u ovoj situaciji je izuzetno teško, jer defekti najčešće nastaju na spoju integracionih elemenata, zbog nekonzistentnosti uočenih tokom implementacije. I ovdje je važno ne tražiti odgovorne za kažnjavanje, već brzo i konstruktivno dogovoriti zajedničke ustupke programera povezanih komponenti i efikasno riješiti problem.

Uzimajući u obzir sve navedeno, faza probnog rada najčešće je puna emocionalnih izliva i međusobnih potraživanja, kako između razvojnih timova, tako i sa kupcima. U ovom slučaju je veoma važna uloga arhitekata i sistemskih analitičara, koji moraju brzo lokalizovati problem, predložiti rešenje i usaglasiti ga sa svim zainteresovanim stranama. Za obavljanje takvog posla, pored osnovnih profesionalnih vještina, potrebno je posjedovati i talenat pregovarača i poznavanje osnova menadžmenta.

U međuvremenu, stigli smo do dna vremena predviđenog za projekat...

4. Koordinacija promjena tokom implementacije informacionog sistema

Ukoliko rad nekih funkcionalnih modula informacionog sistema kritično ne zadovoljava potrebe i očekivanja korisnika, te se pronađu rješenja za prevazilaženje ovih problema, oni se moraju evidentirati i usaglasiti sa korisnikom.

Faza dogovaranja novog rješenja vrlo je važna iz najmanje dva razloga.

Prvo, ako obim implementacije izmjena premašuje iznose koji su namijenjeni slični rizici u smislu projekta potrebno je ili sklopiti dodatne ugovore, ili će tim izvođača raditi s gubitkom. Često se izvođači pozivaju da brzo izvrše izmjene, ali kažu da ćemo ih uzeti u obzir i platiti naknadno, u jednom paketu. Ali u stvari, takvi slučajevi obično dovode do toga da kupac tada potpuno zaboravi svoja obećanja, a završeni posao proglašava ispravkom vlastitih grešaka od strane izvođača.

Drugo, bilo kakve promjene nekih komponenti sistema mogu povlačiti za sobom neizbježnu promjenu međuzavisnih komponenti, što zahtijeva pažljivu analizu i, eventualno, redizajn čitavog lanca podsistema. U suprotnom, pojava kvarova u radu sistema u celini je neizbežna. To se može manifestirati, na primjer, u kvaru modula susjednog tima izvođača, a kupac ih već proglašava hakerima i prebjegima. Istina će, naravno, izaći na vidjelo, ali opsada će ostati.

I da parafraziramo Jerzyja Leca: "Kada smo stigli do dna predviđenog vremena, začulo se kucanje odozdo..."

Pošto je vrijeme isteklo, potrebno je pregovarati sa kupcem i uvjeriti ga da ni on nije bio poklon u projektu, a dio krivice je i na njemu.

5. Dopuna informacionog sistema na osnovu rezultata probnog rada

Ako se tokom probnog rada donesu i dogovore odluke o izmenama u razvijenom softversko-hardverskom kompleksu, onda se na osnovu njih dodeljuju zadaci izvođačima za njihovu implementaciju. Ponavlja se proces opisan u dijelu Dio 3. Implementacija projektnog rješenja. Ali…

Ako smo u fazi projektovanja sistema razgovarali o negativnom uticaju pune upotrebe Scrum metodologije (1) u velikim projektima, onda je u ovoj fazi ona savršeno prikladna. To je posebno vidljivo u projektima u kojima proizvod koji se prenosi na kupca ga u većini aspekata ne zadovoljava. Drugim riječima, vrijeme je da se prepustite panici i vrlo brzo, bezglavo, izvršite promjene na proizvodu koji je već u upotrebi.

U stvari, došao je trenutak kada su relevantni sljedeći uslovi:

1. Kupac je već počeo da radi sa sistemom, ima vremena za to i sada jasno razume šta mu je zaista potrebno. Shodno tome, spreman je da blisko sarađuje sa timom izvođača i za tim ima kritičnu potrebu;
2. Uglavnom, dokumentacija je već gotova i njene izmjene i dopune se više ne mogu vršiti tako brzo, već se sastavljaju naknadno na osnovu rezultata uspješne implementacije.
3. Poboljšanja se najvećim dijelom dešavaju u pojedinačnim modulima, podsistemima, kolima, koji imaju specifičan tim izvođača koji je odgovoran za segment. Stoga je komunikacija između korisnika i programera već lokalizirana, lako je uspostaviti visokokvalitetne povratne informacije;
4. Poboljšanja i korekcije se moraju izvršiti vrlo brzo, u malim naletima, a rezultat se prenosi na kupca koji je za njih vitalno zainteresovan;

Vrlo je važno da se na kraju projektna dokumentacija dovede u potpunu usklađenost sa inovacijama, a tim u njoj lako pronađe relevantno rješenje za analizu i projektovanje narednih promjena.

Slika 20. – Faza implementacije informacionog sistema

Bez komentara…

6. Prelazak informacionog sistema u komercijalni rad

Kada se tokom probnog rada riješe sva sporna pitanja i nesporazumi o tome kako implementirani sistem treba da funkcioniše i u kojoj mjeri je usklađen sa ugovorom o njegovom razvoju, strane potpisuju akte o izvršenju ugovora. Kupac plaća u potpunosti izvršene radove. Ugovor za izradu i implementaciju informacionog sistema može se smatrati završenim.

Implementacija prelazi u fazu industrijskog rada. Ovi odnosi se najčešće pravno uređuju posebnim ugovorom ili dodatni dogovor za podršku industrijskom radu sistema. U okviru ovog ugovora mogu se obavljati preventivni radovi na dijagnostici rada komponenti sistema, njihove interakcije, otklanjanju manjih kvarova itd.

7. Sažetak odjeljka

Faza implementacije informacionog sistema predstavlja trenutak istine cjelokupnog procesa njegove proizvodnje i označit će početak najtežeg perioda za sve učesnike projekta. Može uključivati ​​sljedeće aktivnosti:

1. Postavljanje sistema na lokaciji industrijske operacije, uključujući nabavku opreme, instalaciju sistemskog softvera, instalaciju trenutnog izdanja sistema koji se implementira, itd.;
2. Obuka korisnika za rad sa sistemom, uključujući administratore, stručnjake za održavanje opreme itd.
3. Identifikacija i otklanjanje nedostataka i nedostataka uočenih tokom probnog rada.
4. Koordinacija promjena u radu sistema i njegovo usklađivanje sa ugovornim obavezama;
5. Potpisivanje dokumenata o ispunjenju ugovornih obaveza. Plaćanje u potpunosti izvršenih radova;
6. Stavljanje sistema u komercijalni rad;

Implementacija korporativne IP, razvijene samostalno ili kupljene od dobavljača, često je praćena poremećajem (redizajniranjem) postojećih poslovnih procesa u preduzeću. Moramo ih ponovo izgraditi kako bi ispunili zahtjeve standarda i logiku sistema koji se implementira. Odmah da napomenemo da uvođenje informacionih sistema rješava niz menadžerskih i tehničkih problema, ali dovodi do problema povezanih s ljudskim faktorom.

Implementacija informacionog sistema, po pravilu, u velikoj meri olakšava upravljanje aktivnostima preduzeća, optimizuje interne i eksterne tokove informacija i eliminiše uska grla u upravljanju. Međutim, nakon što je sistem uspješno instaliran, “testiran” u radu i pokazao se djelotvornim, neki zaposleni pokazuju nespremnost da koriste IS u svom radu. Kao rezultat reinženjeringa, postaje jasno da neki zaposleni u velikoj mjeri dupliraju rad drugih ili uopće nisu potrebni. Osim toga, implementaciju CIS-a prati obavezna obuka, ali, kao što je prikazano Rusko iskustvo Nema mnogo ljudi voljnih da se prekvalifikuju. Razbijanje starih vještina i usađivanje novih je dug i težak proces!

Mora se jasno shvatiti da je korporativna intelektualna svojina dizajnirana da pojednostavi upravljanje organizacijom, poboljša procese, ojača kontrolu i na taj način obezbedi konkurentske prednosti. Samo sa ove tačke gledišta mogu se procijeniti koristi od njegove implementacije.

Slijedeći ovu logiku, postaje jasno da iako je korporativni IS općenito namijenjen da svim korisnicima pruži potrebne informacije, upravljanje razvojem i implementacijom CIS-a je prerogativ najvišeg menadžmenta kompanije! Razumiju li ovo lideri?

I ovdje se moramo boriti protiv upornih stereotipa. „Zašto mi treba korporativni sistem ako stvari u preduzeću već idu dobro?“ „Zašto lomiti nešto ako sve radi?“ Ali najčešće nema potrebe da ga razbijete. U prvoj fazi, potrebno je samo kompetentno i korektno formalizirati i prenijeti identificirane procese u kojima preduzeće živi u korporativni IS. Takva formalizacija će samo izoštriti i poboljšati uspješne marketinške i proizvodne ideje, optimizirati proces upravljanja i kontrole i omogućiti ciljane promjene u budućnosti.

Uvođenje novog IS-a - težak proces, u trajanju od nekoliko mjeseci za male IS do nekoliko godina za IS velikih distribuiranih kompanija sa širokim spektrom proizvoda i velikim brojem dobavljača. Uspeh projekta za razvoj (ili nabavku) i implementaciju informacionog sistema u velikoj meri zavisi od spremnosti preduzeća da sprovede projekat, ličnog interesa i volje menadžmenta, realnog programa delovanja, dostupnosti resursa, obučenog osoblja, i sposobnost savladavanja otpora na svim nivoima uspostavljene organizacije.

Do sada se pojavio standardni set tehnika za uvođenje informacionih sistema. Osnovno pravilo je da se tražene faze dovršavaju uzastopno i da se nijedna od njih ne preskače.

Sljedeći faktori su kritični za implementaciju:

· prisustvo jasno formulisanih ciljeva projekta i zahtjeva IP;

· dostupnost strategije za implementaciju i korištenje IP;

· sprovođenje pred-projektne ankete preduzeća i modela izgradnje „Kakav je“ i „Kakav će biti“;

· planiranje rada, sredstava i praćenje realizacije plana implementacije;

· učešće višeg menadžmenta u implementaciji sistema;

· obavljanje poslova na implementaciji IS-a od strane stručnjaka za sistemske integracije zajedno sa stručnjacima preduzeća;

· redovno praćenje kvaliteta obavljenog posla;

· brzo postizanje pozitivnih rezultata barem u dijelu implementiranih IS modula ili tokom probnog rada.

Prije nego počnete razvijati projekt implementacije, morate:

· formalizirati ciljeve projekta implementacije IS što je više moguće;

· procijeniti minimalno neophodni troškovi i stavke troškova;

· postaviti visok prioritet za projekat implementacije u odnosu na druge projekte koji su u toku;

· dati menadžeru projekta najveća moguća ovlaštenja;

· sprovoditi masovni edukativni rad sa osobljem preduzeća kako bi se svima prenela važnost i neophodnost predstojećih transformacija;

· razviti organizacione mjere za korištenje novih informacionih tehnologija;

· distribuirati ličnu odgovornost u svim fazama implementacije i probnog rada.

Takođe je potrebno utvrditi funkcionalne oblasti implementacija modula informacionog sistema:

· organizacioni menadžment;

· organizaciona i administrativna podrška;

· upravljanje poslovnim procesima;

· upravljanje, planiranje, finansije i računovodstvo;

· upravljanje osobljem;

· upravljanje dokumentima;

· upravljanje logistikom;

· upravljanje odnosima sa klijentima i eksternim okruženjem.

Pored gore navedenog, potrebno je postaviti i tehnološke zahtjeve za implementaciju IS-a:

· sistemska platforma - implementacija i adaptacija gotovo rešenje od proizvođača ili prilagođeni razvoj u skladu sa tehničkim specifikacijama kupca;

· integrabilnost – podaci se pohranjuju i obrađuju u jedinstvenom informacionom prostoru; to osigurava njihovu potpunost, dosljednost, pouzdanost i ponovnu upotrebu; sistem može uključivati ​​novorazvijene i već korištene tehnologije i aplikacije;

· prilagodljivost – sistem je konfigurisan u skladu sa zahtevima korisnika i karakteristikama informacionog polja korisnika;

· distribuiran – sistem može efikasno funkcionisati u geografski udaljenim odeljenjima i filijalama preduzeća;

· skalabilnost - sistem se može implementirati u obliku okvira koji sadrži osnovne module i proširivati ​​u skladu sa zahtjevima promjenjivog vanjskog i unutrašnjeg okruženja.

Glavne faze implementacije informacionog sistema

Faza "Preliminarni rad na pripremi projekta implementacije IS." Tokom pretprojektne ankete preduzeća prikupljaju se detaljne informacije o strukturnoj strukturi organizacije, funkcionalnim odnosima, sistemu upravljanja, glavnim poslovnim procesima, tokovima unutar preduzeća (Control Flow, Doc Flow, Data Flow, Work Flow, Cash Protok), neophodnih za izradu odgovarajućih modela i izbor objekata za automatizaciju. Procjenjuju se vrijeme, resursi, vrste i obim posla, obim i cijena softvera, hardvera i telekomunikacija, troškovi obuke osoblja itd.

Faza "Priprema projekta". Nakon završetka prve faze, vrši se prethodno planiranje i formiranje procedura pokretanja projekta:

· formiranje projektnih i stručnih grupa;

· raspodjela ovlasti i odgovornosti;

· utvrđivanje organizacionih i tehničkih uslova za proces implementacije;

· pojašnjenje specifikacija i očekivanja kupaca;

· obuka grupe za implementaciju koju čine stručnjaci iz preduzeća korisnika.

Iz nekog razloga, posljednja, vrlo važna tačka se često propušta prilikom izrade plana implementacije. Ali uspjeh cijelog projekta uvelike ovisi o tome! Nakon početka finansiranja, projekat se smatra pokrenutim.

Faza "Idejna izrada projekta". Tokom ove faze:

· formira se i odobrava idejni projekat;

· postiže se obavezno nedvosmisleno razumijevanje namjera svih učesnika u projektu u vezi sa implementiranim IS;

· ciljevi i zadaci projekta su pojašnjeni i specificirani;

· određuju se dimenzije prototipa sistema;

· dogovara se prošireni plan rada, redoslijed faza i uvjeti probnog rada, planiranje, finansijski i izvještajni pokazatelji;

U ovom slučaju, sve navedene radnje u obavezno su dokumentovani, dogovoreni i odobreni od strane svih zainteresovanih i odgovornih strana.

Faza "Implementacija projekta". Tokom glavnog implementacionog rada kreira se, instalira i konfiguriše sistemsko okruženje, određuju se procedure administracije sistema i instaliraju osnovni hardverski i softverski sistemi i aplikacije. Sistem konfiguriše organizacione, kadrovske i organizaciono-funkcionalne strukture preduzeća koristeći takve organizacione jedinice kao što su filijala, odeljenje, odeljenje, radna grupa itd.

Izvodi se instalacija, konfiguracija i podešavanje mrežnih i telekomunikacionih alata, prenos podataka sa prethodnih lokalni sistemi i formiranje interfejsa sa starim i eksternim sistemima. Istovremeno, svi kreirani modeli, planovi, radni softverski proizvodi i dokumentacija se stavljaju u end-to-end repozitorijum projekta implementacije (slika 3). Važan dio ovog spremišta je dokumentacijski sistem generiran u okviru projekta (slika 4).

Razrađuju se sistemska sigurnosna pitanja rada sistema u višekorisničkom režimu. Kreiraju se aplikacije, šabloni, izvještaji, obrasci za pristup klijentima, a korisnička prava se distribuiraju. Svi sistemi se testiraju u "borbenom režimu" uz učešće svih zainteresovanih strana.

Nakon završetka faze implementacije, projekat implementacije se smatra završenim. Informacioni sistem je pušten u rad.

7. Faktori uspjeha i razlozi za neuspješne implementacije IS-a

modeliranje poslovanja informacionog reinženjeringa

Prema svjetskim statistikama, samo trećina projekata razvoja i implementacije informacionih sistema je uspješna. U Rusiji se ništa ne zna o sličnim studijama, ali se čini da je kod nas još gore.

Uspješan projekat je završen na vrijeme, u okviru budžeta i postiže željene rezultate. Šta se dešava sa ostalim projektima? Oni se ili vuku mnogo duže nego što se očekivalo, zahtijevajući sve više sredstava, ili se stvara automatizirani sistem koji nikome nije potreban, i niko ne želi niti može s njim raditi.

Propali projekti su veoma slični jedan drugom. Čini se da kopiraju jedno drugo, igrajući isti scenario. Dugogodišnje praćenje loših praksi navelo me je da napišem nekoliko pravila za menadžere kompanija koja će im pomoći da izbjegnu većinu tipične greške prilikom implementacije automatizacije upravljanja preduzećem. Jednako su pogodni za projekte automatizacije budžetiranja, upravljačko računovodstvo, upravljanje proizvodnjom i druge oblasti korporativno upravljanje.

Mora se naglasiti da su ovi savjeti upućeni, prije svega, najvišem menadžmentu organizacije, odnosno vlasniku ili generalnom direktoru kompanije, koji se ponašaju kao kupci? promjene u oblasti korporativnog upravljanja, uključujući stvaranje automatiziranih sistema. Nerazumijevanje od strane osoba?višeg ešalona? njegova uloga u ovakvim projektima je glavni razlog neuspjeha takvih poduhvata.

Prvo. Definirajte svrhu projekta

Prema istoj statistici, sedamdeset posto neuspješnih projekata je to postalo zbog neizvjesnosti svojih ciljeva. Drugim riječima, krajnji rezultat nije bio jasno definiran od početka.

Primjer iz prakse. Rukovodilac službe informacionih tehnologija jednog velikog holdinga dobija od generalnog direktora zadatak da implementira automatizovani sistem koji će obezbediti vrhunski nivo korporativnog upravljanja brzim i pouzdanim informacijama. Šef IT službe u potrazi za softver pogodan za rešavanje zadatih problema, obraća se konsultantima. Na naše pitanje koji su problemi naveli menadžment kompanije da implementira automatizovani sistem, dat je sledeći odgovor:

· nedostatak jedinstvenog formata za predstavljanje podataka upravljačkog računovodstva.

· nedostatak propisa za generisanje izvještaja menadžmenta.

· nedostatak jedinstvenog informacionog okruženja

Apsolutno je jasno da su prva dva?problema? nisu vezani za automatizaciju, a ovo drugo nije problem, budući da je postojanje jedinstvenog informacionog okruženja? samo po sebi br praktična korist nema pojma.

Upoznavanje sa stvarnim stanjem u kompaniji dovelo je do shvatanja da postoji problem delegiranja ovlašćenja direktora korporacije na menadžere poslovnih jedinica. Ona se mora rješavati uz pomoć kontrolinga, baziranog na redovnom planiranju i upravljačkom računovodstvu, kao i odgovarajućom motivacijom rukovodilaca. Drugim riječima, treba li prije svega govoriti o uspostavljanju procesa upravljanja na korporativnom nivou, pa tek nakon toga? o automatizaciji ovih procesa. Pošto su to shvatili, menadžeri kompanije su uštedeli mnogo novca napuštajući besmislenu automatizaciju.

Duboko razumijevanje ciljeva projekta može dovesti do odustajanja od njegove implementacije ili odgađanja rokova zbog revizije prioriteta.

Ciljevi automatizacije moraju biti formulisani ne u terminima tehničke prednosti, ali sa stanovišta poslovnih interesa. Mogu se definisati, na primjer, ovako:

· smanjenje zaliha u skladištu zbog preciznijeg planiranja proizvodnje i nabavke;

· smanjenje potraživanja zbog informatička podrška rad sa dužnicima;

· realizacija većeg broja investicionih projekata eliminacijom rutinskih operacija koje obavljaju kvalifikovani menadžeri.

Ovakva definicija ciljeva omogućit će vam da shvatite zašto to radite, koliko ste spremni platiti za rješavanje ovih problema i, što je vrlo važno, da dobijete kriterije za uspjeh projekta po kojima možete ocijeniti konačne rezultate.

Sekunda. Otvorite projekat

Implementacija automatizovanog sistema je strateški projekat kompanije. Mora se otvoriti po nalogu generalnog direktora. Naredbom se definišu ciljevi i rokovi projekta i imenuje rukovodilac projekta.

Primjer iz prakse. Šef velike banke daje instrukcije menadžeru finansijskog upravljanja da implementira sistem budžetiranja. I pored toga što je od imenovanja prošlo više od godinu dana, imenovani rukovodilac ne razume koja ovlašćenja ima u vezi sa ovim zadatkom, kakvi se rezultati iu kom roku od njega očekuju. Čini se da projekat postoji, ali stvari ne idu naprijed.

Drugim riječima, morate jasno razumjeti šta je projekat? Ovo je punopravna organizaciona struktura, privremeno stvorena unutar organizacije radi postizanja vrlo specifičnih ciljeva.

Projektni tim formira menadžer kojeg imenuje generalni direktor. Uključuje šefove odjela i stručnjake koji su zainteresirani za konačni rezultat i kompetentni za predmetnu oblast projekta. Dakle, ako se implementira sistem budžetiranja, tada projektni tim čine menadžeri i stručnjaci iz finansijskih i IT službi, kao i predstavnici sektora proizvodnje i prodaje. Vođa projekta treba da bude menadžer koji zauzima višu poziciju u organizacionoj strukturi preduzeća od bilo kog člana projektnog tima.

Treće. Obezbijedite projektu resurse

Ključni resursi- to je novac i ljudi. Stoga je potrebno odobriti budžet projekta.

Ocjena neophodna sredstva- nije lak zadatak, a ipak je u fazi opravdavanja projekta važno razumjeti koji budžet se smatra prihvatljivim za razvoj tehnologije upravljanja i implementacija automatizovanog sistema. Činjenica je da je rješenje za bilo koji problem trokut: novac - vrijeme - rezultat. Ako je željeni rezultat precizno definiran, tada se može izračunati vrijeme potrebno za njegovo postizanje i budžet. Ako nema jasne ideje o tome šta je "dobar rezultat" (to jest, ciljevi projekta nisu precizno definirani), onda možete ići iz budžeta i riješiti problem u ovom obliku: koji je maksimum upravljački efekat koji se može postići ako se određeni iznos uloži u uspostavljanje upravljanja procesima i implementaciju informacionih tehnologija?

Osim toga, važno je izdvojiti dio radnog vremena ljudi uključenih u projekat za obavljanje poslova vezanih za implementaciju sistema. Inače?promet? upropastiće stvar. Široko rasprostranjena praksa je da se zaposlenima daje zadatak da implementiraju novi sistem upravljanje?opciono?. Budući da im se glavni posao ne smanjuje, dodatni posao tretiraju ili kao hobi ili kao dosadno opterećenje, ovisno o stepenu njihovog interesovanja. Ovakav stav je sasvim prirodan, jer im je uprava kompanije povjerila neplaćeno dodatni posao, demonstrirao je sopstveni odnos prema njoj kao nečemu sporednom.

Kontrola ljudskim resursima projekat uključuje budžetiranje vremena izvođača. Obračun stvarno utrošenog vremena je neophodan ne samo za adekvatnu naplatu izvođača, već i za ispravnu procjenu troškova projekta.

Četvrto. Vodite računa o motivaciji

Motivacija- ključni element menadžmenta, tako da treba pažljivo razmotriti motivacionu šemu za izvođače projekta. To ne moraju nužno biti veliki bonusi za uspješnu implementaciju sistema.

Najčešće, uvođenje novog sistema upravljanja pomaže poboljšanju statusa učesnika u ovom poslu i povećava njihov profesionalni nivo. Ovo su veoma značajni podsticaji. Činjenica je da kreativni ljudi na rad gledaju kao na sredstvo za povećanje svog intelektualnog kapitala. Takvi stručnjaci predstavljaju najveću vrijednost za svaki posao koji se odnosi na inovacije.

Za menadžera koji formira projektni tim važno je da pravilno razumije očekivanja izvođača vezanih za uspjeh ovog posla. To može biti karijera, povećanje plata, sticanje novih znanja, postizanje novih visina u profesionalnom razvoju.

Peto. Podrška menadžmentu

Uspjeh je moguć samo ako projekat ima snažnu podršku najvišeg menadžmenta kompanije. Ako CEO smatra da je uvođenje automatiziranog sistema- ovo je samo stvar IT službe, onda od toga neće biti ništa dobro.

Implementirati informacione tehnologije- ne znači samo instaliranje programa na radne stanice. Ovakvi projekti su povezani sa promjenama u procesima rada i upravljanja, preraspodjelom odgovornosti i ovlaštenja. Ove promjene često dolaze u sukob sa interesima pojedinih šefova odjeljenja i zaposlenih. Kao rezultat, počinje sabotaža ili otvoreni otpor promjenama. Stoga šef organizacije mora jasno pokazati na čijoj je strani i, ako je potrebno, čvrstom rukom suzbiti otpor, pružajući podršku projektnom timu.

Šesto. Podijelite projekat na faze

Dugoročni projekat je najbolji„isjeći na komadiće“ i nemojte prelaziti na sljedeću fazu, a da niste bili sigurni da su zadaci prethodne faze u potpunosti završeni. Veoma je važno odrediti šta bi trebalo da bude rezultat svake faze projekta.

Tako, na primjer, ako govorimo o kreiranju automatiziranog sistema upravljanja budžetom, preporučuje se slijed koraka prikazan na slici.

Na sljedeću fazu možete preći tek nakon što su ispunjena tri uslova:

· projektni tim je razvio zajedničko razumijevanje rezultata faze;

· ovo shvatanje je formalizovano u obliku dokumenta;

· rezultate faze prihvata kupac, odnosno rukovodilac preduzeća.

Ovaj pristup vam omogućava da kontrolišete rizike projekta, progresivno se krećući ka planiranom cilju.

Sedmo. Upravljajte ciljevima i očekivanjima

Ciljevi projekta se mogu prilagoditi ili čak značajno promijeniti tokom rada. Ovo je uobičajena praksa. Situacija se mijenja, naše razumijevanje situacije se mijenja i dolazimo do zaključka da su naši dosadašnji stavovi zastarjeli ili pogrešni. Stoga se trebate redovno (u svakoj fazi projekta) vraćati korijenima? i kritički ispitati sve osnovne premise.

I još jedna stvar. Morate imati hrabrosti da zatvorite projekat ako postane jasno da je došao u ćorsokak. Menadžer projekta koji je pokrenuo inicijativu da se prekine beznadežan projekat zaslužuje ohrabrenje kao odgovoran menadžer koji je sprečio rasipanje sredstava preduzeća.

Faza "Preliminarni rad na pripremi projekta implementacije IS." Tokom pretprojektne ankete preduzeća prikupljaju se detaljne informacije o strukturnoj strukturi organizacije, funkcionalnim odnosima, sistemu upravljanja, glavnim poslovnim procesima, tokovima unutar preduzeća (Kontrolni tok, Tok dokumenata, tok podataka, tok rada, gotovina Protok), neophodnih za izradu odgovarajućih modela i izbor objekata za automatizaciju. Procjenjuju se vrijeme, resursi, vrste i obim posla, obim i cijena softvera, hardvera i telekomunikacija, troškovi obuke osoblja itd.

Faza "Priprema projekta". Nakon završetka prve faze, vrši se prethodno planiranje i formiranje procedura pokretanja projekta:

formiranje projektnih i stručnih grupa;

raspodjela ovlaštenja i odgovornosti;

utvrđivanje organizacionih i tehničkih uslova za proces implementacije;

pojašnjavanje specifikacija i očekivanja kupaca;

obuka grupe za implementaciju koju čine stručnjaci iz preduzeća klijenta.

Iz nekog razloga, posljednja, vrlo važna tačka se često propušta prilikom izrade plana implementacije. Ali uspjeh cijelog projekta uvelike ovisi o tome! Nakon početka finansiranja, projekat se smatra pokrenutim.

Faza "Idejna izrada projekta". Tokom ove faze:

formira se i odobrava idejni projekat;

postiže se obavezno nedvosmisleno razumijevanje namjera svih učesnika projekta u vezi sa implementiranim IS;

ciljevi i zadaci projekta su pojašnjeni i specificirani;

određuju se dimenzije prototipa sistema;

dogovara se prošireni plan rada, redoslijed faza i uslovi probnog rada, planiranje, finansijski i izvještajni indikatori;

Štaviše, sve ove radnje moraju biti dokumentovane, usaglašene i odobrene od svih zainteresovanih i odgovornih strana.

Rice. 3. Okvirni sadržaj repozitorija implementacionog projekta

Faza "Implementacija projekta". Tokom glavnog implementacionog rada kreira se, instalira i konfiguriše sistemsko okruženje, određuju se procedure administracije sistema i instaliraju osnovni hardverski i softverski sistemi i aplikacije. Sistem konfiguriše organizacione, kadrovske i organizaciono-funkcionalne strukture preduzeća koristeći organizacione jedinice kao što su filijala, odeljenje, odeljenje, radna grupa itd.

Izvodi se instalacija, konfiguracija i podešavanje mrežnih i telekomunikacionih alata, prenos podataka sa prethodnih lokalnih sistema i formiranje interfejsa sa naslijeđenim i eksternim sistemima. Istovremeno, svi kreirani modeli, planovi, radni softverski proizvodi i dokumentacija se stavljaju u end-to-end repozitorijum projekta implementacije (slika 3). Važan dio ovog spremišta je dokumentacijski sistem generiran u okviru projekta (slika 4).

Razrađuju se sistemska sigurnosna pitanja rada sistema u višekorisničkom režimu. Kreiraju se aplikacije, šabloni, izvještaji, obrasci za pristup klijentima, a korisnička prava se distribuiraju. Svi sistemi se testiraju u "borbenom režimu" uz učešće svih zainteresovanih strana.

Rice. 4 Okvirni sastav dokumentacije za proces implementacije IS

Nakon završetka faze implementacije, projekat implementacije se smatra završenim. Informacioni sistem je pušten u rad.